Interviews

Pauline Flament, CTO de Michelin : « Le IaaS et le PaaS ne nous ont pas désintermédiés »

---

La priorité donnée au cloud et l'arrivée des technologies IT dans les usines transforment en profondeur la DSI de Michelin. Poussant les équipes infrastructures à se réinventer, comme le raconte la Chief Technology Officer du groupe, Pauline Flament.

PublicitéPauline Flament, la Chief Technology Officer de Michelin, revient sur les deux grands virages technologiques récents de la DSI de l'industriel réalisant près de 29 Md€ de chiffre d'affaires : le cloud et le smart manufacturing, qui amène l'IT à l'intérieur des quelques 80 usines du groupe. Des mutations qu'il a fallu accompagner tant en termes de compétences que d'évolution des pratiques et de l'outillage. Conduisant à ce que la CTO décrit comme « une transformation profonde des métiers de l'infrastructure » et à « leur réinvention autour d'un certain nombre de nouveaux principes ».

Une réinvention qui vise également à se projeter sur un nouveau champ : les usines du groupe. Hier souvent totalement autonomes sur un plan informatique, elles sont de plus en plus connectées à des systèmes mutualisés. Une fusion IT/OT que Michelin encadre via des programmes de convergence, le premier d'entre eux, centrés sur les couches d'infrastructures, venant tout juste de s'achever. Objectif désormais : déployer un modèle homogène de serveurs dans les usines, associé à des capacités cloud.

CIO : Michelin a lancé une stratégie cloud-first. Où en êtes-vous aujourd'hui sur ce terrain de la migration vers les environnements cloud ?

Pauline Flament : Comme beaucoup d'entreprises, nous avons déployé une stratégie cloud-first qu'il faut voir avant tout comme un motto à destination des équipes internes, afin de les inciter à changer leurs façons de travailler. Aller dans le cloud suppose de transformer le design des applicatifs, mais aussi les façons de travailler des développeurs, notamment au sein de la chaîne CI/CD. Il fallait donc afficher une stratégie cloud-first pour amorcer ce mouvement. C'est ce que nous avons fait il y a 5 ou 6 ans. Nous étions alors plutôt en avance sur le marché. Aujourd'hui, nous nous inscrivons plutôt dans la moyenne, avec 30 à 40% de notre parc applicatif dans le cloud.

Aujourd'hui le motto est devenu : 'cloud first but not only', car nous avons été rattrapés par la réalité. En travaillant principalement avec des hyperscalers, nous avons fait face à des questions juridiques, comme celles liées au RGPD, mais aussi géopolitiques. Nous ne pouvons pas héberger toutes nos données et tous nos processus chez ces acteurs. Dans certains pays, un tel choix soulèverait trop de contraintes ou ne serait pas pérenne. La politique cloud-first nous a ainsi poussé à nous reposer la question des données, processus et algorithmes les plus confidentiels et du niveau de confiance qu'on peut accorder à un partenaire.

Et il ne faut pas négliger les contraintes propres à certaines applications. Quand on veut aller vers le temps réel ou vers le traitement de grands volumes de données, le cloud n'est plus adapté. Il ne faut pas perdre de vue que Michelin possède une empreinte industrielle importante, avec certaines implantations assez isolées ne bénéficiant que d'une bande passante limitée. Nous sommes donc obligés de conserver une empreinte IT en usine, ne serait-ce que pour la continuité d'activité. Enfin, nous voulons limiter les risques de dépendance à tel ou tel fournisseur. Aujourd'hui, passer d'un cloud à l'autre demeure difficile, car la chaîne d'outillage reste spécifique à un fournisseur donné.

PublicitéQuelle est la situation actuelle ?

Nous sommes sur un paysage multicloud, avec un cloud primaire et un cloud secondaire, pour lesquels nous avons signé des contrats cadres. Nous y greffons des relations avec des acteurs locaux. Sur ce terrain, nous avons signé un contrat avec un acteur français. Et nous nous interrogeons sur l'opportunité d'en faire de même pour la Chine. Par ailleurs, depuis environ 18 mois, les éditeurs d'applications SaaS autorisent les entreprises à choisir leur propre hébergement cloud, ce qui nous permet d'exploiter nos contrats cadres et de réaliser les volumes qui y sont inscrits.

Sur la stratégie applicative, comment sont réalisés les arbitrages entre modernisation sur le cloud et maintien on-premise ?

