Panne Google Cloud : une seule zone a suffi à paralyser trois banques

Mardi 20 octobre 2026, une panne Google Cloud a privé des millions de clients de Revolut, Lloyds et HSBC de leurs paiements, virements et retraits pendant plusieurs heures. Selon Les Echos, il s'agissait d'une panne électrique. Les tribunaux d'Angleterre et du pays de Galles ont perdu, eux, leur système d'audiences à distance pour toute la matinée.

Le détail technique compte plus que le nom des victimes : une seule zone d'un data center londonien est tombée. Or l'architecture du cloud est justement conçue pour qu'une zone puisse tomber sans conséquence visible. Si des banques dotées d'équipes d'ingénieurs entières se sont arrêtées, la question mérite d'être posée pour vos propres outils.

Le 20 octobre, une matinée sans paiements ni audiences

Google a attribué l'incident à un « power event » survenu dans ses installations de Londres. La défaillance concerne une zone précise : europe-west2-b, l'une des zones de la région europe-west2, qui couvre la capitale britannique.

Chez Revolut, l'application cesse de répondre dès le matin. Inscription, connexion, paiement par carte, virements, retraits aux distributeurs et services crypto sont touchés. D'après Clubic, des clients sont bloqués jusqu'en France. Halifax, qui appartient au groupe Lloyds, signale sur X que certains clients ne peuvent plus se connecter, ni par l'application ni par le site. Côté HSBC, les clients se plaignent de ne plus accéder à leurs comptes.

La justice est touchée elle aussi. Le service de vidéoconférence des tribunaux reste inutilisable toute la matinée. Il permet notamment aux prévenus en détention de comparaître sans transfert physique. Plusieurs audiences auraient été repoussées.

La liste s'allonge : le portail immobilier Rightmove, le site satirique NewsThump et, selon certaines informations, Royal Mail et DPD.

Google annonce un retour progressif vers 13 h, heure de Londres, puis un service rétabli pour la plupart de ses clients vers 15 h. IT for Business parle d'une zone éteinte plus de cinq heures. Le redémarrage n'a pas été uniforme : vers 17 h, Revolut n'indiquait encore que 6 services opérationnels sur 27 sur sa page de statut, parmi lesquels le chat d'assistance et les virements internes.

Pourquoi Revolut et d'autres banques sont en panne pour une seule zone

Une région Google Cloud est découpée en plusieurs zones. Chacune dispose de ses propres ressources d'alimentation, de refroidissement et de réseau, pour qu'un incident local ne se propage pas aux voisines. Google, AWS et Microsoft Azure suivent tous ce modèle, et leur documentation recommande la même règle de base : répartir les services critiques sur au moins deux zones.

Sur le papier, la perte d'europe-west2-b aurait donc dû passer inaperçue pour des clients bien configurés. Ce n'est pas ce qui s'est produit. Google a promis de publier son analyse une fois l'enquête interne terminée. En attendant, plusieurs hypothèses techniques restent ouvertes, et je les présente comme telles :

• un composant resté sur une seule zone, par exemple une base de données ou un service d'authentification ;
• un basculement automatique qui n'a pas fonctionné comme prévu sous la charge ;
• une dépendance indirecte, via un prestataire lui-même hébergé dans cette zone.

La déclaration initiale de Lloyds, qui évoquait des problèmes similaires chez d'autres organisations, et l'analyse de Frandroid, qui situe l'origine hors de la néobanque, pointent vers le fournisseur. Cela n'exclut pas des faiblesses côté client.

Le cas Revolut illustre un principe simple : la disponibilité d'un système est celle de son maillon le plus faible. Si la connexion tombe, les 26 autres services deviennent inaccessibles, même s'ils tournent encore. Et rétablir le courant ne suffit pas. Un système distribué doit ensuite resynchroniser ses données et vider ses files d'attente, ce qui peut expliquer, sans que ce soit confirmé, l'écart entre 15 h et 17 h.

Panne Google Cloud : le premier vrai test pour les régulateurs britanniques

Cet été, la Financial Conduct Authority (FCA) et la Banque d'Angleterre ont obtenu le pouvoir de réguler directement les fournisseurs de services cloud jugés critiques pour le secteur financier britannique. Google en fait partie. L'incident du 20 octobre est le premier test majeur de ce dispositif.

La FCA a confirmé être en contact avec Google pour obtenir plus d'informations. La Prudential Regulation Authority, rattachée à la Banque d'Angleterre, échange également avec l'entreprise. Le régulateur a rappelé que les clients doivent pouvoir accéder à leur argent et payer, et qu'il attend des banques une correction rapide, une information claire et l'absence de pertes pour les clients.

La réaction des régulateurs est elle-même surveillée. Meg Hillier, présidente de la commission du Trésor à la Chambre des communes, leur a écrit pour savoir comment ils ont réagi et mesurer l'impact sur le système financier. Elle attend une première réponse d'ici le 4 novembre.

Côté européen, le règlement DORA (Digital Operational Resilience Act), applicable depuis le 17 janvier 2025, suit la même logique : les fournisseurs informatiques critiques des établissements financiers passent sous la surveillance des autorités européennes.

J'en tire une conclusion pragmatique. Un régulateur peut exiger des comptes, imposer des audits, sanctionner. Il ne peut pas empêcher une coupure de courant. La continuité de service reste la responsabilité de l'entreprise qui utilise le cloud, qu'elle soit une banque ou une PME de vingt salariés.

Quels sont les risques d'une panne cloud pour une PME ?

