« Moscou, nous avons un problème »
Par Rutul Dave, Senior Development Manager chez Coverity

Cela est presque passé inaperçu, mais le mois de décembre aura commencé de manière quelque peu mouvementée pour l’industrie spatiale russe. Dimanche 5 décembre, le lanceur Proton-M était en effet victime d’un accident qui s’est soldé par la chute de trois satellites de navigation dans le Pacifique. Ces trois satellites, qui se sont écrasés à environ 1 500 km au nord-ouest d’Honolulu, devaient achever la création du système GLONASS (Global Navigation Satellite System), le programme russe de positionnement et de navigation par satellite concurrent du système GPS (Global Positioning System) créé et mis en place par les Etats-Unis.

A l’origine de cet accident de la fusée russe : une erreur de programmation.

Dans le même temps, la société américaine privée SpaceX annonçait le 8 décembre dernier le retour sur Terre réussi de la première capsule spatiale commerciale Dragon, mise en orbite terrestre quelques heures plus tôt pour un vol de démonstration. Elon Musk, CEO de SpaceX et fondateur de Paypal, s’est attaché à faire l’analogie suivante pour expliquer ce succès : « Imaginez que vous avez un programme informatique extrêmement complexe dont vous pourriez tester certaines parties, mais dont vous ne pourriez pas tester le fonctionnement global et complet avant de le lancer pour la première fois. Or, au moment où il fonctionne pour la première fois, aucun bug n’est permis. Quelle est la dernière fois que vous avez vu un logiciel répondre à ces exigences ? ».

La complexité des grands systèmes logiciels est analogue à celle des systèmes de tir spatial. Mais la majorité des méthodes de test – depuis le contrôle des codes et d’unités de programme jusqu’aux analyses de qualité – se bornent à tester des parties du programme. Même les outils les plus avancés destinés à tester un système dans son ensemble exigent, le plus souvent, des paramétrages et des simulations de test complexes.

Dans de tels cas, l’automatisation des tests de codes basée sur l’analyse statique est la meilleure solution dont les développeurs disposent. L’analyse statique teste le système logiciel dans son ensemble sans avoir à le faire fonctionner, en procédant à une revue complète du code source. Cette méthode diffère de l’analyse dynamique, qui consiste à tester un logiciel en fonctionnement. Par définition, l’analyse dynamique ne testera que les parties du logiciel qui seront exécutées.

L’analyse statique prend en compte la base entière de codes, bâtit des modèles des parties du système, et utilise une base de connaissances pour identifier les erreurs de code au cours de l’analyse. L’analyse statistique permet également aux développeurs d’identifier les événements qui génèrent les erreurs, leur donnant la capacité de pointer l’ensemble des défauts et de procéder aux changements de code nécessaires. Utilisée de manière combinée avec les tests des unités de programme, les tests fonctionnels et les tests structurels, l’analyse statique nous permet de créer un logiciel qui n’aura aucun bug au moment de fonctionner pour la première fois.

Pour le programme de satellite russe GLONASS, le crash de la fusée Proton est un sérieux revers. En plus du coût des trois satellites perdus, de nombreux coûts indirects sont générés par cet accident. Notamment, le recul de la position de la Russie en matière de système de satellites et de concurrence avec le système GPS américain, ainsi que la perte des revenus issus des taxes d’import/export que la Russie prévoit d’imposer sur les téléphones n’intégrant pas la navigation GLONASS. Les bugs peuvent couter très cher – au sens littéral du terme – à une société, mais encore dégrader sérieusement sa réputation et son image, avec des conséquences dont on elle se passerait volontiers.

Il ne fait pas de doute que les erreurs de programmation sur les systèmes informatiques embarqués qui sont à l’origine du crash de la fusée Proton vont être corrigées (représentant, là aussi, un coût qui ne sera certainement pas négligeable), et que le projet de système de navigation GLONASS sera effectif prochainement. Mais le mal est fait, et il s’agit là du sort malheureusement classique réservé aux premières mises en fonctionnement.

Et le mois de décembre aura malheureusement permis à l’industrie spatiale de le vérifier une seconde fois. Samedi 25 décembre, c’est une fusée indienne qui était volontairement détruite par les responsables de son lancement, moins d’une minute après son décollage, emportant avec elle le satellite de communication GSAT-5P qui devait être mis en orbite. Un problème informatique avait fait perdre le contrôle de la fusée par les ingénieurs indiens, qui n’ont pas eu d’autre choix que de faire partir des centaines de millions de dollars en fumée au dessus de l’océan... 
_____________________________________________________________

Coverity est l'éditeur d'une solution d'analyse statique de codes sources visant à détecter les défauts et les failles de sécurité des logiciels. Cette société privée, dont le siège social se trouve à San Francisco, a été fondée en 2002 par des scientifiques réputés de l'Université Stanford dont le projet de recherche de quatre ans s'est traduit par une percée technologique sur une des problématique les plus coûteuses de l'industrie du développement logiciel. Aujourd'hui, plus de 50 sociétés de premier plan utilisent la technologie de Coverity, dont Juniper Networks, Veritas, McAfee, Synopsys, NASA, PalmOne, Sun Microsystems et Wind River.