Résumé

  • Le projet de démonstration au Hilton reliait des terminaux de conférence, un TIP et des ressources d’ARPANET afin que les visiteurs puissent essayer le réseau.
  • Les RFC de juillet montrent que cette expérience dépendait encore de tests de capacité, de terminaux compatibles, de programmes préparés, d’instructions compréhensibles et de personnes disponibles pour aider.

Le réseau devait avoir une porte d’entrée

Le détail le plus parlant des préparatifs de la démonstration publique d’ARPANET en 1972 est peut-être ce qui n’était pas encore réglé en juillet. Le Terminal Interface Processor (TIP) pourrait-il accueillir les terminaux prévus au Washington Hilton ? Quels modèles fonctionneraient avec quels services distants ? Un visiteur saurait-il quoi saisir, et qui l’aiderait en cas de blocage ? Ce n’étaient pas des finitions autour d’une technologie déjà prête. C’était le travail nécessaire pour qu’une personne extérieure au réseau puisse s’en servir.

Le 12 juillet, Robert Kahn présente le projet dans la RFC 371. L’International Computer Communications Conference devait se tenir à Washington du 24 au 26 octobre. Une démonstration de réseau aurait lieu en parallèle des sessions, pour donner aux participants une expérience directe plutôt qu’une simple explication. Kahn envisage la recherche dans des bases de données, l’usage combiné de plusieurs machines, l’accès à des données en temps réel, la coopération interactive, la simulation et l’impression simplifiée. Il s’agit d’axes de préparation, pas de la liste définitive de chaque activité réellement proposée.

Le parcours matériel comptait. Les terminaux du Hilton devaient être raccordés à un TIP, lui-même relié à ARPANET. Les visiteurs pourraient ainsi atteindre des programmes et des informations hébergés sur des machines distantes. Kahn évoque aussi des ressources d’autres réseaux qui seraient reliés temporairement pour l’occasion. Le TIP devait fournir un point d’entrée commun : le visiteur n’avait pas à disposer d’une ligne distincte vers chaque ordinateur. Mais ce point partagé faisait de sa capacité et de la compatibilité des terminaux une partie de l’expérience publique.

Le plan d’essais restait à faire

La RFC 372, rédigée par Richard Watson, consigne une conversation avec Kahn le même jour. Elle imagine des tables dans une salle de bal, souvent avec un ou deux terminaux, sans que l’aménagement soit encore arrêté. Beaucoup de terminaux pourraient rester sans opérateur. Watson note que les deux hommes évoquent la présence d’experts de différents sites du réseau, mais que le nombre de volontaires est incertain. Un terminal connecté pouvait tout de même laisser un visiteur seul devant une invite de commande.

La phrase la plus frappante des notes de Watson demande elle aussi de la prudence : le TIP n’avait pas encore été testé avec 64 terminaux. Des essais étaient prévus en juillet, puis il fallait vérifier quels terminaux fonctionneraient avec quelles ressources. Si le TIP ne supportait pas toutes les connexions, les sessions pourraient être planifiées à tour de rôle. Il s’agit d’un état des lieux de juillet, non d’une preuve d’échec en octobre ni du nombre final de terminaux installés.

Les notes signalent aussi la pression du calendrier : la salle ne serait peut-être disponible qu’à partir du 22 octobre, ce qui laissait peu de temps pour installer le plancher, les équipements et les lignes téléphoniques. Kahn espérait disposer d’une démonstration fonctionnelle chez BBN en août.

L’interface du réseau dépassait donc le matériel. Kahn explique que les organisateurs préparent une documentation explicite, facile à comprendre, afin qu’un novice puisse utiliser certains services sans aide. Watson mentionne des panneaux, une fiche de commandes du TIP, une brochure de scénarios, un film et des personnes présentes dans la salle. En octobre, le Network Information Center publie Scenarios for Using the ARPANET, un guide qui transforme des usages possibles en étapes que le visiteur peut suivre. Kahn qualifie la documentation de tâche non triviale. Il ne suffit pas d’énumérer les capacités du réseau : il faut rendre un service distant repérable à quelqu’un qui ignore le nom de son hôte, son langage de commande et ses habitudes locales.

L’interopérabilité avait une interface humaine

Ce travail éclaire l’importance de la démonstration au-delà de sa visibilité. Le visiteur traversait une chaîne de systèmes et d’organisations : un terminal prêté, un câblage local, un TIP, ARPANET, un ordinateur hôte et une application entretenue à distance. Chaque maillon pouvait fonctionner techniquement tandis que l’ensemble restait difficile à comprendre. Les scénarios et les personnes disponibles reliaient des machines et des équipes qui ne partageaient ni le même lieu ni nécessairement le même vocabulaire.

La demande de Kahn aux sites du réseau de consacrer du temps et de l’énergie révèle le coût organisationnel. Les ressources distantes ne formaient pas une exposition cohérente simplement parce qu’elles figuraient sur un schéma : leurs responsables devaient préparer les applications et coordonner l’accès. Les notes de Watson citent des contributions envisagées dans plusieurs laboratoires et hors du réseau, tout en précisant que certains engagements restaient incertains. Watson ajoute qu’à son avis, l’ARPA n’avait pas prévu de budget important au-delà des contributions des contractants.

Il présente explicitement cette idée comme sa propre conclusion, non comme une déclaration de Kahn ni comme un audit.

Un rapport rétrospectif sur ARPANET décrit la démonstration d’octobre comme un effort obligeant les participants à déboguer et à tester le support réseau et les protocoles d’application. Avec les RFC de juillet et le guide de scénarios, l’événement apparaît moins comme le dévoilement d’une machine unique que comme un test coordonné : des ressources diverses pouvaient-elles être rendues accessibles à travers le réseau ?

La distinction est importante. Les paquets transportaient des demandes ; l’exposition devait leur donner un objectif et un chemin. En 1972, présenter publiquement les réseaux supposait une liaison fonctionnelle, mais aussi une interface d’usage faite de terminaux, de commandes, de documentation, de programmes préparés et d’assistance humaine. Le réseau devenait tangible lorsqu’un visiteur pouvait en faire quelque chose. En juillet, ce résultat dépendait encore d’un travail d’intégration à terminer.

Sources