Infrastructure de données en temps réel : comment Apache Kafka

Le changement de paradigme du batch vers le streaming

Pendant des décennies, le traitement des données d’entreprise a suivi un paradigme batch : collecter les données tout au long de la journée, les charger dans un entrepôt de données durant la nuit, et les analyser le lendemain matin. Les pipelines ETL (Extract, Transform, Load) fonctionnaient selon des planifications — horaires, quotidiennes, hebdomadaires — alimentant des entrepôts de données que les analystes interrogeaient pendant les heures de bureau. Ce modèle fonctionnait lorsque les décisions commerciales opéraient sur des cycles quotidiens ou hebdomadaires et que le coût du traitement temps réel était prohibitif.

Ce modèle est en train de s’effondrer. Les entreprises modernes exigent la détection de fraude en temps réel (Visa traite jusqu’à 83 000 messages de transaction par seconde et analyse plus de 500 points de données par transaction pour signaler la fraude en millisecondes), des moteurs de recommandation instantanés (Netflix personnalise son interface pour plus de 325 millions d’abonnés en fonction du comportement de la session en cours), une tarification dynamique (la tarification dynamique d’Uber s’ajuste chaque minute en fonction de l’offre et de la demande), et le traitement de capteurs IoT (une usine moderne génère des téraoctets de télémétrie quotidiennement à partir de milliers de capteurs nécessitant une analyse immédiate). La question n’est plus « avons-nous besoin du temps réel ? » mais « quelles charges de travail justifient la complexité du temps réel, et quelle infrastructure le supporte ? »

La réponse, pour une part croissante de l’industrie technologique, est le traitement de flux — et la pile technologique qui a émergé pour le supporter est ancrée par Apache Kafka, Apache Flink et une constellation d’outils complémentaires. Cette infrastructure traite désormais des billions d’événements quotidiennement dans plus de 150 000 organisations, représentant un changement fondamental dans la circulation des données à travers les entreprises. Le marché du traitement de flux d’événements a atteint 1,21 milliard de dollars en 2025 et devrait croître de 16 % par an pour atteindre 2,94 milliards de dollars d’ici 2030.

Apache Kafka : le système nerveux central

Apache Kafka, initialement développé chez LinkedIn en 2010 et publié en open source en 2011, est devenu le standard de facto pour le streaming d’événements distribué à haut débit. L’abstraction fondamentale de Kafka est élégante : un journal distribué en ajout seul organisé en topics, où les producteurs écrivent des événements et les consommateurs les lisent. Les événements sont persistés de manière durable et peuvent être rejoués, permettant le découplage des microservices, les patterns d’event sourcing et les pipelines d’analytique temps réel.

Les chiffres sont impressionnants. LinkedIn traite plus de 7 billions de messages par jour via Kafka à travers plus de 100 clusters avec plus de 4 000 brokers, gérant plus de 100 000 topics et 7 millions de partitions. Apple exploite l’un des plus grands déploiements Kafka au monde, traitant plusieurs pétaoctets de données quotidiennement. Netflix, Uber, Airbnb, Goldman Sachs et le New York Times utilisent tous Kafka à grande échelle. Le rapport 2025 de Confluent sur le Data Streaming, interrogeant 4 175 responsables IT, a révélé que plus de 80 % des entreprises du Fortune 500 utilisent Kafka ou des systèmes compatibles, et 86 % des répondants identifient le streaming de données comme une priorité stratégique majeure. La force de Kafka réside dans sa combinaison de haut débit (millions d’événements par seconde par cluster), faible latence (millisecondes à un chiffre de bout en bout), durabilité (réplication entre brokers avec cohérence configurable) et maturité opérationnelle (plus de 15 ans de durcissement en production).

Le changement architectural le plus important de l’histoire de Kafka est arrivé en mars 2025 avec la sortie d’Apache Kafka 4.0. Cette version a complètement supprimé Apache ZooKeeper — le service de coordination externe dont Kafka dépendait depuis sa création — le remplaçant entièrement par KRaft (Kafka Raft), un mécanisme de consensus intégré à Kafka lui-même. KRaft gère les métadonnées en utilisant le propre journal de Kafka, éliminant la complexité opérationnelle de maintenance d’un ensemble ZooKeeper séparé. Kafka 3.9 était la dernière version supportant ZooKeeper ; les organisations utilisant des versions plus anciennes doivent migrer vers le mode KRaft avant de passer à la 4.0.

Le méga-accord IBM-Confluent et l’écosystème commercial

Confluent, fondée en 2014 par les créateurs originaux de Kafka (Jay Kreps, Neha Narkhede, Jun Rao), a été le gardien commercial de l’écosystème Kafka. L’entreprise propose Confluent Cloud (Kafka entièrement managé en tant que service), Confluent Platform (distribution entreprise auto-gérée), et des produits complémentaires incluant Schema Registry, ksqlDB (interface SQL pour les flux Kafka), et des connecteurs vers plus de 200 systèmes de données. Le revenu annualisé de Confluent a dépassé 1,1 milliard de dollars en septembre 2025, en croissance de plus de 21 % en glissement annuel.

