Panne Orange : la redondance qui partageait la même faille

Un mercredi sans réseau, et une explication en deux temps

À la date du 26 octobre 2026, les faits établis sont les suivants. Le mercredi 21 octobre, en fin de matinée, les abonnés mobiles d'Orange et de sa marque Sosh perdent l'accès aux appels, aux SMS et à l'internet mobile. Sur Downdetector, site participatif de signalement des pannes, les déclarations concernant Orange passent de 39 à 11 494 entre 11 h 18 et 11 h 48, selon Le Figaro, et culminent à près de 12 000 vers 11 h 50, selon France 3. L'opérateur comptait environ 21,6 millions de clients mobiles en France à la fin juin. Le directeur général d'Orange France, Jérôme Hénique, situe le début de l'incident à 11 h 37. Le réseau est déclaré de nouveau opérationnel en soirée, autour de 21 h.

Le jour même, Orange s'en tient à une phrase : « L'incident est lié à une défaillance d'un équipement au niveau de notre cœur de réseau mobile. » Le cœur de réseau (l'ensemble des équipements centraux qui authentifient les cartes SIM et acheminent la voix, les SMS et les données) concentre par construction le trafic de tous les abonnés qui y sont rattachés. Le lendemain, la presse évoque une migration ratée vers le nouveau cœur 5G ou une mise à jour manquée.

Le 23 octobre, dans un entretien au Figaro, Jérôme Hénique livre une autre explication. La panne est due, selon ses mots, à « un bug logiciel sur l'un des équipements au cœur de réseau mobile, qui a provoqué une succession exceptionnelle d'incidents ». Il écarte la cyberattaque et toute mise à jour en cours. Le défaut se trouve, selon Orange, dans le logiciel de l'équipementier Nokia, fournisseur du nouveau cœur de réseau. Selon ZDNet, la migration vers ce cœur se fait depuis dix-huit mois par tranches de 100 000 lignes, et les lignes restées sur l'ancien ont fonctionné normalement.

Le dirigeant ajoute le point qui fait l'objet de cette chronique. Le bug est apparu simultanément « sur les équipements en production et sur ceux censés assurer la redondance du cœur de réseau ». Et, rapporte ZDNet, il résume : « l'incident sort de l'ordinaire parce que la redondance n'a pas fonctionné ». Les équipements de secours, répartis sur des sites distincts, exécutaient la même version logicielle que les équipements principaux. Les messages d'erreur qui faisaient tomber les uns faisaient tomber les autres. Nokia n'a isolé le code défaillant que vers 17 h, d'après ZDNet. Orange compense ses clients par un doublement de leur volume de données pendant un mois.

Le récit de l'exception masque une architecture ordinaire

La couverture a raconté l'événement par l'exception. Le dirigeant parle d'une « situation majeure, mais qui est tout à fait exceptionnelle » et d'un bug « extrêmement complexe à trouver ». Il rappelle qu'Orange n'avait pas connu d'incident comparable depuis quatorze ans, la panne de 2012 ayant été plus longue et plus étendue. Ce récit est loyal sur le défaut lui-même, rare et difficile à diagnostiquer. Il laisse dans l'ombre ce qui n'avait rien d'exceptionnel.

Que deux équipements exécutant le même code tombent sur le même défaut n'est pas une coïncidence. C'est une propriété du dispositif. La redondance géographique protège contre ce qui frappe un site sans frapper l'autre : un incendie, une coupure électrique, une rupture de fibre, une carte qui grille. Elle ne protège pas contre ce que les deux sites partagent. Un logiciel identique, alimenté par les mêmes messages, réagit de la même manière, et le secours tombe avec le principal, au même instant et pour la même raison.

La panne du 21 octobre n'est pas un échec de la redondance, mais la limite d'une redondance conçue pour une autre famille de risques. Elle couvrait les défaillances matérielles et les sinistres locaux. Le défaut logiciel commun se trouvait hors de son périmètre, et le récit de l'exception ne dit pas sur quelle hypothèse ce périmètre avait été arbitré.

Doubler les équipements ne rend pas les défaillances indépendantes

