Programmation

Quel est le bug informatique le plus coûteux de l'histoire ?

La réponse

Le bug informatique le plus coûteux de l'histoire est probablement l'erreur de conception du système de lancements des fusées Ariane 5 en 1996. Une exception non gérée a provoqué l'explosion de la fusée 37 secondes après son décollage, causant une perte estimée à 370 millions de dollars. Cet incident a souligné l'importance des tests rigoureux en programmation.

En savoir plus

Le 4 juin 1996, le vol 501, premier lancement d’Ariane 5, s’achevait en catastrophe au-dessus du centre spatial de Kourou, en Guyane française. Trente-sept secondes après le décollage, la fusée perdait le contrôle avant d’être détruite, emportant avec elle sa charge utile. La cause n’était pas une défaillance mécanique, mais une erreur dans le logiciel du système de référence inertielle, souvent citée comme l’un des bugs informatiques les plus coûteux de l’histoire. La perte de la fusée et des quatre satellites scientifiques Cluster a été estimée à environ 370 millions de dollars.

Un logiciel réutilisé dans un nouvel environnement

Le logiciel responsable du calcul de la trajectoire avait été développé pour Ariane 4, puis réutilisé sur Ariane 5. Cette réutilisation n’était pas en elle-même anormale, mais les deux lanceurs n’avaient pas exactement le même profil de vol. Au début du vol d’Ariane 5, certaines valeurs évoluaient d’une manière que le programme n’avait pas été conçu pour traiter, notamment une donnée liée à la vitesse horizontale.

Le problème est apparu lors de la conversion d’un nombre à virgule flottante codé sur 64 bits vers un entier signé sur 16 bits. La valeur dépassait la plage que ce dernier pouvait représenter. Cette situation a provoqué une exception logicielle qui n’a pas été correctement gérée. Le programme du système de référence inertielle s’est alors interrompu au lieu de fournir des données de navigation valides.

Une erreur commune à deux systèmes redondants

Ariane 5 disposait de deux systèmes de référence inertielle, l’un actif et l’autre de secours. Cette redondance n’a pas empêché l’accident, car les deux systèmes utilisaient le même logiciel et ont rencontré la même erreur dans des conditions identiques. Le système défaillant a transmis des informations de diagnostic au calculateur de bord, qui les a interprétées comme des données de vol. Les commandes qui en ont résulté ont conduit à une perte de contrôle du lanceur, puis à sa destruction.

L’enquête a montré que la fonction à l’origine de l’exception n’était plus indispensable à ce stade du vol, mais qu’elle était restée active. Surtout, le fait qu’une exception puisse interrompre le fonctionnement du système n’avait pas été suffisamment pris en compte dans la conception et la validation du logiciel. Le défaut ne provenait donc pas d’une simple faute de frappe dans une ligne de code, mais d’une combinaison de choix de conception, d’hypothèses héritées d’Ariane 4 et de tests insuffisamment représentatifs du comportement d’Ariane 5.

Une perte financière et une leçon de programmation

L’échec du vol 501 a détruit la fusée ainsi que les quatre satellites Cluster de l’Agence spatiale européenne, conçus pour étudier l’environnement magnétique terrestre. La valeur de la mission perdue a été estimée à environ 370 millions de dollars, ce qui explique pourquoi cet incident est souvent présenté comme le bug informatique le plus coûteux de l’histoire, même si le classement peut varier selon que l’on comptabilise uniquement les biens détruits ou l’ensemble des conséquences économiques.

L’accident est devenu un cas d’école en ingénierie logicielle. Il rappelle qu’un programme fiable dans un environnement donné ne l’est pas nécessairement dans un autre, qu’une conversion numérique doit être contrôlée et qu’une exception ne peut être ignorée dans un système critique. Il montre également que la redondance matérielle ne suffit pas lorsque les composants de secours reproduisent exactement la même erreur de conception. Des essais menés avec les conditions réelles de vol, une analyse rigoureuse des limites numériques et une gestion explicite des erreurs sont indispensables pour les logiciels dont dépendent la sécurité et la réussite d’une mission.

CultureG.org