Trente-six virgule sept secondes. C’est le temps qu’il a fallu, le 4 juin 1996 à Kourou, pour que deux calculateurs identiques, censés se couvrir mutuellement en cas de panne, s’arrêtent exactement au même instant. Le vol inaugural d’Ariane 5, désigné vol 501, s’est soldé par un échec, causé par un dysfonctionnement informatique, qui vit la fusée se briser et exploser en vol seulement 36,7 secondes après le décollage. À bord, quatre satellites scientifiques de la mission Cluster de l’Agence spatiale européenne, partis étudier les interactions entre le Soleil et la Terre. Ils ne verront jamais l’espace.

Sommaire

1. Un système redondant censé être infaillible
2. Une conversion de nombre qui fait tout basculer
3. Les deux calculateurs tombent en panne à la même seconde
4. 370 millions de dollars et un rapport devenu référence

Un système redondant censé être infaillible

Sur le papier, l’architecture d’Ariane 5 semblait à toute épreuve. Le lanceur embarquait deux systèmes de référence inertielle (SRI), l’un actif, l’autre en attente, chargés de mesurer l’attitude et la trajectoire de la fusée à partir de gyromètres laser et d’accéléromètres. En cas de défaillance du premier, l’ordinateur de bord devait basculer instantanément sur le second. Un principe classique en aéronautique, où la duplication du matériel protège contre les pannes physiques aléatoires, un composant qui grille, un capteur qui se dérègle.

Le problème, c’est que les deux SRI ne faisaient pas tourner des puces différentes soumises au hasard des défaillances mécaniques. Ils exécutaient le même logiciel, ligne pour ligne. La conception des SRI d’Ariane 5 était pratiquement la même que celle d’un SRI utilisé à bord d’Ariane 4, notamment pour ce qui est du logiciel. Un code jugé fiable, éprouvé sur des dizaines de vols réussis. Mais Ariane 5 n’était pas Ariane 4, elle volait beaucoup plus vite dès les premières secondes, avec une accélération et une trajectoire bien plus verticales.

Une conversion de nombre qui fait tout basculer

À H0+37 secondes, la trajectoire du lanceur était encore parfaitement normale, à une vitesse de Mach 0,7 (857 km/h) et une altitude de 3 500 mètres. C’est précisément à cet instant que le logiciel du SRI a tenté de convertir une valeur de vitesse horizontale, calculée en nombre flottant sur 64 bits, vers un entier signé de 16 bits. Cette valeur, beaucoup plus élevée que ce qu’Ariane 4 avait jamais produit, dépassait largement la capacité du registre cible. L’exception logiciel interne du SRI s’est produite pendant une conversion de données de représentation flottante à 64 bits en valeurs entières à 16 bits.

Le morceau de code fautif ne servait même plus à rien à cet instant du vol. Il s’agissait d’une routine d’alignement de la plateforme inertielle, utile uniquement avant le décollage, mais que les ingénieurs avaient laissée active pendant les cinquante premières secondes de vol pour permettre un redémarrage rapide en cas de compte à rebours interrompu. Normalement le calcul aurait dû s’arrêter à H0-9 secondes, mais en cas d’arrêt du compte à rebours, réinitialiser le SRI pouvait prendre plusieurs heures sur les versions précédentes ; le calcul continuait donc pendant 50 secondes après le début du mode vol, bien après le décollage. Un vestige technique, jugé inoffensif, qui allait précipiter la perte du lanceur.

Les deux calculateurs tombent en panne à la même seconde

Voici le cœur du problème. Puisque les deux SRI faisaient tourner un logiciel strictement identique et recevaient les mêmes données de vol, l’un après l’autre ils ont buté sur la même erreur de conversion, à quelques dizaines de millisecondes d’intervalle. Le système de guidage de secours, identique au système principal, a subi la même avarie et s’est arrêté à la même seconde. L’ordinateur de bord, qui aurait dû basculer sur l’unité de secours dès la panne de l’unité active, s’est retrouvé sans solution : les deux étaient déjà hors service.

Privé de toute donnée d’attitude fiable, le pilote automatique a alors interprété un signal d’erreur comme une véritable donnée de trajectoire. À la suite d’une mauvaise interprétation du signal de panne provenant des deux systèmes de guidage inertiels hors service, le pilote automatique a ordonné par erreur une violente correction de trajectoire : les tuyères des deux accélérateurs à poudre et du moteur central se sont braquées jusqu’en butée, comme pour rattraper une déviation qui n’existait pas. La fusée a alors basculé brutalement hors de son axe de vol. Ce braquage sec a fait tilter le lanceur, générant des charges aérodynamiques intenses qui ont provoqué sa rupture structurelle. Le système d’autodestruction, conçu pour éviter qu’un lanceur incontrôlé ne retombe sur une zone habitée, s’est déclenché quelques secondes plus tard.

370 millions de dollars et un rapport devenu référence

Le bilan financier reste, encore aujourd’hui, l’un des exemples les plus cités dans les écoles d’ingénieurs pour illustrer le coût d’un bug logiciel. Les quatre satellites scientifiques Cluster embarqués valaient environ 370 millions de dollars, entièrement perdus dans l’explosion, sans compter le coût du lanceur lui-même et le retard accumulé sur le programme Ariane 5. Personne n’a été blessé : le pas de tir avait été évacué et les débris sont retombés sur une zone inhabitée de la Guyane.

Une commission d’enquête conjointe ESA/CNES, présidée par le mathématicien Jacques-Louis Lions, a été constituée dans la foulée. Le rapport, rédigé en anglais à Paris, a été remis le 19 juillet 1996, à peine six semaines après l’accident. Il a disséqué chaque milliseconde du vol et pointé une évidence dérangeante pour l’époque : dupliquer un matériel ne protège en rien contre une erreur de conception présente dans le logiciel qu’il exécute. Deux copies parfaites d’un même bug produisent, logiquement, deux pannes parfaitement synchrones.

Cet épisode a profondément changé la manière dont l’industrie spatiale et aéronautique aborde désormais la réutilisation de code entre programmes différents, poussant au développement de méthodes de vérification formelle capables de prouver mathématiquement l’absence de dépassement de capacité avant même le premier vol. Ariane 5, tirée de cet échec initial, a fini par voler 82 fois de suite sans incident avant de céder la place à Ariane 6 : la preuve qu’un bug, aussi spectaculaire soit-il, ne condamne pas forcément un programme entier, à condition d’en tirer les bonnes leçons.

Sources : deschamp.free.fr | nimareja.fr