Panne Google Cloud : le rétablissement de l’infrastructure ne remet pas tous les services en ligne à la fois

Un incident localisé dans la région de Londres

Plusieurs services Google Cloud ont été perturbés le 20 octobre 2026 dans la région de Londres, identifiée comme europe-west2. La chronologie officielle situe le début de l’incident au 19 octobre à 23 h 08 et sa fin au 20 octobre à 7 heures, en heure du Pacifique. Cela correspond à 8 h 08 puis 16 heures à Paris le 20 octobre. Google attribue l’origine à un événement électrique dans la zone europe-west2-b et décrit une indisponibilité de services ainsi que des erreurs réseau intermittentes.

Dans sa dernière mise à jour, Google indique que les effets étaient corrigés pour la plupart des clients, avec un très petit nombre de situations encore traitées par ses équipes. Le fournisseur annonce aussi une analyse de l’incident après la fin de son investigation interne. Le classement de l’événement comme clos doit donc être lu avec les précisions de cette mise à jour. Il ne signifie pas que chaque application utilisant les services concernés retrouve simultanément toutes ses fonctions, ni que chaque client a subi exactement la même interruption.

Des fonctions bancaires encore perturbées

Lors de la consultation de sa page d’état le 20 octobre, Revolut affichait encore des fonctions partiellement indisponibles. Cette page distingue les différents services proposés aux particuliers et aux entreprises. Un incident peut donc avoir des conséquences différentes sur la connexion, les paiements, les transferts ou l’accès à certaines informations. La présence d’un message d’erreur ne permet pas de déterminer à elle seule le sort d’une opération particulière. Il faut se référer au statut communiqué par l’établissement et aux informations propres à la transaction concernée.

Le retour d’une infrastructure et celui des applications qu’elle héberge correspondent à des étapes différentes. Après la remise en service d’un composant, une application peut encore devoir reprendre des traitements en attente, rétablir des connexions ou vérifier la cohérence de ses opérations. Cette explication générale ne constitue pas un diagnostic détaillé de l’architecture de Revolut. Les éléments nécessaires à un tel diagnostic devront venir des comptes rendus des entreprises concernées. Elle permet seulement de comprendre pourquoi un signal de rétablissement en amont n’équivaut pas à un retour instantané de tous les parcours utilisateurs.

Un écran inaccessible ne décrit pas le solde des actifs

Pour les services financiers et crypto, il faut distinguer l’accès à une interface, l’exécution d’une opération et la conservation des actifs. Une application qui ne répond pas peut empêcher de consulter un solde sans que ce seul symptôme prouve une disparition des fonds. À l’inverse, un écran de connexion fonctionnel ne garantit pas que tous les paiements et retraits sont disponibles. Les pages d’état aident à identifier le périmètre des fonctions touchées ; elles ne remplacent pas le relevé d’une opération ou la réponse du prestataire sur un cas individuel.

La panne ne permet pas non plus d’affirmer qu’un réseau blockchain et toutes les applications qui y donnent accès partagent la même disponibilité. Des interfaces et prestataires peuvent dépendre d’infrastructures communes, même lorsque les actifs utilisent une blockchain. L’évaluation de la continuité doit donc porter sur chaque composant réellement utilisé. Pour cet incident, les informations consolidées à retenir restent la chronologie publiée par Google, les états des services concernés et les analyses détaillées que les opérateurs publieront sur les causes et les mesures correctives.