Une panne électrique, trois banques et la fragilité cachée du cloud

Enquête · Infrastructures critiques · Documents arrêtés au 24 octobre 2026

À 6 h 53, le mardi 20 octobre, une installation électrique d’un centre de données londonien cesse d’alimenter normalement une partie de l’infrastructure de Google Cloud. Sept minutes plus tard, les batteries de secours commencent à s’épuiser. Les générateurs n’ont pas pris le relais : selon le premier rapport technique de Google, les automates chargés de leur démarrage et de leur transfert, principal et de secours, ont échoué. Une zone informatique s’éteint. La panne déborde ensuite sur des services qui disposent pourtant encore d’électricité. S01

Dans la matinée, les clients de Revolut rencontrent des difficultés à payer, retirer de l’argent, transférer des fonds ou accéder à leurs comptes. Lloyds, Halifax et HSBC reconnaissent des perturbations de leurs services numériques. Le problème frappe aussi des entreprises et des services publics extérieurs à la finance, notamment les audiences judiciaires à distance. Le 20 octobre devient ainsi un test grandeur nature de l’une des dépendances les plus discrètes des économies numérisées : plusieurs organisations, plusieurs marques, des relations commerciales distinctes, mais une infrastructure dont l’indisponibilité peut les toucher ensemble. S02 S14 S16

Le rapport préliminaire publié par Google le 22 octobre, deux jours après les faits, permet désormais d’aller plus loin que le récit d’une simple coupure de courant. Il décrit une défaillance des contrôles électriques, puis deux mécanismes de propagation à l’intérieur du cloud : la surcharge créée par le report automatique des travaux et les appels de contrôle qui continuaient de dépendre de composants devenus injoignables. Il indique six heures et dix minutes pour l’incident principal, de 7 h à 13 h 10, heure britannique d’été. Au moment de la rédaction, il reste provisoire et Google annonce une analyse définitive. S01

Cette précision change l’enquête. Les premières questions portent sur le secours électrique. Les suivantes sur la manière de répartir les calculs et les données entre les zones. Les dernières concernent les établissements financiers : quelles fonctions reposaient sur cette région, quelles bascules étaient prévues et quels délais avaient été acceptés ? Google a commencé à documenter les deux premiers niveaux. Les banques et les autorités doivent encore éclairer le troisième.

Sept minutes entre l’électricité et l’arrêt des machines

Un grand centre de données dispose normalement de plusieurs étages de protection électrique. Lorsque l’alimentation extérieure devient indisponible, des UPS, alimentations sans interruption, maintiennent les équipements sous tension grâce à des batteries. Des groupes électrogènes doivent ensuite reprendre la charge pour que le fonctionnement puisse se prolonger. Le transfert exige une coordination de contacteurs, d’ordres de démarrage et de vérifications de sécurité. S01

Google décrit une perturbation du réseau électrique à 6 h 53 BST, dans l’installation hébergeant la zone de disponibilité europe-west2-b. La charge bascule immédiatement sur les batteries. Les PLC, automates programmables industriels chargés de piloter le démarrage et le transfert vers les générateurs, n’accomplissent pas leur fonction. Le rapport indique que le contrôleur principal et le contrôleur de secours sont concernés. À partir de 7 h, les batteries s’épuisent et des serveurs, équipements réseau et unités de stockage perdent leur alimentation. S01

Méthode et limites

Horaires locaux BST convertis depuis le rapport préliminaire Google publié le 22 octobre. Sept minutes = intervalle entre 6 h 53 et 7 h 00, et non autonomie nominale garantie des batteries. L’état mécanique des groupes électrogènes, le fournisseur de colocation et la cause commune éventuelle des deux échecs PLC ne sont pas établis publiquement. L’ordre graphique résume la séquence documentée.

