Confluent : Kafka et Flink managés, streaming de données et IBM

Confluent est un éditeur de logiciels qui fournit une plateforme pour faire circuler, traiter et gouverner les données en temps réel. Son produit central est Apache Kafka, un journal d'événements distribué sur lequel les applications publient et lisent des flux de données. Confluent ajoute à Kafka le traitement de flux avec Apache Flink, des connecteurs, la gouvernance et l'exploitation managée.

L'entreprise est fondée en 2014 à Mountain View par Jay Kreps, Neha Narkhede et Jun Rao, trois ingénieurs qui avaient créé Kafka chez LinkedIn au début des années 2010. Le projet est ensuite confié à la fondation Apache. Confluent lance Confluent Platform, puis Confluent Cloud, son service managé, et entre au Nasdaq en 2021. En 2023, elle acquiert Immerok pour proposer Apache Flink en service managé. En 2024, elle rachète WarpStream, un service compatible Kafka qui fonctionne dans le compte cloud du client, et dévoile Tableflow, qui publie les flux sous forme de tables Iceberg.

Le 17 mars 2026, IBM finalise le rachat de Confluent, annoncé en décembre 2025. Confluent est depuis une filiale du groupe, qui souhaite la rapprocher de ses offres de données et d'IA. Les produits et les équipes restent identifiables, mais leur feuille de route peut évoluer : il faut suivre les annonces officielles.

Sa place dans l'écosystème tient à ce rôle de couche de données en mouvement, entre les applications et les plateformes analytiques comme Databricks ou Snowflake. Pour le fonctionnement du protocole, la fiche Apache Kafka du lexique en détaille les notions.

À retenir : Confluent n'est ni un cloud ni une base de données. C'est une plateforme qui transporte et traite des événements entre les systèmes de l'entreprise.

L'offre se répartit selon qui exploite Kafka : Confluent, le client, ou les deux. Le même protocole sert de base dans tous les cas, ce qui limite l'effort de migration pour les applications.

Le choix du mode d'exploitation est le premier arbitrage. Le service managé réduit la charge opérationnelle, le logiciel auto-hébergé répond aux contraintes de souveraineté ou de datacenter, et le mode BYOC garde les données dans le compte cloud du client.

Comment choisir entre Confluent Cloud et Confluent Platform ?

Confluent Cloud convient quand l'équipe veut se concentrer sur les flux et non sur les clusters. Confluent Platform convient quand les données doivent rester sur site ou quand une exigence réglementaire impose de maîtriser l'infrastructure. Dans les deux cas, estimez le coût sur le débit et la rétention réels, car ce sont eux qui déterminent la facture.

Le mode BYOC de WarpStream constitue une troisième voie : le plan de contrôle reste chez l'éditeur, mais les agents qui lisent et écrivent les données s'exécutent dans le compte cloud du client, et les messages sont stockés dans un stockage objet. Cette architecture réduit les coûts de transfert entre zones de disponibilité, au prix d'une latence en général plus élevée qu'avec des disques locaux. Elle convient aux flux massifs dont le délai de quelques centaines de millisecondes reste acceptable, comme la journalisation ou la collecte de télémétrie.

La réponse demande de distinguer Kafka, Flink et la plateforme commerciale. Confluent est une société commerciale, et ses offres sont des produits payants. Les technologies centrales sont cependant des projets ouverts.

• Projets open source : Apache Kafka et Apache Flink sont des projets de la fondation Apache, sous licence Apache 2.0. Ils s'utilisent sans Confluent, sur n'importe quelle infrastructure.
• Composants sous licence communautaire : une partie des outils de Confluent Platform, comme certains connecteurs et le registre de schémas, est publiée sous la licence Confluent Community, qui limite la revente en service concurrent.
• Briques propriétaires : Confluent Cloud, la gouvernance avancée, Tableflow et les fonctions d'administration ne sont disponibles que dans les offres commerciales.

Les données transitent par un protocole ouvert. Une application écrite pour Kafka peut en principe changer de fournisseur, ce qui limite la dépendance au protocole. L'effort de migration porte plutôt sur les connecteurs, les schémas, les droits et les traitements Flink construits dans la plateforme.

À retenir : un protocole ouvert n'empêche pas une dépendance à l'éditeur. Évaluez ce qu'il faudrait reconstruire en cas de changement de plateforme.

Le rachat par IBM ajoute une question de gouvernance. Les projets Apache restent pilotés par leur communauté, indépendamment de l'actionnaire de Confluent. Pour les offres commerciales, il est prudent de demander à l'éditeur ses engagements de compatibilité, de support et de tarification sur la durée du contrat.

Les deux éditeurs sont souvent associés plutôt qu'opposés : Confluent transporte les données en mouvement, Databricks les stocke et les analyse. Leurs offres se recoupent néanmoins sur le traitement de flux, où Databricks propose Spark Structured Streaming et Confluent propose Flink.

Lequel choisir ? Confluent se justifie lorsque le besoin dominant est de relier des systèmes par des événements et de réagir en temps réel. Databricks se justifie lorsque l'analyse, la data science et les agents IA sur des données stockées dominent. Beaucoup d'architectures combinent les deux : Kafka alimente le lakehouse. Comparez sur une preuve de concept la latence nécessaire, le coût au volume réel et les compétences de l'équipe. Le choix tient aussi au moteur de calcul : Apache Spark côté Databricks, Flink côté Confluent, deux moteurs dont les modèles de programmation et l'exploitation diffèrent. Pour un projet de RAG ou d'agents qui doit s'appuyer sur des données récentes, les deux approches peuvent alimenter une base de connaissances, à condition de définir la fraîcheur réellement nécessaire. Les formations de data engineering de Blent abordent ces architectures en pratique.