Migration cloud : les 5 erreurs qui coûtent des millions

“On migre dans le cloud, ça va réduire nos coûts.” Non.

Cette phrase, je l’entends au moins une fois par semaine. Et à chaque fois, je sais que l’entreprise en face va droit dans le mur. Parce que la migration cloud ne réduit pas les coûts par magie. Mal exécutée, elle les explose.

Sur les 3 dernières années, nous avons accompagné ou audité plus de 30 migrations cloud. Les erreurs se répètent avec une régularité déprimante. Voici les 5 qui coûtent le plus cher.

Erreur n°1 : Le lift-and-shift aveugle

Le lift-and-shift, c’est prendre vos serveurs on-premise et les déplacer tels quels dans le cloud. C’est la stratégie la plus rapide. C’est aussi la plus stupide dans 80% des cas.

Pourquoi c’est un piège :

• Vos VMs on-premise sont surdimensionnées ? Elles seront surdimensionnées dans le cloud aussi, sauf que maintenant vous payez à l’heure
• Votre application n’utilise pas les services managés ? Vous payez pour gérer vous-même ce que le cloud provider fait mieux et moins cher
• Votre architecture n’est pas élastique ? Vous payez 24/7 pour un pic de charge qui arrive 2 heures par jour

Le cas typique : une entreprise migre 50 VMs en lift-and-shift. Facture on-premise : 15K euros/mois. Facture cloud après migration : 35K euros/mois. Le DSI est viré 6 mois plus tard.

Ce qu’il faut faire : avant de migrer quoi que ce soit, catégorisez vos workloads. Certains méritent un lift-and-shift (les bases de données stables, par exemple). D’autres nécessitent une refactorisation. Et certains devraient tout simplement être retirés.

Erreur n°2 : Ignorer le FinOps dès le jour 1

Le FinOps, c’est la discipline qui consiste à optimiser les coûts cloud en continu. Et la plupart des entreprises n’y pensent que quand la première facture tombe.

Les sources de gaspillage les plus fréquentes :

• Ressources orphelines : des disques EBS détachés, des snapshots oubliés, des load balancers qui ne pointent vers rien. Sur un compte AWS moyen, c’est 15 à 25% de gaspillage.
• Surdimensionnement : des instances m5.xlarge pour des workloads qui tournent sur un t3.small. Parce que “on a pris large au cas où”.
• Absence de reserved instances : payer le prix on-demand pour des workloads stables qui tournent 24/7, c’est jeter 30 à 50% de votre budget par la fenêtre.
• Environnements de dev/staging qui tournent le week-end et la nuit sans que personne ne s’en serve.

Notre constat : sur chaque audit FinOps que nous réalisons, nous trouvons en moyenne 30% d’économies sans aucun impact sur la performance. 30%. Sur des factures mensuelles de 50K à 200K euros, faites le calcul.

Erreur n°3 : Pas de stratégie multi-compte

Tout mettre dans un seul compte cloud, c’est comme mettre toute votre entreprise dans un seul bureau sans cloisons. Pas de séparation, pas de visibilité, pas de contrôle.

Les problèmes concrets :

• Explosion des droits : tout le monde a accès à tout. Un développeur junior qui supprime une base de données de production, on a vu.
• Impossible de ventiler les coûts : qui consomme quoi ? Mystère.
• Blast radius maximum : un incident touche potentiellement tout le SI.
• Compliance impossible : comment prouver l’isolation des données si tout est dans le même compte ?

L’architecture qui fonctionne : un compte management, un compte par environnement (dev/staging/prod), un compte shared services, un compte sécurité/audit. Avec des Service Control Policies qui empêchent les bêtises.

Erreur n°4 : Sous-estimer la sécurité cloud

“Le cloud est sécurisé”. Oui, l’infrastructure du cloud provider est sécurisée. Mais la configuration de votre environnement, c’est votre responsabilité. Et c’est là que ça dérape.

Les failles les plus courantes :

