La trouvaille scandaleuse d'un physicien sur une machine de radiothérapie

ce bug a été déterminant dans l'histoire de l'informatique
On vous encourage à aller voir la vidéo qui nous a inspiré cette chronique : • History's Worst Softwa...
👀 À ne pas manquer, la trouvaille scandaleuse d’un hacker sur les câbles Internet sous-marins : • La trouvaille scandale...
👀 La norme HDMI est une mafia : • La norme HDMI est une ...
Pas du tout obligé mais si vous vous abonnez ça m'aide vraiment 🙏 : bit.ly/3xqS2pi
🎥 Suivez l'émission en direct: / micode (c'est 1 mercredi sur 2 à 19h)
🎙 Toute l'émission en podcast, sur votre plateforme préférée: underscoretalk...
📸 Les coulisses de l'émission: / underscoretalk
🐦 Les annonces de dernière minute: / underscoretalk
En plateau, il y a Matthieu Lambda et Tiffany Souterre !

[@lechamoispaladium8869]

Super vidéo comme d'habitude mais je me permet d'apporter quelques précisions : 1) 8:54 Il y a pas mal de confusions ici donc voici un petit recap du fonctionnement de la machine pour mieux comprendre. Le Therac-25 fonctionne en générant des électrons. Il existe plusieurs procédés pour y arriver mais en général on y parvient en appliquant une forte différence de potentielle et en chauffant la cathode. Les électrons obtenus provenant de la cathode peuvent alors être accélérés et dirigés vers la zone à traiter. Il n'y a ici pas de source radioactive, la dose radioactive reçue par le patient ne vient pas de l'exposition à une matière radioactive mais aux chocs des électrons à grande vitesse sur la zone à traiter. Si l'on souhaite utiliser les rayons X à la place des électrons il suffit de placer une cible entre l'accélérateur d'électrons et le patient. Dans le cas du Therac-25 il s'agit d'un plaque de Tungstène. L'explication exacte de ce phénomène passe par la mécanique quantique mais on peut comprendre le principe physique assez facilement : Les électrons sont des particules chargées négativement et le Tungstène est un élément dont le noyau est contient 74 protons, il est donc chargé positivement. Les électrons qui passent à grande vitesse dans le Tungstène vont interagir avec les noyaux. Cette interaction va ralentir les électrons et l'énergie cinétique de la vitesse perdue par les électrons est convertie en rayons X. Cet effet est appelé "rayonnement de freinage". Ce phénomène est notamment illustré par la figure que tu montres à 8:10. D'ailleurs, je pense qu'il y a ici une erreur de traduction car il ne s'agit pas d'un aimant mais bien d'une plaque de Tungstène. Voilà pour le principe de fonctionnement. Maintenant il faut prendre en compte que le rendement de rayons X générés par le rayonnement de freinage est de moins de 1%. Le reste de l'énergie est dissipé sous forme de chaleur. Exemple : Si un patient doit recevoir 100 rad pour sa radiothérapie (je simplifie ici, c'est plus compliqué que ça en vrai) - Avec des électrons : On règle l'accélérateur d'électrons sur "100 rad" et le patient reçoit 100 rad d'électrons. - Avec des rayons X : Si on envoie 100 rad d'électrons à travers une plaque de Tungstène, le patient ne reçoit que 1 rad de rayons X. Il faut donc régler l'accélérateur d'électrons sur "10 000 rad" pour que le patient reçoive 100 rad de rayons X (1% de 10 000). Contrairement à ce que tu dis à 8:56 il n'a pas reçu des rayons X mais bien des électrons et c'est là qu'est le problème : la machine à envoyé une dose d'électrons avec un réglage prévu pour générer des rayons X (donc environ 100 fois trop puissant par rapport à ce qui était prévu). Autrement dit il a pris 18 000 rad d'électrons car la machine était réglée pour envoyer 180 rad de rayons X. 2) 2:53 Le Gray et le Rad ne correspondent pas du tout à la même unité ! Le Rad correspond à une ancienne unité de dose de radiation qui n'est plus utilisée aujourd'hui. 1 Gray = 100 Rad 3) 14:26 5 Gy reçus sur le corps entier correspond à la DL50 (DL50 signifie : Dose Léthale à 50%), autrement dit si je reçois 5 Gy j'ai 50% de "chances" de mourir. Attention ici, le tableau n'est utilisable qu'en cas d'exposition du corps ENTIER. Par exemple, si je reçoit 5 Gy sur le corps entier j'ai une "chance" sur deux de mourir. Par contre si je reçois cette même dose ciblée sur une partie du corps réduite alors l'effet sera très différent. Certains patients qui effectuent des radiothérapies reçoivent plusieurs dizaines de Grays par séance sans que cela ne les tue car la dose est reçue sur une zone très localisée. J'espère que mon commentaire est à peu près clair. N'hésitez pas à demander si vous avez besoin de précisions, je bosse dans le milieu.

[@trollenz]

Merci !

[@nukeo7872]

Super commentaire ! Thx !

[@Interfector]

C'est toi le "physicien" qui travaillait a l'hopital a cette epoque la ?? :p

[@lechamoispaladium8869]

Heureusement non ^^ Je n'aurais pas aimé être à la place du mec quand il s'est rendu compte de ce qui s'est passé

[@edouardcourty4267]

Passionnant, merci :)

[@jeanpauljeannet6348]

Il y a une année j’ai subis pendant 33 jours la radiothérapie Et croyez moi ils m’ont mis la grosse dose . Tous les jours j’avais l’appréhension pour savoir si j’allais me relever ,et à chaque fois c’est comme si j’avais pris une bonne cuite avec des nausées vraiment très désagréable . Les dix derniers jours ont été les plus dures J’avais le cou qui étais cramé au sang je vous laissent imaginer toutes les souffrances . Mais c’est à ce prix car aujourd’hui je suis guéri mais n’allez pas imaginer que cela va prendre que 33 jours . Rajouter 7 mois où je ne pouvais plus mangé les repas normaux car ma gorge avais aussi été cramée.Putain de cancer J’ai gardé l’espoir en luttant de toutes mes forces . Gardez courage ceux qui ont un cancer en ce moment .

[@fredbouvet2913]

Merci pour votre témoignage émouvant. Une question, vous avez beaucoup fumé dans votre vie ?

[@jeanpauljeannet6348]

@@fredbouvet2913 Bonjour ! Oui j’ai fumé depuis l’âge 13 ans j’en ai 65 aujourd’hui Mais la cause de mon cancer a été le virus du Papilloma je vous laisse à allez vous renseigner .Salutations

[@Fortheweak13]

Quelques corrections sur l'aspect radiologique : 2:52 le Gray n'est pas la version française du Rad, c'est l'unité internationale qui à remplacé le Rad depuis des dizaines d'années. Y'a aussi pleins d'erreurs concernant les doses reçues par exemple il faut faire la différence entre la quantité de surface exposée : lorsqu'on parle d'une dose léthale 50 à 5 Gy c'est sur une exposition corps ENTIER (type liquidateurs de Tchernobyl), ce qui n'est pas le cas de la radiothérapie où on expose uniquement de petites parties du corps. 5 Gy sur la main par exemple c'est grosso modo "seulement" un érythème et éventuellement une irritation, sécheresse et desquamation cutanée plusieurs jours après exposition. Idem quand vous mentionnez que les 13 travailleurs de Fukushima les plus exposés ont pris 12 Gy, si c'était corps entier ils ne seraient plus parmi nous depuis des années, hors il n'y a eu aucun décès lié aux radiation dans cet accident. Bref c'est un sujet complexe

[@Jean-BaptisteLesaffre]

Merci d’avoir pris le temps

[@lu6f33razazel6]

il y a eu des décès sur les intervenants les plus proche de Fukushima.. juste que le Japon a laisse passé les informations au comptes goutes voit pas du tout, ou complétement faussé les résultats... surtout sur ce genre de catastrophe qui toucheront bon nombre de personnes a long terme

[@bobbobbob3847]

C'est vrai, mais toutes les solutions implique ce genre de problème, les ruptures de barrages, les explosions de centrales thermiques a gaz ou pétrole et leurs lots de particules fines, les accidents miniers (mêmes si c'est pas notre pays) quotidien pour extraire tout les métaux nécessaires ... Toutes celles ci ont d'ailleurs à l'heure actuelle causé bien plus de mort que les catastrophes nucléaires (estimation faible ou haute !), alors oui tout peut être motif de remise en question, mais la réponse n'est pas forcément la plus simple et intuitive@@telespectre9764

[@Ekaterinetta]

