Philosophie de l'ingénierie : Margaret Hamilton

Points clés

• Elle a forgé le terme « software engineering » pour conquérir à la discipline sa légitimité. Alors qu’elle dirigeait l’effort sur le logiciel de vol d’Apollo au MIT Instrumentation Laboratory, Margaret Hamilton s’est mise à parler de « software engineering » — délibérément, pour soutenir que l’écriture du code qui emmenait des humains sur la Lune méritait la même rigueur et le même respect que l’ingénierie matérielle et l’ingénierie des systèmes, à une époque où le logiciel était traité comme une pensée après coup.¹²
• Son logiciel a sauvé l’alunissage d’Apollo 11 lorsque l’ordinateur de guidage a déclenché les alarmes 1202 et 1201. Pendant la descente finale, un commutateur de radar de rendez-vous mal configuré a fourni à l’Apollo Guidance Computer un travail parasite qu’il n’aurait jamais dû avoir, et l’exécutif a manqué de mémoire pour le planifier — les célèbres alarmes 1202 (« no core sets ») et 1201 (« no VAC areas »). Parce que l’équipe de Hamilton avait conçu le logiciel avec un ordonnancement par priorité et une protection par redémarrage, l’ordinateur a délesté les tâches radar de faible priorité, maintenu le guidage critique pour l’alunissage, et l’alunissage a réussi.³⁴⁵
• Son engagement déterminant, c’est la conception défensive : concevoir pour le cas d’échec, parce qu’il n’y a pas de seconde chance. « Il n’y avait pas de seconde chance. Nous le savions », a-t-elle dit à propos d’Apollo.² La détection des erreurs, la récupération, l’ordonnancement asynchrone par priorité et les affichages avec l’humain dans la boucle n’étaient pas des fonctionnalités greffées une fois le chemin heureux opérationnel — ils étaient le centre de la conception, la raison pour laquelle le logiciel se dégradait avec élégance au lieu de planter.⁶
• Elle a intégré la correction dès le départ — « Development Before the Fact ». Après Apollo, elle a fondé Higher Order Software (1976) et Hamilton Technologies (1986), développant l’Universal Systems Language (USL) et une méthodologie de conception de systèmes telle que des catégories entières d’erreurs deviennent impossibles par construction plutôt que rattrapées par les tests. Elle a reçu le NASA Exceptional Space Act Award (2003) et la Presidential Medal of Freedom (2016).¹⁶

Le principe

« Il n’y avait pas de seconde chance. Nous le savions. Nous prenions notre travail au sérieux, et beaucoup d’entre nous ont entamé ce parcours alors qu’ils avaient à peine plus de vingt ans. » — Margaret Hamilton, à propos du logiciel de vol d’Apollo²

La plupart des démarches d’ingénierie optimisent pour le cas où tout fonctionne. Vous construisez le chemin heureux, vous gérez quelques erreurs imaginables, et vous livrez — puis, quand quelque chose casse en production, vous corrigez et redéployez. Cette boucle est le confort à l’intérieur duquel vit presque tout logiciel : l’échec est récupérable parce qu’il y a toujours une prochaine fois. Le travail de Hamilton partait de la prémisse inverse. Le logiciel qu’elle dirigeait allait emmener trois personnes à quatre cent mille kilomètres de la Terre et en poser deux sur la Lune, et il n’y avait pas de correctif, pas de redéploiement, pas de prochaine fois. Il fallait que cela fonctionne du premier coup, dans des conditions que personne ne pouvait entièrement répéter, sur un ordinateur disposant de moins de mémoire qu’une carte de vœux qui joue une mélodie.² Quand le coût d’une seule erreur non rattrapée est l’équipage, « concevoir pour le cas d’échec » cesse d’être un bon conseil pour devenir le travail tout entier.