Le détail est important. Un générateur peut exister, avoir été entretenu et rester incapable de prendre la charge faute d’un ordre de démarrage ou de transfert correct. Une alimentation redondante n’offre une protection réelle que si les commandes, leurs dépendances et la séquence complète fonctionnent pendant la crise. Le rapport de Google documente l’échec des deux automatismes ; il n’explique pas encore pourquoi ils ont échoué ensemble. Une cause commune, telle qu’une configuration ou une dépendance partagée, constitue une piste technique à examiner, pas une conclusion établie. S01

Google précise que les équipes sur place ont pu rétablir une alimentation stable du réseau dans l’heure, puis remettre à zéro et tester les contrôleurs des générateurs. La remise en route de la plateforme a demandé beaucoup plus longtemps : il fallait isoler les éléments défaillants, vérifier les équipements, réactiver progressivement les services et laisser se résorber les travaux accumulés. La durée de la coupure électrique, celle de la panne informatique et celle ressentie par le client final appartiennent donc à trois calendriers différents. S01

Le centre de données concerné était exploité dans une installation tierce, selon la déclaration transmise par Google à Reuters. Nous n’avons pas trouvé, dans les pièces consultées, de nom public confirmé pour son exploitant ni de contrat détaillant la répartition des responsabilités électriques entre les parties. L’attribution de la panne à une installation extérieure ne permet pas d’en déduire à elle seule la responsabilité contractuelle de cette défaillance. S04

Le report de charge et les dépendances entre zones

La région Google Cloud de Londres, appelée europe-west2, comprend plusieurs zones de disponibilité. Une zone désigne un ensemble d’installations où des ressources informatiques peuvent fonctionner avec une certaine autonomie matérielle. Les clients peuvent répartir leurs applications et leurs bases de données entre ces zones pour traverser des incidents localisés. Ce principe améliore la résilience, mais son efficacité dépend du service utilisé, de sa configuration et des capacités disponibles ailleurs. S01 S10

Quand europe-west2-b devient inaccessible, Google décrit d’abord un mouvement attendu : les mécanismes de routage et des applications redirigent des tâches vers europe-west2-a et europe-west2-c, restées opérationnelles. Ce report augmente brutalement la demande sur leurs capacités de calcul. Les bases de données à haute disponibilité doivent elles aussi basculer. Files d’attente, attente de ressources et achèvement différé de certains transferts provoquent des erreurs intermittentes, notamment des réponses HTTP 500 et 503, qui signifient respectivement une erreur côté serveur et une indisponibilité de service. S01

Un second mécanisme est moins visible : certains services régionaux utilisent un plan de contrôle, c’est-à-dire les composants chargés de décider où lancer une tâche, vérifier une configuration ou consulter des métadonnées. Selon Google, des appels synchrones continuaient de viser des composants de catalogue ou de métadonnées situés dans la zone éteinte. L’appel attend alors une réponse qui ne vient pas, jusqu’à expiration de son délai. Des opérations demandées depuis les zones toujours alimentées pouvaient ainsi ralentir ou échouer. S01

Méthode et limites

Reconstitution conceptuelle directement tirée des causes techniques publiées par Google le 22 octobre. Les zones A et C sont bien citées comme pouvant subir des effets indirects. Les tailles des blocs, les flèches et les deux parcours n’encodent ni volume de trafic ni causalité bancaire propre à une banque.

Cette propagation distingue deux formes de redondance. La redondance matérielle prévoit d’autres serveurs pour reprendre le travail. La redondance fonctionnelle exige que ces serveurs disposent aussi des capacités, données, autorisations et services de contrôle nécessaires pour accomplir ce travail. Une deuxième salle vide, déjà saturée ou dépendante d’un composant resté dans la première, apporte une protection plus limitée que ne le suggère une simple carte de trois zones.

Plusieurs bascules multizones ont fonctionné pendant l’incident. Selon le rapport Google, des services de données comme Cloud SQL, AlloyDB et Bigtable ont transféré leurs opérations vers des zones voisines. Le problème réside dans la capacité à absorber le basculement et dans les dépendances transversales qui l’accompagnent. La documentation de reprise après sinistre de Google rappelle elle-même qu’une restauration rapide demande des choix d’architecture explicites et, pour les services les plus exigeants, des ressources de secours et une automatisation coûteuses. S01 S10