Le 8 décembre 2025, IBM a annoncé un accord définitif pour acquérir Confluent à 31 dollars par action en espèces — soit une valeur d’entreprise d’environ 11 milliards de dollars. L’opération, qui devrait se conclure d’ici mi-2026, est la plus grande acquisition dans l’écosystème du streaming de données à ce jour. Le PDG d’IBM, Arvind Krishna, a déclaré que « les données temps réel sont extrêmement importantes pour le fonctionnement d’une entreprise », présentant l’acquisition comme la création d’une plateforme unifiée combinant les capacités IA watsonx d’IBM avec le streaming de données temps réel de Confluent. Confluent continuera à opérer en tant que marque distincte au sein d’IBM.

L’accord IBM-Confluent signale une conviction plus large de l’industrie : l’infrastructure de données temps réel n’est plus une préoccupation de niche — c’est une exigence fondamentale pour les entreprises, particulièrement à mesure que les organisations construisent des systèmes d’IA qui dépendent de données fraîches et contextuelles. Le rapport 2025 de Confluent a révélé que 87 % des responsables IT s’attendent à ce que les plateformes de streaming alimentent de plus en plus les systèmes d’IA avec des données temps réel, contextuelles et fiables.

Traitement de flux : Flink 2.0, Spark et le mouvement SQL-sur-flux

Kafka gère le transport des données — acheminer les événements du point A au point B de manière fiable et à grande échelle. Mais traiter ces événements en temps réel — agréger, filtrer, joindre, fenêtrer et transformer les flux — nécessite un moteur de traitement de flux. C’est là qu’interviennent Apache Flink, Apache Spark Structured Streaming et les nouveaux entrants comme Materialize et RisingWave.

Apache Flink a franchi une étape majeure en mars 2025 avec la sortie de Flink 2.0.0 — sa première version majeure depuis le lancement de Flink 1.0 neuf ans auparavant. La version a introduit la gestion d’état désagrégée pour une utilisation efficace des ressources cloud-natives, des tables matérialisées permettant aux utilisateurs de se concentrer sur la logique métier, et une intégration profonde avec Apache Paimon pour les architectures de streaming lakehouse. Plus de 165 contributeurs ont complété 25 propositions d’amélioration de Flink pour la version 2.0.

Le rythme s’est accéléré en 2025. Flink 2.1.0 (juillet 2025) a ajouté la gestion de modèles IA et ML_PREDICT, une fonction permettant l’inférence de modèles IA en temps réel directement dans Flink SQL. Flink 2.2.0 (décembre 2025) a étendu cela avec l’inférence de grands modèles de langage et VECTOR_SEARCH pour les recherches vectorielles en temps réel — des capacités qui positionnent Flink non plus comme un simple processeur de flux mais comme une plateforme de données et d’IA temps réel. En février 2026, la communauté Flink a publié Flink Agents 0.2.0, un nouveau sous-projet pour construire des agents IA événementiels directement sur le runtime de streaming de Flink. Flink fournit une sémantique de traitement exactly-once, le traitement par temps d’événement et des opérations de fenêtrage sophistiquées. Alibaba, le plus grand utilisateur de Flink, exécute sa version modifiée appelée Blink pour traiter des milliards d’événements par seconde lors des pics comme le Singles’ Day. Uber utilise Flink pour l’analytique temps réel de sa marketplace, et Stripe l’utilise pour le scoring de fraude en temps réel.

Apache Spark Structured Streaming, faisant partie de l’écosystème Spark plus large, offre le traitement de flux avec l’avantage d’une API unifiée batch-et-streaming. Databricks, l’entreprise commerciale derrière Spark désormais valorisée à 134 milliards de dollars après une levée de fonds de 5 milliards de dollars début 2026, a massivement investi pour rendre Structured Streaming prêt pour la production. Cependant, Spark Structured Streaming fonctionne en micro-batches (traitant les données par petits intervalles, typiquement 100ms-1s), ce qui le rend légèrement plus lent que le traitement événement-par-événement de Flink. Pour les cas d’usage où la latence sous la seconde est critique — fraude de paiement, enchères temps réel — Flink est généralement préféré.

Materialize, soutenu par plus de 100 millions de dollars de financement, adopte une approche différente : il fournit des vues matérialisées maintenues incrémentalement sur des données de streaming, accessibles via du SQL standard compatible PostgreSQL. RisingWave, une alternative open source avec plus de 8 400 étoiles sur GitHub, offre un modèle SQL-sur-flux similaire. Ces outils représentent un pari que le traitement de flux peut être démocratisé au-delà des ingénieurs spécialisés.

Quand le streaming est nécessaire vs. sur-ingéniéré

