Stratégie

Infrastructures : Michelin s'est redonné de l'air avec l'infra-as-code

Une usine Michelin. L’industriel en possède 80 dans le monde entier, largement autonomes en matière de production IT. (Photo : Michelin)

Pour sortir d'un modèle d'infogérance manquant de souplesse, Michelin s'est tourné vers le cloud et l'automatisation, harmonisant les pratiques entre ses environnements Azure et son cloud privé. Un virage qui s'appuie sur des outils, mais aussi sur un profond changement de culture des équipes IT.

Publicité'Michelin(e), 120 ans, est passée à l'Infrastructure as-code' : le titre du 'talk' se veut volontairement provocateur. Lors du salon Devoxx, qui se tenait du 17 au 19 avril à Paris, Guillaume Hospital, architecte cloud chez Michelin, et son collègue Adrien Gooris, architecte sur la plateforme software engineering, ont raconté comment l'industriel de Clermont-Ferrand est passé, en matière d'infrastructures IT, d'une logique de demande de services à une logique d'automatisation pilotée par des scripts. « Jusqu'en 2015, un déploiement sur l'ensemble de nos 80 usines se traduisait par un ticket pour monter l'environnement de développement et autant de tickets que d'usines pour les environnements de production ! », résume Adrien Gooris. « Et il fallait encore vérifier que les services réellement obtenus auprès de l'infogérant correspondaient bien à ce qui était demandé », ajoute Guillaume Hospital. Bref, un « cauchemar », au sein duquel les managers IT prennent la pression de métiers mécontents de la lenteur avec lequel le service est délivré.

En 2015, l'industriel fait un premier état des lieux, qui acte à la fois les bénéfices de son modèle d'infogérance (avec une certaine standardisation des infrastructures et un modèle de support bien établi), mais aussi ses limites (l'absence de modèle as-a-service, la multiplication des échanges avec le prestataire, la stratégie d'infrastructures qui repose avant tout sur ce dernier). « Certes, tout était contractualisé. Mais les équipes IT devaient apprendre à vivre dans l'espace situé entre les lignes de ce contrat ! » glisse Guillaume Hospital. Michelin, qui fonctionne sur des infrastructures 100% on-premise, décide de se pencher d'abord sur la standardisation de ses demandes d'infrastructures à son partenaire (IBM et désormais Kyndryl), en se basant sur un outil appelé Decatrix, un référentiel pour le patrimoine applicatif qui, au fil du temps, a été intégré à l'outil de gestion de la CI/CD Jenkins. À cette même époque, l'équipe méthodes et outils de la DSI de Michelin (la DOTI, pour Digital transformation & information system, forte de près de 6000 personnes) fait une percée sur le cloud. « Les équipes IT ont alors touché du doigt l'autonomie apportée par le cloud et les capacités d'automatisation qu'il pouvait amener, indique Guillaume Hospital. Même si l'organisation n'était pas prête à passer à l'échelle sur ce type d'environnements. »

Les principes du cloud sur le on-premise

Michelin commence alors à consommer des services Azure via Decatrix. « C'était un premier pas vers l'automatisation, en se basant sur des templates Azure et des scripts de cybersécurité écrits en interne », indique Adrien Gooris. Mais les équipes s'aperçoivent assez rapidement qu'opérer une infrastructure suppose des compétences spécifiques... et un reporting dédié au management. « Le bilan était mitigé, reprend l'architecte. Sur la standardisation de l'infrastructure et le modèle de support, nous avions perdu par rapport à notre modèle historique. En termes d'organisation, le bilan était mitigé, puisque l'innovation était portée par une équipe spécifique. Mais, sur la répétabilité et l'accès à des environnements as-a-service, nous avions progressé. De même que sur notre vision en matière de stratégie d'infrastructures. »

Publicité
De gauche à droite : Adrien Gooris, architecte sur la plateforme software engineering, et Guillaume Hospital, architecte cloud.

Sur la base de ces constats, en 2018, Michelin opère un premier virage décisif, via une réorganisation de la DOTI via la création d'équipes en charge de plateformes, dont une dédiée au cloud et une autre à l'automatisation IT. « Par ailleurs, nous avons décidé d'appliquer les principes du cloud sur les environnements on-premise et de replacer la responsabilité de l'infrastructure chez Michelin, et non plus chez le prestataire », explique Adrien Gooris. Ce que les deux architectes décrivent comme le premier Shift Left de la DOTI se traduit par une transformation des équipes fournissant l'infrastructure vers les pratiques nées dans le cloud (infrastructure-as-code, API) et la réécriture du portail Decatrix pour s'adapter à ces nouvelles attentes. Sans oublier l'adaptation du partenaire afin d'amener l'infrastructure on-premise vers le mode as-a-service.

Shift left n°2 : impliquer toutes les équipes

En parallèle, l'équipe en charge de la plateforme cloud commence l'intégration de Kubernetes dans Decatrix. « Une tâche finalement assez simple, dit Guillaume Hospital, même si nous avons dû absorber la complexité des standards internes - notamment en termes de cybersécurité -, via des modules Terraform que les équipes peuvent venir consommer. » En 2022, le bilan de l'opération est largement positif, si on en croit les deux architectes. D'abord, via Decatrix positionné en cloud broker, l'expérience des utilisateurs a été unifiée entre le cloud public et le cloud privé. « Et nous étions à la cible en termes de standardisation, de support, de répétabilité, d'organisation ou de fonctionnement as-a-service », estime Adrien Gooris. Qui émet toutefois quelques bémols : d'abord parce que la vision technologique reste alors le monopole d'équipes centrales ; ensuite, parce que des disparités subsistent entre le mode de fonctionnement des différents environnements techniques. « Nous devions aller plus loin en termes de démarche cloud native et d'approche produit », résume Guillaume Hospital.

D'où ce que les deux architectes décrivent comme le second Shift left, consistant à transférer le savoir dans les équipes IT afin que celles-ci soient pleinement responsables du fonctionnement en production de leurs applicatifs. Un changement majeur. Pour rendre la marche un peu moins haute, l'équipe responsable de la plateforme cloud définit des Golden Path, une référence à la démarche des équipes d'ingénierie de Spotify. Les Golden Path recouvrent l'ensemble des standards permettant de bâtir un service numérique. « Ils sont adaptés aux différentes natures des applications, détaillent l'outillage associé et le support apporté par les équipes en central », dit Adrien Gooris. L'objectif, selon les deux architectes : éviter ce qu'ils appellent le « rumeur développement », autrement dit les astuces que s'échangent les ingénieurs sur les outils et pratiques. « D'où la mise en place d'outils comme Backstage (une solution Open Source pour créer des portails pour développeurs, née également chez Spotify, NDLR), de catalogues Golden Path ou encore de templates Github. Tout est fourni clef en main » », assure Adrien Gooris. En parallèle, un programme de formations (à des outils comme Ansible, Terraform, à la plateforme Azure, etc.) est aussi mis sur pied. « Tout comme il existe en interne une filière d'expertise pour les pneus, pour la R&D ou encore le management, nous avons créé une filière d'expertise IT », résume Guillaume Hospital.

En complément :
- Pauline Flament, CTO de Michelin : « Le IaaS et le PaaS ne nous ont pas désintermédiés »
- Le blog de la DSI de Michelin