Annexe : Quand les erreurs numériques tuent

Les erreurs numériques ne sont pas qu'un sujet académique abstrait. L'histoire de l'informatique est jalonnée de catastrophes causées par des erreurs d'arrondi, des dépassements de capacité ou des conversions de types mal gérées. Cette annexe présente deux cas emblématiques — la défaillance du missile Patriot et l'explosion de la fusée Ariane 5 — ainsi qu'un panorama d'autres incidents notables.

1. Le missile Patriot de Dhahran (1991)

Les faits

Le 25 février 1991, pendant la guerre du Golfe, une batterie de missiles Patriot stationnée à Dhahran (Arabie saoudite) échoue à intercepter un missile Scud irakien. Le Scud frappe une caserne de l'armée américaine, tuant 28 soldats et en blessant une centaine d'autres. C'est la perte humaine la plus importante subie par les forces américaines lors d'une seule attaque pendant l'opération Tempête du désert.

La cause : une erreur d'arrondi sur 1/10

L'enquête du Government Accountability Office (GAO) a établi que la défaillance était due à une erreur de calcul du temps dans l'ordinateur de contrôle du système Patriot.

Le système mesurait le temps écoulé depuis son démarrage en dixièmes de seconde, stockés sous forme d'entier. Pour effectuer les calculs de trajectoire, cette valeur devait être convertie en secondes en la multipliant par 0,1.

Or, le nombre 0,1 n'est pas représentable exactement en binaire :

Le registre du Patriot ne stockait que 24 bits après la virgule, ce qui introduisait une erreur de troncature :

L'accumulation fatale

Cette erreur, infime en apparence, s'accumulait avec le temps. Le tableau suivant, extrait du rapport du GAO, montre la dérive :

Au moment de l'incident, la batterie Alpha fonctionnait depuis plus de 100 heures en continu. L'erreur de temps accumulée était de 0,34 seconde.

Un missile Scud se déplace à environ 1 676 m/s. En 0,34 seconde, il parcourt :

Le Scud se trouvait donc à plus d'un demi-kilomètre de l'endroit où le radar s'attendait à le voir. Il était en dehors de la fenêtre de détection (range gate), fixée à environ 137 m. Le système Patriot n'a tout simplement pas « vu » le missile entrant.

Le calcul de l'erreur

Vérifions le calcul. L'erreur sur la représentation de 0,1 tronquée à 24 bits est :

En 100 heures, le nombre de dixièmes de seconde est :

L'erreur totale accumulée :

Leçons pour l'analyse numérique

1. Les petites erreurs s'accumulent : Une erreur de 10⁻⁷ semble négligeable, mais multipliée par des millions d'itérations, elle devient catastrophique.

2. 0,1 n'est pas représentable en binaire : C'est l'exemple canonique du problème de représentation des fractions décimales.

3. Le contexte d'utilisation compte : Le Patriot avait été conçu pour des engagements mobiles de quelques heures, pas pour une défense statique de plusieurs jours.

Sources

• U.S. General Accounting Office, "Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia", GAO/IMTEC-92-26, 4 février 1992.
• Douglas N. Arnold, "The Patriot Missile Failure", University of Minnesota.

2. L'explosion d'Ariane 5 vol 501 (1996)

Les faits

Le 4 juin 1996, la fusée Ariane 5 effectue son vol inaugural depuis Kourou, en Guyane française. Trente-sept secondes après le décollage, à une altitude d'environ 3 700 mètres, la fusée dévie brutalement de sa trajectoire, se disloque sous les contraintes aérodynamiques et explose. Le système d'autodestruction achève la destruction de l'engin.

La perte est estimée à 370 millions d'euros (coût de la fusée et des quatre satellites scientifiques Cluster qu'elle transportait).

La cause : un dépassement de capacité entière

L'enquête menée par une commission présidée par Jacques-Louis Lions a identifié la cause avec une précision remarquable.

Le système de référence inertielle (SRI), qui fournit les données d'attitude et de trajectoire, effectuait un calcul de « biais horizontal » (variable BH) représentant la vitesse horizontale de la fusée. Cette valeur, stockée en virgule flottante 64 bits, devait être convertie en entier signé 16 bits pour être transmise à l'ordinateur de bord.

