Projets

EDF migre du cloud de GE Steam Power vers son cloud en 27 mois

EDF migre du cloud de GE Steam Power vers son cloud en 27 mois
EDF a progressivement intégré, puis migré les 17 applications du cloud AWS de sa nouvelle filiale Arabelle Solutions, rachetée à GE, sur son propre cloud AWS. (Photo : EDF)

Après l'opération de rachat de GE Steam Power - devenue sa filiale Arabelle Solutions -, EDF a choisi de migrer les applications du cloud du fabricant américain de turbines nucléaires vers le sien. Même si les deux structures étaient hébergées sur AWS, la démarche a requis plus de deux ans de travail pour réconcilier systèmes et gouvernances, et enfin basculer vers un cloud unique.

PublicitéFin mai 2024, EDF a finalisé l'acquisition du géant des turbines nucléaires GE Steam Power, provenant du rachat de la branche énergie d'Alstom en 2015, sous le nom d'Arabelle Solutions (3300 employés dans 16 pays, contrats concernant plus d'une centaine de centrales dans le monde.). Une opération d'envergure synonyme de réorganisation et, en l'occurrence, côté DSI, de rationalisation des différents sites IT et datacenters des deux structures dans le monde et de rapprochement de leurs cloud respectifs. Même si GE Steam Power et EDF avaient tous deux opté pour AWS, cette dernière démarche n'a pas consisté en un simple lift-and-shift des applications d'un cloud vers l'autre. Ahn Le Viet, expert cloud public chez EDF, a raconté les détails du projet à l'occasion de l'AWS Summit de Paris, le 9 avril.

Pour commencer, EDF a rapidement choisi de procéder à une migration applicative en l'état, et de ne réaliser les modifications ou évolutions nécessaires qu'a posteriori. Mais l'opération n'a pas été simple pour autant et a représenté plusieurs défis. « Elle a en effet concerné des d'applications variées qui allaient de l'application classique 3 tiers jusqu'aux développements maison avec de nombreux composants et interdépendances, a précisé Ahn Le Viet. Mais c'est la vision très différente qu'avaient GE Steam Power et EDF de la landing zone, le cadre qui permet de déployer, d'opérer et de sécuriser une application dans le cloud [sécurité, autorisations, conformité, optimisation des coûts, etc.], qui a représenté un de nos défis majeurs ». EDF a donc défini la liste des tâches nécessaires à l'adaptation applicative d'un cloud vers l'autre, à partir des différences entre ces deux visions. L'entreprise a aussi dû prévoir une période transitoire durant laquelle les utilisateurs GE ont disposé d'accès provisoires au cloud d'EDF, pour la durée du projet. Enfin, les engagements contractuels entre les deux organisations ont imposé des échéances spécifiques fixes et non négociables, très structurantes pour la migration.

Une migration en deux phases

Ahn Le Viet a choisi de travailler en deux phases de migration correspondant à deux lots d'applications. L'équipe a travaillé très en amont, consciente que la date de migration finale ne serait connue que tardivement, et elle ne l'a effectivement été que 3 semaines avant sa mise en application. « Pour respecter ce délai contraignant, j'ai organisé la première phase en 3 étapes », a poursuivi l'expert cloud public d'EDF. Pour la première étape, les équipes de GE Steam Power ont créé de nouveaux comptes dans le cloud EDF, dans lesquels ils ont dupliqué les applications et les ont rendues autonomes et indépendantes de leur SI. Durant la 2e étape, ces comptes ont été transférés à EDF - c'est AWS qui a dû procéder à cette opération, pour laquelle aucun service managé n'est disponible -, et pendant la 3e étape, les comptes ont été raccordés à la landing zone EDF et ainsi véritablement intégrés à son cloud. Cette opération a nécessité une importante préparation en amont avec, par exemple, l'utilisation du côté de GE d'adresses IP compatibles avec le plan d'adressage EDF et du côté d'EDF, la résolution de noms en arabellesolutions.com.

Publicité
« La migration a concerné des d'applications variées, depuis l'application classique 3 tiers jusqu'aux développements maison avec de nombreux composants et interdépendances » : Ahn Le Viet, expert cloud public chez EDF, à l'occasion du AWS Summit Paris, le 9 avril 2025. (photo : ED)

