Il existe une différence fondamentale entre avoir des comptes actifs chez deux fournisseurs de cloud et exploiter une architecture multi-cloud résiliente. La première est une position en matière d’approvisionnement. La seconde est une décision technique avec des coûts opérationnels réels, une complexité constante et des avantages qui ne se matérialisent qu’en cas de catastrophe. La confusion entre les deux a conduit les entreprises à dépenser de l'argent dans des licenciements qui ne fonctionnent pas quand elles en ont besoin – et à le découvrir à leurs dépens, lors d'un incident de production.
Pourquoi les entreprises optent pour le multi-cloud pour de mauvaises raisons
La conversation menant à l’adoption du multi-cloud commence souvent au sein du service des achats ou de la direction. La logique est apparemment solide : si vous avez des contrats avec AWS et Azure, aucun des deux ne peut vous enfermer dans des conditions abusives. La concurrence entre les prestataires maintient les prix sous contrôle et vous avez une issue si la relation se détériore.
Ce raisonnement n’est pas faux en tant que stratégie commerciale. Le problème est de confondre levier commercial et résilience technique. Une entreprise qui exécute 90 % de sa charge sur AWS et gère un compte Azure avec certains services périphériques ne dispose pas d'une architecture multi-cloud : elle dispose d'une diversification des fournisseurs. Si AWS subit une grave panne régionale, l'environnement Azure n'absorbera pas automatiquement la charge. Cela nécessitera des heures ou des jours de travail manuel, de migration de données, de reconfiguration du réseau et une équipe qui comprend parfaitement les deux environnements. Il ne s’agit pas de résilience, c’est d’un plan d’urgence qui n’a jamais été testé.
Ce qu'exige une véritable résilience multi-cloud
L'architecture active-active chez plusieurs fournisseurs (le seul modèle offrant une véritable résilience) suppose que l'application s'exécute simultanément dans les deux environnements avec la capacité d'absorber la totalité de la charge dans l'un ou l'autre. Cela nécessite une synchronisation des états entre les cloud, un équilibrage de charge global, une gestion de la latence entre environnements et des stratégies de cohérence des données qui fonctionnent sous pression.
la base de données est presque toujours le goulot d'étranglement. Les données au repos sont intrinsèquement plus difficiles à répliquer entre fournisseurs qu’à calculer. Les fournisseurs proposent des services de réplication gérés au sein de leur propre environnement, mais la réplication inter-cloud pour les services natifs de chaque fournisseur n'existe pas en tant que produit prêt à l'emploi : elle doit être créée. Cela signifie choisir des bases de données prenant en charge la réplication cross-cloud (PostgreSQL avec une configuration appropriée, CockroachDB, YugabyteDB) ou accepter que les données aient un seul fournisseur de vérité et que la résilience ne s'applique qu'à la couche application.
La couche réseau change également de manière significative. Connecter des VPC de différents fournisseurs avec une latence acceptable et une sécurité adéquate nécessite la mise en place de VPN ou d'interconnexions privées (AWS Direct Connect, Azure ExpressRoute) qui coûtent souvent plus cher que l'infrastructure de calcul.
Le coût opérationnel que personne n'évoque dans le pitch
Les équipes d'infrastructure spécialisées d'un fournisseur ont déjà du pain sur la planche pour rester informées des versions constantes, des modifications de service et des meilleures pratiques. Doubler cette complexité pour deux fournisseurs ayant des abstractions différentes, une terminologie différente, des outils d'observabilité différents et des modèles de tarification différents revient à doubler la charge cognitive de l'équipe – ou à embaucher des ingénieurs compétents dans les deux environnements, qui sont plus rares et plus coûteux.
Les outils d'infrastructure en tant que code doivent être écrits pour abstraire les différences entre les fournisseurs, ce qui signifie souvent des couches d'abstraction supplémentaires (Terraform avec des modules indépendants du fournisseur) qui augmentent la complexité sans ajouter de fonctionnalités visibles. L'observabilité unifiée – cruciale pour diagnostiquer les incidents qui traversent les environnements – nécessite une plate-forme de surveillance neutre (Datadog, New Relic, Grafana Cloud) qui regroupe les métriques des deux fournisseurs, ce qui représente davantage un coût et davantage une intégration à maintenir.
Le résultat pratique est que le coût réel d’exploitation d’un multi-cloud actif-actif est entre 30 % et 50 % plus élevé que l’exploitation de la même charge de travail sur un seul fournisseur, en tenant compte des coûts d’informatique, de réseau, de stockage et d’équipe. Avant de s’engager dans cette architecture, la bonne question est : quel est le coût d’une indisponibilité de 4 heures pour l’entreprise ? Si la réponse est inférieure au coût du maintien de la résilience, les calculs plaident en faveur d’une stratégie différente.
Quand le multi-cloud est la bonne réponse
Il existe des cas où les frais généraux sont clairement justifiés. Services financiers et infrastructures critiques dont la disponibilité réglementaire est supérieure à 99,99 % et pour lesquels une panne entraîne un préjudice réglementaire ou financier immédiat. Les plates-formes avec une couverture mondiale où la latence est importante et où les différents fournisseurs ont une meilleure présence dans des régions spécifiques. Les organisations qui ont eu de graves incidents avec leurs fournisseurs et qui doivent démontrer aux clients et aux régulateurs que la dépendance a été résolue.
En dehors de ces contextes, la stratégie de résilience la plus efficace pour la plupart des entreprises est celle d’un fournisseur unique et multirégional, avec une reprise après sinistre bien documentée et testée. AWS us-east-1 tombant avec des charges de travail us-west-2 prêtes à prendre le relais offre le même résultat pratique pour la plupart des scénarios de panne, avec une fraction de la complexité opérationnelle.
La distinction pertinente pour prendre cette décision concerne les domaines de défaillance. Si le problème concerne une région spécifique en panne, le multi-région le résout. Si le problème concerne la défaillance ou l’arrêt de l’ensemble du fournisseur, le multi-cloud est nécessaire. La deuxième hypothèse est techniquement possible mais historiquement rare chez les trois plus grands prestataires. Calibrer la stratégie de résilience en fonction du risque réel, et non du risque imaginé, est ce qui différencie une décision architecturale judicieuse d'un projet coûteux qui résout un problème qui n'existe pas.
Comment évaluer avant de construire
Une évaluation correcte commence par une cartographie honnête des dépendances. Quels services de fournisseur natifs l’application utilise-t-elle actuellement ? Combien d’entre eux ont un équivalent fonctionnel chez le deuxième fournisseur ? L’effort de portage vers des services agnostiques ou compatibles est-il proportionnel au bénéfice recherché ?
L'étape suivante consiste à simuler une défaillance d'un fournisseur avant de créer une redondance. Combien de temps faudrait-il pour restaurer le fonctionnement d'un deuxième fournisseur à partir de l'état actuel ? Quelles données seraient perdues ? Quels processus manuels seraient nécessaires ? Cette simulation — qui n'a pas besoin d'être réalisée en production, peut être un exercice d'architecture papier — révèle souvent que le chemin le plus rapide vers la résilience n'est pas le multi-cloud mais plutôt l'amélioration des processus de récupération chez le fournisseur actuel. Ce n’est qu’après avoir épuisé cette option que la complexité supplémentaire du multi-cloud se justifie.
A lire aussi
-Optimisation des coûts du cloud : stratégies FinOps pour les petites entreprises -Sans serveur avec AWS Lambda : Guide pratique pour les applications évolutives
- Des chaînes d'approvisionnement résilientes : au-delà du juste à temps
- Informatique autonome : lorsque le système se corrige avant que vous ne remarquiez l'erreur -Résidence des données : ce que signifie en pratique garantir que les données restent au Brésil
- Évolutivité de l'application : stratégies et liste de contrôle avant de croître