La panne d'Orange transforme le scénario de Zero Day en test de résilience pour les DSI La panne d’Orange du 21 octobre remet une question au centre des préoccupations des DSI : comment un incident circonscrit devient-il une interruption étendue ? La série Zero Day fournit un scénario spectaculaire. L’ingénierie de résilience permet de le transformer en épreuve technique.

Dans Zero Day, une cyberattaque déstabilise des infrastructures américaines et déclenche une crise nationale. Chez Orange, le 21 octobre 2026, une interruption du réseau mobile a perturbé les communications d’une partie des abonnés. Le rapprochement s’arrête ici concernant les causes : l’opérateur a indiqué à 01net qu’un équipement de son nouveau cœur de réseau était en cause et a écarté une cyberattaque.

La cyberattaque détectée par Orange le 25 juillet 2025 constitue un événement distinct. Cette distinction ouvre une analyse plus utile que la recherche d’une prédiction télévisuelle. Une panne et une attaque peuvent produire des symptômes comparables pour les utilisateurs, tout en nécessitant des investigations différentes.

La disponibilité appartient pleinement au périmètre de la cybersécurité. Pour un DSI, la question devient celle des dépendances, de la propagation et du rétablissement. Les informations publiques ne permettent pas de reconstituer la panne d’Orange ; les mécanismes suivants constituent une grille d’analyse, pas son diagnostic.

Le réseau visible peut fonctionner sans rendre le service Un téléphone qui capte une antenne ne dispose pas nécessairement d’un service utilisable. Le réseau d’accès radio et le cœur de réseau remplissent des fonctions différentes. Le second intervient notamment dans l’enregistrement des terminaux, l’authentification des abonnés et l’établissement des sessions.

Une liaison radio disponible peut donc coexister avec un échec de connexion aux services. Dans une architecture 5G autonome, l’AMF gère notamment l’accès et la mobilité, l’AUSF intervient dans l’authentification, le SMF dans la gestion des sessions et l’UPF dans l’acheminement des données utilisateurs. Ces fonctions ne décrivent pas à elles seules les services voix, qui mobilisent également l’IMS.

Sans connaître l’équipement défaillant et les populations concernées, attribuer la panne à une fonction précise serait spéculatif. Le parallèle avec une entreprise est immédiat. Un réseau IP peut répondre tandis que l’identité, le DNS ou le service de certificats empêche les applications de fonctionner.

La supervision doit mesurer des transactions représentatives : authentification, ouverture de session, accès applicatif. Un serveur disponible et un port ouvert renseignent sur un composant ; ils ne démontrent pas que l’utilisateur peut travailler. La redondance doit survivre aux causes communes Deux instances ne constituent une protection que si l’incident ne peut pas les affecter simultanément.

Un logiciel identique, une configuration distribuée automatiquement, un stockage partagé ou une dépendance d’authentification peuvent transformer plusieurs équipements en un seul domaine de défaillance. La séparation géographique protège contre certains accidents physiques ; elle laisse subsister ces dépendances logiques. Le DSI doit donc documenter ce que chaque redondance couvre réellement.

Une architecture répartie sur deux sites peut rester exposée à une erreur propagée par son orchestrateur. Deux liens télécoms peuvent emprunter un même chemin physique. Deux contrats commerciaux ne garantissent aucune indépendance technique.

L’audit utile suit les chemins, les fournisseurs effectifs et les services communs jusqu’aux points dont la perte neutraliserait les deux solutions. La capacité disponible après bascule doit également être démontrée. Si chaque site supporte la moitié de la charge, perdre un site double potentiellement la demande sur l’autre.

Encore faut-il intégrer le coût de reconstruction des sessions, les caches froids et les requêtes supplémentaires. Une capacité nominale suffisante peut devenir insuffisante pendant la transition. Le redémarrage peut entretenir la panne Le rétablissement d’un composant ne termine pas nécessairement l’incident.

Les clients peuvent retenter leurs connexions, les applications renouveler leurs requêtes et les tâches différées se présenter simultanément. Cette demande de rattrapage consomme les ressources nécessaires à la reprise. Le système recommence alors à échouer, ce qui provoque de nouvelles tentatives.

Un exemple fictif permet de quantifier le problème. Si 600 000 clients tentent chacun une opération toutes les trente secondes, ils génèrent en moyenne 20 000 tentatives par seconde, avant les échanges internes. Une répartition inégale ou des tentatives synchronisées augmente les pointes.

Ce calcul illustre un dimensionnement ; il ne décrit ni les volumes ni le comportement des terminaux lors de l’incident Orange. Pour les applications et API, les protections comprennent un nombre limité de tentatives, des délais croissants avec dispersion aléatoire, des files bornées et un contrôle d’admission. Les mécanismes télécoms suivent leurs propres procédures et temporisations normalisées.