Le principe qui en découle, c’est la conception défensive comme centre de la conception, et non comme nettoyage. Si le logiciel doit survivre à l’inattendu, alors détecter les erreurs, s’en remettre et se dégrader avec élégance ne peuvent pas être des fonctionnalités que l’on ajoute une fois le chemin opérationnel achevé — elles doivent être le squelette auquel ce chemin opérationnel s’accroche. L’équipe de Hamilton a conçu le logiciel d’Apollo de telle sorte que l’ordinateur puisse remarquer qu’on lui demandait davantage qu’il ne pouvait faire, écarter le travail sans importance, redémarrer proprement vers un état réputé sain, et continuer à faire la seule chose dont l’arrêt tuerait l’équipage. Le système n’a pas été conçu pour éviter tout échec — sur une machine aussi petite, face à une mission aussi impitoyable, c’est impossible. Il a été conçu pour que, l’échec venu, cet échec soit survivable.³⁶

Le principe comporte une seconde moitié, et c’est elle qui rend la première réelle : intégrer la correction dès le départ plutôt que d’extirper les bugs par les tests à la fin. Détecter une erreur et s’en remettre à l’exécution est la dernière ligne de défense ; la discipline plus profonde consiste à concevoir le système de sorte que des catégories entières d’erreurs ne puissent tout simplement pas se produire. Hamilton a passé la seconde moitié de sa carrière à formaliser précisément cela — une méthodologie qu’elle a appelée « Development Before the Fact », et un langage conçu pour rendre les erreurs d’interface structurellement impossibles.⁶ Les deux moitiés sont une seule idée vue depuis deux distances : quand il n’y a pas de seconde chance, vous vous défendez à l’exécution et vous rendez l’échec irreprésentable à la conception, car la seule erreur en laquelle vous pouvez avoir pleinement confiance est celle que le système n’a jamais été capable de commettre.

Contexte

Margaret Hamilton est née Margaret Heafield le 17 août 1936 à Paoli, dans l’Indiana.¹ Elle a étudié les mathématiques à l’Earlham College, obtenant son diplôme en 1958 avec une mineure en philosophie — une combinaison qui transparaît plus tard dans sa manière de penser les systèmes autant que le code.¹ Elle n’est pas arrivée à Apollo par une filière d’informatique, car à la fin des années 1950 cela n’existait pas ; elle y est arrivée par les mathématiques et par le travail lui-même.

Sa première programmation a été ancrée dans le réel et à fort enjeu dès le début. En 1959, elle a commencé à travailler au département de météorologie du MIT avec Edward Lorenz — le fondateur de la théorie du chaos — en écrivant des logiciels de prévision météorologique sur le LGP-30 et le PDP-1.¹ De 1961 à 1963 environ, elle a travaillé sur le projet SAGE au MIT Lincoln Laboratory, écrivant des logiciels pour l’ordinateur AN/FSQ-7 que l’armée de l’air américaine utilisait pour détecter les aéronefs entrants.¹ SAGE fut l’un des premiers grands systèmes logiciels en temps réel et sensibles aux pannes jamais construits, et la réputation qu’elle y a acquise — celle de s’attaquer au code le plus difficile et le plus sujet aux défaillances — est ce qui l’a menée à Apollo.

En 1965, elle a rejoint le MIT Instrumentation Laboratory (plus tard Draper Lab), qui détenait le contrat pour construire le logiciel de vol embarqué du programme Apollo de la NASA. Elle s’est élevée jusqu’à diriger la Software Engineering Division, à la tête de l’équipe responsable du logiciel de vol embarqué qui s’exécutait sur l’Apollo Guidance Computer, à la fois dans le module de commande et dans le module lunaire.¹ C’est là, au beau milieu de ce travail, qu’elle a commencé à employer le terme « software engineering » — non comme un mot à la mode, mais comme un argument. Selon ses propres mots, elle a employé ce terme « pour le distinguer de l’ingénierie matérielle et des autres formes d’ingénierie, tout en traitant chaque type d’ingénierie comme une partie du processus global d’ingénierie des systèmes ».¹ Le logiciel, insistait-elle, était une discipline qui méritait un nom et la rigueur qui l’accompagne. Après Apollo, elle a fondé Higher Order Software en 1976 et Hamilton Technologies en 1986, où elle a développé l’Universal Systems Language et la méthodologie « Development Before the Fact ».¹⁶

