L’incident Therac-25 (2021)

• La machine médicale de radiothérapie Therac-25 a été impliquée dans des accidents mortels
• Des défauts logiciels ont provoqué chez plusieurs patients une grave surexposition aux radiations
• Le remplacement des anciens systèmes de sécurité par un système de contrôle numérique a entraîné ces problèmes
• L’absence de diagnostic des défauts et de communication a retardé l’identification de la cause des accidents
• Parmi les principales leçons de sécurité, l’incident souligne l’importance de la fiabilité des algorithmes et de tests rigoureux

---

Aperçu de l’incident Therac-25

• Therac-25 était un appareil médical de radiothérapie largement utilisé
• Cet équipement servait à administrer de fortes doses de rayonnement à des patients atteints de cancer
• Les anciens dispositifs de sécurité mécaniques de type interlock ont été remplacés par un système de contrôle basé sur le logiciel
• Cependant, ce changement a accru le risque de bogues logiciels

Déroulement des accidents

• Un défaut du programme se manifestait lors de certaines séquences d’opérations ou en cas de saisie rapide et successive
• En conséquence, les dispositifs de sécurité ne fonctionnaient pas correctement, et les patients recevaient un rayonnement d’une intensité supérieure à celle prévue
• Entre 1985 et 1987, plusieurs patients ont subi de graves surdoses d’irradiation, dont certains sont décédés
• Au départ, la tendance était à négliger la cause logicielle comme origine des défaillances de la machine de radiothérapie

Causes du problème

• Lors du processus de validation de la fiabilité, seuls des tests simplifiés ne reflétant pas l’environnement clinique réel ont été effectués
• Une gestion insuffisante des erreurs et des interlocks a provoqué des erreurs d’algorithme dans des situations extrêmes
• L’absence d’un système clair de signalement des problèmes et de communication entre le fabricant et les hôpitaux a retardé l’identification et la résolution du défaut
• Cet incident est considéré comme un échec de la conception logicielle centrée sur la sécurité

Principales leçons

• Lors de la conception d’algorithmes directement liés à la sécurité, une validation rigoureuse et une programmation défensive sont nécessaires
• Il est indispensable de diversifier les cas de test et de mener des simulations fondées sur des scénarios d’usage réel
• L’importance d’une mise en œuvre structurée des boucles de traitement des erreurs et des systèmes de journalisation est soulignée
• Dans les domaines exigeant une très haute fiabilité, il faut reconnaître les risques liés à une dépendance au seul contrôle logiciel
• Cet incident reste un cas emblématique rappelant à l’ingénierie logicielle et à l’industrie des dispositifs médicaux du monde entier l’importance de la fiabilité des algorithmes, de la gestion de la sécurité et des systèmes de communication

[GN⁺]

Réactions sur Hacker News

• Cela souligne que la qualité logicielle ne naît pas simplement de la présence de bons développeurs, mais qu’elle est le produit final de processus à l’échelle de toute l’organisation. Ces processus touchent non seulement aux pratiques de développement, mais aussi aux tests, à la direction, et même aux équipes commerciales et de service. La leçon à tirer de l’affaire Therac-25, c’est qu’un système de types, des tests unitaires ou du code défensif ne suffisent pas à tout résoudre. Le vrai échec, à mon avis, est qu’il a fallu beaucoup trop de temps pour signaler l’accident, l’enquêter et le corriger. Le sujet a aussi été traité récemment dans le podcast Cautionary Tales, et ce qui m’a frappé, c’est que les utilisateurs du Therac-25 rencontraient continuellement des erreurs incompréhensibles sans que cela ne remonte correctement à ceux qui pouvaient les corriger. (lien vers le podcast)

  • Je ne suis pas d’accord avec cet avis. J’ai longtemps travaillé sur la conception de pièces d’avion, et le principe fondamental est qu’une seule défaillance ne doit jamais pouvoir provoquer un accident. Le moyen d’y parvenir n’est ni « écrire du bon logiciel » ni « tester suffisamment », mais d’avoir des systèmes indépendants capables d’empêcher le pire même si le logiciel se comporte de la pire manière possible. Dans le cas du Therac-25, il aurait fallu un détecteur de rayonnement coupant automatiquement au-delà d’un seuil critique, ainsi qu’une conception physique rendant impossible toute émission excessive de radiation.

  • J’allais justement recommander ce podcast moi aussi. Il vaut particulièrement le détour si vous vous intéressez aux bugs logiciels. Fait intéressant, les premiers appareils exploités manuellement présentaient le même défaut, mais un fusible grillait lors d’une fuite électrique, ce qui empêchait le défaut de se matérialiser. C’est un excellent exemple du Swiss Cheese Model (référence sur le Swiss Cheese Model)

  • Je voudrais souligner que la plupart des logiciels ne sont pas directement liés à la vie ou à la mort. Dans la majorité des cas, un échec signifie juste qu’une page se charge lentement, qu’un rapport est rempli de NaN, ou qu’il faut lancer un batch manuellement. Il est rare que des gens meurent réellement à cause d’un problème de qualité logicielle, et les développeurs qui créent ce type de logiciel savent probablement très bien quelle est leur responsabilité.

  • L’entreprise où j’ai travaillé fabriquait du matériel photo et scientifique de très haute qualité. C’était très cher, mais les clients considéraient que cela valait le prix. J’y ai constaté en pratique que la qualité n’est pas simplement le produit d’un processus, mais qu’elle vient au fond d’une « culture ».

  • Beaucoup de développeurs pensent que, s’ils ne travaillent pas sur des systèmes à haute fiabilité, les questions de qualité ne les concernent pas, et c’est complètement faux. Même une panne logicielle apparemment mineure peut avoir un impact énorme sur la vie de quelqu’un ou sur une entreprise. Par exemple, elle peut bloquer un flux critique, corrompre des données de vie ou des dossiers médicaux, ou empêcher le paiement d’un produit indispensable.

