Résumé

  • La perturbation longue distance du 15 janvier 1990 ne se comprend pas comme une panne matérielle nationale. Le point de départ public est un incident matériel mineur sur un 4ESS de New York, suivi d’une reprise normale de quatre à six secondes; la cause systémique documentée par AT&T se situe dans un défaut logiciel sensible au minutage dans la logique Direct Link Node pendant la récupération d’état CCS7.
  • L’enjeu de responsabilité porte sur le contrôle opérationnel: tests de transitions d’état, exposition progressive d’un changement commun, inventaire des versions, isolement de la signalisation, autorité de retour arrière et vérification indépendante. Les estimations d’impact doivent rester attribuées, et les limites publiques de preuve doivent rester visibles.

Le 15 janvier 1990, une perturbation importante a touché le réseau longue distance d’AT&T aux États-Unis. Le fait central n’est pas qu’un réseau téléphonique national ait rencontré une défaillance isolée. Les réseaux de télécommunications sont construits pour absorber des défauts matériels locaux, des reprises de processeur, des réacheminements et des variations de charge. Le point critique est plus précis: une transition de récupération, normalement banale, a rencontré une condition logicielle commune dans la signalisation de contrôle, puis cette condition a pu se répéter de commutateur en commutateur.

Le dossier public place le début de l’événement vers 14 h 30, heure de l’Est, sur un commutateur de transit 4ESS à New York. AT&T a décrit un problème matériel mineur sur une interface de lignes de jonction. Ce premier événement a déclenché une procédure de reprise normale. Pendant cette reprise, le commutateur suspendait brièvement le traitement de nouveaux appels, généralement pendant quatre à six secondes, et indiquait aux commutateurs connectés de ne pas lui envoyer de nouveau trafic. Cette description est importante parce qu’elle sépare le déclencheur de la cause nationale.

Un tel incident local devait être absorbé; il ne devait pas devenir l’explication complète d’une instabilité à grande échelle.

Après cette courte récupération, le 4ESS de New York a repris le traitement et a envoyé des Initial Address Messages, ou IAM, aux commutateurs voisins. Dans l’architecture CCS7, ces messages font partie du plan de signalisation: ils transportent l’information nécessaire à l’établissement des appels et à la coordination entre éléments de réseau. Selon le récit technique d’AT&T, les IAM qui ont atteint les commutateurs adjacents étaient valides. Le problème n’était donc pas un message malveillant, un protocole extérieur anormal ou une demande de trafic manifestement illégitime.

Le problème était qu’un processeur Direct Link Node, chargé de mettre à jour sa carte d’état et de reconnaître le retour en service du commutateur de New York, pouvait entrer dans une fenêtre vulnérable de plusieurs secondes.

AT&T a attribué cette vulnérabilité à un défaut logiciel introduit dans une mise à jour commune de mi-décembre. Cette mise à jour avait pour objectif opérationnel d’aider les commutateurs à atteindre plus vite un réseau de signalisation de secours. L’intention était donc de renforcer la récupération, non de l’affaiblir. Mais dans un système de contrôle distribué, l’intention d’un changement ne protège pas le réseau si le code exécuté rend une transition d’état instable.

D’après AT&T, deux IAM arrivant à moins d’un centième de seconde l’un de l’autre pouvaient altérer des données pendant la mise à jour de la carte d’état et forcer le processeur concerné à se réinitialiser.

La redondance locale n’a pas suffi à créer une frontière indépendante. Le processeur DLN disposait d’un processeur dupliqué, capable de prendre le trafic lorsque le premier se réinitialisait. Mais si ce processeur jumeau exécutait le même programme et recevait la même condition de minutage pendant sa propre transition d’état, il pouvait être exposé à la même défaillance. La paire dupliquée devenait alors un domaine de panne corrélé plutôt qu’une protection indépendante.

Un commutateur qui perdait temporairement ses processeurs de signalisation pouvait se retrouver isolé du réseau CCS7, même si sa partie de commutation de trafic n’était pas détruite.

C’est là que la récupération devient propagation. Quand un commutateur se trouvait isolé de la signalisation, il annonçait son indisponibilité. Lorsqu’il se réinitialisait et revenait en service, il reprenait l’échange de messages. Les commutateurs voisins devaient alors reconnaître son changement d’état. Sous la charge continue des messages d’appel, ces voisins pouvaient rencontrer la même fenêtre temporelle et le même défaut logiciel. Les annonces de reprise, destinées à restaurer le service, devenaient donc les événements qui exposaient d’autres commutateurs à la même condition.