Dans les deux cas, la stratégie de reprise doit limiter la demande effectivement acceptée. Google documente notamment le risque d’amplification lorsque plusieurs couches logicielles réessaient indépendamment une même opération. Restaurer exige parfois de rouvrir par cohortes, de limiter certaines fonctions ou de différer les traitements secondaires.

Le bon indicateur devient le débit de transactions utiles abouties, accompagné des taux d’erreur et des latences élevées. Le nombre de processus redémarrés peut augmenter sans que le service rendu progresse. Un retour arrière doit restaurer un état cohérent Lorsqu’un changement précède un incident, revenir à la version précédente paraît évident.

L’opération devient plus complexe si des schémas de données, des états de session ou des configurations ont évolué. L’ancienne version peut ne plus comprendre les données nouvelles. Le retour arrière exige alors une stratégie de compatibilité et une procédure de réconciliation.

Les déploiements progressifs doivent comporter des seuils d’arrêt explicites : taux d’échec d’authentification, latence au percentile 99, saturation des files, erreurs par cohorte. Un test portant uniquement sur une faible charge peut manquer les effets de contention ou les interactions avec des clients anciens. Il faut aussi vérifier la représentativité fonctionnelle des premiers utilisateurs migrés.

La décision de poursuivre, d’arrêter ou de revenir en arrière doit être attribuée avant la crise. Une procédure inexécutable sans l’accord d’un responsable injoignable ajoute une dépendance humaine au système. Les journaux de changement, les versions déployées et la chronologie des symptômes doivent rester consultables depuis un environnement de secours.

Le secours peut dépendre de ce qui vient de tomber Une entreprise peut disposer d’une connexion secondaire et rester paralysée parce que ses administrateurs ne peuvent plus recevoir leurs codes d’authentification. Elle peut conserver ses applications cloud tout en perdant le canal permettant de réunir la cellule de crise. L’indisponibilité d’un opérateur révèle alors des dépendances que les inventaires techniques traitaient séparément.

Le test doit porter sur une chaîne complète : alerte, accès d’administration, authentification, coordination, intervention du fournisseur et validation métier. Les accès d’urgence doivent être protégés, limités, journalisés et régulièrement vérifiés. Leur utilisation ne doit pas dépendre exclusivement du service dont ils doivent permettre la réparation.

Les alternatives aux SMS doivent elles-mêmes faire l’objet d’une analyse de disponibilité. Les objectifs de reprise doivent distinguer restauration technique et reprise métier. Le RTO fixe une durée cible de rétablissement ; le RPO définit la perte de données acceptable.

Une panne de connectivité peut surtout provoquer des transactions en attente, des traitements retardés et des opérations dont le statut devient incertain. Leur réconciliation mérite un objectif et un responsable propres. Le contrat fournisseur doit préciser les informations disponibles pendant l’incident : périmètre affecté, services maintenus, fréquence des mises à jour et modalités d’escalade.

Une garantie de disponibilité mensuelle ne décrit pas la capacité de l’entreprise à supporter une interruption continue. Le DSI doit confronter cette durée aux exigences des métiers, puis tester les bascules avec les utilisateurs concernés. Une caisse, un centre de contact et un accès distant ne présentent pas les mêmes besoins.

Leur priorité de restauration doit être décidée avant que les demandes concurrentes arrivent à la cellule de crise et ralentissent les arbitrages techniques nécessaires. Transformer Zero Day en exercice mesurable La fiction devient utile lorsqu’on traduit son interruption spectaculaire en hypothèses contrôlables. Un exercice peut supposer la perte d’un opérateur mobile pendant plusieurs heures, alors que les applications restent disponibles.

Il peut ajouter une indisponibilité du fournisseur d’identité, puis tester séparément une reprise soumise à une forte demande. Chaque variante doit préciser son périmètre et ses critères de réussite. Pour distinguer les causes, l’équipe confronte la chronologie aux changements récents, aux journaux de sécurité, aux flux et aux alertes d’intégrité.

Elle conserve les traces avant les opérations susceptibles de les écraser. Une restauration rapide ne doit pas effacer les éléments nécessaires à l’analyse d’une compromission éventuelle. Il faut mesurer le temps nécessaire pour joindre les décideurs, ouvrir les accès de secours et rétablir une transaction métier.

Les équipes suivent ensuite le débit utile, les latences, les doublons et les opérations à réconcilier. L’exercice vérifie aussi que les communications distinguent les faits établis, les hypothèses et la prochaine échéance d’information. La confiance se fragilise lorsqu’une explication prématurée doit être corrigée sans chronologie claire.

Une série peut donner une forme familière à la crise et pousser à voir une attaque avant d’en connaître la cause. Son intérêt professionnel réside dans les questions qu’elle permet d’éprouver. Après Orange, un DSI devrait pouvoir demander une démonstration : couper une dépendance identifiée, maintenir les fonctions indispensables, puis reprendre sans saturation.

La résilience commence lorsque ce scénario possède des résultats mesurés, des responsables et des écarts à corriger.