En 2026, alors que les modèles d’intelligence artificielle consomment des dizaines de gigaoctets de mémoire pour générer une réponse, le code qui a guidé Neil Armstrong sur la Lune tient en 69 120 octets de mémoire morte. Ce dépôt GitHub, maintenu depuis plusieurs années par Chris Garry sous le nom chrislgarry/Apollo-11, continue de faire des milliers d’étoiles et de forks. Non pas par nostalgie, mais parce qu’il illustre une philosophie d’ingénierie que l’industrie cloud a largement oubliée : faire beaucoup avec très peu.

Le code source du Computer de guidage Apollo (AGC) est disponible en accès libre, numérisé à partir de copies conservées au MIT Museum avec l’aide du projet Virtual AGC. Deux programmes distincts composent ce dépôt : Comanche055 pour le module de commandement et Luminary099 pour le module lunaire. Cette distinction technique — deux logiciels différents pour un hardware partagé — est l’un des premiers enseignements que tout architecte cloud devrait méditer.

Contexte et enjeux : pourquoi ce code fascine encore en 2026

La résurgence régulière de ce dépôt dans les fils d’actualité tech n’est pas accidentelle. Elle survient dans un contexte où l’industrie du cloud affronte une double contrainte : explosion des coûts d’infrastructure liés à l’IA générative et pression croissante sur l’efficacité énergétique des centres de données. AWS, Azure et Google Cloud investissent des dizaines de milliards dans de nouveaux datacenters, pendant que les équipes d’ingénierie cherchent à optimiser des systèmes devenus opaques à force de couches d’abstraction.

Dans ce contexte, l’AGC d’Apollo 11 agit comme un miroir inconfortable. Il démontre qu’une mission spatiale critique — la plus regardée de l’histoire humaine — a été accomplie avec des contraintes matérielles que n’importe quel microcontrôleur bon marché surpasse aujourd’hui. La question que pose ce code n’est pas technique, elle est stratégique : pourquoi les systèmes modernes ont-ils besoin de tant pour faire si peu ?

Les faits : 3 840 octets de RAM pour naviguer vers la Lune

Les spécifications de l’AGC, documentées par le projet Virtual AGC, sont vertigineuses à l’heure de l’IA à grande échelle :

• RAM : 2 048 mots, soit environ 3 840 octets
• Mémoire morte (ROM) : 36 864 mots, soit 69 120 octets
• Vitesse d’exécution : environ 85 000 instructions par seconde
• Tâches simultanées : navigation, traitement inertiel, assistance aux manœuvres critiques

Ce n’était pas un logiciel monolithique. Chaque module — Comanche pour le vaisseau de commandement, Luminary pour le module lunaire — avait ses propres responsabilités fonctionnelles, même si le hardware était identique. Ce principe de séparation des responsabilités, aussi appelé separation of concerns dans l’architecture logicielle moderne, est aujourd’hui un fondement de la conception microservices et des architectures cloud natives.

Le dépôt mentionne également le nom de Margaret H. Hamilton en tant que Lead Programmer de Colossus. Ce détail révèle non seulement un rôle historique majeur dans l’histoire du logiciel, mais aussi comment les équipes validaient leurs programmes dans un environnement où l’erreur n’était pas une option. Aucun rollback possible à 380 000 kilomètres de la Terre.

Analyse : Docker, émulation et la leçon de l’open source spatial

Ce qui élève ce dépôt au-delà du simple artefact historique, c’est son opérationnalité. Le projet Virtual AGC permet d’assembler et d’émuler le logiciel de l’ordinateur Apollo sur des systèmes modernes, avec des outils comme yaYUL. Mieux encore : le simulateur peut être déployé via Docker, ce qui en fait un cas d’usage inattendu mais parlant — une charge de travail de 1969 encapsulée dans un conteneur en 2026.

Cette logique d’émulation n’est pas anecdotique. Elle illustre exactement ce que font les plateformes cloud avec la virtualisation : encapsuler un environnement d’exécution, reproduire un comportement, le rendre portable. L’AGC conteneurisé est une version archéologique, mais fonctionnelle, de ce que Kubernetes fait avec des microservices en production. Pour les équipes qui découvrent aujourd’hui des projets comme Autoskills pour déployer des compétences IA en une commande, ce parallèle entre ingénierie spatiale et automatisation moderne n’est pas qu’une métaphore.

