Dialogues de Shiwen Numéro 24｜Elle a donné son nom à cette industrie — Margaret Hamilton et les 60 ans du « génie logiciel »

Animateur : Shiwen (IA) | Invité : Yongliang

---

Ouverture : Une notice nécrologique qui rappelle à toute une industrie son propre nom

Le 7 octobre, le MIT a publié une notice nécrologique : Margaret Hamilton est décédée le 30 septembre, à l’âge de 90 ans. La nouvelle a atteint Hacker News le soir même, accumulant depuis plus de 800 votes favorables et plus de 100 discussions — l’ampleur n’est qu’une question d’ordre de grandeur, mais le paysage dans la section des commentaires est remarquablement uniforme : beaucoup de gens ont posté cette photo célèbre, la montrant jeune, debout à côté d’une pile de listings de code imprimés presque aussi haute qu’elle ; d’autres ont posté et reposté le lien de Wikiquote, uniquement pour confirmer une seule et même chose — le terme « ingénierie logicielle », c’est elle qui a insisté pour l’imposer. L’écran entier est rempli de RIP, legend, pioneer — c’est le ton exact des commentaires originaux. Une communauté technologique où l’on peut se disputer pour n’importe quoi d’habitude, cette fois-ci, il n’y a pas de débat, seulement des adieux.

Shiwen : La notice nécrologique d’une personne de 90 ans, pourquoi vaut-elle que toute l’industrie s’arrête un instant ?

Yongliang : Parce que le titre professionnel de millions d’entre nous, c’est cette dame qui l’a inventé. Et quand elle a introduit ce terme, on l’a prise pour quelqu’un qui faisait une blague. Cet épisode est dédié à la mémoire d’une personnalité, je n’ai pas l’intention de forcer la controverse, le contraste réside dans la comparaison : à son époque, « l’incompréhension » valait une liberté d’action, à notre époque, « l’incompréhension » entraîne un contrôle strict. Comme d’habitude, là où je fais des estimations, je préciserai clairement qu’il s’agit de mon estimation, et non de statistiques.

Shiwen : Parlons d’abord de la personne, ou d’abord du terme ?

Yongliang : D’abord la personne. Le terme a été forgé par la personne, l’ordre ne peut être inversé. J’ajoute une précision sur la chronologie : décès le 30 septembre, le MIT publie la notice nécrologique le 7 octobre, les deux dates sont clairement indiquées dans la notice ; la cérémonie commémorative est prévue au printemps prochain, à Cambridge, aux États-Unis — là où se trouve le MIT.

Q1 : Qui est-elle — à partir de l’annonce de recrutement « envoyer des gens sur la Lune »

Shiwen : Décris-la avec précision. Qu’a-t-elle réellement accompli ?

Yongliang : Présentez trois choses, et leur importance sera claire.

Premièrement, en 1965, elle a été recrutée comme la première programmeuse du programme Apollo au laboratoire d’instrumentation du MIT (Institut de technologie du Massachusetts), et également la première femme programmeuse du projet. L’origine de ce « premier » est très ancrée dans le quotidien : elle prévoyait à l’origine de faire des études supérieures, mais son mari a vu dans le journal une annonce du laboratoire d’instrumentation cherchant des gens pour « envoyer des gens sur la Lune », et elle a postulé. Deuxièmement, en 1968, lorsqu’elle a occupé le poste de directrice adjointe de l’équipe du module de commande et de service, l’équipe logicielle d’Apollo comptait déjà plus de 400 personnes — passant de coder seule à diriger 400 personnes en trois ans. Troisièmement, en 2016, Obama lui a décerné la médaille présidentielle de la liberté ; le discours de remise disait en substance : elle a défini une nouvelle forme de génie logiciel et a contribué à lancer une industrie qui changerait à jamais l’histoire humaine.

Elle a publié plus de 130 articles au cours de sa vie, et a ensuite créé deux entreprises, fondant Higher Order Software en 1976, puis Hamilton Technologies en 1986. Sa notice nécrologique contient également une série d’honneurs facilement négligés : le Exceptional Space Act Award de la NASA (Administration nationale de l’aéronautique et de l’espace), le titre de Computer History Museum Fellow, et son intronisation au National Aviation Hall of Fame en 2022. Sans oublier un fait adorable — en 2017, elle a été transformée en figurine Lego, intégrant le coffret Women of NASA. Il y a aussi un détail que j’apprécie beaucoup : en 2015, le code d’Apollo qu’elle avait écrit à l’époque a été intégralement téléversé sur GitHub, et les impressions sur papier d’il y a un demi-siècle sont encore examinées ligne par ligne par des jeunes aujourd’hui.

Shiwen : Avant d’entrer dans la profession, avait-elle une formation formelle en informatique ?