La panne n’avait pas besoin que tous les 4ESS échouent simultanément. Elle avait besoin d’un code commun, d’un état de récupération commun et d’un flux de messages suffisant pour reproduire la séquence.

Le périmètre de changement commun est l’un des faits structurants. AT&T a indiqué que le défaut avait été introduit dans ses commutateurs 4ESS par la mise à jour de mi-décembre. Un compte rendu contemporain publié dans Telephony et repris dans le forum RISKS indique que le nouveau code avait été chargé dans les processeurs frontaux des 114 systèmes 4ESS. Ces éléments ne constituent pas un audit public du code source ni une chronologie complète de chaque commutateur.

Ils suffisent toutefois à fonder l’analyse de risque: un changement logiciel commun avait une exposition suffisamment large pour transformer une anomalie locale en instabilité de flotte.

Il faut éviter deux raccourcis. Le premier serait d’appeler le défaut matériel de New York la cause profonde nationale. Il a déclenché la première reprise documentée, mais la propagation dépendait de la logique de récupération et du défaut logiciel. Le second serait d’affirmer que les 114 systèmes ont tous échoué en même temps. Le dossier disponible ne le prouve pas. La thèse défendable est plus rigoureuse: la même condition logicielle était largement présente, certains commutateurs ont été exposés à des états de récupération et à des IAM rapprochés, et cette combinaison a suffi à produire une cascade de signalisation.

L’architecture explique pourquoi ce type d’événement dépasse le simple cadre d’un téléphone qui ne passe pas. Les recommandations de l’UIT sur le système de signalisation no 7 décrivent une architecture à canal commun dans laquelle les fonctions de transfert de messages transportent la signalisation entre fonctions utilisatrices. Les documents Q.700, Q.701, Q.704, Q.705, Q.706 et Q.752 donnent le vocabulaire de structure, de fonctions réseau, de performance, de surveillance et de mesure. Ils ne prouvent pas rétroactivement une non-conformité d’AT&T en 1990.

Ils éclairent plutôt la nature du contrôle: l’état, le routage, la disponibilité des liens, la reprise et l’établissement des appels sont des faits opérationnels partagés. Si ce plan devient instable, le réseau porteur peut être présent sans que le service longue distance reste utilisable.

Les récits contemporains convergent sur l’ampleur sans donner un seul nombre définitivement audité. Des journaux et AT&T ont rapporté qu’environ la moitié des tentatives d’appels longue distance échouaient pendant des parties importantes de l’interruption. UPI a rapporté une estimation de 50 millions d’appels bloqués et des effets sur les numéros 800 ainsi que sur des lignes informatiques. Ces deux formulations doivent rester séparées. « Environ la moitié » décrit une proportion de tentatives dans une période ou un périmètre rapporté; « 50 millions » est une estimation attribuée du nombre d’appels bloqués.

Les fusionner produirait une précision artificielle. Le paquet public ne permet pas non plus de chiffrer une perte économique vérifiée, une liste complète de clients touchés ou un impact uniforme sur tous les territoires.

La réponse technique d’AT&T a suivi plusieurs étapes. Les équipes ont d’abord appliqué des procédures standard, puis ont constaté qu’elles ne suffisaient pas. Elles ont examiné les messages d’erreur, le comportement des commutateurs et les motifs de reprise. Des équipes de support technique et de Bell Labs ont participé au diagnostic. Selon AT&T, la stabilisation a été obtenue en suspendant temporairement le trafic de signalisation sur des liens de secours, afin de réduire la charge de messages vers les processeurs touchés. Le dernier lien a été libéré à 23 h 30, heure de l’Est.

Le lendemain, AT&T a retiré la mise à jour fautive, est revenue temporairement au programme précédent, a reproduit le problème en laboratoire, l’a corrigé et a testé le changement avant de restaurer les liens de secours.

Cette séquence de mitigation doit rester distincte de la cause. Réduire le trafic sur les liens de secours n’est pas la même chose que corriger le défaut logiciel. C’est une mesure de stabilisation: elle réduit la pression de signalisation qui alimente la répétition de la fenêtre vulnérable. Le retour arrière vers l’ancien programme est une mesure de contrôle de version: il retire de la flotte le comportement commun qui rend la cascade possible. La reproduction en laboratoire et la correction du défaut relèvent de la preuve technique: elles rapprochent l’incident observé d’une explication testable.

Ces étapes forment une chaîne utile, mais elles ne suppriment pas la question initiale: comment un changement de récupération aussi largement exposé a-t-il atteint la flotte sans que cette transition précise soit confinée ?

