--- title: "Une zone, six heures : ce que montre la panne Google Cloud à Londres" summary: "Le 20 octobre, une panne de courant d'une zone Google Cloud à Londres a perturbé des banques pendant des heures, dont Revolut en Suisse. Causes et contrôles." author: "Samuel Krauss" author_title: "Founder" publisher: "Elchi Studios" published: 2026-10-26 updated: 2026-10-26 url: https://elchi.dev/fr/journal/une-zone-six-heures-panne-google-cloud-londres language: fr translation_of: https://elchi.dev/en/journal/one-zone-six-hours-google-cloud-outage-london tags: ["hosting","availability","cloud","operations"] words: 1427 --- # Une zone, six heures : ce que montre la panne Google Cloud à Londres *Par Samuel Krauss, Founder. Publié le 26 octobre 2026.* > Le 20 octobre, une panne de courant d'une zone Google Cloud à Londres a perturbé des banques pendant des heures, dont Revolut en Suisse. Causes et contrôles. Le mardi 20 octobre 2026, l'une des trois zones de la région londonienne de Google Cloud a perdu son alimentation électrique. Pendant plusieurs heures, des banques, des services de livraison et des boutiques en ligne au Royaume-Uni ont été totalement ou partiellement inaccessibles, et des clients de banques sur le continent européen l'ont aussi ressenti, parmi eux les clients de Revolut en Suisse. Selon Google, la cause était une défaillance de l'équipement même censé rendre une coupure de courant sans conséquence. ## Ce qui s'est passé À 05:53 UTC, l'alimentation du réseau électrique du centre de données qui abrite la zone europe-west2-b a été interrompue. Les batteries ont pris le relais, comme prévu. Les générateurs, non. Selon le rapport d'incident préliminaire de Google, ni l'automate de commande principal ni celui de secours, qui démarrent les générateurs et leur transfèrent la charge, ne se sont déclenchés. À 06:00 UTC, 08:00 en Suisse, les batteries étaient vides, et les serveurs, les commutateurs réseau et le stockage local de cette zone se sont éteints. Google chiffre la perturbation à six heures et dix minutes, jusqu'à 12:10 UTC, lorsque plus de 99 % de ses machines virtuelles Compute Engine fonctionnaient à nouveau. Google a publié son avis de clôture à 14:03 UTC et le rapport préliminaire le 22 octobre. Un rapport final avec des mesures préventives doit encore suivre. La coupure a touché une zone. Les effets ont atteint toute la région. Selon le rapport de Google, le trafic basculé a épuisé la capacité de calcul et de traitement disponible dans les autres zones, et des vérifications du plan de contrôle qui franchissent les limites entre zones ont propagé la perturbation. Regional Persistent Disk et Cloud SQL figurent parmi les services qui ont connu des problèmes de basculement et de dégradation. Pendant l'incident, la seule solution de contournement proposée par Google était de déplacer les charges de travail vers une autre zone ou région, si possible. La liste des entités touchées était longue. Reuters a fait état de perturbations chez Revolut, Lloyds et HSBC. Le service judiciaire britannique a signalé des problèmes avec la plateforme vidéo qu'il utilise pour une partie des audiences à distance. En Suisse, Revolut, qui y compte 1,3 million de clients, a signalé des problèmes de paiements par carte, de virements et de retraits d'espèces, selon Netzwoche. À 17 heures, heure suisse, une heure après que Google eut déclaré l'incident terminé, la page d'état de Revolut indiquait encore 27 de ses services en Suisse comme partiellement indisponibles. Hostinger et MongoDB Atlas ont aussi signalé des problèmes liés à la panne. Les autorités de surveillance ont réagi en moins d'un jour. L'Autorité bancaire européenne (ABE) a pris contact avec Google Cloud pour évaluer les conséquences pour les entreprises financières de l'UE. Google fait partie des 19 prestataires que les autorités européennes de surveillance ont désignés en novembre 2025 comme prestataires tiers critiques de services TIC au titre de DORA. L'ABE a ajouté une phrase qui mérite d'être lue deux fois : cette désignation ne décharge pas le prestataire de sa responsabilité en matière de gestion des incidents ni ne libère les entités financières de leurs propres obligations réglementaires. Google répond de son incident. La banque continue de répondre de son service, quel que soit l'exploitant des serveurs. ## Ce que cela signifie pour une entreprise ou une administration La première leçon se trouve dans la documentation de Google elle-même : une zone doit être considérée comme un domaine de défaillance unique au sein d'une région. Le 20 octobre, la zone était un centre de données dont les générateurs n'ont pas démarré. Tout ce qui tourne dans une seule zone, une machine virtuelle isolée, un disque, une base de données sans réplique ailleurs, partage le sort des générateurs de ce bâtiment. Ce n'est pas propre à Google. La plupart des centres de données reposent sur la même chaîne de batteries, de générateurs et de commandes automatiques, et cette chaîne peut lâcher n'importe où. La deuxième leçon est moins confortable. Répartir un service sur plusieurs zones n'a pas suffi le 20 octobre. Quand une zone a disparu, le travail est passé aux deux autres, et leur capacité est devenue insuffisante. Un plan qui compte sur de la place libre ailleurs ne fonctionne que si cette place est réservée et si le basculement a été testé sous charge. La troisième concerne le temps. Google arrive à six heures et dix minutes. Pour les clients de Revolut en Suisse, cela a duré plus longtemps. Votre panne dure jusqu'à ce que votre propre service fonctionne à nouveau, pas jusqu'à ce que la page d'état de votre fournisseur passe au vert. Le rétablissement chez Google a demandé des redémarrages échelonnés, l'écoulement des files d'attente et des contrôles de l'état et du stockage, et chaque client a sa propre version de cette liste. La quatrième concerne la chaîne. Des personnes et des entreprises qui n'ont jamais signé de contrat avec Google ont été touchées quand même, parce que leur banque ou leur hébergeur y tourne. La question est de savoir si vous connaissez le cloud dont dépendent vos propres fournisseurs, et dans combien de zones. ## Où en est Elchi Studios Nos services, et les sites d'entreprise que nous exploitons, tournent sur notre propre cluster : huit serveurs chez cinq fournisseurs dans quatre pays, la Suisse, l'Allemagne, les Pays-Bas et la France. J'ai choisi cette répartition pour que la perte d'un bâtiment ou d'une entreprise n'emporte pas tout le service avec elle. - **Deux entrées,** où arrive la connexion d'un navigateur : Hetzner à Falkenstein et UpCloud à Amsterdam. Si l'une tombe, l'autre reprend le trafic. - **Deux nœuds d'application,** qui servent en même temps : Infomaniak à Genève et Scaleway à Amsterdam. - **Trois nœuds de base de données,** à Francfort, Nuremberg et Paris. Une modification ne compte comme écrite que lorsque les trois la détiennent. La partie la moins répartie, ce sont les fichiers stockés. EMX conserve les messages et les pièces jointes chiffrés à Genève, et les photos de profil et les logos se trouvent dans le stockage objet chez Infomaniak, avec une copie nocturne chez Scaleway. Une copie nocturne protège contre la perte de fichiers. Elle ne les garde pas accessibles tant que l'emplacement d'origine est en panne. Deux autres points, dans l'esprit de la phrase de l'ABE. Premièrement, nous n'avons pas encore coupé un emplacement entier sous charge et publié le résultat. Tant que ce n'est pas fait, l'architecture ci-dessus est un plan et non une mesure, et le résultat sera publié dans ce journal, quel qu'il soit. Deuxièmement, la panne d'un fournisseur que nous avons choisi est notre panne. Pour les projets clients hébergés, nous promettons 99,99 % par an, et les pannes des hébergeurs et des services DNS que nous avons choisis sont imputées sur cet engagement, comme nous l'avons expliqué lorsque nous avons [ramené cette promesse de 99,999 % à 99,99 %](https://elchi.dev/fr/journal/pourquoi-nous-promettons-99-99-pour-cent). Quatre sondes indépendantes, installées à des endroits différents, surveillent nos services, et [status.elchi.dev](https://status.elchi.dev) publie ce qu'elles mesurent. ## Ce qu'il faut vérifier cette semaine 1. **Dressez la liste de ce qui tourne dans une seule zone.** Machines virtuelles, disques, bases de données sans réplique, un cache, une file d'attente. Pour chacun, notez ce qui arrive à votre service si cette zone disparaît pendant six heures. 2. **Vérifiez que les zones restantes peuvent absorber la charge.** Si votre basculement compte sur de la capacité libre ailleurs, réservez-la ou testez-la. Le 20 octobre, la capacité des autres zones londoniennes est devenue insuffisante. 3. **Cherchez les dépendances qui franchissent les zones.** Un plan de contrôle, un magasin de configuration, un service de secrets ou une vérification de licence situé à un seul endroit peut empêcher le reste de démarrer. 4. **Demandez à vos fournisseurs où ils tournent.** Votre prestataire de paiement, votre hébergeur, votre service de base de données : quel fournisseur, combien de zones, combien de régions, et comment ils vous préviennent quand quelque chose tombe en panne. 5. **Mesurez depuis l'extérieur.** Une sonde hors de votre propre infrastructure vous indique quand vos clients sont touchés. La page d'état de votre fournisseur vous indique quand le fournisseur est touché. Le 20 octobre, ce n'étaient pas les mêmes moments. 6. **Lisez la clause de disponibilité de vos contrats.** Vérifiez le chiffre, la façon dont il est mesuré, et si les pannes des propres fournisseurs de votre prestataire comptent ou sont exclues. 7. **Prévoyez la perte d'une région entière.** Google recommande lui-même un plan de reprise après sinistre pour la perte d'une région. Une sauvegarde dans une autre région ne compte qu'une fois qu'une restauration à partir de celle-ci a été testée. ## Sources 1. [Preliminary Incident Report: multiple services in europe-west2 (London)](https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj), Google Cloud Service Health, consulté le 2026-10-26 2. [Geography and regions](https://docs.cloud.google.com/docs/geography-and-regions), Google Cloud, consulté le 2026-10-26 3. [Google Cloud says a 'power event' caused today's outage](https://www.theregister.com/paas-and-iaas/2026/10/20/google-cloud-says-a-power-event-caused-todays-outage/5304160), The Register, consulté le 2026-10-26 4. [Europe's financial regulators query Google over cloud outage that hit banks](https://www.globalbankingandfinance.com/europes-financial-regulators-query-google-over-cloud-outage/), Reuters, via Global Banking & Finance Review, consulté le 2026-10-26 5. [European banks, websites hit as Google Cloud data centre goes offline for hours](https://www.abc.net.au/news/2026-10-20/google-cloud-failure-europe-banks/107290238), ABC News, consulté le 2026-10-26 6. [Störung bei Google Cloud beeinträchtigt zahlreiche Dienste in der Schweiz und Europa](https://www.netzwoche.ch/news/2026-10-21/stoerung-bei-google-cloud-beeintraechtigt-zahlreiche-dienste-in-der-schweiz-und), Netzwoche, consulté le 2026-10-26 7. [Grossausfall bei Google Cloud](https://www.inside-it.ch/grossausfall-bei-google-cloud-20261020), Inside IT, consulté le 2026-10-26 8. [EU regulators designate critical tech providers under DORA](https://www.pinsentmasons.com/out-law/news/tech-designated-dora-regulation), Pinsent Masons Out-Law, consulté le 2026-10-26 9. [The October 20, 2026 Google Cloud europe-west2 Outage](https://blog.incidenthub.cloud/google-cloud-europe-west2-outage-oct-20-2026), IncidentHub, consulté le 2026-10-26