Cadrer une migration cloud : business case, gouvernance PMO et pilotage par vagues

Les programmes cloud échouent rarement sur la technique

Quand un programme de migration déraille, le retour d'expérience ne pointe presque jamais Terraform, Kubernetes ou la landing zone. Il pointe un périmètre jamais borné, un business case que plus personne ne porte après la signature, un COPIL transformé en théâtre du reporting, et un registre des risques mis à jour la semaine précédant l'audit.

Le cadrage — les deux à douze semaines qui précèdent la première bascule — est l'endroit où le programme se gagne ou se perd. C'est aussi la phase que les organisations compriment le plus, parce qu'elle produit des slides plutôt que des systèmes qui tournent. Le marché est mauvais : chaque ambiguïté laissée au cadrage se rembourse avec intérêts pendant l'exécution, sous forme de dérive de périmètre, de double run qui s'éternise et de décommissionnements qui n'arrivent jamais.

Cadrer, c'est transformer une intention en périmètre mesurable

« Aller vers le cloud » n'est pas un périmètre. Un livrable de cadrage exploitable répond précisément à quatre questions.

Qu'est-ce qui est dans le périmètre ? Un inventaire applicatif avec, pour chaque item : propriétaire métier, propriétaire technique, niveau de criticité, classification des données, dépendances d'exécution, intégrations amont/aval, contraintes de licences et coût d'hébergement actuel. L'outillage de discovery (analyse de flux réseau sans agent, extraction CMDB, topologie APM) vous amène à 70 % du chemin ; les 30 % restants viennent des entretiens, et c'est là que se cachent les surprises : le job FTP non documenté, la fonctionnalité Oracle que personne ne sait remplacer, l'appliance dont l'éditeur n'a pas de version cloud.

Quelle est la cible ? Pas seulement « AWS » ou « OVHcloud », mais la trajectoire par application. Le modèle des 7R (retire, retain, rehost, relocate, replatform, repurchase, refactor) est utile précisément parce qu'il force une décision par application plutôt qu'une stratégie uniforme. Attendez-vous à un mix : un portefeuille 100 % refactor est un budget fantasmé, un portefeuille 100 % rehost est un problème de coût simplement reporté de dix-huit mois.

Quelles sont les contraintes de séquencement ? Dépendances, périodes de gel métier, échéances contractuelles, date de sortie du datacenter, obligations réglementaires. La fin de bail du datacenter est souvent la seule date réellement dure du programme — tout le reste se négocie.

Que veut dire « terminé » ? Une migration n'est pas finie quand la charge tourne dans le cloud. Elle est finie quand la source est décommissionnée, la licence résiliée, le runbook à jour et l'astreinte transférée. Définissez-le au cadrage, sinon vous porterez de l'infrastructure zombie pendant des années.

Un business case que le DAF ne peut pas démonter

Les business cases les plus faibles comparent une facture cloud à une facture matériel. Cette comparaison perd toujours, parce qu'elle ignore tout ce qui rend l'on-premise coûteux et tout ce qui rend le cloud économique au-delà du compute.

Construisez le modèle sur un coût complet de possession à horizon défini — typiquement trois à cinq ans, aligné sur votre cycle de renouvellement matériel — en incluant les mêmes postes des deux côtés.

Deux lignes méritent une attention particulière parce qu'elles sont systématiquement sous-estimées. Le double run est la période pendant laquelle vous payez la source et la cible. Son coût est une fonction directe de la vélocité de migration : diviser par deux la durée d'une vague divise par deux la facture de double run. C'est l'argument financier le plus fort pour industrialiser une usine de migration plutôt que de traiter chaque application comme un projet isolé. Les transferts de données, pendant la migration puis structurellement pour les intégrations hybrides, peuvent peser lourd sur les charges data-intensives.

Côté bénéfices, évitez les promesses vagues d'« agilité ». Quantifiez ce que vous pouvez défendre : renouvellement matériel évité, surface rendue, consolidation de licences, délai de provisioning d'environnement (en jours avant, en heures après), capacité tampon qu'il n'est plus nécessaire d'acheter par anticipation. Associez un niveau de confiance à chaque bénéfice et laissez les chiffres prudents porter le dossier. Un business case crédible à 60 % de son scénario optimiste survit au contact du DAF ; celui qui a besoin de 100 % de ses bénéfices, non.

Gouvernance PMO : trois instances, pas dix

