Une migration cloud échoue rarement pour des raisons techniques
La landing zone finit par être construite. Les modules Terraform finissent par être écrits. Les workloads finissent par bouger. Et pourtant, une part importante des programmes de migration dérape : budget dépassé, calendrier glissant, ou arrêt à mi-parcours avec deux patrimoines à exploiter au lieu d'un. Le mode de défaillance n'est presque jamais « on n'a pas réussi à le faire tourner sur AWS, Azure, GCP ou OVHcloud ». C'est un périmètre jamais cadré, un business case que personne ne porte, une gouvernance incapable d'arbitrer, et des équipes applicatives informées plutôt qu'embarquées.
C'est très exactement le terrain de l'AMOA, du PMO et de la conduite du changement. Cet article décrit comment nous structurons et pilotons un programme de migration : cadrage, business case, répartition des rôles, cadence de gouvernance, cadres méthodologiques à emprunter (PMP, SAFe, ITIL 4, PRINCE2) et indicateurs qui disent réellement si le programme tient la route.
Le cadrage : transformer une intention en périmètre défendable
« On va au cloud » est une direction, pas un périmètre. La phase de cadrage — typiquement quatre à huit semaines pour un patrimoine de taille moyenne — a une seule mission : convertir cette direction en décisions opposables. Quatre livrables comptent vraiment.
1. Inventaire applicatif et cartographie des dépendances. Pas un tableau de VM, mais un inventaire d'applications avec leur propriétaire métier, leur criticité, la classification des données, la dette technique, les contraintes contractuelles et surtout leurs dépendances entrantes et sortantes. L'outillage de découverte (Azure Migrate, AWS Application Discovery Service, extraction de CMDB, analyse des flux réseau) vous amène à 70 % ; les entretiens avec ceux qui exploitent réellement l'application font le reste.
2. Une disposition par application (les 7 R). Retire, retain, rehost, replatform, repurchase, refactor, relocate. Cette décision doit être tracée et scorée, pas issue d'une conversation de couloir. Un modèle pondéré simple fait le travail :
applications:
- nom: facturation-core
responsable: dsi-finance
criticite: tier-1
scores: # 1 (faible) a 5 (fort)
valeur_metier: 5
appetence_changement: 2 # capacite de l'equipe a absorber un refactoring
dette_technique: 4
cloud_readiness: 2 # stateless ? conteneurisable ? licences ?
poids_reglementaire: 4
disposition: replatform
vague: 3
justification: >
Chaine de revenus tier-1, faible appetence au changement cette annee.
PostgreSQL manage + conteneurs, refactoring reporte a N+1.
3. Architecture cible et principes de landing zone. Découpage en comptes ou souscriptions, topologie réseau, modèle d'identité, garde-fous de sécurité, taxonomie de tags, standard d'observabilité. On décide une fois, de manière centralisée, puis les équipes consomment. Chaque dérogation négociée plus tard coûte un multiple de ce qu'elle coûte à traiter maintenant.
4. Plan de vagues. Séquencer par grappe de dépendances et par risque, pas par ordre alphabétique ni selon l'équipe qui crie le plus fort. La vague 0 doit être un pilote réellement représentatif : une application avec de vrais utilisateurs, de vraies données, une vraie astreinte — pas le wiki interne.
Business case et ROI : sortir du piège du « lift & shift moins cher »
Le business case le plus destructeur est celui qui promet des économies d'infrastructure à partir d'un pur rehost. Déplacer un parc de VM surdimensionnées vers des instances à la demande coûte généralement plus cher le premier mois, et l'écart ne se referme qu'avec le rightsizing, la couverture par engagements, l'extinction des environnements hors production et le tiering du stockage — autant de travaux FinOps qu'il faut staffer et planifier explicitement.
Un business case crédible comporte quatre gisements de valeur, à modéliser séparément :
| Gisement | Contenu | Horizon de matérialisation | Fiabilité |
|---|---|---|---|
| Coût d'infrastructure | Compute, stockage, réseau, licences, datacentre, renouvellement matériel évité | Après rightsizing et engagements, 6 à 12 mois post-migration | Élevée — mesurable |
| Efficacité opérationnelle | Moins de patching, de sauvegarde, d'ops matérielle ; services managés remplaçant des middlewares auto-hébergés | Progressif, corrélé à la décommission | Moyenne |
| Vélocité de delivery | Délai de mise à disposition d'environnement, fréquence de déploiement, lead time | Nécessite l'investissement plateforme + CI/CD, 12 mois et plus | Moyenne — à suivre via les métriques DORA |
| Capacité métier | Élasticité pour les pics saisonniers, accès aux plateformes data/IA, time-to-market | Long terme, porté par le métier | Faible — à modéliser en scénarios, pas en chiffre unique |
Deux disciplines maintiennent le business case honnête. D'abord, modéliser le coût de double run : la période où l'on paie les deux patrimoines. C'est la plus grosse ligne de coût de la plupart des programmes, et la raison pour laquelle la décommission doit être un livrable daté et suivi, pas une intention. Ensuite, traiter la sortie du datacentre comme un jalon dur avec une échéance contractuelle : une migration sans date de décommission dérive indéfiniment.
Exprimez le résultat sous forme de courbe de trésorerie sur trois à cinq ans, avec un point de bascule, plutôt qu'en pourcentage unique. Et intégrez explicitement le coût du programme lui-même : ingénierie cloud, PMO, AMOA, formation, renégociation de licences, et la baisse de productivité pendant la transition.
AMOA, AMOE, PMO, Product Owner : qui fait quoi
L'échec organisationnel le plus fréquent consiste à confondre ces rôles, ou à les confier tous à un responsable infrastructure déjà saturé.
| Rôle | Porte | Livrables clés | Anti-pattern |
|---|---|---|---|
| AMOA | Le pourquoi et le quoi : besoins métier, choix de disposition, critères d'acceptation | Inventaire applicatif, expression de besoins, stratégie de recette, préparation métier | Une fonction purement documentaire, sans pouvoir de décision |
| AMOE / delivery technique | Le comment : landing zone, IaC, usine de migration, exécution des bascules | Décisions d'architecture, runbooks, pipelines automatisés | Décider du périmètre seul « parce que le métier n'est pas disponible » |
| PMO | Le quand et le combien : planning, risques, budget, dépendances, reporting | Plan de vagues, registre RAID, suivi budgétaire, dossier de comité | Usine à reporting qui révèle les problèmes après coup |
| Product Owner plateforme | La landing zone comme produit interne avec de vrais utilisateurs | Backlog plateforme, golden paths, métriques d'adoption | Construire une plateforme que personne n'a demandée ni n'adopte |
Dans un programme cloud, le PMO n'est pas une fonction administrative. Sa valeur réelle est la gestion des dépendances — ces contraintes de séquencement inter-applications, inter-équipes, inter-fournisseurs qu'aucune squad ne voit depuis son périmètre — et la mise en visibilité des risques suffisamment tôt pour agir. Un PMO qui se contente d'un tableau vert/orange/rouge est un coût ; un PMO qui débloque la dépendance réseau de la vague 3 six semaines avant l'impact est le rôle au plus fort effet de levier du programme.
Gouvernance : moins de réunions, des décisions plus nettes
La gouvernance existe pour décider au bon niveau et à la bonne vitesse. Trois étages suffisent généralement :
- Comité de pilotage (mensuel) — sponsor, direction métier et DSI. Ordre du jour : budget vs business case, trajectoire des jalons et de la décommission, risques majeurs, et arbitrages uniquement. Si le COPIL est informé plutôt que décisionnaire, c'est du théâtre.
- Comité de programme (hebdomadaire) — PMO, architecte référent, responsable AMOA, responsables de vague. Avancement des vagues, blocages transverses, demandes de changement, revue RAID.
- Stand-up usine de migration (quotidien en période de bascule) — opérationnel, 15 minutes, blocages seulement.
Ajoutez deux artefacts au rendement disproportionné. Un référentiel d'ADR (Architecture Decision Records) dans Git, versionné à côté de l'IaC, pour que personne ne rejuge six mois plus tard le choix d'une topologie transit gateway ou d'un moteur de base de données. Et un processus de demande de changement avec étiquette de prix : toute évolution de périmètre est chiffrée en euros et en jours avant d'être acceptée. Rien ne discipline la dérive de périmètre aussi vite qu'un coût visible.
PMP, SAFe, ITIL 4, PRINCE2 : emprunter sans importer en bloc
Aucun cadre ne couvre une migration cloud de bout en bout. Une migration est hybride : prédictive au niveau programme (les dépendances, les dates de bascule et les échéances contractuelles ne se négocient pas avec un backlog), adaptative au niveau delivery (chaque application révèle ses surprises).
| Cadre | Ce qu'on en prend | Où ça coince |
|---|---|---|
| PMP / PMBOK | Rigueur sur périmètre, risques, parties prenantes et achats ; valeur acquise sur les vagues longues et prévisibles | Un contrôle des changements lourd freine des équipes qui doivent itérer chaque semaine |
| PRINCE2 | Business case explicitement porté, jalons de phase, escalade par tolérances | Cérémonial documentaire si appliqué à la lettre |
| SAFe | PI planning pour synchroniser de nombreuses équipes, visualisation des dépendances, flux dédié plateforme / enablers | SAFe intégral sur un programme à 4 équipes est du pur surcoût : prenez la cadence de planification, laissez l'organigramme |
| ITIL 4 | Transition de service, change enablement, continuité — indispensables pour le modèle opérationnel day-2 et le passage build → run | Appliqué rigidement, son comité de changement redevient le goulot que la plateforme devait supprimer |
Le montage pragmatique : jalons de phase à la PRINCE2 en fin de vague, événement de planification trimestriel inspiré de SAFe pour aligner squads applicatives et équipe plateforme, ITIL 4 pour le change enablement et le modèle de service cible, discipline PMP sur les risques et les achats. Les certifications comptent moins que la capacité des pilotes à expliquer pourquoi ils ont retenu chaque mécanisme.
La conduite du changement est un livrable, pas un plan de communication
Migrer une application sans migrer le modèle opérationnel produit une machine virtuelle dans le datacentre de quelqu'un d'autre et une facture plus élevée. Ici, la conduite du changement se traduit par trois chantiers concrets.
Compétences. Cartographier le modèle opérationnel cible rôle par rôle : qui traite un incident sur une base managée, qui revoit les politiques IAM, qui approuve une modification de module Terraform. Le plan de formation et de certification se construit contre cette cartographie, pas contre un catalogue générique. Et une communauté de pratique interne réelle — une clinique hebdomadaire où les équipes amènent leurs vrais problèmes — vaut mieux qu'une semaine de formation one-shot.
Processus. Incident, changement, capacité, continuité : tout bouge. La sauvegarde devient politique de snapshots plus tests de restauration. Le capacity planning devient politique d'autoscaling plus stratégie d'engagements. Les nouveaux runbooks s'écrivent pendant la migration, avec l'équipe run dans la salle, pas après la mise en production.
Adoption. Elle se mesure : part des workloads déployés via le golden path, nombre d'équipes onboardées, tickets ouverts sur le self-service. Une landing zone adoptée à 20 % est un produit en échec, quelle que soit sa qualité technique.
Les indicateurs qui pilotent réellement
- Vélocité de migration — applications ou VM migrées par vague vs plan, avec un burn-up cumulé.
- Taux de décommission — le seul indicateur qui prouve que la valeur est captée. L'écart entre migré et décommissionné mesure votre exposition au double run.
- Dépenses réelles vs business case, ventilées par vague, avec des coûts unitaires (par application, par environnement).
- Stabilité post-bascule — incidents dans les 30 jours suivant la mise en production, par application : indique si vos tests pré-migration sont suffisants avant que la vague N+1 n'amplifie le problème.
- Métriques DORA sur les applications migrées — fréquence de déploiement et lead time, pour objectiver le gisement « vélocité ».
- Adoption plateforme — taux d'usage des golden paths.
Cinq schémas d'échec à nommer
Le pilote qui ne prouve rien. Un outil interne stateless sans utilisateur ne valide ni votre processus de bascule ni votre modèle d'exploitation. Choisissez un pilote qui pique un peu.
La décommission traitée « plus tard ». Sans date contractuelle de sortie de datacentre et sans responsable nommé par décommission, l'ancien patrimoine survit des années et le business case s'évapore.
Le FinOps greffé à la fin. Taxonomie de tags, alertes budgétaires, showback et stratégie d'engagements appartiennent à la conception de la landing zone, pas à un projet de réduction de coûts post-migration.
Une équipe plateforme sans mandat produit. Si les équipes applicatives contournent le golden path sans conséquence ni dialogue, vous obtiendrez une plateforme centrale et un patrimoine parallèle.
Une gouvernance qui rend compte au lieu d'arbitrer. Si aucune décision n'a été prise au dernier COPIL, annulez le suivant et corrigez l'ordre du jour.
Une migration cloud est une transformation organisationnelle à composante technique, et non l'inverse. L'ingénierie est largement un problème résolu ; c'est sur le cadrage, la rigueur du business case, la cadence de gouvernance et la conduite du changement que les programmes se gagnent ou se perdent.