Par Andrew Tan
Deux faits qui se retrouvent constamment amalgamés
Apache Kafka reste un protocole ouvert. Vous pouvez l’exécuter sur MSK, sur un cluster que vous gérez, sur Redpanda ou sur Confluent Platform. Le format filaire n’a pas été acquis.
Confluent, l’entreprise qui a transformé ce protocole en pile Kafka commerciale par défaut, est une société IBM depuis le 17 mars 2026. IBM a payé environ 11 milliards de dollars, soit 31 dollars par action. Dès le premier jour, le discours n’était pas « nous restons l’entreprise Kafka indépendante ». Dès le premier jour, il s’agissait de watsonx.data, d’IBM MQ, de webMethods et d’IBM Z. Le Streaming comme carburant pour une plateforme de données IA et d’automatisation hybride.
Considérer ces deux éléments comme un seul et même événement vous fera manquer les 18 prochains mois de décisions produit. Les séparer rendra la prochaine conversation avec votre fournisseur bien plus utile.
Ce qui a réellement été acquis
J’ai déjà rédigé la comparaison technique de Kafka. Ceci est l’article de concentration.
Le jour de la finalisation, IBM a résumé sa thèse dans le titre du communiqué de presse : les données en temps réel comme moteur de l’IA d’entreprise et des agents. Rob Thomas a parlé de modèles et d’agents agissant sur ce qui se passe maintenant. Jay Kreps, encore cité en tant que CEO, a évoqué la mise en mouvement des données du monde à l’échelle d’IBM.
C’est un pari produit différent de « le meilleur Kafka ».
« Best Kafka » signifie rééquilibrages de partitions, qualité des connecteurs, packaging de Flink, références cloud, et savoir si votre page de retard de consommateurs fonctionne encore un mardi. Le pari d’IBM signifie que Confluent Cloud et Platform sont tirés vers watsonx, MQ et le mainframe. Le journal Kafka est la rampe d’accès. La destination est la suite d’IA et d’intégration d’IBM.
Vous pouvez apprécier ce pari. De nombreuses entreprises vivent déjà dans cette suite. Vous ne devriez pas faire semblant qu’il s’agit de la même feuille de route que celle que Confluent vendait en tant que société cotée.
Le fondateur est parti. Le protocole est resté.
Le 13 août, Jay Kreps s’est retiré après presque douze ans. Les transitions de fondateur après une acquisition de 11 milliards de dollars sont normales. Elles indiquent aussi où s’écrit l’histoire.
Les feuilles de route étaient autrefois débattues à Mountain View, sur l’horloge d’une entreprise Kafka. Elles le sont désormais à l’intérieur d’IBM Software, sur l’horloge de watsonx et du mainframe. La cadence des connecteurs, le packaging cloud et la signification de « supporté » suivront cette nouvelle horloge.
Un signal concret est apparu fin octobre. IBM a annoncé l’intégration de watsonx.data pour Apache Flink, avec un canevas visuel et un SDK Python qui soumet des jobs sur Confluent Platform for Apache Flink. Ce n’est pas un tueur de Kafka. C’est IBM qui intègre le traitement de flux dans la gamme de produits watsonx.data. Si vous avez choisi Confluent parce que vous vouliez une entreprise de streaming indépendante, relisez cette phrase.
Je ne prétends pas que le produit s’est dégradé. Je n’ai pas de télémétrie dans Confluent Cloud. Je prétends que le centre de gravité a bougé, et que cela se voit publiquement.
Kafka le langage, IBM l’éditeur
Considérez Kafka comme un langage. Beaucoup de gens le parlent. La grammaire est ouverte. IBM a acheté la plus grande école qui enseignait le dialecte commercial, imprimait les manuels et tenait le stand de certification à la conférence.
Vous pouvez toujours parler le langage. Vous pouvez embaucher des gens qui le parlent. Vous pouvez faire tourner un cluster qui n’envoie jamais un dollar à IBM.
Ce que vous ne pouvez pas supposer, c’est que le chemin commercial par défaut (Confluent Cloud, Confluent Platform, le catalogue de connecteurs sur lequel vous vous êtes déjà standardisé) défendra l’indépendance de Kafka. Il suivra la plateforme de données et d’IA d’IBM. Le double flux d’un topic vers watsonx.data recevra plus d’attention que de rendre trivial le fait de partir.
Les fournisseurs suivent leur thèse. Votre travail est de remarquer que la thèse a changé.
Trois questions que votre prochain QBR devrait inclure
Passez outre la diapositive « êtes-vous toujours engagés envers Kafka ? ». Bien sûr qu’ils le sont. Kafka est l’asset.
Posez plutôt les questions opérationnelles que le communiqué de presse ne couvre pas.
Double exécution pendant les deux prochaines années
Si IBM fusionne des références, renomme les consoles ou vous fait migrer vers un plan de contrôle watsonx, vous avez besoin d’une période pendant laquelle l’ancien chemin et le nouveau produisent les mêmes résultats. La double exécution est ennuyeuse. La double exécution est ce qui vous permet de survivre à une fusion de fournisseurs sans bascule de week-end.
Rejouer quand MQ, Z et un entrepôt sont dans le même incident
La plupart des équipes Kafka savent déjà comment rembobiner un consumer group. Le cas difficile est mixte : un flux, une transaction mainframe, un fichier ERP nocturne et une table Iceberg déjà interrogée. Le schéma du jour 1 d’IBM place tout cela dans une même famille. Votre incident du mardi soir a toujours besoin d’une personne capable de rembobiner l’un sans corrompre les autres.
Si le batch a encore besoin d’un second orchestrateur
Si la réponse est « utilisez Airflow pour les fichiers et Confluent pour les topics », vous n’avez pas acheté une plateforme. Vous avez acheté une suite de streaming et conservé la séparation que vous aviez déjà. Demandez-leur de montrer un Workflow qui rejoue un fichier en retard et un topic défectueux avec la même propriété.
Si votre AE ne peut pas répondre à ces questions sans faire intervenir un architecte de solution et une semaine de délai, vous avez votre signal.
Le problème qui n’a pas été acquis
IBM a acheté une entreprise de streaming. Il n’a pas acheté votre problème de coordination.
Vous devez toujours rattraper un job batch qui a manqué sa fenêtre pendant que le flux continuait. Vous devez toujours rejouer trois heures de messages empoisonnés sans double écriture dans l’entrepôt. Vous devez toujours joindre une dimension à évolution lente à un topic en direct. Vous devez toujours indiquer à un nouvel arrivant quel système est la source de vérité le vendredi après-midi.
Rien de tout cela ne vit dans le protocole Kafka. Le logo IBM sur la console Confluent ne le rend pas plus facile. Une partie devient même plus difficile si la pile commerciale est réorientée vers les agents et watsonx alors que votre charge de travail réelle reste « faire en sorte que le fichier de paiements et le topic de fraude concordent ».
Les équipes avec lesquelles je discute et qui restent sereines à ce sujet n’ont pas écrit « Kafka est open source, on est tranquilles » sur Slack. Elles considèrent déjà le broker comme un transport et conservent l’exécution (réessais, dépendances, replay, approbations) dans un endroit qu’elles contrôlent.
Où nous nous situons
Chez layline.io nous travaillons avec des équipes qui parlent Kafka et qui doivent quand même déposer des fichiers à 18 h. Nous ne sommes pas un remplacement de Kafka et nous ne sommes pas une alternative à IBM. Nous sommes le moteur d’exécution qui se place au-dessus du batch et du streaming afin que le travail de coordination ne vive pas à l’intérieur de la suite du fournisseur de streaming.
Si la plateforme d’IBM est le bon foyer pour vous, utilisez-la. Mais ne confondez pas « nous produisons toujours des enregistrements Kafka » avec « notre modèle opérationnel est inchangé ». Les enregistrements peuvent ressembler aux mêmes. La gravité autour d’eux ne le peut pas.
Si vous êtes sur Confluent Cloud ou Platform et que vous essayez de séparer le confort du protocole de la gravité du fournisseur, contactez-nous. Nous avons aidé des équipes à cartographier la double exécution et le replay entre batch et streaming sans attendre la prochaine renomination.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, qui construit une infrastructure de traitement de données d’entreprise capable de gérer à la fois les charges de travail batch et en temps réel à grande échelle.
