Migration Cloud : les 7 erreurs qui coûtent cher

Introduction : pourquoi tant de migrations cloud échouent

Les chiffres sont édifiants. Selon Gartner, 83% des projets de migration cloud dépassent le budget prévu, et 40% subissent des retards significatifs. 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 coeurs 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. 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. 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.

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 une analyse approfondie de cette discipline, consultez notre article dédié sur le FinOps et la réduction des coûts 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’investissement en formation représente typiquement 3 à 5% du budget total de migration. C’est marginal par rapport aux économies qu’il génère en évitant les erreurs coûteuses.

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 lecons 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.

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 missions dans le secteur de 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