AT&T a indiqué que la mise à jour avait été rigoureusement testée en laboratoire et que la combinaison exacte d’événements n’avait pas été prévue. Cette affirmation peut être vraie et rester insuffisante pour l’analyse de responsabilité. Dans les systèmes de signalisation, la qualité d’un test ne se mesure pas seulement à la présence d’un environnement de laboratoire.

Elle se mesure à la capacité du test à reproduire les transitions d’état les plus dangereuses: retour en service après isolement, messages IAM rapprochés, bascule entre processeurs dupliqués, charge de signalisation persistante, comportement des commutateurs voisins et interaction avec les liens de secours. Un test qui valide la fonction nominale mais n’exerce pas la dynamique de reprise peut manquer le risque principal.

La notion de message valide est également essentielle. Dans un incident d’exploitation, il est tentant d’attribuer l’instabilité à des entrées « mauvaises ». Ici, le récit d’AT&T porte sur des IAM ordinaires qui arrivaient dans une fenêtre précise. Une architecture fiable ne peut pas supposer que des messages valides, rapprochés sous une charge réaliste, n’arriveront pas pendant une récupération. La bonne question n’est donc pas de savoir si les opérateurs auraient dû deviner exactement deux IAM en moins d’un centième de seconde.

Elle est de savoir si les transitions critiques du plan de signalisation étaient testées contre des rafales plausibles, des répétitions, des reprises simultanées et des états partiellement reconstruits.

Les analyses académiques ultérieures ont utilisé l’événement comme exemple de message empoisonnant du plan de contrôle: un message de protocole autrement valide déclenche un défaut latent de mise en œuvre, et le comportement de gestion du réseau maintient ou propage l’instabilité. Cette catégorie aide à nommer le risque, mais elle ne doit pas remplacer le dossier factuel. Dans le cas de 1990, le compte technique attribué à AT&T reste la base pour le minutage IAM/DLN. Les récits secondaires qui évoquent une instruction de rupture mal placée, ou une erreur de structure de code particulière, doivent rester des narrations attribuées.

Le paquet public ne donne pas le code source vérifié, le contexte de compilation, la structure de données altérée ou le journal complet des exécutions.

L’incident montre aussi la limite de la redondance quand elle est trop homogène. Deux processeurs sont utiles contre une panne matérielle isolée. Ils le sont moins contre un défaut de code commun qui se manifeste au même moment logique. Un réseau de signalisation de secours est utile si son chemin d’accès reste indépendant du changement en cours. Il l’est moins si la mise à jour destinée à atteindre ce secours plus rapidement introduit la condition de panne. La responsabilité opérationnelle ne consiste donc pas seulement à compter les composants de rechange.

Elle consiste à définir les domaines de défaillance: version logicielle, état de récupération, flux de messages, autorité de bascule, visibilité des alarmes et capacité de retour arrière.

Le contrôle de version est le registre pratique de cette responsabilité. Un opérateur national doit pouvoir dire quel programme tourne sur quels commutateurs, quel changement a été autorisé, quel périmètre a été exposé, quelles conditions d’arrêt existent et quelle version précédente peut être restaurée. Sans cet inventaire, la reprise dépend de la mémoire des équipes et d’une lecture fragmentaire des symptômes. Avec cet inventaire, un incident de signalisation devient traçable: on peut relier un état de commutateur, une version de logiciel, un comportement de processeur et une décision d’exploitation.

Le fait opérationnel important n’est pas l’étiquette « redondant »; c’est la carte exacte de ce qui exécute quoi, où, et dans quel état.

La chronologie publique invite donc à une lecture en couches. Première couche: un événement matériel local active une reprise normale à New York. Deuxième couche: des IAM valides atteignent des commutateurs voisins pendant une fenêtre de récupération d’état. Troisième couche: un défaut logiciel dans la logique DLN rend cette fenêtre vulnérable à deux messages très rapprochés. Quatrième couche: les processeurs dupliqués ne fournissent pas d’indépendance parce qu’ils partagent le même code et le même état temporel. Cinquième couche: les annonces d’indisponibilité et de retour en service alimentent de nouvelles transitions chez les voisins.

Sixième couche: la stabilisation passe par une réduction de la charge sur les liens de signalisation de secours, puis par le retour au programme précédent.

Cette séparation n’est pas une subtilité éditoriale. Elle change les contrôles à exiger. Si le matériel de New York était la cause profonde, la réponse principale serait l’amélioration locale de ce matériel. Si les messages étaient malveillants, la réponse principale serait l’authentification, le filtrage d’origine ou la poursuite. Si la cause est une condition logicielle commune exposée par une transition de récupération, la réponse est différente: tests de transitions, canari de déploiement, isolement de la signalisation, observabilité au niveau des messages, inventaire de version et retour arrière vérifié.

