L’arnaque intellectuelle du multi-cloud
Je sais. Ce titre va me valoir des commentaires enflammés. Tant mieux.
Le multi-cloud — utiliser simultanément AWS, GCP et Azure en production — est présenté par les cabinets de conseil et les éditeurs comme la stratégie cloud de référence. “Évitez le vendor lock-in”, “Diversifiez vos risques”, “Best of breed pour chaque service”.
Après avoir accompagné plus de 30 migrations cloud, je peux vous dire ceci : le multi-cloud est l’une des erreurs stratégiques les plus coûteuses que font les DSI en 2026. Pas toujours, mais dans la grande majorité des cas.
Les 3 arguments fallacieux du multi-cloud
Argument n°1 : “Éviter le vendor lock-in”
C’est l’argument massue. Et c’est un fantasme.
Le vrai vendor lock-in ne vient pas de votre provider cloud. Il vient de l’utilisation de services managés propriétaires : DynamoDB, BigQuery, Azure Functions, AWS Lambda, Cloud Spanner.
Être sur 2 clouds ne résout rien si vous utilisez DynamoDB sur AWS et Cosmos DB sur Azure. Vous êtes doublement locked-in, pas libéré.
Pour éviter le lock-in, il faut utiliser des technologies portables (PostgreSQL, Kubernetes, Kafka). Et ça, on peut le faire sur un seul cloud.
Le vrai coût du lock-in fantasmé ? Une migration d’un cloud à l’autre coûte entre 6 mois et 2 ans de travail. Combien d’entreprises l’ont réellement fait ? Quasiment aucune. Le lock-in théorique n’est presque jamais un problème réel.
Argument n°2 : “Diversifier les risques”
“Si AWS tombe, on a Azure en backup.”
Soyons sérieux. AWS a un uptime de 99,99% sur ses services core. Les pannes majeures (région entière indisponible) arrivent 1 à 2 fois par an et durent quelques heures.
Pour vous “protéger” contre ces quelques heures, vous allez :
- Dupliquer votre infrastructure sur 2 clouds
- Maintenir 2 pipelines de déploiement
- Former vos équipes sur 2 plateformes
- Payer 2 factures avec des modèles de pricing différents
- Gérer la synchronisation des données entre 2 clouds
Le coût de cette “assurance” ? 2 à 3x le budget cloud d’une stratégie single-cloud. Pour se protéger contre un risque qui représente quelques heures par an.
C’est comme payer 3 fois le prix de votre maison pour avoir une maison de secours en cas de tremblement de terre, alors que vous vivez en Picardie.
Argument n°3 : “Best of breed”
“On prend le ML de GCP, le compute d’AWS, et les outils Microsoft d’Azure.”
En théorie, c’est rationnel. En pratique, c’est un cauchemar opérationnel.
Chaque cloud a son propre système de :
- IAM (gestion des identités et des accès)
- Networking (VPC, peering, firewall)
- Monitoring (CloudWatch vs Cloud Monitoring vs Azure Monitor)
- Billing (modèles de pricing incompatibles)
- CLI et SDK (AWS CLI vs gcloud vs az)
Vos ingénieurs doivent maîtriser 3 plateformes au lieu d’une. Votre dette de compétences explose. Et les interactions inter-cloud (données qui transitent entre AWS et GCP) ajoutent de la latence, de la complexité réseau, et des coûts d’egress considérables.
Les vrais coûts cachés du multi-cloud
J’ai fait l’exercice de chiffrage avec un client du secteur bancaire qui voulait passer en multi-cloud. Voici les coûts que personne ne mentionne :
Coûts d’egress inter-cloud
Transférer des données entre AWS et GCP coûte entre 0,08 et 0,12 dollar par Go. Pour une entreprise qui transfert 10 To par mois entre clouds, c’est 800 à 1 200 dollars par mois juste en transfert de données. Et ça scale linéairement.
Coûts de compétences
Former une équipe de 5 ingénieurs sur un deuxième cloud provider prend 3 à 6 mois et coûte entre 50 000 et 100 000 euros (formations, certifications, temps improductif).
Recruter des profils multi-cloud ? La prime salariale est de 15 à 25% par rapport à un spécialiste single-cloud. Et ils sont plus rares.
Coûts d’outillage
Terraform, oui. Mais les modules Terraform sont spécifiques à chaque provider. Un module AWS EC2 ne se transpose pas à GCP Compute Engine. Vous devez maintenir 2 codebases d’infrastructure.
Les outils d’observabilité doivent être cross-cloud : Datadog, New Relic, ou Grafana Cloud. Coût additionnel de 30 000 à 100 000 euros par an selon la taille.
Coût de la coordination
Qui décide quel workload va sur quel cloud ? Comment arbitrer quand le même service existe sur les deux ? Qui gère les incidents quand le problème est à la frontière entre deux clouds ?
Ce coût organisationnel est le plus insidieux. J’ai vu des comités d’architecture passer 50% de leur temps à arbitrer des questions multi-cloud au lieu de résoudre des problèmes business.
Quand le multi-cloud fait (vraiment) sens
Je ne dis pas que le multi-cloud est toujours une erreur. Il y a 3 cas légitimes :
1. Contraintes réglementaires
Certains secteurs (bancaire, santé, défense) ont des exigences de souveraineté des données ou de résilience qui imposent la diversification. Si le régulateur exige que vos données soient répliquées chez 2 providers cloud distincts, vous n’avez pas le choix.
2. Fusion-acquisition
Quand vous rachetez une entreprise qui est sur Azure alors que vous êtes sur AWS, vous devenez multi-cloud de facto. La question n’est pas “faut-il être multi-cloud” mais “à quelle vitesse consolider”.
3. SaaS best-of-breed (le vrai multi-cloud)
Utiliser Snowflake (qui tourne sur AWS), MongoDB Atlas (sur GCP), et votre infra principale sur Azure. Ce n’est pas du multi-cloud au sens opérationnel — ce sont des SaaS managés qui se trouvent être sur des clouds différents. Le fardeau opérationnel est chez le fournisseur SaaS, pas chez vous.
C’est la seule forme de “multi-cloud” que je recommande activement.
La stratégie qui fonctionne : single-cloud + portabilité
Voici l’approche que je recommande à 90% des entreprises :
1. Choisissez UN cloud provider principal
Le choix dépend de votre contexte :
- AWS : choix par défaut, écosystème le plus large, meilleur pour l’e-commerce et le SaaS
- GCP : meilleur pour le data/ML, intégration Google Workspace, pricing plus simple
- Azure : incontournable si vous êtes un écosystème Microsoft (AD, Office 365, .NET)
2. Utilisez des technologies portables pour les couches critiques
- Kubernetes au lieu de ECS/Cloud Run/AKS pour le compute (portable)
- PostgreSQL/MySQL au lieu de DynamoDB/Spanner/Cosmos (portable)
- Kafka/RabbitMQ au lieu de SQS/Pub-Sub/Service Bus (portable)
- Terraform pour l’infrastructure as code (multi-provider)
3. Gardez la possibilité de migrer sans en payer le prix maintenant
La portabilité théorique est suffisante. Vous n’avez pas besoin de faire tourner votre app sur 2 clouds en parallèle pour prouver qu’elle est portable. Vous avez besoin de savoir que si un jour vous devez migrer, ce sera faisable en 6 mois.
4. Utilisez les services managés propriétaires quand le ROI est évident
BigQuery pour l’analytics ? Oui, le rapport performance/coût est imbattable. Lambda pour des fonctions événementielles simples ? Oui, c’est plus pragmatique que de containeriser chaque micro-fonction.
Le lock-in partiel sur des services à fort ROI est un choix rationnel, pas une erreur.
Le test décisif
Avant de valider une stratégie multi-cloud, posez ces 3 questions :
- Quel problème business concret le multi-cloud résout-il ? (pas technique, business)
- Avez-vous chiffré le coût total (egress, compétences, outillage, coordination) ?
- Avez-vous l’équipe pour l’opérer ? (minimum 8-10 ingénieurs cloud pour gérer 2 providers correctement)
Si une seule réponse est floue, restez en single-cloud. Vous économiserez du temps, de l’argent, et de la santé mentale.
FAQ
Mon DSI insiste pour du multi-cloud “par principe de précaution”. Comment le convaincre ?
Chiffrez. Demandez un budget détaillé pour la stratégie multi-cloud vs single-cloud sur 3 ans. Incluez les coûts de formation, recrutement, outillage, et egress. La différence de 2 à 3x est généralement suffisante pour recentrer la discussion sur les besoins réels plutôt que sur les principes théoriques.
Terraform suffit-il pour être cloud-agnostique ?
Non. Terraform permet de décrire l’infrastructure de plusieurs clouds avec le même langage (HCL), mais les modules sont spécifiques à chaque provider. Un module AWS n’est pas utilisable sur GCP. La portabilité réelle vient des choix applicatifs (Kubernetes, PostgreSQL, etc.), pas de l’outil d’IaC.
Et si AWS augmente ses prix de 50% demain ?
C’est l’argument du lock-in poussé à l’extrême. En pratique, les cloud providers sont en concurrence féroce et les prix baissent régulièrement. Une augmentation brutale de 50% enverrait la moitié de leurs clients chez la concurrence. C’est un scénario qui ne sert qu’à justifier un investissement multi-cloud disproportionné.
Le multi-cloud est-il pertinent pour les grandes entreprises du CAC 40 ?
Pour les très grandes organisations (10 000+ collaborateurs, équipes cloud de 50+ personnes), le multi-cloud peut faire sens si le budget et les compétences sont disponibles. Mais même au CAC 40, la plupart des entreprises seraient plus efficaces avec un cloud principal et des SaaS best-of-breed, plutôt qu’avec une infrastructure répartie sur 3 hyperscalers.