Duck Conf 26 - 7 ans au pays de Kafka
Le voyage initiatique de Michelin dans l'event streaming
Avec les nouvelles technologies, on a souvent la promesse de monts et merveilles et … un chemin semé d’embûches pour les mettre en œuvre. Valérie et Fabien, architectes chez Michelin, nous racontent sept ans d’aventures sur l’implémentation progressive de Kafka au sein du géant industriel : de grandes réussites, des difficultés inédites à chaque étape de croissance et de très nombreux apprentissages.
2018. L'ambition d'une révolution.
Michelin, c’est un groupe de diverses sociétés : “des sociétés de pneumatiques, des sociétés autour du pneu et des sociétés au-delà du pneu” : des polymères mais aussi des étoiles gastronomiques, des guides de voyages. Le groupe Michelin, c'est 120 000 employés, 80 usines réparties dans le monde entier et 5700 collaborateurs IT.
“Remontons le temps : nous sommes en 2018, une ambition claire : devenir une data driven company”.
Valoriser la donnée comme un produit, accélérer les processus métiers, construire un système d'information réactif capable de soutenir une transformation de grande envergure.
Pour porter cette vision, l'équipe d'architecture d'entreprise fait un choix structurant : déployer Apache Kafka comme épine dorsale événementielle du système d'information. Sur le papier, l'idée est séduisante. En pratique, l'histoire va s'avérer plus mouvementée.
Le baptême du feu : l’effondrement initial du cluster
L'installation du cluster ne se passe pas sans heurts. Kafka est une plateforme distribuée exigeante : elle réclame de la mémoire, des disques SSD rapides, une infrastructure solide.
“Mais les équipes infrastructure de l'époque nous challengent. "T'as pas besoin de toute cette mémoire, je t'en donne un tiers." Les SSD ? Trop chers, on verra plus tard.”
Six mois s'écoulent. Et puis, c'est le drame. Les alertes virent au rouge. Les producers n'arrivent plus à écrire. Les Zookeepers perdent le contrôle du master. L'effet domino s'enclenche, et le cluster “tombe”.
Ce n'est pas encore catastrophique d'un point de vue business car peu de systèmes critiques sont en production à ce stade. Mais pour l'image du projet, c'est un coup dur. Une technologie réputée hautement résiliente qui s'effondre sur ses fondations, c’est difficile à vendre en interne.
La leçon est retenue : “on obtient enfin la RAM et les SSD demandés. On documente, on monitore, on capitalise. Et on commence à partager ces apprentissages sur un blog public, avec une franchise qui force le respect.”
2021. Le chantier de la migration.
Trois ans plus tard, la maturité a grandi, et avec elle, la complexité. Le cluster interne tourne, mais l'opérer au quotidien s'avère coûteux en énergie humaine. Sur le marché, une nouvelle offre émerge : les services Kafka managés. L'équipe décide de migrer.
Sauf que migrer un cluster Kafka, ce n'est pas simplement "déplacer des données". C'est coordonner 25 équipes, gérer 1 500 topics, garantir la continuité de la donnée transactionnelle sans la perdre en chemin (le fameux “Exactly Once”) et concevoir une solution de réplication efficace.
“Et il nous a fallu convaincre le business d'accepter une pause dans les projets fonctionnels pour permettre cette migration technique : Un double défi : technologique et organisationnel.”
C'est dans ce contexte que naît une initiative interne baptisée Ns4Kafka — un outil de gestion des namespaces Kafka, inspiré des pratiques de Kubernetes. Pensé pour organiser l'isolation et la configuration des topics à l'échelle de l'entreprise, il se révèle si utile qu'il est rapidement open-sourcé. Une fierté d'équipe, un geste vers la communauté.
2021 - 2025 L'ère de la maturité : quand le streaming révèle sa vraie complexité.
Une fois l'infrastructure stabilisée, vient le moment de tenir la promesse initiale : construire de vraies architectures événementielles. Et là, une révélation s'impose : modéliser des événements métiers, c'est un métier à part entière.
“L’objectif est d’avoir le bon pneu, au meilleur endroit au meilleur moment pour pouvoir livrer nos clients”.
Pour leur programme de supply chain, faire sortir les pneus des usines et les acheminer jusqu'aux clients dans les meilleures conditions, les équipes apprennent à penser en événements : une commande passée, un camion chargé, une livraison annoncée, un stock manquant. Chaque transition d'état devient un événement nommé, modélisé avec les équipes métier. Le vocabulaire lui-même fait l'objet d'un travail rigoureux d’alignement sémantique : que signifie exactement "Delivery" selon les différents systèmes du groupe ?
Mais si la modélisation fonctionnelle s'apprend, l'implémentation technique réserve ses propres pièges. Kafka Streams, la librairie de traitement événementiel en temps réel, paraît simple dans les slides de présentation. Dans les faits, gérer des jointures entre flux asynchrones, des événements qui arrivent dans le désordre, des fenêtres temporelles qui débordent... cela réclame une expertise profonde. Pour simplifier la vie des équipes, Michelin développe un framework interne maison, déposé lui aussi en open source.
L’état des lieux fin 2025
Aujourd'hui, l'écosystème Kafka de Michelin c'est : un cluster central managé, des clusters autonomes dans chacune des 80 usines du monde (pour garantir l’indépendance opérationnelle de chaque site), et 220 équipes utilisatrices.
Mais seulement 20% des équipes (celles qui utilisent Java) font du Kafka Streams : la démocratisation du streaming est donc encore à venir pour rendre le streaming accessible là où les gens travaillent déjà, qu’ils soient développeurs Python, data engineers SQL, ou praticiens .NET : Démocratiser, pas uniformiser.
Le futur, entre opportunités et chantiers ouverts.
Plusieur défis à fort impact sont identifiés pour l’avenir proche :
- la migration vers Kafka 4.0, avec la suppression de Zookeeper, la scalabilité horizontale via KRaft,
- la connexion avec des partenaires et clients externes via des protocoles de médiation qui leur permettra de recevoir directement des événements en temps réel (comme, par exemple, être notifié qu’un chargement vient de quitter l’usine, pour préparer l’arrivée du camion),
- la construction de la donnée analytique au plus proche des systèmes opérationnels, via le shift left data, qui facilitera la collaboration entre les équipes opérationnelles qui gèrent les systèmes transactionnels et temps réel et les équipes data qui traitent et analysent ces données.
L'équipe explore aussi les usages d'IA sur les flux Kafka : le RAG sur des données streamées, l'intégration de serveurs MCP pour accéder à Kafka depuis des agents et pourquoi pas, imaginer des agents puissent un jour communiquer entre eux à travers Kafka, en utilisant le bus événementiel non plus comme un système de données, mais comme un protocole de coordination entre intelligences distribuées.
Ce qu'on retient de 7 ans au pays de Kafka
Valérie et Fabien tirent quatre enseignements de cette passionnante épopée.
“Kafka c’est une technologie super, ça amène plein de choses mais c’est beaucoup plus facile à utiliser qu’à opérer, c’est pour ça que nous sommes sur des services managés”.
“Pour modéliser une architecture événementielle, partez des événements métier, définissez les objets métiers, le vocabulaire en co-construction avec vos métiers (L’event storming marche très bien)”.
“Le streaming apporte une vraie valeur produit, mais son adoption est difficile et ne s'improvise pas — des frameworks et de l'expertise sont indispensables.
“Le marché bouge vite, les promesses sont nombreuses, et il faut savoir rester informé sans se laisser emporter.”
Sept ans au pays de Kafka : des galères d'infrastructure, des migrations tendues, des architectures complexes, des frameworks open-sourcés, et une expertise qui fait aujourd'hui la fierté de Michelin. Une histoire vraie, racontée sans filtre par ceux qui l'ont vécue.
Pour aller plus loin …
**Ressources publiées par Michelin
**Blog Michelin : https://blogit.michelin.io
Repository Github Michelin : github.com/michelin
Sur Apache Kafka — les fondamentaux
"Apache Kafka 101 : comprendre le fonctionnement du message broker en temps réel"
Une série d'articles qui introduisent les concepts fondamentaux de Kafka : topics, partitions, producers, consumers, mécanismes de réplication. Le point de départ idéal pour comprendre ce que Michelin a opéré pendant 7 ans. OCTO Talks !
"Kafka répond-il à mon besoin ?"
Un article pratique qui présente les cas d'usage et les contraintes de Kafka, avec notamment une analyse de Kafka Connect. Utile pour contextualiser les choix d'architecture de Michelin. OCTO Talks !
Sur Kafka Streams
"Kafka Streams : un framework léger et puissant pour le stream processing"
Un article qui explique en détail comment Kafka Streams exploite le partitionnement pour scaler quasi linéairement. Il aborde notamment la complexité des jointures entre flux — exactement le problème que Michelin a rencontré sur sa supply chain. OCTO Talks !
Sur les architectures événementielles
"Event-driven : est-ce que je suis prêt ?"
Un compte-rendu de talk Duck Conf qui pose les vraies questions avant de se lancer dans l'event-driven : promesses, implications concrètes, top 5 des pièges à éviter. Résonne directement avec le retour d'expérience de Michelin. OCTO Talks !
"Retour sur la conférence EventSourcing Live @ DDD Europe 2023"
Un compte-rendu riche sur l'event sourcing, le CQRS et les architectures event-driven. Aborde notamment l'Event Storming comme méthode de modélisation — la même démarche que Michelin utilise pour partir des événements métiers. OCTO Talks !
"Duck Conf 2025 : Modern Software Engineering & Architecture - Les Tech Trends 2025"
Le talk d'Antoine Chantalou sur les tendances 2025, qui inclut l'Event Driven Architecture parmi les patterns clés — avec une mise en garde sur le dogmatisme et un appel au pragmatisme, en écho aux leçons tirées par Michelin. OCTO Talks !