10 bugs informatiques qui ont tué, crashé et coûté des milliards (et ce qu'ils m'ont appris)

Pourquoi j’ai écrit 10 articles sur des bugs catastrophiques

Quand j’ai lancé ce blog, je cherchais un moyen de parler de qualité de code sans sonner comme un manuel scolaire. Puis j’ai découvert l’histoire du missile Patriot. 28 soldats morts à cause d’un arrondi de virgule flottante. J’ai eu envie de comprendre comment une erreur aussi simple pouvait tuer.

Un article en a appelé un autre. Puis un troisième. J’en suis à dix. Chaque bug que j’ai décortiqué m’a fait réaliser un truc que je faisais mal dans mes propres projets. Ces histoires ne sont pas juste des anecdotes pour briller en soirée. Ce sont des post-mortems gratuits, écrits avec du sang et des milliards de dollars.

Voici les dix, dans l’ordre chronologique.

1. Therac-25 : la machine qui irradiait ses patients (1985-1987)

Entre juin 1985 et janvier 1987, un appareil de radiothérapie a massivement surdosé six patients, d’après l’enquête de Nancy Leveson et Clark Turner publiée dans IEEE Computer. Quatre en sont morts. Une dose thérapeutique tourne autour de 200 rads, ils en ont reçu jusqu’à cent fois plus en une fraction de seconde.

La cause : deux tâches concurrentes écrivaient dans la même structure partagée de deux octets, sans aucune vérification de cohérence entre elles. Sur une séquence de saisie rapide, la tourelle porte-filtre se retrouvait dans une position et les paramètres du faisceau dans une autre. La machine tirait à pleine énergie, filtre atténuateur hors du chemin.

Le fabricant a d’abord nié. Quand la machine détectait l’anomalie, elle affichait Malfunction 54, un code qui ne distinguait pas une dose trop élevée d’une dose trop faible. Les opérateurs avaient pris l’habitude de relancer.

La leçon : un logiciel qui contrôle du matériel physique ne peut pas être testé comme une app web. Et des messages d’erreur que personne ne comprend, c’est la même chose que pas de message du tout.

→ Lire l’article complet sur le Therac-25

2. Le missile Patriot : 28 morts pour un arrondi (1991)

Le 25 février 1991, un missile Scud irakien frappe une caserne américaine à Dhahran. Le système Patriot, censé l’intercepter, regarde au mauvais endroit dans le ciel. La batterie tournait sans redémarrage depuis plus de 100 heures. À chaque dixième de seconde, le compteur accumulait une erreur de troncature de 95 nanosecondes, parce que 0,1 n’a pas de représentation exacte en binaire. Après 100 heures, la dérive atteint 0,3433 seconde, soit 575 mètres pour un Scud à 1 676 mètres par seconde.

Le chiffre qui compte n’est pas celui-là. Après une heure de fonctionnement, la dérive vaut six mètres. Une recette de quelques heures ne voit strictement rien.

La leçon : 0.1 + 0.2 != 0.3 en Python. Ce n’est pas une curiosité de langage. C’est le même type d’erreur qui a tué 28 personnes.

→ Lire l’article complet sur le bug du missile Patriot

3. London Ambulance Service : le jour où la prod était le seul environnement de test (1992)

En octobre 1992, le nouveau système de dispatch du London Ambulance Service s’effondre le jour de sa mise en production. Les ambulances partent aux mauvaises adresses, les doublons s’empilent, les appels se perdent. Le système n’avait jamais été confronté à la charge réelle de 2 500 appels quotidiens. Pas de staging équivalent à la production, pas de plan de rollback, et des opérateurs qui découvrent le logiciel en même temps que les patients.

Tu liras partout un bilan de 20 à 46 morts. Il vient de la presse britannique de l’époque, pas de l’enquête officielle, qui n’a pas établi de lien de causalité entre la défaillance et des décès. Ce n’est pas la même chose que dire qu’il n’y en a pas eu : sur des patients en urgence vitale, un tel lien est presque impossible à établir, et l’enquête ne l’a pas fait.

La leçon : un environnement de staging n’est pas un luxe. C’est la dernière ligne de défense avant que tes utilisateurs deviennent tes testeurs.

