Résumé

  • Margaret Hamilton a raconté plus tard avoir proposé un affichage prioritaire et un délai de cinq secondes : une urgence pouvait remplacer les informations ordinaires, puis l’astronaute avait le temps de répondre. Son récit porte sur une interface et une procédure, non sur un ordinateur qui aurait choisi l’issue de l’alunissage.
  • Les archives d’Apollo 11 consignent les alarmes 1202 et 1201, les observations de l’équipage et les appels « Go » de Charlie Duke. Les annotations de la NASA et les souvenirs de plusieurs ingénieurs éclairent des moments différents de la chaîne de conseil ; ils ne doivent pas être réduits à l’exploit d’une seule personne.
  • Un signal prioritaire peut interrompre l’attention sans conférer le pouvoir d’agir. L’autorisation dépend encore du rôle de chacun, des éléments disponibles, de la procédure et d’un jugement humain.

L’alerte n’est pas encore une décision

Le récit le plus intéressant de Margaret Hamilton n’est pas celui d’une personne qui aurait, seule, sauvé Apollo 11. C’est celui d’une ingénieure confrontée à une question d’interface : si l’écran présente déjà des données utiles à une tâche, comment l’ordinateur peut-il faire comprendre qu’un état exceptionnel exige désormais l’attention de l’astronaute ? Dans son entretien rétrospectif avec le Computer History Museum, Hamilton se souvient avoir proposé un affichage prioritaire qui interrompait la présentation normale et laissait cinq secondes à l’astronaute pour répondre. Elle attribue la mise en œuvre matérielle à ses collègues et rappelle que la procédure fut intégrée aux listes de contrôle et à la formation de Houston. C’est un témoignage précieux sur la manière dont elle comprenait le problème et son rôle ; ce n’est pas, dans les sources examinées ici, une spécification technique contemporaine qui confirmerait chaque détail de conception.

Cette prudence ne diminue pas sa contribution. Elle en précise la portée. Le dispositif décrit donne à une condition urgente le moyen de passer devant l’information ordinaire. Il organise une interruption et ménage un temps de réponse. Il ne dit pas à lui seul si l’astronaute doit poursuivre la tâche, demander une explication, attendre ou s’en remettre à Houston. Le logiciel peut modifier ce que voit une personne et le moment où elle le voit ; l’attention ainsi captée ne devient pas automatiquement une autorisation.

Le délai de cinq secondes est donc moins une règle universelle qu’un indice de conception. Les sources consultées ne permettent pas de conclure que cinq secondes constituaient la durée optimale dans toutes les situations. En revanche, le souvenir de Hamilton décrit une séquence : le message prioritaire apparaît, un humain peut répondre, puis le système reprend selon une règle. Le comportement dépend à la fois du signal, du temps laissé à la personne et de ce que l’ordinateur fait ensuite. Une interface sûre rend ces trois éléments compréhensibles.

La notice biographique de la NASA situe Hamilton à la tête de la division de génie logiciel du laboratoire d’instrumentation du MIT, au sein d’un effort collectif de guidage Apollo. En 2003, la NASA a également reconnu Hamilton et son équipe pour leur contribution aux logiciels de vol, dans son annonce de récompense. Ces sources attestent un rôle important et une reconnaissance institutionnelle ultérieure ; elles ne démontrent pas qu’elle ait écrit seule chaque programme ou détenu l’autorité opérationnelle sur l’alunissage. Son travail gagne à être décrit à l’échelle où il s’inscrit : une équipe, des interfaces matérielles, des procédures et des utilisateurs.

Ce que les alarmes 1202 et 1201 permettent d’affirmer

Pendant la descente lunaire du 20 juillet 1969, l’équipage d’Apollo 11 a signalé les alarmes informatiques 1202 puis 1201. Le journal de l’alunissage rassemble les échanges radio et des annotations éditoriales rédigées après la mission. On y lit l’annonce d’Aldrin, des demandes de renseignement et les appels « Go » transmis par Charlie Duke. Une alarme 1201 reçoit à son tour une réponse de ce type. Le journal établit ce qui a été prononcé et l’ordre général des événements ; ses annotations ne sont pas toutes des paroles enregistrées en direct.

Le résumé de mission replace ces échanges dans la chronologie de l’atterrissage. Le rapport de mission Apollo 11 apporte une explication technique ultérieure : les alarmes sont reliées à des interruptions de compteur inattendues associées aux interfaces du résolveur du radar de rendez-vous, lesquelles mobilisaient plus de dix pour cent de la capacité de l’ordinateur. Parler d’un simple « plantage » ferait perdre cette précision. Le rapport décrit un problème de charge et de priorité ; il ne répond pas, à lui seul, à la question de ce que chaque personne savait au moment de choisir la suite.

