Le multi-cloud, ou l'art de ne pas mettre tous ses œufs dans le même datacenter
Il y a quelque chose d'assez délicieux dans la trajectoire des DSI modernes. Après avoir passé des années à convaincre leurs directions que « le cloud », c'était sérieux, les voilà à jongler avec plusieurs clouds simultanément, comme si un seul fournisseur ne suffisait plus. La stratégie multi-cloud n'est pas une lubie de consultant en mal de facturation. C'est une réponse pragmatique, parfois contrainte, à des enjeux de souveraineté, de performance et de résilience qui ne cessent de s'intensifier.
87 % des entreprises mondiales adoptent une approche multi-cloud, selon IDC. Ce chiffre dit beaucoup. Il dit surtout que le marché a tranché, même si les pratiques restent très inégales.
Pourquoi le multi-cloud s'impose aux DSI
La fin du fournisseur unique providentiel
Longtemps, l'idée d'un partenaire cloud unique avait ses vertus : cohérence technique, interlocuteur identifié, tarification négociée en bloc. Sauf que cette logique de dépendance, le fameux vendor lock-in, s'est progressivement transformée en risque stratégique. Quand AWS subit une panne régionale, quand Azure revoit unilatéralement sa grille tarifaire, la question se pose différemment.
Le multi-cloud répond d'abord à une logique de résilience. Distribuer les charges applicatives sur plusieurs hyperscalers permet de maintenir la continuité de service même en cas d'incident majeur chez l'un d'eux. C'est une forme d'assurance, coûteuse certes, mais de plus en plus justifiable au regard des SLA réels observés sur le terrain.
La souveraineté des données en toile de fond
Le RGPD n'est pas mort. Loin de là. L'émergence du Cloud de Confiance, portée en France par des acteurs comme OVHcloud ou Outscale, a rebattu les cartes pour certains secteurs critiques : santé, défense, services publics. Une DSI en charge d'un hôpital ou d'un groupe industriel sensible ne peut pas se permettre d'ignorer où ses données dorment réellement la nuit.
Le multi-cloud permet de calibrer le niveau de sensibilité des données selon leur destination. Les workloads critiques restent sur des environnements souverains certifiés, pendant que les applications moins sensibles profitent des économies d'échelle des grands hyperscalers américains. Une segmentation qui relève autant du droit que de l'architecture.
Les avantages concrets d'une architecture multi-cloud
Flexibilité et optimisation des coûts
Chaque cloud a ses points forts. Google Cloud excelle sur l'analytique et le machine learning. AWS reste imbattable sur la diversité de ses services managés. Azure s'intègre naturellement dans les environnements Microsoft déjà présents dans 90 % des entreprises européennes. Plutôt que de choisir, le multi-cloud permet d'utiliser le meilleur outil pour chaque usage.
Cette granularité ouvre aussi des leviers de négociation. Un DSI qui peut crédiblement menacer de migrer une charge vers un concurrent change radicalement de posture face à son account manager. Le commitment financier cesse d'être un chemin à sens unique.
Résilience et plan de continuité
La disponibilité à cinq neuf, 99,999 %, reste un objectif noble. Elle suppose une architecture où aucun point de défaillance unique ne peut tout emporter. Le multi-cloud, couplé à des stratégies de failover automatisé, forme un socle solide pour les plans de reprise d'activité (PRA) et de continuité (PCA).
En décembre 2021, un incident sur AWS US-EAST-1 avait paralysé une partie non négligeable d'Internet mondial. Les entreprises multi-cloud en avaient profité pour démontrer concrètement leur valeur. La pédagogie par l'exemple reste la plus efficace.
Les pièges qu'on ne voit pas venir
La complexité comme ennemi silencieux
Le multi-cloud donne une impression de maîtrise. Plusieurs fournisseurs, plusieurs options, plusieurs équipes. En réalité, la complexité opérationnelle explose presque mécaniquement : chaque cloud a ses propres API, ses propres outils de monitoring, ses propres modèles de sécurité. Sans une couche d'abstraction solide (Terraform, Kubernetes, une plateforme d'observabilité unifiée comme Datadog ou Dynatrace), le château de cartes vacille rapidement.
Les équipes IT se retrouvent à maintenir plusieurs certifications, plusieurs stacks, plusieurs rythmes de mise à jour. Le coût humain est souvent sous-estimé dans les business cases initiaux. Une DSI qui adopte le multi-cloud sans dimensionner ses équipes en conséquence joue à un jeu risqué.
Le shadow-cloud, version aggravée
Le shadow IT classique (ces applications SaaS adoptées sans validation de la DSI) avait déjà de quoi faire grisonner. Le multi-cloud non gouverné en est l'évolution naturelle. Des équipes métiers qui provisionnent directement sur GCP parce que leur prestataire préféré y est hébergé, un projet data science qui ouvre un compte AWS pour « tester quelque chose » et reste trois ans en production sans que personne ne le sache vraiment.
La gouvernance multi-cloud n'est pas optionnelle. C'est la condition pour que la stratégie reste une stratégie et ne devienne pas une accumulation désordonnée de contrats qu'on redécouvre à chaque audit.
Les coûts cachés qui ruinent les promesses
Le cloud promet des économies. Le multi-cloud, mal géré, peut doubler la facture. Les coûts d'egress, ces frais de transfert de données sortant d'un cloud vers un autre, sont particulièrement sournois. Ils n'apparaissent pas dans les simulateurs de coût initiaux et peuvent représenter des montants significatifs sur des architectures fortement interconnectées.
Sans FinOps dédié, sans tagging cohérent des ressources, sans alertes budgétaires fines, les dépenses cloud multi-providers deviennent rapidement opaques. Une dépense opaque est une dépense non maîtrisée.
Bonnes pratiques pour une stratégie multi-cloud mature
Définir une politique de placement avant de déployer
Avant tout déploiement, chaque application devrait être classifiée selon quelques critères simples : sensibilité des données traitées, exigences de latence, dépendances techniques, budget alloué. Ce référentiel de placement, sobre, tenu à jour, connu des équipes, évite les décisions ad hoc qui fragmentent inutilement le patrimoine applicatif.
La règle n'est pas d'utiliser tous les clouds pour tout, mais d'utiliser chaque cloud là où il est objectivement supérieur. Une nuance qui peut sembler évidente, mais qui disparaît vite sous la pression des roadmaps.
Investir dans l'abstraction et l'automatisation
Terraform pour l'infrastructure as code, Kubernetes pour l'orchestration des conteneurs, des pipelines CI/CD agnostiques du cloud : ces choix techniques ne sont pas des modes passagères. Ils forment l'épine dorsale d'une architecture multi-cloud réellement portable.
L'automatisation réduit les erreurs humaines, accélère les déploiements et rend les migrations inter-cloud moins traumatisantes. Elle a aussi l'avantage de documenter l'infrastructure de facto, ce qui est rarement négligeable quand arrive le turn-over.
Mettre en place une gouvernance FinOps sérieuse
Le FinOps n'est pas un poste de contrôle de coûts supplémentaire. C'est une culture d'ingénierie financière qui réconcilie développeurs, ops et finance autour d'une visibilité partagée sur les dépenses cloud. En multi-cloud, cette discipline devient encore plus déterminante.
Des outils comme CloudHealth, Apptio Cloudability ou la combinaison native AWS Cost Explorer/GCP Cost Management permettent de centraliser la vision. Mais l'outil sans le processus ne sert à rien. Un rituel hebdomadaire de revue des anomalies de coût, impliquant les équipes techniques, change plus les comportements que n'importe quel dashboard.
Ne pas négliger la sécurité transversale
Chaque cloud a son modèle de responsabilité partagée. Multiplier les clouds multiplie les surfaces d'attaque et les zones d'ombre potentielles. Une stratégie multi-cloud mature intègre une approche CSPM (Cloud Security Posture Management) unifiée, capable de détecter les mauvaises configurations sur l'ensemble des environnements.
Les identités forment le périmètre le plus critique. Une gestion IAM cohérente entre clouds, idéalement fédérée autour d'un fournisseur d'identité central, est le premier rempart contre les escalades de privilèges et les compromissions latérales.
Ce que disent les DSI qui ont bien fait le chemin
Les DSI les plus avancés sur le sujet partagent quelques points communs. Ils ont commencé petit, sur quelques workloads définis, avant d'élargir la surface. Ils ont investi dans les compétences internes plutôt que de tout déléguer à des intégrateurs. Et ils ont accepté que la stratégie multi-cloud soit un work in progress permanent, sans date de fin inscrite nulle part.
Le multi-cloud n'est pas une destination. C'est un mode opératoire qui évolue avec les offres des fournisseurs, les contraintes réglementaires et les besoins métiers. Les DSI qui l'ont intégré comme une capacité organisationnelle plutôt que comme un état figé en tirent le meilleur parti, sans s'y noyer.