L'étude d'impact sur la gouvernance a constitué l'autre sujet important de la phase de préparation. La landing zone comprenait en effet l'implantation de garde-fous conformes aux bonnes pratiques en la matière, avec entre autres des politiques empêchant des actions telles que la création d'instances EC2 directement exposées sur Internet. Globalement, comme l'a expliqué Ahn Le Viet, les deux entreprises avaient des politiques de gouvernance différentes, et, dans cette période de transition, celles d'EDF ne devaient pas perturber les applications de GE, une fois migrées. « C'était le cas, par exemple, de la remédiation de ressources non conformes, déployées avec des tags qui ne respectent pas les standards par défaut », a-t-il précisé.

4 premières applications basculées

Le 13 mai 2024, EDF a donné le feu vert à ses équipes cloud pour une migration le 31 mai. Après la vérification d'une check-list de 54 points, les comptes ont été intégrés la landing zone et l'ensemble testé et validé. Cela a marqué la fin de la première phase, la migration officielle de 4 applications en 3 semaines et la création de la filiale Arabelle Solutions. « La première phase de la bascule était destinée à la migration des applications les plus simples d'Arabelle Solutions, a rappelé Ahn Le Viet. La seconde a été consacrée aux plus complexes, notamment les applications SAP ».

La filiale étant officiellement créée, les équipes EDF ont pu travailler avec les équipes de GE, qui ont directement reconstruit leurs applications avec des comptes EDF spécifiquement créés pour elles, directement dans la landing zone cible. Le défi majeur de cette 2e phase a été la migration des données. « Une instance hébergée sur la landing zone de GE devaient pouvoir accéder à une instance EDF, a raconté l'expert cloud public de l'entreprise. Les flux applicatifs GE devaient fonctionner au sein de notre landing zone, tout en évitant des flux réseaux vers les comptes des autres entités d'EDF ou ses datacenters. Pour se conformer à l'ensemble de nos règles de gouvernance, nous avons donc mis en place un VPN site à site et un filtrage des flux ».

Prendre en compte les systèmes obsolescents

Dans cette deuxième phase, EDF a aussi dû s'occuper de l'obsolescence de certains systèmes sur lesquelles les applications GE reposaient. « La migration devant se faire en l'état, nous avons par exemple dû basculer des machines EC2 avec du Redhat 7.9, a ainsi raconté Ahn Le Viet. Or, ce système n'est plus maintenu par l'éditeur depuis juin 2024, ce qui nous a contraints à souscrire des services de maintenance étendue auprès de Red Hat, décentralisés au niveau de l'organisation et fournir des AMI (Amazon machine images) pour ce faire ». Par ailleurs, les premières applications migrées avaient été fournies avec la V1 du pare-feu applicatif AWS WAF (web application firewall), également rendu obsolète cette année. Cette fois, EDF a organisé un plan de migration vers la V2.

En dehors de ces sujets identifiés en amont de la migration, les équipes EDF ont aussi eu quelques surprises, comme l'a souligné Ahn Le Viet. « Quelque temps après les débuts de la migration, nous nous sommes rendu compte que notre facture cloud s'alourdissait de 3000 dollars par mois. Cela provenait du service de protection DDoS AWS Shield Advanced, ajouté à la protection standard incluse dans AWS ». Ce service, qui n'était activé que chez GE, a été activé automatiquement chez EDF après la réception d'un compte GE dans le cloud cible. Un moindre mal puisque, finalement, EDF a trouvé le service utile, et l'a conservé comme une brique disponible dans son environnement.

« Le résultat de ce processus, cela a été la migration de 17 applications sur 38 comptes en deux phases successives d'une durée total de 27 mois, a conclu Ahn Le Viet. Un projet qui a mobilisé principalement quatre personnes à temps plein, dont moi-même, avec la contribution d'autres équipes. Et à date, nous avons 140 To de stockage objet, 280 VM, une trentaine de bases de données avec 6 moteurs différents et 127 fonctions as-a-service. ».

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis