Panne Google Cloud Londres : cascade de défaillances critiques et stratégie de redondance

Ce mardi 20 octobre 2026, à 06 h 08 GMT, une seule zone de disponibilité londonienne suffisait à paralyser des paiements bancaires dans toute l'Europe. Ce n'est pas une fiction : un « power event » dans la zone europe-west2-b a déclenché une cascade qui a laissé des millions de clients Revolut, Lloyds, HSBC ou Royal Mail sans accès à leurs services numériques. La panne illustre avec une brutalité rare la fragilité systémique d'une économie numérique concentrée sur un petit nombre de régions hyperscale.

1) Situation : anatomie d'un incident régional à effets globaux

!Salle de serveurs plongée dans l'obscurité lors d'une panne électrique dans un datacenter Photo : imgix / Unsplash

Le tableau de bord officiel Google Cloud a enregistré le début de l'incident à 08 h 08, heure suisse (soit 06 h 08 GMT). La cause identifiée : un « power event » localisé dans la zone europe-west2-b, l'une des trois zones de disponibilité de la région londonienne.

Les symptômes immédiats ont été des taux d'erreurs élevés et des pannes réseau intermittentes. La liste des services impactés est rapidement devenue imposante : BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, App Engine, Cloud NetApp Volumes, Google Kubernetes Engine (GKE) et Managed Service for Apache Kafka. Selon la presse française, une trentaine de produits auraient été listés dans le tableau d'incident.

La géographie de l'impact ne s'est pas limitée au Royaume-Uni. Plusieurs services dépendant de l'infrastructure londonienne ont subi des perturbations dans d'autres pays européens, illustrant la concentration des dépendances sur un nombre restreint de régions cloud.

figures 06:08 GMT | Heure de début officielle de l'incident dans la zone europe-west2-b | The Register ~30 produits | Nombre de services Google Cloud listés dans le tableau d'incident | Clubic 3 zones | Nombre de zones de disponibilité dans la région europe-west2 (Londres) | The Register 1 zone | Zone affectée par le « power event » (europe-west2-b) | ABC News

2) Dynamiques à l'œuvre : la cascade opérationnelle

!Application bancaire mobile affichant une erreur lors d'une panne de service cloud Photo : Jonas Leupe / Unsplash

Des noms emblématiques au cœur de la perturbation

La liste des entreprises impactées lit comme un annuaire de l'économie numérique britannique. Revolut a confirmé une perturbation de plusieurs services : ses clients se sont retrouvés dans l'incapacité d'effectuer des paiements par carte, de retirer de l'argent aux distributeurs automatiques ou d'accéder à l'application. La banque en ligne a tenu à rassurer ses utilisateurs : aucune perte de fonds ni de données clients n'a été signalée.

Des signalements publics ont également concerné Lloyds Bank, HSBC, DPD, Screwfix, Rightmove et Royal Mail. Les fintech Emma et Synapse ont, elles aussi, confirmé une indisponibilité directement liée à la panne Google Cloud londonienne.

Le mécanisme de la cascade

Comment un incident sur une seule zone de disponibilité se transforme-t-il en crise multisectorielle ? La réponse tient en un mot : concentration. Comme le résume Shattered.io, « une grande partie de la société internet de consommation — applications bancaires, annonces immobilières — repose sur un petit nombre de régions hyperscale cloud. Quand une région dysfonctionne, l'impact est visible sous forme de carte refusée en supermarché ou d'application bancaire qui ne s'ouvre pas ».

Les composants régionaux partagés, comme le réseau et le DNS, constituent des points de défaillance communs qui peuvent neutraliser simultanément des services théoriquement indépendants. Même l'outil Spanner de Google, qui réplique normalement les données entre zones, peut devenir inopérant si le bâtiment physique hébergeant la zone concernée devient indisponible — comme observé lors d'un incident similaire sur la zone europe-west9-a en 2023.

chart {"type":"bar","title":"Pannes majeures Google Cloud en 2026 : nombre de services touchés","unit":"services dégradés","labels":["20 août 2026 (us-west1)","1 sept. 2026 (us-central1-b)","20 oct. 2026 (europe-west2-b)"],"series":[{"name":"Nombre de services/produits dégradés","values":}],"source":"Outage Cost / The Register","url":"https://outagecost.com/gcp-outages"}

3) Implications stratégiques : les limites réelles de la redondance cloud

!Architecture cloud multi-régions illustrant la redondance et le basculement entre zones de disponibilité Photo : Growtika / Unsplash

Le mythe de la redondance automatique

