Migration Cloud : les 7 erreurs qui coûtent cher

Introduction : pourquoi tant de migrations cloud échouent

Les chiffres sont édifiants. Selon McKinsey, 75% des migrations cloud dépassent le budget initial (dépassement moyen : 23%), et 38% subissent des retards significatifs. Sur trois ans, ces dépassements représentent plus de 100 milliards de dollars d’investissements non planifiés à l’échelle mondiale. Pourtant, la migration cloud n’est plus un sujet nouveau : les entreprises la pratiquent depuis plus d’une décennie. Alors pourquoi les mêmes erreurs se répètent-elles ?

La réponse tient en un mot : sous-estimation. Sous-estimation de la complexité technique, de l’impact organisationnel, des coûts réels, et des compétences nécessaires. Chez Nobori, nous avons accompagné des dizaines de migrations cloud, des PME aux grands groupes, et nous retrouvons systématiquement les mêmes écueils

Cet article détaille les 7 erreurs les plus fréquentes et les plus coûteuses, avec pour chacune des recommandations concrètes issues de notre expérience terrain

Erreur 1 : le Lift & Shift aveugle

Le problème

Le Lift & Shift consiste à déplacer une application telle quelle vers le cloud, sans modification. C’est l’approche la plus rapide et la plus simple, ce qui la rend séduisante. Mais appliquée sans discernement, elle produit les pires résultats

Une application conçue pour tourner sur un serveur physique avec 64 Go de RAM et 16 cœurs n’a aucune raison de bien fonctionner sur une instance cloud équivalente. Les patterns de performance diffèrent : le stockage local n’a pas les mêmes caractéristiques IOPS qu’un EBS, la latence réseau entre composants augmente, les licences logicielles (Oracle, SQL Server) deviennent prohibitives en mode cloud

Résultat typique : la facture cloud est 30 à 50% supérieure au coût de l’infrastructure on-premise, pour des performances identiques voire dégradées. Ce surcoût s’observe principalement sur les applications legacy dimensionnées pour le peak on-premise. Pour des applications cloud-native ou des microservices, le lift & shift peut être neutre voire avantageux à court terme. Le cloud est alors perçu comme un échec, alors que c’est la stratégie de migration qui est en cause

La solution

Appliquer le framework des 7R (Retire, Retain, Rehost, Replatform, Repurchase, Refactor, Relocate) à chaque application. Le Lift & Shift (Rehost) n’est qu’une option parmi 7. Pour chaque application, l’analyse doit prendre en compte la complexité technique, la valeur métier, les dépendances, et le coût de chaque stratégie

Stratégie	Description	Cas d’usage	Coût migration
Retire	Supprimer l’application	Apps obsolètes, doublons	Nul
Retain	Garder on-premise	Dépendances matérielles, conformité	Nul
Rehost	Lift & Shift	Apps stables, faible complexité	Faible
Replatform	Ajustements mineurs	Passage à un service managé (RDS, ElastiCache)	Modéré
Refactor	Rearchitecture significative	Apps stratégiques à forte évolution	Élevé
Repurchase	Passage en SaaS	ERP, CRM, messagerie	Variable

Notre recommandation : investissez 4 à 6 semaines dans une phase de discovery avant toute migration. C’est un investissement modeste qui évite des mois de remédiation coûteuse

Erreur 2 : sous-estimer le réseau

Le problème

On-premise, les composants applicatifs communiquent sur un réseau local avec une latence de l’ordre de la microseconde et une bande passante quasi illimitée. Dans le cloud, la topologie réseau change radicalement : les composants sont distribués sur des sous-réseaux virtuels, les communications passent par des load balancers, des NAT gateways, parfois des passerelles VPN vers le datacenter résiduel

Les applications qui font des milliers d’appels réseau entre composants (appels base de données, appels inter-services, accès à des systèmes de fichiers partagés) subissent une dégradation de performance significative lorsque la latence réseau passe de 0.1ms à 1-5ms par appel

La solution