Six heures dix chez Google, davantage de perturbations chez certains clients

Le premier signal public de Google mentionnait 7 h 08 BST comme début du problème. Le rapport préliminaire reconstruit désormais trois étapes distinctes : la coupure électrique à 6 h 53, la dégradation informatique comptabilisée à 7 h, puis la détection par les systèmes de supervision à 7 h 08. La différence tient à la nature de ces horodatages. Les confondre fausserait la chronologie de la reprise. S01

Google situe la fin de la première phase de perturbations, affectant les principaux services, à 12 h 29. La création de nouvelles machines virtuelles reprend à 12 h 46. À 13 h 10, plus de 99 % des machines virtuelles Compute Engine sont déclarées dans un état sain, et la grande majorité des charges clients a retrouvé sa disponibilité. La notification de clôture n’arrive qu’à 15 h 03, après le traitement d’une petite partie résiduelle des incidents. Le chiffre de 99 % concerne les machines virtuelles de ce produit, à ce moment donné : il ne mesure ni le nombre de banques rétablies ni celui des clients capables de payer. S01

Méthode et périmètre

Source primaire : rapport Google du 22 octobre. La barre rouge couvre 7 h à 13 h 10, soit 370 minutes ; la partie bleu-vert marque le délai entre le rétablissement majoritaire et la clôture administrative à 15 h 03. Les événements de 6 h 53, 7 h 08, 12 h 29 et 12 h 46 apparaissent dans des cartes séparées pour préserver la lisibilité ; le graphique n’est pas un enregistrement minute par minute de disponibilité bancaire.

La banque Revolut montre combien la reprise d’une application peut s’écarter de celle de son fournisseur. À 18 h BST, soit près de cinq heures après le rétablissement majoritaire déclaré par Google, Reuters observe que six des vingt-sept catégories de services présentées sur la page de statut britannique de Revolut sont indiquées comme opérationnelles. Les autres, dont les paiements par carte, les virements et les retraits, sont encore signalées comme perturbées. Dans une actualisation de 20 h 14, heure de Paris, MoneyVox constate ensuite que tous les services sont opérationnels. Cet horaire est celui du constat publié ; la minute exacte du rétablissement reste à documenter. S03 S12

Les 6/27 décrivent un tableau de statut britannique à un instant donné. Chaque catégorie couvre des fonctions et des volumes différents ; ce ratio renseigne l’étendue des fonctionnalités signalées comme disponibles. Le nombre d’utilisateurs affectés et la durée propre à chaque interruption demanderaient d’autres données. De même, les six heures et dix minutes de Google mesurent son incident principal, alors que la restauration des applications clientes peut exiger de vider des files d’attente, de reconnecter des systèmes ou de vérifier des transactions. Aucune ventilation publique ne permet ici de quantifier la contribution de chacun de ces mécanismes à la reprise propre de Revolut.

Des fonctions bancaires interrompues, des architectures à documenter

Les effets financiers constatés concernent d’abord des fonctions ordinaires. Un utilisateur peut posséder des fonds parfaitement intacts tout en étant momentanément incapable de les utiliser pour payer un commerce ou effectuer un retrait. Revolut a assuré que les fonds et les données de ses clients étaient restés en sécurité, une affirmation attribuée à la banque ; elle ne fournit pas une mesure indépendante des opérations ratées ou différées. S02 S04

Lloyds Banking Group, dont fait partie Halifax, a signalé des difficultés d’accès ou d’utilisation de certains services numériques. HSBC a également reconnu des difficultés rencontrées par ses clients. Les descriptions publiques ne présentent pas des inventaires identiques : Revolut documente une gamme étendue de fonctionnalités affectées ; Lloyds et HSBC ont communiqué plus généralement sur leurs canaux en ligne. Il serait trompeur de faire comme si toutes ces banques avaient subi une interruption de la même durée ou du même périmètre. S02 S14

