Ce que les crashs des Boeing nous disent à propos de nos logiciels

Hervé Rincent -

Le 13 mars 2019, tous les avions 737 Max de Boeing sont cloués au sol.

A cause du Covid ?

Non.

Cette suspension fait suite à deux crashs consécutifs :

  • Le 29 octobre 2018 : celui du vol Lion Air 610, 13 minutes après son décollage de Jakarta
  • et le 10 Mars 2019 : celui du vol 302 d'Ethiopian Airlines, 6 minutes après son décollage d'Addis-Abeba.

Une série noire pour le constructeur aéronautique américain.

L'analyse de ces 2 accidents a révélé un comportement surprenant de l'appareil, qui s'est mit à piquer tout droit vers le sol.

Tout seul. Comme ça.

Et malgré la vaine tentative des pilotes pour redresser l'avion en tirant sur le manche.

L'enquête menée par le département Américain des transports a conclut à une défaillance du système "MCAS". Mais au delà du problème technique, c'est avant tout la défaillance d'une organisation qui n'a pas su détecter ses dérives.

Le MCAS, et la volonté de bien faire.

Le MCAS siginifie "Maneuvering Characteristics Augmentation System". C'est un système automatique qui réduit le risque de décrochage dans certaines situations.

Le décrochage, c'est le cauchemar du pilote. L'appareil ne vole plus. Il tombe comme un fer à repasser.

Le MCAS observe l'inclinaison de l'avion et sa vitesse : s'il est en train de monter, et que sa vitesse est trop faible, il risque de décrocher. Dans ce cas, il faut rapidement corriger l'inclinaison pour revenir à l'horizontal.

Donc ça part d'une bonne intention ce nouveau système numérique : améliorer la sécurité.

Pour connaître l'inclinaison, le MCAS utilise les informations fournies par un capteur situé sur le nez de l'appareil :

Oui, voila. Cette petite aile.

Elle va bouger en fonction du flux d'air horizontal qu'elle reçoit. Si l'avion monte, elle va s'incliner vers le haut, et le MCAS va corriger automatiquement la trajectoire en agissant sur les gouvernes de profondeur à l'arrière de l'appareil.

Et ça fonctionne bien quand ... tout va bien.

Un problème de conception

Voila une erreur d'ingénierie parmi les plus courantes : on ne s'intéresse qu'aux cas ou tout va bien.

Mais que se passe-t-il lorsque le capteur d'inclinaison est défaillant ? Lorsqu'il se met à transmettre n'importe quoi au MCAS en lui faisant croire que l'avion est beaucoup plus incliné qu'il ne l'est en réalité ?

Et bien l'avion dispose d'un second capteur d'inclinaison, situé de l'autre côté du premier. Il suffit de comparer les informations envoyées par les 2 capteurs, et d'inhiber le système lorsqu'une incohérence est détectée.

C'est ce que prévoyait la conception initiale du MCAS (et en place sur les versions militaires).

Mais là, non.

Le MCAS utilise UN seul capteur.

Pourquoi ce choix hasardeux ?

Un problème de régulation

L'entité Américaine en charge d'autoriser l'exploitation d'un avion est la FAA (Federal Aviation Administration). C'est l'équivalent de la Direction de Sécurité de l'Aviation Civile (DSAC) en France.

Et aussi hallucinant que ça puisse paraître, l'analyse de sûreté menée par Boeing et approuvée par la FAA indique que le pilote va se rendre compte en moins de 3 secondes d'une défaillance du MCAS et le désactiver.

3 secondes...

Alors pourquoi s'embêter à complexifier le MCAS avec une redondance des capteurs, puisque le pilote va réagir tout de suite ?

Et pire encore :

Avec une redondance, on double la probabilité d'avoir un MCAS indisponible (puisqu'il a besoin que les 2 fonctionnent), et donc que l'avion ne puisse pas partir à l'horaire prévu !

Voilà une seconde erreur : pousser le KISS (Keep it simple and stupid) trop loin en détournant le regard de tous les cas limites, et en comptant sur quelque chose d'autre pour régler le problème que l'on a soit même créé.

Et c'est ainsi qu'un système initialement motivé par l'amélioration de la sécurité de l'avion fait 346 morts.

Ce que ça nous dit de nos logiciels

Coder un logiciel, c'est un processus d'ingénierie. Comme construire un avion, une voiture.

Le code sert à interagir avec son environnement : des utilisateurs, des capteurs, des données issues d'autres systèmes (sinon, c'est que le code ne sert à rien).

Ces interactions sont chaotiques et imprévisibles. Elles emmènent parfois le code dans des endroits ou son exécution n'est plus appropriée.

Alors c'est important de bien délimiter les entrées et les sorties attendues qui font que ce qu'on a codé reste légitime.

Et de se ménager une porte de sortie, une exception "laisse tomber, ça part en cacahuète" que l'on va gérer pour revenir dans un état de repli stable et sûr (ex : désactivation du MCAS).

On code ça par des gardes au début et à la fin des fonctions.

Cette "hygiène fonctionnelle" passe aussi par l'absence d'effets de bords. Mieux vaut garder des fonctions pures :

  • dont le résultat ne dépend QUE de ses entrées,
  • et dont le résultat de l'exécution est intégralement exprimé dans les données retournées.

Prenez-cet exemple scabreux :

Ce code a tout faux.

Il utilise un objet global settings et modifie l'objet passé en paramètre pour y mettre son résultat.

Dans ces conditions, il va être compliqué de délimiter le périmètre des entrées et les sorties qui conservent la légitimité du code.

Un ré-écriture s'impose donc.

On peut la guider des des tests unitaires qui vont planter une clôture entre la zone normale et celle qui ne l'est plus. Ces tests permettront de découvrir qu'un cas n'est pas prévu (le nom de famille est renseigné, mais pas la civilité, mais ce n'est pas pour autant un utilisateur anonyme).

Tous les codes n'ont pas le même enjeu

Alors oui, on n'attend pas forcément le même niveau de fiabilité pour un système de sécurité d'un avion et pour une appli de rencontre en ligne.

Pour autant, avez-vous évalué les risques ? Quelles sont les conséquences d'un bug, ou d'une fuite de données ?

Que se passe-t-il s'il est "facile" d'accéder aux messages privés échangés par les utilisateurs d'une appli de rencontre en ligne ? C'est peut-être juste tout votre business qui va se crasher.

Ne sous-estimez pas l'analyse de risques comme la FAA. Et ne pariez pas trop sur la capacité des utilisateurs à régler les problèmes à votre place en moins de trois secondes !

Références :