→ Lire l’article complet sur le désastre LAS 1992

4. Ariane 5 : dix ans de programme détruits en 37 secondes (1996)

Le 4 juin 1996, la fusée Ariane 5 explose 37 secondes après le décollage. Une valeur de vitesse horizontale, stockée en flottant 64 bits, est convertie en entier signé 16 bits. Elle dépasse 32 767. Overflow. Le calculateur de bord interprète le message de diagnostic comme des données de vol, braque les tuyères à fond, et la fusée part en morceaux, d’après le rapport de la commission d’enquête.

Le pire détail : la variable qui a débordé servait à un alignement inertiel qui n’avait plus aucune utilité une fois la fusée en vol. Elle tournait encore parce que le code venait d’Ariane 4, qui décollait moins vite et ne franchissait jamais la limite. Personne n’avait revérifié l’hypothèse.

Sur le coût, ni le rapport d’enquête ni l’ESA ne publient de montant. Le chiffre de 370 millions de dollars qu’on lit partout est une estimation de presse qui additionne le lanceur et les quatre satellites Cluster.

La leçon : réutiliser du code d’un ancien projet sans vérifier les hypothèses d’origine, c’est planter une bombe à retardement dans ton système.

→ Lire l’article complet sur le bug Ariane 5

5. Le bug Y2K : la facture que personne ne sait vraiment chiffrer (1999)

Pendant des décennies, les développeurs ont stocké les années sur deux chiffres pour économiser de la mémoire. « 99 » pour 1999. Le problème : « 00 » pouvait signifier 1900 ou 2000. À l’approche du 1er janvier 2000, personne ne savait quels systèmes allaient confondre les deux. Banques, centrales nucléaires, systèmes de défense, hôpitaux. Tout était potentiellement touché.

Les 300 milliards de dollars qu’on lit partout n’ont pas d’origine traçable. La facture se lit à trois échelles, et leur solidité décroît. Les 24 principales agences fédérales américaines : 8,7 milliards de dollars en mai 1999, suivis trimestre par trimestre par le Government Accountability Office. Les États-Unis entiers : de l’ordre de 100 milliards sur 1995-2001 selon le Department of Commerce, qui prend soin d’écrire lui même qu’il s’agit d’estimations conservatrices et non d’une mesure. Le monde : aucun chiffre dont la méthode soit publiée.

Le passage s’est fait sans catastrophe majeure. Pas parce que le risque était imaginaire, mais parce que les corrections ont fonctionné.

La leçon : la dette technique ne se manifeste pas progressivement. Elle attend le pire moment possible pour exploser.

→ Lire l’article complet sur le bug Y2K

6. La panne de 2003 : 50 millions de personnes dans le noir (2003)

Le 14 août 2003 à 16h06, le nord-est des États-Unis et l’Ontario perdent l’électricité. Le rapport final de la task force américano-canadienne chiffre l’événement à environ 50 millions de personnes et 61 800 MW de charge perdue, sur huit États et une province.

La cascade a commencé par une race condition dans le système d’alarme de FirstEnergy, en Ohio. L’alarme n’a pas planté bruyamment : elle s’est tue. Les opérateurs voyaient un réseau stable pendant que des lignes tombaient les unes après les autres. La task force ne retient d’ailleurs pas le bug comme cause principale, mais la perte de conscience de la situation qu’il a rendue possible.

La leçon : un système de monitoring qui ne monitore plus et qui n’alerte pas qu’il ne monitore plus, c’est pire que pas de monitoring du tout. Tu crois que tout va bien. C’est le scénario le plus dangereux.

→ Lire l’article complet sur la panne électrique de 2003

7. Corrupted Blood : le bug de WoW qui a prédit une vraie pandémie (2005)

En septembre 2005, un bug dans World of Warcraft propage un sort contagieux en dehors de la zone prévue. Le sort se transmet de joueur à joueur. Les personnages de bas niveau meurent instantanément. Les grandes villes du jeu se transforment en charniers. Les joueurs fuient vers les zones reculées. Certains personnages à haute résistance continuent à se promener sans symptômes, contaminant tout le monde autour d’eux.

