Avant le web moderne, avant le Wi-Fi, avant même l’Internet grand public, ARPANET servait de colonne vertébrale expérimentale à ce qui allait devenir le réseau mondial. Et pourtant, en 1980, cette infrastructure pionnière a connu une panne majeure provoquée non par un sabotage, mais par un emballement logiciel interne.
Une panne qui a rendu le réseau presque inutilisable
Le 27 octobre 1980, ARPANET a semblé devenir inutilisable pendant plusieurs heures. Dans son étude de cas publiée ensuite sous forme de RFC 789, Eric C. Rosen explique que le réseau a été paralysé par un processus logiciel de haute priorité parti hors de contrôle. Le problème immédiat venait d’un dysfonctionnement matériel inhabituel, qui a généré une séquence fautive de paquets de contrôle réseau. Ces paquets ont ensuite perturbé la répartition des ressources logicielles dans les IMP, les machines qui jouaient alors un rôle comparable à celui des routeurs.
Le réseau ne tombait pas partout physiquement, mais il ne savait plus fonctionner
Rosen décrit une situation étrange: les machines n’étaient pas toutes mortes, mais elles ne parvenaient plus à communiquer correctement entre elles. Les connexions déjà établies étaient rompues, les tentatives d’accès à distance échouaient, et des appels arrivaient de partout au centre de contrôle du réseau, ce qui montrait que la panne n’était pas locale mais quasi nationale à l’échelle d’ARPANET.
Un ancêtre de la panne moderne par boucle logicielle
Le Computer History Museum résume l’incident comme le premier grand crash réseau d’ARPANET, avec une panne d’environ quatre heures. L’explication technique met en cause une combinaison de faiblesses dans le traitement des horodatages et dans un mécanisme de nettoyage des anciens messages. Dit plus simplement, le réseau s’est retrouvé prisonnier de sa propre circulation de messages de contrôle.
Ce que cette vieille panne dit encore sur les réseaux d’aujourd’hui
Ce qui rend cet épisode fascinant en 2026, c’est qu’il raconte déjà une vérité très contemporaine. Une infrastructure distribuée peut être conçue pour survivre à des coupures, à des nœuds défaillants ou à des chemins cassés, tout en restant vulnérable à une boucle interne de contrôle. Le papier de Rosen insiste d’ailleurs sur un autre point très moderne: une fois la cause trouvée, une partie du problème venait encore du fait qu’il fallait reprendre le contrôle des machines qui se comportaient mal. En clair, la récupération et l’observabilité comptent presque autant que l’architecture elle-même.
L’ironie fondatrice d’Internet
ARPANET avait été imaginé dans un esprit de robustesse réseau, avec la logique de packet switching qui permettait de contourner certains points de défaillance. DARPA rappelle que l’un des défis initiaux était justement d’éviter qu’un seul nœud ne fasse tomber tout le système. Et pourtant, cette panne de 1980 montre qu’une autre menace existait déjà: non pas la chute d’un maillon isolé, mais l’asphyxie du réseau par ses propres mécanismes de coordination.
Une vieille histoire, très actuelle
On pourrait croire à une curiosité de musée. En réalité, cette panne ressemble à une version primitive d’un problème toujours bien vivant: quand une infrastructure complexe devient victime de ses propres automatismes. Ce n’est pas exactement l’histoire d’Internet qui s’effondre. C’est plutôt celle d’un réseau pionnier qui a appris, très tôt, qu’être distribué ne suffit pas toujours à être résilient.