Le streaming de données en 2026 n'est plus une technologie d'avant-garde : c'est une brique d'infrastructure, au même titre qu'une base de données ou qu'un bus d'intégration. Apache Kafka en reste la référence, et les derniers mois ont surtout consolidé l'existant : un Kafka qui fonctionne entièrement sans ZooKeeper depuis la version 4.0 1, des files de messages natives déclarées prêtes pour la production en version 4.2 2, et un marché des offres managées recomposé par la finalisation, le 17 mars 2026, du rachat de Confluent par IBM 4.
Pour une DSI, la question n'est donc plus de savoir s'il faut faire du streaming, mais pour quels flux, sur quelle plateforme et avec quel modèle d'exploitation. Cet article fait le point sur l'état technique de Kafka, sur le paysage des plateformes managées et sur les cas d'usage qui justifient réellement l'investissement.
Les autres articles de cette série approfondissent l'architecture orientée événements, l'arbitrage entre Kafka auto-géré et managé, le Change Data Capture et l'alimentation de l'IA en données fraîches. Celui-ci sert de carte d'ensemble.
Kafka 4.x : ce qui a changé dans le moteur du streaming de données
La fin de ZooKeeper
Publiée en mars 2025, Kafka 4.0 est la première version majeure qui fonctionne entièrement sans Apache ZooKeeper 1. Les métadonnées du cluster sont désormais gérées par le mode KRaft, un quorum de contrôleurs intégré à Kafka, qui devient le mode par défaut et unique. Il n'y a donc plus d'ensemble ZooKeeper séparé à dimensionner, sécuriser, superviser et mettre à jour.
La contrepartie est très concrète pour les parcs existants : un cluster encore sous ZooKeeper ne peut pas passer directement en 4.x, il doit d'abord être migré vers KRaft. La version 4.0 relève aussi les prérequis d'exécution : Java 17 pour les brokers, Kafka Connect et les outils, Java 11 pour les clients et Kafka Streams 1. Ces deux points suffisent à transformer une simple montée de version en projet à part entière, avec inventaire, tests de non-régression et fenêtre de bascule.
Des files de messages natives
La nouveauté fonctionnelle la plus structurante est l'arrivée des share groups (KIP-932), présentés sous le nom de Kafka Queues. Introduits en accès anticipé dans la 4.0 1, ils sont déclarés prêts pour la production dans Kafka 4.2, publiée en février 2026 2. Le principe : plusieurs consommateurs traitent en parallèle les enregistrements d'une même partition, avec un acquittement enregistrement par enregistrement et sans affectation fixe entre partitions et consommateurs 2. La 4.2 ajoute notamment un type d'acquittement RENEW pour prolonger le verrou sur un traitement lent 2.
Cela affaiblit l'un des arguments historiques pour maintenir une infrastructure séparée dédiée aux files de travail. Cela ne rend pas pour autant caducs les brokers de messagerie transactionnelle déjà en place : le choix se fait au cas par cas, selon les garanties attendues et l'existant applicatif.
Un rythme de versions soutenu
Kafka 4.3, publiée le 22 mai 2026, embarque 25 KIP et plus de 600 commits depuis la 4.2 3. On y trouve par exemple la mise en quarantaine (cordoning) de répertoires de logs pour faciliter le retrait de brokers, des améliorations du stockage hiérarchisé et de nouveaux paramètres pour les share groups 3. Elle annonce aussi des dépréciations en vue de Kafka 5.0 et recommande déjà le nouveau protocole de rééquilibrage des consommateurs 3, disponible depuis la 4.0 mais à activer explicitement côté client avec group.protocol=consumer 1.
En 2026, le vrai sujet n'est plus d'adopter Kafka mais de tenir son rythme de versions sans dette d'exploitation.
Le paysage des plateformes managées après le rachat de Confluent
IBM a finalisé le 17 mars 2026 l'acquisition de Confluent, à 31 dollars par action en numéraire, pour une valeur d'entreprise d'environ 11 milliards de dollars 4. Le communiqué positionne Confluent comme la couche de flux temps réel qui alimente watsonx.data, qui diffuse les données transactionnelles d'IBM Z et qui complète IBM MQ et webMethods Hybrid Integration 4. Apache Kafka reste pour sa part un projet de l'Apache Software Foundation, distinct des offres commerciales construites au-dessus.
Côté hyperscalers, l'offre s'est également étoffée. Amazon MSK propose un mode provisionné avec brokers Standard ou Express, ainsi qu'un mode Serverless facturé à l'heure de cluster, à la partition et au volume écrit et lu 7. Google Cloud Managed Service for Apache Kafka est en disponibilité générale depuis le 12 novembre 2024 et a reçu en 2026 des connecteurs PostgreSQL pour Kafka Connect et la compression zstd 5. Azure Event Hubs, enfin, expose un point d'accès compatible avec le protocole Kafka sans être un cluster Kafka 6.
Compatibilité de protocole n'est pas équivalence fonctionnelle
Cette distinction est essentielle. Selon la documentation Microsoft à la date de rédaction, Kafka Streams et les transactions Kafka sont en préversion publique et réservés aux niveaux Premium et Dedicated, et seule la compression gzip est prise en charge 6. Une application qui fonctionne sur un cluster Kafka peut donc nécessiter des adaptations, voire ne pas être portable. Avant de retenir une offre, il faut vérifier fonctionnalité par fonctionnalité ce qui est réellement couvert.
- Version de Kafka exécutée et délai habituel de mise à disposition des nouvelles versions.
- Fonctionnalités couvertes : transactions, Kafka Streams, share groups, stockage hiérarchisé, Kafka Connect managé.
- Localisation des données, juridiction de l'opérateur et options de chiffrement avec clés maîtrisées.
- Dimensions de facturation : instances ou unités de capacité, stockage, volume entrant et sortant, partitions, connectivité privée 7.
- Réversibilité : réplication vers un autre cluster, export des schémas, des ACL et des configurations de topics.
Les cas d'usage qui justifient le streaming
Le streaming apporte de la valeur quand le délai entre un fait métier et la réaction du système a un coût mesurable, ou quand plusieurs systèmes doivent réagir au même événement. Cinq familles de cas d'usage reviennent régulièrement dans les SI des ETI et des grands comptes.
- Synchronisation du SI : propager les changements d'un ERP ou d'une base cœur de métier vers les autres applications sans multiplier les interfaces point à point.
- Détection et réaction : fraude, anomalies de paiement, incidents de production, où une décision prise une heure plus tard ne sert plus à rien.
- Logistique, industrie et IoT : suivi d'expéditions, télémétrie d'équipements, alertes de maintenance.
- Observabilité et sécurité : collecte centralisée de journaux et d'événements techniques avant leur routage vers les outils d'analyse.
- Alimentation analytique et IA : ingestion continue vers un lakehouse, calcul de variables fraîches pour les modèles et contexte à jour pour les agents.
À l'inverse, un reporting consolidé en J+1, des volumes faibles ou un unique consommateur ne justifient généralement pas une plateforme de streaming : un traitement par lots bien orchestré reste plus simple à exploiter. Le bon réflexe consiste à partir de l'exigence de fraîcheur réelle, exprimée par le métier, plutôt que de la technologie.
Souveraineté, sécurité et gouvernance des flux
Les topics Kafka transportent souvent les mêmes données que les bases dont elles proviennent : données clients, transactions, informations de santé ou de paie. Ils doivent donc être soumis aux mêmes exigences de protection, de durée de conservation et de traçabilité. Un topic dont la rétention est réglée par défaut, sans réflexion sur la finalité, est un angle mort classique de la conformité.
Le choix de la plateforme intègre aussi la question de la souveraineté : nationalité de l'opérateur, localisation des sauvegardes, accès du support. Pour certains flux sensibles, un déploiement sur une infrastructure qualifiée ou sur site reste préférable, quitte à combiner plusieurs plateformes reliées par réplication. La gouvernance des schémas et des droits d'accès doit alors être homogène d'un environnement à l'autre.
Feuille de route : par où commencer en 2026
Que vous partiez de zéro ou d'un parc Kafka existant, la démarche suivante permet d'éviter les investissements sans retour.
- Inventorier les flux candidats et, pour chacun, l'exigence de fraîcheur, le volume et le nombre de consommateurs.
- Pour un parc existant, recenser les clusters encore sous ZooKeeper et les versions Java, puis planifier la migration vers KRaft avant toute montée en 4.x 1.
- Choisir le modèle d'exploitation (auto-géré, managé, hybride) à partir d'un coût total chiffré et d'exigences de souveraineté explicites.
- Définir des contrats d'événements versionnés, un registre de schémas et une convention de nommage des topics avant la mise en production.
- Fixer la rétention, le chiffrement et les ACL topic par topic, en lien avec le DPO et le RSSI.
- Mesurer la valeur sur un premier cas d'usage avant de généraliser.
Conclusion
Le streaming de données a atteint sa maturité : Kafka 4.x simplifie l'architecture, les files natives élargissent son périmètre et les offres managées se sont multipliées. La difficulté s'est déplacée vers l'exploitation, la gouvernance et le choix d'un modèle de plateforme cohérent avec les contraintes de souveraineté. Partenaire intégrateur IBM et Confluent, DATASWING accompagne ces choix d'architecture et de trajectoire de migration.
— Questions fréquentes
Ce qu'on nous demande souvent
Kafka 4 fonctionne-t-il encore avec ZooKeeper ?+
Non. Depuis Kafka 4.0, publiée en mars 2025, le mode ZooKeeper a été retiré et seul le mode KRaft est pris en charge : les métadonnées sont gérées par un quorum de contrôleurs intégré à Kafka. Un cluster encore sous ZooKeeper doit donc être migré vers KRaft avant de pouvoir être mis à jour vers une version 4.x.
Kafka peut-il remplacer une file de messages classique ?+
En partie. Les share groups, ou Kafka Queues, sont déclarés prêts pour la production depuis Kafka 4.2. Ils permettent à plusieurs consommateurs de traiter une même partition avec un acquittement enregistrement par enregistrement. Cela couvre de nombreux besoins de files de travail, mais le remplacement d'un broker existant doit être évalué au regard des garanties attendues et de l'existant applicatif.
Qu'est-ce que le rachat de Confluent par IBM change pour les clients ?+
IBM a finalisé l'opération le 17 mars 2026. Le groupe positionne Confluent comme la couche temps réel de watsonx.data, d'IBM Z et de ses outils d'intégration. Pour les clients, il convient de suivre l'évolution des feuilles de route, des contrats et du support, tout en gardant à l'esprit qu'Apache Kafka reste un projet open source de la fondation Apache.
Azure Event Hubs est-il un vrai service Kafka ?+
Event Hubs expose un point d'accès compatible avec le protocole Kafka, ce qui permet souvent de connecter des clients Kafka en changeant seulement la configuration. Ce n'est toutefois pas un cluster Kafka : à la date de rédaction, Kafka Streams et les transactions sont en préversion sur les niveaux Premium et Dedicated, et seule la compression gzip est prise en charge.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
Apache Kafka 4.0.0 Release Announcement ↗Apache Software Foundation · 2025-03
-
[2]
Apache Kafka 4.2.0 Release Announcement ↗Apache Software Foundation · 2026-02
-
[3]
Apache Kafka 4.3.0 Release Announcement ↗Apache Software Foundation · 2026-05
-
[4]
IBM Completes Acquisition of Confluent, Making Real-Time Data the Engine of Enterprise AI and Agents ↗IBM (PR Newswire) · 2026-03
-
[5]
Google Cloud Managed Service for Apache Kafka release notes ↗Google Cloud · 2026
-
[6]
Azure Event Hubs for Apache Kafka overview ↗Microsoft Learn · 2026
-
[7]
Amazon MSK pricing ↗Amazon Web Services · 2026