Deux publications de 2007 ont fait entrer l’incident dans la littérature scientifique, dont celle de Ran Balicer dans la revue Epidemiology. Ce que les chercheurs y ont trouvé, ce ne sont pas des courbes : ce sont des comportements humains que leurs modèles prédisaient sans jamais avoir pu les observer. La fuite, l’altruisme des soignants qui reviennent vers la zone infectée, et le sous-groupe qui entre délibérément dans la contamination malgré les avertissements.

La leçon : un bug ne reste jamais contenu dans le périmètre prévu. Si un état peut se propager, il se propagera.

→ Lire l’article complet sur le Corrupted Blood

8. Le hack de la Jeep Cherokee : prise de contrôle à 110 km/h (2015)

En 2015, deux chercheurs en sécurité prennent le contrôle à distance d’une Jeep Cherokee lancée sur autoroute, depuis un ordinateur portable à des kilomètres de là. Ils coupent la transmission, actionnent les freins, manipulent l’essuie-glace et la radio. Le point d’entrée n’est pas le Bluetooth : c’est le système d’infodivertissement Uconnect, qui exposait un port D-Bus sans authentification sur le réseau cellulaire Sprint, avec une adresse IP joignable depuis internet.

Le problème fondamental : le réseau multimédia et le réseau de contrôle moteur n’étaient pas isolés l’un de l’autre. Chrysler a rappelé 1 416 903 véhicules dix jours après la publication, campagne 15V461 de la NHTSA, premier rappel automobile de l’histoire déclenché par une faille de cybersécurité. Le correctif est parti par la poste, sur clé USB.

La leçon : la surface d’attaque ne se mesure pas à ce que tu exposes volontairement. Elle se mesure à tout ce qui est connecté, directement ou indirectement, à l’extérieur.

→ Lire l’article complet sur le hack Chrysler

9. CrowdStrike : 8,5 millions de machines en écran bleu (2024)

Le 19 juillet 2024, une mise à jour de contenu de l’agent CrowdStrike Falcon fait planter 8,5 millions de machines Windows dans le monde, moins de 1% du parc selon Microsoft. Compagnies aériennes clouées au sol, hôpitaux en mode dégradé, banques inaccessibles.

Le fichier n’était pas « corrompu », contrairement à ce qu’on a beaucoup lu. D’après l’analyse de cause racine publiée par CrowdStrike, le type de template définissait 21 paramètres d’entrée quand le code du capteur n’en fournissait que 20. Tant que le 21e restait un joker, rien ne cassait. Le 19 juillet, une instance a introduit un critère non joker sur ce 21e champ. Lecture hors limites, crash du driver kernel au démarrage, réparation manuelle machine par machine.

Le décalage avait traversé plusieurs couches de validation et de tests. Et ce contenu de réponse rapide partait vers toute la flotte d’un coup, sans déploiement échelonné.

La leçon : un pipeline CI/CD sans canary release et sans rollback automatique, c’est une arme pointée vers ta propre base d’utilisateurs.

→ Lire l’article complet sur le crash CrowdStrike

10. Les killer typos : quand une lettre manquante déclenche une catastrophe

Ce dernier article ne raconte pas un seul bug mais une collection de désastres déclenchés par un caractère. Une barre de surlignage absente dans la transcription manuscrite d’une formule de guidage, en 1962, a fait réagir Mariner 1 au bruit du signal radar au lieu de le filtrer. Sonde détruite 293 secondes après le lancement. En 2017, un mauvais argument tapé à la main sur une commande de routine a retiré du service bien plus de serveurs S3 que prévu et mis hors ligne une fraction significative du web.

Et un contre-exemple, parce qu’il vaut mieux que les deux autres : le Flash Crash de 2010 n’était pas un typo. L’histoire du trader qui aurait tapé « milliards » au lieu de « millions » a circulé le jour même, avant toute analyse. Le rapport conjoint de la SEC et de la CFTC attribue le déclenchement à un algorithme de vente sans contrainte de prix ni de temps. Quand une panne est spectaculaire, l’explication par l’erreur humaine ponctuelle arrive vite, se retient bien et se corrige mal.

La leçon : les linters et le code review ne sont pas des formalités bureaucratiques. Ce sont les seuls filets qui rattrapent les erreurs que ton cerveau refuse de voir parce qu’il lit ce qu’il s’attend à lire.

