Une mission lunaire cachée dans deux classeurs
Voici une vérité surprenante : le code qui a permis aux humains de se poser sur la Lune en 1969 existe toujours, méticuleusement transcrit à partir de deux classeurs papier conservés au MIT Museum. Des bénévoles ont minutieusement converti ces scans historiques en une base de code numérique utilisable, désormais accessible au public et exécutable. C'est un témoignage de préservation et d'effort collaboratif.
Ce n'est pas l'histoire d'un génie solitaire. Margaret Hamilton, alors informaticienne pionnière, dirigeait la Software Engineering Division au MIT Instrumentation Laboratory. Son équipe de plus de 400 personnes a développé les logiciels critiques pour les modules de commande et lunaire d'Apollo. Le leadership de Hamilton et l'ampleur de l'effort soulignent le génie collectif derrière Apollo.
Écrit en langage assembleur pour l'Apollo Guidance Computer, ce code source survivant peut être assemblé pour correspondre parfaitement à l'image mémoire originale. Les passionnés peuvent même l'exécuter via l'émulateur Virtual AGC, en faisant l'expérience des séquences exactes exécutées par les astronautes d'Apollo 11. Cela offre un aperçu sans précédent du monde rigoureux et contraint des premiers logiciels de vol spatial.
L'ordinateur avait moins de mémoire qu'un tweet
Les missions lunaires fonctionnaient sur du matériel moins puissant qu'un thermostat moderne. L'Apollo Guidance Computer (AGC), construit au MIT Instrumentation Laboratory, fonctionnait à seulement 1,024 MHz, avec seulement 2 048 mots de mémoire effaçable—environ 3 840 octets. Un Raspberry Pi Pico moderne, en comparaison, possède 70 fois plus de RAM et une horloge 130 fois plus rapide.
Les contraintes définissaient l'AGC. Ses 72 Ko de mémoire morte reposaient sur la core rope memory, une merveille de programmation physique. Des fils enfilés à travers de minuscules noyaux magnétiques encodaient le logiciel directement : un fil passant à travers un anneau signalait un « 1 » binaire, autour de lui un « 0 ». Cela signifiait aucune mise à jour logicielle rapide ; le code de vol était littéralement tissé dans le matériel, verrouillé des mois avant le lancement.
De telles limitations ont forcé une conception brillante. Les ingénieurs ont créé un code exceptionnellement compact, rigoureusement vérifié pour la perfection. Le planificateur exécutif de l'AGC priorisait les tâches, gérant jusqu'à huit travaux dans des emplacements de 12 mots. Même les commentaires internes du code, comme le révèle un examen du dépôt GitHub transcrit, divergeaient parfois de la logique implémentée, un témoignage du développement rapide et itératif sous une pression extrême.
Le code contient des blagues. Les mesures de sécurité, elles, sont sérieuses.
L'humour, s'avère-t-il, est une constante universelle, même dans le code destiné à la Lune. Malgré l'immense pression, les ingénieurs du MIT Instrumentation Laboratory ont parsemé l'assembleur de l'Apollo Guidance Computer de commentaires délicieux et humanisants. « Please crank this silly thing around » demande à l'astronaute de déplacer l'antenne radar d'atterrissage, tandis que « Off to see the wizard » précède la séquence d'allumage du moteur, intitulée de manière ludique « Burn Baby Burn ».
Les astronautes interagissaient avec ce système complexe via le DSKY (Display/Keyboard), une interface minimaliste composée d'un petit clavier numérique et d'un écran. Les commandes étaient des paires verbe-nom numériques concises—un « verbe » pour l'action (par exemple, afficher) et un « nom » pour l'objet (par exemple, horloge). Ces instructions répétées, souvent mémorisées ou référencées à partir de listes de contrôle, étaient le seul moyen d'utiliser l'ordinateur en vol.
Pourtant, sous l'esprit se cachait une résilience à toute épreuve. L'Executive scheduler de l'Apollo Guidance Computer priorisait les tâches, garantissant que les fonctions de guidage critiques s'exécutaient toujours. Lorsque les systèmes étaient surchargés, comme ce fut le cas lors de la descente d'Apollo 11 en raison d'un radar de rendez-vous défectueux, les tâches moins importantes étaient abandonnées, déclenchant des alarmes comme la 1202.
De manière cruciale, les restart checkpoints protégeaient le travail vital. Si l'ordinateur redémarrait, il reprenait les processus essentiels à partir du dernier point de contrôle, allant même jusqu'à redémarrer le moteur de descente. Cette conception robuste a permis à l'ordinateur de gérer les pannes sans abandonner la mission, un témoignage de prévoyance sous des contraintes extrêmes. Pour ceux qui sont curieux d'explorer ce mélange de rigueur et d'humour, le code source original de l'Apollo 11 Guidance Computer (AGC) est disponible publiquement.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Pourquoi la 1202 n'a pas mis fin à l'alunissage
L'alarme 1202, tristement célèbre depuis l'alunissage d'Apollo 11, signalait une lutte désespérée pour le temps de processeur. Alors que le module lunaire descendait, le rendezvous radar consommait de manière inattendue 13 à 15 % des cycles de l'ordinateur en émettant 12 800 impulsions par seconde. Cette activité, combinée au processeur déjà utilisé à 90 %, empêchait les tâches de navigation critiques de se terminer à temps.
L'Executive de l'Apollo Guidance Computer (AGC), son ordonnanceur, ne pouvait gérer que huit emplacements de travail, chacun long de 12 mots. Lorsque la tâche de navigation ne parvenait pas à se terminer, de nouvelles copies se mettaient en file d'attente, remplissant rapidement ces emplacements et déclenchant l'alarme 1202. L'AGC a réagi en supprimant le travail non protégé et en redémarrant, en priorisant les fonctions de descente essentielles. Les contrôleurs de vol, notamment Steve Bales, ont dû évaluer rapidement si l'alunissage pouvait se poursuivre, une décision prise cinq fois au cours des dernières minutes.
Cette résilience n'était pas accidentelle. L'équipe de Margaret Hamilton au MIT Instrumentation Laboratory a conçu l'AGC avec une restart protection robuste, lui permettant de reprendre des opérations critiques même en pleine descente. Des points de contrôle tout au long du code garantissaient que les tâches vitales, comme le moteur de descente, pouvaient être réactivées immédiatement.
Aujourd'hui, la brillance de l'AGC est inspectable. Le projet Virtual AGC émule fidèlement l'ordinateur et son interface Display and Keyboard (DSKY), permettant à quiconque d'exécuter le code de vol d'Apollo 11. Vous pouvez explorer les séquences exactes utilisées par les astronautes, des vérifications pré-lancement aux alarmes d'alunissage, sur le dépôt Apollo 11 AGC. Comme l'a fait remarquer Hamilton, son équipe n'avait "aucune seconde chance", mais leur code nous donne des opportunités infinies d'apprendre.
Questions fréquemment posées
Peut-on exécuter le code source original d'Apollo 11 aujourd'hui ?
Oui. Le code source transcrit peut être assemblé et exécuté dans l'émulateur open-source Virtual AGC.
Quelle était la mémoire de l'Apollo Guidance Computer ?
Il disposait de 2 048 mots de mémoire effaçable, soit environ 3 840 octets, en plus de la mémoire morte fixe de type core rope.
Qu'est-ce qui a causé l'alarme 1202 lors de l'alunissage d'Apollo 11 ?
Les impulsions radar ont consommé du temps de processeur, surchargeant les emplacements de travail limités de l'ordonnanceur. L'ordinateur a supprimé les tâches de moindre priorité et a redémarré les tâches protégées.
Qui était Margaret Hamilton ?
Hamilton était une responsable logicielle sur le programme Apollo au MIT Instrumentation Laboratory et a aidé à développer le logiciel qui a guidé les missions habitées.

