Introduction
Le 20 octobre 2026, au petit matin, les applications bancaires de milliers de clients britanniques tombent en cascade. Revolut ne traite plus les paiements ni les retraits DAB. Les portails de Lloyds et HSBC affichent des erreurs. Les audiences vidéo des tribunaux civils anglais sont interrompues. La cause n'est ni un bug applicatif ni une attaque : c'est un câble souterrain rompu et deux automates programmables mal configurés.
Quand le filet de sécurité lui-même tombe
À 06h00 UTC, l'alimentation externe du datacenter hébergeant la zone europe-west2-b de Google Cloud à Londres se coupe sur rupture d'un câble souterrain. Le scénario est prévu : des onduleurs UPS prennent le relais, puis les groupes électrogènes de secours sont supposés démarrer automatiquement. Ils ne l'ont pas fait.
Le rapport post-incident publié le 4 novembre documente la cause : les deux contrôleurs logiques programmables (PLC), principal et de secours, présentaient une faille dans leur logique de détection de tension. L'automate signalait qu'une source électrique saine était disponible, alors même que les deux alimentations du datacenter étaient hors tension. Les générateurs n'ont jamais reçu leur signal de démarrage. Les batteries UPS se sont épuisées en cinq minutes. Serveurs, stockage et équipements réseau se sont éteints.
La panne totale a duré sept heures cinquante-deux minutes. Plus de cinquante produits Google Cloud ont été affectés : Compute Engine, Cloud SQL, Cloud Storage, BigQuery, GKE, Cloud Run, toute la pile d'une zone entière.
Douze services en cascade
L'onde de choc ne s'est pas arrêtée aux portes de Google. Douze services tiers dépendants de cette zone ont basculé à leur tour. Les systèmes de Revolut ont perdu successivement connexions, virements et retraits DAB. Lloyds, HSBC et Royal Mail ont été impactés. Quatre heures après la résolution officielle, six des vingt-sept services Revolut restaient encore dégradés.
Ce que cet incident met en lumière, c'est la différence structurelle entre résilience logique et résilience physique. Les architectures multi-zones protègent contre les pannes applicatives et les défaillances logicielles. Elles ne compensent pas un défaut d'ingénierie dans les systèmes de contrôle industriel d'un datacenter, des systèmes auxquels ni les clients ni leurs auditeurs n'ont accès direct.
Infrastructure critique : une désignation, puis une panne
Le calendrier réglementaire ajoute une dimension particulièrement instructive. En juillet 2026, le Trésor britannique a officiellement désigné Google Cloud EMEA Limited, avec AWS, Microsoft Azure et Oracle, comme « tierce partie critique » du système financier britannique. Première en Europe, cette désignation reconnaissait la dépendance systémique des institutions financières au cloud public. Trois mois plus tard, l'un de ces prestataires désormais réglementés enregistrait la panne la plus médiatisée de l'année au Royaume-Uni.
Pour les organisations soumises à DORA, le règlement européen sur la résilience opérationnelle numérique applicable depuis janvier 2025, l'incident est une démonstration concrète : les tests de continuité doivent intégrer des scénarios de défaillance chez les fournisseurs cloud critiques, pas seulement des pannes internes.
Ce que les équipes IT doivent retenir
Google a reprogrammé les PLC défaillants et s'engage à renforcer ses protocoles de test d'infrastructure physique. Mais ces mesures correctives ne résolvent pas les questions qu'une DSI devrait poser aujourd'hui.
Vos plans de continuité testent-ils réellement un scénario de panne complète d'une zone cloud pendant plusieurs heures, avec bascule effective et vérifiée vers une région alternative ? Votre architecture suppose-t-elle qu'une zone est disponible tant que le fournisseur ne déclare pas d'incident ? Ce datacenter londonien a perdu l'alimentation six minutes avant que Google détecte les premières erreurs applicatives.
Enfin, pour les organisations financières : les exigences DORA en matière de tests de résilience avec les tiers critiques sont-elles planifiées et documentées pour 2027 ?
La résilience cloud ne se lit pas seulement dans les SLA, elle se teste dans la salle des générateurs.