Une migration cloud bloquée fait perdre du temps, du budget et de la confiance. Débloquer une migration cloud bloquée exige un diagnostic technique lucide et un pilotage ferme pour reprendre la trajectoire.
Une migration cloud bloquée est un scénario plus courant qu’on ne le pense. Selon Gartner, près de 30 % des projets de migration cloud prennent du retard ou sont suspendus en cours de route. Cette ETI automobile de 600 collaborateurs a vécu cette situation : un projet cloud à l’arrêt depuis plusieurs mois, sans vision claire ni pilotage. TransiCIO a redéfini la trajectoire et relancé la migration avec succès.
Contexte : une migration cloud au point mort depuis un an
L’entreprise avait initié la migration de son système d’information vers une infrastructure cloud un an auparavant. L’objectif initial (moderniser les infrastructures, gagner en agilité et réduire les coûts d’exploitation) était pertinent. Mais le projet s’est enlisé progressivement.
Le projet manquait d’alignement stratégique entre la DSI, les directions métiers et la direction générale. Aucune priorisation claire n’avait été définie : quelles applications migrer en premier ? Quel modèle cloud adopter (IaaS, PaaS, SaaS) ? Quelle architecture cible ? Les équipes internes, insuffisamment formées aux technologies cloud, avaient accumulé les impasses techniques.
Cette situation avait généré un climat de défiance. Les métiers reprochaient à la DSI des interruptions de service récurrentes, tandis que la DSI pointait le manque de moyens et de soutien de la direction. Le budget initial de 1,2 M€ avait été consommé à 720 K€ sans livrable opérationnel probant. L’ERP restait sur site, l’infrastructure était hybride non maîtrisée, et les coûts cloud augmentaient de 15 % par mois sans visibilité.
Les enjeux identifiés
Absence de pilotage structuré
Le projet ne disposait ni de chef de programme dédié, ni de gouvernance formalisée. Les décisions étaient prises de manière ad hoc, sans traçabilité ni arbitrage. La DSI, les métiers et la direction générale n’avaient pas de vision partagée de la cible cloud.
Les réunions de suivi, initialement hebdomadaires, s’étaient espacées puis avaient cessé. Aucun tableau de bord consolidé ne permettait de suivre l’avancement réel. Les comptes-rendus de migration étaient rédigés sans plan d’action formalisé. Cette absence de cadre a conduit à une démobilisation progressive des équipes, qui ne voyaient plus de cap clair.
Choix technologiques non validés
Plusieurs choix d’architecture avaient été faits sans étude préalable suffisante, créant des impasses techniques. Certaines applications legacy, non compatibles cloud-native, avaient été partiellement migrées dans un état instable, générant des incidents de performance récurrents.
L’équipe avait notamment tenté de migrer une application de gestion de production codée en Visual Basic 6 vers Azure sans analyse de compatibilité préalable. Résultat : une application qui crashait quotidiennement, obligeant à maintenir un serveur on-premise en parallèle. Les bases de données avaient été migrées vers des instances surdimensionnées par méconnaissance du rightsizing, générant des coûts 3 fois supérieurs au nécessaire.
Budget consommé sans résultats visibles
Près de 60 % du budget avait été consommé pour des résultats marginaux. La direction générale remettait en question la pertinence même de la migration cloud, envisageant un retour en arrière qui aurait représenté une perte sèche considérable.
L’analyse détaillée révélait que 280 K€ avaient été dépensés en licences cloud mal dimensionnées, 180 K€ en consulting externe peu coordonné, et 260 K€ en temps équipe interne consacré à des migrations avortées. Le ROI initialement prévu à 24 mois paraissait hors de portée, alimentant la tentation d’abandonner le projet.
Pourquoi les migrations cloud échouent : les facteurs structurels
Selon une étude IDC de 2023, 73 % des entreprises européennes déclarent avoir rencontré des difficultés majeures lors de leur migration cloud. Les causes ne sont pas uniquement techniques.
Le manque d’alignement business-IT arrive en tête des facteurs d’échec. Quand la DSI migre pour des raisons techniques (obsolescence, fin de support) sans lien clair avec les objectifs métier (time-to-market, innovation, scalabilité), les arbitrages deviennent impossibles. La direction générale ne comprend pas pourquoi investir autant pour « juste déplacer des serveurs ».
La sous-estimation de la dette technique constitue le deuxième piège. Une application vieille de 15 ans, avec des dépendances obscures et une documentation inexistante, ne se migre pas comme une application moderne conteneurisée. Le lift-and-shift devient un cauchemar opérationnel, et le re-architecting un projet en soi.
L’absence de compétences cloud internes crée une dépendance dangereuse aux prestataires externes. Sans capacité de jugement interne, l’entreprise ne peut challenger les recommandations, détecter les surcoûts ou anticiper les risques. Les certifications AWS Solutions Architect ou Azure Administrator ne sont pas des luxes, mais des prérequis.
L’intervention TransiCIO : redéfinir la trajectoire cloud
Phase 1 : Audit de la situation et recommandations (Semaines 1-4)
Le manager de transition a réalisé un audit complet de la situation cloud : état des migrations en cours, qualité de l’architecture déployée, analyse des coûts réels vs prévisionnel, et évaluation des compétences internes. Cet audit a été complété par des entretiens avec les parties prenantes clés pour comprendre les attentes et les frustrations de chacun.
L’audit a révélé 14 applications migrées dont 6 fonctionnaient en mode dégradé, 8 serveurs cloud actifs en dehors des heures ouvrées sans raison, et une absence totale de stratégie de backup cloud. Les interviews ont mis en lumière que les métiers attendaient surtout une amélioration de la disponibilité et de la capacité à déployer rapidement de nouveaux services, alors que la DSI s’était concentrée sur la réduction des coûts d’infrastructure.
Les recommandations ont pris la forme d’une trajectoire cloud révisée, avec trois scénarios chiffrés présentés au COMEX. Le scénario retenu combinait une approche hybride (cloud privé pour les données sensibles, cloud public pour les workloads standards) avec un séquencement réaliste sur 18 mois.
Le scénario retenu prévoyait une migration par vagues : vague 1 (applications web non critiques), vague 2 (CRM et outils collaboratifs), vague 3 (ERP et applications métier critiques), vague 4 (data analytics et BI). Chaque vague disposait de critères de succès mesurables et d’un budget dédié. L’investissement complémentaire était estimé à 680 K€ sur 18 mois, avec un ROI recalculé à 32 mois.
Phase 2 : Restructuration de la gouvernance et montée en compétences (Mois 2-3)
Une gouvernance projet a été instaurée avec un comité cloud mensuel, des revues techniques hebdomadaires et des indicateurs de suivi clairs (FinOps, disponibilité, performance). En parallèle, un programme de montée en compétences cloud a été déployé pour les équipes IT : certifications, formations pratiques et shadowing avec des architectes cloud seniors.
Le comité cloud réunissait DSI, DAF, directeur industriel et directeur commercial pour valider les arbitrages stratégiques. Les revues techniques hebdomadaires suivaient un dashboard standardisé : applications migrées vs planifiées, coûts réels vs budget, incidents P1/P2, taux d’utilisation des ressources cloud. Ces métriques ont créé une transparence qui manquait totalement auparavant.
Le plan de montée en compétences ciblait 8 collaborateurs IT : 3 ont passé la certification AWS Solutions Architect Associate, 2 la certification Azure Administrator, et 3 ont suivi une formation FinOps Practitioner. Ces formations étaient couplées à des ateliers pratiques sur des environnements sandbox, permettant d’expérimenter sans risque. Un budget de 45 K€ a été alloué à cette montée en compétences, considéré comme un investissement stratégique.
Phase 3 : Reprise des migrations par vagues (Mois 3-8)
Les migrations ont été reprises par vagues ordonnées, en commençant par les applications les moins critiques pour valider les processus, puis en progressant vers les workloads critiques. Chaque migration suivait un processus standardisé : assessment, architecture cible, plan de migration, tests, bascule et validation post-migration.
La première vague a concerné 12 applications web (portail RH, intranet, outils de reporting) migrées en 6 semaines. Cette phase pilote a permis de roder le processus, identifier les points de friction et ajuster la méthodologie. Un playbook de migration de 40 pages a été rédigé, documentant chaque étape, chaque checklist, chaque rôle.
La deuxième vague incluait le CRM (Salesforce) et les outils collaboratifs (Microsoft 365 déjà SaaS mais mal configuré). La troisième vague, la plus délicate, concernait l’ERP. Une analyse approfondie a conduit à opter pour une migration en lift-and-shift vers des VM Azure réservées pour 3 ans, avec un plan de modernisation ultérieur. Cette approche pragmatique a permis de sécuriser le calendrier sans prendre de risques excessifs.
Phase 4 : Optimisation FinOps et pérennisation (Mois 8-12)
La dernière phase a été consacrée à l’optimisation des coûts cloud (rightsizing, réservations, policies d’extinction), à la mise en place d’outils de monitoring et d’alerting, et au transfert complet vers les équipes internes désormais formées et autonomes.
L’optimisation FinOps a généré des gains immédiats : suppression de 28 instances surdimensionnées, mise en place de scaling automatique réduisant les coûts de 22 % en période creuse, achat d’instances réservées sur 1 an pour les workloads stables (économie de 35 % sur ces ressources). Des policies d’extinction automatique ont été configurées pour les environnements de dev/test, réduisant leur coût de 60 %.
Des outils de monitoring (CloudWatch, Azure Monitor) et d’alerting ont été paramétrés pour détecter les anomalies de coûts (augmentation de plus de 15 % sur 7 jours), les dégradations de performance, et les incidents de sécurité. Un dashboard FinOps mensuel a été créé pour le COMEX, traduisant les métriques techniques en impact business.
Résultats obtenus
- 80 % du parc applicatif migré en cloud en 12 mois, contre 15 % après la première année
- Réduction de 30 % des coûts d’infrastructure, grâce à l’approche FinOps et au rightsizing
- Disponibilité améliorée à 99,95 %, contre 99,2 % en environnement on-premise
- Time-to-market réduit de 40 % pour les nouvelles applications métiers
- Équipe IT certifiée : 6 collaborateurs certifiés AWS/Azure, autonomes sur les opérations cloud
- Coûts cloud maîtrisés, stabilisation à 42 K€/mois contre 58 K€ avant optimisation
- Dette technique réduite : décommissionnement de 18 serveurs physiques obsolètes
Au-delà des métriques, la transformation culturelle a été significative. Les équipes ont retrouvé confiance dans leur capacité à délivrer, les métiers ont cessé de contourner la DSI pour leurs nouveaux besoins, et la direction générale a validé une enveloppe d’investissement pluriannuelle pour poursuivre la modernisation.
Les pièges courants de la migration cloud
Migrer sans stratégie claire. Lift-and-shift, re-platforming, re-architecting : chaque application mérite une stratégie de migration adaptée. Tout migrer en lift-and-shift est souvent une fausse économie. Une application legacy monolithique migrée telle quelle en cloud coûtera plus cher qu’on-premise sans apporter les bénéfices attendus (scalabilité, résilience). Selon Forrester, 38 % des entreprises regrettent d’avoir opté pour un lift-and-shift généralisé.
Sous-estimer le volet compétences. Le cloud exige de nouvelles compétences que les équipes on-premise ne possèdent pas naturellement. Un plan de montée en compétences structuré est un investissement indispensable. Infrastructure as Code, conteneurisation, orchestration Kubernetes, observabilité cloud-native : ces compétences ne s’improvisent pas. Le coût d’une certification AWS SAA (1 500 €) est négligeable face au coût d’une migration ratée (plusieurs centaines de milliers d’euros).
Ignorer le FinOps. Sans pilotage actif des coûts cloud, la facture peut exploser rapidement. La mise en place d’une démarche FinOps dès le début du projet est nécessaire. Le cloud transforme les CAPEX en OPEX, ce qui nécessite une nouvelle discipline budgétaire. Une instance EC2 t3.xlarge oubliée active 24/7 coûte 1 200 €/an. Multipliez par une cinquantaine de ressources mal gouvernées, et vous dépassez rapidement le budget.
Négliger la sécurité et la conformité. Migrer en cloud sans revoir le modèle de sécurité expose à des risques majeurs. Les principes on-premise (périmètre de sécurité, firewall centralisé) ne s’appliquent pas tel quel. Le modèle Zero Trust, l’IAM granulaire, le chiffrement par défaut, la traçabilité des accès doivent être repensés. Le RGPD impose également de maîtriser la localisation des données, ce qui nécessite une configuration rigoureuse des régions cloud.
Le rôle clé du management de transition dans la reprise cloud
Un projet cloud bloqué nécessite rarement plus de technologie. Il demande souvent plus de leadership et de méthode. Le manager de transition apporte ce regard extérieur capable de casser les blocages politiques, de challenger les certitudes techniques et de redonner une dynamique projet.
Son premier apport est l’objectivité. Non impliqué dans les décisions passées, il peut diagnostiquer sans langue de bois : architecture inadaptée, compétences insuffisantes, gouvernance défaillante. Il ne cherche pas à protéger sa réputation mais à résoudre les problèmes.
Son deuxième apport est l’expérience transverse. Ayant mené 5, 10 ou 15 migrations cloud dans des contextes variés, il identifie immédiatement les patterns d’échec et les leviers de succès. Il sait qu’un projet cloud sans sponsor exécutif échoue dans 80 % des cas, que l’absence de tests de charge génère des catastrophes en production, que l’optimisation FinOps doit commencer dès le jour 1.
Son troisième apport est la capacité d’exécution. Il ne se contente pas de recommandations PowerPoint. Il prend le rôle de chef de programme, structure la gouvernance, anime les comités, débloque les arbitrages, suit les plannings, escalade les risques. Il transforme une ambition en réalité opérationnelle.
Votre migration cloud est bloquée ? TransiCIO peut vous aider
TransiCIO accompagne les ETI dans la reprise en main de leurs projets de migration cloud. Nos managers de transition apportent l’expertise technique, la méthodologie et le leadership nécessaires pour redéfinir la trajectoire et mener la migration à terme.
Nous intervenons en moyenne pour des missions de 6 à 12 mois, avec un objectif clair : remettre le projet sur rails et transférer l’autonomie aux équipes internes. Nos managers sont tous certifiés cloud (AWS, Azure, GCP), ont piloté au minimum 3 migrations complexes, et maîtrisent les enjeux FinOps, sécurité et conformité.
Pour aller plus loin
Pour aller plus loin
- CTO de transition
- alignement DSI-métiers
- transition d’infogérance
- fusion de systèmes d’information
- audit SI et transformation
- redressement de projet
- management de transition
- Transformation digitale en ETI : par où commencer ?
- DSI de transition et conduite du changement
- Management de transition DSI
Migration cloud bloquée : comment reprendre la main
Face à une migration cloud bloquée, la priorité est de requalifier l’existant, isoler les points de blocage et réordonnancer. Notre pilotage transforme une migration cloud bloquée en trajectoire maîtrisée et mesurable.