Le multi-cloud n'achète pas la résilience

Après chaque panne majeure d'un grand fournisseur cloud, la même conversation revient en comité de direction : « et si on passait en multi-cloud, pour ne plus dépendre d'un seul acteur ? ». L'intention est légitime, le raisonnement est souvent faux. Le multi-cloud, tel qu'il est pratiqué dans la majorité des entreprises qui s'y lancent, n'achète pas de résilience — il achète de la complexité, et la complexité est elle-même une source de pannes.

Ce que le multi-cloud résout vraiment

Le multi-cloud a un cas d'usage solide : se protéger contre la disparition ou l'indisponibilité prolongée d'un fournisseur entier, ou répondre à une contrainte réglementaire de souveraineté qui impose une diversification. Pour une poignée d'entreprises — banques systémiques, opérateurs critiques, acteurs soumis à des obligations de continuité extrêmes — ce risque justifie l'investissement.

Pour la très grande majorité des PME et scale-ups, ce risque n'est simplement pas celui qui menace leur activité. Le risque réel n'est presque jamais « AWS disparaît » — c'est « notre équipe a mal configuré une bascule », « notre base de données n'a pas de réplique testée », ou « personne ne sait relancer le service de paiement un dimanche ».

Le vrai coût caché du multi-cloud

Faire tourner une infrastructure sur deux fournisseurs cloud ne double pas le travail, il le multiplie bien davantage, parce que chaque fournisseur a ses propres primitives, ses propres limites, sa propre API, son propre modèle de facturation et ses propres pannes.

• Compétences doublées : l'équipe doit maîtriser deux écosystèmes en profondeur, ou se contenter du plus petit dénominateur commun, ce qui revient à renoncer aux services managés les plus utiles de chacun.
• Outillage divergent : supervision, gestion des accès, sauvegardes, réseau — chaque brique doit être pensée deux fois, ou remplacée par une couche d'abstraction supplémentaire qui devient elle-même un point de défaillance.
• Tests de bascule quasi jamais faits : la promesse du multi-cloud (« si l'un tombe, l'autre prend le relais ») n'a de valeur que si la bascule a été testée en conditions réelles, ce qui est rarissime tant l'exercice est coûteux à répéter.
• Coût financier : la duplication de l'infrastructure et le temps d'ingénierie supplémentaire dépassent presque toujours le coût d'une panne évitée, surtout quand cette panne ne s'est jamais produite.

Le résultat observé sur le terrain est presque toujours le même : une infrastructure multi-cloud mal testée, plus complexe à opérer, avec davantage de surface d'erreur humaine — c'est-à-dire moins résiliente que l'infrastructure mono-cloud bien conçue qu'elle a remplacée.

Ce qui construit réellement la résilience

La résilience ne vient pas du nombre de fournisseurs, elle vient de la qualité des pratiques appliquées à celui qu'on a choisi.

• Multi-zone avant multi-cloud. Les grands fournisseurs proposent plusieurs zones de disponibilité au sein d'une même région : c'est la première ligne de défense, largement suffisante contre l'écrasante majorité des incidents.
• Sauvegardes testées, pas seulement planifiées. Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une hypothèse. Un test de restauration trimestriel révèle plus de failles qu'une architecture multi-cloud jamais déclenchée.
• Un plan de reprise d'activité écrit et chronométré. Savoir combien de temps il faut réellement pour revenir en production, et qui fait quoi, avant que la question ne se pose en urgence.
• Une infrastructure comme code réplicable. Si tout votre environnement peut être reconstruit ailleurs à partir de fichiers versionnés, vous avez déjà l'essentiel de la portabilité que le multi-cloud est censé apporter, sans en payer le coût permanent.
• Une vraie observabilité. La majorité des incidents graves ne viennent pas du fournisseur cloud mais de déploiements, de configurations ou de dépendances applicatives — un système bien surveillé les détecte avant qu'ils ne deviennent critiques.

Une décision à prendre avec les yeux ouverts, pas par réflexe

Le multi-cloud reste parfois justifié — négociation tarifaire, contrainte contractuelle spécifique, souveraineté imposée par un client public. Dans ce cas, il doit être traité comme un projet à part entière, avec son propre budget, ses propres tests de bascule et sa propre équipe formée, pas comme une case cochée pour rassurer un comité de direction après une panne médiatisée.

C'est le type d'arbitrage que nous tranchons régulièrement dans nos missions de CTO à temps partagé : évaluer le risque réel de l'entreprise avant de recommander une architecture, plutôt que de suivre une mode technique coûteuse et rarement testée jusqu'au bout.

FAQ

Le multi-cloud est-il justifié pour une startup en forte croissance ?

Presque jamais à ce stade. Une startup en croissance a un besoin critique de vitesse d'exécution et un besoin limité de tolérance à la disparition d'un fournisseur entier. L'énergie d'ingénierie est bien mieux investie dans la robustesse mono-cloud — sauvegardes testées, multi-zone, observabilité — que dans une architecture distribuée sur deux fournisseurs.

Comment se prémunir d'une panne d'un grand fournisseur cloud sans passer au multi-cloud ?

En s'assurant que l'architecture exploite plusieurs zones de disponibilité au sein de la même région, en gardant une infrastructure comme code capable d'être redéployée rapidement ailleurs si nécessaire, et en documentant un plan de reprise réaliste. Cela couvre la quasi-totalité des scénarios de panne réellement rencontrés, pour une fraction du coût d'exploitation permanent du multi-cloud.