Méthode et limites

Sources : Reuters, AP et déclarations bancaires reproduites dans leurs articles du 20 et 21 octobre. Les constats ne portent pas sur des périmètres comparables. Aucun diagramme applicatif de Revolut, Lloyds/Halifax ou HSBC n’a été publié dans les pièces examinées. Les cartes recensent des symptômes connus et indiquent cette lacune documentaire.

Revolut attribue explicitement ses perturbations à l’incident Google Cloud. Reuters et AP rapportent également les difficultés de Lloyds/Halifax et de HSBC dans cet épisode ; les déclarations bancaires reproduites confirment ces difficultés, tandis que leur chaîne technique précise reste à documenter. L’enquête porte ainsi sur un risque commun : une dépendance partagée peut affecter plusieurs clients à la fois. Pour retracer chaque parcours, il faudrait connaître les produits utilisés, la distribution des charges entre zones, les capacités de secours et les éventuels sous-traitants intermédiaires. S02 S04 S12 S14

Il faut garder cette séparation pour ne pas transformer une cartographie conceptuelle en divulgation imaginaire d’une architecture de sécurité bancaire. Plusieurs banques peuvent être touchées par le même prestataire à travers des parcours techniques très différents : un moteur de paiement, une passerelle d’API, une chaîne de données ou un service périphérique indispensable à l’application. Le dossier disponible n’autorise pas à assigner un de ces parcours à Revolut, Lloyds ou HSBC. Il ne documente pas davantage une compromission informatique, un vol de données ou une cyberattaque comme origine de l’incident : la cause physique et l’échec des automatismes constituent les éléments aujourd’hui décrits par Google. S01

Le rayon d’impact dépasse les banques. Les services britanniques d’audiences judiciaires à distance ont signalé des problèmes sur leur plateforme vidéo ; des perturbations ont également été rapportées dans la livraison, l’immobilier et d’autres services numériques. Cette diversité importe davantage que l’accumulation de noms : l’échec d’une même région peut gêner des fonctions économiques qui n’ont aucune relation commerciale entre elles, sinon leur recours à certains étages de l’informatique externalisée. Pour plusieurs autres signalements apparus sur les plateformes de suivi, le lien causal avec Google Cloud n’a cependant pas été confirmé ; il ne faut pas les ajouter automatiquement au bilan. S02 S14 S16

Douze jours plus tôt, Londres avait joué une panne mondiale de cloud

Le 8 octobre, douze jours avant l’incident réel, le Cross-Market Operational Resilience Group (CMORG), coprésidé par la Banque d’Angleterre et UK Finance, organise son exercice SIMEX26. Son scénario : une perturbation mondiale des services cloud. La banque centrale indique que 38 grandes banques et infrastructures de marché importantes y ont participé, aux côtés des autorités. Le communiqué a été publié le 9 octobre. S05

Le rapprochement a quelque chose de saisissant, mais mérite de rester exact. Le scénario SIMEX26 concernait une panne globale hypothétique, alors que l’événement du 20 octobre a une origine localisée dans une zone londonienne, avec des répercussions plus larges. Le nombre 38 correspond aux participants de la simulation. Il ne donne aucune indication sur le nombre de banques réellement touchées douze jours après, ni sur l’ampleur des pertes, ni sur la rapidité de leurs plans de continuité. La Banque d’Angleterre n’a pas publié, dans ce communiqué, d’évaluation individuelle des résultats de l’exercice. S05

Méthode et périmètre

Chronologie institutionnelle non proportionnelle au temps. 13 juillet : entrée en vigueur des quatre désignations britanniques. 8 octobre : exercice impliquant 38 institutions ; 20 octobre : incident et lettre parlementaire ; 22 octobre : rapport préliminaire Google. Le 4 novembre 2026 et le 20 janvier 2027 sont des dates de réponse demandées, pas des dates de publication garanties.