Plusieurs rôles se succèdent alors. Une activité liée au radar génère des interruptions ; le logiciel ordonne le travail ; l’ordinateur émet une alarme ; l’équipage l’observe et la signale ; des spécialistes au sol en évaluent la portée ; Houston communique une réponse. L’alarme est une sortie du système, pas une décision d’atterrir. L’observation de l’équipage, l’évaluation technique et l’appel radio sont eux aussi des actes distincts. Dire que « l’ordinateur a décidé que l’atterrissage était sûr » effacerait cette séparation tout autant que d’attribuer l’issue à un seul ingénieur.

Les annotations de la NASA donnent un rôle important au Guidance Officer Steve Bales dans l’évaluation du risque pour l’atterrissage. Des souvenirs ultérieurs, dont celui de Hamilton, mettent également en avant Jack Garman pour sa connaissance des alarmes et ses conseils. Ces récits ne sont pas forcément incompatibles : reconnaître un code, recommander une conduite, apprécier le risque et transmettre le « Go » peuvent être quatre moments différents. Mais les sources publiques ne reconstruisent pas chaque transfert d’information avec assez de détail pour les fondre en une chaîne de commandement entièrement certaine.

Les témoignages rétrospectifs de Frank McGwire et Peter Adler ouvrent deux autres fenêtres. Dans son récit à la première personne, McGwire décrit son expérience des alarmes et les réactions de l’équipe d’ingénierie. Le témoignage distinct de Peter Adler apporte le point de vue d’un autre participant. McGwire dit ne pas avoir lui-même rencontré ces alarmes dans ses essais avant le vol ; cette phrase concerne son expérience personnelle, pas l’ensemble des simulations ou des procédures de récupération du programme. De même, le fait que Hamilton cite Garman ne justifie pas d’écarter Bales, nommé dans les annotations de la mission.

Les sources suggèrent également que la connaissance acquise en simulation n’était pas transmise de manière identique à tous. Les annotations évoquent des alarmes simulées antérieures ; Aldrin a ensuite rappelé que leur signification ne lui avait pas été pleinement expliquée. Cela suffit à observer une frontière de connaissance entre ingénieurs, équipage et contrôle au sol. Cela ne permet pas de dire qu’Apollo n’avait pas été testé, ni qu’un seul groupe détenait tout le savoir utile.

Un essai peut produire un résultat sans que chaque opérateur en reçoive l’explication ; une formation peut présenter une procédure sans préparer à reconnaître immédiatement toutes ses variantes.

La contribution de Hamilton, à sa juste échelle

La tentation est grande de relier directement le récit des cinq secondes aux alarmes de l’alunissage : l’affichage prioritaire aurait interrompu l’écran, puis sauvé l’équipage. Les documents utilisés ici ne démontrent pas ce lien causal. L’entretien de Hamilton décrit l’intention et le développement dont elle se souvient ; le journal de vol documente des alarmes et des communications. Aucun document de conception contemporain dans ce corpus ne montre que le délai de cinq secondes ait été déclenché par l’alarme 1202 ou 1201. Deux dossiers liés par la question de l’information ne constituent pas, à eux seuls, une preuve de causalité.

La valeur de l’histoire se trouve ailleurs. Hamilton a décrit un défaut possible de la voie d’information : une situation urgente ne devait pas rester noyée dans les données normales. La réponse associée à son récit mobilisait le logiciel, le matériel et les pratiques opérationnelles. L’ordinateur signalait une priorité ; l’astronaute disposait d’un intervalle pour répondre ; les procédures et l’entraînement rendaient cette interaction reconnaissable. C’est une contribution aux conditions de l’exercice du jugement humain, non le transfert de ce jugement à la machine.

Le projet Apollo reposait sur des équipes de la NASA, du laboratoire du MIT, des ingénieurs matériels, des spécialistes systèmes, des contrôleurs de vol, des équipages et des équipes d’essais. Hamilton dirigeait une division logicielle dans ce réseau. Le comportement d’un affichage peut traverser plusieurs responsabilités : un logiciel demande un changement de présentation ; le matériel doit pouvoir le montrer ; les procédures expliquent ce que l’équipage est censé faire ; la formation met le cas en pratique ; les équipes au sol relient l’état embarqué à leur propre diagnostic. Aucun titre individuel ne résume à lui seul cette chaîne.

La conception d’un logiciel critique ne se réduit donc pas à l’écriture d’instructions. Elle comprend des choix de priorité, de temporisation, de modes dégradés et d’attentes envers les opérateurs. Le récit du décompte de cinq secondes pose des questions précises : quel état peut interrompre l’écran ? Que se passe-t-il si l’astronaute répond, ne répond pas ou demande plus d’informations ? Quelle tâche reprend ensuite ? Les sources citées ne fournissent pas le cahier des exigences complet, le code, les essais de réception ou le programme de formation associé.