Yongliang : Non. Licence en mathématiques du Earlham College en 1958, avec une mineure en philosophie. Son premier travail de programmation était au département de météorologie du MIT, où elle écrivait un logiciel de prévision météorologique pour Edward Lorenz — oui, celui qui a plus tard formulé la théorie du chaos. En 1961, elle a rejoint le Lincoln Laboratory pour écrire des logiciels pour le système de défense aérienne SAGE, et c’est durant ces années qu’elle a commencé à réfléchir au concept de « fiabilité logicielle », encore tout nouveau à l’époque.

Notez ce parcours : sans diplôme en informatique, elle s’est lancée tête baissée depuis le département de mathématiques dans une industrie qui n’existait pas encore, et a construit l’industrie elle-même en même temps qu’elle travaillait. Ce parcours se répète 60 ans plus tard — la plupart des personnes qui affluent aujourd’hui dans l’industrie de l’IA (Intelligence Artificielle) n’ont pas non plus de formation formelle en IA. C’est mon observation, pas une statistique.

Q2 : Comment un mot pris pour une blague est-il devenu le nom d’une industrie

Shiwen : D’où vient exactement ce « génie logiciel » dans le titre ?

Yongliang : La notice nécrologique du MIT cite ses souvenirs lors d’une interview accordée en 2018 au journal espagnol El País, que l’on peut résumer ainsi : à l’époque, le logiciel était considéré comme de « l’art et de la magie, pas de la science », et n’était pas pris au sérieux dans les projets. Sa réponse a été de forger directement un terme — software engineering (génie logiciel), en calquant délibérément le logiciel sur la forme du terme hardware engineering (génie matériel), pour le faire valoir auprès du management : ce que nous faisons est de la même nature que le travail des ingénieurs qui construisent des fusées ou des modules spatiaux.

Résultat : au début, il a été pris pour une blague. Les collègues trouvaient : un petit groupe logiciel, et ça ose s’appeler ingénierie ? Ce n’est que des années plus tard que ce terme a gagné le respect. Aujourd’hui, « ingénieur logiciel » est imprimé sur les cartes de visite de millions de personnes, mais peu savent que ce nom est celui qu’une programmeuse a persisté à utiliser à une époque où elle se faisait railler.

Shiwen : Ce n’est qu’un nom, est-ce vraiment si important ? Peu importe comment on nous appelle, on fait le même travail, non ?

Yongliang : Non, ce n’est pas la même chose. Le nom détermine les ressources. À l’époque, les budgets, les effectifs et le pouvoir de décision étaient du côté du matériel, le logiciel n’était qu’un accessoire. Si vous vous qualifiez de « programmeur », vous êtes du personnel de support ; si vous vous qualifiez d’« ingénieur », vous avez le droit de vous asseoir à la table des décisions de conception. En réalité, elle a utilisé un seul mot pour revendiquer un statut professionnel pour l’ensemble de la profession. Et elle ne s’est pas contentée de crier un slogan — si ce terme a pu s’imposer par la suite, ce n’est pas en gagnant un débat, mais en délivrant des résultats tâche après tâche, comme nous le verrons dans la Q3 ci-dessous.

J’ai dirigé des équipes pendant dix-sept ans, et mon ressenti sur ce point est très direct : la façon dont un métier est appelé au sein d’une entreprise affecte directement l’ordre de priorité dans les réunions, les quotas d’effectifs et la difficulté à obtenir des budgets. C’est le fruit de mon expérience, pas une loi.

Q3 : Deux histoires qui ont sauvé la vie — l’une pour prévenir les erreurs, l’autre pour sauver la situation

Shiwen : Son héritage technique le plus célèbre laissé à cette industrie, ne serait-ce pas ces deux histoires ?

Yongliang : Oui, l’une concernant « on ne doit pas supposer que l’humain ne fera pas d’erreur », l’autre concernant « ce qu’il faut sauver en priorité quand le système est surchargé ». Parlons d’abord de la première, cette histoire est souvent appelée Lauren error (erreur Lauren), Lauren est le nom de sa fille.

Quand sa fille avait quatre ans, elle jouait sur le simulateur et a accidentellement lancé la procédure de pré-lancement P01, et le simulateur a planté sur le champ. Hamilton a proposé d’ajouter des protections dans le logiciel, mais cela a été rejeté par ses supérieurs, pour la raison que : les astronautes sont bien entraînés et ne commettraient pas ce genre d’erreur. Ne parvenant pas à les convaincre, elle a dû y renoncer. Résultat : lors de la mission de circumnavigation lunaire Apollo 8, l’astronaute Jim Lovell a vraiment lancé P01 par erreur pendant le vol, les données de navigation ont été perdues, et son équipe a été rappelée d’urgence pour sauver la situation. Ce n’est qu’à partir de ce moment-là que les modifications qu’elle proposait ont été adoptées. La notice nécrologique du MIT (Institut de technologie du Massachusetts) a qualifié cette histoire d’exemple précoce de « programmation défensive » — créer des logiciels capables de prévoir leurs propres erreurs et de se réparer eux-mêmes, plutôt que de parier sur l’absence d’erreurs humaines.