Le cadre public ne permet pas d’attribuer une faute individuelle. Il ne montre pas une attaque, un virus, un sabotage, une violation réglementaire prouvée ou une responsabilité juridique établie. Il ne justifie pas non plus de projeter la structure actuelle d’AT&T Inc. sur l’opérateur de 1990 sans nuance historique. L’objet d’analyse est le réseau longue distance exploité à l’époque par American Telephone & Telegraph Company et ses organisations techniques associées. Le lien d’annuaire contemporain peut identifier l’entité de référence, mais l’événement appartient à un contexte opérationnel et institutionnel précis.

Ce contexte rend l’incident durablement utile pour les infrastructures actuelles. Les réseaux modernes ont davantage d’automatisation, davantage de couches logicielles et davantage de reprises orchestrées. Ils reposent toujours sur une vérité simple: le code qui tourne pendant un changement d’état est le contrôle réel. Les diagrammes de redondance, les plans de continuité et les promesses de secours sont secondaires si les transitions qui les activent ne sont pas observables, testées et réversibles. La panne de 1990 montre qu’un mécanisme conçu pour restaurer le service peut devenir le chemin par lequel l’instabilité se déplace.

La continuité télécom n’est pas seulement la disponibilité d’un faisceau ou d’un commutateur. Elle est la capacité du système à maintenir une représentation exacte de son propre état pendant les défauts. Dans cet incident, l’état à reconnaître était simple en apparence: New York est temporairement indisponible, puis revient en service. Mais cette mise à jour d’état traversait les DLN, les cartes d’état, les IAM, les processeurs dupliqués et la signalisation CCS7. Si cette représentation se corrompt, les décisions de routage et d’établissement d’appel deviennent instables.

La responsabilité consiste alors à protéger l’exactitude de l’état autant que la capacité physique de transporter la voix.

Les limites de mesure doivent être traitées avec la même rigueur. Le public a reçu des indications sur la proportion d’appels qui échouaient, des estimations de volumes bloqués et des récits sur certains services touchés. Il n’a pas reçu une matrice complète des échecs par région, par tranche horaire, par type de service, par client ou par commutateur. Il n’a pas reçu non plus un rapprochement indépendant des estimations. Une analyse sérieuse ne comble pas ces trous par des nombres inventés.

Elle dit que l’impact était important, nationalement visible et suffisant pour exposer une faiblesse de contrôle; puis elle précise ce qui reste non mesuré.

L’incident devrait également orienter la manière dont les opérateurs publient leurs explications. Un bon rapport sépare le déclencheur, le défaut latent, la condition de propagation, les actions de stabilisation, le correctif et les inconnues. Cette séparation évite deux erreurs opposées: réduire une cascade logicielle à un « petit problème matériel » ou gonfler une défaillance de code en récit d’effondrement total sans preuve. Elle donne aussi aux clients, aux régulateurs, aux pairs techniques et aux assureurs une base pour vérifier les contrôles plutôt que pour débattre d’une formule vague.

Les documents de l’UIT, les publications de la NTIA et les travaux cités dans ce paquet donnent un arrière-plan d’architecture et de fiabilité. Ils ne sont pas des verdicts contre AT&T. Ils montrent pourquoi un système de signalisation commun, des fonctions de transfert de messages, des mesures de performance et des mécanismes de surveillance doivent être considérés comme des surfaces de contrôle.

Les rapports du GAO sur la dépendance aux systèmes d’information et la fiabilité des infrastructures publiques appartiennent au même registre: ils éclairent les attentes de gouvernance et de continuité, sans transformer un incident de 1990 en violation rétroactive d’une règle qui ne serait pas établie dans le dossier.

La conclusion technique est donc étroite, mais forte. Une panne locale a exposé un défaut de reprise dans un logiciel commun. Des messages valides ont déclenché une fenêtre de corruption d’état. La redondance n’a pas isolé le défaut parce qu’elle partageait le code et le moment critique. Les annonces de récupération ont fourni le chemin de propagation. La stabilisation a réduit la pression de signalisation, puis le retour arrière a retiré le programme en cause.

C’est précisément parce que la chaîne est technique qu’elle devient une question de responsabilité: un opérateur qui contrôle le code commun, le déploiement, l’inventaire, les tests et le retour arrière contrôle aussi les conditions dans lesquelles une anomalie locale reste locale ou devient nationale.