D'abord, dans le cadre du lancement de notre stratégie cloud, nous nous sommes montrés opportunistes. Ce sont plutôt de nouvelles applications qui ont été portées sur le cloud. Car, sur la transformation d'applications existantes, l'équation économique n'est pas toujours au rendez-vous. Aujourd'hui, sur tout ce qui est back-office, standard et stable, nous nous appuyons sur les stratégies des éditeurs. Or, la plupart des applications de back-office, qui étaient historiquement on-premise, sont en train d'évoluer vers le SaaS. Nous accompagnons donc ce mouvement... quand cela a du sens pour nous ! Le cloud est également bien adapté à toutes les interfaces proches des clients ou aux applicatifs devant évoluer rapidement, car ces environnements apportent flexibilité et accès rapide à l'innovation, notamment sur la data.


« Nous savions que les équipes avec qui nous travaillons allaient nous comparer avec les hyperscalers ou avec les éditeurs en mode SaaS. » (Photo : Marielsa Niels)

La transformation vers le cloud a un impact sur les développeurs, mais aussi sur la production, car une partie de la responsabilité est transférée vers les hyperscalers. Quelles sont les conséquences de ce mouvement au sein votre organisation ?

C'est effectivement une transformation profonde des métiers de l'infrastructure qui nous a conduit à nous réinventer. Nous nous sommes appuyés sur une transformation Lean pour redéfinir nos missions, responsabilités et clients. Car nous savions que les équipes avec qui nous travaillons allaient nous comparer avec les hyperscalers ou avec les éditeurs en mode SaaS. Nous devions donc proposer une simplicité d'interfaçage et de provisioning comparable à celle de ces acteurs. Ce qui nous a demandé de travailler sur notre culture interne, mais aussi sur notre outillage.

La seconde transformation que nous avons menée tient à l'accompagnement des équipes dans leur consommation cloud. Car ces dernières ne connaissaient pas ces environnements, qui sont souvent arrivés dans notre paysage par le IaaS. Nous avons créé des équipes pour les aider à sourcer les bons composants et éventuellement à les repackager. Les équipes de développement ne se rendent donc pas directement sur le portail de l'hyperscaler. Nous les conseillons sur les bons outils, sur les bonnes pratiques en matière de monitoring, de passage en production ou de sécurité. Pour ce faire, nous avons construit deux offres de services en fonction de la maturité de l'équipe applicative. Soit elle est déjà très orientée produit et elle est à même de travailler directement sur le PaaS d'un hyperscaler, et nous instaurons alors un dialogue d'experts à experts. Soit ce n'est pas le cas, et nous apportons cette couche de services et de provisioning. Finalement, le IaaS et le PaaS ne nous ont pas désintermédiés. Notre mission est de garantir la performance des services informatiques, quel que soit le mode d'hébergement, ainsi que les coûts associés et la sécurité adéquate.

Enfin, il faut garder à l'esprit que chez Michelin, les opérations IT étaient déjà largement outsourcées. A part dans les usines, nous n'avions plus de datacenters opérés en propre. Le cloud nous a plutôt conduit à réinternaliser des compétences pour accélérer la transformation et maîtriser nos coûts. D'abord sur des missions d'architecture ou de chefferie de projet, puis sur des opérations et de l'automatisation. Les effectifs de l'infrastructure augmentent donc légèrement, mais nous apportons davantage de valeur ajoutée à l'entreprise et contribuons à réaliser de nouvelles missions, notamment dans la sécurité. Sans oublier que, sur la data ou sur le calcul, les volumes d'activité connaissent des rythmes de progression allant jusqu'à 30% par an, des croissances qui absorbent les gains d'efficience qu'apporte l'évolution des technologies.

Comment gérez-vous le contrôle des coûts du cloud, donc le Finops ?

La transformation que je viens de décrire nous conduit à exposer notre catalogue de services, mais également les coûts associés. Chaque équipe d'infrastructure produit des rapports, affichant les inventaires et les coûts des services. Ce qui permet de mener un travail d'éducation auprès de nos clients internes. Par exemple, le département chargé du computing organise une réunion avec chaque équipe applicative pour partager les niveaux de consommation à la fois on-premise et dans le cloud, les tendances observées et les leviers d'optimisation. Force est de constater que ce travail d'éducation doit encore s'approfondir avec les équipes de développement. La maturité grandit quand ces dernières s'organisent en mode produit et affichent la volonté d'instaurer un dialogue sur la valeur avec leurs propres clients, un dialogue portant sur les services, les usages et les coûts. C'est le chemin que nous voulons suivre, mais la maturité n'est pas encore identique partout.