Les programmes sur-gouvernés brûlent leurs meilleurs ingénieurs en réunion. Une structure qui fonctionne comporte trois niveaux de décision, chacun avec un mandat distinct.

• Comité de pilotage (mensuel, exécutif) : budget, arbitrage de périmètre, risques escaladés, go/no-go de vague. Le sponsor doit être un dirigeant métier, pas seulement le DSI — une migration sponsorisée uniquement par l'IT perd sa priorité dès le premier conflit avec une roadmap produit.
• Revue de programme (hebdomadaire, delivery) : avancement des vagues, points bloquants, ressources, conflits de dépendances. Animée par le directeur de programme, avec les responsables de chantier.
• Comité d'architecture et sécurité (bimensuel ou à la demande) : patterns cibles, dérogations, évolutions de la landing zone. Son pouvoir est de dire « non, utilisez le pattern standard » — et son obligation est de publier ce pattern.

En dessous, un Cloud Center of Excellence ou une équipe plateforme détient les actifs réutilisables : landing zone, modules IaC, pipelines CI/CD, garde-fous, politique de tagging FinOps. Le CCoE n'est pas une instance de gouvernance qui relit ; c'est une équipe produit qui livre. La distinction est essentielle : un CCoE qui ne fait que relire se fait contourner par les équipes applicatives.

Rédigez un RACI une seule fois, sur les décisions réellement récurrentes : choix de la trajectoire par application, acceptation d'une bascule, approbation d'une dérogation sécurité, propriété du coût post-migration. L'ambiguïté sur ce dernier point est la cause la plus fréquente d'échec FinOps : personne n'est responsable d'une facture qui arrive après la dissolution de l'équipe projet.

Vagues, jalons et critères d'entrée/sortie

Découpez le portefeuille en vagues cohérentes : une grappe de dépendances partagées, un pattern cible commun, un domaine métier. La première vague doit être volontairement ennuyeuse : criticité faible, peu de dépendances, une trajectoire que vos équipes maîtrisent déjà. Son objectif est de valider l'usine, pas de démontrer l'ambition.

Chaque vague a des critères d'entrée et de sortie explicites, versionnés au même titre que le reste des artefacts du programme :

vague: W03-backoffice-retail
fenetre: 2026-03-02 .. 2026-04-24
applications: [ORD-142, INV-078, PRC-330]
trajectoire: replatform (RDS PostgreSQL + ECS Fargate)
criteres_entree:
  - cartographie_dependances_validee: true
  - compte_landing_zone_provisionne: true
  - modules_iac_disponibles: [vpc, rds, ecs-service, alb]
  - runbook_redige: true
  - plan_de_rollback_teste_en_preprod: true
  - fenetre_de_gel_metier_confirmee: true
criteres_sortie:
  - tests_fonctionnels_ok: 100%
  - performance_dans_slo: p95 < 400ms
  - observabilite: dashboards + alertes branchees sur l_astreinte
  - environnement_source_decommissionne: true
  - licences_resiliees: true
  - tags_de_cout_appliques: [app, env, owner, cost-center]
hypercare: 10 jours ouvres

Les deux critères que les équipes sautent sous pression — plan_de_rollback_teste_en_preprod et environnement_source_decommissionne — sont exactement ceux qui déterminent si le programme tient son business case. Faites-en des jalons de sortie non négociables et présentez le taux de décommissionnement à chaque COPIL.

Les risques qui se matérialisent vraiment

Un registre des risques qui liste « retard du projet » est décoratif. Une entrée utile nomme un mécanisme, un signal d'alerte précoce et un responsable.

Piloter avec des chiffres, pas des récits

Quatre indicateurs suffisent à tenir un COPIL mensuel : pourcentage du portefeuille migré et décommissionné (deux courbes distinctes — l'écart entre elles mesure votre exposition au double run), dépense cloud réelle contre prévision par vague, taux d'incident de bascule pendant l'hypercare, et délai moyen par application entre critère d'entrée et critère de sortie. Suivez la vélocité comme une tendance : si l'usine n'accélère pas dès la troisième vague, le problème est l'industrialisation, pas l'effort.

Dernier point de gouvernance, et il est temporel. Un programme de migration a une date de fin ; l'exploitation cloud, non. Planifiez le transfert de propriété — coût, sécurité, fiabilité — vers des équipes pérennes dès la première vague, et non comme une formalité de clôture. Les programmes qui tiennent leur business case sont ceux où, six mois après la dernière bascule, quelqu'un est encore responsable de la facture.