• Buckets S3 publics : en 2026, ça arrive encore. Des bases de données clients exposées sur Internet parce que quelqu’un a coché la mauvaise case.
• Secrets en dur dans le code : des clés API AWS commitées sur GitHub. En moyenne, il faut 4 minutes à un bot pour les trouver et les exploiter.
• Pas de chiffrement : données au repos non chiffrées, transit en HTTP, certificats expirés.
• IAM trop permissif : des rôles avec *:* parce que c’est plus simple. C’est aussi plus simple pour un attaquant.

Le minimum vital : activez GuardDuty, configurez Config Rules, mettez en place un CSPM, et auditez vos IAM policies avec IAM Access Analyzer. Ce n’est pas optionnel.

Erreur n°5 : Pas de plan de sortie

Personne n’en parle, mais c’est crucial : qu’est-ce qui se passe si vous devez quitter votre cloud provider ?

Les raisons peuvent être multiples : explosion des coûts, changement de politique tarifaire, exigences réglementaires de souveraineté, ou simplement un meilleur deal ailleurs.

Le problème : plus vous utilisez de services propriétaires (DynamoDB, Lambda, Aurora, Cloud Functions), plus vous êtes verrouillé. Et le coût de sortie augmente avec le temps.

La bonne approche :

• Documenter les dépendances par service cloud utilisé
• Privilégier les standards ouverts quand c’est possible (Kubernetes plutôt qu’ECS, PostgreSQL plutôt que DynamoDB)
• Tester le plan de sortie au moins une fois par an, même partiellement
• Négocier les conditions de sortie dans le contrat initial

La check-list avant toute migration cloud

Avant de migrer le moindre workload, validez ces 7 points :

1. Inventaire complet des workloads avec classification (retain, retire, rehost, replatform, refactor)
2. Estimation des coûts cloud avec au moins 3 scénarios (optimiste, réaliste, pessimiste)
3. Architecture multi-compte définie et validée
4. Baseline sécurité configurée (IAM, chiffrement, monitoring, alertes)
5. Stratégie FinOps avec outils de monitoring des coûts dès le premier jour
6. Plan de formation pour les équipes (le cloud, ça s’apprend)
7. Plan de rollback pour chaque phase de migration

Les chiffres qui comptent

• 60% des migrations cloud dépassent leur budget initial de plus de 30%
• Le coût moyen de correction d’une migration mal planifiée : 2 à 5 fois le coût de la migration initiale
• Les entreprises avec une pratique FinOps mature dépensent 20 à 35% de moins que les autres à workload équivalent
• Le délai moyen pour qu’une entreprise atteigne l’optimisation de ses coûts cloud : 18 à 24 mois après la migration

La vérité que personne ne veut entendre

La migration cloud n’est pas un projet IT. C’est une transformation organisationnelle. Elle change la façon dont vous provisionnez, sécurisez, budgétez et opérez votre infrastructure. Si vous la traitez comme un simple déménagement de serveurs, vous allez payer très cher pour des résultats décevants.

FAQ

Le cloud est-il vraiment moins cher que le on-premise ?

Pas automatiquement. Pour des workloads stables et prévisibles, le on-premise peut être moins cher. L’avantage du cloud réside dans l’élasticité, la vitesse de provisionnement et l’accès aux services managés. Le gain financier vient de l’optimisation continue, pas du simple déplacement.

Combien de temps prend une migration cloud bien menée ?

Pour une entreprise de taille moyenne, comptez 12 à 24 mois pour une migration complète. Les 3 premiers mois sont de la planification pure. Les entreprises qui bâclent cette phase paient le prix fort ensuite.

Faut-il un cloud architect dédié ?

Oui, c’est indispensable. Un cloud architect senior coûte cher, mais une migration mal architecturée coûte beaucoup plus. Si vous ne pouvez pas recruter, faites appel à un cabinet spécialisé pour la phase d’architecture et de planification.

AWS, Azure ou GCP : comment choisir ?

Cela dépend de votre contexte. AWS pour l’écosystème le plus large, Azure pour l’intégration Microsoft, GCP pour les workloads data et IA. Mais le choix du provider est souvent moins important que la qualité de l’architecture et de l’exécution.