Cartographier les flux réseau avant la migration. Des outils comme AWS Application Discovery Service ou des solutions open-source comme Weave Scope permettent de visualiser les dépendances et les volumes d’échange. Les applications qui communiquent fortement doivent migrer ensemble, dans la même zone de disponibilité

Dimensionner correctement les liens réseau (Direct Connect, VPN) entre le cloud et le datacenter résiduel. Ne pas sous-estimer les coûts de transfert de données sortantes (egress), qui représentent souvent une surprise sur la première facture cloud

Erreur 3 : ignorer la sécurité dès le départ

Le problème

La sécurité est trop souvent traitée comme un sujet à adresser “après la migration”. Le raisonnement est compréhensible : “migrons d’abord, sécurisons ensuite”. Mais c’est une erreur aux conséquences potentiellement désastreuses

Un environnement cloud mal sécurisé est exposé à Internet par défaut. Un security group trop permissif, un bucket S3 public, des credentials codées en dur dans une image Docker : chacune de ces failles triviales peut conduire à une compromission majeure. Et les attaquants surveillent activement les nouvelles ressources cloud déployées

La solution

Intégrer la sécurité dès le jour 1 de la migration, selon le principe du “Shift Left Security”. Concrètement, cela signifie mettre en place avant toute migration applicative les fondations suivantes :

• Landing Zone sécurisée : multi-comptes (AWS Organizations), garde-fous via Service Control Policies, centralisation des logs (CloudTrail, Config)
• Gestion des identités : SSO fédéré, politique IAM least-privilege, pas de clés d’accès long-terme
• Réseau : segmentation VPC, security groups restrictifs par défaut, inspection du trafic (Network Firewall, WAF)
• Détection : GuardDuty, Security Hub, alertes automatisées vers le SOC

Ces fondations représentent typiquement 3 à 4 semaines de travail, mais elles sont non négociables. Budget type pour une landing zone sécurisée (multi-comptes, networking, IAM, logging) : 30-60K€ selon la complexité, soit 3-4 semaines d’architecture. Le coût de remédiation après un incident est sans commune mesure

Erreur 4 : pas de stratégie FinOps

Le problème

La promesse du cloud est l’élasticité : payer uniquement ce que l’on consomme. En réalité, sans gouvernance financière, le cloud est un système à consommation illimitée où personne n’est responsable de la facture

Nous observons systématiquement le même schéma : les 6 premiers mois de migration se concentrent sur le technique (faire fonctionner les applications), et la facture cloud gonfle sans contrôle. Quand le sujet FinOps émerge enfin, la dette d’optimisation est considérable

La solution

Mettre en place une gouvernance FinOps dès le début de la migration, pas après. Les actions minimales comprennent la mise en place d’un tagging obligatoire sur toutes les ressources (projet, environnement, propriétaire, centre de coûts), la configuration d’alertes budgétaires par compte et par projet, un reporting hebdomadaire des dépenses par équipe, et l’identification précoce des workloads éligibles aux Reserved Instances ou Savings Plans

Plan d’action FinOps en 4 semaines (à lancer en parallèle de la phase de discovery, pas après) :

Semaine	Action	Résultat attendu
S1	Définir la stratégie de tagging obligatoire (4 tags minimum : project, environment, owner, cost-center) et l’appliquer via SCP/policy as code	Toute nouvelle ressource est taguée à la création
S2	Configurer AWS Cost Anomaly Detection (ou équivalent Azure/GCP) avec alertes sur dépassement +20% vs baseline	Détection automatique des dérives
S3	Construire un dashboard par équipe (Cost Explorer + filtres tags) accessible à chaque tech lead	Visibilité hebdomadaire sur la consommation
S4	Programmer la revue FinOps mensuelle (1h, 5 KPIs : coût total, coût/transaction, coût par environnement, top 5 services, ressources orphelines)	Gouvernance récurrente sans tour d’ivoire

Le FinOps n’est pas un frein à la migration, c’est un accélérateur : il donne la visibilité nécessaire pour prendre les bonnes décisions d’investissement. Pour aller plus loin (unit economics, showback, FinOps as code), consultez nos articles FinOps : réduire vos coûts cloud et FinOps 2.0 : ingénierie de la valeur cloud