L’exercice documente une préparation collective à un scénario précis. Pour évaluer son apport lors de l’incident réel, il faudrait rapprocher les fonctions testées, les procédures de chaque participant et les résultats de la simulation. Le communiqué laisse ce bilan individuel ouvert. Le retour d’expérience du 20 octobre devra établir les plans déclenchés, leurs délais et les services essentiels effectivement maintenus.

Les nouveaux contrôles réglementaires font leurs premiers pas

Depuis le 13 juillet 2026, Google Cloud EMEA Limited est l’une des quatre entreprises désignées Critical Third Party par le Trésor britannique, avec des entités d’Amazon Web Services, de Microsoft et d’Oracle. Ce statut permet à la Banque d’Angleterre, à la Prudential Regulation Authority et à la Financial Conduct Authority d’exercer une supervision conjointe, centrée sur les services dont la défaillance pourrait menacer la stabilité ou la confiance dans le système financier britannique. Le régime existait depuis janvier 2025, mais les premières désignations individuelles sont entrées en vigueur en juillet 2026. S06 S15

Le dispositif européen est distinct. Le règlement DORA, applicable depuis le 17 janvier 2025, organise la gestion des risques informatiques dans le secteur financier de l’Union et la surveillance de prestataires technologiques critiques. Les autorités européennes ont publié en novembre 2025 une liste de 19 prestataires critiques, dont Google Cloud EMEA Limited. La désignation repose notamment sur les dépendances documentées dans les registres contractuels des entités financières, l’importance des services rendus et leur substituabilité. Une interruption survenue à Londres peut concerner des clients européens, mais le droit britannique et DORA ne doivent pas être traités comme un régime unique. S08 S09

Le 21 octobre, Reuters rapporte que l’Autorité bancaire européenne a pris contact avec Google pour comprendre l’incident et ses conséquences possibles pour les établissements de l’Union. La FCA britannique lui confirme également des échanges avec le fournisseur. Ces échanges ouvrent une collecte d’informations sur l’incident. Les conclusions sur la conformité et ses éventuelles suites restent à produire. S04

Le Parlement britannique a demandé des comptes de manière particulièrement précise. Dans une lettre datée du 20 octobre, la présidente de la commission du Trésor, Meg Hillier, demande aux autorités quand elles ont été alertées, combien d’entreprises financières et de consommateurs ont été touchés, quels services ont été indisponibles, combien de temps et quelles pertes ou réparations ont été constatées. Elle réclame un premier retour pour le 4 novembre 2026 et une réponse complète pour le 20 janvier 2027. Ces échéances sont des demandes parlementaires, sans préjuger du contenu ni de la date effective de publication. S07

Le centre de gravité de la responsabilité se situe aussi chez les banques. La doctrine britannique impose aux établissements concernés d’identifier leurs services métiers importants, de définir des tolérances d’impact, c’est-à-dire le niveau maximal de perturbation acceptable, puis de démontrer qu’ils peuvent tenir ces limites dans des scénarios graves mais plausibles. L’externalisation d’une fonction ne transfère pas la responsabilité réglementaire de fournir le service au client. S11

Cette responsabilité ne permet pourtant pas de juger aujourd’hui une banque particulière. Pour dire qu’une tolérance a été dépassée, il faudrait connaître le service officiellement classé important, la tolérance adoptée, l’étendue réelle des défaillances, les contournements accessibles au client et les preuves de leur mise en œuvre. Les documents publics examinés ne réunissent pas ces pièces. L’annonce d’un service « rétabli » apporte une information utile sur son état, beaucoup moins sur le préjudice subi pendant l’interruption.

Le coût de la résilience et la tentation du multi-cloud

Un second fournisseur peut sembler offrir une réponse à cette dépendance. Diversifier peut réduire la dépendance à certaines causes communes, à condition que les applications puissent réellement fonctionner ailleurs. Une application capable de redémarrer sur un autre cloud demeure vulnérable si ses données y sont absentes, si la réplication est trop lente, si ses secrets d’accès dépendent d’un service indisponible ou si personne n’a testé la manœuvre. S10