Or, la trajectoire d'Ariane 5 générait des vitesses horizontales beaucoup plus élevées que celles d'Ariane 4 (dont le logiciel avait été réutilisé). La valeur de BH a dépassé 32 767, la valeur maximale représentable sur 16 bits signés :

La cascade d'erreurs

La séquence des événements est un cas d'école de défaillance en cascade :

1. T+37 s : La conversion 64 bits → 16 bits échoue (overflow). Le processeur du SRI génère une exception « Operand Error ».

2. Le logiciel du SRI interprète cette exception comme une défaillance matérielle. Conformément à la spécification, il arrête le processeur et envoie un message de diagnostic sur le bus de données.

3. Le SRI de secours (identique au premier) subit exactement la même panne au même moment — les deux systèmes exécutent le même code avec les mêmes données.

4. L'ordinateur de bord reçoit le message de diagnostic (une suite de bits représentant l'adresse mémoire de l'erreur) et l'interprète comme des données de vol valides.

5. Ces « données » aberrantes commandent une correction de trajectoire massive : les tuyères des boosters et du moteur Vulcain pivotent à fond.

6. La fusée effectue un virage de plus de 20°, les forces aérodynamiques dépassent les limites structurelles, les boosters se détachent, le système d'autodestruction s'active.

Pourquoi cette conversion non protégée ?

Le rapport Lions révèle un détail accablant : sur les sept variables susceptibles de provoquer un dépassement lors de la conversion, quatre étaient protégées par une vérification. Les trois autres, dont BH, ne l'étaient pas.

Pourquoi ? Pour respecter une contrainte de charge processeur maximale de 80 %. Les ingénieurs avaient jugé, sur la base de l'expérience d'Ariane 4, que ces trois variables ne pouvaient jamais atteindre des valeurs dangereuses.

Cette hypothèse était correcte pour Ariane 4. Elle était fausse pour Ariane 5, dont le profil de vol différait significativement.

Simulation de l'erreur en Python

import struct

def conversion_64_vers_16(valeur_float64):
  """
  Simule la conversion fatale d'Ariane 5.
  Convertit un float 64 bits en entier signé 16 bits.
  """
  MAX_INT16 = 32767
  MIN_INT16 = -32768

  # Conversion en entier
  valeur_int = int(valeur_float64)

  # Vérification de dépassement (ABSENTE dans le code d'Ariane 5)
  if valeur_int > MAX_INT16 or valeur_int < MIN_INT16:
      raise OverflowError(
          f"OPERAND ERROR: {valeur_int} hors limites [{MIN_INT16}, {MAX_INT16}]"
      )

  return valeur_int

# Test avec des valeurs typiques
print("=== Simulation du bug Ariane 5 ===\n")

vitesses_horizontales = [1000, 10000, 30000, 32767, 32768, 40000]

for v in vitesses_horizontales:
  try:
      resultat = conversion_64_vers_16(float(v))
      print(f"BH = {v:>6} → Conversion OK : {resultat}")
  except OverflowError as e:
      print(f"BH = {v:>6} → ERREUR : {e}")

Leçons pour l'analyse numérique

1. Valider les hypothèses lors de la réutilisation de code : Un code correct dans un contexte peut être dangereux dans un autre.

2. Les dépassements de capacité sont silencieux : Contrairement à une division par zéro, un overflow ne génère pas toujours d'erreur visible.

3. La redondance ne protège pas des erreurs systématiques : Les deux SRI ont échoué simultanément car ils exécutaient le même code défectueux.

4. Le code « mort » peut tuer : Une fonction inutile qui continue à s'exécuter reste une source potentielle d'erreurs.

Sources

• Commission d'enquête Ariane 501, "ARIANE 5 Flight 501 Failure: Report by the Inquiry Board", présidée par J.-L. Lions, 19 juillet 1996.
• Jean-Marc Jézéquel & Bertrand Meyer, "Design by Contract: The Lessons of Ariane", IEEE Computer, janvier 1997.

3. Autres catastrophes numériques célèbres

Le bug FDIV du Pentium (1994)