Le découpage d'une région cloud en plusieurs zones est présenté par les fournisseurs comme un rempart contre les défaillances locales. L'ENISA décrit effectivement la redondance logique entre plusieurs centres de données comme un moyen de résister à la panne d'un centre individuel. Google lui-même déclare, dans son catalogue officiel britannique, disposer de capacités de reprise après sinistre, de stockage géoredondant et de déploiements multirégions.

Mais la réalité opérationnelle révèle une asymétrie d'information critique : les clients sont généralement conseillés d'utiliser plusieurs zones et régions pour la résilience, mais ils reçoivent rarement une visibilité sur les dépendances à un seul datacenter au sein d'une zone pour les services managés. De nombreuses organisations supposent que l'abstraction cloud fournit plus de redondance au niveau des installations qu'il n'en existe réellement pour les services spécialisés.

La mesure de contournement de Google et ses limites

Face à l'incident, Google a recommandé officiellement de migrer les charges de travail affectées vers une autre zone ou une autre région disponible. Recommandation théoriquement raisonnable, mais pratiquement limitée par deux contraintes majeures :

1. Les dépendances d'infrastructure régionale : certaines architectures sont si étroitement liées à une région qu'elles ne peuvent pas basculer à chaud sans refonte applicative.
2. Les exigences de résidence des données : les réglementations RGPD et les contraintes sectorielles (banque, santé) limitent souvent la possibilité de répliquer des données vers d'autres régions géographiques.

Google a présenté ses excuses aux clients affectés et confirmé que ses équipes d'ingénierie enquêtaient sur les défaillances, sans communiquer de cause détaillée ni d'heure estimée de rétablissement dans les premières heures.

4) Cadre de décision : tirer les leçons stratégiques

Le pattern 2026 : une accumulation préoccupante

La panne londonienne du 20 octobre 2026 ne s'inscrit pas dans le vide. Elle vient s'ajouter à une série d'incidents graves survenus dans la même année :

• 20 août 2026 : défaillance réseau régionale sur us-west1, avec reroute automatisé échoué pendant une maintenance fiber — 33 produits dégradés pendant environ 2 h 22 min.
• 1er septembre 2026 : maintenance hardware mal exécutée sur us-central1-b, un technicien ayant déconnecté tous les chemins fibres simultanément au lieu de procéder routeur par routeur — 19 produits dégradés pendant environ 4 h 11 min.
• 20 octobre 2026 : « power event » sur europe-west2-b — environ 30 produits dégradés, durée totale non précisée dans les sources.

Ce palmarès documenté par Outage Cost révèle un pattern : les incidents ne résultent pas uniquement de défaillances matérielles imprévisibles, mais parfois de procédures opérationnelles insuffisamment sécurisées.

Les trois questions stratégiques pour les DSI

1. Cartographiez vos dépendances réelles, pas vos dépendances déclarées. Chaque service managé cloud peut avoir des dépendances à un seul datacenter physique que la couche d'abstraction masque. L'audit de résilience doit descendre jusqu'au niveau de la zone, voire du bâtiment.

2. Testez le basculement, ne le supposez pas. Google déclare effectuer chaque année des tests de ses plans de continuité pour simuler des scénarios catastrophiques. Vos propres plans doivent être testés avec la même rigueur — un RTO théorique non testé est une fiction budgétaire.

3. Anticipez les contraintes réglementaires dans votre architecture multicloud. Les exigences de résidence des données limitent les options de basculement. La stratégie de résilience doit être co-conçue avec les équipes juridiques et de conformité dès la phase d'architecture, pas en réponse à une crise.

Un précédent historique instructif

Ce n'est pas la première fois que Londres pose problème à Google Cloud. En juillet 2022, une panne avait déjà été attribuée à une défaillance du système de refroidissement dans un centre de données londonien, exacerbée par des températures record. En 2024, un incident encore plus grave avait vu Google Cloud effacer accidentellement le compte complet d'UniSuper, un fonds de pension australien, y compris ses sauvegardes. Ces précédents auraient dû alerter les organisations sur la nécessité d'une stratégie de résilience qui ne repose pas uniquement sur les garanties contractuelles du fournisseur.

Conclusion

La panne du 20 octobre 2026 sur europe-west2-b est un cas d'école. Un « power event » sur une seule zone a suffi à faire trembler le système bancaire britannique, non par manque de redondance théorique, mais par manque de redondance effective et testée. La leçon n'est pas que Google Cloud est peu fiable — c'est que toute architecture qui suppose la disponibilité sans la tester est une architecture fragile.

Pour les organisations, la question n'est plus « notre fournisseur cloud est-il redondant ? » mais « notre propre déploiement est-il conçu pour survivre à la défaillance d'une zone, d'une région, voire d'un fournisseur entier ? » La réponse à cette question mérite un audit urgent.

— Équipe éditoriale InekIA