Cette hypothèse a un nom et une histoire. En 1986, John C. Knight et Nancy G. Leveson publient dans les IEEE Transactions on Software Engineering une expérience devenue classique. Vingt-sept versions d'un même programme sont écrites séparément, à partir de la même spécification, par des étudiants de deux universités. Elles sont soumises à un million de cas de test. Chaque version prise isolément se révèle très fiable. Mais le nombre de tests sur lesquels plusieurs versions échouent ensemble dépasse nettement ce que prédirait l'indépendance des défaillances.

L'hypothèse d'indépendance (Knight et Leveson, 1986)

La programmation multiversion (le fait de faire tourner en parallèle plusieurs versions d'un logiciel écrites séparément, puis de retenir le résultat majoritaire) repose sur un postulat : des programmes développés indépendamment échoueraient indépendamment. John C. Knight et Nancy G. Leveson ont soumis ce postulat à l'expérience, avec vingt-sept versions d'un même programme et un million de tests. Les auteurs rejettent statistiquement l'hypothèse d'indépendance.

Leur conclusion n'est pas que la diversité serait inutile. Knight rapporte la même année que des systèmes à trois versions réduisaient la probabilité de défaillance d'environ un ordre de grandeur. Elle est que la fiabilité d'un dispositif redondant ne peut pas se calculer en multipliant les probabilités de panne de ses éléments, parce que ces pannes se ressemblent plus que ce calcul ne le suppose.

L'apport du résultat, appliqué au 21 octobre, tient dans un renversement. Knight et Leveson montraient que même des versions écrites par des équipes différentes partagent une partie de leurs erreurs. Le cœur de réseau d'Orange se situait à l'autre extrémité de l'échelle : une seule version, d'un seul fournisseur, déployée à l'identique sur le principal et sur le secours. La dépendance entre les défaillances n'y était pas partielle, elle était complète pour tout défaut logiciel. Sur ce point, la redondance ne valait qu'un seul équipement.

Martin Landau, dans un article de 1969 sur la redondance dans les administrations, avait posé la même condition sous un autre angle : multiplier les voies n'achète de la fiabilité que si ces voies peuvent tomber séparément. Une chronique précédente l'a mobilisé à propos de la seconde pile bureautique de la Confédération suisse, dans La redondance n'est pas une demi-mesure. Le cas Orange montre ce qui arrive lorsqu'elle n'est pas remplie.

Le temps du rétablissement appartenait au détenteur du code

Le second enseignement porte sur la durée. Entre 11 h 37 et 17 h, l'opérateur dispose de ses équipes et de ses sites, pas du code. Le défaut se trouve dans un logiciel qu'il exploite sans l'avoir écrit, et sa localisation dépend de l'équipementier, dont l'intervention a été nécessaire, souligne ZDNet. Le délai avant identification du défaut, plus de cinq heures, est celui d'un diagnostic que l'exploitant ne pouvait pas conduire seul.

Ce mécanisme rejoint ce que la chronique SaaS : la cause d'une panne, un bien de croyance décrivait à partir du bien de croyance de Michael Darby et Edi Karni (1973) : le client constate la réparation mais ne peut pas établir lui-même la cause. Le 21 octobre en ajoute une conséquence. Quand le principal et le secours partagent un seul code, l'exploitant perd à la fois sa capacité de bascule et la maîtrise de son délai de reprise. Le second effet relève du contrat avec l'équipementier, dont les engagements ne sont pas publics.

Ariane 501, ou le secours qui tombe le premier

Le cas d'école le plus proche date du 4 juin 1996. Ce jour-là, le premier lanceur Ariane 5 se désintègre une quarantaine de secondes après le début de la séquence de vol. La commission d'enquête présidée par Jacques-Louis Lions rend son rapport le 19 juillet 1996. Le lanceur disposait de deux systèmes de référence inertielle (les calculateurs qui fournissent l'attitude et la position de la fusée), l'un actif, l'autre en secours. Le rapport le dit sans détour : « There are two SRIs operating in parallel, with identical hardware and software » (deux systèmes fonctionnent en parallèle, avec un matériel et un logiciel identiques).

Une fonction d'alignement héritée d'Ariane 4, sans utilité sur Ariane 5, produit une valeur trop grande pour une conversion de donnée non protégée, et le calculateur s'arrête sur erreur. Le système de secours s'arrête le premier, un cycle de 72 millisecondes avant le système actif, pour exactement la même raison. Le rapport attribue la décision d'arrêter le calculateur en cas d'erreur à une culture qui ne traitait que les défaillances matérielles aléatoires.

La structure est la même qu'à l'automne 2026. Une redondance pensée contre la panne matérielle, un logiciel partagé, un défaut qui frappe les deux voies ensemble. Trente ans séparent les deux événements. Leur parenté montre qu'il ne s'agit pas d'une ignorance technique, mais d'une hypothèse qui se reconstitue d'elle-même chaque fois qu'un achat consolide le principal et le secours chez un seul fournisseur.

Le mécanisme sans la marque

Le mécanisme se formule sans Orange. Une organisation qui achète sa redondance auprès d'un seul fournisseur, sur une seule version de logiciel, se protège des sinistres locaux mais reste exposée au défaut commun, dont la durée dépend du fournisseur. Trois conditions le rendent probable : la consolidation des achats, qui rend l'homogénéité moins chère que la diversité, la synchronisation des versions, que l'exploitation recherche pour simplifier la maintenance, et la concentration du diagnostic chez l'éditeur.

Ces conditions se retrouvent bien au-delà des télécommunications. Un plan de reprise d'activité (le dispositif qui permet de relancer un système sur un site de secours) qui réplique à l'identique une base de données, un progiciel ou un système d'exploitation reproduit la configuration du 21 octobre. Il en va de même d'un service en nuage dont toutes les zones exécutent le même code. Dans chacun de ces cas, la redondance est réelle pour un incendie et nulle pour un défaut logiciel. Les tests de bascule, souvent conduits en simulant la perte d'un site, ne révèlent pas cette limite, puisqu'ils éprouvent précisément le risque contre lequel le dispositif a été conçu.

Une organisation qui décrit sa résilience en nombre de sites ou de centres de données décrit sa protection contre le sinistre physique, pas contre le défaut commun, qui se mesure en versions, en fournisseurs et en délais contractuels.

Grille de lecture

1. Les systèmes de secours de l'organisation exécutent-ils la même version logicielle que les systèmes principaux, et qui a décidé de ce choix ?
2. Les exercices de bascule simulent-ils un défaut logiciel commun aux deux sites, ou seulement la perte de l'un d'eux ?
3. Pour les systèmes critiques, combien de fournisseurs distincts interviennent entre l'équipement principal et son secours ?
4. Le contrat avec l'éditeur ou l'équipementier fixe-t-il un délai de diagnostic en cas de défaut bloquant, et ce délai est-il compatible avec la durée d'interruption tolérable ?
5. Le registre des risques distingue-t-il la panne d'un site de la panne commune à tous les sites ?

Une redondance à mesurer en versions, pas en sites

Le 21 octobre, Orange disposait de plusieurs sites, pas de deux logiciels. La phrase de son dirigeant, selon laquelle la redondance n'a pas fonctionné, est exacte au sens où les secours ne se sont pas substitués aux équipements principaux. Elle l'est moins au sens où la redondance aurait failli : elle a protégé contre ce qu'elle couvrait, et ce qu'elle ne couvrait pas s'est produit. La rareté du défaut relève de la malchance. L'indépendance supposée des défaillances, dont Knight et Leveson ont montré la fragilité il y a quarante ans, relevait d'un choix d'architecture et d'achat.

L'hypothèse de cette chronique est que la réponse se jouera sur la diversité, non sur le nombre. Plusieurs indicateurs permettront de la vérifier d'ici fin 2027. Le premier est ce qu'Orange dira des suites techniques de l'incident : l'annonce de versions logicielles décalées entre principal et secours, ou d'un second fournisseur, confirmerait la lecture, tandis qu'un renforcement du seul nombre de sites l'infirmerait. Le second est le document d'enregistrement universel qu'Orange publiera au titre de l'exercice 2026, dont les facteurs de risques diront si la dépendance à un équipementier unique pour le cœur de réseau y est nommée. Le troisième est extérieur : une panne de même nature chez un autre opérateur, dont le cœur repose sur un seul fournisseur, montrerait que le 21 octobre était une architecture avant d'être un accident.

Note méthodologique

Les faits reposent sur la presse de référence (Le Figaro, ZDNet, 20 Minutes, France 3) et sur l'entretien accordé au Figaro le 23 octobre 2026 par le directeur général d'Orange France. Le lien causal entre le logiciel commun et l'échec des secours est assumé, car il a été reconnu publiquement par le dirigeant de l'opérateur. L'origine du défaut dans le code de Nokia est attribuée à Orange, l'équipementier ne s'étant pas exprimé publiquement à la date du 26 octobre 2026, dans le périmètre de presse consulté. Les sources divergent sur deux points : l'hypothèse d'une mise à jour manquée, évoquée en interne selon Le Figaro du 22 octobre, a été écartée par le dirigeant le lendemain, version retenue ici. ZDNet indique que les appels d'urgence sont restés fonctionnels, alors que France 3 rapporte des perturbations et une consigne du département du Tarn invitant à composer le 112 depuis un autre réseau. Le cadre de Knight et Leveson est préféré à celui de Martin Landau, déjà employé dans une chronique antérieure, parce qu'il nomme directement l'hypothèse d'indépendance que le 21 octobre a démentie. Les faits sont arrêtés au 26 octobre 2026.

Recherche de sources, croisement des données et structuration du raisonnement s'appuient sur une assistance par intelligence artificielle. Le choix de l'angle et du cadre théorique, la vérification des sources, les arbitrages et l'établissement du texte final relèvent de l'auteur.

image générée par IA (ChatGPT Images 2.5)

Sources

Documents d'organisations

Agence spatiale européenne, « Ariane 501 - Presentation of Inquiry Board report », communiqué de presse n° 33-1996, 23 juillet 1996. https://www.esa.int/Newsroom/Press_Releases/Ariane_501_-_Presentation_of_Inquiry_Board_report

Commission d'enquête présidée par Jacques-Louis Lions, « ARIANE 5 Flight 501 Failure. Report by the Inquiry Board », Paris, 19 juillet 1996. https://esamultimedia.esa.int/docs/esa-x-1819eng.pdf

Presse de référence

Le Figaro, « “Un incident majeur et inédit” : le patron d'Orange France explique au Figaro les raisons de la panne géante du 21 octobre », entretien avec Jérôme Hénique, 23 octobre 2026. https://www.lefigaro.fr/secteur/high-tech/un-incident-majeur-et-inedit-le-patron-d-orange-france-explique-au-figaro-les-raisons-de-la-panne-geante-du-21-octobre-20261023

Le Figaro, « Panne géante chez Orange : les dessous d'un incident jamais vu depuis 2012 », 22 octobre 2026. https://www.lefigaro.fr/secteur/high-tech/panne-geante-chez-orange-les-dessous-d-un-incident-jamais-vu-depuis-2012-20261022

ZDNet, « Panne Orange du 21 octobre : un bug Nokia a paralysé le cœur de réseau et ses secours », 26 octobre 2026. https://www.zdnet.fr/actualites/panne-orange-du-21-octobre-un-bug-nokia-a-paralyse-le-coeur-de-reseau-et-ses-secours-506524.htm

20 Minutes, « Orange : La panne de mercredi était due à “un bug de logiciel” inédit, explique le directeur », 23 octobre 2026. https://www.20minutes.fr/economie/4257044-20261023-orange-panne-mercredi-due-bug-logiciel-inedit-explique-directeur

Lucas Rodriguez, France 3 Régions Occitanie, « Panne Orange : ce que l'on sait des perturbations qui touchent le réseau mobile ce mercredi », 21 octobre 2026. https://france3-regions.franceinfo.fr/occitanie/haute-garonne/toulouse/panne-orange-ce-que-l-on-sait-des-perturbations-qui-touchent-le-reseau-mobile-ce-mercredi-3436962.html

Cadres théoriques

John C. Knight et Nancy G. Leveson, « An Experimental Evaluation of the Assumption of Independence in Multiversion Programming », IEEE Transactions on Software Engineering, vol. SE-12, n° 1, p. 96-109, janvier 1986. https://doi.org/10.1109/TSE.1986.6312924

John C. Knight, « Detection of Faults and Software Reliability Analysis », rapport annuel NASA NAG-1-605, université de Virginie, août 1986. https://ntrs.nasa.gov/api/citations/19870002808/downloads/19870002808.pdf

Martin Landau, « Redundancy, Rationality, and the Problem of Duplication and Overlap », Public Administration Review, vol. 29, n° 4, p. 346-358, juillet 1969. https://doi.org/10.2307/973247

Michael R. Darby et Edi Karni, « Free Competition and the Optimal Amount of Fraud », The Journal of Law and Economics, vol. 16, n° 1, p. 67-88, avril 1973. https://doi.org/10.1086/466756