TL;DR
Le multi-cloud n’est pas un objectif. C’est un moyen, et un moyen coûteux. Il devient pertinent quand il sert une exigence documentée : continuité d’activité contractuelle, obligation réglementaire (NIS2, DORA), accès à un service unique chez un fournisseur, ou pouvoir de négociation tangible. Quatre architectures concurrentes coexistent (actif-passif, actif-actif, distribué par service, multi-souverain). Aucune n’est universellement supérieure. Les couches d’abstraction (Kubernetes, Terraform, GitOps) réduisent une partie de la complexité, jamais sa totalité. Une exit strategy se mesure à des tests réels, pas à des slides.
Définir le multi-cloud sans jargon
Le multi-cloud désigne l’utilisation simultanée et coordonnée de plusieurs fournisseurs IaaS ou PaaS pour héberger des charges de production. Trois précisions s’imposent.
D’abord, multi-cloud ne signifie pas hybride. Un environnement hybride combine un cloud public et une infrastructure on-premise. Multi-cloud combine plusieurs clouds publics. Les deux peuvent coexister.
Ensuite, multi-cloud ne signifie pas avoir un compte chez plusieurs fournisseurs. Une organisation peut consommer du stockage chez AWS pour la sauvegarde et de la production chez Azure : c’est de l’utilisation parallèle, pas du multi-cloud au sens architectural. Le multi-cloud commence quand au moins une charge applicative dépend (par conception ou par bascule) de deux fournisseurs.
Enfin, multi-cloud ne signifie pas indépendance totale. Les services managés (Cloud SQL, RDS, Cosmos DB, BigQuery, Redshift, Cloud Run, Lambda) restent propriétaires. Le multi-cloud n’élimine pas le lock-in fonctionnel : il le distribue.
Les 4 raisons légitimes du multi-cloud
Continuité d’activité
Un fournisseur hyperscaler isolé reste un point de défaillance unique. Les pannes régionales documentées (incidents majeurs AWS us-east-1, Azure East US, OVH SBG2) rappellent que la disponibilité contractuelle (souvent 99,9 %) n’élimine pas les incidents corrélés. Pour une activité dont la tolérance à l’indisponibilité est inférieure à 4 heures par an, déployer le plan de reprise sur un second fournisseur fait sens.
Cette logique se renforce dans les secteurs régulés. DORA (Digital Operational Resilience Act), applicable aux entités financières depuis janvier 2025, exige une stratégie de sortie documentée des fournisseurs critiques de services TIC [1]. La directive NIS2, transposée en France par la loi 2024-364, impose aux entités essentielles et importantes des plans de continuité testés [2].
Conformité
Certaines obligations réglementaires imposent ou recommandent une distribution géographique ou juridique des charges. Le règlement européen sur les données (Data Act, en application depuis 2025) facilite la portabilité entre fournisseurs cloud et encadre les frais de sortie [3]. Pour des données sensibles soumises à des qualifications nationales (SecNumCloud en France, qualifications BSI en Allemagne, ENS au niveau espagnol), un cloud souverain peut être obligatoire pour une partie du périmètre, tandis qu’un hyperscaler reste pertinent pour le reste.
Best-of-breed
Aucun fournisseur n’est leader sur toutes les briques. Google Cloud reste fort sur l’analytique (BigQuery, Vertex AI), AWS sur la largeur de catalogue, Azure sur l’intégration Active Directory et Office 365, OVHcloud sur l’hébergement bare-metal européen. Une architecture qui utilise un service unique non substituable peut justifier un déploiement secondaire chez un autre fournisseur pour les autres charges.
Pouvoir de négociation
À partir d’un certain volume (généralement un committed spend annuel à 7 chiffres), un client peut négocier des remises significatives. Disposer d’une capacité technique réelle (pas seulement déclarative) à basculer une partie des charges chez un concurrent constitue un levier mesurable. Cela suppose toutefois que l’exit strategy soit prête, sinon le levier est creux.
Les 4 mauvaises raisons
Peur diffuse du vendor lock-in
Le lock-in est réel mais souvent surévalué. Une application bien conçue (12-factor, conteneurisée, IaC, stateless quand possible) est portable au niveau compute. Le verrou se situe sur les services managés (bases SQL managées avec extensions propriétaires, files de messages, fonctions, IAM). Multi-clouder une application pour éviter un lock-in non identifié coûte plus cher que payer la migration le jour où elle devient nécessaire.
Mimétisme
“Les concurrents font du multi-cloud” n’est pas une raison. Examiner pourquoi ils le font, oui.
R&D distribuée par défaut
Laisser chaque équipe choisir son fournisseur produit un patchwork ingérable. Multi-cloud doit être une décision d’architecture, pas une conséquence du shadow IT.
Coûts mal compris
Le multi-cloud est plus cher qu’un cloud unique. Pas parfois : structurellement. Coûts de duplication (stockage, sauvegardes), de transfert (egress), d’expertise (deux équipes à former ou une équipe transverse), d’outillage (FinOps, observabilité, sécurité). Toute justification doit intégrer ces coûts.
Architecture multi-cloud : 3 modèles
Actif-passif
Un cloud principal porte la production, un cloud secondaire héberge un environnement de bascule, parfois en cold standby (infrastructure provisionnée mais éteinte) ou en warm standby (capacité réduite, démarrage en quelques minutes). Modèle le moins coûteux, RTO de quelques heures, RPO selon la fréquence de réplication.
Cas d’usage typique : continuité réglementaire, où le secondaire ne doit pas absorber la charge nominale mais doit pouvoir prendre le relais en moins de 4 heures. La complexité opérationnelle reste contenue : un seul cloud porte la charge nominale, le second reste figé en miroir périodique. Les coûts de duplication se limitent au stockage (RPO bas) et à une capacité compute réduite. Le risque principal de ce modèle est la dérive silencieuse du secondaire : sans test régulier, la bascule échoue le jour où elle compte (versions logicielles désynchronisées, secrets non répliqués, configurations DNS oubliées).
Actif-actif
Les deux clouds servent du trafic en production simultanément. Routage DNS pondéré ou anycast, réplication bidirectionnelle des données, sessions partagées. Modèle le plus coûteux et le plus complexe. RTO proche de zéro, RPO également faible.
Cas d’usage : services à très forte exigence de disponibilité (paiement, télécoms, plateformes critiques). À réserver aux applications dont l’indisponibilité coûte plus que la complexité. La réplication bidirectionnelle pose des défis spécifiques : conflits d’écriture, cohérence eventuelle vs forte, gestion des sessions inter-cloud, latence des appels croisés. Le pattern CRDT (Conflict-free Replicated Data Types) ou les bases multi-master globales (Spanner, Cosmos DB multi-region) répondent à une partie du besoin mais introduisent leurs propres contraintes (coût, lock-in fournisseur).
Distribué par service
Chaque service applicatif vit chez un fournisseur, choisi pour ses caractéristiques (proximité utilisateurs, conformité, capacité spécifique). L’analyse big data chez Google Cloud, le front et l’auth chez AWS, la bureautique et l’IAM chez Azure. Modèle qui maximise le best-of-breed mais qui multiplie les surfaces d’attaque, les contrats et les flux inter-cloud.
À utiliser uniquement quand chaque déploiement correspond à un service non substituable. Les flux inter-cloud génèrent un poste de coût souvent sous-estimé (egress, latence, transit) et compliquent l’observabilité : tracer une transaction qui traverse trois fournisseurs nécessite une corrélation par trace_id homogène (OpenTelemetry) et des outils de monitoring qui collectent depuis plusieurs sources.
Matrice de décision rapide
Pour orienter le choix : RTO inférieur à 15 minutes plus charges critiques plus budget conséquent égale actif-actif. RTO 1 à 4 heures plus exigence réglementaire de continuité égale actif-passif. Services non substituables hébergés chez plusieurs fournisseurs égale distribué par service. Les trois modèles peuvent coexister dans une même organisation, sur des périmètres différents.
Couche d’abstraction : ce qui marche et ce qui ne marche pas
Ce qui marche
Kubernetes constitue le plus petit dénominateur commun sérieux. Un workload containerisé tourne sur EKS (AWS), GKE (Google), AKS (Azure), OVHcloud Managed Kubernetes ou Scaleway Kapsule avec des variations mineures. Helm et les opérateurs CNCF (cert-manager, external-dns, ingress-nginx) sont portables [4].
Terraform (ou OpenTofu, son fork sous licence MPL) gère l’IaC multi-provider de façon homogène, avec un fournisseur officiel par hyperscaler et des providers communautaires pour OVHcloud et Scaleway. Combiné à GitOps (Flux, ArgoCD), il offre une chaîne de déploiement reproductible.
Voir l’article dédié sur Kubernetes en production : sécurité et observabilité 2026 pour le détail.
Ce qui ne marche pas
Les services PaaS managés ne s’abstraient pas. Une application qui dépend de DynamoDB ne tourne pas tel quel sur Cosmos DB ou Firestore. Les abstractions universelles (Crossplane, Pulumi multi-provider avec interfaces communes) couvrent les ressources d’infrastructure (compute, stockage, réseau) mais buttent sur les services différenciants. Plus une équipe veut tout abstraire, plus elle redéveloppe l’équivalent d’un cloud privé : ce n’est plus du multi-cloud, c’est du sur-cloud.
L’IAM est l’autre angle mort. AWS IAM, Azure Entra ID et Google Cloud IAM ne sont pas isomorphes. Une politique de sécurité unifiée passe par une couche tierce (Okta, Ping Identity, Keycloak en self-hosted) ou par des conventions strictes de mapping.
Exit strategy hyperscaler
Une exit strategy n’est pas un document : c’est une capacité opérationnelle prouvée. Quatre exigences minimales.
RPO et RTO documentés
Pour chaque charge critique, définir le Recovery Point Objective (perte de données maximale acceptable) et le Recovery Time Objective (durée maximale d’indisponibilité). Ces valeurs orientent l’architecture : un RTO de 15 minutes impose actif-actif ou warm standby, un RTO de 4 heures autorise du cold standby.
Plan de bascule écrit et versionné
Le runbook décrit chaque étape de la bascule : préparation des données, ajustement DNS, ré-authentification, validation fonctionnelle. Versionné dans Git, revu à chaque évolution majeure d’architecture.
Tests réels, pas simulés
Un test de bascule annuel minimum, avec mesure des RTO/RPO réels. Sans test, le plan est une fiction. NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) et la guidance EBA sur l’externalisation cloud convergent sur ce point [5].
Coûts de sortie identifiés
Les frais d’egress (sortie de données hors d’un cloud) constituent le poste de sortie le plus visible. Ils varient selon le fournisseur et sont publiés dans les grilles tarifaires (pages pricing publiques de chaque hyperscaler). Le Data Act européen prévoit la réduction progressive de ces frais, mais la situation reste à vérifier au moment du chiffrage [3]. À cela s’ajoutent les coûts de re-licensing logiciel, de re-test, et de double exploitation pendant la phase de transition.
Coût total : pourquoi le multi-cloud coûte cher
Quatre postes structurellement supérieurs.
Duplication. Stockage, sauvegardes, infrastructures de monitoring : facteur multiplicateur direct, parfois compensé par des engagements de volume négociés mais rarement à 100 %. Dupliquer 100 To de données chez deux fournisseurs revient à payer deux fois le stockage, plus la bande passante de réplication initiale et continue.
Sortie de données. Tout transfert entre clouds (réplication, sauvegarde croisée, appels API inter-cloud) traverse l’egress. Une réplication continue d’une base à fort volume peut représenter une part significative de la facture annuelle. Les grilles tarifaires publiques de chaque hyperscaler documentent ces frais à la sortie ; les comparaisons à iso-volume montrent des écarts importants entre fournisseurs.
Expertise. Un ingénieur cloud certifié AWS n’opère pas Azure ou Google Cloud à plein régime sans formation et expérience. Deux options : doubler l’équipe spécialisée par fournisseur, ou monter une équipe transverse plus petite mais avec une couverture par fournisseur incomplète. Le marché de l’emploi reflète cette tension : un profil expert sur deux clouds majeurs commande une rémunération supérieure à un profil mono-cloud.
Outillage transverse. FinOps, observabilité, sécurité, identités, CI/CD : chaque couche nécessite des outils qui couvrent les deux fournisseurs, souvent payants à l’instance ou au volume. Une stack d’observabilité multi-cloud (Datadog, Dynatrace, ou Grafana Cloud avec ingestion multi-source) ajoute un poste significatif. Les alternatives open source (Prometheus fédéré, OpenTelemetry Collector central) réduisent ce poste mais demandent une équipe plateforme dédiée à leur maintenance.
Le FinOps Foundation Framework décrit les principes d’allocation et d’optimisation [6]. Voir l’article dédié sur FinOps : réduire la facture cloud de 30 % sans casser la perf.
Combiner souveraineté et multi-cloud
Pour une organisation française ou européenne, la combinaison cloud souverain plus hyperscaler répond à plusieurs exigences simultanées.
Pattern OVHcloud plus Scaleway. Deux acteurs européens, hébergement en Union européenne, immunité claire aux lois extraterritoriales américaines (CLOUD Act). Pertinent quand l’enjeu est la conformité RGPD stricte et la souveraineté juridique, et que le catalogue de services managés (Kubernetes, object storage, bases managées) suffit.
Pattern hyperscaler plus cloud souverain. Charges sensibles (données de santé, données personnelles à risque) chez un fournisseur qualifié SecNumCloud ou équivalent, charges génériques (front, intégrations tierces, analytique) chez un hyperscaler. Le pattern dominant pour les acteurs régulés français qui n’ont pas migré l’intégralité de leur SI vers un acteur souverain.
Voir l’article dédié sur Cloud souverain France 2026 : panorama des options réelles pour le détail des qualifications.
À retenir
Le multi-cloud n’est pas une posture mais un outil. Il s’évalue contre des exigences mesurables : continuité contractuelle (RTO, RPO), conformité (DORA, NIS2, SecNumCloud), capacité technique non substituable, ou levier de négociation tangible. Trois modèles d’architecture coexistent (actif-passif, actif-actif, distribué par service) avec des profils de coût et de complexité qui varient d’un facteur 3 à 10. Kubernetes, Terraform et GitOps absorbent une partie de la complexité mais pas les services managés différenciants ni l’IAM. Une exit strategy ne vaut rien sans tests réguliers de bascule. Le TCO multi-cloud intègre quatre postes structurellement supérieurs : duplication, egress, expertise, outillage. Pour une organisation européenne, combiner un cloud souverain (OVHcloud, Scaleway) et un hyperscaler reste le pattern le plus défendable quand des exigences réglementaires coexistent avec des besoins techniques généralistes.
[1] Commission européenne, Digital Operational Resilience Act (DORA), Règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025. [2] Directive (UE) 2022/2555 (NIS2), transposée en France par la loi 2024-364. [3] Règlement (UE) 2023/2854 sur les données (Data Act), applicable depuis le 12 septembre 2025. [4] Documentation Kubernetes officielle, kubernetes.io/docs/concepts/. [5] NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. [6] FinOps Foundation, FinOps Framework, finops.org/framework/.