Un bug logiciel contraint un Boeing 787 à se poser d’urgence

Fleuron de l’offre de Boeing, le 787 Dreamliner n’en finit pas d’aligner les déboires. Le dernier en date présente l’originalité d’être logiciel et d’avoir affecté un élément critique de l’informatique embarquée. De fait, un Dreamliner d’Air India qui reliait New Delhi à Melbourne ce mercredi 5 février a du atterrir en urgence à Kuala Lumpur (Malaisie) après un arrêt des écrans des ordinateurs de gestion de vol, ceux-ci devenant brutalement vierges. Les pilotes, sans informations transmises par le système, ont du poser l’appareil manuellement. Se refusant à fournir des détails complémentaires, Boeing a reconnu être au courant de l’incident. Un porte-parole de la compagnie aérienne a indiqué qu’une mise à jour logicielle pourrait être à son origine mais que la sécurité des passagers n’a pas été mise en danger.

Ce n’est pas la première fois que la fiabilité de l’avionique est mise en cause. Lundi, un autre Dreamliner, de la compagnie polonaise Lot, est resté au sol suite à un incident ayant nécessité de redémarrer un ordinateur de bord. Fin 2011, c’est un Airbus A330 de Qantas qui avait été mis à l’index. Suite à la défaillance d’un tube Pitot, qui mesure la vitesse de l’appareil par rapport à l’air, le pilote automatique se serait déconnecté sans que retentissent les alertes prévues dans le poste de pilotage. Une chute brutale a été à l’origine de plusieurs blessés parmi les passagers, dont 12 grièvement. Les enquêteurs chargés de l’incident ont alors identifié un défaut dans l’algorithme empêchant le calculateur de « faire face aux données erronées provenant du tube Pitot défaillant ». Airbus avait procédé à une mise à jour logicielle en novembre 2009 pour corriger ce défaut.

A la suite du crash du vol 447 d’Air France, Sylvain Maier, avocat de l’association des victimes, avait évoqué un possible « bug de l’ordinateur de bord », reprenant une hypothèse précédemment révélée par le Wall Street Journal. Dans nos colonnes, Cyrille Comar, directeur exécutif d’AdaCore, un éditeur d’outils de développement d’applications critiques avec le langage Ada, avait souligné les difficultés inhérentes au logiciel embarqué des avions. Celui-ci doit notamment être certifié suivant un standard international, le DO-178B, pour « s’assurer de la fiabilité du code ». Ce standard a trouvé son successeur fin 2011, le DO-178C, avec notamment l’intégration de la mise en oeuvre des méthodes formelles (via le standard DO-333) afin de valider mathématiquement le code par rapport à ses spécifications. Airbus a déjà adopté les méthodes formelles pour certains tests sur le logiciel embarqué critique des A400M, A380 et A350. Dassault Aviation fait de même depuis 2004 pour valider le logiciel de contrôle de vol de ses Falcon.

Reste que l’informatique embarquée est complexe. Cyrille Comar expliquait ainsi à l’époque que la plus importante question touche à « un problème d’horizon : plus un système d’information grossit et se complexifie, moins on arrive à en voir les limites ». Et de citer en exemple les premières versions de l’informatique embarquée de l’Airbus A380, avec quelque 18 millions de lignes de code, un chiffre « très probablement appelé à doubler, voire tripler au fil des évolutions ». Avec le Dreamliner, il faudrait compter sur environ 8 millions de lignes de code. Et c’est sans compter avec la question de la conception même du logiciel embarqué : « pour chaque panne, il y a un scénario de prévu. Mais lorsque trois pannes s’enchaînent en cascade, il n’est pas sûr que les scénarios vont pouvoir s’imbriquer; ce n’est pas abordé par le standard. »