Résumé

  • Le passage de NCP à TCP/IP exigeait une migration opérationnelle, pas seulement un nouveau protocole.
  • La compatibilité temporaire réduisait le risque, tandis que les essais et le 1er janvier 1983 rendaient le report plus coûteux.

L’histoire est souvent résumée par une date : le 1er janvier 1983. Pourtant, cette date n’aurait pas suffi si les services utilisés par les personnes et les organisations n’avaient pas suivi. Vint Cerf a co-conçu TCP/IP dans un effort collectif. Il n’a pas été l’inventeur unique du protocole ni l’opérateur unique du basculement. Jon Postel, Dave Crocker, les organisations hôtes et de nombreux implémenteurs ont également compté.

Dans son témoignage ultérieur, Cerf rappelle une exigence de l’ARPA et des essais d’arrêt de NCP en 1982. Il situe les essais de façon approximative : l’un vers le milieu de l’année, l’autre plus tard, peut-être en octobre. Il ne faut donc pas transformer ce souvenir en chronologie précise. Le point important est ailleurs : l’arrêt expérimental a perturbé le courrier et a exposé l’écart entre la présence d’un protocole et la disponibilité d’un service.

La RFC 773, publiée par Cerf en 1980, proposait une coexistence des services de courrier NCP et TCP. Elle décrivait des mécanismes de transfert explicites ou implicites et l’évolution des tables de capacités. Il s’agissait d’un pont de migration, non d’une preuve que chaque proposition avait été déployée exactement comme indiqué. La RFC 801, écrite par Jon Postel en 1981, élargissait le plan : objectif de basculement complet au 1er janvier 1983, responsabilités confiées aux organisations hôtes, conversion des services, essais et relais.

La migration concernait donc Telnet, le transfert de fichiers et le courrier électronique. Un hôte doté du code TCP/IP mais incapable d’offrir ces services n’était pas réellement prêt. La coexistence donnait du temps ; les essais rendaient les dépendances visibles ; la date de retrait créait une raison de terminer. C’est cette combinaison, et non le protocole seul, qui rendait le programme crédible.

Le récit historique ne promet pas une transition sans panne. Au contraire, la perturbation du courrier pendant les répétitions fournissait une information opérationnelle. Elle indiquait ce qu’il fallait réparer avant la date finale. Le Computer History Museum confirme la planification de 1981 et la standardisation de janvier 1983. Pour les opérateurs actuels, on peut en tirer une inférence éditoriale : une migration complexe a besoin d’une période de compatibilité, d’un inventaire des dépendances, d’essais réalistes et d’une date de fin explicite. Les sources historiques ne prescrivent toutefois pas directement les pratiques modernes.

Sources