Incident : Les processeurs Intel Pentium (60-100 MHz) retournaient des résultats de division erronés pour certaines combinaisons de nombres.

Cause : Cinq entrées manquantes dans une table de consultation (lookup table) de 1 066 éléments utilisée par l'algorithme de division SRT.

Exemple :

Conséquence : Rappel de tous les processeurs affectés. Coût pour Intel : 475 millions de dollars.

Source : Thomas R. Nicely, "Original Pentium FDIV flaw e-mail", Lynchburg College, 1994. Voir aussi Wikipedia.

L'indice de la Bourse de Vancouver (1983)

Incident : L'indice boursier de Vancouver, initialisé à 1 000 points en 1982, affichait 524,881 points en novembre 1983, alors que le marché était en hausse.

Cause : L'indice était recalculé après chaque transaction et tronqué (et non arrondi) à trois décimales. Des milliers de troncatures par jour accumulaient une erreur systématique vers le bas.

Correction : Après recalcul avec arrondis corrects, l'indice réel était de 1 098,892 — plus du double de la valeur affichée !

Source : Wikipedia, TU München.

Le vol 501 du Boeing 787 Dreamliner (2015)

Incident : La FAA a émis une directive de navigabilité exigeant le redémarrage périodique des générateurs électriques du Boeing 787.

Cause : Un compteur interne en entier signé 32 bits débordait après exactement 248 jours de fonctionnement continu (2³¹ centièmes de seconde), provoquant une panne électrique totale.

Solution : Redémarrer les générateurs au moins tous les 120 jours.

Source : FAA Airworthiness Directive 2015-09-07, Federal Register, mai 2015.

La sonde Mars Climate Orbiter (1999)

Incident : La sonde de la NASA s'est désintégrée dans l'atmosphère martienne au lieu de se mettre en orbite.

Cause : Une équipe utilisait des unités impériales (livres-force), l'autre des unités métriques (newtons). Les données de poussée n'ont jamais été converties.

Conséquence : Perte de la sonde. Coût : 125 millions de dollars.

Source : NASA Mars Climate Orbiter Mishap Investigation Board, "Phase I Report", novembre 1999.

La plateforme pétrolière Sleipner A (1991)

Incident : La base en béton de la plateforme Sleipner A s'est effondrée lors d'un test de ballastage en Norvège.

Cause : Une erreur dans le maillage des éléments finis (logiciel NASTRAN) a sous-estimé les contraintes de cisaillement de 47 %, conduisant à des murs de béton trop minces.

Conséquence : Perte de la structure (190 millions de dollars). La plateforme reconstruite est en service depuis 1993.

Source : Douglas N. Arnold, "The sinking of the Sleipner A offshore platform", University of Minnesota. Voir aussi Wikipedia.

Le Therac-25 (1985-1987)

Incident : Cette machine de radiothérapie a administré des doses de radiation 100 fois supérieures à la normale, tuant au moins 3 patients et en blessant gravement 3 autres.

Cause : Une condition de course (race condition) dans le logiciel : si l'opérateur modifiait les paramètres trop rapidement, le système pouvait appliquer une dose de haute énergie sans le filtre de sécurité.

Source : Nancy G. Leveson & Clark S. Turner, "An Investigation of the Therac-25 Accidents", IEEE Computer, vol. 26, no. 7, juillet 1993, pp. 18-41.

4. Tableau récapitulatif

Conclusion

Ces incidents démontrent que les erreurs numériques ne sont pas des curiosités théoriques mais des risques concrets aux conséquences potentiellement mortelles. Ils rappellent plusieurs principes fondamentaux :

1. Comprendre les limites de la représentation numérique : Tous les nombres ne sont pas représentables exactement.

2. Valider les hypothèses : Un code correct dans un contexte peut échouer dans un autre.

3. Protéger les conversions de types : Chaque conversion est une source potentielle d'erreur.

4. Tester aux limites : Les erreurs surviennent souvent dans les cas extrêmes non anticipés.

5. La redondance ne suffit pas : Elle protège contre les pannes aléatoires, pas contre les erreurs systématiques.

L'analyse numérique n'est pas qu'une discipline académique — c'est une compétence vitale pour quiconque écrit du code dont dépendent des vies ou des systèmes critiques.