Résumé

  • Après son retour au sein de l’U.S. Navy en 1967, Grace Hopper contribua à organiser des tests et un service de validation des compilateurs. Dans son histoire orale de 1980, elle attribua à George Baird une méthode importante pour exécuter les mêmes routines de test sur des machines différentes.
  • Les tests rendaient observables certaines fonctions COBOL et leurs résultats. Ils ne démontraient ni l’exactitude totale d’un compilateur, ni la couverture de toutes les combinaisons, ni la portabilité automatique de chaque application.
  • Une norme définit une cible; une suite vérifie un échantillon limité; un test de migration porte sur le programme et son environnement réels. Confondre ces trois niveaux transforme une preuve bornée en promesse sans limite.

Une norme n’est pas un résultat

Pour une administration qui achetait des ordinateurs de plusieurs fabricants, COBOL portait une promesse économique: écrire un programme une fois, puis pouvoir le déplacer. Mais un langage commun ne garantissait pas à lui seul que tous les compilateurs interpréteraient chaque fonction de la même façon. La norme précisait le comportement attendu; elle ne mesurait pas l’implémentation livrée.

C’est dans cet écart que se situe l’épisode moins raconté de la carrière de Grace Hopper. Au lieu de revenir sur le débat populaire autour du « premier compilateur » ou de présenter COBOL comme son œuvre individuelle, il s’agit ici de comprendre comment une ambition de compatibilité est devenue une pratique de vérification. L’administration avait besoin de résultats reproductibles: le compilateur accepte-t-il une fonction requise? Le programme produit-il la sortie attendue? Le même contrôle peut-il être exécuté ailleurs?

L’histoire technique était déjà collective. Dans son article de 1972 sur le système de validation COBOL du Department of Defense, George N. Baird remonte à un groupe de travail créé en 1963. Ce groupe rédigeait des programmes destinés à vérifier la disponibilité de fonctions définies par la norme. Il ne cherchait pas à tester toutes les combinaisons possibles ni à déboguer chaque compilateur. Il sélectionnait des cas, seuls ou combinés, puis enregistrait ce qui se passait.

Rendre l’échec lisible

Le premier ensemble de routines de l’U.S. Navy, décrit par Baird, reprenait les travaux antérieurs et ajoutait des informations utiles: le résultat obtenu par la machine pouvait être comparé au résultat attendu, et le rapport identifiait la procédure où un échec était apparu. La version préliminaire comptait douze programmes et environ 5 000 lignes de code source.

Ce niveau de détail change la nature de la discussion. «Notre compilateur prend en charge COBOL» est une affirmation générale. «Ce compilateur a accepté telles constructions et produit telles sorties dans cette configuration de test» est une proposition qu’un autre acheteur peut examiner et répéter. La suite ne supprimait pas le jugement; elle en rendait une partie vérifiable.

Hopper racontait en 1980 que Norman Ream lui avait demandé de revenir au service actif en 1967 pour développer des procédures de test et de validation. Elle comparait le besoin à l’essai d’un produit: une norme a besoin de tests capables d’indiquer si l’implémentation la respecte. Elle précisa aussi qu’elle avait demandé des programmeurs. Elle nomma Ed Ford, un lieutenant et deux marins; George Baird faisait partie du premier groupe. Arnold Johnson arriva ensuite.

Le récit de Hopper est rétrospectif. Un article de Datamation publié en janvier 1971 apporte un autre repère, contemporain: il indique que l’U.S. Navy exigeait alors la validation des compilateurs COBOL et que le DoD et le National Bureau of Standards s’étaient accordés en principe sur une suite de tests commune, alignée sur la norme ANSI. «En principe» ne signifie pas que le service fédéral était déjà achevé; le texte décrit l’état du projet à cette date.

La contribution qu’elle attribua à George Baird

Le passage le plus révélateur de l’entretien n’est pas une revendication personnelle. Hopper expliqua que George Baird avait trouvé comment isoler les différences propres à chaque ordinateur — noms particuliers et cartes de contrôle — dans des données de configuration séparées. Les routines de test communes pouvaient rester écrites dans le langage standard; un petit fichier apportait les adaptations propres à la machine testée.

