español   français   english   português

dph participe à la coredem
www.coredem.info

rechercher
...
dialogues, propositions, histoires pour une citoyenneté mondiale

Une faute dans un programme informatique peut avoir des conséquences dramatiques

Comment s’assurer que tout a été vérifié

Elisabeth BOURGUINAT

08 / 1999

Si l’on devait décrire en détail la marche d’une entreprise en posant comme principe que les destinataires sont absolument stupides et absolument obéissants, cela supposerait des millions d’instructions ; mais personne ne fait l’hypothèse que cela pourrait être efficace. C’est pourtant de cette façon que fonctionne un ordinateur : à la différence de ce qui se passe généralement dans une entreprise, lorsqu’une instruction est mauvaise, l’ordinateur l’exécute avec une conscience professionnelle absolue.

Or si dans le domaine de la mécanique on admet des marges de tolérance, en informatique la moindre erreur peut avoir des conséquences incalculables : chez ATT, le mauvais placement d’une parenthèse a entraîné la panne de l’ensemble du téléphone longue distance américain pendant toute une journée.

Quant à l’explosion de la fusée Ariane V, qui a coûté 5 milliards de francs, elle est due à une banale anomalie dans un élément du programme parfaitement superflu. Le problème principal du lancement d’une fusée est la stabilisation de cet objet longiligne poussé du bas par un gros moteur ; les données, traitées informatiquement, sont fournies par des gyrolasers qui mesurent périodiquement l’angle de la fusée par rapport à la verticale. L’une des séquences du programme d’Ariane IV mesurait la vitesse horizontale de la fusée, nulle au sol, croissante au fur et à mesure du déplacement ; cette mesure avait été maintenue dans le programme d’Ariane V, bien que la procédure de lancement soit très différente et que cette mesure soit devenue totalement inutile ; mais la vitesse d’Ariane V était bien plus importante que celle d’Ariane IV, et la séquence spéciale n’était pas conçue pour enregistrer les données correspondantes ; l’ordinateur a considéré que les gyrolasers étaient en panne et la fusée a explosé.

A la suite de cet accident, la commission d’enquête a recommandé de ne plus faire fonctionner un logiciel qui ne sert à rien ; ceci paraît une lapalissade, mais c’est une habitude très répandue parmi les programmeurs que de "ne pas changer un logiciel qui marche ". La commission a recommandé également de faire des tests avant le lancement réel, tests qui sont souvent négligés pour des raisons de coût ; mais après des erreurs aussi catastrophiques, les données du calcul changent : la société Intel, depuis le bug du Pentium qui lui a coûté 300 millions de dollars, consacre désormais 75 pour cent de ses coûts à ces tests.

Quelle que soit la bonne volonté qu’on y met, une vérification totale paraît cependant largement utopique. En l’occurrence, le Centre National d’Etudes Spatiales (CNES)avait demandé, avant le lancement, une vérification de la séquence qui a causé l’accident ; la vérification avait été faite, mais une ligne avait malheureusement été oubliée. Il aurait fallu ne pas se contenter de vérifier que la vérification avait été faite, mais aussi vérifier ce qui avait été vérifié...

Dans ce cercle vicieux, la seule solution consiste à limiter les risques de défaillance humaine en recourant de plus en plus à des machines-outils qui écrivent elles-mêmes les lignes de code, plutôt que de passer par des programmeurs manuels. Par ailleurs, le problème majeur des logiciels est leur instabilité : la modification d’une petite partie du code se propage en chaîne avec des effets très difficiles à déterminer ; les vérificateurs formels déterminent si les formules logiques gigantesques ainsi obtenues sont vraies ou fausses, ce qui est hors de portée pour un homme. Mais ils ne sont utilisables, pour le moment, que dans des domaines limités.

Le coût de ces vérifications et leur difficulté (d’autant que beaucoup de bugs ne se produisent que dans un environnement très particulier, par exemple avec telle carte graphique implantée à mille exemplaires dans le monde)pousse les concepteurs de logiciels qui ne sont pas susceptibles d’entraîner de telles catastrophes, comme les traitements de texte, à mettre des logiciels remplis de bugs entre les mains des utilisateurs, et à se contenter d’attendre que ces derniers les détectent eux-mêmes. C’était le cas de la première version de Word, qui contenait 600 bugs répertoriés, dont 100 capables de "planter" les machines. Pendant longtemps encore, selon l’orateur, les ordinateurs seront des serviteurs parfaitement fidèles et tragiquement obéissants...

Mots-clés

informatique, entreprise


, France,

Commentaire

Le perfectionnement des ordinateurs est une intéressante leçon d’humilité pour les hommes, qui rêvent depuis toujours d’atteindre la pure rationalité, et buttent constamment sur de petites erreurs stupides et tragiques qu’ils ne peuvent s’empêcher de commettre. Si l’on reprend la comparaison du début, la différence entre les milliers de lignes d’un programme et les milliers de petites actions individuelles qui font tourner une entreprise, c’est que dans le second cas le "programme" écrit par les gestionnaires de l’entreprise pour être exécuté par les opérateurs est corrigé spontanément par ces derniers, dans la mesure de leurs possibilités, chaque fois qu’une erreur se manifeste. Les dirigeants peuvent ainsi avoir l’impression fallacieuse d’avoir construit une mécanique bien huilée, alors que ce sont d’ingénieux acteurs de base qui la sauvent du désastre. On raconte ainsi qu’une usine qui avait été vendue clef en main à l’étranger présentait de gros dysfonctionnements, incompréhensibles pour les ingénieurs puisque la même usine tournait parfaitement en France ; mais quelques petits aménagements invisibles et précieux avaient été apportés par les opérateurs : l’un d’entre eux, par exemple, ne parvenait à saisir des rondelles parfaitement inaccessibles qu’en les collant sur une ficelle qu’il trempait régulièrement dans un pot de confiture. Or, dans un ordinateur, pas de pot de confiture : si cela ne marche pas, les programmeurs doivent retourner à leurs équations. Moralité : quand on veut éviter toute défaillance humaine, on se prive aussi de toute l’ingéniosité humaine, et cela peut coûter cher (voir aussi la fiche : " Le facteur humain dans la conduite d’une centrale nucléaire ").

Source

Compte rendu de colloque, conférence, séminaire,… ; Articles et dossiers

BERRY, Gérard, LEFEBVRE, Pascal, Logiciels : comment chasser les bugs ?  - séminaire 'Vie des affaires' in. Les Annales de l'Ecole de Paris, 1997 (France), III

Ecole de Paris de Management - 94, Boulevard du Montparnasse 75014 Paris, FRANCE - Tél. 33 (0)1 42 79 40 80 - Fax 33 (0)1 43 21 56 84 - France - ecole.org/ - ecopar (@) paris.ensmp.fr

mentions légales