• Un commentaire sous l’article mentionnait que, dans les années 80 et 90, le secteur médical considérait largement les ordinateurs comme dangereux. Même au début et au milieu des années 2000, les dossiers médicaux étaient encore écrits à la main sur papier. J’ai brièvement participé à un projet pilote de dossier patient électronique en réanimation, où je m’occupais des serveurs, et tout le personnel soignant détestait ce système. À l’époque, il n’y avait même pas encore de tablettes, donc consulter ou modifier les notes sur ordinateur était pénible. Toutes les prescriptions étaient habituellement écrites directement sur la feuille au pied du lit, avec vérification et correction immédiates. Comme la perte d’information ou les retards d’accès pouvaient être fatals, les médecins ne détestaient pas les ordinateurs sans raison : ils avaient réellement l’impression que c’était plus dangereux qu’un stylo et du papier. J’imagine que la situation s’est améliorée depuis, mais c’est un point à garder en tête.

  • Aujourd’hui, des entreprises comme Chipsoft ont quasiment le monopole de l’IT hospitalière. Elles facturent des sommes énormes tout en produisant un logiciel de piètre qualité, et plus ces fournisseurs grossissent, moins il reste d’alternatives. Je ne comprends pas pourquoi on tolère de tels prestataires hostiles.

  • On voit encore des cas où une panne du système informatique oblige le personnel médical à revenir au papier et au stylo. Je ne comprends pas que ces systèmes n’aient pas de redondance. Le plus étonnant, c’est que ce soient des produits commerciaux actuels.

  • Aux États-Unis et en Europe, les EMR (dossiers médicaux électroniques) ne sont pas classés comme dispositifs médicaux, ce qui les exempte d’une grande partie de la réglementation. Lien vers l’article

• La comparaison avec le scandale de la Poste britannique est intéressante. Ce sont des affaires totalement différentes, mais elles partagent toutes deux le même postulat erroné : « le logiciel ne peut pas se tromper ». Pour un développeur, c’est une idée presque risible, mais pour les non-spécialistes, la fragilité du logiciel est difficile à comprendre. Il existait une culture où l’on partait du principe qu’un logiciel ne pouvait pas être défectueux, au point de ne même pas le tester correctement.

  • En réalité, même les développeurs font souvent excessivement confiance aux logiciels. Tous les systèmes que j’ai développés, je les ai toujours considérés comme susceptibles de s’effondrer un jour. C’est pour ça que je ne monterai jamais dans une voiture autonome. Je trouve fascinant que les utilisateurs de HN aiment autant servir de bêta-testeurs à des technologies toutes neuves. Bien sûr, on affirme que les voitures autonomes sont statistiquement plus sûres, mais c’est aussi en partie parce que les conducteurs autour d’elles conduisent prudemment. En plus, ce sont des systèmes nouveaux qui ne reposent pas sur une supervision humaine directe ni sur des standards stricts appliqués de manière équivalente, et c’est cela qui me pose problème.

  • Je pense qu’avec la plupart des machines électriques et mécaniques traditionnelles, l’usure des pièces était la panne dominante, et comme le logiciel ne s’use pas, on a fini par croire à tort qu’il était forcément plus fiable.

  • Le scandale de la Poste était bien plus malveillant, à mon avis. Les hauts dirigeants recevaient des incitations en fonction des montants récupérés auprès des gérants de bureau, et ils ont aussi menti aux tribunaux et aux ministres sur la fiabilité du logiciel. Comparé à cela, Therac-25 relevait davantage d’une erreur honnête.