Erreur 5 : négliger la formation des équipes

Le problème

Migrer l’infrastructure vers le cloud sans former les équipes qui la gèrent, c’est donner les clés d’une Formule 1 à quelqu’un qui a le permis B. Les compétences on-premise ne se transposent pas automatiquement au cloud : les modèles de sécurité, de réseau, de stockage et de facturation sont fondamentalement différents

Le résultat : des équipes qui reproduisent des patterns on-premise dans le cloud (serveurs surdimensionnés “au cas où”, absence d’auto-scaling, stockage sur disques locaux), des erreurs de configuration coûteuses (instances non étiquetées, environnements de développement allumés 24/7), et une frustration qui alimente la résistance au changement

La solution

Investir dans la formation avant et pendant la migration. Un plan de montée en compétences typique comprend trois niveaux

Fondamentaux (toute l’équipe) : concepts cloud, modèle de responsabilité partagée, navigation dans la console, compréhension de la facturation. Durée : 2 à 3 jours par personne

Opérationnel (équipes Ops/SRE) : infrastructure as code (Terraform, CloudFormation), CI/CD, monitoring cloud-native, sécurité opérationnelle. Durée : 5 à 10 jours, combinant formation et pratique sur des cas réels

Architecture (tech leads, architectes) : design patterns cloud-native, Well-Architected Framework, optimisation des coûts, haute disponibilité, disaster recovery. Durée : 3 à 5 jours

L’effort de formation et d’accompagnement au changement représente typiquement 8 à 15% du budget total de migration, décomposé en 3 postes :

Poste	Part typique du budget migration	Contenu
Certifications techniques	3-5%	Formations éditeurs (AWS/Azure/GCP), examens, montée en compétence Ops
Accompagnement au changement	3-7%	Conduite du changement, ateliers métiers, communication interne
Acculturation continue	2-3%	Communautés de pratique, brown bags, partages d’expérience post-migration (sur les 12 mois suivants)

C’est un investissement significatif mais largement rentabilisé par les erreurs coûteuses qu’il évite. Les organisations qui ne budgètent que les certifications techniques (3-5%) sous-estiment systématiquement la facture réelle

Erreur 6 : big bang vs. migration progressive

Le problème

La tentation du “big bang” – migrer toutes les applications en une seule vague – est forte. Elle promet de réduire la durée du projet, de limiter la période de coexistence on-premise/cloud, et de simplifier la gouvernance. En réalité, elle multiplie les risques

Un big bang concentre tous les risques sur un même créneau : si une application critique échoue pendant la migration, elle entraîne potentiellement toutes les autres. La pression est maximale sur les équipes, les tests sont bâclés faute de temps, et le plan de rollback est souvent théorique faute d’avoir été testé

La solution

Adopter une approche progressive par vagues, en commençant par les applications les moins critiques et les plus simples

Vague 0 – Fondations (4-8 semaines) : Landing Zone, réseau, sécurité, identités, monitoring. Aucune application n’est migrée, mais l’infrastructure d’accueil est prête et validée

Vague 1 – Applications pilotes (4-6 semaines) : 3 à 5 applications non critiques (environnements de développement, outils internes, sites vitrines). L’objectif est de valider le processus de migration, pas de migrer du volume

Vagues 2 à N – Montée en puissance (itérations de 4-6 semaines) : chaque vague migre un lot d’applications de criticité croissante. Les leçons de chaque vague alimentent la suivante. La capacité de migration s’accélère naturellement à mesure que les équipes gagnent en expérience

Cette approche prend plus de temps au total, mais elle est plus prévisible, moins risquée et plus économique que le big bang, car les erreurs sont détectées tôt, sur des applications non critiques

Erreur 7 : pas de plan de rollback

Le problème

Aucune migration ne se déroule exactement comme prévu. Des dépendances non identifiées, des performances dégradées, des problèmes de compatibilité, des incidents de production : les surprises sont inévitables. Sans plan de rollback, l’équipe se retrouve dans une situation impossible : avancer dans l’incertitude ou tout arrêter sans savoir comment revenir en arrière