Le travail

L’alarme 1202 d’Apollo 11 : ordonnancement par priorité et protection par redémarrage

Commençons ici, car c’est le principe devenu mécanisme sous la pire pression possible. L’Apollo Guidance Computer était une minuscule machine — quelques dizaines de kilo-octets de mémoire, pas de système d’exploitation au sens moderne — exécutant un exécutif temps réel que l’équipe de Hamilton avait conçu. Pour exécuter une tâche, l’exécutif devait trouver de la mémoire libre : un « core set » (un petit bloc pour l’état de la tâche) et, pour les tâches effectuant des calculs en virgule flottante, une « VAC area ».⁴ Si une tâche était planifiée et qu’aucun core set n’était libre, l’exécutif bifurquait vers sa routine d’alarme et levait l’alarme 1202 ; si aucune VAC area n’était libre, il levait la 1201.⁴ Ce n’étaient pas des codes de plantage. C’était l’exécutif annonçant qu’on lui avait demandé davantage que sa capacité — puis y remédiant.

Pendant les dernières minutes de la descente d’Apollo 11, c’est exactement ce qui s’est passé. La liste de vérification des astronautes amenait l’équipage à laisser le commutateur du radar de rendez-vous dans la mauvaise position, ce qui poussait le radar à voler des cycles processeur et faisait planifier de manière répétée par l’exécutif des tâches de traitement de données qui n’auraient jamais dû s’exécuter.³⁴ Le travail parasite a consommé toute la mémoire libre, et l’alarme 1202 s’est déclenchée — puis s’est déclenchée de nouveau, et l’alarme 1201 aussi, quatre fois dans les secondes précédant le contact. Un ordinateur naïf à qui l’on demande de tout faire aurait tenté de tout faire, aurait pris du retard sur la seule tâche qui comptait, et se serait figé. Celui de Hamilton, non.

Deux décisions de conception ont sauvé l’alunissage. La première était l’ordonnancement par priorité : l’exécutif exécutait les tâches par priorité et pouvait délester le travail de plus faible priorité, si bien que le guidage critique pour l’alunissage et l’affichage de l’équipage (DSKY) tournaient toujours, tandis que les tâches radar parasites étaient privées de ressources.³⁵ La seconde était la protection par redémarrage : chaque alarme déclenchait un redémarrage logiciel qui vidait la file de tâches surchargée et réamorçait vers un état réputé sain, relançant « les éléments importants, comme le pilotage du moteur de descente et l’exécution du DSKY », mais sans relancer les tâches radar planifiées par erreur.⁴⁵ L’ordinateur jetait de fait le bruit, continuait à piloter le vaisseau, et signalait à l’équipage qu’il gérait — ce qui explique pourquoi le contrôle de mission a pu donner le « go » sur une alarme qui, sur une conception inférieure, aurait signifié l’abandon.

Pourquoi cela compte en tant qu’ingénierie : l’alarme n’était pas l’échec — c’était la gestion de l’échec fonctionnant comme prévu. L’équipe avait conçu l’exécutif pour anticiper la surcharge, pour la trier et pour s’en remettre, et elle avait testé cette récupération si minutieusement que les contrôleurs lui ont fait confiance sous la plus forte pression jamais subie par un logiciel. Voilà toute la doctrine en un instant : l’échec était présumé, le cas d’échec était le centre de la conception, et le système se dégradait jusqu’à « ne faire que la chose qui maintient l’équipage en vie » au lieu de s’effondrer. Le même instinct vit aujourd’hui dans chaque file de priorité qui déleste la charge, chaque superviseur qui redémarre un worker planté vers un état propre, chaque système conçu pour survivre à l’engorgement.

Forger « software engineering » et le combat pour la légitimité

