Résumé

  • Le pilote proposé par Segal en août 1984 ne cherchait pas à relier deux machines semblables : il devait vérifier si TCP/IP pouvait réunir les systèmes ouverts récents et les ordinateurs propriétaires déjà indispensables au CERN.
  • Devenu premier coordinateur TCP/IP en 1985, Segal a organisé les tables d’hôtes, le routage et le support. En mars 1988, 355 machines utilisaient le protocole, mais la politique du laboratoire interdisait encore toute connexion TCP/IP extérieure.
  • Le « big bang » de janvier 1989 a remplacé les adresses internes par des adresses officielles, puis permis les premiers liens Internet. La réussite technique avait préparé l’ouverture ; elle ne pouvait pas l’autoriser à elle seule.

Une réussite enfermée dans son périmètre

Le chiffre de 355 provient d’un inventaire contemporain, rédigé au printemps 1988 pendant la préparation de LEP. Il ne compte pas 355 machines connectées à l’Internet mondial. Il décrit un service interne, très utilisé pour la connexion à distance, le transfert de fichiers et les appels de procédure, sur des IBM, ND, Apollo, VAX, PC, Sun, Cray et Macintosh.

Cette précision change le récit. On pourrait croire qu’un protocole adopté par autant de plateformes avait nécessairement franchi le seuil de l’organisation. Or le CERN avait précisément séparé les deux décisions. TCP/IP était toléré, expérimenté puis exploité sur le site ; sa circulation vers l’extérieur restait interdite.

La trajectoire de Segal n’est donc pas celle d’un inventeur imposant une solution supérieure. C’est celle d’un praticien qui construit assez de preuves, de routines et de dépendances pour qu’une décision ultérieure devienne possible.

Le problème n’était pas seulement le réseau

Lorsque Segal arrive au CERN en 1971, la communication de données ressemble à une juxtaposition de mondes. Les constructeurs proposent leurs architectures, le laboratoire entretient ses propres systèmes et les standards ouverts demeurent incomplets. Lors d’un congé sabbatique à Palo Alto en 1977, il rencontre ARPANET et Unix. De retour à Genève, il voit dans TCP/IP une manière de faire coopérer des ordinateurs qui n’ont pas été conçus pour appartenir au même ensemble.

En 1983, le CERN crée un groupe Data Communications chargé d’unifier le réseau. Le mandat paraît large, mais les responsabilités restent distribuées. Le groupe construit une infrastructure dorsale et privilégie les normes ISO, tout en prenant en charge DECnet. Les réseaux du grand système IBM, le courrier, les nouvelles, Unix et les stations de travail demeurent ailleurs. TCP/IP progresse justement dans ces interstices.

En août 1984, Segal propose un pilote sur des machines non-Unix essentielles, notamment le système central IBM-VM et un VAX sous VMS. L’enjeu est l’hétérogénéité : peut-on offrir un langage réseau commun aux nouveaux systèmes ouverts et aux investissements propriétaires existants ?

Le projet est accepté. Dans son histoire rétrospective, Segal explique que l’évaluation a confirmé l’intérêt de TCP/IP et conduit à recommander l’interface « sockets » issue de BSD. Cette interface fournit aux développeurs une méthode reproductible. Sans elle, le protocole resterait une démonstration de transport ; avec elle, des applications peuvent l’adopter sans réinventer leur accès au réseau.

Une fonction de coordination, pas un droit de passage

Au début de 1985, un accord entre les groupes Software et Data Communications fait de Segal le premier « TCP/IP Coordinator » du CERN. Le titre répond à un besoin opérationnel. Il ne lève pas l’interdiction externe.

L’inventaire de 1988 permet d’observer ce que « coordonner » signifie. Le routage interne est statique. Une table maîtresse associe noms et adresses ; le coordinateur la maintient et transmet les mises à jour, tandis que les responsables de systèmes conservent leurs copies locales. Une partie du savoir est centralisée, l’exécution reste répartie.

Ce montage transforme la compatibilité en service. Une installation réussie ne garantit pas que les noms resteront cohérents le mois suivant, que les routes seront corrigées ou qu’une nouvelle plateforme recevra les mêmes informations. La coordination est une fonction de continuité.

