Panne Google Cloud à Londres : cinq leçons de résilience pour les entreprises
Une interruption de la région Google Cloud de Londres a perturbé le 20 octobre 2026 des banques, des entreprises et des services publics. L’incident, clos après 7 heures et 52 minutes selon la page de statut du fournisseur, rappelle qu’un contrat cloud ne remplace ni une architecture de continuité ni des exercices réguliers.
Ce que l’incident permet d’affirmer
Google Cloud a signalé des erreurs élevées et des défaillances réseau intermittentes dans la région europe-west2. La page de santé recense plusieurs dizaines de produits affectés. Des établissements financiers, dont Revolut, Lloyds et HSBC, ont indiqué des perturbations de leurs services en ligne ; Reuters a relié l’incident de Revolut à la panne du fournisseur.
Les services ont été progressivement rétablis. Revolut a indiqué que l’argent et les données de ses clients restaient en sécurité. Une indisponibilité n’implique donc pas automatiquement une perte de données, mais elle peut empêcher l’accès, les paiements, les transferts ou l’assistance pendant une durée critique.
Leçon 1 : connaître les dépendances cachées
Une application peut sembler répartie sur plusieurs serveurs tout en dépendant d’un service unique d’identité, de stockage, de réseau ou de gestion des secrets. Une cartographie utile relie chaque service client aux composants techniques indispensables et précise ce qui se passe lorsque l’un d’eux devient indisponible.
Leçon 2 : distinguer zone, région et fournisseur
Déployer plusieurs instances dans une même zone ou une même région ne protège pas contre tous les incidents. Une architecture multi-région peut réduire certains risques, mais elle impose une réplication des données, un routage testé et des règles de cohérence. Le recours à plusieurs fournisseurs ajoute encore de la complexité et ne doit pas être présenté comme une assurance automatique.
Leçon 3 : définir un service minimum
Toutes les fonctions n’ont pas la même criticité. Une entreprise doit décider ce qui doit rester disponible : consultation d’un solde, paiement, prise de commande, support ou accès aux dossiers prioritaires. Un mode dégradé bien conçu peut maintenir ces fonctions essentielles sans reproduire l’intégralité du système principal.
Leçon 4 : tester le basculement avec des objectifs mesurables
Le RTO, ou objectif de temps de reprise, fixe la durée acceptable avant restauration. Le RPO, ou objectif de point de reprise, précise la quantité de données que l’organisation peut tolérer de perdre. Ces objectifs doivent être associés à des responsables, à des procédures et à des tests réels. Une documentation non exercée ne démontre pas la capacité de reprise.
Les exercices doivent inclure les dépendances humaines : qui décide du basculement, qui informe les clients, comment les équipes accèdent aux outils de secours et comment éviter des actions contradictoires pendant la crise ?
Leçon 5 : préparer la communication et le retour à la normale
Une page de statut indépendante, des messages validés à l’avance et une liste de contacts réduisent l’incertitude. La communication doit distinguer l’indisponibilité, la sécurité des données et l’état des transactions. Après la reprise, l’entreprise vérifie les files d’attente, les paiements en double, les traitements différés et les données restées incohérentes.
Le fournisseur critique ne transfère pas la responsabilité
Les règles européennes sur la résilience opérationnelle renforcent la surveillance de certains prestataires technologiques, mais les organisations clientes restent responsables de leurs processus critiques. Le contrat doit préciser les engagements de disponibilité, l’accès aux informations d’incident, les audits, les mécanismes de sortie et les responsabilités respectives.
La leçon principale n’est pas de renoncer au cloud. Elle consiste à concevoir chaque service important avec une hypothèse simple : une région, un réseau ou un outil central peut tomber. La résilience apparaît lorsque l’entreprise connaît cette dépendance, limite son impact et démontre régulièrement qu’elle sait continuer à fonctionner.
Sources
Comprendre l’innovation. Mesurer son impact. Agir avec discernement.
Challenge Impact News décrypte les évolutions de l’intelligence artificielle et des nouvelles technologies, ainsi que leurs conséquences concrètes sur les entreprises, les métiers et notre société.
Sous la direction éditoriale de Cyril Darmon
Fondateur d’UMANIA, consultant, formateur et conférencier spécialisé en intelligence artificielle et en transformation des entreprises.
UMANIA — L’IA au cœur de l’humain. Un partenaire éditorial à l’origine de Challenge Impact News.
Commentaires