L’écosystème d’infrastructure de streaming est puissant, mais il comporte une complexité opérationnelle significative. Un cluster Kafka en production nécessite une gestion soigneuse des partitions, la coordination des groupes de consommateurs, une stratégie d’évolution de schéma et une supervision. Les jobs Flink nécessitent des checkpoints, une gestion d’état et la gestion des données arrivant en retard. Les équipes d’ingénierie qui construisent et maintiennent des pipelines de streaming ont besoin de compétences spécialisées — les ingénieurs data seniors avec une expertise Kafka et Flink commandent 150 000-350 000+ dollars de rémunération totale dans les grandes entreprises technologiques américaines.

L’évaluation honnête : la plupart des applications n’ont pas besoin du streaming temps réel. Un pipeline batch qui traite les données toutes les 5 minutes suffit pour 90 % des cas d’usage analytiques. Les cas d’usage canoniques où l’infrastructure de streaming est véritablement justifiée incluent : la détection de fraude financière (décisions en millisecondes sur l’approbation des transactions), la personnalisation temps réel à grande échelle (millions d’utilisateurs simultanés), le traitement de télémétrie IoT (milliers de capteurs générant des données continues), et la supervision opérationnelle (détection d’anomalies d’infrastructure en temps réel).

L’anti-pattern — et il est courant — est d’adopter Kafka et Flink parce qu’ils sont « modernes » quand une base de données PostgreSQL avec un cron job suffirait. Martin Kleppmann, auteur de « Designing Data-Intensive Applications », a noté que le budget de complexité d’une organisation est fini, et le dépenser en infrastructure de streaming qui apporte une valeur marginale par rapport au batch est un négatif net. Le cadre de décision devrait être : quel est le coût métier de la latence ? Si traiter les données en 5 minutes au lieu de 5 secondes n’a aucun impact métier mesurable, le batch l’emporte en simplicité, coût et charge opérationnelle.

La réalité opérationnelle et l’orientation future

Exploiter une infrastructure de streaming à grande échelle est une discipline opérationnelle. Les clusters Kafka nécessitent la surveillance du retard des consommateurs, de la santé des brokers (utilisation disque, nombre d’ISR — in-sync replicas), et de l’équilibrage des partitions. Les applications Flink nécessitent la surveillance des durées de checkpoint, de la rétropression (backpressure) et de la croissance de la taille d’état. La pile d’observabilité pour le streaming — typiquement Prometheus, Grafana et des outils spécifiques Kafka comme Burrow ou Conduktor — représente elle-même un investissement en infrastructure non négligeable.

Les services managés ont réduit mais pas éliminé cette charge opérationnelle. Confluent Cloud gère l’infrastructure Kafka. Amazon MSK (Managed Streaming for Apache Kafka) offre un service similaire dans l’écosystème AWS. Pour Flink, Amazon Managed Service for Apache Flink et Realtime Compute d’Alibaba Cloud fournissent des environnements d’exécution managés. Ces services gèrent la couche infrastructure mais nécessitent toujours une expertise au niveau applicatif.

La trajectoire de l’écosystème de streaming pointe vers deux thèmes convergents : la simplification et l’intégration IA. La vision de Confluent d’une « plateforme de streaming de données » — où Kafka n’est pas simplement un bus de messages mais une plateforme complète d’intégration et de traitement des données avec gouvernance, lignage et interfaces SQL intégrés — est désormais renforcée par la portée entreprise et les ambitions IA d’IBM. La montée des outils SQL-sur-flux (Materialize, RisingWave, ksqlDB) suggère que le traitement de flux deviendra accessible aux analystes, pas seulement aux ingénieurs. Et l’intégration du streaming avec les pipelines IA/ML est passée d’une frontière émergente à un déploiement actif : Flink 2.x supporte désormais nativement l’inférence de modèles IA et la recherche vectorielle, les feature stores temps réel comme Tecton et Feast sont construits sur Kafka et Flink, et l’accord IBM-Confluent est explicitement cadré autour de l’alimentation des systèmes d’IA générative avec des données d’entreprise temps réel. L’ère des données temps réel n’arrive pas — pour les organisations qui en ont besoin, elle est déjà là.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Apache Kafka 4.0: Default KRaft, Queues, Faster Rebalances — Confluent
• Apache Flink 2.0.0: A New Era of Real-Time Data Processing — Apache Flink
• IBM to Acquire Confluent to Create Smart Data Platform for Enterprise Generative AI — IBM Newsroom
• How LinkedIn Customizes Apache Kafka for 7 Trillion Messages Per Day — LinkedIn Engineering
• 2025 Data Streaming Report — Confluent
• Apache Flink 2.2.0: Advancing Real-Time Data + AI — Apache Flink
• Databricks Surpasses $5.4B Revenue Run-Rate, Growing 65% YoY — Databricks
• Top Trends for Data Streaming with Apache Kafka and Flink in 2026 — Kai Waehner
• Inside Visa’s Engine of Global Commerce — Visa
• Designing Data-Intensive Applications — Martin Kleppmann, O’Reilly