Pourquoi les pannes continuent-elles à se produire, et que pouvez-vous faire pour y remédier ?
2025 a été difficile si vous aviez misé votre entreprise sur un seul fournisseur de cloud. En décembre, les clients de Snowflake ont assisté, impuissants, à une mise à jour de schéma en cascade dans plusieurs régions, bloquant les requêtes pendant 13 heures. Les utilisateurs de Databricks ont fait face à des jours de services d'IA dégradés.
En octobre, la région US-East-1 d’Amazon Web Services (AWS) est restée inactive pendant 15 heures— une erreur DNS affectant DynamoDB a mis hors service plus de 1 000 entreprises. En juin, une exception de pointeur nul dans le binaire Service Control de Google Cloud a désactivé plusieurs systèmes, dont Cloud Storage, Compute Engine et BigQuery, pendant plusieurs heures, ce qui a eu des répercussions sur Spotify, Discord et OpenAI.
À travers tous ces incidents, le schéma était le même : les clients actualisaient les pages de statut et attendaient que quelqu'un d'autre résolve le problème. La différence entre les fournisseurs n'est pas de savoir si les pannes se produisent, mais quelles options s'offrent à vous lorsqu'elles se produisent.
Le modèle : des points de défaillance uniques avec une portée mondiale
L'incident survenu en décembre chez Snowflake a été déclenché par une mise à jour du schéma de la base de données incompatible avec le passé. Des erreurs de décalage de version faisaient échouer ou bloquer indéfiniment les opérations dans plusieurs régions sur AWS, Microsoft Azure et Google Cloud Platform (GCP). Les communications de Snowflake ont indiqué qu'il n'y avait pas de solution de rechange, sauf pour les clients qui avaient préconfiguré la réplication vers des régions non touchées. Tous les autres ont attendu.
La panne de décembre de Databricks (qui s'est étendue sur plusieurs jours) comprenait des problèmes liés au catalogue Unity, une dégradation du calcul dans plusieurs régions et une perturbation de Mosaic AI qui s'est étendue sur plusieurs jours. Les mises à jour de statut ont régulièrement indiqué qu'ils étaient en train de « travailler avec le fournisseur de cloud sur des pistes de mitigation potentielles. » Cette phrase vous dit tout sur la chaîne de dépendance : quand Azure a une mauvaise journée, les clients de Databricks sur les régions Azure ont aussi une mauvaise journée.
L’incident de Google Cloud en juin a révélé la même vulnérabilité. Une politique défectueuse avec des champs vides a été insérée dans les tables de configuration globales et reproduite dans le monde entier en quelques secondes. Les données corrompues ont déclenché des boucles de plantage qui ont mis hors service les services de base pendant 7,5 heures. Les tableaux de bord de statut de Google étaient initialement indisponibles — les équipes SRE ne pouvaient même pas confirmer l'étendue du désastre.
La redondance régionale n'est pas utile lorsque la défaillance est logique plutôt que physique. Lorsqu'une plateforme repose sur des métadonnées coordonnées à l'échelle mondiale ou une configuration partagée, une seule mise à jour incorrecte se propage partout. La panne vous suit de région en région.
En outre, dans ces scénarios, l'infrastructure est distribuée, mais le contrôle reste centralisé. Lorsque le plan de contrôle de Snowflake tombe en panne, peu importe qu'ils fonctionnent sur AWS, Azure et Google Cloud. Lorsque Databricks attend qu'Azure résolve un problème, le marketing multi-cloud n'aide pas. Le seul point de défaillance est la couche propriétaire qui se trouve au-dessus.
Ce que disent les analystes
L’analyse Gartner® 2025 sur les tendances d’adoption du cloud estime que plus de 50 % des organisations n’obtiendront pas les résultats attendus de leurs implémentations multi-cloud d’ici 2029. Le problème central : le manque d’interopérabilité entre les environnements.
Dans Forrester Predictions 2026 : Pannes majeures de cloud, IA privée sur des clouds privés et l'essor des néo-clouds, le cabinet de recherche prévoit au moins deux grandes pannes de cloud de plusieurs jours en 2026. L'industrie du cloud connaît une transition massive d'infrastructure, alors que les hyperscalers s'empressent de construire des centres de données natifs de l'IA. Cet investissement a un coût : les environnements hérités x86 et ARM sont dépriorisés, ce qui conduit à une infrastructure vieillissante vacillant face à une complexité croissante.
Dans le même article, Forrester estime qu'au moins 15 % des entreprises passeront à des déploiements d'IA privée construits sur des clouds privés en 2026. Les facteurs : la hausse des coûts de l’IA, les inquiétudes liées au verrouillage des données et le risque opérationnel de dépendre d’une infrastructure de plus en plus optimisée pour les priorités d’autrui. Les pannes de 2025 étaient un avant-goût de ce qui se produit lorsque vos charges de travail ne sont pas la priorité absolue du fournisseur.
Concevoir des solutions de résilience avec Cloudera
La plupart des entreprises disposent d'architectures « multi-cloud accidentelles » par le biais d'acquisitions, d'informatique parallèle ou de la sélection des meilleurs outils, et non par une planification architecturale délibérée. Leurs charges de travail sont réparties entre les fournisseurs, mais ils ne peuvent pas transférer les données et les charges de travail en cas de problème.
L'architecture axée sur la résilience implique de s'assurer que votre plateforme de données et d'IA permet la portabilité et élimine les points de basculement uniques.
La plateforme Cloudera est conçue pour la portabilité, ce qui vous permet de basculer d'un environnement à l'autre pour maintenir les opérations. Les charges et les données peuvent être déplacées entre les environnements AWS, Azure, Google Cloud et les environnements sur site sans réécriture, friction ou verrouillage de la part du fournisseur. Les mises à jour ne sont pas imposées comme des changements globaux et non rétrocompatibles.
Lorsque la panne inévitable survient, vous avez des options : basculer vers un autre cloud ou transférer les charges de travail vers votre centre de données. Vous n’êtes pas obligé de surveiller une page de statut—vous gardez le contrôle de vos données et pouvez maintenir des opérations et une conformité cohérentes, peu importe où résident les données.
Pour en savoir plus sur la création d'une architecture résiliente avec Cloudera, consultez notre blog : Concevoir pour la résilience des données : garantir la continuité des activités avec Cloudera
Perspectives
La mise en place de l'IA met à rude épreuve l'infrastructure, et les cabinets d'analystes prévoient plus de turbulences à l'avenir : Forrester prédit des pannes de plusieurs jours, Gartner prévoit une adoption défensive du multi-cloud. Les entreprises qui passeront le cap de 2026 en bonne santé seront celles qui considèrent la résilience comme un principe architectural plutôt que comme une case à cocher de conformité.
Cloudera ne propose pas de basculement inter-cloud par simple pression d'un bouton prêt à l'emploi—personne ne le fait. Mais nous sommes architecturalement positionnés pour soutenir cette résilience, ce qui n'est pas le cas des plateformes propriétaires.
Si les pannes de 2025 vous ont inquiété, nous aimerions en discuter. Parce que le cloud n'est que l'ordinateur de quelqu'un d'autre. Et quand cet ordinateur passe une mauvaise journée, vous devriez avoir un autre endroit où aller.
Pour en savoir plus sur la façon dont vous pouvez concevoir une architecture résiliente avec Cloudera, contactez notre équipe de professional services, consultez nos démonstrations de produits ou inscrivez-vous pour un essai gratuit de 5 jours.