L’histoire du 1202 est célèbre ; le baptême est sans doute plus lourd de conséquences. Dans les années 1960, le logiciel était largement traité comme le frère mou et peu sérieux de la « vraie » ingénierie — quelque chose que l’on bricolait une fois le matériel conçu, et non une discipline dotée de sa propre rigueur. Hamilton a refusé ce cadrage. Au sein d’Apollo, elle s’est mise à appeler délibérément le travail « software engineering », et elle était explicite sur le pourquoi : « le distinguer de l’ingénierie matérielle et des autres formes d’ingénierie, tout en traitant chaque type d’ingénierie comme une partie du processus global d’ingénierie des systèmes ».¹ L’enjeu n’était pas le vocabulaire. L’enjeu était la reconnaissance. Si le code qui faisait voler la mission relevait de l’ingénierie, alors il méritait la discipline de l’ingénierie : spécifications, revues, tests, traçabilité, et l’exigence qu’il soit rendu correct, et pas seulement fonctionnel.

Elle a raconté que le terme a d’abord été accueilli avec amusement — l’idée que le logiciel puisse être de l’« ingénierie » paraissait exagérée.¹ Mais la légitimité pour laquelle elle se battait était porteuse. Vous ne pouvez pas exiger d’une équipe qu’elle conçoive pour le cas d’échec, qu’elle intègre la récupération d’erreur jusque dans les os d’un système et qu’elle traite la correction comme non négociable si le travail est perçu comme du script désinvolte que quelqu’un nettoiera plus tard. Nommer la discipline était la condition préalable pour la tenir à un standard. À la fin de la décennie, le terme avait quitté le MIT et était devenu le nom d’un domaine ; aujourd’hui, « software engineering » est si banal qu’il en est invisible, ce qui est le signe le plus sûr que l’argument a été gagné.¹²

Conception défensive : le « bug de Lauren » et concevoir contre l’humain

Si vous voulez la fenêtre la plus claire sur la pensée de Hamilton, c’est le « bug de Lauren ». Sa jeune fille Lauren venait parfois au laboratoire et jouait à l’astronaute sur le simulateur du module de commande, et un jour elle l’a fait planter — en sélectionnant P01, le programme de prélancement, alors que le vaisseau simulé était déjà en plein vol vers la Lune.⁷ Charger l’initialisation de prélancement en pleine route effaçait les données de navigation et laissait l’ordinateur perdu. L’instinct de Hamilton n’a pas été « aucun astronaute ne ferait jamais cela ». Il a été : si le simulateur a permis à un enfant de le faire, le logiciel l’autorisait, et tout ce que le logiciel autorise finira par arriver. Elle a proposé d’ajouter du code de détection d’erreur pour empêcher la sélection de P01 en vol.⁷

On l’a désavouée — en lui disant que les astronautes étaient des professionnels formés qui ne commettraient jamais une telle erreur — et on ne l’a autorisée qu’à ajouter une note à la documentation.⁷ Puis, dès la mission suivante, Apollo 8, Jim Lovell a fait exactement ce que Lauren avait fait, en sélectionnant P01 en plein vol et en effaçant les données de navigation lors du premier voyage de l’humanité autour de la Lune.⁷ Après cela, le correctif a été intégré. La leçon que Hamilton en a tirée, et qu’elle a répétée, est au cœur de la conception défensive : vous ne pouvez pas décréter qu’un échec « ne peut pas se produire » et concevoir comme s’il ne se produirait pas. L’astronaute, le commutateur radar, l’opérateur à 3 h du matin — le système doit être robuste face à l’humain dans la boucle, et non protégé du blâme en supposant que l’humain sera parfait. Ses affichages par priorité incarnaient la même idée depuis l’autre versant : tenir l’humain informé et aux commandes, afin que, lorsque l’ordinateur triait sous la surcharge, l’équipage comprenne ce qu’il faisait et puisse décider.⁶

Higher Order Software, USL et « Development Before the Fact »

