Panne Orange : quand la redondance ne suffit pas, et votre PME dans la même logique

Mercredi matin, vos commerciaux ne passent plus d’appels. Les livraisons s’organisent au feeling. Le responsable informatique reçoit des codes de connexion par SMS… qui n’arrivent pas. Ce n’est pas votre réseau qui flanche : c’est celui de l’opérateur mobile de la moitié de l’équipe. Le 21 octobre 2026, Orange — et sa marque Sosh — reconnaissent une panne majeure sur le réseau mobile en France. Franceinfo relaie le communiqué : appels, SMS et usages mobiles perturbés pour une partie des clients ; l’incident est lié à une défaillance d’un équipement au cœur de réseau mobile. L’opérateur écarte une cyberattaque et précise à 01net qu’il s’agit de son nouveau cœur de réseau. Le rétablissement est annoncé en soirée (vers 21 h pour les abonnés les plus longuement touchés, après un début vers 11 h 20).

Deux sites identiques ne font pas deux secours

La surprise, pour les spécialistes, n’est pas la durée : c’est la redondance qui n’a pas tenu. ZDNet France décrit un bug logiciel sur un équipement Nokia du cœur de réseau, chargé notamment d’authentifier les cartes SIM. Les nœuds de secours tournaient avec la même version que les primaires : la bascule a donc répliqué la panne au lieu de l’isoler. Jérôme Hénique, directeur général d’Orange France, le résume au Figaro : l’incident sort de l’ordinaire parce que « la redondance n’a pas fonctionné ». Chez vous, le parallèle est prosaïque : deux liens signés chez le même opérateur, deux serveurs patchés le même soir, deux facteurs d’authentification qui passent tous les deux par le même SMS.

Le réseau « visible » n’est pas le service rendu

Une chronique publiée sur Journal du Net (29 octobre) insiste sur un piège classique : une antenne captée ou un ping qui répond ne prouvent pas qu’un utilisateur peut s’authentifier, ouvrir une session ou joindre une application métier. Même logique en entreprise : le DNS, le fournisseur d’identité ou le service de certificats peut bloquer le travail alors que le switch affiche tout en vert. La supervision utile mesure des transactions — connexion, ouverture de dossier, validation d’une commande — pas seulement la disponibilité d’un composant.

Reprendre vite peut prolonger la panne

Quand le service revient, clients et applications retentent en masse. Cette tempête de reconnexion peut saturer ce qui vient à peine de redémarrer — phénomène connu aussi sur les API et les bases de données. La chronique JDN rappelle l’intérêt de limiter les tentatives, d’étaler les reprises et de suivre le débit utile plutôt que le nombre de processus relancés. Pour une PME, cela se traduit par des consignes simples : ne pas relancer vingt fois la même appli métier, prioriser les flux critiques, reporter ce qui peut attendre une heure.

• Cartographier une dépendance : si l’opérateur mobile tombe, qui reçoit encore les alertes ? Qui peut joindre le prestataire cloud ?
• Tester les accès de secours sans compter sur le canal qui vient de lâcher (SMS seul pour l’administration, par exemple).
• Fixer avant la crise qui peut décider d’un retour arrière après un changement récent — pas « quand on aura retrouvé le directeur ».
• Exercice mesuré : couper volontairement le mobile d’une équipe une demi-journée et chronométrer le rétablissement d’une transaction métier indispensable.

Si vous n’avez jamais simulé une coupure opérateur ou si vos codes d’accès critiques ne passent que par SMS, on peut en parler : quinze minutes suffisent souvent pour lister les maillons fragiles.