Par ailleurs, ces efforts sont accompagnés par la gouvernance mise en place au plus haut niveau de l'entreprise. Tous les deux mois, une réunion est organisée avec le co-gérant du groupe et les responsables de domaines fonctionnels et nous échangeons non seulement sur la dépense en construction de nouvelles applications, mais aussi sur les coûts que ces projets génèrent en infrastructures et en run. Ma responsabilité consiste à leur amener des informations leur permettant de prendre conscience des défis auxquels nous faisons face, de l'augmentation des volumes ainsi que des leviers d'optimisation que nous actionnons pour compenser cette croissance. Ce qui me rend optimiste, c'est que la prise de conscience progresse, par exemple du côté des équipes positionnées sur la data qui voient leurs volumes croître très rapidement. Et le Green IT joue un rôle très positif. Car le niveau des émissions carbone est très directement corrélé aux dépenses.

Comment est abordée la question de la maîtrise de la dette technique ?

D'abord, le mode produit constitue une avancée importante en la matière, car la question de l'usage et de la valeur y est portée tant par les équipes applicatives que par celles des infrastructures. Ensuite, dans les comités de gouvernance, on parle certes de budgets de projets et de run, mais aussi de patrimoine. Avec des indicateurs comme le nombre d'applications de chaque domaine métier, leur âge moyen et leur taux d'obsolescence. Ces données proviennent de notre CMDB, qui renferme une description fine des composants. Notre levier, c'est d'afficher ces taux d'obsolescence, calculés par nos architectes, pour instaurer un dialogue sur ce sujet. Ce taux, qui peut monter à 40 ou 50%, en fonction de la définition choisie (tout composant non supporté par exemple), n'est pas un critère en tant que tel. Il faut avant tout déterminer si cette obsolescence est grave ou pas pour être en mesure de prioriser les chantiers et de proposer une roadmap raisonnable. Par exemple, un applicatif exposé sur Internet dans une DMZ ne peut pas présenter une obsolescence grave, pour des raisons de sécurité.


« Ma responsabilité dans la fusion IT/OT, c'est de masquer les complexités qu'apportent des technologies sans cesse plus présentes dans la production. » (Photo : Marielsa Niels)

Chez la plupart des industriels, les informaticiens sont aujourd'hui entrés dans les usines et ateliers. Quelle est la stratégie de Michelin en la matière et le rôle des équipes d'infrastructures ?

Tout est né, avant tout, d'une volonté des différents départements de travailler ensemble, à tous les niveaux. Nous recevions ainsi des sollicitations des automaticiens qui voulaient connecter leurs machines. Mais le vrai levier, qui s'est concrétisé il y a une dizaine d'années, est de nouveau passé par la cybersécurité. Avec les attaques de type Stuxnet, nous avons collectivement pris conscience que les systèmes de production, raccordés à l'informatique, étaient vulnérables. Ce constat a poussé les informaticiens et les automaticiens à faire chacun un pas vers l'autre. Pour les premiers, il s'agissait tout d'abord de comprendre les méthodes de travail en usines. Celles-ci tournent en 24/7 et un problème informatique suffit à mettre toute une chaîne à l'arrêt. Il nous fallait donc faire preuve d'humilité, comprendre ces contraintes, pour identifier la valeur ajoutée que nous pouvions amener, mais aussi les domaines sur lesquels l'autonomie aux usines devait prévaloir, pour des questions de réactivité.

Sur ces fondations, nous avons défini un premier programme de convergence de l'IT des usines, courant de 2019 à 2022. Ce programme se concentrait sur les couches basses d'infrastructures, tandis que l'usine et la direction industrielle mettaient l'accent sur leurs enjeux clefs, comme le capital humain ou la productivité. Ce premier cycle a placé les couches basses d'infrastructures sous la responsabilité de l'IT, parce qu'il s'agit d'un métier d'expertise. Sur ce terrain, les usines se positionnent donc désormais dans une logique d'expression de besoins et de consommation de services. Nous avons ainsi fait converger les réseaux et les catalogues de services offerts aux utilisateurs. Ce n'est pas encore le cas sur la partie serveurs.

