Stratégie

Architecture événementielle : comment Michelin a tenu le cap

De gauche à droite, Fabien Alberi, architecte intégration chez Michelin, et Valérie Servaire, architecte intégration au sein du programme de transformation de la supply chain de l’industriel, lors du salon Devoxx 2026 à Paris. (Photo : R.F.)

Plus de 7 ans après de premiers tests, Michelin a fait de l'architecture orientée événements Apache Kafka un rouage essentiel de son fonctionnement dans le manufacturing et la supply chain.

Publicité7 ans au pays de Kafka. Dans une conférence le 22 avril, dans le cadre du salon Dexoxx qui se tenait au Palais des congrès de Paris, les équipes IT de Michelin sont revenues sur leur adoption progressive de l'architecture orientée événements Kafka pour des besoins internes. Tout démarre en 2018-2019 lorsque l'industriel se fixe pour ambition de conduire son activité avec la donnée, notamment afin de rendre ses opérations plus réactives, en parallèle d'une modernisation des systèmes d'information vers les architectures cloud native. C'est ce virage qui amène Michelin à se tourner vers la solution de streaming de données Kafka, du nom de la messagerie open source de type Pub/Sub publiée sous licence Apache. « Nous avons alors déployé la solution on premise, dans des VM - plutôt que dans des conteneurs -, sur une configuration inférieure aux recommandations de l'époque. Et nous sommes partis en production », raconte l'ingénieur Valérie Servaire, architecte intégration au sein du programme de transformation de la supply chain du groupe aux 120 000 employés. Un galop d'essai, avec un premier cas d'usage autour du MDM (master data management) sur les référentiels de produits/services et de tiers, qui a vu les premiers producteurs de données essuyer quelque peu les plâtres.

En 2020-2021, tenant compte de cette première expérience, Michelin amorce un virage vers les services managés, en optant pour le cloud de Confluent, le principal contributeur au projet open source, pour héberger les clusters centraux. « A l'époque, 25 équipes travaillaient déjà sur le cluster central, souligne Valérie Servaire. Nous avons donc bâti une stratégie de migration sans perte de données. » C'est d'ailleurs à cette époque que les équipes techniques de l'industriel développent un outil facilitant la migration entre clusters Kafka, Ns4Kafka, aujourd'hui disponible en open source.

Remplacer un orchestrateur centralisé

L'architecture reposant sur les événements (event-driven architecture) cible alors deux activités clefs de l'industriel de Clermont-Ferrand : le manufacturing, via notamment la récupération de données sur les automates industriels, et la gestion de la supply chain pour 80 usines dans le monde. Sur ce terrain, cette architecture vient supplanter un orchestrateur centralisé (Oracle Weblogic) supportant 275 000 étapes de processus chaque jour.

Cette exploitation de Kafka au sein des rouages clefs de l'entreprise passe par une modélisation des processus avec les métiers. « Avec ces derniers, il s'agit de décrire tous les événements, les cas passants et les cas non passants. On travaille ensuite sur le modèle de données associé avec les équipes techniques, pour décrire la topologie des streams Kafka », résume Valérie Servaire. En pratique, la transition peut s'avérer complexe, comme le souligne Fabien Alberi, architecte intégration chez Michelin. Par exemple, il faut être en mesure de regrouper plusieurs événements ayant une signification métier, comme plusieurs lignes de commandes faisant l'objet d'une livraison unique. « Et sur des cas non passants, il faut avoir recours à une API de plus bas niveau de Kafka », précise l'ingénieur. Pour gérer les cas complexes, Michelin décide d'ailleurs alors de développer en interne un framework dédié, Kstreamplify, une librairie pour Kafka Streams facilitant notamment la gestion d'erreurs. « Cet outil est aujourd'hui utilisé par une grande partie des équipes », indique Fabien Alberi.

PublicitéSe rapprocher du monde analytique

Ces fondations aujourd'hui en place - avec un cluster Kafka central de 5 To sur le cloud de Confluent et une soixantaine de clusters locaux dans les usines, un environnement supportant 1 million de données ou événements chaque jour - Valérie Servaire entend désormais étendre les usages de la technologie, par exemple pour communiquer avec les clients de l'industriel, en se connectant aux solutions SaaS utilisées en interne ou en se rapprochant des applications analytiques. « Nous perdons beaucoup de temps à exposer les données. Les mondes opérationnel et analytique ne parlent pas le même langage et n'utilisent pas la même boîte à outils », souligne l'ingénieur, qui explique vouloir proposer des tableaux de bord au sein même des outils opérationnels. Ce défi de la démocratisation de Kafka en interne passe aussi par la capacité à sortir du monde Java, pour s'ouvrir à Python et .Net, voire à s'intégrer aux outils de GenAI, via l'exposition de services sur un serveur MCP mais aussi via un projet d'intégration de Kafka dans une solution agentique avec le protocole Agent2Agent. « Aujourd'hui, nous avons embarqué environ 20% des équipes opérationnelles », souligne Valérie Servaire. Façon de dire que la route est encore longue.