Deux mesures techniques rendent ces arbitrages intelligibles. Le RTO (recovery time objective) fixe la durée de reprise visée après un incident. Le RPO (recovery point objective) fixe la perte maximale de données admissible, généralement exprimée par la durée séparant le dernier point de reprise récupérable du moment de l’incident. Un paiement bancaire pose une difficulté particulière : une reprise rapide qui ne permet pas de déterminer si une opération a été autorisée, enregistrée ou réglée peut créer un problème plus grave qu’un retard correctement identifié. La documentation de Google souligne que les modes de réplication et de bascule déterminent concrètement ces deux objectifs. S10

Une architecture active sur plusieurs régions implique des ressources permanentes, des réplications, des procédures d’arbitrage des données et des exercices réguliers. La présence de deux fournisseurs peut ajouter des dépendances opérationnelles, contractuelles et humaines. Une protection graduée peut associer fonctionnement multizone, secours régional pour certaines fonctions et procédures manuelles ou dégradées lorsque leur délai de reprise le permet. Pour juger ces choix, il faut les rapporter au préjudice potentiel d’une interruption et à la probabilité des scénarios envisagés. S10 S11

L’objection à la critique des grands clouds est solide : mutualiser des infrastructures et des équipes spécialisées peut offrir une fiabilité, une capacité de surveillance et une vitesse de restauration supérieures à celles de nombreux centres informatiques isolés. Le dossier du 20 octobre ne mesure pas une fréquence d’incidents comparable entre ces modèles. Il démontre, plus précisément, comment une dépendance partagée fait circuler une défaillance au-delà de son emplacement initial et oblige plusieurs opérateurs économiques à reprendre leur activité en même temps.

Cette dépendance prolonge notre enquête sur les fournisseurs invisibles du risque bancaire européen. Les dossiers CDK et Synnovis suivent la propagation d’une interruption chez un prestataire commun ; le prix de la reprise examine les moyens et les tests engagés avant une crise. Les causes de ces épisodes diffèrent, mais chacun permet d’examiner un service et ses dépendances à partir de documents précis.

Les documents qui manquent pour mesurer le risque réel

Quatre ensembles de pièces permettraient d’aller au bout de l’enquête. D’abord le rapport définitif de Google : la cause exacte de l’échec des PLC principal et de secours, les tests de bascule antérieurs, la topologie des automatismes et les engagements du gestionnaire du site tiers. Ensuite, les relevés d’impact de chaque banque : fonctions interrompues, début et fin par service, transactions refusées ou différées, et procédures alternatives. Viennent les données de capacité et les plans de continuité effectivement testés dans les architectures clientes, puis les conclusions des autorités sur les notifications, la conformité et le préjudice pour les usagers. Au 24 octobre, ces éléments ne sont pas réunis dans le dossier public consulté. S01 S04 S07

Sans ces pièces, un chiffrage des pertes bancaires serait spéculatif. Les tableaux de statut renseignent l’accessibilité de fonctions, les déclarations attestent certains incidents et les comptes clients donnent la taille potentielle d’une population, sans prouver combien de personnes ont effectivement échoué à payer ni pour quel montant. Le courrier parlementaire a précisément demandé aux autorités de produire cette mesure. S07

L’épisode du 20 octobre laisse néanmoins une constatation ferme. La région londonienne a disposé de plusieurs zones et de mécanismes de reprise, qui ont effectivement permis à certaines charges de basculer. Leur activation a révélé les limites des capacités disponibles et de certaines dépendances de contrôle. Les perturbations bancaires rapportées présentent des périmètres et des durées différents ; chez Revolut, la dégradation a persisté après le rétablissement majoritaire déclaré par Google. La suite de l’enquête se jouera dans les contrats, les journaux d’incident et les tolérances opérationnelles que les régulateurs demanderont à examiner. S01 S03 S11

Sources et périmètre de vérification