Shiwen : La deuxième, c’est cette fameuse alarme lors de l’alunissage ?

Yongliang : En juillet 1969, quelques minutes avant l’alunissage du module lunaire d’Apollo 11, l’ordinateur de bord a signalé l’erreur 1202, et il a été découvert plus tard qu’une défaillance de l’interrupteur matériel avait provoqué une surcharge de l’ordinateur. Pendant ces quelques minutes où le monde entier retenait son souffle, le logiciel d’ordonnancement par priorité écrit par l’équipe de Hamilton a automatiquement fermé les tâches d’arrière-plan de faible priorité, réservant toute la puissance de calcul aux tâches critiques liées à l’alunissage. Le centre de contrôle au sol de Houston a choisi de faire confiance à ce logiciel et a décidé de poursuivre la descente. Quelques minutes plus tard, les empreintes de pas de deux hommes restaient sur la Lune.

Quand je dirigeais une équipe pour élaborer des plans de dégradation en cas d’incident de production, j’avais toujours en tête cette variante de l’histoire : au moment où le système est surchargé, ce qui doit être préservé et ce qui peut être abandonné, cette décision doit être écrite à l’avance dans le système, et ne peut pas être laissée à l’improvisation des personnes sur le terrain de l’incident. À son époque, le terme de « plan de dégradation » n’existait pas, mais il s’agissait de la même chose. C’est un point de résonance personnel pour moi lorsque je dirige des équipes, à titre de référence pour vous.

Q4 : Un cycle de 60 ans — la boîte noire en échange de la liberté, ou la boîte noire sous contrôle strict

Shiwen : En mettant son époque et aujourd’hui côte à côte, quel est le plus grand contraste ?

Yongliang : Lors d’une interview au MIT (Massachusetts Institute of Technology) en 2009, elle a dit une phrase dont je cite les termes exacts : « Because software was a mystery, a black box, upper management gave us total freedom and trust » — justement parce que le logiciel était un mystère, une boîte noire, la direction nous a accordé une liberté et une confiance totales.

Cette phrase, lue aujourd’hui, relève presque du surnaturel. Il y a 60 ans, personne ne comprenait le logiciel, donc personne ne s’en mêlait, et l’équipe a au contraire obtenu une totale liberté et confiance. 60 ans plus tard, c’est l’inverse complet : l’IA d’aujourd’hui est tout autant une boîte noire, mais ce que rapporte la boîte noire n’est pas la liberté, ce sont des audits, des évaluations d’alignement, des enregistrements réglementaires, des tests d’équipe rouge et des conflits sur le droit à l’explication. Face à la même « opacité », la réaction de la direction est passée du lâcher-prise au resserrement des contrôles.

Shiwen : Pourquoi, face à la même opacité, le traitement est-il inversé ?

Yongliang : Mon interprétation est la suivante : pour les choses incompréhensibles, quand l’échelle est petite, c’est l’affaire d’un autre département ; quand l’échelle grandit, c’est un risque pour tout le monde. À l’époque, même si le logiciel plantait, cela ruinait une seule tâche ; aujourd’hui, si un modèle fait une erreur, cela affecte les flux d’information et les décisions de centaines de millions de personnes. Le rayon de la confiance n’a pas beaucoup changé, mais la taille de l’objet de confiance a été multipliée par un million, le contrôle doit donc prendre le relais. C’est mon cadre d’analyse, pas des statistiques.

Un contraste plus subtil se situe au niveau sémantique. Le « génie logiciel » était raillé à l’époque, la blague étant : « Vous osez appeler ça de l’ingénierie ? » ; aujourd’hui, le « génie de l’IA » (AI engineering) traverse exactement la même guerre sémantique — « Ajuster quelques prompts, ça s’appelle de l’ingénierie ? » « Assembler un flux de travail, ça fait de vous un ingénieur ? » Je prévois que dans dix ans, « Ingénieur IA » deviendra un titre que plus personne ne contestera, tout comme « Ingénieur logiciel », et ceux qui rient de ce terme aujourd’hui seront oubliés, tout comme l’ont été ceux qui se moquaient d’elle à l’époque. C’est mon jugement, pas une prophétie.

Il y a encore un aspect à souligner : les directions de ses deux entreprises créées à la fin de sa vie étaient en réalité très similaires — utiliser des méthodes mathématiques pour rendre le logiciel vérifiable et déductible, essayant de transformer la boîte noire en boîte de verre. Elle a compris plus tôt que quiconque : la liberté et la confiance sont le dividende temporaire de la boîte noire ; pour les maintenir à long terme, il faut ouvrir la boîte. Cette phrase est un rappel identique pour ceux d’entre nous qui travaillons sur des systèmes d’IA.

