La panne de Google Cloud du 20 octobre a perturbé de nombreux sites, dont la banque Revolut et relancé une question stratégique : comment poursuivre son activité lorsque les communications habituelles deviennent indisponibles ?

Une application inaccessible, des paiements perturbés, des équipes privées de leurs moyens d’échange : une interruption informatique peut rapidement désorganiser une entreprise. L’incident de Google Cloud du 20 octobre 2026 replace la continuité des communications au cœur du débat. Data Security Breach souligne une dépendance souvent sous-estimée : plusieurs outils peuvent reposer sur une infrastructure commune. Le retour d’expérience transmis par Revolut à ses clients illustre également les conséquences prolongées d’une panne, certaines opérations nécessitant un délai de régularisation après le rétablissement. L’enjeu dépasse donc la disponibilité technique : il concerne la capacité à coordonner, informer et décider.

Plusieurs applications, une même dépendance

Le 20 octobre, plusieurs services de Google Cloud ont rencontré des difficultés dans la région de Londres. La page officielle de suivi mentionne un incident électrique ayant provoqué une interruption dans la zone europe-west2-b. Une défaillance d’infrastructure peut ainsi se répercuter sur les organisations qui utilisent les services concernés.

Revolut figure parmi les entreprises touchées. Dans le message adressé à ses clients, la société attribue explicitement son interruption de service à cette panne de Google Cloud. Elle indique que le problème a été résolu le jour même et affirme que les fonds comme les données sont restés en sécurité pendant toute la perturbation. Le rétablissement technique ne signifie toutefois pas que toutes les conséquences disparaissent immédiatement. Revolut prévient que certaines transactions par carte, remboursements compris, peuvent demander quelques jours avant d’apparaître sur le compte et d’être répercutées dans le solde. L’établissement précise travailler au traitement de ces opérations et renvoie les clients rencontrant encore des difficultés vers l’assistance accessible dans son application.

Ce décalage illustre une distinction essentielle : remettre un service en ligne et retrouver un fonctionnement entièrement normal constituent deux étapes différentes. Entre les deux, les utilisateurs doivent comprendre ce qui fonctionne, ce qui reste en attente et comment obtenir une réponse. DataSecuritybreach.fr Derbes attire précisément l’attention sur cette fragilité organisationnelle. Une entreprise peut disposer d’une téléphonie sur IP, d’une messagerie instantanée, d’une plateforme collaborative et d’un outil de visioconférence sans bénéficier de quatre voies de secours indépendantes. Ces applications peuvent partager un hébergeur, un fournisseur cloud ou certaines infrastructures. Leur nombre ne renseigne donc pas, à lui seul, sur leur capacité à résister à une défaillance commune. La diversification apparente des interfaces peut masquer une concentration des dépendances.

L’enjeu consiste alors à identifier les communications indispensables. Joindre les collaborateurs, transmettre une décision urgente, répondre aux clients et coordonner les interventions ne peuvent dépendre d’un dispositif dont personne n’a vérifié les possibilités de remplacement.

Autre détail, de taille, nous savons maintenant que Révolut sauvegarde les données chez Google Cloud !

Le secours doit fonctionner pendant la panne

L’existence d’une solution alternative ne garantit pas sa disponibilité au moment critique. Elle peut utiliser le réseau déjà interrompu, demander une authentification inaccessible ou présenter des limites de traçabilité incompatibles avec les exigences de l’activité. La question opérationnelle devient très concrète : les personnes chargées de gérer la crise peuvent-elles effectivement se joindre lorsque leurs outils habituels ne répondent plus ? Un dispositif documenté reste insuffisant si son activation dépend précisément du service défaillant.

L’identification des dépendances et l’expérimentation régulière des moyens de remplacement est indispensable. Pendant que les techniciens rétablissent les systèmes, l’organisation doit conserver la possibilité de transmettre des consignes et d’expliquer la situation à ses interlocuteurs.

Les données européennes donnent une autre dimension à cette réflexion. Publié en juin 2026, le premier rapport commun des autorités européennes de supervision sur les incidents majeurs déclarés dans le cadre de DORA porte sur 3 383 événements. Environ un tiers ont produit des effets transfrontaliers. Ces chiffres concernent les incidents informatiques du secteur financier, et non exclusivement les communications. Ils illustrent néanmoins l’étendue possible des répercussions d’une défaillance numérique.

Orange : des suspensions préventives liées à PHP
Le 22 octobre, Orange a annoncé la fermeture temporaire de certains services après la publication de vulnérabilités PHP le 21 octobre.
Le groupe indique avoir interrompu ces accès pour installer les correctifs et effectuer les contrôles nécessaires.
Plusieurs filiales et entités sont concernées, avec une remise en service progressive des sites et applications.
Une mesure préventive.

Ces situations replacent la disponibilité des échanges dans les décisions de direction. Les performances, les fonctionnalités et les coûts doivent être examinés avec les conséquences d’une interruption prolongée. Les responsables opérationnels et, lorsque nécessaire, les fonctions de conformité ont donc leur place dans cette préparation. Confier une infrastructure à un prestataire ne dispense pas l’entreprise d’organiser sa propre continuité.