@@lu6f33razazel6 aucun intervenant à Fukushima ne s'est pris plus de 0.5Gy (début des effets déterministes), et pour l'instant aucun effet stochastique n'a été vu (et à priori jamais)

[@rca168]

Dans underscore les sujets sont intéressants mais la précision est souvent proche de 0 et ça n'a pas l'air de les embêter plus que ça. Surtout que souvent ça devrait nuancer beaucoup les conclusions. Bon dans mon cercle d'amis et pros on sait que cette émission est très putaclic mais ce n'est pas le cas des gens qui sont moins expérimentés dans ces domaines...

[@lucasdalbosco7539]

Je suis physicien médical en radiotherapie externe et j'ai fais une thèse en IA et j'apprécie beaucoup la vidéo, on étudie souvent les cas d'incidents techniques en clinique je ne connaissais pas celui-ci très instructif ! Tout n'est pas correct dans la video mais ça reste intéressant 😊

[@elyon2966]

Gros t’as un cc à réviser

[@ericv-kj3du]

Intéressante vidéo. Je ne connais pas la chaine, je vais en regarder d'autres. J'attendais une chaine comme celle là, visiblement tournée vers les développeurs, mais c'est si compliqué... Les gens qui viennent commenter négativement ne se rendent pas compte des difficultés à proposer des contenus intéressants sur un domaine aussi transverse que le développement. Le développement est un métier, et les spécialistes de ce métier ne peuvent pas être à la fois des spécialistes de ce métier et des spécialistes du métier qui a recourt à leurs développements (en l'occurrence ici, le biomédical) sauf à avoir plusieurs années d'expérience, en général une vie rangée et peu d'attrait pour faire des vidéos peu rémunératrices (au regard du temps investi), en plus d'être rapidement monosujet. Il n'est donc pas étonnant qu'il y ait de nombreuses approximations sur l'imagerie X, les mesures de dosimétrie et leurs unités, qui sont légions. Les commentaires pertinents sauront corriger ces erreurs, qui ne remettent pas en cause l'intérêt de cette vidéo, qui est de présenter le mécanisme à la base du dysfonctionnement.

[@saidbaci4344]

Quand l'odeur du fric allèche plus que la volonté de guérir.

[@manu-wj5wb]

Dans le même registre : coût du bug informatique de la fusée Ariane 5 en 1995 qui a explosé 40s après son lancement, 500 millions de $

[@dyspee]

J'ai la même référence depuis que j'ai vu le document sur France 5

[@NicolasGin]

En plus c'était un overflow, ça paraît tellement naturel maintenant de faire attention à ça (même si des histoires de problèmes dus à des oveflows j'en connais pas mal, mais heureusement sans importance)

[@antoine2571]

@@NicolasGinOui ! C'est une conversion d'un float vers un int 16 bits non-protégée

[@mooncorp212]

@@NicolasGin ca l'était aussi à l'époque, en code. C'est encore plus con qu'un simple overflow. Il me semble que c'est un capteur qui a envoyé une valeur très grande au code (valeur anormale sauf dans ce cas physique particulier), que le code a interprétté comme un signé négatif (le premier bit étant levé à un). En gros le code n'attendait pas une valeur par exemple 8 bit > 127 et le capteur a envoyé 200, ce que le programme a interpretté comme -72. Le code a ensuite chercher à retourner la fusée pour rétablir une valeur positive. En France, cet exemple est donné à tout les étudiants en info idus depuis au moins les années 2000, tellement on a pas envie de refaire la boulette :)

[@mooncorp212]

@@antoine2571 pas de flottant en asm. obligé de passer par un coprocesseur qui fait les conversions, et qui les fait bien.

[@abriotde]

Je ne suis pas certain que le monde ait bien changé depuis. Le déni de problème est toujours aussi courant dans les communication des entreprises. Certes, dans le domaine critiques, le code est bien relu/testé mais les problèmes ne sont pas moins courants pour autant. En témoigne les scandale de Médiator et autres...

[@Oriannaotp]

