Quelques minutes avant que le module lunaire ne touche le sol, en juillet 1969, l'ordinateur de bord se met à afficher des codes d'alarme. Les astronautes ne savent pas ce qu'ils signifient. À Houston, on dispose de quelques secondes pour décider s'il faut annuler l'alunissage. La réponse est : on continue. La machine est surchargée, mais elle ne panique pas. Elle abandonne ce qui peut attendre et garde ce qui compte : guider l'engin vers la surface. Cette réaction avait été prévu, des années plus tôt, par une équipe dirigée par une jeune mathématicienne du Massachusetts Institute of Technology, Margaret Hamilton.
La disparition d'une architecte de l'invisible
Margaret Hamilton est morte le 30 septembre 2026, à l'âge de 90 ans, comme l'a annoncé le MIT, son ancien employeur, dans un communiqué. L'institut la décrit comme une informaticienne « profondément influente », connue avant tout pour avoir dirigé l'équipe de génie logiciel de son Instrumentation Laboratory pendant le programme Apollo de la NASA. Elle y a travaillé de 1959 au milieu des années 1970.
La notice que lui consacre la revue Nature insiste sur deux idées qui font aujourd'hui partie du vocabulaire courant des informaticiens : la gestion des priorités entre tâches et la tolérance aux pannes. Deux idées qui semblent banales. Elles ne l'étaient pas du tout quand il fallait les faire tenir dans un ordinateur de bord aux ressources minuscules.
Un point mérite d'être dit dès le départ : Hamilton n'a pas codé seule. Selon le New York Times, elle dirigeait une équipe d'environ cent personnes chargée d'écrire le logiciel embarqué des missions Apollo, celui qui a guidé Neil Armstrong et Buzz Aldrin jusqu'au sol lunaire. Une œuvre collective, donc, et c'est justement l'organisation de ce collectif qui allait faire école.
L'art de savoir quoi oublier
Revenons à ces alarmes de 1969. Pour les comprendre, il faut d'abord comprendre ce qu'est un système « temps réel ». Un programme ordinaire doit donner la bonne réponse. Un programme temps réel doit donner la bonne réponse à temps. Une trajectoire calculée avec une seconde de retard, pendant une descente vers la Lune, est une trajectoire fausse. Le temps devient une contrainte au même titre que l'exactitude.
Or l'ordinateur de guidage d'Apollo, l'Apollo Guidance Computer, ne disposait que d'une mémoire de travail limitée. Il devait pourtant mener de front plusieurs tâches : lire les capteurs, mettre à jour la position, piloter les moteurs, afficher des données aux astronautes. Chacune réclame une part du temps de calcul. Et ce temps est une ressource finie.
Imaginez que chaque tâche occupe une fraction de chaque seconde : 30 % pour la navigation, 25 % pour le pilotage, 20 % pour l'affichage, 15 % pour la surveillance. Total : 90 %. Tout va bien. Ajoutez maintenant une tâche parasite qui réclame 20 %. On atteint 110 % d'une seconde à faire tenir dans une seconde. Quelque chose doit céder.
La question n'est donc pas « comment éviter la surcharge ? » (on ne peut pas toujours) mais « que sacrifier quand elle arrive ? ». La réponse de l'équipe tient en un principe : attribuer à chaque tâche un rang d'importance et, en cas de saturation, laisser tomber les moins prioritaires pour sauver les plus vitales. C'est ce que les informaticiens appellent un ordonnancement par priorités.
L'élégance du dispositif tient à un renversement. Plutôt que de rêver d'un système qui n'échoue jamais, on conçoit un système qui sait comment échouer. La panne cesse d'être un accident pour devenir un scénario prévu, avec sa propre procédure. C'est toute la philosophie de la tolérance aux pannes que met en avant la notice de Nature.
De la Lune aux cockpits
Les principes éprouvés sur Apollo ont essaimé dans tout ce qu'on appelle aujourd'hui les systèmes embarqués critiques, ces ordinateurs enfouis dans une machine dont la défaillance peut coûter des vies. Commandes de vol des avions, freinage des voitures, appareils médicaux : partout où un calcul doit arriver à l'heure, on retrouve ces principes : hiérarchiser les tâches, prévoir la surcharge, survivre à l'erreur.
L'idée est désormais si familière qu'on oublie qu'elle a dû être inventée.
Et voilà peut-être le plus bel héritage de Margaret Hamilton et son équipe : avoir montré que la fiabilité ne vient pas de la puissance d'une machine, mais de la clarté avec laquelle on lui a appris à choisir.
Concepts à emporter
Sous la pression de l'horloge : quand la charge dépasse 1
Formalisons le petit calcul de pourcentages évoqué plus haut. Considérons un processeur unique qui doit exécuter n tâches répétitives. Chaque tâche numéro i se reproduit à intervalles réguliers de durée Ti (sa période) et demande, à chaque répétition, un temps de calcul Ci. Sa part de l'occupation du processeur est le rapport Ci/Ti : une tâche qui demande 3 millisecondes toutes les 10 millisecondes occupe 30 % du temps.
On appelle taux d'utilisation la somme U = C1/T1 + … + Cn/Tn. Première observation, élémentaire mais implacable : si U > 1, aucune stratégie, aussi astucieuse soit-elle, ne permet de tout exécuter à temps, car on demande plus de temps de calcul qu'il n'en existe. Il faut alors renoncer à certaines tâches : c'est le délestage par priorités.
Plus surprenant : U ≤ 1 ne suffit pas toujours, si les priorités sont fixées une fois pour toutes. Un résultat classique, dû à Chung Laung Liu et James Layland en 1973 (donc postérieur à Apollo), traite le cas où l'on donne la priorité aux tâches de période la plus courte. Ils montrent que toutes les échéances sont garanties dès que U ≤ n(21/n − 1). Pour une tâche, la borne vaut 1 ; pour deux, environ 0,83 ; et quand n devient grand, elle tend vers ln 2, soit environ 0,69. Autrement dit, avec beaucoup de tâches à priorités fixes, ne charger le processeur qu'aux deux tiers est la seule garantie universelle : au-delà, il faut examiner le cas particulier.
Cette marge de sécurité, qui paraît du gaspillage, est le prix mathématique de la ponctualité. Les concepteurs de systèmes critiques le paient sciemment, en sachant que le jour où la charge dépassera malgré tout la capacité, le dernier rempart sera la même idée qu'en 1969 : savoir ce qu'on peut se permettre de laisser tomber.