Une TPE n'est pas une banque systémique. Une heure d'arrêt n'a ni le même coût ni les mêmes conséquences. Il serait faux de prétendre que chaque PME court le risque de Revolut. Mais l'exposition existe, et elle est souvent indirecte.

Les points sensibles reviennent toujours aux mêmes endroits :

• l'encaissement : terminal de paiement connecté, logiciel de caisse en ligne, compte dans une néobanque ;
• la prise de commande : boutique en ligne, prise de rendez-vous, formulaire de devis ;
• les outils du quotidien : messagerie et documents sous Google Workspace ou Microsoft 365 ;
• le logiciel métier en mode SaaS, dont vous ignorez souvent l'hébergeur.

C'est ce dernier point qui pose problème. Votre CRM ou votre outil de facturation tourne peut-être chez Google, AWS ou Azure, dans une seule zone, sans que vous l'ayez choisi. La liste des services touchés le 20 octobre, de Rightmove à DPD, montre qu'une même défaillance traverse des secteurs sans lien entre eux.

Pour ceux qui cherchent les trois inconvénients du cloud, je les résumerais ainsi : une dépendance technologique envers un tiers dont vous ne maîtrisez pas l'infrastructure, une activité suspendue à votre connexion internet, et une réversibilité souvent compliquée le jour où vous voulez partir.

Cela ne fait pas du cloud un mauvais choix. Un data center de Google reste en général plus fiable qu'un serveur posé dans un placard. Les incidents existent pourtant : la région parisienne europe-west9 a été coupée en avril 2023 après une infiltration d'eau suivie d'un incendie.

Continuité de service : quatre mesures à la portée d'une PME

Inutile de copier l'architecture d'une banque. La plupart des PME peuvent réduire nettement leur exposition avec des mesures simples, à condition de les préparer avant l'incident.

• Cartographier vos dépendances. Pour chaque outil, notez qui l'héberge, dans quelle région, et ce qui s'arrête s'il tombe. Cet inventaire révèle souvent des points de défaillance uniques que personne n'avait identifiés. Ce travail de cartographie est d'ailleurs un pilier central lors d'un Audit & Sécurité, où l'on suit chaque flux jusqu'à son hébergeur réel.
• Prévoir un mode dégradé. Un second compte dans une autre banque, un moyen d'encaissement de secours, un export régulier de votre fichier clients, une procédure papier pour noter les commandes. Le 20 octobre, un client de Revolut équipé d'une carte d'une autre banque continuait à payer.
• Lire votre contrat. Les engagements de disponibilité des fournisseurs cloud prévoient en général des crédits de service, pas l'indemnisation de votre perte d'exploitation. Mieux vaut le savoir avant.
• Répartir ce que vous hébergez. Si vous exploitez vos propres applications, déployez-les sur au moins deux zones et stockez vos sauvegardes dans une autre région.

Mon conseil est de tester la restauration au moins une fois par an. Une sauvegarde jamais restaurée n'est qu'une hypothèse. J'ai développé cette approche plus largement dans l'article sur la résilience numérique de votre entreprise.

Le multi-cloud n'est pas une réponse pour tout le monde

Après chaque incident de ce type, le même conseil revient : répartissez-vous entre plusieurs fournisseurs, Google Cloud et AWS par exemple. Pour une TPE ou une petite PME, c'est rarement une bonne idée.

Une architecture multi-cloud double la complexité. Il faut maîtriser deux écosystèmes, synchroniser les données entre eux et payer les frais de sortie de données que facturent les fournisseurs. Il faut aussi tester régulièrement le basculement, faute de quoi il échouera le jour où il servira. Pour une structure sans équipe technique dédiée, ce surcoût dépasse souvent le coût d'une demi-journée d'arrêt.

La redondance se dimensionne selon une question simple : combien vous coûte une heure d'indisponibilité ? Pour une boutique en ligne qui réalise l'essentiel de son chiffre sur quelques jours de soldes, une architecture sur plusieurs régions peut se justifier. Pour un cabinet de conseil, un déploiement sur deux zones chez un seul fournisseur et un plan de secours manuel suffisent dans la plupart des cas.

La souveraineté des données est un autre critère, distinct de la disponibilité. Choisir un hébergeur européen répond à une question juridique, pas forcément à une question de résilience. Un data center français peut aussi subir une défaillance électrique.

Le point le plus instructif du 20 octobre reste ailleurs. Revolut, Lloyds et HSBC disposent de moyens techniques sans commune mesure avec ceux d'une PME, et ils ont été touchés. La redondance ne se décrète pas dans un schéma d'architecture : elle se vérifie par des exercices de coupure.

Ce que cet incident dit de votre propre architecture

La défaillance d'une seule zone londonienne a suffi à bloquer des banques, des tribunaux et des transporteurs, alors que le cloud est conçu pour encaisser ce type d'événement. La résilience ne vient pas du fournisseur choisi, mais de la façon dont vos outils sont répartis, documentés et testés.

Si l'hébergeur de votre logiciel de facturation ou de votre solution d'encaissement s'arrêtait demain matin pendant cinq heures, sauriez-vous précisément ce qui continuerait à fonctionner chez vous ?

Sources : The Guardian : Google cloud failure hits millions as UK courts and banks knocked offline Les Echos : Une panne de Google Cloud affecte lourdement Revolut, Lloyds et HSBC IT for Business : Panne Google Cloud, Revolut, Lloyds et HSBC à l'arrêt Clubic : Revolut, Lloyds, HSBC, les banques britanniques dans la tourmente Frandroid : Panne Revolut, Google Cloud et son centre de données de Londres pointés du doigt