La portabilité concernait donc aussi l’outil de contrôle. Réécrire chaque test pour chaque compilateur aurait rendu les comparaisons plus coûteuses à entretenir et plus faciles à biaiser. En séparant la logique commune de la configuration particulière, l’équipe pouvait réutiliser les mêmes vérifications tout en reconnaissant les différences entre systèmes.

Il faut garder les deux niveaux de preuve ensemble. Hopper se souvient d’avoir obtenu la mission et réuni une équipe; Baird publie l’architecture du système et ses détails. Les sources étayent une répartition des rôles: Hopper a contribué à installer la capacité institutionnelle, Baird a conçu une technique importante de réutilisation, et la validation s’appuyait sur des travaux antérieurs et d’autres collaborateurs. Elles ne justifient pas de transformer l’une ou l’autre personne en auteur unique.

Ce qu’un test réussi ne garantissait pas

Un passage réussi montrait que le compilateur avait traité les fonctions sélectionnées et produit les sorties attendues dans les conditions du test. Il ne démontrait pas que toutes les combinaisons valides avaient été essayées, que tout défaut avait été découvert ou qu’une application donnée fonctionnerait sans changement sur une autre machine.

Cette limite n’est pas propre à COBOL. Le récit de NIST sur un autre effort, mené par Betty Holberton et Elizabeth Parker autour de tests FORTRAN, rappelle qu’aucune suite finie ne peut prouver complètement l’exactitude d’un compilateur. Il s’agissait d’un projet distinct du NBS, non du système COBOL de Hopper. Garder cette séparation rend le portrait plus juste: la validation des langages devenait une pratique institutionnelle portée par plusieurs équipes et plusieurs langages.

La conformité du compilateur et la portabilité d’une application restent deux niveaux différents. Un compilateur peut réussir les tests choisis tandis qu’un programme dépend d’une extension propriétaire, d’un service du système d’exploitation, d’un format de fichier, d’un comportement d’exécution ou d’une représentation des données. C’est une déduction à partir du périmètre des tests, non l’affirmation que la suite de l’U.S. Navy avait examiné toutes ces dépendances. Le déplacement d’une application exige aussi des tests propres à l’application et un relevé de son environnement.

La leçon n’est donc pas de se méfier des normes ou des tests. Il faut nommer exactement la preuve: la norme décrit le comportement attendu; une suite contrôle un échantillon borné d’une implémentation; un test de migration vérifie le système que l’acheteur veut réellement déplacer. Dire seulement «portable» masque la partie du risque qui reste.

Une preuve qui doit garder son périmètre

L’apport de Hopper paraît plus fort lorsqu’on ne l’exagère pas. Elle a contribué à faire d’un objectif de compatibilité une fonction de validation dotée d’une équipe. Son témoignage rappelle aussi une pratique de direction rarement mise en avant dans les récits du génie solitaire: demander des collaborateurs et attribuer le mécanisme technique à la personne qui l’a conçu.

Les tests de Baird montrent ce que cela change. La portabilité ne se réduisait pas à une déclaration de comité; elle dépendait de la conception des cas, des adaptations par machine, de la comparaison des sorties et de l’exécution répétable. Une norme sans test observable laissait l’acheteur avec une affirmation. Une suite sans attribution effaçait ses auteurs. Une réussite sans limites risquait de devenir une promesse plus vaste que la preuve.

Pour un logiciel qui doit durer, le reçu devrait donc accompagner l’affirmation: quelle version de la norme, quel compilateur, quels tests, quelle configuration propre à la machine et quels résultats? Le travail de Hopper n’a pas supprimé les différences entre fournisseurs. Il a donné aux institutions un moyen d’en rendre certaines visibles, de comparer des implémentations et d’acheter avec des éléments plus solides. C’est plus précis que «COBOL rendait les logiciels portables» — et plus durable.

Sources