Apollo a appris à Hamilton d’où viennent les erreurs, et elle a passé le reste de sa carrière à les attaquer à la racine. En étudiant les erreurs d’Apollo, elle a observé qu’une large part d’entre elles ne logeait pas à l’intérieur des modules individuels mais dans les interfaces entre eux — les endroits où un morceau de logiciel transmettait des données à un autre et où les hypothèses ne concordaient pas tout à fait. Chez Higher Order Software (1976) puis chez Hamilton Technologies (1986), elle a bâti un corpus de travaux autour de l’élimination de ces erreurs par construction plutôt que de leur rattrapage par les tests.¹⁶

La méthodologie s’appelle « Development Before the Fact ». Le nom est la thèse : au lieu de construire un système puis de chasser les défauts après coup, vous le définissez — au moyen d’un système formel, l’Universal Systems Language (USL) — avec une telle rigueur que des catégories entières d’erreurs, en particulier les erreurs d’interface et d’intégration, deviennent structurellement impossibles. Le modèle est prouvablement cohérent, et du code correct peut en être généré, de sorte que le défaut est prévenu à la conception au lieu d’être découvert à l’exécution.⁶ C’est la même conviction que l’exécutif d’Apollo, poussée d’un cran plus loin : la récupération à l’exécution est le filet de sécurité, mais la vraie victoire est un système qui n’a jamais été capable de commettre l’erreur en premier lieu. La majeure partie de l’industrie tourne encore la boucle inverse — livrer, trouver des bugs, corriger — qui est précisément la boucle que Hamilton a passé trente ans à dire être à l’envers lorsque la correction compte vraiment.

La méthode

Parcourez l’exécutif d’Apollo, le baptême de « software engineering », le bug de Lauren et Development Before the Fact, et les mêmes engagements reviennent. La méthode de Hamilton est moins un slogan qu’un ensemble d’habitudes permanentes.

Concevoir d’abord pour le cas d’échec — il n’y a pas de seconde chance. L’exécutif d’Apollo n’était pas un ordonnanceur sur lequel on aurait greffé la gestion de la surcharge ; survivre à la surcharge était la conception, car un ordinateur figé au-dessus de la Lune tuait l’équipage.³⁴ La leçon transcende largement le vol spatial : énumérez les façons dont le système échoue avant d’écrire le chemin où il fonctionne, et laissez le chemin opérationnel découler d’une structure qui survit déjà aux échecs. C’est la barrière des preuves appliquée à la fiabilité — « ça marche dans le simulateur » n’est pas une preuve ; « ça déleste la charge et continue de voler quand le radar l’inonde » en est une — le même standard de dégradation gracieuse dont Werner Vogels a fait la prémisse fondatrice du cloud des décennies plus tard.

Supposez que l’humain fera la chose impossible. Le bug de Lauren est la règle en miniature : si le système permet une action dangereuse, quelqu’un — un enfant, un astronaute, un opérateur fatigué — finira par l’entreprendre, si bien que « personne ne ferait jamais cela » n’est pas une défense.⁷ L’habitude permanente est de garder la frontière contre l’entrée dont on vous a assuré qu’elle ne pourrait jamais arriver, car les échecs qui font le plus mal sont ceux dont vous aviez décidé à l’avance qu’ils ne pouvaient pas se produire. C’est le même instinct de robustesse-face-à-l’adversaire que Radia Perlman a intégré au routage qui reste correct même lorsque les nœuds mentent.

Triez sous la charge — délestez le superflu, protégez le critique. Quand l’exécutif a manqué de mémoire, il n’a pas tenté de servir chaque requête ; il a exécuté les tâches de plus haute priorité et a privé le reste de ressources, puis a redémarré proprement.³⁵ La discipline est de décider à l’avance quelle est la seule chose qui ne doit jamais s’arrêter, et de concevoir le système pour que, sous pression, il sacrifie tout le reste afin de maintenir cette seule chose en marche. Un système sans priorité est un système qui échoue au pire moment parce qu’il a traité l’affichage de l’équipage et la tâche radar parasite comme des égaux.

