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 1985 et 1987, un appareil de radiothérapie a surdosé des patients avec des radiations 100 fois supérieures à la normale. Au moins trois personnes sont mortes. La cause : une race condition dans le logiciel de contrôle. Deux processus accédaient à la même variable sans verrouillage, et dans certaines séquences de saisie rapide de l’opérateur, la machine passait en mode haute énergie sans le filtre de protection.

Le fabricant a d’abord nié le problème. Les opérateurs recevaient des messages d’erreur cryptiques qu’ils avaient pris l’habitude d’ignorer.

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. L’horloge interne du système tournait depuis 100 heures. À chaque dixième de seconde, une erreur d’arrondi en virgule flottante s’accumulait. Après 100 heures, le décalage atteignait 0,34 seconde. À la vitesse d’un Scud, ça représente 600 mètres d’erreur.

Les Israéliens avaient signalé le problème deux semaines avant. Le correctif n’était pas encore déployé.

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 : quand la prod crashe et que des gens meurent (1992)

En octobre 1992, le nouveau système informatique du London Ambulance Service crashe le jour de sa mise en production. Les ambulances sont envoyées aux mauvaises adresses, les doublons s’empilent, les appels se perdent. Vingt personnes meurent dans les jours qui suivent.

Le système n’avait jamais été testé en conditions réelles. Pas de staging environment. Pas de plan de rollback. Le jour du lancement, les opérateurs découvrent le logiciel en même temps que les patients.

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 : 370 millions 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 nombre flottant 64 bits, est convertie en entier 16 bits. La valeur dépasse 32 767. Overflow. Le système de navigation reçoit des données absurdes et fait pivoter la fusée. Les boosters se déchirent. Autodestruction.

Le module de navigation provenait d’Ariane 4, où la valeur ne dépassait jamais la limite. Personne n’avait revérifié cette hypothèse pour Ariane 5, qui accélérait plus vite.

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 : 300 milliards pour deux chiffres manquants (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é.

Le monde a dépensé environ 300 milliards de dollars pour auditer et corriger du code legacy avant la date fatidique. 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 : 55 millions d’Américains dans le noir (2003)

Le 14 août 2003, le nord-est des États-Unis et une partie du Canada perdent l’électricité. 55 millions de personnes touchées. La cascade a commencé par un bug logiciel dans le système d’alarme de FirstEnergy, en Ohio. Une race condition empêchait le système de mettre à jour son affichage en temps réel. Les opérateurs voyaient un réseau stable alors que des lignes tombaient les unes après les autres.

Quand ils ont compris ce qui se passait, la surcharge avait déjà atteint un point de non-retour.

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.

Des épidémiologistes ont publié des articles dans des revues scientifiques sur cet événement. Le comportement des joueurs reproduisait les dynamiques observées lors de vraies pandémies.

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 à 100 km/h (2015)

En 2015, deux chercheurs en sécurité prennent le contrôle à distance d’une Jeep Cherokee en mouvement sur autoroute. Ils coupent la transmission, activent les freins, manipulent la direction. Le tout via le système d’infodivertissement Uconnect, connecté en Bluetooth et accessible depuis le réseau cellulaire. 1,4 million de véhicules rappelés.

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.

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 automatique de l’agent CrowdStrike Falcon fait planter 8,5 millions de machines Windows dans le monde. Compagnies aériennes clouées au sol, hôpitaux en mode dégradé, banques inaccessibles. La mise à jour contenait un fichier de configuration mal formé qui provoquait un crash du driver kernel au démarrage. Pas de rollback automatique. Chaque machine devait être réparée manuellement.

Le fichier en question n’avait pas été testé en canary deployment avant le déploiement mondial.

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 causés par des fautes de frappe dans du code. Un trait d’union manquant dans le logiciel de guidage de Mariner 1, en 1962, a détruit la sonde 293 secondes après le décollage. Un opérateur de la Bourse de Tokyo, en 2005, a tapé “vendre 610 000 actions à 1 yen” au lieu de “vendre 1 action à 610 000 yens”. Coût : 225 millions de dollars.

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”.

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

Je ne suis pas ingénieur logiciel. J’ai commencé à coder avec l’IA il y a moins d’un an. 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