→ Lire l’article complet sur les killer typos

Les 4 patterns qui reviennent dans chaque catastrophe

Après avoir écrit ces dix articles, je vois quatre schémas qui se répètent systématiquement.

Le code réutilisé sans vérifier les hypothèses d’origine. Ariane 5 a hérité d’un module d’Ariane 4 sans revalider ses limites. Le bug Y2K venait de conventions des années 60 encore actives 30 ans plus tard. Chaque fois que tu copies du code d’un projet à l’autre, tu importes aussi les conditions dans lesquelles il a été écrit.

L’absence de test en conditions réelles. Le London Ambulance Service, CrowdStrike : même scénario. Le système n’a jamais été confronté à la charge ou aux conditions de la production avant d’y être envoyé. Un test unitaire qui passe ne prouve pas que le système fonctionne. Il prouve qu’une fonction isolée retourne la bonne valeur.

Le monitoring silencieux. La panne de 2003, le Therac-25 : les opérateurs croyaient que tout allait bien parce que le système ne leur disait pas le contraire. Un monitoring qui tombe en panne sans alerter, c’est de la dette technique invisible.

La surface d’attaque sous-estimée. La Jeep Cherokee, le Corrupted Blood de WoW : un système connecté sera attaqué ou perturbé par des vecteurs que ses concepteurs n’avaient pas imaginés. La question n’est pas « est-ce qu’on sera touché » mais « est-ce qu’on a isolé ce qui doit l’être ».

Questions fréquentes

Quel est le bug informatique le plus meurtrier de l’histoire ?

Le Therac-25 et le missile Patriot sont les deux cas les mieux documentés. L’enquête de Leveson et Turner recense six surdosages de radiothérapie entre 1985 et 1987, dont quatre suivis d’un décès. L’erreur d’arrondi du Patriot a coûté la vie à 28 soldats à Dhahran en 1991. Dans les deux cas, le logiciel n’avait rien de malveillant, il était juste mal testé sur ses cas limites.

Combien a coûté le bug de l’an 2000 ?

Personne ne le sait au niveau mondial, et les 300 à 600 milliards de dollars qu’on lit partout n’ont aucune méthodologie publiée. Le seul montant traçable jusqu’à sa source est celui des 24 principales agences fédérales américaines, suivi trimestriellement par le GAO : 8,7 milliards de dollars en mai 1999, contre 2,3 milliards estimés deux ans plus tôt. Le triplement est le fait le plus parlant du dossier.

Ces catastrophes sont-elles encore possibles aujourd’hui ?

Oui. En juillet 2024, CrowdStrike a mis 8,5 millions de machines Windows en écran bleu avec un décalage d’un seul paramètre, poussé vers toute la flotte sans déploiement échelonné. Les langages et les outils ont changé, les quatre patterns de fond n’ont pas bougé.

Pourquoi lire des post-mortems quand on n’écrit pas de logiciel critique ?

Parce que les mécanismes sont les mêmes à toutes les échelles : du code réutilisé sans revérifier ses hypothèses, un environnement de test qui ne ressemble pas à la production, un monitoring muet quand ça casse. Ton SaaS ne tuera personne, mais il perdra des clients pour exactement les mêmes raisons.

Ce que ça change dans ma façon de coder

Je suis autodidacte. J’ai appris à builder avec l’IA et je ship en production, sans être passé par une école d’ingé. Ces dix histoires m’ont rendu paranoïaque, et c’est exactement ce dont j’avais besoin.

Aujourd’hui, avant de réutiliser du code, je relis les commentaires pour comprendre les hypothèses d’origine. Je teste mes déploiements sur un environnement de staging avant de pousser en production. Je vérifie que mes systèmes de monitoring m’alertent quand ils tombent. Et quand Claude ou Gemini me génèrent du code, je le passe dans un linter avant de le merger.

Ce n’est pas de la rigueur de senior dev. C’est du bon sens, extrait de catastrophes qui auraient pu être évitées.

Si tu veux creuser un de ces bugs en détail, chaque article contient l’histoire complète, l’explication technique, et un exemple de code Python pour reproduire ou prévenir l’erreur.

Dernière mise à jour : mai 2026