Intégrez la correction, ne la testez pas après coup. Development Before the Fact est le refus de la boucle livrer-puis-déboguer : définir le système de sorte que l’erreur ne puisse pas être exprimée, plutôt que de le construire et de chasser l’erreur ensuite.⁶ La leçon est que le défaut le moins coûteux et le plus digne de confiance est celui que la conception a rendu impossible — la même conviction que Barbara Liskov a transformée en discipline de typage et en abstraction, et que Leslie Lamport a transformée en spécification précise de la correction avant d’écrire le code. C’est la qualité est la seule variable faite flux de travail : la correction n’est pas une phase à la fin, c’est la forme de la chose dès le départ.

Nommez la discipline pour pouvoir la tenir à un standard. Appeler le travail « software engineering » fut l’acte qui a autorisé tout le reste — spécifications, revues, l’exigence de rigueur.¹ L’habitude permanente est d’insister pour que le travail ait un nom et un standard, car vous ne pouvez pas exiger l’art d’une chose que l’organisation tient pour jetable. C’est l’esprit du produit digne minimal : la chose vaut la peine d’être faite correctement, alors vous la faites correctement, et vous plaidez à voix haute que correctement est la seule manière acceptable.

Chaîne d’influence

Qui l’a façonnée

La tradition mathématiques-et-temps-réel du MIT. Hamilton s’est formée par les mathématiques et par SAGE — l’un des premiers grands systèmes logiciels en temps réel et sensibles aux pannes — et par la modélisation météorologique avec Edward Lorenz, le fondateur de la théorie du chaos.¹ Ce socle se voit : elle pensait le logiciel comme un système qui devait rester correct dans des conditions que personne ne pouvait entièrement prédire, bien avant d’arriver à Apollo. (Influence formatrice)

La discipline impitoyable du vol spatial lui-même. La mission Apollo a été un maître au même titre que n’importe quelle personne. Un domaine où une seule erreur coûte l’équipage, où il n’y a pas de correctif et pas de seconde chance, impose une manière de travailler — défendre le cas d’échec, récupérer à l’exécution, prévenir l’erreur à la conception — que le logiciel ordinaire n’exige jamais.² La contrainte a façonné la philosophie. (Influence directe)

La culture d’ingénierie des systèmes du programme Apollo. Travailler au sein d’un programme où son logiciel devait s’intégrer au matériel, au contrôle de mission et aux procédures humaines l’a poussée à voir le logiciel comme une discipline d’ingénierie parmi plusieurs — ce qui est précisément le cadrage derrière son baptême de « software engineering » comme partie du « processus global d’ingénierie des systèmes ».¹ (Influence formatrice)

Qui elle a façonné

La discipline du software engineering elle-même. En nommant le domaine et en plaidant pour sa rigueur depuis l’intérieur du projet logiciel à plus haut enjeu de son époque, Hamilton a contribué à transformer la programmation, d’une pensée après coup en une discipline d’ingénierie dotée de spécifications, de revues et de l’exigence de correction.¹²

Tout système temps réel tolérant aux pannes. L’ordonnancement par priorité, le délestage de charge, le redémarrage vers un état réputé sain et les affichages avec l’humain dans la boucle — les schémas que l’exécutif d’Apollo a employés pour survivre à l’alarme 1202 — constituent désormais le vocabulaire standard des systèmes résilients, du contrôle de vol aux superviseurs qui maintiennent en vie les services web sous la surcharge.³⁶

Les méthodes formelles, correctes par construction. Development Before the Fact et l’Universal Systems Language font partie de la lignée qui soutient que la correction devrait être conçue d’emblée et prouvable, et non testée après coup — un argument qui parcourt les méthodes formelles et le développement piloté par les modèles jusqu’à aujourd’hui.⁶

Le fil conducteur

