Réussir le « Move To Cloud » (3ème partie)

• 19 février 2025
• Steven Huet

Introduction 

Cet article est le troisième volet d’une série dédiée à la migration de portefeuilles d’applications vers un environnement Cloud. 

Il s’appuie sur notre retour d’expérience de missions d’accompagnement auprès de grands acteurs industriels sur de tels projets. 

Consacré à la migration en environnement cloud (ou « cloudification ») en elle-même, l’article met en avant quatre recommandations que nous considérons essentielles à mettre en œuvre. 

Cet article fait suite au deuxième volet consacré à l’évaluation des applications. 

Recommandation n°1 : penser ‘industrialisation’ même si elle reste une illusion. 

Le réflexe habituel d’un bon professionnel est de construire des catégories, des patterns, des feuilles de routes, des abaques etc. pour capitaliser son expérience, la transmettre et accélérer. Malheureusement, la vraie vie impose une réalité disparate, surtout lorsqu’il s’agit de migrer des applications « legacy » qui ont chacune leur histoire, leur mode de gestion, leurs intervenants, leur architecture technique etc. Il devient alors naturel de basculer d’un plan bien construit à un mode commando où ‘on se débrouille et on fait au mieux’. 

Cependant, la capitalisation reste essentielle et elle est toujours possible. Elle permet bien sûr de sécuriser les coûts et les délais. Il ne faut pas lâcher. Les basiques de la gestion de programme doivent être maintenus. 

Un Process Owner (Delivery Lead) est en charge de s’assurer de la définition collaborative des processus projet, de leur mise en place opérationnelle, de leur amélioration continue notamment via des rétrospectives. Il livre les vues synthétiques permettant de coordonner les parties prenantes et des outils, des supports, des protocoles très opérationnels au service des acteurs de la migration. 

Recommandation n°2 : une implication mesurée de l’équipe applicative. 

La responsabilité de la gestion de l’application à migrer reste à l’équipe applicative. Le fait qu’une équipe projet manipule une application (la migre) en mode projet ne signifie pas un transfert de propriété, même ponctuellement. La migration ne peut se faire sans l’équipe applicative ; elle connait la solution technique, elle a la relation avec les utilisateurs avec qui il faut communiquer le changement, elle a la relation avec l’éditeur, avec l’équipe de maintenance. La migration sur le Cloud est avant tout une transformation avec une dimension organisationnelle et non une simple opération technique. 

Il importe donc dès le début (et même dans les phases amont) de clarifier très précisément les rôles et responsabilités, le planning, la gouvernance de la migration, d’avoir des points de rencontre fréquents – voire en temps réel avec les outils modernes, pour que l’équipe applicative gère son niveau d’implication. Il est faible dans la première phase mais non nul. 

Cela évite les abandons qui conduisent à des blocages et des escalades, les postures client-fournisseur qui se terminent toujours en conflits prétendument contractuels, qui bloquent l’opérationnel et laissent tout le monde amer. 

Recommandation n°3 : un gel fonctionnel bien compris et effectif. 

La modernisation se fait avec une application qui fonctionne en production pour ne pas mélanger les cas d’usage, pour éviter de patcher en continu l’application en cours de modernisation dans les environnements Cloud et d’étirer le planning. Lorsque la modernisation prend plus de temps que prévu, l’App Owner est tenté de continuer de modifier son application alors en production pour améliorer le service aux utilisateurs. 

Le principe du gel fonctionnel est fermement posé auprès de l’App Owner dès le démarrage de la modernisation. Des arbitrages sont organisés si des corrections de bugs critiques sont nécessaires en production. Sinon, les travaux sont reportés après la mise en production de l’application modernisée. 

Un suivi régulier (hebdomadaire) avec l’App Owner permet de vérifier la mise en œuvre effective de cette consigne et de l’informer sur la tenue du planning pour gérer son éventuelle impatience. 

Recommandation n°4 : préparer en parallèle la montée en puissance de l’organisation Cloud. 

Le move to Cloud n’est pas qu’un simple projet de migration technique. Il faut penser dans son ensemble la gestion du cycle de vie de l’application modernisée. Aucun gain ne serait réalisé si, une fois l’application migrée sur le Cloud, les pratiques associées et le support ne sont pas en place. 

Il s’agit non seulement de l’accompagnement du changement des équipes applicatives, avec ce que cela comporte de communication, de formations, d’organisation des équipes, mais surtout du dispositif à mettre en place pour opérer le support lié au Cloud, pour offrir les bons services aux équipes et les faire évoluer. Une organisation complète est à mettre en place avant la migration de la première application. 

Ce sont des moyens supplémentaires engagés au niveau de l’entreprise elle-même et non du projet de move-to-cloud en lui-même. Il faut parler ici de transformation d’entreprise. 

En conclusion, la modernisation des applications doit être pilotée avec rigueur et persévérance 

Notre retour d’expérience met en lumière deux axes fondamentaux : 

1. Garder une démarche structurée tout au long du projet. Celui-ci prend place au sein d’une entreprise existante, il doit s’appuyer sur celle-ci et non jouer contre elle ; 

1. Une communication régulière avec les équipes applicatives afin d’entretenir la confiance et le rythme des travaux de modernisation. 

Un programme de “move to cloud” est une ambition de longue haleine qui a la vertu de faire le ménage dans le legacy du système d’information de l’entreprise. Mais c’est d’abord le pan technique d’un programme plus large de transformation d’entreprise.