Graeme Stewart, responsable du secteur public chez Check Point Software Technologies, analyse l’impact de la panne de ce mardi 20 octobre 2026

Panne majeure ce matin. « Un incident électrique dans la zone europe-west2-b ; le problème a été résolu, nous constatons un rétablissement progressif », justifie Google Cloud. Reste une question incommodante : jusqu’où notre dépendance ?
« Lorsqu’une entreprise de l’envergure de Google connaît une panne, cela se ressent presque immédiatement sur les services dont dépendent chaque jour des millions de personnes, commente Graeme Stewart. Le fait que des clients de banques signalent des problèmes est particulièrement préoccupant. Les gens utilisent de plus en plus ces plateformes pour gérer leur argent, diriger leur entreprise et accéder à des services essentiels. »

Ironie du calendrier, la panne de Google Cloud célèbre jour pour jour l’anniversaire d’une autre panne mémorable, celle d’AWS le 20 octobre 2025, qui avait déjà privé Lloyds, Halifax et Bank of Scotland de leurs services en ligne. Autre hyperscaler, même région… et même scénario dramatique.

Quand un fusible saute…

Parmi les services devenus indisponibles, on compte BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, Google App Engine, Google Cloud NetApp Volumes, Google Kubernetes Engine et Managed Service for Apache Kafka. Parmi les victimes, relevons des entreprises telles que Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Cloudflare, Screwfix et Revolut.« Nous avons construit une économie numérique dans laquelle des millions d’entreprises sont reliées à la même rallonge électrique, analyse Graeme Stewart. Si le fusible saute, tout le monde risque de se retrouver dans le noir. Une part considérable de notre infrastructure numérique dépend d’un nombre relativement restreint de fournisseurs de technologies. Cela constitue une grande vulnérabilité : les problèmes rencontrés par un seul fournisseur se répercutent sur des organisations qui n’ont elles-mêmes pratiquement aucun contrôle sur la situation. »

« cloud » n’est pas synonyme de « résilience »

Ce que cette panne met en évidence, c’est l’ampleur des perturbations que peut entraîner l’indisponibilité de systèmes critiques, quelle qu’en soit la cause. Un problème survenant dans une seule région cloud peut donc se propager à toute la chaîne logistique numérique, affectant des organisations situées à plusieurs niveaux de distance de la panne initiale. Bien qu’il s’agisse d’une panne régionale concentrée sur la zone europe-west2, l’ampleur des services touchés illustre une leçon fondamentale en ingénierie cloud : la résilience ne s’obtient pas par le simple fait de migrer vers le cloud !

« Les entreprises et les administrations publiques doivent se poser des questions difficiles. À quel point sont-elles devenues dépendantes de fournisseurs individuels ? Et leurs plans d’urgence leur permettent-ils réellement de continuer à fonctionner en cas de panne prolongée ? Pour les organisations qui fournissent des services essentiels, les conséquences vont bien au-delà d’un simple désagrément, surtout lorsque les gens n’ont plus accès à leur argent, aux soins de santé ou à d’autres services sur lesquels ils comptent. » 

Nous préparer davantage

Une véritable résilience exige de concevoir des systèmes capables de supporter des défaillances régionales, grâce à des déploiements multi-régions, à la portabilité des charges de travail et à des procédures de reprise après sinistre dûment testées. Mais nous n’y sommes pas, constate encore Graeme Stewart.

« La dure réalité est que notre dépendance à l’égard de ces systèmes a augmenté bien plus rapidement que notre capacité à y faire face en cas de panne. À l’heure où de plus en plus de services essentiels se déploient en ligne, nous devons nous préparer beaucoup plus sérieusement au moment où la technologie que nous considérons comme acquise cessera soudainement de fonctionner. »