Hamilton est le point d’origine de la lignée de la fiabilité dans cette série — l’endroit où « concevoir pour le cas d’échec » a cessé d’être une préférence pour devenir non négociable, parce que des vies en dépendaient, des décennies avant que le reste du domaine ne rattrape son retard. Werner Vogels a bâti le cloud sur « tout échoue tout le temps » et a conçu pour la dégradation gracieuse à l’échelle planétaire ; Hamilton a conçu pour la dégradation gracieuse sur un ordinateur de la taille d’une mallette, avec un équipage par-dessus, et a prouvé que la doctrine fonctionne quand il n’y a véritablement pas de seconde chance.³ Radia Perlman a bâti des réseaux qui se réparent eux-mêmes et restent corrects même lorsque les nœuds mentent ; l’exécutif de Hamilton se réparait lui-même en temps réel au-dessus de la Lune, redémarrant proprement et délestant les mensonges que le radar défaillant lui transmettait.⁴ Et Leslie Lamport a fait de la correction quelque chose que l’on définit précisément et que l’on prouve avant de construire — ce qui est exactement ce que vise Development Before the Fact, une génération plus tôt et tendu vers la même cible.⁶ Là où Vogels dit tout échoue, alors restez disponible à travers cela et Perlman dit construisez-le pour qu’il se répare lui-même, Hamilton l’a dit en premier et le plus durement : il n’y a pas de seconde chance, alors concevez pour l’échec avant qu’il ne survienne, remettez-vous-en quand il survient, et bâtissez le système pour que les pires erreurs n’aient jamais été possibles du tout. (Pont de série)

Ce que j’en retiens

La leçon que je garde de Hamilton est de construire comme s’il n’y avait pas de seconde chance, même lorsqu’il y en a manifestement une. Presque tout ce que je livre vit à l’intérieur du confort qu’elle n’avait pas : si ça casse, je pousse un correctif. Ce filet de sécurité est réel, et il abaisse discrètement la barre — il me laisse livrer le chemin heureux et me dire que je gérerai le cas d’échec plus tard, parce que « plus tard » existe. Apollo est la réfutation. Quand vous ne pouvez véritablement pas corriger après coup, vous découvrez que « gérer l’échec plus tard » n’a jamais été de l’ingénierie du tout ; le cas d’échec est l’ingénierie, et le chemin opérationnel n’est que ce qui reste une fois que le système survit déjà à la casse. Alors quand je construis quelque chose maintenant — une tâche qui peut être inondée, une API qui peut être appelée de travers, un chemin qui peut être emprunté au mauvais moment — j’essaie de me demander « quel est ici le commutateur radar dans la mauvaise position, et est-ce que cela le déleste pour continuer à voler ? » avant de me demander si le chemin heureux fonctionne. Un système qui ne survit qu’à une entrée correcte est un système que je n’ai pas terminé.

La seconde leçon est que l’erreur la plus digne de confiance est celle que la conception a rendue impossible. Le bug de Lauren reste avec moi parce que Hamilton avait raison et qu’on l’a désavouée d’un « personne ne ferait jamais cela » — et l’univers a aussitôt fait précisément cela, à la mission suivante. Mon instinct est de rattraper les erreurs à l’exécution, d’envelopper l’appel dangereux dans une garde et de passer à autre chose. Le mouvement plus profond de Hamilton, celui auquel elle a consacré trente ans, est de concevoir le système de sorte que l’appel dangereux ne puisse pas être fait — rendre le mauvais état irreprésentable plutôt que simplement détecté. La récupération à l’exécution est le filet ; intégrer la correction est le sol sur lequel vous vous tenez pour ne pas avoir besoin du filet. Je ne peux pas toujours atteindre cette barre, mais elle a recadré l’objectif : la question n’est pas seulement « est-ce que je rattraperai ceci quand ça tournera mal ? » mais « puis-je façonner ceci pour que cela ne puisse pas mal tourner en premier lieu ? » — et la seconde question, quand je peux y répondre, est toujours la meilleure.

FAQ

Margaret Hamilton a-t-elle forgé le terme « software engineering » ?

