Hubadviser est une société de veille technologique consacrée à l’IT. Nous organisons régulièrement des entretiens avec des leaders de l’IT en France. Cette fois, nous avons eu l’honneur de recevoir Guillaume Yvon, directeur IT chez Engie, qui pilote une équipe de 90 personnes. Il nous a parlé du « Move to Cloud » réalisé par Engie pour répondre à deux objectifs majeurs : augmenter l’efficacité opérationnelle du groupe d’énergie et supporter le lancement de nouvelles offres. Vous retrouverez dans cet article les questions auxquelles les dirigeants d’IT sont confrontés lorsqu’ils entreprennent un « Move to Cloud ».
Bonjour Guillaume, peux-tu te présenter s’il te plaît ?
Je suis Guillaume Yvon, en charge de l’infrastructure IT chez Engie Retail France. Je pilote actuellement une équipe de 90 personnes réparties sur différents sujets : support, cloud, tests, plateforme digitale. Avant cela, j’ai évolué au sein de grandes structures comme Saint-Gobain ou Storengy, chez qui j’ai travaillé sur la stratégie cloud.
Peux-tu nous expliquer pourquoi Engie a adopté une stratégie "Cloud First"?
Selon moi, le choix du cloud est presque inévitable pour plusieurs raisons :
1. Le besoin de flexibilité : le marché de l’énergie est très imprévisible en ce moment avec la guerre en Ukraine, les prix du marché sont très variables, en plus de cela, on a de fortes contraintes réglementaires auxquelles nous devons nous aligner en peu de temps.
2. Le besoin business : Engie se doit de proposer des offres personnalisées et différenciantes au rythme de l’actualité… Nous devons permettre à nos clients de surmonter une vague de froid, une canicule de longue durée en leur proposant des offres qui varient vite et s’adaptent à leur contexte personnel.
3. La raison financière : Engie doit innover et doit aussi adopter de nouvelles technologies pour gagner en performance. Nous avons notamment besoin de recourir à l’IA. Or, il n’est aujourd’hui pas possible de s’offrir des capacités d’IA et de traitement de données sans faire appel aux cloud providers. J’ai eu l’opportunité de participer au AWS Summit 2023 et de rencontrer le patron de Nvidia, le plus grand fournisseur de puces permettant d’exploiter l’IA. Ce qui est clair, c’est qu’aujourd’hui, ces puces ne sont achetées exclusivement que par des cloud providers. Si bien que pour pouvoir exploiter la puissance de ces puces, il faut passer par un cloud provider car l’achat en direct est quasiment impossible.
Ce que je comprends, c’est que l’adoption du cloud est un choix business et pas technologique ?
C’est vrai et faux. C’est vrai dans l’absolu car on répond toujours à un impératif business, mais pour Storengy, filiale d’Engie, leader des solutions de stockage de gaz naturel, la décision du move to cloud répondait à un impératif technique.
Chez Storengy, nous avons rencontré les problèmes suivants :
• Obsolescence de nombreuses applications.
• Paysage IT très complexe avec des applications parfois en doublon, c’est-à-dire ayant la même fonction.
• Des développements internes non maintenus.
• Des hébergements hétérogènes.
• Des coûts de maintenance qui explosent.
• Des incidents majeurs de manière régulière.
Le move to cloud nous a permis de moderniser considérablement notre SI, de faire de la rationalisation, de nous concentrer sur des activités à valeur ajoutée et d’augmenter notre niveau de performance.
Peux-tu nous dire comment vous avez procédé pour réussir le move to cloud chez Engie ?
Il y a plusieurs choses qu’on a mises en place, mais pour commencer, on a décidé de faire une cartographie des applications du SI avec le TCO ( Total Cost of Ownership ) sur 1 an et 3 ans. Ensuite, on a appliqué la méthodologie des 7R développée par AWS.
1. Rehosting (Réhébergement) : Transférer une application vers le cloud sans modifications. Souvent appelé « lift and shift ».
2. Replatforming (Replateformage) : Faire évoluer l’application pour l’adapter au cloud, avec des changements mineurs pour bénéficier des avantages du cloud sans redéveloppement complet.
3. Repurchasing (Rachat) : Remplacer l’application existante par une version cloud-native, souvent une SaaS.
4. Refactoring / Rearchitecting (Refactorisation / Réarchitecture) : Modifier profondément l’application pour être nativement cloud, optimisant les performances et l’évolutivité.
5. Retire (Retraite) : Éliminer les parties de l’application qui ne sont plus nécessaires.
6. Retain (Conservation) : Garder certaines parties de l’application en dehors du cloud, sans changement.
7. Relocate (Relocalisation) : Déplacer des conteneurs vers AWS sans modifications majeures, spécifique à certaines technologies AWS. Cet audit nous a permis d’identifier la stratégie à mettre en place pour chaque application du SI.
Nous avons réduit les coûts opérationnels IT de 40%.
Avec le recul, peux-tu nous dire quel est le constat sur les différentes stratégies move to cloud que vous avez adopté, les fameux 7R ?
Je vais commencer par te décrire là où la migration vers le cloud ne présente pas d’intérêt et représente un coût. Le réhébergement, ou lift & shift, pur et dur qui consiste à faire passer une application d’un serveur on-premise au cloud n’a pas d’intérêt. Cela va même coûter de l’argent.
Par contre, la migration vers le cloud est une opportunité de revoir sa stratégie applicative et de prendre des décisions. Par exemple, on a obtenu d’excellents résultats financiers sur les points suivants :
• Changement de runtime : Migrer l’application sur un framework open-source répandu pour rationaliser les compétences.
• Changement d’architecture de migration : Passer en mode conteneurs avec un service managé. Modifier le moteur de base de données.
• Serverless : Transformer l’application pour utiliser une combinaison de services managés
On dit souvent que le cloud fait exploser les coûts de la DSI, es-tu d’accord avec cette idée ?
Concernant ce point, je peux simplement partager mon expérience, ça n’a pas été notre cas. Pour notre part, on a réussi à réduire les coûts opérationnels IT de 40%. Surtout, il y a un point à souligner d’extrêmement important : nous avons réduit drastiquement le nombre d’incidents, avec tous les coûts que cela comprend. Après, effectivement, un move to cloud, ce n’est pas magique, il faut bien le préparer pour le réussir.
La formation c’est le nerf de la guerre.
Comment Engie a préparé son move to cloud ?
Il y a plusieurs points :
1. La gouvernance : Engie a fait le choix d’avoir une instance très centralisée qui a réalisé les principaux choix (fournisseurs, architecture, méthodologie à suivre). Par la suite, cette instance a adopté un modèle fédéré en nommant des responsables cloud dans chaque entité pour diffuser le modèle et laisser une marge de manœuvre aux différentes filiales.
2. La formation : Il faut miser sur la formation des équipes à grande échelle. À la fois sur de la méthodologie comme le FinOps mais aussi sur des outils. C’est le nerf de la guerre.
3. La relation avec les fournisseurs : Il faut investir du temps et des ressources pour obtenir les meilleures conditions. La gestion des contrats est un sujet clé, il ne faut pas hésiter à investir des ressources sur cet enjeu pour réaliser les bons choix.