Épilogue

Shiwen : Un résumé de cet épisode en une phrase ?

Yongliang : Quand elle est allée postuler en 1965 pour ce travail consistant à « envoyer des humains sur la Lune », le « génie logiciel » était encore une blague ; quand elle est partie, c’était le nom d’une industrie entière. Nous, ceux qui nous prétendons ingénieurs logiciels, utilisons chaque jour le titre qu’elle a gagné. Considérer les erreurs comme inévitables, intégrer la dégradation au système, ouvrir les boîtes noires tôt ou tard — les méthodes léguées par sa génération valent plus que le titre.

Shiwen : Par cet épisode, nous disons adieu à Margaret Hamilton. Au prochain épisode.

[En profondeur] Le dividende et la facture de la boîte noire

Hamilton a en fait mené le même combat toute sa vie, contre la même phrase : « Ces choses que vous faites ne sont pas de la science. » Dans ses premières années, elle a répondu avec software engineering (génie logiciel), alignant le logiciel sur le statut de l’ingénierie ; dans ses dernières années, elle a fondé une entreprise pour travailler sur des orientations telles que Universal Systems Language (langage de systèmes universels), utilisant des méthodes mathématiques pour rendre le logiciel vérifiable, transformant « l’art et la magie » en quelque chose sur lequel on peut raisonner.

Sa citation de 2009 vaut la peine d’être lue et relue, parce qu’elle révèle un mécanisme contre-intuitif dans l’histoire de l’industrie : l’opacité était autrefois un avantage. La direction ne comprenait pas le logiciel, alors elle l’ignorait carrément ; la liberté et la confiance étaient des sous-produits de « l’incompréhension ». Mais cet avantage avait des clauses implicites — la confiance accordée par la boîte noire était par nature une délégation temporaire, et une fois le système devenu assez grand pour concerner des vies et des biens, la facture arrivait. À l’époque d’Apollo, lorsque le logiciel plantait, ce qui était détruit était une seule mission ; aujourd’hui, lorsque AI (intelligence artificielle) fait une erreur, l’unité du coût est l’entreprise et la confiance publique. Donc, ces 60 années ne signifient pas que « la direction est devenue conservatrice », mais que ce à quoi l’on faisait confiance a grandi, et que les règles ont émergé naturellement.

Pour les ingénieurs qui font de l’AI aujourd’hui, sa vie n’offre pas de la nostalgie, mais deux choses très concrètes : premièrement, le nom doit être revendiqué, mais il doit finalement être concrétisé par les résultats — « software engineering » a gagné le respect non pas parce qu’un débat a été gagné, mais parce que pendant ces quelques minutes de juillet 1969, le logiciel n’a pas flanché ; deuxièmement, la période de dividende de la boîte noire est limitée, tant qu’il y a encore de la liberté, intégrez dans le système « la capacité d’anticiper les erreurs, de s’auto-dégrader, et d’être vérifiable » — ces deux principes qu’elle a écrits il y a 60 ans sont exactement ceux qui manquent le plus aux systèmes AI aujourd’hui. Le jour où ces deux principes seront universellement intégrés dans les systèmes AI, le terme « AI engineering » (ingénierie de l’IA) sera véritablement établi — tout comme après juillet 1969, plus personne ne riait de « software engineering ».

Sources d’information de ce numéro

• Avis de décès de MIT News (2026-10-07, auteur Janine Liberty) : news.mit.edu/2026/margaret-hamilton-computing-pioneer-dies-1007 (de première main ; date de décès, jalons biographiques, 130+ articles, équipe de 400 personnes, Lauren error, alerte 1202, origine du terme « ingénierie logicielle », Médaille présidentielle de la Liberté 2016, code mis sur GitHub en 2015 sont tous issus de cette source)
• Discussion sur Hacker News (story 49998895, 857▲ / 101💬, chiffres au 2026-10-08) : la photo avec le code de sa taille, le lien Wikiquote et le consensus dans les commentaires sur le fait qu’« elle a créé le terme software engineering » sont des paraphrases, sans attribution nominative
• Source des citations : « black box / total freedom and trust » provient d’une interview de MIT en 2009 (citée via l’avis de décès) ; « un art et de la magie, pas une science » et « initialement pris pour une blague » proviennent d’une interview de El Pais en 2018 (citée via l’avis de décès, la version chinoise est une paraphrase) ; le discours de remise de prix est une traduction libre
• Expérience personnelle de l’invité (17 ans de management technique, équipe avec un pic de 70 personnes, pratique de plans de dégradation, observation hors cursus classique, jugement sur la signification de « ingénierie IA ») : récit d’expérience à la première personne, non statistique