Très bonne vidéo, et je suis d'accord avec la demoiselle, qui n'a pas pu développer son propos. C'est l'histoire de l'homme et de la sécurité en général. Malheureusement, il doit y avoir des blessés, voir des morts, pour améliorer les process, les repenser, et comment faire pour ne plus que cela arrive. C'est cynique mais la triste vérité. Comparer les standarts de sécurité d'une automobile, il n'y a pas si longtemps, une trentraine d'années, a une voiture d'aujourd'hui. Que ce soit pour les constructeurs et pour l'usager ( la ceinture, l'alcool, la vitesse ... ) Dans l'aviation, ne pas sanctionner les pilotes s'ils font une erreur pour éviter leur mutisme, afin de comprendre et corriger des manquements, retour d'expérience etc Je le vois dans mon métier, sur une installation électrique récente et conforme, je ne peux m'électriser. Je ne peux en dire autant des vieilles installations, sans parler des incendies qui était récurent dans l'habitat. Dans tous les domaines, la sécurité s'améliore a cause d'accident, même dans le cas de cette machine. C'est choquant mais il faut l'accepter. Savez vous pourquoi ? Car nous sommes hommes, fait d'imperfection.

[@vincentgourlier4299]

7:19 #Bravo Tyffanie, excellente analyse j'aime beaucoup ta présence dans ces publications car tes propos sont toujours très compréhensibles et directs, ça tape dans le mille.... vous formez 1 excellent trio c'est plaisant des chroniques tech instructives comme celles qui vous nous proposez.... ps : je garde toujours ton exploit avec le bot minecraft dans l'esprit, et croise les doigts que vous nous meniez à ce niveau 1 jour ! Meilleurs vœux pour la suite !

[@toto7571]

après vu que lors de l'histoire, il a un peu insisté là-dessus, c'était assez attendu comme explication !

[@pipoto18283]

Merci aux auteurs des commentaires d'avoir compléter ou "corriger" cette superbe vidéo. Rien que le sujet est passionnant mais aussi très technique. Merci pour la vidéo.

[@Zyrc0]

Pour ceux qui veulent plus de détails et d'illustations en complément de ce sujet, il y a une vidéo de Kyle Hill qui en parle très bien

[@trollenz]

Ah ben merci parce que l'explication est un peu vaseuse tant au niveau physique qu'au niveau logiciel...

[@Gitalien1]

1. Pb de conception logicielle (ça arrive tous les jours et c'est normal) 2. Pas de peer review (anormal) 3. Pas de test, négative testing, exploratory testing pour détecter l'erreur 4. Pas de calcul théorique de la dose envoyée selon configuration courante de la machine (en tenant compte donc de l'aimant en place). Et donc blocage potentiel du flow si on dépasse des valeurs non sécuritaires 5. Pas d'investigation poussée après le premier incident 6. Pas de détection de la dose perçue par le patient après coup, qui aurait pu donner un indice de la malfonction Ça commence à faire beaucoup.

[@NicolasGin]

Oui, beaucoup de problèmes, il n'y a pas que la problème logiciel

[@docteurlowbat]

Tu es sur que si tu te pointe à l'époque et que tu commence à parler de "peer review", "negative testing", etc ... tu ne risques pas d'être obligé d'expliquer la signification de ces néologismes ? 🤔

[@Gitalien1]

@@docteurlowbat Oui j'utilise les mots de l'industrie IT d'aujourd'hui. Mais à l'époque il suffit simplement de dire: - Fait vérifier ton boulot par un autre développeur - Fait vérifier ton boulot par un spécialiste qui utiliserait ta machine. Ça semble la base, sauf à avoir un ego démesuré.

[@docteurlowbat]

@@Gitalien1 A l'époque ce n'était pas forcement la culture. Ils disent bien que c'est un gars seul qui a fait ça. Alors faire vérifier par un autre qui n'est pas de la boite, qui ne c'est pas intéressé au problème, sur du code machine, ça me semble illusoire.

[@Gitalien1]

@@docteurlowbat @docteurlowbat je pense pas qu'il était dans les usages, même à l'époque, de faire développer une application critique du médical par un gars seul, amateur, qui n'est pas de la boîte. Je rappelle qu'on envoyait des hommes sur la lune 15 ans avant. Les années 80 c'était pas le moyen âge.

[@pointservicephone1049]

Dans l’industrie automobile des années 80, certaines presses à tôle n’avaient qu’un seul bouton d’activation, on s’est retrouvé avec une multitude d’accidents où les opérateurs laissant à se balader leurs mains dans la machine pendant qu’ils appuyaient sur la presse. Toutes les machines ont ensuite été équipées de deux boutons simultanés pour obliger les deux mains à être à l’extérieur

[@chrisb9143]

idiot-proof design is great

[@Uriel_777_]

Jusqu'à la fin des années 1990 en fait, malheureusement j'ai connu des accidents en injection de plastique même début 2000...

[@guillaumepoirier3618]

Quelqu'un l'a sans doute déjà dit: l'illustration est un IRM alors qu'il est question d'un appareil de radiothérapie

[@arcaelum2022]

Erreur volontaire je pense, les IRM sont plus connus, et beaucoup de spectateurs ont déjà dû en faire. Contrairement aux machines de radiothérapie, qui ont pourtant un air aguicheur avec leur bras rotatif...

[@DIMZEROCENT]

C'était en 1982, il y a bien longtemps, mais ce serait faire preuve de suffisance que de croire qu'aujourd'hui tout est parfait dans le meilleur des mondes et que des erreurs potentiellement dramatiques ne peuvent plus arriver. Je suis moi-même amené à produire du code, souvent à en reprendre d'autres personnes (qui quittent la boîte, changent de service, ...) , inutiles de vous dire qu'il est difficile de tout prévoir et de tout anticiper. Tout change souvent - au niveau des "requirements -" en cours de développement voire en production.... et dans l'urgence, toujours dans l'urgence, et toujours pour pas cher. On en vient à reprocher à celui qui code de ne pas avoir prévu que des changements fondamentaux allaient survenir A POSTERIORI au niveau du cahier des charges. Alors on bricole, on "patche"... Heureusement, dans mon cas tout ce qu'on risque de perdre, c'est du pognon... Et c'est pareil dans tous les secteurs. Petite anecdote : Aux alentours de 2015, la boîte où je travaille se dotait d'un système "hyper moderne et optimisé" de gestion de ses 16 ascenseurs. L'idée est d'éviter les files aux heures de pointe, : on commande son étage à l'extérieur de l'ascenseur, avant même d'y arriver (les commandes sont placées une dizaine de mètres avant d'arriver aux cabines elles-mêmes) et le système vous dirige vers la cabine correspondant le mieux à votre destination à ce moment-là en optimisant l'occupation des cabines (16 personnes max). Révolutionnaire, magnifique, géré par un puissant serveur, on allait voir ce qu'on allait voir. On a vu que c'était pis qu'avant. Ça coûtait un bras, donc les techniciens de la société (une des deux bien connues qui vous viennent à l'esprit en matière d'ascenseurs en europe) passaient leur vie chez nous à essayer d'améliorer le système. À tel point qu'un jour ayant moi-même pris l'ascenseur un peu plus tard que de coutume pour quitter le bureau j'ai pu entendre un échange désabusé entre deux employés de la société en question qui partageaient ma cabine et ça donnait à peu près ceci : "Rien à faire, je n'y comprends rien, le système continue à déconner". "Bah, tu m'étonnes, ça ne ressemble plus à rien à force de patcher le code qu'on installe partout depuis des années, plus personne ne s'y retrouve... on devrait reprendre "from scratch" !". "Alors là tu peux te gratter pour faire passer une idée pareille.... trop cher !". Il ne s'agissait à priori pourtant de rien de trop complexe. Les techniciens en ascenseurs ont disparus du paysage après quelques semaines, et aujourd'hui, les ascenseurs de ma boîte déconnent toujours :D

[@anysbougaa6645]

Pour donner des precision sur le mode de fonctionnement Dans les 2 cas c’est des rayon X qui traitent la tumeur (il existe le gamma knife qui utilise les rayons gamma) Un tube radiogene est un tube électronique sous vide qui contient 2 electrodes (je rentre pas dans le detail mais c est la même chose qu’un tube électronique d’ampli mais avec une grosse anode) lorsque on injecte une très haute tension a quelques mA un faisceau d’electron se produit entre les electrodes. Les électrons viennent s’ecraser a la vitesse de la lumière sur l’anode et 99% de l’énergie part en chaleur 1% produit des rayons X en gros c’est la forme la plus primitive d’accelerateur de particule Dans une machine de radiothérapie on a un tube radiogene très puissant (comme pour la radiographie) sauf qu’il est plus puissant et un système d’optique (l’optique X c’est du metal pas des lentilles en verre) concentre le rayon sur une petite zone Il existe un second type de machine qu’on appelle Accélérateur de particules linéaire, on accélère toujours un faisceau d’électrons mais au lieu de le faire dans un tube en verre c’est un espèce de canon qui envoie les electron qui sur la tumeur Les electrons s’ecrasent non pas sur l’anode mais sur la tumeur et produit des rayons x a l’intérieur de la tumeur (plus precis au mm près et plus efficace) Le gamma knife est la même chose que la machine a tube radiogene sauf que le tube est remplacé par une capsule de cobalt 60 (un produit extrêmement radioactif 1mg tuerais 1000pers peut être) emetteur de rayon gamma beaucoup plus énergétique et pénétrant que les X (qui sont plus « mous »)

[@LeonxLeon]

En tant que radiothérapeute cette histoire m'a toujours effrayé

[@fanlou1698]

Bonjour je ne sais pas sur quel matériel vous travaillez, mais le risque est non nul de nos jours mais, avec toutes les redondance sur la mécanique et contrôles des débits, et doses, les accidents de ce genre ,j'ose l'espérer ne seront plus possible. En 15 d'expériences sur la maintenance des anciens Siemens, primus,oncor,artiste et toute la gamme Varian, clinac,truebeam et halcyon, les seuls incidents, accidents que j'ai relevé ou documenté pour des materio-vigilance avaient dans 99% des cas des causes humaines.

[@LeonxLeon]

@@fanlou1698 Sur Elekta actuellement (mais plus pour longtemps surement, peu satisfait de leur évolution), oui effectivement les contrôles qualité sont extrêmement rigoureux ! J'ai toute confiance dans mes physiciens.

[@NicolasGin]

Je comprends...on fait quand même les choses mieux maintenant, et je ne sais pas si ces machines deux en un existent encore, mais vu que le début de la production des électrons et rayons X est la même (on produit et accélère des électrons), mais à des intensités différentes, je trouve ça économe mais vraiment dangereux de base

[@fanlou1698]

@@NicolasGin oui oui. Le principe est toujours utilisé de nos jours. On accélère des électrons, soit ils ont le passage libre, et l'on traite en e-, soit on place une cible en tungstène et par effet de freinage génère des photo X, en général de 6 a 25Mev. De nos jours les électrons sont de moins en moins utilisés. Les nouvelles techniques, comme Vmat ou adaptatif font que tout est fait en général en X6. -> machine mono énergie beaucoup plus stable. J'ai quitté l'industrie pour la particule thérapie, plus précisément sur du carbone via cyclotron. Un autre challenge. 😁

[@NicolasGin]

@@fanlou1698 Merci pour les détails. J'ai été dans une équipe rayons X, mais surtout pour le côté imagerie (un point de vue très maths). Je n'ai pas entendu parler de radiothérapie par faisceaux d'électrons, et ça fait sens si c'est moins utilisé

[@Cataplasme44]

Merci les gens gentils. Ça fait du bien quelque part de se dire que l'on a quand même appris de ces erreurs qui ont coûté des vies et causé des souffrances inimaginables.

[@Perska121]

Attention ici pour Fukushima (14:15): Je ne sais pas d'où viennent les chiffres concernant les "13 travailleurs" les plus exposés, mais selon l'IRSN, les chiffres sont très différents. En effet la dose max reçue par le travailleur le plus exposé était de 678.80 mSv (0.678 Sv) ou encore 0.678 Gy. Et cette dose a été reçu sur une période de 5 ans. Il n'est donc ici pas spécialement approprié d'utiliser un évènement comme Fukushima pour comparer la dose reçue par ces patients lors des incidents.

[@TTxR2]

En effet merci, cela m'a étonné que quelqu'un ait reçu une dose d'une telle létalité.

[@raph7711]

10:06 à mon avis c'était les débuts de la programmation donc pas d'expérience en terme check-up ou de redondance

[@bricewernet6493]

Je trouve que ça reste courant dans le développement de produits. 1-se dire qu'on pourra tout faire en sort, c'est plus rapide et facile à ajuster 2-du coup ne pas se soucier d'une vérification de sécurité hardware 3-pour des raisons de marché (coût, time to market, discrétion sur un produit qu'on veut breveter): ne pas en dire trop aux prestataires Au final, le développeur crée un programme sans réelle visibilité sur les impacts et sans savoir que tout repose sur son travail. Il y a plein de bugs moins dramatiques, et certainement plein de bugs dramatiques qui ne sont pas encore survenus mais sont en gestation. Combien avez-vous vu de sites internes, logiciels web qui plantent côté client (erreur JavaScript, arrêt du script) totalement silencieusement pour l'utilisateur? Par contre, ce que j'adorais programmer sur vax, mode terminal : - hyper efficace en dev, car lui est simple et prévisible - hyper efficace pour les utilisateurs, qui savent faire immédiatement la différence entre un comportement différent du logiciel et un simple message de l'os

[@alienews0]

13:50 "aucun test de régression" non mais gros c'est aussi pertinent que de dire au sujet d'une voiture conçu en 1950 "aucun airbag". Tu n'imagines pas comme l'informatique à changer rapidement et comment tous ces concepts n'existaient pas. Rien que sur les 20-25 dernières années (entre quand j'étais étudiant en info en 2000 et maintenant) il y a eu des révolutions de dingues (à savoir par exemple à cette époque on parlait pas de test unitaire/de régression/... on enseignait pas les méthodes agiles (qui n'existaient même pas) quand t'étais dev c++ tu manageais entièrement la mémoire tout seul (pas de pointeurs intelligents et donc oui si ça plante il y aura très probablement du memory leak au passage, sans compter que tu peux aussi en avoir sans plantage si le dev oublie de libérer une partie de la mémoire qu'il a dynamiquement réservé...). Bref tu vois ça avec des lunettes de jeune dev des années 2010~2020 et la plupart de tes remarques sont complètement anachroniques...

[@tronche2cake]

je suis étudiant en médecine, il me semble que ce serait une erreur médicale de ne pas aller vérifier comment va le patient avant de redémarrer la machine

[@benjaminm6788]

Alors ici la le patient semblais aller bien avant le début de la scéance c'est au début de la scéance que ça a foiré 😅

[@baltiendebagdinath5924]

@@benjaminm6788oui mais ce que veux dire tronche2cake c'est que il aurait dut aller voir le patient AVANT de remettre une seconde fois la machien en route.

[@tototurbo]

De toute façon, même si ils avaient vérifié c'était déjà trop tard, ils ont pris directement une dose massive de radiation il me semble.

[@djydjy1995]

Tout a fait

[@LudovicEv]

​@@benjaminm6788il a écrit REdémarrer 😉

[@azdinator]

Un accès concurrent à une shared memory était un défi très important en programmation assembleur à l'époque, et elle l'est toujours aujourd'hui dans les langages de programmation de plus haut niveau comme le C (on est sur de l'embedded ). Les bibliothèques du C offrent des abstractions et des mécanismes de synchronisation plus élevés, ce qui simplifie souvent la gestion de l'accès concurrent par rapport à la programmation en assembleur Par exemple, en C, vous pouvez utiliser des primitives de synchronisation telles que les mutex, les sémaphores, les variables de condition, etc., qui sont fournies par des bibliothèques standard ou des bibliothèques tierces. Ces mécanismes abstraient une grande partie de la complexité de la gestion des threads concurrents et de la mémoire partagée. C'est d'ailleurs ce trop grand niveau d'abstraction qui fait baisser le niveau des developeurs car la complexité est cachée...c'est un autre thème.

[@yannmassard3970]

entierement d accord. Les surcouches d abstraction, de classes et d apis font qu on a maintenant d avantage de "scripteurs" que de codeurs. Et ca va en empirant.

[@driiade6311]

@@yannmassard3970 C'est vrai que c'est mieux l'ancienne époque a envoyer les gens au cimetiere en assembleur. Qu'est-ce qu'il faut pas lire, les logiciels sont de plus en plus gros avec tout un tas de données à gérer. Mais non on va surement repasser en assembleur pour gérer le fait d'acceder à une variable....

[@yannmassard3970]

@@driiade6311 on voit que t as jamais travaille sur de "gros logiciels" comme tu dis...

[@bryansprajc1612]

Très bonne vidéo. On sent le stress de Matthieu Lambda lors de cette présentation, rien de gênant d'autant plus que l'histoire est très bien expliquée. Matthieu ne t'en fais pas ton intervention est top et tu verras que ce stress disparaîtra peu à peu au fil de tes interventions ;)

[@jpdubdub]

Le bug de decallage de son aussi est pas mal . Mais super interessant

[@aissabriand]

Salut, j'ai un truc à dire effectivement je vis à Saint Pierre et Miquelon et nous somme à 20 km de Terre Neuve au Canada, mais sachez que 6 personnes dont 5 mortes à cause de ce bug c'est vraiment le sommet de l'iceberg, le canada n'a pas partagé de vrai chiffre officiel, mais c'est très certainement des 100 ene de personnes qui on souffert, plus ou moins, oui. Il on pas remarqué aussi vite, mais ils or à fallut bien plus de temps pour comprendre et trouver le pb, bien évidement le mal été fait

[@seevaq]

Le coup du patch pour empêcher de modifier le beam je peux le comprendre, dans un premier temps empêcher le plus rapidement possible que l'erreur soit reproduite quitte à faire une régression fonctionnelle et dans un second temps produire un autre patch qui remet la fonctionnalité mais suffisamment testée pour qu'il n'y ait pas de possibilité de bug.

[@goku445]

Quand il y a des morts. C'est pas un patch à la vite qu'il faut mais reprendre tout de zéro et mettre la machine hors production.

[@ip.3117]

@@goku445 Sauf que mettre hors production des machines de ce type, ça se fait très lentement, car elles sont extrêmement chères, qu'il faut les produire, les livrer, les remplacer etc. alors que les patients en ont toujours besoin. Donc lancer l'avertissement et faire le patch pour éviter que ça se reproduise avant que le parc ne soit renouvelé, c'est une bonne solution pour du court terme. ( évidemment pas satisfaisante sur le long terme )

[@goku445]

@@ip.3117 Les patients ont surtout besoin de ne pas être irradiés façon Hiroshima.

[@ip.3117]

@@goku445 Mais ils ont quand même besoin d'une radiothérapie. Le dysfonctionnement se produit dans des conditions très précises. Dans un premier temps il suffit d'éviter de permettre à ses conditions de se produire. Parce que ok, mettons on suit votre approche et on bloque toutes les machines concernées... Et on fait quoi en attendant que les nouvelles machines soient construites ( car oui c'est pas un ordinateur, tu n'as pas des hangars en contenant des quantités astronomiques, encore plus à l'époque), livrées, installées ... Peut être on peut envisager en cas d'un seul remplacement de repartir la charge dans plusieurs hôpitaux à proximité ( et encore fait ils qu'il y en ai équipé avec les anciennes machines) mais ça génère des augmentations de flux dans des hôpitaux pas forcément dimensionnés pour accueillir tous ces patients additionnels dans cet intervalle. Le retard de soin dans le cas d'un cancer, ça peut aussi être létal. Le patch n'était pas satisfaisant pour du long terme, mais pour du court terme, c'était une idée raisonnable.

[@goku445]

@@ip.3117 On parle pas de reconstruire les machines... C'est un bug software. On stoppe les machines et on reprend le software et on TEST extensivement. La radiothérapie c'est pas comme si c'était miraculeux non plus pour traiter le cancer... Risk/reward est toujours le plus important.

[@escalope7214]

Merci, juste après cette vidéo je vais partir faire un scanner ça donne envie !

[@willyrobert3375]

@15:38 : le mot que tu cherches c'est "drame". Les processus de sécurité qu'ils soient médicaux, domestiques, routiers, ferroviaires, aériens, spatiaux, informatique, au travail, etc.. ont toujours été revus/augmentés qu'à partir du moment où il y a eu un drame ! L'Homme est un animal majoritairement réactif et très peu proactif. Comme disait Bigard : c'est au pied du mur qu'on voir le mieux le mur...

[@harbardr63]

Vos émissions sont toujours aussi excellentes ! Petite suggestion qui serait super : ajouter vos sources en description, ça serait très intéressant ;)

[@bluessharky7373]

J'adore vos vidéos, mais "le monde à bien changé!" ,je ne suis pas sur du tout de ça 🤣

[@user-cv6kv9rk5s]

Idem

[@duftravel1]

Les process ont bien evolué en 40ans, les machines sont calibrées regulierement, testées tous les matins avant les traitements. Le traitement du patient est testé sur un 'recepteur', pour etre mesuré afin de valider la cohérence du rayonnnement. Le rayonnement est hyper ciblé afin de se concenrtrer sur la tumeur en evitant les organes sains. Et le micro et la caméra fonctionnent ! 😊

[@Stephane2718]

Cela m'amuse toujours d'écouter les gens critiquer le passé tout en étant persuadé que c'est mieux aujourd'hui. Surtout les commentaires du genre, comment peux t'on faire une erreur aussi basique. Nous faisons des erreurs que sur les points ou nous ne prenons pas la peine ou le temps nécessaire a la réflexion. Les points complexes sont analysés profondément au détriment des choses devenue basique pour lesquelles on évite les pertes de temps en reétudes. Les choses basiques sont statistiquement plus génératrices d'erreurs, cela est une évidence pour n'importe quel ingénieur, sauf que je ne le ressens pas vraiment dans vos propos. N'oubliez jamais que les procédures que vous appliquez bêtement aujourd'hui de façon systématique ont toujours une raison d'être. Et êtes vous toujours en mesure de les expliciter ? Si c'est le cas, pourquoi avoir mis en place des bonnes pratiques de travails pour quasiment tout les métiers, y compris la programmation informatique. Les erreurs sont les principales sources de progrès et les progrès restes les principales sources d'erreurs. Etes vous certain que les logiciels d'aujourd'hui sont plus fiable que ceux d'hier ? Les exemples récents qui prouvent le contraire sont pourtant nombreux. Il suffit de regarder la pléthore de logiciels disponibles qui pourtant, pour beaucoup, ne fonctionnent pas comme ils le prétendent. Les morts du a des bugs logiciels n'ont pas disparues de nos jours. Regardez les statistiques de l'Industries.

[@shino5429]

Super cool j'aurais une nouvelle anecdote a racontée au radiologue et autres l'or de mes poses d'anti X ( ce sont des plaque recouverte de plombs qui tapisse toute la pièces )

[@Aboudrar2010]

Une suggestion pour un nouvel épisode : "La trouvaille scandaleuse de médecins et de biologistes sur les inoculations ARNm de Prizer"

[@brunofocant2481]

Va vomir ton incompréhension scientifique ailleurs que sur une chaine d'informatique. Ton commentaire montre tellement à quel point tes capacités d'analyses sont, sans équivoque, nulles 👌

[@Aboudrar2010]

@@brunofocant2481 🤣🤣🤣🤣 Généralement je ne me rabaisse jamais à de tels niveaux de médiocrité intellectuelle. Conseil d'"ami". N'oublie surtout pas ta cinquième dose. Elle te rendra encore plus intelligent, ainsi tu arrivera peut être un jour au rang de "génie" parmis la nouvelle race de tranhmumains dopé à la biotechnologie ARNm. Et tu acquérera peut être la capacité pour me faire comprendre ce que je n'arrive pas à comprendre à cause de ma crasse 'ignorance". En attendant peut tu m'expliquer ce que raconte cette étude publié sur Nature. Si vous voulez le papier complet, je peut vous l'envoyer sous PDF. J'ai aussi pleins d'articles sur le sujet que je n'arrierai jamais a comprendre sans l'aide de génies tranhmumains comme vous. Je suis vraiment trop con pour comprendre tout seul. J'attends votre expertise avec impatience. Merci d'avance. www.nature.com/articles/s41586-023-06800-3

[@danielleblanc5923]

Bon, quand on a un processus qui dépend d'une grandeur physique comme la position d'un élément on introduit une boucle d'asservissement. Donc, question peut-être stupide mais pourquoi est-ce qu'on a pas au moins bloqué la machine pendant que l'élément mobile n'est pas en place ? Le logiciel peut "lire" la position de l'élément pour confirmer qu'il est sûr de passer sur l'autre dosage et donc pendant les 8 secondes la source d'émission est coupée. Ce n''est une question de programmation seulement mais on n'a surement même pas demandé dans les spécifications qu'il y ait cette forme de sécurité ce qui est aberrant.

[@marie-christineronvaux9423]

Bonjour à vous 3! Vous êtes vraiment très intéressants, captivants!! Waouw!!

[@Duaner244]

Et la victime s’appelait Ray…

[@kerry8977]

développer en assembleur c'est chaud ...

[@simonngoy4803]

Ce bug est encore présent dans là plus part de nos applications moderne on appel ça "Race conditions" conditions de course en français. ils utilisent des requêtes synchronisées pour dépasser une certaine sorte de limite, par exemple : Utiliser une carte-cadeau plusieurs fois Appliquer à plusieurs reprises un seul code de réduction Noter un produit plusieurs fois Retirer ou transférer des espèces au-delà du solde de votre compte Réutiliser une seule solution CAPTCHA Contourner une limite de taux anti-bruteforce

[@LudovicEv]

On avais ce souci aussi avec les codes allopass ou plein de personne entrait le même code en même temps...

[@ledupret]

ça me tue le nombre de commentaires alors que la vidéo est sortie y a 4 minutes alors qu'elle dure 16.

[@francoisp3625]

Mode chippoteur/chieur 2:20 sauf que ca c est un VT100 un terminal passif pas un ordinateur :) il est relie par serial port a un ordi vu que c est DEC surement un VAX/VMS ?? 11:55 ah non pdp11 12:50 mauvais choix d archive INA ca c est du basic pas de l asm :)

[@tahameron9155]

Super vidéo comme d'hab'. Mais j'aimerais témoigner en tant développeur logiciel : La conclusion de fin c'est : "Et c'était dans les années 80-90, le monde a bien changé heureusement." Et bah je suis désolé de dire qu'en France c'est encore une réalité. Je n'ai jamais travaillé dans les logiciels medicals ceci dit. J'espère que dans ce domaine ils sont plus honnête avec leurs clients.

[@davilinkicefire]

Ce que je me demande, c'est pourquoi la machine était capable de produit un rayon x aussi puissant que ça, il devrait avoir eu un maximum physique.

[@fabien8268]

Pour mettre qu’un seul programmer dans le projet pour moi c’est un problème de temps accordé au développement du hardware. Le gars qui s’en est occupé a forcément omis de programmer des limitations dans son code

[@carbonn7280]

Effectivement, ca rejoint un peu la vidéo précédente où Colin parlé de "sécurité par design", le problème aurait été éliminé dès la conception.

[@skythree4561]

visiblement parce que pour le mode électron la machine doit envoyer une dose de rayon X élevée sur l’aimant

[@benjaminm6788]

La en l'occurrence niveau rayonnement le problème a été qu'il a été irradié avec une certaine quantité de faisceau d'électrons d'une énergie de 25Mv qui devait être convertis en rayons X en quantité voulue avec une cible par rayonnement de freinage (qui est l'"aimant" en question dans la vidéo). Or ici l'"aimant" n'était pas en place mais la machine générait tout de même des électrons prévus pour être freinés à 99% (convertie en chaleur). Voilà pour les explications des rayonnement j'espère que j'ai été clair.

[@NicolasGin]

Je trouve que la vidéo n'est pas très claire pour l'aspect non informatique (mais c'est pas leur domaine, donc je comprends). Je ne connais pas ce type de système et je connais mieux les systèmes d'imagerie que de radiothérapie. Mais il faut comprendre qu'il n'y a pas que la puissance du rayon X ou du faisceau d'électron qui compte, il y a la zone irradiée, sa taille, et surtout la durée d'exposition. Je ne sais pas à l'époque, mais maintenant il y a des systèmes de plaque amovible (je suppose en plomb) pour que les rayons X n'atteignent que la zone à irradier. Funfact pas fun : la radiothérapie est cancérigène ! Mais le rapport bénéfices/risques est largement en faveur du traitement du cancer bien sûr.

[@fizzle5912]

Comme d'habitude super intéressant, pour aider à la traduction physician=médecin

[@fizzle5912]

Edit je ne sais pas tout peut être qu'au Canada il y a un métier physicien sûrement spécialiste en physique nucléaire ???

[@lorentzisagoat8409]

Non c'est bien physicien pas médecin, c'est un physicien médical qui s'occupe de faire la dosimètrie

[@TheDjudj]

Pour avoir travaillé sur des softs embarqués (typiquement comme pour ces machines) depuis maintenant 23 ans, j'ai été plusieurs fois amené a reprendre du code vieux de 20 ans environ. C'est là que je vois comment mon métier a évolué depuis tout ce temps. Autant au niveau des process de validation qu'au niveau des normes de codage ou de conception. A l'époque l'usage de sémaphore d'exclusion mutuelle ou le principe d'un getter pour protéger les accès concurrentiels aux données n'était pas répandu.

[@jnbreton4560]

Passionnant. J’ai appris à programmer dans ces années là sur de gros systemes Ibm en assembleur. Effectivement piloter des systèmes temps réel était beaucoup plus complexes avec des mini systèmes comme PDP 11, HP 1000, ETC. L’i nterface présentée ici est tout à fait classique pour l’époque 😢. Les erreurs d’entrée devaient etre soigneusement contrôlées car les interfaces étaient très frustes : pas de fenêtres, pas de souris, pas de pop-up😊. Chaque programme était livré avec un manuel de saisie presq'u aussi volumineux que le manuel d’utilisation lui-même. Ce type de problème a été a l’origine du crash du mont St Odile. Ecran affichant le taux de descente sur deux digits. Soit le nb pieds minutes divisé par 100 soit l’angle en degrés... en clair pensant rentrer 15 ° d’angle de descente vous rentrez 1500 pieds par minute ou l'inverse ce qui fait une sacrée différence.

[@bebert0712]

Il n'y a même pas un dosimètres à la place du patient pour vérifier les doses reçues en fin de séance? Ne serait que pour faute humaine? Ok....

[@meca-tronic1857]

Il y avait un moniteur de dose, qu’on appelle chambre d’ionisation (elle se trouve dans le machine et est traversée par le faisceau avant que celui-ci arrive sur le patient). Ce détecteur est effectivement sensé mettre la machine en sécurité si la dose mesurée est différente de la dose programmée… Mais ça n’a pas fonctionné dans le cas des incidents du Therac25. La raison est qu’elle saturait dans cette configuration très précise et donnait un résultat « low dose »…. Les ingénieurs n’ont pas pensé à toutes les possibilités en designant la chambre. C’est complètement dingue. C’est au final un vrai concours de circonstances. On en entend rarement parler de cet aspect là quand l’histoire du Therac est évoquée. Aujourd’hui ces chambres d’ionisation sont redondantes et beaucoup plus fiables. C’est le composant le plus important car il permet à la machine de réguler la dose de radiations administrée au patient.

[@bebert0712]

En effet, vraiment un enchainement malheureux. :( Merci pour les précisions. @@meca-tronic1857

[@jeantalbot4182]

A quand une video sur la thermographie médicale ,tres peut connue en France je reside à Chypre depuis des années un institut de recherche médicale en est équipé, cela détecte des problèmes que même l'échographie et scanner ne vois pas , en 2020 grâce à la thermographie découverte de caculs dans l'estomac.

[@brunofocant2481]

c'est une chaine d'informatique, pas une chaine médicale 😅

[@paullanglois5908]

En France à Epinal dans les années 2000 il y a eu une grave série de sur-irradiation liée à : une erreur d'unité de mesure. Je ne connais pas précisément les détails mais en gros la machine utilisait une unité avec des pouces au carré (car de conception anglosaxonne) alors que les opérateurs indiquaient les valeurs en cm carré ... Je crains que du fin fond de mes souvenirs cela est était fatal à un patient au moins. Ps : le pb venait peut-être mm d un bug entre rad et gray Ps2 : après verif wiki ce sont 5 victimes et la cause est "une erreur de programmation dans le système de planification de traitement" ce qui me semble extrêmement vague

[@roc-simulateurs7917]

Pour etre proche (meme tres proche) de cette malheureuse histoire, les victimes se comptent par centaines....

[@FrenchPopularizer]

Dommage de ne pas dire que ça arrive aussi en France….peur de la mauvaise pub pour la ville d’Epinal ? 🤡 Je pense que les gens sont assez intelligent pour faire la part des choses !

[@bongibault_nathan]

Super intéressant a chaque fois

[@Gabrios]

Très beau travail merci

[@johnkingsize]

La machine n'implique pas un aimant mais une plaque de tungstène. La machine envoie des éléctrons quelque soit le réglage, il ne s'agit donc pas d'un canon à éléctron et à rayons X combinés dans la même machine, simplement d'une machine capable de changer de rayonnement en plaçant ou en déplaçant une plaque de tungstène sous les électrons, sa présence permettant de générer un rayonnement X à partir du rayonnement d'électrons. C'est donc bien un faisceau d'électrons que les patients ont subi durant les incidents. Le problème ne venait pas du type de rayon mais de la quantité. En effet, l'irradiation du rayon X produit par l'influence du tungstène ne correspond qu'à une très faible fraction de l'irradiation que le faisceau d'électrons à la source provoquerait. Un faisceau d'électrons qui provoquerait 150 rad produit donc un rayonnement X bien en dessous de 150 rad de potentiel, et il faut donc intensifier le faisceau d'électrons en conséquence. C'est pour cette raison que les patients ont reçu des doses léthales de radiations : sans la présence de cette plaque de tungstène, c'est tout le faisceau d'électrons qu'ils ont reçu, et pas le rayon X issu d'une fraction de son énergie. En ce qui concerne les efforts du fournisseur pour vérifier la sécurité du produit, ils ont bien effectué des tests, y compris après l'apparition des incidents. Toutefois, ces tests ont été peu nombreux et aucun opérateur du fournisseur n'a passé assez de temps à tester la machine pour acquérir les habitudes nécessaires à effectuer des manipulations au dessous du temps de changement de mode.

[@DavidAlain]

...la majorité pensent qu'aujourd'hui cela n'existe plus... (Fin de l'histoire désormais la censure existe...et les menaces qui vont avec...).

[@NicolasGin]

Des trucs aussi gros, c'est quand même beaucoup plus rare, en tout cas en Europe

[@meca-tronic1857]

Il y a encore eu des incidents et il y en aura encore. Plus des aussi graves car le design des machines modernes permet d’éliminer tout risque que cela se reproduise. Mais il reste le facteur humain… Tout cela est documenté publiquement au même titre que les incidents en aviation. Ça n’a aucun intérêt à être censuré.

[@legpetruchka2124]

génialissime émission merci à vous trois.

[@philipperaybaudi9546]

HORRIBLE !!! J'étais ingénieur biomédical en milieu hospitalier à cette époque (années 80) et je confirme que la sécurité des patients pouvaient être mise en jeu par l'intervention de prestataires extérieurs (électroniciens, informaticiens, etc.), ou de personnel en interne non formé... dont personne ne vérifiait les compétences, capacités ou diplômes. Et je confirme également que le gamin de tel ou tel chirurgien, chef de service, administrateur ou autres pouvaient parfaitement être appelé à la rescousse pour peu qu'il programmait correctement sur son Thomson To7 ou sur son Amiga... et même si le dit gamin avait 12 ans.

[@Blastdoor]

Ça fait plaisir que Tiffany soit revenue, elle a toujours des interventions de qualité 👍👍

[@verslavenir9990]

Elle est snobée par tout le monde. Les geek sont machistes j'ai l'impression

[@Blastdoor]

@@verslavenir9990 comment ça ? J’ai pas vraiment fait attention car j’écoute surtout les vidéos sans les regarder

[@verslavenir9990]

@@Blastdoor j'ai pas fais attention spécialement dans cette vidéo. Mais ça fait des mois que je me dis qu'ils sont dans un total manque de respect envers elle, les mecs ne se regardent dans les yeux qu'entre eux, elle est la au milieu a tenter d'attirer l'attention pour qu'on la fasse participer. C'est une fille qui a l'air intelligente et qui a un très grand courage pour venir se faire mal traiter systématiquement juste pour faire une présence féminine pour micode. Elle mérite le respect! Je précise 2 points: - je suis un mec - je suis contre le feministe

[@pvs31]

C'était la préhistoire de l'informatique... D'une façon générale si il y a du logiciel il y a du bug, même maintenant. Alors dès que c'est un peu sensible comme dans ce cas, il faut bétonner.

[@vrocher93]

à 11:59 "le petit ordinateur", ça s'appelait un terminal (passif)

[@JLebas]

Entièrement contrôlé par logiciel. Ca fait penser à des avions qui se sont écrasés.

[@YounasF]

Est ce que ce serait possible de faire un sujet sur la peur autour du bug de l'an 2000?

[@LudovicEv]

En vrai ce but est plutôt facile à comprendre au début de l'informatique à cause du manque d'espace et memoire les dates étaient programmée sur deux chiffre à la place d'avoir 1985 on avais simplement 85. En programmation on réalise beaucoup de vérification type Si ageUtilisateur > ageMajorite Faire y Sauf qu'avec le passage à l'an 2000 la nouvelle date de l'année aurai été 00 donc aurai foutu pas mal le bordel dans pas mal de code avec des effets non désiré. Ce bug n'a pas eu le cataclysme annoncé car de nombreux programmeur ont travailler pour remettre toutes les années sur 4 chiffres. J'espère que mes explications sont suffisamment claires. Bonne journée.

[@YounasF]

@@LudovicEv merci bcp c'est tout con en fait mdrrr

[@ScalinoCorleone]

l'erreur est essentiellement humaine, c'est celle de l'opérateur d'abord, mais surtout c'est la faute des formateurs. Les opérateurs n'ont pas reçu la formation adéquate (on en est toujours là aujourd'hui, malgré les couches et les couches d'abstraction logicielle entre les programmeurs et l'assembleur, voire même à cause de ces couches). Le fait que la machine ne traite pas les entrées claviers pendant 8 secondes après une sélection de mode, ça AURAIT DÛ être expliqué dans la première demie-journée de formation à TOUS les opérateurs autorisés (les processeurs à l'époque ne pouvaient vraisemblablement pas gérer ce genre de limitations intrinsèques).

[@exelsisdeii]

Haaa, le Therac-25... Je recommande la vidéo de Plainly Difficult a ce sujet, elle est top!

[@ericv-kj3du]

Sur l'erreur maintenant: Dans ces années là, les langages utilisés étaient largement procéduraux, ce qui réduisait les accès concurrentiels (mais ne les rendaient pas impossibles, sinon ces drames ne seraient jamais arrivé). Ce sont les langages orientés objet (eux-mêmes une réponse à la complexité croissante des logiciels) qui ont fait exploser les échanges entre les objets et qui ont augmenté le nombre d'erreurs d'accès concurrentiels. En conséquence, un développeur moderne a acquis en la matière des réflexes que les développeurs des années 1980 n'avaient pas. Le développement en assembleur était par ailleurs compliqué à relire, corriger et valider par d'autres développeurs Je m'interroge aussi sur la qualification de développeur "amateur" pour la personne ayant produit le code. Il a forcément été rémunéré et est donc bien un professionnel. Alors c'est aussi une personne qui a dû se former sur le tas. On se demande toujours qui de l'œuf ou de la poule a été le premier, mais entre les écoles de développement et les développeurs, c'est bel et bien les développeurs qui sont arrivés en premier, de 2 bonnes décennies. J'imagine donc que par "développeur amateur", on doit comprendre "développeur autodidacte" Encore récemment, j'ai vu du code généré par un développeur "amateur" (ie un employé "recyclé") et évidemment, les principes de bases du développement n'étaient pas respectés.

[@user-sg5ih6vc3v]

4 ans et 52 jours après le 5 septembre 2019: Meillant va t'embaucher, non je rigole 🤣🤣🤣🤣

[@labstral]

Bon sang mais cette chaîne est juste exceptionnelle ❤️

[@Real_Claudy_Focan]

Gros bug qui coutent cher ?? La fusée N-1 sovietique et la première Ariane 5 !!

[@tade769]

Il y a 8 mois j'ai fini 33 séances tomographie + chimio et pour l'instant peux aller..., fameux tomographe coûte environ 1.500.000 € et assez vite remboursé , un séance dure envirant 8-10' et coute SS 1000 € (en totale on m'a envoyer 70 Gy )... 😜

[@philippenachtergal6077]

1:14 Plus précisement, la radio thérapie tue des cellules. Puis tu vises pour que ce soit les cancéreuses... Sauf que, ce que tu envoies (rayon x, neutron ou protons selon les cas) a un profil d'émission. Si tu envoies du rayon X (photons à haute énergie) vers une tumeur, tout ce qui se trouve entre ta tumeur et ta nozzle (l'embout d'émission) se prend encore plus de radiations que la tumeur elle-même. Et ce qui se trouve derrière s'en prend moins mais pas mal quand-même. D'où un des intérêts d'avoir un truc ultra précis qui peut tourner pour envoyez le bousin, comme-ça c'est pas toujours les même cellules saines entre ta peau et la tumeur qui morflent : tu attaques par différents angles. Pas par tous les angles non-plus parce que tu as des trucs qui posent plus de problèmes que d'autres si tu y tues les cellules saines (comme la moelle épinière, les yeux et le cerveau si je me souviens bien). Pour le protons, tu as le pic de bragg qui fait que les tissus avant la zone ciblée se prennent beaucoup moins d'énergie que la cible. Mais cà demande un cyclotron donc c'est bien plus cher. Puis l'embout est lourd du coup la gantry pour faire tourner aussi doit être super grosse et lourde pour pouvoir être précise donc si tu veux un truc qui tourne, c'est très cher. Et sauf pour quelques applications comme le cancer des yeux, tu veux un truc qui tourne. Ceci dit, tu peux connecter un seul cyclotron à plusieurs salles (mais très proches hein, tu déssert pas plusieurs hopitaux).

[@violettabicycletta331]

Tres rigolo le sujet ! Quand on pense que certains on perdu la vie!.

[@AlighieriD4nte]

Super intéressant en tout cas !

[@thorsketil]

Vous vous rendez pas compte de la merde qu'on subit en embarqué. Vous devez jouer avec le HW qui n'est pas toujours opti avec du SW qui l'est encore moins. Y'a énormément de règles mise en place pour faire du code "safe" mais jamais de risque 0...

[@AlphonzTheMagnanimous]

Aujourd'hui le dispositif médical est un domaine industriel très reglementé. Par exemple en UE on est aujourd'hui obligés de se conformer à l'ISO 14971 qui nous oblige à mener une analyse de risques selon un processus bien établi. Tous les fabricants de DM sont régulièrement audités par un organisme notifié, en particulier sur leur gestion du risque patient.

[@DavidAlain]

...tu parles ! Dans les textes et sur le papier OUI... sur le terrain s'est une autre histoire...

[@Wolf-if1bt]

En théorie, oui. Cela n'a pas empêché les surirradiés d'Epinal : fr.wikipedia.org/wiki/Affaire_des_surirradi%C3%A9s_de_l%27h%C3%B4pital_d%27%C3%89pinal?wprov=sfla1

[@jacquesfret1628]

@@DavidAlain Non, c'est factuel, ce qui n'empêche pas les erreurs, les bugs et les gens malhonnêtes, un peu de recul, à moins que vous ne préféreriez l'époque ou la médecine consistait à vous vider de votre sang !

[@derrienjerome5245]

@@Wolf-if1bt Epinal c'était une erreur humaine, ou plutôt une suite d'erreurs. En 40 ans même s'il peut y avoir encore des failles, le domaine à quand même sacrément évolué.

[@dooday1]

Ce qui est choquant c'est que les symptômes sont clairement ceux d'une irradiation. La personne ayant été dans une machine capable d'envoyer des rayons X c'est un peu étonnant de n'avoir rien conclus.

[@abdelben2800]

il y a eu beaucoup de scandales liés aux problèmes de calibrage dont les surirradiés de l'hôpital d'Épinal en France dans les années 2000 le vrai bug c'est la radiothérapie elle même ! en 1910 on a livré 2 machines à William Coley (chirurgien orthopédiste) en prétextant que son immunothérapie était inefficace il a conclu après quelques années que la radiothérapie était beaucoup moins efficace...Quand l'égo dépasse la réalité c'est un autre débat ! Plus d'un siècle après en 2023 des chercheurs de la Harvard Medical School ont découvert que les fameuses toxines du Dr Coley jouaient un rôle capital dans le traitement des cancers et des maladies auto-immunes 120 années d'aveuglement

[@futildelalicorne]

Qd tu laisses un ingé dans la nature : à un autre niveau, TPferro, la ligne à grande vitesse entre paris et barcelone, 600M€ de trou dans le budget, pourquoi : ils se sont rendu compte, à l'entrée du tunnel côté france ET au moment de la pose des rails , que l'écartement était pas le même entre les trains FR et SP (1.668 mm vs 1901 mm) (Et pour les haters, je le sais d'autant plus que c'est moi qui ait évalué ce montant)

[@laurenttoselli4808]

Pas de test... c'est juste magnifique... personne ne s'est dit tiens si on essaye pour voir si... non personne... une fois fait bon ben on le vend... allez

[@shammash1124]

les reufs le son est en retard sur l'image, après j'ai kiffé la vidéo quand même

[@clement2536]

Merci pour votre vidéo

[@jeanehachette505]

Souvenez vous aussi du scandale des surirradiés d'Epinal dans les Vosges ?😢De toute façon les rayons, quoiqu'ils vous disent🙄; même ciblés, touchent plus ou moins des centres vitaux ...😨🤔🤨 Bénédictus et gracias 🙏💖

[@jean-lucchaudon1386]

Les études de Safety existent depuis, qui aurait permis d'identifier les cas de pannes pouvant conduire à des accidents graves et de rendre ces cas presque improbable... 40 ans nous sépare de cette histoire...

[@wysiwiew6195]

C'est l'histoire de l'évolution ... Mais on pourrait aussi les cumuler dans le monde de l'aviation ... De là à dire que le monde à bien changé aujourd'hui ... il y a une marge, voir la page entière !

[@warheaven999]

"le monde à bien changé".. Bah non, Krosoft nous sort des OS plein de bugs depuis des décennies et on accepte le patch hebdomadaire... Par chance, c'est moins critique...

[@juanromano-chucalescu2858]

Ça n'a rien à voir

[@NicolasGin]

Hum, vu la sécurité des hôpitaux et de toutes les infrastructures en jeu, c'est quand même critique, beaucoup de vulnérabilités (l'ANSSI les reporte souvent par exemple). (le moins critique était peut-être du 2nd degré mais je précise dans le doute)

[@derrienjerome5245]

@@NicolasGinD'autant que les softs des machines actuelles fonctionnent sous ... Windows!!

[@dduncane]

ahahahah ça me rappel le plot du premier Jurassic Park

[@tanteparodie573]

Sa arrive encore si ce n'est pas un bug ces des problème de configuration voir les surirradiés de l'hôpital d'Épinal ou de Toulouse

[@user-fb3mg5gn2j]

un couteau est un couteau, une cuillère est une cuillère. le bug n'a pas commencé au moment où le programme a été codé, le bug est initié au moment où les ingénieurs d'AECL ont décidé de faire un scanner multifonction. COURAGE A LA PALESTINE

[@michi4056]

13:09 wow trop belle Tiff

[@Floweed420]

pas besoin d’être médecin pour connaître la radiothérapie 😂😂😅😅😅 sa me tue ses pas les médecins qui l’ont créé la machine 😂😂😂😂😂😂 merci les ingénieurs et physiciens 😌😌🙏🏼🙏🏼

[@lillyco1366]

Bonsoir Désolée pour les 5 décès je trouve qu'ils ont eu du "bol" qu'il ni en ai pas beaucoup plus 👍🏼merci pour la vidéo

[@liwil9624]

Le patch ressemble beaucoup à ce que proposait Lockheed Martin il y a un an ou deux pour son canon qui abîmait la cellule de F-35 : recommandation de ne pas utiliser le canon de l'appareil

[@manolo7660]

🎯 Key Takeaways for quick navigation: 00:00 🚑 The video discusses a critical software bug in a medical device that caused six accidents, five of which were fatal. 00:29 📅 The machine in question, Terraac 25, was designed in 1982 to perform both X-ray and electron radiotherapy, which was an innovative combination at the time. 01:13 🏥 Terraac 25's unique feature was its ability to perform two types of radiotherapy in one machine, making it more cost-effective and convenient for hospitals. 02:22 💻 The machine was entirely controlled by software, a significant advancement in 1982. 02:36 🩺 On March 21, 1986, a patient named Ray Cox received radiotherapy, but due to an operator error, the wrong mode was selected, leading to a critical incident. 06:42 ⚠️ Less than a month later, another tragic incident occurred with the same machine, resulting in the death of a patient with head issues. 07:37 🐛 The root cause of the incidents was a software bug related to a concurrency issue in the code, causing a critical failure in the machine's operation. 09:25 🧠 The video raises questions about the lack of safeguards in place for a machine with such critical implications for human life and the decision to rely solely on software control. 12:27 🧑‍💻 The programmer who coded the critical software bug was a lone amateur, not a team ofhighly skilled engineers. 13:09 🧪 The testing process for the software was insufficient, with only 2700 hours of production tests on real patients, rather than rigorous pre-production testing. 13:51 ☑️ Code from previous machines was reused without proper regression testing to ensure compatibility with the new machine. 14:03 ☢️ The patient, Ray Cox, received a dose hundreds of times higher than the most exposed workers at Chernobyl and Fukushima, leading to his tragic death. 14:56 📚 The incident became a case study in software security, highlighting the need for rigorous standards in critical systems development. Made with HARPA AI

[@ymc9694]

😵😵‍💫😵‍💫😵‍💫😵‍💫

[@maskitoad]

your goofy ahh ai didnt even write therac correctly lmao

[@radosawpawlak8802]

J’ai du passer un IRM du rachis dans un hôpital , pendant l’examen qui doit durer 20 min je ressens des brûlures au niveau des poignets et des épaules . Réponse de la technicienne qui m’a mis sur le Q ! C’est à cause de vos tatouages l’encre doit contenir des particules métalliques ! Alors avec le nombre d’IRM que j’ai passé ça ne met jamais arrivé et je n’ai jamais entendu une personne tatoué avoir eue la même expérience !

[@Thierry-qd5we]

J’ai vécu un peu la même chose car l’ IRM était neuf et pas totalement paramétré ! De plus j’ ai du matériel en titane dans le corps mais je n’ ai rien ressentie à ce niveau !

[@angetassou166]

Moi-même à l'intérieur de l'irm à l'hopital européen pour un examen au bout de 7/8 mn après le début, l'appareil stoppe, deux trois minutes après l'assistance viens bouger les cables au dessus de ma tête en me disant "il est en encore en panne , mais il va redémarrer " et me laisse à l'intérieur" 3/4 mn plus tard sans redémarrage, voyant entre mes pieds la salle de contrôle les opératrices énervées, contrariées , j'ai finis par sonner pour sortir de l'appareil. Je me suis fait dire de tout "et bien Monsieur, vous avez la chance d'avoir un irm et vous êtes impatient!?, tant pis pour vous!" depuis cela fais deux ans, j'avais besoin d'en passer un tout les ans, cela à du être transmis au médecin et depuis il ne me prescrit plus que des échographies... Ah j'oubliais casque sur la tête régler à fond ! les tympans vibrent et sont douloureux à chaque parole , personne ne peut régler le son???? Bref, plus d'irm.

[@raccoun2436]

Les irm n’ont rien à voir avec les systèmes de radiographie et n’oppose absolument pas le même risque

[@angetassou166]

question de situation: un appareil à ce prix-la avec un entretien approximatif , la technicienne m'a dit "c'est un appareil mécanique ,sa tombe en panne! A ce que je lui ai répondu " heureusement que ce n'est pas un hélico", puis la froideur de l'intervenante c'était le matin elle en avait déjà marre de bosser, de plus le son était a fond dans le casque à en souffrir, Bref artisan retraité ayant cotisé toute ma vie traité "sois content et ferme-là!" totalement inadmissible, sérieux!@@raccoun2436

[@Wolf-if1bt]

Des logs auraient probablement permis d'identifier le problème après la première victime.

[@meca-tronic1857]

C’est clair. Aujourd’hui sur ce type de machine, plusieurs GO de logs sont générés chaque jour. On peut analyser de façon très détaillée toutes les erreurs générées, tous les déplacements mécaniques, tensions, courants, doses, actions des opérateurs etc… Toutes les 10 millisecondes chaque action et mesure sont capturés.

[@mathieubois1768]

quels logs ? on est au début des années 1980, les ordinateurs avaient très très peu de mémoire et de stockage, la programmation était en assembleur pour être compact et efficace en termes d'occupation mémoire et de rapidité d'exécution, ça n'a rien à voir avec ce que vous connaissez aujourd'hui, c'est d'ailleurs ce que je reproche à leur vidéo avec leurs petits rires moqueurs : ils ne se rendent pas compte

[@jeanlovephoto7572]

Pour parler un peu cancer. À une époque je programmais des petits logiciels de gestion et j'avais un délai. Pour imager je considérais mon outil comme une sphère parfaite. Tout dedans et rien dehors. Mais le(s) patrons me disaient au dernier moment "il nous faudrait aussi telle information". Résultat une petite bulle qui de greffe sur ma sphère parfaite et qui peut provoquer un cancer. Si cela se trouve, c'est ce qui est arrivé au programmeur dans ce cas. En automobile c'est pire avec les options possibles et qui sont impossibles à tester toutes. Merci et bon courage

[@jeanlovephoto7572]

J'ai eu aussi le même problème. Une sphère parfaite puis des ajouts non prévus au départ. Je comparais ça à des petits cancers. Exemple très bien dit sur les options automobiles. Les bugs générés peuvent être mortels.

[@ordinosaurs]

2:23 "C'est contrôlé par cet ordinateur..." Image : un terminal passif DEC VT100. Dead 11:53 "pdp/11"... Aaahhh enfin on y est ! 11.57 ..."le petit ordinateur à côté"... OMG /smh

[@skorpion7319]

La pire erreur de l histoire c est de laisser wargaming faire eux même leur matchmaking ! Après presque 15 ils n en sont toujours pas capables et pire ils arrivent à toujours faire pire !

[@tuberroot1112]

L'erreur est de mettre en action le réglage de la machine avant que tous les paramétrés soient renseignés. Et pourquoi en assembleur? Ce n'est pas une missile balistique, c'est une machine lente avec interface manuel. Le language C était écrit dans les années 70 et était disponible sur le PDP11.

[@chrismoto6974]

Euh Tiffany avec un patronyme pareil surtout ne vas pas tester la machine stp ! 🤣🤣