• J’ai le pressentiment qu’un incident comparable à Therac-25 finira par se produire bientôt. Il y a trop de gens qui déploient des agents IA en mode YOLO, et si des modèles comme Claude ou Gemini sont mal branchés sur du matériel réel, cela finira probablement en accident un jour. L’IA agentique est encore insuffisante dans le domaine des systèmes embarqués, et l’idée d’une application irresponsable de l’IA à des domaines comme les équipements de radiothérapie me fait vraiment peur.

  • Dans l’affaire Horizon de la Poste britannique, plusieurs gérants se sont suicidés et des dizaines de vies ont été détruites. Je pense que Therac-25 doit nous apprendre que tout logiciel est important. Tout logiciel comporte un risque de nuire à quelqu’un, donc il faut toujours rester prudent.

  • Même l’IA non agentique est déjà, selon certaines définitions, en train de « tuer des gens ». Un cas récent où un chatbot IA a contribué à un suicide a beaucoup fait parler, et si l’IA est davantage utilisée demain dans des domaines de décision cruciaux comme l’assurance santé, le nombre de morts « à cause de l’IA » risque d’augmenter. L’IA provoque déjà des accidents mortels dans plusieurs domaines, comme la conduite autonome. Même des bugs apparemment anodins, comme des erreurs Excel, ont déjà eu des impacts sociaux touchant des dizaines ou des centaines de milliers de personnes. Mais avec l’IA aussi, les responsabilités seront probablement floues, laissant beaucoup de place à l’évitement comme dans l’affaire Horizon. J’ai aussi le sentiment que les outils de copilote IA restent insuffisants pour l’embarqué.

  • L’affaire du 737 MAX et du MCAS est un échec au niveau système, mais elle reste un exemple représentatif de ce type de catastrophe majeure liée à la qualité logicielle. Je pense que ce genre de désastre se reproduira encore à l’avenir.

  • Les crashes du Boeing 737 MAX sont eux aussi un exemple typique où un logiciel de mauvaise qualité a coûté la vie à environ 350 personnes (informations sur le MCAS)

  • Quand j’ai essayé des tâches embarquées avec les derniers agents IA, les performances étaient en dessous de mes attentes. Même sur une simple app web CRUD, dès que le modèle de données devient complexe, j’ai souvent vu les LLM se perdre après seulement deux ou trois transformations. Par exemple, si en entrée on a created_at, en stockage created_on, et pour l’envoi vers un système externe last_modified, cela devient problématique.

• L’anecdote selon laquelle, sur le Therac-25, certaines frappes au clavier depuis un terminal VT100 pouvaient provoquer en un instant une surexposition aux radiations m’a marqué. Un utilisateur expérimenté pouvait taper très vite en moins de 8 secondes, et dans ce cas la saisie n’était pas correctement prise en compte, ce qui pouvait conduire à un accident fatal. Quand on voit ce genre de problème, la tendance actuelle à mettre des écrans tactiles partout, même dans les interfaces industrielles ou automobiles, devient inquiétante.

  • En UI, on utilise souvent des optimistic updates pour améliorer l’expérience utilisateur, ce qui rend l’affichage rapide même si l’application réelle n’est synchronisée qu’ensuite. J’espère qu’on saura bien identifier les contextes où cette approche n’a rien à faire.

  • Il y a eu un cas sur la calculatrice d’iOS 11 où une saisie rapide de « 1+2+3 » ne donnait pas le bon résultat (exemple HN associé). Même une calculatrice apparemment triviale peut présenter exactement le même mode de défaillance.

