Résumé

  • Dans le RFC 873, Michael Padlipsky contestait l’idée de reporter les achats de réseaux du ministère américain de la Défense jusqu’à l’arrivée d’une suite ISO prise en charge par des fournisseurs.
  • Une suite inachevée et des options laissées au choix des implémenteurs pouvaient produire deux produits conformes mais incapables de communiquer sans travaux supplémentaires.

La formule « pris en charge par le fournisseur » a une qualité admirable : elle tient sur une ligne de bon de commande. La question de ce que deux machines feront ensemble tient beaucoup moins bien sur cette ligne. Le RFC 873 est la réponse mordante de Michael A. Padlipsky à un débat de 1982 dans les achats informatiques du ministère américain de la Défense. Certains préféraient attendre des protocoles livrés par des fournisseurs, associés au modèle de référence ISO, plutôt que retenir la famille déjà utilisée dans le monde ARPANET. Ils espéraient ainsi économiser de l’argent public. Padlipsky a demandé de détailler ce qu’on achetait et quand cela fonctionnerait.

Il a d’abord démonté l’étiquette « suite ». X.25 couvrait une partie du chemin, selon son analyse, mais ne constituait pas à lui seul l’ensemble nécessaire au partage de ressources entre ordinateurs. Lui ajouter des spécifications d’accès ne donnait toujours pas la suite complète que travaillaient le National Bureau of Standards et l’ISO; ces deux efforts avaient en outre leurs différences. Un acheteur pouvait donc signer pour une expression séduisante alors que les pièces, leurs interfaces et leur statut restaient en discussion. Le vendeur était bien réel. L’objet unique qu’on croyait lui commander était encore en chantier.

Le calendrier rendait la confusion coûteuse. Padlipsky relevait la longueur des procédures d’achat du ministère. En septembre 1982, la suite liée au modèle ISO n’était pas achevée; plusieurs couches comportaient des propositions encore à éprouver. La normalisation prendrait des années, estimait-il, tandis que des contrats de mise en réseau étaient passés tout de suite. De l’autre côté du dossier figuraient des protocoles du modèle ARPANET déjà utilisés sur plusieurs systèmes d’exploitation employés au ministère. Ces logiciels avaient des frais d’intégration et de maintenance.

Ils avaient aussi l’avantage déterminant d’exister au moment où l’administration devait commander.

Le deuxième point de la note concerne le mot « soutien ». Une garantie de fournisseur ne tranche pas d’elle-même le sens d’une interface entre couches, le passage obligatoire ou facultatif par chacune d’elles, ni le nombre de protocoles autorisés à un niveau. Padlipsky énumérait ces questions en examinant les documents disponibles. Deux équipes pouvaient lire de bonne foi les mêmes principes et produire des comportements différents. Les produits auraient alors besoin d’un accord complémentaire, d’un correctif ou d’un adaptateur. La conformité sur la fiche commerciale laissait aux opérateurs le travail de faire circuler le paquet.

Les options rendent ce travail presque visible à l’œil nu. Le fournisseur A implémente une fonction facultative dont son client dépend. Le fournisseur B choisit de ne pas l’offrir. Aucun mensonge n’est nécessaire pour que les machines échouent à dialoguer. Il faut choisir une autre option, modifier une application ou payer de l’ingénierie. Dans le raisonnement de Padlipsky, la facture ira probablement au client. L’optionalité n’a pas supprimé la décision de compatibilité; elle l’a déplacée du texte commun vers la jonction entre deux installations.

Il y avait encore le prix payé par les machines elles-mêmes. Temps processeur et mémoire n’étaient pas abondants. L’essai interrogeait les règles qui pourraient imposer un passage par chaque étage d’un modèle ou multiplier les opérations de contrôle. Padlipsky rappelait un épisode où des sondes répétées avaient rendu plus chère l’exploitation d’un hôte. Cette histoire était une alerte sur une forme de coût, pas une mesure universelle de tous les produits. Pour signer sérieusement, il fallait demander une preuve de consommation de ressources, en plus du vocabulaire de la conformité.

L’auteur n’avait pas besoin d’imaginer un cartel de mauvais vendeurs. Il suggérait que les incitations de leurs équipes pouvaient simplement favoriser autre chose que de petites implémentations efficaces. Son dernier mouvement invoquait l’absence de repas gratuit : maintenance, interopérabilité, mémoire et cycles CPU avaient chacun leur addition. Il notait aussi que davantage de fournisseurs livraient, ou s’apprêtaient à livrer, TCP/IP. Le choix apparemment binaire entre « fournisseur » et « ARPANET » se brouillait déjà dans le marché qu’il décrivait.

L’intérêt du RFC 873 est de conserver cette discussion au présent de 1982. Il ne sert pas à deviner les résultats de tous les contrats ultérieurs. Il oblige plutôt à poser quatre questions avant l’achat : quelle suite est réellement prête, quelles interfaces ont un sens partagé, comment les options fonctionnent-elles entre deux produits, et qui paiera la différence ? Une signature commerciale crée une relation avec un fournisseur. Elle ne crée aucun accord entre deux ordinateurs par simple pression du stylo.