La première Ariane 5 n'a pas explosé à cause d'un bug informatique

En réalité, on retrouve ce genre de problèmes multi-factoriels dans pratiquement tous les gros échecs de systèmes industriels. Mais il est beaucoup plus simple d’accuser le seul management qui fait de l’économie à outrance (si on est technique) ; ou la seule technique qui ne sait pas développer ou tester (si on est dans le management).

Comme toujours dans ce genre de choses, un bogue est introduit pour une raison X ou Y et une faille dans la procédure lourde (en gros : manque de rigueur) n’a pas permis de l’identifier et de le corriger à temps. Alors que c’est le but même de ces procédures.

En vrai je ne vois pas en quoi ça invalide le propos des gens que tu critiques. Le vrai problème est en effet ce changement de représentation de la valeur qui ne correspondait plus à ce qui était attendu d’un code plus ancien.

Et pour des raisons de coûts, de temps et d’erreurs humaines, ce problème n’a pas été identifié ni corrigé avant le lancement inaugural. Donc la critique reste valide.

Après oui, ce n’est pas forcément la faute au décideur pressé uniquement (ça l’est rarement entièrement de toute façon). D’où le fait que les procédures doivent être suivies avec rigueur et qu’on doit éviter dans des systèmes si complexes se passer de tests d’intégration complets (quitte à utiliser des simulateurs).

De quelle critique parles-tu ? Je ne suis pas sur de te suivre.

Le début de ton message jusqu’à

Cette explication est fausse, ou au moins très, très incomplète.

En gros. Tu critiques les personnes qui tiennent ces propos.

L’ironie c’est que le code d’Ariane est écris en Ada. Ce qui prouve, que même avec un langage sûr, il est toujours possible de faire des conneries

Le rapport mentionne le langage en disant ceci :

Il en est résulté une erreur d’opérande. Les instructions de conversion de données (en code Ada) n’étaient pas protégées contre le déclenchement d’une erreur d’opérande bien que d’autres conversions de variables comparables présentes à la même place dans le code aient été protégées.

Et ceci :

On a notamment analysé la conversion de représentations flottantes en nombres entiers et il s’est avéré que les opérations comportant sept variables risquaient de conduire à une erreur d’opérande. En conséquence, une protection a été ajoutée à quatre des variables, comme en témoigne le code Ada, alors que trois variables sont restées non protégées. Aucun élément justifiant cette décision n’a été retrouvé dans le code source proprement dit.

Je ne connais pas assez Ada pour savoir si la sûreté du langage a un rapport direct avec tout ça.

Il a été signalé à la Commission que les conversions n’étaient pas toutes protégées car un objectif de charge de travail maximale de 80 % avait été assigné au calculateur du SRI. Afin de déterminer la vulnérabilité des codes non protégés, une analyse a été conduite sur chaque opération pouvant donner lieu à une exception, y compris une erreur d’opérande.

En gros, c’était délibéré d’avoir certaines conversions non protégées. Mais c’est sûr que si ton langage permet facilement de vérifier ça et que tu ne le fais pas, c’est un risque. Quand tu prends ce risque de manière calculée, ça va. Quand tu te merdes dans le calcul de ce risque, ça ne va pas.

Je ne connais pas non plus Ada assez, mais dans d’autres langages, les conversions de type sont très surveillées et tu as de meilleurs outils pour gérer les erreurs quand elles surviennent.

Quand tu décides de faire autrement (pour des raisons de performance par exemple), tu peux passer par de l’analyse statique (Polyspace dans mon ancienne boîte sur du C), pour faire des vérifications sur le code sans perte de performance à l’éxécution. En gros, tu vires des if ou utilise des fonctions de conversion non-sûres parce que tu sais prouver que le dépassement n’arrivera pas avec ce qui est connu sur les opérandes.

Le problème, c’est que les analyses automatiques ont des limites liées à la quantité d’information disponible à travers le reste du code (par exemple des tests de plage de valeur). Au bout d’un moment, tu es obligé de donner des informations toi-même, et donc potentiellement introduire des erreurs. Surtout si ces hypothèses se révèlent fausses (par exemple les entrées envoyées par un autre calculateur, ou des accélérations supérieures à ce qui était envisagé).

Dans le cas présent, ce risque était parfaitement calculé… avec les données de trajectoire d’Ariane 4, pour laquelle ce logiciel a été développé, tandis qu’on a choisi de ne pas joindre les données de vols d’Ariane 5 aux specs de la mise à jour du SRI pour Ariane 5 (dont une centrale inertielle n’a à priori pas besoin, à moins qu’on y ajoute des fonctionnalités annexes, ce qui n’était d’ailleurs pas le cas sur Ariane 5: la fonctionnalité annexe était héritée d’Ariane 4).

J’aime beaucoup ce cas de catastrophe industrielle, où, comme souvent, personne n’a fait de choix expliquant à lui seul la catastrophe. Pour citer le rapport:

Bien que la source de l’erreur d’opérande ait été identifiée, elle n’est pas en soi la cause de l’échec de la mission.

Sur ce sujet, je ne me risquerai pas a faire un commentaire avant d’avoir bien lu et compris le rapport.

Je ne peux que vous recommander la lecture du rapport si le sujet vous intéresse : il est pas très long, assez facile à lire et très instructif, notamment sur les évènements déclencheurs de catastrophes et sur les chaines de confiance douteuses qui ont conduit à ne pas tester des éléments testables.

Cela me rappelle une expérience professionnelle marquante : un équipement majeur était constitué de deux sous systèmes : un unité de commande et de contrôle, et plusieurs unités de production.
Chaque sous système faisait l’objet de spécifications très complète., et de tests destinés à vérifier la conformité aux spécifications. Mais on n’avait pas de spécification documentée d’interfonctionnement !
Or, en situation de forte charge, des éléments d’information des unités de productions parvenaient trop tard au système de commande et de contrôle, d’où des plantages catastrophiques en pleine heure de pointe.
En fait, les spécifications ne prévoyaient pas une charge aussi élevée, mais comme le truc marchait, personne ne s’est posé la sérieusement la question des moyens de test pour générer une charge comparable.

En l’occurrence, si un truc marche très bien depuis 10 ans, a du mal à imaginer pourquoi il se plante de temps en temps.