Ces absences limitent la reconstruction ; elles ne prouvent pas que ces documents n’existent pas.

Une alarme ne distribue pas seule l’autorité

Une interface prioritaire exerce un pouvoir réel : elle modifie ce qui occupe l’attention. Le signal peut demander un examen urgent sans être auto-interprétable. Un code exige une correspondance avec un état, un contexte temporel et une compréhension des conséquences. La même alarme peut avoir une portée différente selon la phase de mission, la charge simultanée, la capacité restante et les procédures de reprise connues. Si l’écran n’affiche pas assez de contexte, l’équipage doit parfois consulter une autre source ou attendre une expertise au sol.

Le journal d’Apollo 11 rend cette différence visible. Aldrin signale une observation ; Duke transmet une réponse de Houston ; les annotations attribuent une évaluation à Bales ; les souvenirs d’autres participants mentionnent Garman. La machine produit le code. Ces faits n’impliquent pas qu’un seul rôle ait pris toutes les décisions. Il faut distinguer celui qui détecte, celui qui interprète, celui qui accepte le risque opérationnel et celui qui communique l’autorisation. Le dossier public laisse certaines transitions ouvertes ; mieux vaut les conserver comme telles que de les compléter par un récit héroïque.

Le délai lui-même est une règle décidée par des humains. À son expiration, l’ordinateur doit restaurer l’écran antérieur, répéter l’alarme, entrer dans un mode sûr ou poursuivre la tâche. Chaque solution choisit un risque plutôt qu’un autre lorsque la personne ne répond pas. Le souvenir de Hamilton rend cette question visible, mais les éléments disponibles ne permettent pas d’affirmer que « cinq secondes » soit la norme de sécurité appropriée. La leçon transférable est de spécifier l’interruption, le temps de réponse et le comportement de repli, puis de tester la séquence sous charge réaliste.

Une méthode de lecture pour les systèmes actuels

Le lien avec les logiciels d’aujourd’hui ne consiste pas à copier l’architecture d’Apollo. Il tient à une difficulté récurrente : notifications, tableaux de bord, interverrouillages et escalades automatiques prennent tous part à la répartition de l’attention. Pour les évaluer, il faut savoir quel état déclenche le signal, quelles preuves le destinataire peut consulter, qui possède l’expertise et l’autorité pour répondre, ce qui arrive après un acquittement ou un délai, et si l’action laisse une trace vérifiable.

Trop d’interruptions finissent par se banaliser : le destinataire peut apprendre à les acquitter sans les examiner. À l’inverse, un signal important noyé dans l’affichage ordinaire peut rester invisible au moment critique. La priorité est une ressource rare. Elle doit être justifiée, et le message devrait préserver assez de contexte pour que la personne comprenne pourquoi son travail est interrompu. C’est une question de gouvernance autant que d’ergonomie, puisque seuils, capteurs, procédures et conséquences peuvent relever d’équipes différentes.

Les essais doivent porter sur l’interaction, pas seulement sur le calcul. Un test unitaire peut vérifier qu’un indicateur prioritaire s’active. Une simulation peut révéler une interaction temporelle. Un exercice peut montrer si l’utilisateur reconnaît l’alarme ; une revue de procédure, si le bon rôle reçoit l’information ; une répétition interéquipes, si le transfert entre système embarqué et contrôle au sol fonctionne. Chaque essai produit une catégorie de preuve différente. La réussite de l’un ne garantit pas celle des autres.

L’histoire d’Apollo invite à séparer ces preuves ; elle ne prétend pas qu’un protocole contemporain particulier était appliqué en 1969.

Conclusion : interrompre, puis laisser décider

Le récit de Hamilton conserve toute sa force dès lors qu’on ne lui attribue pas plus qu’il ne démontre. Elle a décrit un problème d’attention et une solution d’affichage prioritaire assortie d’un temps de réponse. La NASA la présente comme une dirigeante d’une équipe logicielle et l’a plus tard reconnue, avec ses collègues, pour son travail. Le dossier d’Apollo 11 montre que les alarmes ont été traitées dans un système opérationnel où équipage, spécialistes et communications au sol remplissaient des rôles distincts.

Le sujet n’est donc pas de savoir si un écran ou une personne a « sauvé la mission ». Il est de comprendre la chaîne qui rend possible une décision : le logiciel indique où regarder ; une personne interprète ; les éléments disponibles et l’autorité de chacun déterminent l’action. Les cinq secondes sont une image mémorable de cette frontière, non la preuve que ce délai a résolu les alarmes précises de l’alunissage. Un système peut réclamer l’attention. Des personnes et des institutions doivent encore décider ce que le signal autorise.

Sources

Les sources sont volontairement de nature différente : témoignage rétrospectif, notice institutionnelle, dossier de vol, rapport technique et souvenirs de participants. Elles répondent chacune à une question distincte.