La panne de Google Cloud prouve que la résilience est un choix d’entreprise

Une panne de cloud n’est plus seulement la mauvaise matinée d’un ingénieur. Lorsqu’une défaillance chez un fournisseur perturbe les services bancaires, les audiences vidéo des tribunaux et les services publics, elle révèle à quel point une société a discrètement concentré son infrastructure numérique en un seul endroit.

Le 20 octobre 2026, Google Cloud a subi une perturbation dans sa région europe-west2, la zone europe-west2-b ayant notamment été touchée. Reuters rapporte que des utilisateurs ont signalé des problèmes concernant Lloyds, HSBC et Rightmove, tandis que d’autres articles citaient Revolut, ING Germany et Halifax parmi les services en difficulté. La page d’incident de Google indiquait que les services étaient indisponibles dans la zone touchée et que certains services de la région pouvaient subir une hausse du nombre d’erreurs. La panne s’est depuis atténuée, mais l’important n’est pas de savoir si Google a fini par rétablir le service. La vraie question est de savoir pourquoi autant d’entreprises ont été exposées à la même défaillance.

« Le cloud » n’est pas une stratégie quand tout le monde utilise le même fournisseur

Le cloud computing est souvent présenté comme un moyen d’échapper à la fragilité des infrastructures internes. Cette promesse est réelle: un grand fournisseur peut offrir une répartition géographique, une reprise automatisée et une expertise opérationnelle que de nombreuses entreprises ne pourraient pas reproduire à un coût raisonnable. Les propres recommandations de Google en matière de reprise après sinistre reposent explicitement sur la conception de charges de travail capables de résister aux pannes d’infrastructure du cloud.

Mais la résilience n’est pas synonyme de disponibilité. Un client peut fonctionner dans une région cloud moderne tout en dépendant d’un seul fournisseur, d’une seule région, d’une seule zone ou d’un petit ensemble de services partagés. Le résultat est un système qui semble distribué sur un schéma d’architecture, tout en restant concentré dans les faits.

C’est la leçon centrale de cet incident. Il n’était pas nécessaire que la panne mette hors service tous les services de Google Cloud dans le monde pour provoquer une perturbation généralisée. Il suffisait qu’elle atteigne suffisamment de clients dont les applications, les flux de paiement ou les systèmes accessibles au public étaient liés à la même infrastructure régionale. Une plateforme cloud peut être immense tout en créant un point de défaillance étroit pour les entreprises qui se construisent dessus.

C’est pourquoi l’expression « passer au cloud » est devenue trop imprécise pour être utile. La question pertinente n’est pas de savoir si une entreprise utilise une infrastructure cloud. Il faut savoir combien de voies indépendantes restent disponibles lorsque cette infrastructure devient indisponible.

La redondance coûte cher — et faire semblant du contraire est pire

Le plus inconfortable, c’est que la solution ne consiste pas simplement à cocher une case supplémentaire dans un outil de déploiement. Une véritable résilience peut exiger un deuxième fournisseur cloud, des données dupliquées, des systèmes d’identité indépendants, d’autres circuits de paiement, des procédures de basculement testées et des équipes capables de fonctionner en mode dégradé. Ces mesures coûtent de l’argent et ajoutent de la complexité.

Elles peuvent également rendre les systèmes plus difficiles à gérer. Une architecture multicloud peut réduire la dépendance à un fournisseur, mais elle peut introduire des services incompatibles, une supervision plus complexe et un travail supplémentaire en matière de sécurité. Répliquer une base de données entre plusieurs fournisseurs n’est pas automatiquement plus sûr si le processus de réplication, les identifiants ou le plan de reprise reposent toujours sur une dépendance commune.

La bonne réaction n’est donc pas d’exiger par réflexe que toutes les entreprises abandonnent Google Cloud. Ce serait aussi simpliste que de supposer qu’un fournisseur unique suffit toujours. La question raisonnable est celle de la proportionnalité: que se passe-t-il si ce service est indisponible pendant plusieurs heures, et quel serait le coût financier ou le coût pour le public de cette interruption ?

Pour un outil interne peu sensible, accepter une concentration peut être parfaitement rationnel. Pour l’accès aux services bancaires ou un service public, la réponse devrait être différente. Le client — et pas seulement le fournisseur cloud — doit décider si les économies et la commodité justifient cette exposition.

Une panne régionale peut devenir un problème d’infrastructure publique

La perturbation des services bancaires rend le problème particulièrement visible, car les clients ne vivent pas l’architecture cloud comme un choix technique abstrait. Ils la vivent comme une carte bancaire qui ne fonctionne pas, un compte auquel ils ne peuvent pas accéder ou un service qui ne répond plus. La BBC a rapporté que la panne avait touché des tribunaux, des banques et d’autres entreprises en ligne, une combinaison qui transforme un incident fournisseur en question de résilience institutionnelle.

Cela ne signifie pas que Google soit seul responsable de chaque défaillance en aval. Les entreprises choisissent la manière dont elles architecturent leurs systèmes, et la documentation disponible n’établit pas que toutes les banques européennes reposaient sur la même conception. La conclusion la plus défendable est plus circonscrite — et plus grave: une perturbation régionale de Google Cloud pouvait affecter plusieurs services essentiels parce que de nombreuses organisations avaient accepté une dépendance commune.

Il faut également se méfier de l’idée que le taux de disponibilité passé puisse remplacer une véritable planification de la reprise. Google Cloud a connu d’autres incidents, notamment une perturbation de Cloud Storage dans us-central1, le 8 octobre 2026, lorsque les téléversements et les écritures ont subi une latence et un nombre d’erreurs élevés pendant 12 heures et 30 minutes. Le compte rendu d’IncidentHub indique que l’explication préliminaire de Google impliquait un épuisement des ressources après une optimisation du tri du trafic, ainsi qu’un problème distinct de base de données. Le fait que les régions et les causes diffèrent ne prouve pas que toutes les charges de travail soient exposées de la même manière, mais cela remet en cause l’idée rassurante selon laquelle une grande plateforme pourrait être traitée comme un service collectif invisible.

Les clients doivent payer leur indépendance là où une panne compte

Le grand avantage du cloud est aussi sa faiblesse politique et économique: il permet à des milliers d’organisations d’externaliser des décisions d’infrastructure difficiles auprès de quelques fournisseurs. C’est efficace jusqu’à ce que la décision externalisée devienne un mode de défaillance commun.

À notre avis, les régulateurs et les conseils d’administration devraient cesser de se demander uniquement si un fournisseur affiche des chiffres de disponibilité impressionnants. Ils devraient se demander si un service critique peut fonctionner lorsque sa région principale, son fournisseur ou son plan de contrôle partagé est indisponible. La réponse devrait être documentée, testée et financée — et non abandonnée à une diapositive consacrée à la reprise après sinistre.

Google Cloud reste une plateforme puissante, et cette panne ne la rend pas particulièrement irresponsable. Elle montre en revanche que la résilience a un prix, et que ce prix ne disparaît pas parce qu’on qualifie l’infrastructure de « cloud ». Pour les charges de travail non critiques, la concentration peut encore être un compromis judicieux. Pour les services bancaires et publics, en revanche, l’indépendance n’est pas une duplication inutile. Elle fait partie intégrante du service.