Documents consultés jusqu’au 24 octobre 2026. Les heures de l’incident technique utilisent BST (UTC+1) ; les heures de Paris sont signalées comme telles (CEST, UTC+2). Les documents intéressés sont attribués à leur émetteur ; les résumés de presse servent notamment à recouper les services bancaires affectés. Une version provisoire de Google n’est pas assimilée à un rapport d’audit indépendant.

1. [S01] Google Cloud, rapport préliminaire d’incident.Publié le 22 octobre 2026 ; incident du 20 octobre, 7 h-13 h 10 BST. Chronologie détaillée, échec des automates principal et de secours, bascules et files d’attente. Rapport définitif annoncé, sans date confirmée.
2. [S02] Reuters, Anhata Rooprai, panne de Google Cloud et services britanniques.Publié le 20 octobre 2026 ; déclarations d’organisations affectées et précautions sur les signalements non reliés.
3. [S03] Reuters, état de Revolut.Publié le 20 octobre 2026 ; photographie de la page britannique à 17 h UTC, six services opérationnels sur vingt-sept.
4. [S04] Reuters, Phoebe Seers et Elizabeth Howcroft, régulateurs européens.Publié le 21 octobre 2026 ; contact de l’EBA et de la FCA, localisation dans une installation tierce selon Google. Les échanges des autorités n’établissent aucune sanction.
5. [S05] Bank of England, communiqué SIMEX26.Publié le 9 octobre 2026, exercice tenu le 8 octobre. 38 participants = institutions associées à l’exercice, sans rapport avec le nombre de victimes de la panne du 20.
6. [S06] Financial Conduct Authority, régime Critical Third Parties.Publié le 10 juillet 2026, premières désignations effectives le 13 juillet. Établit la supervision ciblée et les obligations persistantes des institutions financières.
7. [S07] UK Parliament, Treasury Committee, lettre signée par Meg Hillier.Datée du 20 octobre 2026. Neuf questions sur l’incident ; réponses demandées au 4 novembre 2026 et au 20 janvier 2027. Lettre de deux pages.
8. [S08] ESMA / EBA / EIOPA, désignation de prestataires critiques DORA.Publié le 18 novembre 2025 ; 19 prestataires désignés, Google Cloud EMEA Limited inclus.
9. [S09] Union européenne, règlement (UE) 2022/2554 DORA.Texte du 14 décembre 2022, applicable depuis le 17 janvier 2025 ; notamment dispositions relatives aux prestataires informatiques critiques.
10. [S10] Google Cloud, documentation d’architecture de reprise après sinistre.Documentation mise à jour le 10 mai 2024, consultée le 24 octobre 2026 ; principes généraux de reprise, distincts de l’architecture des banques touchées.
11. [S11] Bank of England / PRA, SS1/21, résilience opérationnelle.Version publiée le 11 mars 2022, effective le 31 mars 2022 ; services métiers importants, tolérances d’impact et responsabilité des établissements (§§ 2.2, 3.1 et 4.5). Consultée le 24 octobre 2026.
12. [S12] MoneyVox, suivi français de la panne Revolut.Publié le 20 octobre 2026 à 13 h 19, mis à jour à 20 h 19 ; statut opérationnel rapporté dans une actualisation de 20 h 14, heure de Paris.
13. [S13] Uptime Institute, Owen Rogers, analyse indépendante.Octobre 2026 ; met en perspective le rapport préliminaire et les limites de responsabilité entre colocation, cloud et clients.
14. [S14] Associated Press, établissements et services affectés.Publié le 20 octobre 2026 ; corroboration de la perturbation des banques, sans documentation de leur topologie applicative.
15. [S15] HM Treasury, désignation des quatre prestataires critiques.Publié le 10 juillet 2026 ; entrée en vigueur annoncée le 13 juillet 2026.
16. [S16] Law Society Gazette, Matilda Battersby, audiences à distance.Publié le 20 octobre 2026 à 14 h 03 BST ; reprend la communication du service des cours et tribunaux HMCTS sur sa Cloud Video Platform, sans établir son architecture Google interne.