Nous avons vu des clients perdre plusieurs jours de production parce que la migration d’une base de données avait échoué et qu’aucune procédure de retour arrière n’avait été prévue. La base on-premise avait été désactivée, les sauvegardes n’étaient pas exploitables dans le délai requis, et la nouvelle base cloud présentait des corruptions

La solution

Chaque application migrée doit disposer d’un plan de rollback documenté, testé et réalisable dans un délai défini. Les éléments clés comprennent les conditions de déclenchement du rollback (critères objectifs : seuil de latence, taux d’erreur, indisponibilité), le mécanisme technique du retour arrière (basculement DNS, réactivation de l’infrastructure on-premise, restauration de la base de données), et la durée maximale du rollback (typiquement inférieure à 4 heures pour les applications critiques)

Pour les bases de données, la stratégie de rollback est particulièrement critique. Nous recommandons une période de coexistence pendant laquelle les deux bases (source et cible) sont synchronisées. Des outils comme AWS DMS (Database Migration Service) ou Debezium permettent cette réplication continue, offrant un rollback instantané tant que la synchronisation est active

La règle est simple : si vous ne pouvez pas revenir en arrière, vous n’êtes pas prêt à migrer

Synthèse : les 7 erreurs et leurs antidotes

Erreur	Impact	Antidote
Lift & Shift aveugle	Surcoût de 30-50%	Framework 7R, phase de discovery
Sous-estimation du réseau	Dégradation des performances	Cartographie des flux, dimensionnement
Sécurité après la migration	Exposition aux risques	Landing Zone sécurisée dès le jour 1
Absence de stratégie FinOps	Facture incontrôlée	Tagging, alertes, reporting dès le départ
Manque de formation	Erreurs opérationnelles	Plan de formation à 3 niveaux
Migration big bang	Risque maximal concentré	Migration progressive par vagues
Pas de plan de rollback	Impossible retour arrière	Plan documenté, testé, avec délai défini

Conclusion

Une migration cloud réussie n’est pas un exploit technique : c’est le résultat d’une préparation rigoureuse, d’une exécution méthodique et d’une gouvernance continue. Les 7 erreurs décrites dans cet article ne sont pas théoriques – nous les observons régulièrement, y compris chez des organisations techniquement matures

La bonne nouvelle, c’est qu’elles sont toutes évitables. L’investissement dans la phase de préparation (discovery, formation, sécurité, FinOps) représente typiquement 15 à 20% du budget total de migration, mais il évite des surcoûts et des retards qui peuvent dépasser le budget initial de la migration elle-même

Le cloud est un formidable accélérateur pour les organisations qui l’abordent avec méthode. C’est un gouffre pour celles qui confondent vitesse et précipitation

Sources et méthodologie

• McKinsey, Cloud-migration opportunity 2024, 75% des migrations dépassent le budget initial (dépassement moyen : 23%), 38% subissent des retards. Échantillon : enquête McKinsey auprès d’entreprises ayant déjà entrepris des migrations cloud. Source publique et gratuite (vs Gartner paywall).
• Le surcoût lift & shift de 30-50% est observé principalement sur les applications legacy dimensionnées pour le peak on-premise (retour de missions Nobori, 2022-2025).
• Le budget landing zone (30-60K€) est une fourchette basée sur nos missions d’architecture cloud sécurisée auprès d’ETI (50 à 500 utilisateurs cloud).
• Les 7 erreurs identifiées proviennent de l’analyse de 50+ missions de migration cloud accompagnées par Nobori depuis 2020.
• L’effort de formation (8-15% du budget) inclut les certifications techniques, la conduite du changement et l’accompagnement post-migration

Nobori accompagne les ETI et grands comptes dans leurs migrations cloud, de la stratégie à l’exécution. Découvrir notre offre Platform Engineering

Pour aller plus loin

• Découvrez notre expertise Platform Engineering et nos méthodologies de migration éprouvées
• Explorez nos cas clients, notamment dans la finance où les exigences de conformité et de résilience ajoutent une couche de complexité aux migrations cloud
• Consultez notre article sur le FinOps pour approfondir la gouvernance financière du cloud