Réussir le « Move To Cloud » (1ère partie)

• 22 novembre 2024
• Nicolas Portalier

Cet article est le premier d’une série consacré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.
Nombreuses sont les entreprises et organisations à avoir opté pour des architectures Cloud pour leur Système d’Information. Les enjeux associés à de tels choix ne sont pas uniquement techniques mais également organisationnels, contractuels et humains. Les acteurs qui ne considéreront pas cette portée transformationnelle sont condamnés à ne pas réaliser pleinement les gains économiques escomptés de telles initiatives. En effet la migration vers un environnement Cloud est d’abord une opportunité unique de modernisation et de rationalisation du portefeuille applicatif. C’est également l’occasion de transformer en profondeur la façon dont sont maintenues les applications en abandonnant les pratiques classiques de maintenance évolutive au profit du « Continuous Integration / Continuous Delivery » (CI/CD).

Ce premier article est consacré à la préparation de la migration. Il met en exergue 4 préconisations qu’il nous semble essentiel de mettre en œuvre.

1. Construire le business model et l’utiliser pour prioriser les applications

Il n’y a en général pas de débat sur l’existence de gains globaux et à long terme associés à la migration vers une architecture Cloud. Cependant, à moyen terme et au niveau de chaque application, le calcul du ROI est moins évident. Effectuer cet exercice pour chaque application permet de prioriser les cas applicatifs et sécuriser le financement du projet dans son ensemble. Si le business model n’est pas clair, alors les priorités ne sont pas connues et les applications candidates mal sélectionnées.
Pour répondre à ce besoin, il est recommandé de mettre en place une petite équipe dédiée dont la mission est de récupérer les coûts, construire et maintenir les hypothèses de coûts et leur répartition par applications. Elle a vocation à travailler avec les différents départements et unités du Groupe.

2. Etablir une planification rigoureuse

En proie aux difficultés opérationnelles, les équipes projets ont tendance à lâcher les vues globales du projet pour ne se concentrer que sur les cas d’espèce. Cependant, comme sur tout projet, la préparation et l’anticipation permettent de gagner du temps et de réduire les efforts des équipes. Cette anticipation est également nécessaire à plus haut niveau pour aligner les feuilles de routes des différents services d’hébergement cible qui seront nécessaires à telle ou telle application à moderniser.
Une typologie simple de cas de modernisation (taille de tee-shirt) est construite pour estimer les élongations de chaque modernisation. Un planning charge / capacité est tenu à jour et partagé pour donner de la visibilité et coordonner tous les acteurs et parties prenantes.
D’autre part, les nouvelles zones d’hébergement ont besoin que soient définis leur modèle opérationnel et leur organisation (processus, ressources, outils) de support utilisateurs.

3. Assurer la qualité de la baseline documentaire

Les informations concernant les applications existantes héritent parfois d’un historique compliqué, elles sont parfois incomplètes voire erronées. Cependant, elles restent critiques pour permettre une évaluation pertinente de la situation de départ pour construire la vision cible adéquate et un plan de modernisation réaliste.
Dans certains cas, certains documents critiques n’existent pas : document d’architecture ou cahier de test par exemple.
Un contrôle qualité est mis en place avec les guidelines et les expertises nécessaires, notamment en matière d’architecture solution. Un jalon de rendu est constitué avec une check-list formelle et une revue de passation. Le projet peut également se doter d’une cellule de rédaction de ces documents à la demande.

4. Sécuriser la mobilisation du propriétaire de l’application

La mobilisation du responsable fonctionnel de l’application est indispensable tout au long du processus de migration. La phase de préparation est l’occasion de construire la relation sur le long terme. Cette démarche est menée avec tous les « propriétaires » d’applications indépendamment du niveau de priorité de l’application. Une démarche individualisée peut également être proposée face à d’éventuels propriétaires d’applications initialement réticents. Un volet change management permet d’entretenir les différents niveaux de communication nécessaires : depuis l’amont pour amorcer la prise de conscience jusqu’à l’aval pour capitaliser sur les retours d’expérience.
Une fois embarqués, les propriétaires d’applications font l’objet d’une communication régulière notamment sur le planning global et ses évolutions.

Une préparation réussie permet d’envisager plus sereinement la phase de migration technique. Celle-ci fera l’objet d’un prochain article. A bon entendeur…