Introduction
Le 20 octobre 2026, à 07h08 heure de Londres, une coupure d'alimentation frappe la zone europe-west2-b de Google Cloud. Huit heures plus tard, quand le feu vert est finalement donné, des banques britanniques, des greffiers, des livreurs et des millions d'utilisateurs ont mesuré ce que signifie concrètement dépendre d'une seule zone de disponibilité chez un hyperscaler. Cette panne révèle une tension vieille comme les SLA cloud : celle entre la promesse d'une architecture redondante et la réalité opérationnelle au moment de l'incident.
Quand la redondance zonale ne tient pas sa promesse
Les régions Google Cloud sont organisées en zones de disponibilité censées fonctionner de façon indépendante. En théorie, la défaillance d'europe-west2-b ne devrait pas emporter les services des deux autres zones londoniennes. En pratique, 38 produits cloud ont connu des perturbations ce matin-là : BigQuery, Cloud Run, Google Kubernetes Engine, App Engine et Cloud Filestore, entre autres.
La raison tient à l'architecture réseau : les équipements chargés de router les réponses sortantes vers Internet se trouvaient dans la zone privée de courant. Quand ces équipements se sont éteints, les routes annoncées par Google ont été retirées des réseaux partenaires, rendant les services inaccessibles bien au-delà de la seule zone concernée. Ce mécanisme de cascade n'était pas une première : en juillet 2022, la même région europe-west2 avait connu un incident similaire, avec des conséquences comparables sur les services régionaux.
Google n'a dans un premier temps proposé aucune solution de contournement. La première communication publique est arrivée deux heures et demie après le début des perturbations. Ce n'est qu'après plusieurs heures que la recommandation a été formulée : migrer les charges de travail vers une zone disponible. Pour les applications non conçues pour ce type de basculement, le conseil arrivait trop tard.
Une économie entière concentrée sur une seule zone
Ce qui rend cet incident particulièrement instructif, c'est la nature des services touchés. Lloyds Banking Group, HSBC, Revolut, Royal Mail, Rightmove, DPD et BT figuraient parmi les organisations impactées. Le service de vidéoconférence judiciaire britannique (HM Courts and Tribunals Service), utilisé pour les audiences à distance en Angleterre et au Pays de Galles, a lui aussi subi des interruptions.
La concentration de services aussi hétérogènes — banque, justice, logistique, immobilier, télécoms — sur une même infrastructure cloud soulève une vraie question de gouvernance. Ce n'est pas le fait qu'un hyperscaler tombe en panne qui est remarquable : tous le font. C'est le fait que des organisations aussi différentes partagent un même point de défaillance, sans que leurs plans de continuité n'aient manifestement anticipé ce scénario.
Ce que les architectes cloud doivent réviser
Trois enseignements s'imposent.
L'existence d'une architecture multi-zones ne suffit pas. Il faut tester régulièrement le basculement effectif entre zones et s'assurer que la configuration DNS et réseau le permet en quelques minutes. Le jour d'un incident n'est pas le moment de découvrir qu'une dépendance cachée ancre l'application dans une seule zone.
La surveillance du statut des fournisseurs doit être intégrée aux outils d'observabilité internes, sans attendre les communications officielles. Deux heures et demie d'incertitude, c'est du temps de diagnostic perdu et des décisions d'escalade retardées.
Enfin, pour les services véritablement critiques, la résilience dépasse la seule architecture cloud. Elle implique de questionner la concentration fournisseur et d'évaluer sérieusement les architectures multi-cloud ou hybrides — même lorsque la complexité supplémentaire paraît difficile à justifier en période d'exploitation normale. La prochaine coupure de courant ne préviendra pas davantage.