• Je me demande si certains ont étudié des cas comme Therac-25 ou d’autres questions de sécurité et d’éthique à l’université. Pour ma part, j’ai vu cette affaire dans un cours général d’ingénierie, avec la courbe en baignoire ou encore le calcul des pompes de refroidissement redondantes, et je me demande si ce type de contenu fait encore partie des cursus aujourd’hui.

  • Dans un cours sur les interfaces machine à Purdue, au début des années 90, le concept d’« hystérésis » était mis en avant. Il fallait absolument tenir compte du fait qu’un système analogique ne s’arrête pas instantanément comme un ordinateur et qu’il peut présenter toute une gamme de comportements dans sa plage de fonctionnement.

  • On aborde des sujets similaires dans les cours d’ingénierie système. (cours du MIT)

  • J’ai étudié ce type d’incident dans un cursus universitaire de niveau licence ou plus en informatique. Puis, en travaillant dans la medtech, j’y ai souvent repensé.

  • Je me souviens qu’en éthique de l’ingénierie, on n’avait vu en pratique que Tacoma Narrows et Therac-25. Et encore, cela tenait dans un seul cours d’une heure.

  • Cela m’a donné envie de faire moi-même un sondage. Je suis curieux de savoir qui a eu ce type de cours. (lien vers le sondage)

• Les anciens appareils avaient des interverrouillages matériels. Même en cas de problème logiciel, cela se traduisait seulement par un désagrément. Mais, avec l’excès de confiance dans la stabilité du logiciel, ces interlocks matériels ont été retirés pour réduire les coûts, et la surveillance a reposé uniquement sur le logiciel. Au final, un problème mineur a mené à une catastrophe mortelle. C’est un cas emblématique de dissonance entre acteurs placés à différents niveaux.

• Le premier auteur de commentaire sous l’article est médecin, diplômé aussi en informatique, et président d’une société savante spécialisée dans la prévention de la maltraitance infantile (lien vers son profil). Pourtant, dans l’évaluation médicale des maltraitances infantiles, il existe encore de nombreuses failles liées à des données erronées, à des éléments de preuve fragiles et à des raisonnements circulaires exploratoires. Il est difficile d’y trouver une vérité objective, et sur le terrain on a tendance à conclure à une « maltraitance infantile sans l’ombre d’un doute » à partir de quelques indices seulement. On voit maintenant apparaître des IA boîte noire qui prétendent détecter cela avec une grande précision sur la base de données imparfaites, alors qu’on ne peut pas produire de bonnes prédictions à partir de mauvaises données (garbage in, garbage out). Je crains que des diagnostics IA inexacts n’aboutissent à de fausses accusations de maltraitance, à des familles brisées ou à des sanctions injustes. (référence associée, article clinique, IA et problèmes de données, étude)

• Un rapport de 1993 évoquait la nécessité de qualifications pour les ingénieurs en logiciel de sécurité critique. Il affirmait qu’on ne pouvait pas se prétendre développeur de logiciel de sécurité critique après seulement quelques formations à la programmation, et prédisait que si des événements comme Therac-25 se reproduisaient, une certification deviendrait incontournable. Au Royaume-Uni, on discutait déjà de la conception d’un cursus obligatoire. Mais 32 ans plus tard, la réalité est loin de ces attentes.

  • J’ai exercé pendant 15 ans comme ingénieur logiciel professionnel agréé au Canada, mais comme je n’en ai tiré aucun bénéfice concret, je compte bientôt arrêter de renouveler cette accréditation. Il y a eu des discussions pour faire du développement logiciel une discipline d’ingénierie plus structurée, mais elles semblent aujourd’hui largement retombées.

  • Le logiciel de sécurité critique ne s’apprend pas en salle de cours, mais par une longue expérience pratique et de l’entraînement. Même s’il existe des standards comme Do-178 dans l’aéronautique ou IEC 61508 dans l’industrie, le niveau réel d’application varie selon le budget et les délais. Mais lorsqu’un accident se produit, peu importe qu’il existe un historique d’audit : du point de vue des victimes, cela ne change rien. Toutes les règles et réglementations finissent par être écrites après que quelqu’un a déjà payé le prix fort.

• Le logiciel du Therac-25 a été entièrement écrit par une seule personne, dont l’identité n’a jamais été rendue publique après son départ de l’entreprise en 1986. Beaucoup de lecteurs pourraient imaginer que « le développeur s’est enrichi grâce à cette tragédie et a pris une retraite luxueuse », mais à l’époque, contrairement à aujourd’hui, les développeurs étaient mal payés et peu reconnus. Dans les années 80, les figures centrales des entreprises technologiques étaient les commerciaux, et il est probable que la commission sur une vente de Therac-25 dépassait le salaire annuel du développeur. Entre l’emplacement d’AECL, le contexte de l’époque, son statut lié au gouvernement et la nature embarquée du logiciel, tous les facteurs pointent vers une faible rémunération. On parle d’environ 30 000 à 50 000 dollars canadiens en 1986, soit environ 78 000 à 129 000 dollars américains actuels, sans stock-options.