Le mardi 20 octobre 2026, à 7 heures à Londres, une partie des serveurs de Google Cloud dans sa région europe-west2 cesse de répondre. Selon le rapport d’incident publié par Google le 27 octobre, l’impact principal dure 6 heures et 8 minutes. Selon la dépêche de Reuters du 21 octobre, Revolut, Lloyds et HSBC figurent parmi les banques touchées ; chez Revolut, connexion, paiements par carte et retraits sont perturbés. L’Autorité bancaire européenne dit avoir pris contact avec Google Cloud pour évaluer l’impact sur les entités financières de l’Union ; la Financial Conduct Authority britannique dit « échanger » avec Google et les établissements touchés, selon City AM.
Le 28 octobre, au lendemain de ses résultats trimestriels, le directeur général de l’éditeur suisse de logiciels bancaires Temenos, Takis Spiliopoulos, déclare à Reuters que les offres européennes de cloud et d’IA souverains ne sont « pas encore à un niveau de maturité » suffisant pour que les grandes banques les envisagent sérieusement (traduit par ELMARQ). Il constate que l’ouverture de centres de données locaux par les fournisseurs américains n’a pas levé les doutes sur l’endroit d’où les données peuvent être consultées, et cite comme obstacles les opérations transfrontalières et les exigences réglementaires des banques présentes dans plusieurs pays. Au même moment, la proposition de la Commission européenne sur le cloud et l’IA, qui crée une grille de souveraineté des fournisseurs, attend l’examen du Parlement européen.
Le besoin de souveraineté des banques progresse plus vite que les solutions, et faute d’instance qui tranche, le choix se fait par défaut : rester chez l’hyperscaler, en y ajoutant de la redondance.
Ce que disent le rapport de Google et les autorités
Le centre de données qui héberge la zone europe-west2-b repose sur une double alimentation électrique. Ce jour-là, l’une des 2 arrivées était consignée pour réparation, après des anomalies relevées lors d’un test des groupes électrogènes le 14 octobre. À 6 h 53, un défaut de câble souterrain, hors du site, coupe l’autre arrivée. L’automate chargé de démarrer les groupes ne lance pas l’ordre : il détecte une tension sur la ligne pourtant isolée et conclut qu’une source saine est disponible. Les batteries, dimensionnées pour 5 minutes, s’épuisent. Les serveurs de la zone s’arrêtent à 7 heures.
Le trafic est redirigé vers les 2 autres zones de la région, qui saturent. Google écrit que « certaines bascules ont échoué en raison de contraintes de capacité » et que des clients installés dans les zones épargnées ont subi un « impact inattendu » (traduit par ELMARQ). Le rapport rappelle que les machines virtuelles d’une zone exigent que le client prévoie lui-même ses ressources de repli. Le gros des services est rétabli à 13 h 08, et Google promet de vérifier d’ici le 15 novembre les automates de tous ses sites de même architecture.
Le cadre réglementaire est établi. Le règlement européen sur la résilience opérationnelle numérique du secteur financier (DORA) s’applique depuis le 17 janvier 2025. Le 18 novembre 2025, les 3 autorités européennes de surveillance ont publié la liste des 19 prestataires informatiques désignés comme critiques et placés sous leur surveillance directe. Google Cloud EMEA Limited y figure, comme Amazon Web Services EMEA et Microsoft Ireland Operations. Au Royaume-Uni, Google Cloud EMEA Limited est désigné tiers critique depuis le 13 juillet 2026, par un texte réglementaire, soit 99 jours avant la panne selon un calcul d’ELMARQ ; selon Reuters, ce régime l’oblige à signaler ses pannes graves à la FCA et à la Banque d’Angleterre.
Ce que les pièces ne disent pas encore
Le rapport de Google ne nomme aucun client. La liste des banques touchées repose sur Reuters ; City AM y ajoute Barclays, où des problèmes ont été signalés. Le nombre de clients privés de service, la durée de l’interruption par banque et un éventuel préjudice ne sont pas publiés. Ce sont les questions que la présidente de la commission du Trésor de la Chambre des communes, Meg Hillier, a posées le 20 octobre au gouverneur de la Banque d’Angleterre et au directeur général de la FCA, parmi 9, dans une lettre qui demande aussi quand et par qui les autorités ont été alertées, et quelles leçons les banques doivent tirer pour leur propre résilience.
On ignore aussi pourquoi certaines banques ont décroché quand d’autres clients de la région ont tenu : architecture limitée à une zone, bascule prévue mais saturée, ou dépendance indirecte par un logiciel hébergé chez Google. Aucune pièce ne permet de trancher. La formule de « premier test majeur » des nouvelles règles est celle de Reuters, et aucune autorité n’a annoncé de mesure.
Le jugement de Temenos, enfin, est l’appréciation d’un acteur du marché, pas un constat. Il a été formulé dans un entretien à Reuters, et le communiqué de résultats du 27 octobre n’évoque pas la souveraineté, mais son directeur général s’y dit « particulièrement satisfait » de la performance en Europe (traduit par ELMARQ). Temenos vend des logiciels bancaires, notamment en mode SaaS, et a annoncé le 11 mars 2026 que cette offre « fonctionne nativement sur Azure », avec des ventes conjointes avec Microsoft. Cela ne rend pas son diagnostic faux : cela signifie que celui qui juge l’alternative immature a un intérêt dans l’offre installée.
Le mécanisme : une redondance qui dépend d’une seule chaîne
La panne du 20 octobre montre que la résilience d’une banque dans le cloud ne se joue pas là où elle se négocie. Le contrat porte sur un fournisseur, une région, des niveaux de service. La défaillance est venue d’un câble public, d’un automate mal configuré et d’une maintenance en cours, dans un bâtiment exploité par un tiers. Une banque peut répartir ses serveurs sur 3 zones et rester dépendante d’une seule chaîne de décisions qu’elle ne voit pas.
La saturation des zones voisines en donne la mesure. Une architecture multizone protège contre la perte d’un bâtiment si les autres peuvent absorber la charge au même moment, pour tous les clients à la fois. Quand de nombreux établissements partagent la même région, leurs plans de secours tirent sur la même réserve.
C’est le risque que DORA nomme sans le plafonner. L’article 29 impose d’évaluer, avant un contrat, si un prestataire est « facilement substituable » et si les fonctions critiques se concentrent chez un même fournisseur. L’article 28 exige des plans de sortie « soumis à des tests suffisants ». Mais le considérant 67 écarte « tout plafond rigide », pour ne pas « restreindre la liberté contractuelle ». Le droit organise la mesure de la dépendance ; il ne la limite pas.
La proposition de la Commission ne change pas cette donnée pour les banques. Le texte du 3 juin 2026, qui relève que 3 hyperscalers non européens contrôlent plus de 70 % du marché européen du cloud, crée 4 niveaux d’assurance de l’Union (annexe II). Ils vont d’un fournisseur établi dans l’Union, avec des données qui y restent, jusqu’à l’exclusion de tout contrôle par un pays tiers et au contrôle effectif de la chaîne logicielle. Ces obligations visent les acheteurs publics. Les entités privées des secteurs de la directive NIS2, dont le secteur bancaire, « peuvent » mener des évaluations similaires (article 31) ; la Commission pourrait l’imposer par acte délégué.
L’arbitrage déplacé : 4 instances, un choix par défaut
Qui décide du degré de dépendance acceptable d’une banque à un fournisseur ? La réponse se répartit entre 4 instances, dont aucune ne tient la décision entière.
La banque porte la responsabilité : DORA dispose qu’elle reste « à tout moment pleinement responsable » de ses obligations quand elle sous-traite, et Reuters rappelle que le droit britannique dit la même chose. Le régulateur surveille le prestataire, mais sa désignation constate une criticité sans désigner d’alternative, et le texte lui interdit de plafonner la concentration. La Commission propose une grille de souveraineté pour l’achat public et laisse le secteur bancaire à l’appréciation de chaque établissement. Le fournisseur dessine l’architecture, fixe la capacité de repli des zones et renvoie au client la charge de prévoir ses secours.
Entre ces instances, le choix par défaut s’opère sans être décidé. Une banque qui juge, avec Temenos, l’offre souveraine immature, et qu’aucune autorité n’oblige à en changer, ajoute des zones, des régions ou un 2e hyperscaler. Le 12 juin, dans notre analyse du paquet européen du 3 juin, nous établissions que la grille des 4 niveaux était déjà un outil d’acheteur utilisable ; la panne de Londres montre qu’une banque peut s’en servir, mais qu’aucune règle ne l’y oblige. Tant que personne ne fixe le niveau de dépendance acceptable, il est fixé par l’offre disponible.
Les dates qui diront qui arbitre
D’ici le 31 octobre, Google prévoit de rétablir la double alimentation du site et de refaire un test complet de transfert de charge ; d’ici le 15 novembre, de vérifier ses automates sur tous les sites de même architecture.
Le 4 novembre 2026, la Banque d’Angleterre et la FCA doivent adresser une 1re réponse à la commission du Trésor, puis une réponse complète le 20 janvier 2027 ; lettre et réponses seront publiées. Si elles chiffrent les clients privés de service par établissement, la responsabilité des banques deviendra mesurable ; si elles s’en tiennent au prestataire, la question restera celle du fournisseur.
Au Parlement européen, la procédure 2026/0138 attend la décision des commissions de l’industrie et du marché intérieur, sans date de vote publiée. Un amendement rendant obligatoire pour les banques l’évaluation facultative de l’article 31 déplacerait l’arbitrage vers le législateur. Une fois adopté, le règlement ne s’appliquera que 1 an après son entrée en vigueur, elle-même fixée 20 jours après sa publication au Journal officiel.
Déroulé de la panne : rapport d’incident de Google Cloud du 27 octobre 2026, heures converties en heure de Londres. Banques touchées et démarches de l’Autorité bancaire européenne et de la Banque d’Angleterre : dépêche de Reuters du 21 octobre 2026, reprise par The Star ; FCA et Barclays : City AM du 20 octobre 2026 ; questions et échéances de la commission du Trésor : sa lettre du 20 octobre 2026 ; désignation de Google Cloud EMEA Limited : texte réglementaire 2026/777, cité par cette lettre. Propos de Takis Spiliopoulos : dépêche de Reuters du 28 octobre 2026, signée Emanuele Berro ; résultats et partenariat de Temenos : communiqués des 27 octobre et 11 mars 2026. DORA cité d’après le Journal officiel du 27 décembre 2022 (articles 28, 29, 64, considérant 67) ; NIS2 d’après son annexe I ; prestataires critiques d’après la liste du 18 novembre 2025 ; proposition COM(2026) 502 d’après son texte, son annexe II et l’Observatoire législatif, consulté le 29 octobre 2026. Le délai d’application du règlement est un calcul d’ELMARQ. Citations de l’anglais traduites par ELMARQ.