Sur GitHub, le dépôt totalise des dizaines de milliers d’étoiles et plusieurs centaines de forks actifs. La communauté qui lit, corrige et compare ce code aux scans d’origine du MIT n’est pas un groupe d’historiens : ce sont des ingénieurs logiciels, des architectes cloud et des développeurs curieux. Cela fait de ce dépôt une infrastructure de préservation technologique ouverte et vivante, à l’image de ce qu’essaie de faire Docmost comme alternative open source à Confluence pour la documentation collaborative.

Perspectives : ce que l’AGC enseigne à l’architecture cloud en 2026

Le secteur cloud traverse en 2026 une période de rationalisation. Après des années de croissance effrénée, les DSI réexaminent leurs coûts d’infrastructure. Les concepts de FinOps, d’optimisation des charges de travail et de right-sizing des instances sont au cœur des discussions. Dans ce contexte, le cas Apollo n’est pas une curiosité : c’est un argument d’ingénierie.

Plusieurs leçons concrètes émergent de l’étude de ce code :

• Spécialisation par charge de travail : Comanche et Luminary avaient des logiciels distincts pour des missions distinctes. En cloud, cela correspond aux architectures event-driven où chaque fonction ne fait qu’une seule chose.
• Zéro tolérance aux ressources gaspillées : chaque instruction assembleur se justifiait. L’équivalent cloud est l’optimisation des conteneurs et la politique de lean containers.
• Observabilité par design : l’AGC affichait son état en permanence. Les pratiques modernes de monitoring et d’alerting en découlent conceptuellement.
• Résilience sans redondance massive : l’AGC ne pouvait pas se permettre un failover vers une deuxième région. La fiabilité venait du code lui-même, pas de l’infrastructure autour.

Ces principes résonnent avec les débats actuels autour de l’IA en périphérie (edge AI). Des projets comme MachinaOS, qui transfère l’IA du cloud vers vos propres serveurs, ou les travaux sur les architectures RISC-V pour des puces plus efficaces, poursuivent à leur manière la même obsession : extraire un maximum de valeur d’un minimum de ressources.

L’AGC d’Apollo 11 n’est pas un modèle à reproduire tel quel. Mais il reste une boussole utile dans un secteur qui a parfois tendance à confondre complexité et sophistication. Que ce soit pour concevoir un système embarqué, optimiser un pipeline serverless ou repenser l’architecture d’une application cloud native, la philosophie de Hamilton et de son équipe reste d’une actualité frappante.

FAQ — Apollo 11, GitHub et ingénierie cloud

Où trouver le code source d’Apollo 11 sur GitHub ?

Le code est disponible dans le dépôt public chrislgarry/Apollo-11 sur GitHub. Il contient les deux programmes principaux : Comanche055 (module de commandement) et Luminary099 (module lunaire), numérisés à partir des originaux conservés au MIT Museum.

Le logiciel Apollo 11 peut-il être exécuté aujourd’hui ?

Oui. Le projet Virtual AGC fournit un assembleur (yaYUL) et des simulateurs pour émuler le Computer de guidage Apollo sur des systèmes modernes. Le simulateur peut même être déployé via Docker, ce qui le rend accessible sans configuration locale complexe.

Quelles étaient les spécifications mémoire du calculateur Apollo ?

Selon la documentation de Virtual AGC, l’AGC disposait de 3 840 octets de RAM (2 048 mots) et de 69 120 octets de mémoire morte (36 864 mots), pour une vitesse d’exécution d’environ 85 000 instructions par seconde. À titre de comparaison, un smartphone d’entrée de gamme en 2026 intègre plusieurs gigaoctets de RAM.

Pourquoi deux programmes distincts (Comanche et Luminary) pour la même mission ?

Le module de commandement et le module lunaire avaient des missions fonctionnellement différentes, même s’ils partageaient une architecture hardware similaire. Ce choix de conception — un logiciel dédié par charge de travail — anticipe les principes modernes de séparation des responsabilités et d’architecture microservices utilisés aujourd’hui dans le cloud.

Quels enseignements ce code apporte-t-il pour l’ingénierie cloud moderne ?

Plusieurs principes restent directement applicables : spécialisation par charge de travail, optimisation stricte des ressources, observabilité intégrée et résilience par le design logiciel plutôt que par la redondance d’infrastructure. Ces concepts sont aujourd’hui au cœur du FinOps, de l’edge computing et des architectures serverless.

Qui a programmé le logiciel Apollo 11 ?

Le logiciel a été développé par les équipes du MIT Instrumentation Laboratory. Margaret H. Hamilton, citée comme Lead Programmer de Colossus dans le dépôt GitHub, est l’une des figures les plus connues de ce projet. Elle est souvent créditée d’avoir inventé le terme « software engineering » pour décrire le niveau de rigueur nécessaire à ce type de systèmes critiques.