Mais sa juridiction s’arrête au bord du site. Selon Segal, la politique du groupe Data Communications réserve les protocoles Internet à l’intérieur du CERN : aucune connexion TCP/IP externe ne doit être établie. À l’extérieur, les choix ISO, IBM et DECnet conservent leur primauté jusqu’au début de 1989. Dans l’Europe de l’époque, administrations des télécommunications, gouvernements et industriels soutiennent d’autres normes ; promouvoir IP peut coûter politiquement et professionnellement.

LEP donne un propriétaire au besoin

En novembre 1985, la direction du collisionneur LEP choisit TCP/IP pour son système de contrôle. Le futur anneau de 27 kilomètres n’est pas un banc d’essai que l’on peut abandonner sans conséquence. Son adoption, renforcée ensuite par le choix d’Unix, place le protocole dans une chaîne d’exploitation scientifique concrète.

Le pilote acquiert ainsi un client interne capable de transformer une préférence technique en exigence de fiabilité. Des machines différentes doivent fonctionner ensemble, et la panne n’est plus seulement une mauvaise démonstration : elle peut toucher un grand instrument.

Entre 1985 et 1988, le service s’étend avec peu de personnes. Puis Data Communications accepte la responsabilité du support TCP/IP. Le passage d’une petite opération du groupe Software à une activité dotée en personnel marque une étape distincte de l’installation initiale. L’organisation reconnaît enfin la charge récurrente produite par le succès.

Le jour où les adresses changent de statut

Les adresses employées dans un réseau fermé peuvent être cohérentes localement sans être valables ailleurs. Pour entrer dans l’Internet, le CERN doit adopter des adresses officiellement attribuées et rendre sa configuration compatible avec les réseaux extérieurs.

En janvier 1989, le laboratoire renumérote l’ensemble lors d’un « big bang ». Les premières connexions Internet externes suivent. L’opération est lourde parce que TCP/IP a déjà réussi : des centaines de machines, des tables, des logiciels et des équipes locales dépendent de la configuration antérieure.

La renumérotation n’est donc ni un détail administratif ni la cause unique de l’ouverture. Elle matérialise l’alignement de quatre éléments jusque-là disjoints : protocole éprouvé, support reconnu, identifiants mondiaux et autorisation de franchir la frontière.

Cette chronologie évite aussi deux erreurs. TCP/IP existait au CERN avant la proposition d’août 1984 ; le pilote ciblait son extension aux systèmes non-Unix. Et la connexion Internet de 1989 n’est pas la naissance du Web.

Préparer le milieu du Web sans en revendiquer l’invention

Tim Berners-Lee rédige sa première proposition pour le World Wide Web en mars 1989. Le premier serveur et le premier navigateur fonctionnent à la fin de 1990. Le Web utilise une infrastructure Internet devenue disponible, mais ajoute une architecture d’information, des protocoles et des logiciels propres.

L’Internet Hall of Fame attribue à Segal un rôle de conseil : familiarisation avec la pile IP et les sockets, orientation vers les RFC ainsi que vers FTP et NNTP. Ce soutien éclaire le milieu technique dans lequel Berners-Lee travaille. Il ne transforme pas Segal en co-inventeur.

Segal lui-même formule la limite avec soin. Il pense que le Web aurait pu apparaître plus tôt si le CERN avait été connecté plus tôt, puis qualifie cette idée de spéculation. La conclusion solide est plus sobre : l’Internet a créé une occasion. La précision protège à la fois son apport réel et celui de Berners-Lee.

Ce que le pilote a rendu négociable

Le succès interne n’a pas aboli la politique. Il a changé la qualité de la décision à prendre. En 1989, la direction ne juge plus une promesse abstraite. Elle dispose d’un parc de 355 hôtes, d’applications quotidiennes, d’un coordinateur, d’une API adoptée, d’équipes formées et d’un programme scientifique dépendant du service.

Le pilote réduit ainsi l’incertitude technique tout en révélant les obstacles non techniques. C’est sa valeur institutionnelle. Il montre où se trouvent les décisions de support, d’adressage et d’autorisation qui ne peuvent pas être résolues par un test de performance.

L’histoire de Segal rappelle enfin qu’une frontière de réseau est aussi une frontière de responsabilité. Le protocole peut transporter un paquet ; il ne peut pas signer la politique qui l’autorise à partir.

Sources