07.10.2026 · Signal Titans Editorial

Margaret Hamilton a conçu le logiciel Apollo pour échouer sans catastrophe, pas pour ne jamais échouer

Margaret Hamilton près de piles de listings du logiciel Apollo dans une couverture éditoriale cinématographique sombre.

Trois minutes avant l’alunissage d’Apollo 11, l’ordinateur du module lunaire s’est mis à afficher des alarmes de programme.

La vraie question d’ingénierie n’était pas de savoir si l’ordinateur pouvait éviter toute surcharge.

Il fallait savoir si le logiciel pouvait reconnaître une surcharge, abandonner les tâches secondaires, préserver l’essentiel et récupérer assez vite pour que la mission continue.

Cette distinction se trouve au cœur du travail de Margaret Hamilton au MIT Instrumentation Laboratory.

Le logiciel est devenu critique avant que la discipline soit mature

Lorsque la NASA attribua au MIT son premier contrat Apollo en 1961, le logiciel n’était pas encore considéré comme la discipline d’ingénierie mature qu’il allait devenir. L’Apollo Guidance Computer disposait de ressources minuscules selon les standards actuels, mais son logiciel devait gérer navigation, guidage, affichage, interaction avec les astronautes et séquences critiques en temps réel.

Hamilton finit par diriger la Software Engineering Division de l’Instrumentation Laboratory. Son équipe travaillait sur le logiciel de vol embarqué du module de commande et du module lunaire. La célèbre photographie de Hamilton à côté de hautes piles de code imprimé est forte parce qu’elle rend le logiciel physique : il n’était pas un accessoire invisible du programme Apollo, mais une partie du système opérationnel du vaisseau.

Le défi n’était pas seulement d’écrire des instructions correctes. Le logiciel devait continuer à se comporter intelligemment si des données arrivaient au mauvais moment, si la charge augmentait, si un opérateur se trompait ou si le matériel réagissait de façon imprévue.

Les alarmes d’Apollo 11 ont testé la récupération, pas la perfection

Pendant la descente lunaire du 20 juillet 1969, l’ordinateur de guidage a produit les alarmes 1201 et 1202. Les récits historiques de la NASA et des ingénieurs du système décrivent une surcharge de l’exécutif provoquée par des tâches inutiles liées au radar de rendez-vous pendant la descente.

L’ordinateur ne s’est pas simplement figé. Son logiciel exécutif pouvait redémarrer et reprendre certains programmes hautement prioritaires tout en abandonnant le travail non essentiel à l’alunissage. Ce comportement avait été conçu et testé avant la mission.

La version populaire de l’histoire se résume parfois à « Hamilton a écrit le code qui a sauvé Apollo 11 ». La réussite technique était plus large et collective. Hamilton dirigeait une grande organisation logicielle, tandis que de nombreux ingénieurs concevaient, implémentaient, testaient et soutenaient le système. La mission a continué parce que l’architecture et l’équipe opérationnelle avaient été préparées aux situations anormales.

Sa contribution se comprend donc mieux comme le leadership d’un système où la fiabilité incluait la capacité de récupérer proprement.

Les systèmes fiables supposent qu’un problème finira par arriver

Un système fragile fonctionne magnifiquement tant que toutes ses hypothèses restent vraies. Un système résilient part de l’idée inverse : une hypothèse finira par casser.

Hamilton a ensuite mis en avant des concepts comme le logiciel asynchrone, l’ordonnancement par priorité, les affichages prioritaires, les tests de bout en bout et la décision avec l’humain dans la boucle. La NASA a reconnu ces idées comme des fondations importantes de la conception moderne de logiciels ultra-fiables.

Cette philosophie apparaît clairement dans les alarmes Apollo. L’ordinateur pouvait distinguer le travail urgent du travail secondaire, redémarrer et préserver les tâches essentielles. Le contrôle mission pouvait interpréter les alarmes parce que ce comportement avait été testé et compris.

Rien de cela ne rendait l’échec impossible. Cela rendait l’échec récupérable.

La leçon profonde concerne l’architecture

Les équipes parlent souvent de fiabilité comme d’un problème de nombre de bugs : éliminez assez de défauts et le système devient sûr. Apollo montre une vérité plus difficile. Certains incidents naissent de combinaisons inattendues de composants corrects, d’un timing inhabituel, de ressources saturées ou de procédures qui interagissent mal avec le logiciel.

La fiabilité doit donc être conçue dans l’architecture et les opérations, pas ajoutée à la fin par davantage de tests.

Un bon système demande à l’avance : quel travail est réellement essentiel ? Que peut-on abandonner ? Quel état doit survivre à un redémarrage ? Que doit voir l’opérateur ? Que se passe-t-il lorsque la capacité est dépassée ? Comment l’équipe saura-t-elle que la récupération est sûre ?

Ces questions existent aujourd’hui dans les systèmes distribués, le cloud, l’aviation, les dispositifs médicaux, la cybersécurité et presque tout service qui doit rester disponible sous pression.

Pourquoi l’histoire de Hamilton reste actuelle

En 2016, Hamilton a reçu la Presidential Medal of Freedom pour ses contributions au génie logiciel et aux missions Apollo. Entre-temps, le logiciel était devenu l’infrastructure de presque tous les secteurs modernes.

Son histoire est utile précisément parce qu’Apollo a connu des alarmes. Un système qui ne subit jamais de stress nous apprend peu sur sa résilience.

Le meilleur test commence après l’alarme.

Le système peut-il identifier l’essentiel, abandonner le secondaire, retrouver un état connu, communiquer clairement avec les humains et continuer en sécurité ?

Le logiciel parfait est une ambition.

Le logiciel récupérable est une stratégie d’ingénierie.