La seconde percée amenée par ce programme portait sur la rationalisation des parcs applicatifs, avec une rationalisation des portefeuilles séparant le temps réel, relevant de l'automate, de tout le reste - la data, le reporting, la performance et la qualité -, relevant plutôt d'une informatique dite centrale. En parallèle, les métiers se sont lancés sur des expérimentations sur la data et l'IA, pour structurer leurs besoins en termes de données, de cas d'usage pertinents et de compétences.

Ce cycle vient de s'achever. Quelles sont les ambitions désormais ?

Nous sommes en train d'écrire un second cycle, qui vise à repartir de ces acquis pour aller plus loin. Maintenant que les deux ingénieries centrales ont appris à travailler ensemble, nous allons nous concentrer sur les problématiques des usines et sur les façons de les aplanir. Ce qui passe notamment par une rationalisation des datalakes et de l'IA déjà présents sur les sites industriels. L'objectif désormais sur ces technologies, c'est de passer à l'échelle. Aujourd'hui, chaque usine possède son datalake et travaille sur ses données. Notre ambition, c'est de partager des données et des cas d'applications entre usines, partout où cela fait sens. La valeur viendra de la transversalité et de l'homogénéisation, ce qui montre aussi combien la rationalisation préalable de l'infrastructure était un levier important.

Une consolidation qui se fera plutôt dans le cloud ?

Oui, mais avec des limites portant sur la performance attendue des applications et la confidentialité de certaines données. La réflexion sur l'architecture technique doit s'accompagner d'une analyse fonctionnelle. Sur le plan de l'architecture IT, il faut identifier les solutions permettant, de façon transparente, d'être soit en local - quand cela s'impose -, soit dans le cloud, quand c'est pertinent. Le tout sans que l'aiguillage des données ne devienne trop complexe.

Nous cherchons ainsi à déployer un modèle homogène de computing en usines, en y introduisant des capacités cloud. Si les usines ont longtemps cherché à s'abstraire du cloud pour demeurer autonomes dans leur fonctionnement, elles consomment aujourd'hui de facto des environnements de ce type, sans forcément bien le mesurer. Par exemple, une partie du suivi d'activité est désormais dans le cloud. Et cette tendance ne va aller qu'en s'accentuant avec la data et l'IA. Notre objectif est d'entériner cet état de fait pour garantir le bon niveau de performances et de sécurité, avec le niveau de support adéquat. Car il faut garder à l'esprit que les usines ne possèdent pas toutes les compétences requises pour accompagner ce virage. Ma responsabilité sur ce plan, c'est de masquer les complexités qu'apportent des technologies sans cesse plus présentes dans la production.


« Nous sommes passés d'un monitoring technique, focalisé sur la disponibilité des ressources unitaires, à de l'observabilité, une démarche qui part des processus et applications critiques pour l'activité. » (Photo : Marielsa Niels)

Comment Michelin est-il organisé pour exploiter la donnée ?

Nous regroupons la data et l'IA dans une même organisation. S'y ajoute un maillage au sein des métiers, avec des data offices pour les métiers du tertiaire, du commerce, de la R&D, du manufacturing, sans oublier l'IT elle-même. Et chaque métier ou groupe de métiers possède sa gouvernance pour légiférer sur ses données, couplée aux outils nécessaires. Ce dispositif est aujourd'hui en bonne voie de déploiement.

Tant avec le cloud qu'avec la fusion IT/OT, on assiste à une extension du périmètre de l'IT. Quelles sont les conséquences sur le monitoring ?

Pour accompagner ces transformations, nous sommes passés d'un monitoring technique, focalisé sur la disponibilité des ressources unitaires, à de l'observabilité, une démarche qui part des processus et applications critiques pour l'activité et vise à suivre leur niveau de performances. Il ne s'agit donc plus seulement de vérifier que telle application ou tel processus répond bien aux requêtes, mais qu'il le fait dans les conditions attendues par le métier concerné. Bien sûr, cette forme de monitoring nécessite toujours de se connecter aux éléments techniques permettant de délivrer la performance attendue afin de construire des tableaux de bord d'observabilité. Mais ces derniers ne sont pas dédiés à des responsables de domaines techniques, mais sont plutôt partagés entre des équipes techniques, de support, voire métiers. Cela fait maintenant près de deux ans que nous nous inscrivons dans cette démarche, même si ce n'est pas encore généralisé partout. Nous essayons d'avoir un démonstrateur par domaine métiers afin que ce changement de posture se déploie, ensuite, par capillarité.

Article rédigé par

Reynald Fléchaux, Rédacteur en chef CIO
Suivez l'auteur sur Twitter

Partager cet article