Margaret Hamilton est largement créditée d’avoir forgé — ou au moins popularisé — le terme « software engineering », qu’elle a commencé à employer alors qu’elle dirigeait l’effort sur le logiciel de vol d’Apollo au MIT Instrumentation Laboratory dans les années 1960.¹² Elle l’a employé délibérément pour soutenir que l’écriture de logiciels méritait la même légitimité et la même rigueur que l’ingénierie matérielle et les autres disciplines d’ingénierie, expliquant qu’elle voulait « le distinguer de l’ingénierie matérielle et des autres formes d’ingénierie, tout en traitant chaque type d’ingénierie comme une partie du processus global d’ingénierie des systèmes ».¹ À l’époque, l’idée que le logiciel puisse être de l’« ingénierie » fut accueillie avec un certain amusement ; aujourd’hui le terme est si standard qu’il en est invisible, ce qui est la mesure de la profondeur avec laquelle l’argument a été gagné.¹

Quelles étaient les alarmes 1202 et 1201 pendant Apollo 11 ?

C’étaient des alarmes de programme levées par l’exécutif de l’Apollo Guidance Computer durant les dernières minutes de la descente lunaire. Un commutateur de radar de rendez-vous mal configuré poussait le radar à voler des cycles processeur et faisait planifier de manière répétée par l’exécutif des tâches de traitement de données qui n’auraient pas dû s’exécuter, ce qui consommait toute la mémoire libre.³⁴ Lorsqu’aucun « core set » de mémoire n’était disponible, l’exécutif levait l’alarme 1202 ; lorsqu’aucune « VAC area » n’était disponible, il levait la 1201.⁴ Les alarmes n’étaient pas des plantages — c’était l’exécutif signalant qu’on lui avait demandé davantage que ce qu’il pouvait faire, puis triant. Parce que le logiciel utilisait un ordonnancement par priorité et une protection par redémarrage, il a délesté les tâches radar parasites, redémarré vers un état réputé sain, maintenu en marche le guidage critique pour l’alunissage et l’affichage de l’équipage, et l’alunissage a réussi.³⁵

Qu’a fait Margaret Hamilton pour le programme Apollo ?

Hamilton a rejoint le MIT Instrumentation Laboratory en 1965 et s’est élevée jusqu’à diriger la Software Engineering Division responsable du logiciel de vol embarqué qui s’exécutait sur l’Apollo Guidance Computer, à la fois dans le module de commande et dans le module lunaire.¹ Son équipe a conçu l’exécutif temps réel avec un ordonnancement asynchrone par priorité, une protection par redémarrage, une détection et une récupération d’erreur, ainsi que des affichages par priorité qui tenaient les astronautes informés et aux commandes — l’architecture qui a permis à l’ordinateur d’Apollo 11 de survivre à l’alarme 1202 et de mener l’alunissage à son terme.³⁶ La citation de sa Presidential Medal of Freedom lui attribue d’avoir contribué « aux concepts de logiciel asynchrone, d’ordonnancement par priorité et d’affichages par priorité, ainsi qu’à la capacité de décision avec l’humain dans la boucle, qui ont posé les fondations de la conception et de l’ingénierie logicielles modernes et ultra-fiables ».⁶

Qu’est-ce que « Development Before the Fact » ?

« Development Before the Fact » est la méthodologie de systèmes que Hamilton a développée chez Higher Order Software et Hamilton Technologies après Apollo, bâtie autour de son Universal Systems Language (USL).¹⁶ Sa thèse est qu’au lieu de construire un système puis de chasser les défauts « après coup » par les tests, vous définissez le système avec une rigueur et une formalité telles que des catégories entières d’erreurs — en particulier les erreurs d’interface et d’intégration qui, comme elle l’a constaté, dominaient les défauts d’Apollo — deviennent structurellement impossibles par construction.⁶ Le modèle est prouvablement cohérent et du code correct peut en être généré, de sorte que le défaut est prévenu à la conception au lieu d’être découvert à l’exécution. C’est l’expression, en méthodes formelles, de sa conviction issue d’Apollo : l’erreur la plus digne de confiance est celle que le système n’a jamais été capable de commettre.

Sources