URL: https://linuxfr.org/news/bogues-de-logiciel-et-bogues-de-management-737-max-et-autres-catastrophes Title: Bogues de logiciel et bogues de management : 737 Max et autres catastrophes Authors: palm123 Oliver, Thomas Debesse, Pierre Jarillon, Nicolas Boulay, Davy Defaud, Yves Bourguignon, Snark, Kerro, Arcaik, papap, Benoît Sibaud, Pierre Tramal, Ysabeau, ZeroHeure, Storm, BAud, Fabrice Mousset, Marco, matteli, windu.2b, TintinL, _seb_ et Blackknight Date: 2019-04-21T13:13:11+02:00 License: CC By-SA Tags: bug et management Score: 87 Tout le monde sait ce qu’est un bogue sur un logiciel, mais un bogue au niveau management, cela existe aussi. Les conséquences peuvent être catastrophiques. Commençons par le Boeing 737 Max. Le Boeing 737 Max est la dernière évolution du premier 737 sorti en 1967. Comme certaines caractéristiques ont été sensiblement modifiées, les concepteurs de l’avion ont décidé que le logiciel rattraperait les problèmes de stabilité. Par souci d’économie et pour concurrencer Airbus, Boeing a décidé d’aller vite, trop vite, en négligeant les principes fondamentaux du développement aéronautique qui ont permis à l’avion d’être le moyen de transport le plus sûr de tous. Cette dépêche retrace également d’autres catastrophes, révélant les problèmes dans le processus de décision qui, bien souvent, éloigne les décideurs des alertes émises par du personnel compétent. Dans bien des organisations, les subordonnés sont incités à minimiser ce qui dérange la direction. ---- [Le Boeing 737 Max et le logiciel](https://spectrum.ieee.org/aerospace/aviation/how-the-boeing-737-max-disaster-looks-to-a-software-developer) [Rapport d’enquête du vol 501 d’Ariane 5](http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf) ---- # Boeing 737 Max # L’avion en est à sa sixième version. Il a été rallongé et équipé de réacteurs plus lourds et surtout plus gros, qui, s’ils avaient été mis au même endroit, auraient raclé le sol. Comme on ne pouvait pas allonger le train d’atterrissage, il a fallu réaliser de nouveaux mâts de réacteur pour avancer et relever les moteurs. Le centrage, le centre de poussée et l’aérodynamique de l’avion ont été de ce fait sérieusement modifiés, ce qui change notablement son comportement en vol. L’avion a tendance à cabrer. Pour corriger cela un capteur d’assiette a été ajouté à l’avion, et un logiciel devait renvoyer le nez de l’avion vers le sol pour compenser. Le logiciel était censé corriger le problème de conception. Ce logiciel était un pis‑aller qui a été mal étudié. Il est anormal qu’un système de commandes de vol électriques doive avoir besoin d’être désactivé. La bonne démarche eut été de modifier les points d’ancrage des ailes, voire de les redessiner, tout comme le plan de dérive. En fait, c’était un nouvel avion qu’il fallait créer et qualifier. Or, Boeing voulait rattraper son retard sur l’[A320neo](https://fr.wikipedia.org/wiki/Airbus_A320#A320neo_(A319,_A320_et_A321) "New Engine Option") qui se vendait bien. Et l’une des raisons était l’absence de formation supplémentaire pour les pilotes. Pour compléter le tableau, Boeing n’a utilisé qu’un seul capteur d’incidence (pas de redondance). L’existence même du logiciel a été cachée aux pilotes, ainsi que le moyen de le désactiver en cas de problème, pour éviter de devoir faire une formation longue à ce nouvel avion et faire croire qu’il se pilotait exactement comme un 737 classique. Le but était d’avoir les mêmes avantages que l’A320neo. _Business Insider_ rapporte que lors d’une réunion plénière, un responsable [avait déclaré](https://www.businessinsider.fr/le-logiciel-du-boeing-737-max-aurait-ete-concu-par-des-interimaires-sous-payes/) que « les ingénieurs expérimentés n’étaient plus nécessaires dans l’entreprise » et qu’après l’incident, un porte‑parole a déclaré que « la sécurité était toujours au centre des préoccupations ». Bilan : 346 morts, deux avions perdus, déjà un milliard de dollars de perte. Boeing [serait obligé de garer ses avions](https://www.businessinsider.fr/boeing-est-maintenant-oblige-de-garer-ses-737-max-inutilises-sur-le-parking-des-employes/) cloués au sol sur le parking de ses employés. _[The Roots of Boeing’s 737 Max Crisis: A Regulator Relaxes Its Oversight](https://www.nytimes.com/2019/07/27/business/boeing-737-max-faa.html)_. _[Veteran Boeing manager was transferred to 787 production; based on he saw there, he won’t fly in a Dreamliner and begs his family not to](https://boingboing.net/2019/12/02/razor-sharp-metal-shavings.html)_. [Le cauchemar du 737 Max ne cesse de s’aggraver] (https://embarque.developpez.com/actu/296371/Le-cauchemar-du-737-MAX-ne-cesse-de-s-aggraver-un-rapport-accablant-des-enqueteurs-de-la-Chambre-US-montre-la-pire-defaillance-de-securite-dans-l-avion-cloue-au-sol-a-cause-des-problemes-logiciels/). # Ariane 5 vol 501 (vol inaugural) # La conception de la fusée Ariane 5 s’est basée sur des éléments d’Ariane 4, dont le boîtier des mesures de navigation (centrale inertielle). Notons qu’Ariane 4 était le lanceur réputé le plus fiable de son époque avec 97 % de succès sur quinze ans de service (116 lancements). Afin de valider l’ensemble complet d’un système, l’Aérospatiale avait l’habitude de réaliser des « chaînes sur table », c’est‑à‑dire un montage en laboratoire de tous les équipements de la fusée reliés à des simulateurs de stimuli. Dans le cas d’Ariane 5, l’Aérospatiale l’avait budgétisé à 800 000 francs. Mais le CNES pensait que l’Aérospatiale voulait réaliser ces « chaînes sur table » uniquement pour avoir plus de rentrées financières. Pourtant, ce n’était pas un test optionnel, l’Aérospatiale avait bien cette pratique sur tous ses projets spatiaux. Donc, pour faire des économies, le CNES a décidé la réutilisation de certains éléments d’Ariane 4, la calibration d’Ariane 4 et l’absence des « chaînes sur table ». Le résultat a été l’explosion de la fusée après quarante secondes de vol (vidéos [1](https://www.youtube.com/watch?v=fCnO-UYF3co "La vidéo du vol inaugural Ariane 5 le 4 juin 1996") et [2](https://www.youtube.com/watch?v=PK_yguLapgA)). Heureusement, le [vol 501 d’Ariane 5](https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5) n’a pas fait de victimes, mais a entraîné un retard de plus d’un an sur le programme. L’économie des « chaînes sur table » de 800 000 francs, a coûté mille fois plus, 800 millions de francs ! Et effectivement, les « chaînes sur table » effectuées par la suite ont montré la parfaite reproductibilité du phénomène. L’accélération d’Ariane 5 étant cinq fois plus élevée que celle d’Ariane 4, la valeur *accélération* est copiée dans un registre trop petit, ce qui provoque une interruption logicielle « _integer overflow_ ». Le pire, c’est que cette valeur n’était pas utile dans le cadre d’Ariane 5 ! > *4, 3, 2, unité, feu… allumage… décollage.* Dès la phase d’accélération, les deux boîtiers issus d’Ariane 4 connaissent tous les deux l’interruption logicielle « _integer overflow_ ». Et par conséquent, le gestionnaire d’interruption par défaut effectue un *autotest*, c’est‑à‑dire qu’il vérifie le bus de données en envoyant alternativement des `0x5555` et des `0xAAAA`. Le modèle interne simulé fonctionne bien, quant à lui, mais le système de vote à la majorité donne raison aux deux boîtiers issues d’Ariane 4. > *Tous les paramètres propulsifs sont normaux et la trajectoire est normale*. Le pilotage automatique prend les commandes à la trente‑septième seconde, il pense que les données qui circulent sur le bus sont des données valides de navigation et procède à une correction extrême de la trajectoire. Ce braquage brutal exerce une pression aérodynamique très élevée. Une partie de la structure de la fusée se désolidarise, ce qui déclenche son auto‑destruction. Notons que ces boîtiers sont utiles pour réaliser des mesures quelques secondes avant le décollage, mais après le décollage, ils ne sont plus d’aucune utilité. Ces boîtiers sont pourtant restés actifs pendant le décollage car c’était une exigence d’Ariane 4. Leur désactivation était prévue 40 secondes après le décollage, soit quelques secondes après le braquage de la fusée. Depuis, il y a une vraie chasse au code mort (le code inutile) dans les logiciels embarqués critiques. ## Code source Ada du boîtier ![Scan du code source Ada du SRI (Système de Référence Inertielle)](http://olibre.github.io/GreatTips/unit-test/bug-Ariane-501_by-JeanJacquesLevy-INRIA-2010.jpg "Scan du code source Ada du SRI (Système de Référence Inertielle)") ## Variable **B**iais **V**ertical `BV` Nous avons bien le test des bornes -32768..32767 avant copie dans le registre 16 bits : ```ada L_M_BV_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) * G_M_INFO_DERIVE(T_ALG.E_BV)); if L_M_BV_32 > 32767 then P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#; elsif L_M_BV_32 < -32768 then P_M_DERIVE(T_ALG.E_BV) := 16#8000#; else P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32)); end if; ``` ## Variable **B**iais **H**orizontal `BH` La valeur est copiée directement dans le registre 16 bits sans protection. Le [rapport d’enquête](http://www.astrosurf.com/luxorion/astronautique-accident-ariane-v501.htm) indique que certaines variables n’étaient pas protégées pour éviter que la charge du processeur dépasse les 80 %. Aucune information n’a été trouvée pour justifier de protéger telle variable plutôt qu’une autre. ```ada P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH))); ``` ## Enquêtes Un contributeur de _LinuxFr.org_ qui travaillait au projet Ariane 5, nous indique que seulement quelques heures après l’échec du lancement, les équipes d’Aérospatiale avaient déjà repéré des signaux d’erreur en ASCII qui circulaient sur le bus de données et que le pilotage automatique avait pris cela pour des données numériques valides. Le CNES met immédiatement en place une commission d’enquête qui donne ses conclusions un mois après. Le [rapport officiel](http://deschamp.free.fr/exinria/divers/ariane_501.html) démontre que les concepteurs du calculateur de la trajectoire ont volontairement exclu la spécificité d’Ariane 5. Lire aussi [cette version anglaise](http://www.math.umn.edu/~arnold/disasters/ariane5rep.html) et cette [autre version anglaise](http://www.rvs.uni-bielefeld.de/publications/Reports/ariane.html). Cette commission d’enquête officielle est composée d’ingénieurs en logiciel, et conclut à un problème logiciel. Deux autres enquêtes indépendantes remettent davantage en cause les erreurs de gestion du programme (le lien vers le [PDF](http://cmpe.emu.edu.tr/chefranov/Cmps201-fall2011/Notes/Ariane5failure.pdf) est cassé). Gérard Le Lann (INRIA) conclut à un [problème d’intégration système](https://hal.inria.fr/inria-00073613/document). Jacques‑Louis Lions parle d’[erreur de spécification et de conception logicielles](https://zoo.cs.yale.edu/classes/cs422/2010/bib/lions96ariane5.pdf). Quant à Mark Dowson, il insiste sur l’[environnement de travail](https://www.deepdyve.com/lp/association-for-computing-machinery/the-ariane-5-software-failure-jZY4texaSd) comme étant les racines de l’échec : 1. carriérisme des managers et aspirations politiques de leurs décisions ; 2. pressions sur les budgets ; 3. pressions sur les délais ; 4. culture du « pas cassé, pas corrigé » (_If it’s not broken don’t fix it_). Alors, le problème d’Ariane 5 était‑il un bogue logiciel comme en conclut la commission d’enquête officielle, ou alors un bogue managérial ? Dans tous les cas, aucun manager n’a été inquiété. En revanche, les développeurs, eux, ont [eu du pain sur la planche](https://fr.wiktionary.org/wiki/avoir_du_pain_sur_la_planche#Locution_verbale). # Challenger STS-51-L # L’[[accident de la navette spatiale Challenger]] a aussi pour origine la volonté de faire des économies sur le délai et le budget. Les personnes prenant ces décisions ont tendance à ignorer les alertes des ingénieur·e·s et physicien·ne·s car n’apprécient pas être remises en cause. C’est malheureusement un comportement humain répandu, qui devient un défaut fatal quand on a un poste de grande responsabilité. L’accident a eu lieu 73 secondes après le décollage, entraînant la mort de l’équipage dont une institutrice qui devait donner un cours depuis l’espace et devenir la première « passagère de l’espace », tout un symbole. La médiatisation de ce coup de communication rendit le drame plus insoutenable car 48 % des élèves américains de neuf à treize ans regardaient le décollage depuis leur école. L’équipage a probablement survécu à la désintégration du vaisseau et serait dans ce cas décédé lors de l’impact de la cabine avec la mer. La navette spatiale américaine avait été conçue sans système de sauvetage au décollage, en se fondant sur l’hypothèse que la navette spatiale devait abaisser le risque couru par les astronautes au même niveau que celui des passagers des avions. L’accident a entraîné la mort de sept personnes, la perte du vaisseau, et une interruption de trente‑deux mois du programme de la navette. En complément : la vidéo de Stardust « [La destruction de la navette _Challenger_](https://www.youtube.com/watch?v=59n4bMjL_xc) » (durée : 14 minutes). # Columbia STS-107 # Le 1ᵉʳ février 2003, après quinze jours passés en orbite basse, [la navette spatiale américaine _Columbia_ se désintègre lors de sa rentrée dans l’atmosphère terrestre](https://fr.wikipedia.org/wiki/Accident_de_la_navette_spatiale_Columbia). En août 2003, dans son rapport final, la Commission d’enquête sur l’accident de _Columbia_ détermine que la cause directe de l’accident fut l’impact sur l’aile gauche de la navette d’un morceau de mousse isolante qui s’était détaché du réservoir externe lors du décollage. Le bouclier thermique de la navette étant endommagé, le vaisseau fut détruit lors de la rentrée atmosphérique en retour de mission. Mais les causes de l’accident sont aussi d’ordre organisationnel. Ce problème de débris de mousse isolante était déjà connu des ingénieurs, mais les missions ont continué parce que les impacts étaient considérés comme inévitables et sans solution (« S’il n’y a pas de solution, c’est qu’il n’y a pas de problème. » — Jacques Rouxel _in_ _Les shadoks_). Aussi, après le décollage, plusieurs responsables veulent obtenir des images de la navette pour étudier les dégâts potentiellement provoqués par l’impact, mais se voient refuser leurs demandes pour des raisons de délais ou de budget. Ils se voient également reprocher d’avoir contourné la hiérarchie et de ne pas respecter la bureaucratie de la NASA. Résultat : sept morts supplémentaires, une navette supplémentaire détruite, interruption du programme de la navette pendant vingt‑neuf mois, et suspension de la construction de l’ISS. ## Références * [Columbia STS-107 – Chronique d’une catastrophe annoncée](http://www.securiteaerienne.com/columbia-sts-107-chronique-dune-catastrophe-annoncee/) ; * vidéo de Stardust « [La destruction de la navette Columbia](https://www.youtube.com/watch?v=Nelzv2NJqqQ) » (durée : 13 minutes). # Le Vasa # Cet énorme vaisseau, le _[[Vasa]]_, a sombré en 1628 lors de sa sortie inaugurale après seulement 1 600 m de navigation. On ne pouvait pas incriminer le logiciel à l’époque et même si, près de quatre siècles plus tard, la perception d’une construction bâclée et d’un chantier désorganisé sont à l’origine du [syndrome de Vasa](https://fr.wikipedia.org/wiki/Syndrome_de_Vasa). Les responsabilités sont difficiles à cerner et semblent diluées tout au long de la construction. Beaucoup d’éléments semblent concourir à l’aboutissement d’un bateau instable : * les demandes de modifications faites par le roi de Suède pendant la construction, notamment les 72 canons qui étaient trop nombreux pour tenir sur un seul pont ; * les changements de direction de la construction navale ; * les délais et les questions économiques du fait de la perte de dix navires en une seule tempête ; * les tests de navigabilité négligés. Résultat : trente à cinquante personnes périrent avec le navire et, par ailleurs, ce naufrage du _Vasa_ fut un véritable désastre financier pour le petit État suédois. # Autres catastrophes similaires * mauvaises décisions lors de la construction du dirigeable britannique [R101](https://www.airships.net/blog/british-airship-r101-crashes-killing-48-day-1930/) qui s’écrase à 80 km au nord de Paris ; * volonté des dirigeants d’arriver en avance et [naufrage du _Titanic_](https://fr.wikipedia.org/wiki/Titanic) ; * déni d’erreur du commandant de bord et mauvaise procédures de secours lors du [naufrage du _Sewol_](https://fr.wikipedia.org/wiki/Naufrage_du_Sewol). # Anneau de fer martelé L’histoire commence avec l’ambitieuse construction du [[pont de Québec]] en 1903 : le plus long pont de type porte‑à‑faux au monde. La construction débute sous la direction d’un ingénieur originaire des États‑Unis ([[Theodore Cooper]]). À cause d’erreurs de calcul, le poids réel du pont excède sa capacité portante. Des problèmes furent remarqués par les ingénieurs canadiens, mais la direction ne tient pas compte de la gravité de la situation. En 1907, un ingénieur responsable demande l’arrêt complet des travaux, mais les travaux continuèrent. Deux jours après, 20 000 tonnes d’acier croulent dans le fleuve, et soixante‑seize travailleurs (sur cent) sont tués. À marée basse, la ferraille provenant de cet effondrement est visible sur la rive du fleuve. Le pont connaît un second effondrement en 1916, provoquant treize décès. L’année suivante, le pont est enfin achevé. Suite à ces incidents, en 1922, l’ingénieur [Haultain](https://en.wikipedia.org/wiki/H._E._T._Haultain) propose un rite d’engagement solennel qui oblige les ingénieurs à un comportement professionnel exemplaire. La même année, la Société des Sept Gardiens est créée et procède à sa première cérémonie en 1925 en remettant un [anneau de fer martelé](https://fr.wikipedia.org/wiki/Anneau_de_fer_martelé) à chaque ingénieur. Si l’ingénieur abandonne son serment, il doit rendre l’anneau. # Le Guide de terrain pour comprendre l’erreur humaine Pour aller plus loin, le livre _[The Field Guide to Understanding “Human Error”](https://www.oreilly.com/library/view/the-field-guide/9781317031833/)_, troisième édition par Sidney Dekker (CRC Press, novembre 2017, ISBN 9781317031833). # Voir aussi d’autres bogues * 1980 — Le système [NORAD](https://fr.wikipedia.org/wiki/Commandement_de_la_défense_aérospatiale_de_l’Amérique_du_Nord "commandement de la défense aérospatiale de l’Amérique du Nord") déclenche, à deux reprises, à trois jours d’intervalle, une [fausse alerte](https://en.wikipedia.org/wiki/North_American_Aerospace_Defense_Command#False_alarms) d’attaque nucléaire, et, à chaque fois, les bombardiers chargés de bombes nucléaires décollent pour la contre‑attaque. En fait, le logiciel ne gérait pas la défaillance électrique. * 1983 — Un satellite soviétique déclenche une fausse alerte d’une attaque de missiles, mais heureusement, l’officier russe n’y croit pas. * 1983 — Le [[Vancouver Stock Exchange]] corrige son index de [525 à 1099 à cause d’une erreur d’arrondi](https://en.wikipedia.org/wiki/Vancouver_Stock_Exchange#Rounding_errors_on_its_Index_price) passée inaperçue pendant quelques années. * 1985 — La NASA [ne détecte aucun trou d’ozone](https://earthobservatory.nasa.gov/Features/RemoteSensingAtmosphere/remote_sensing5.php) pendant sept ans car les grandes variations dans les mesures ne sont pas prises en compte. * 1993 — Bogue du Pentium sur les nombres flottants. * 1998 — Désintégration de [Mars Climate Orbiter](https://fr.wikipedia.org/wiki/Mars_Climate_Orbiter#Perte_de_la_sonde_(23_septembre_1999)) car une fonction utilise l’unité [livre‑force](https://fr.wikipedia.org/wiki/Livre-force) ([système anglo‑saxon](https://fr.wikipedia.org/wiki/Unit%C3%A9s_de_mesure_anglo-saxonnes)) au lieu du [newton](https://fr.wikipedia.org/wiki/Newton_(unité)). Pourtant, les projets de la NASA sont censés utiliser le [système métrique](https://fr.wikipedia.org/wiki/Syst%C3%A8me_m%C3%A9trique). * 2010 — Toyota rappelle un million de véhicules mais ce n’est pas la mécanique qui est en cause, plutôt le [code spaghetti bourré de négligences](https://linuxfr.org/news/encore-un-exemple-de-code-spaghetti-toyota). * 2012 — [[Knight Capital Group]] met en production un automate de _trading_ haute fréquence qui exécute, par erreur, un code de test faisant perdre à l’entreprise 440 millions de dollars en 45 minutes, soit 90 millions de plus que son capital, plongeant son cours de bourse de 75 %. Pour l’anecdote, KCG a réussi à renaître de ses cendres en levant 400 millions (4 jours après), puis revend ses logiciels *KCG Hotspot* à BATS pour 365 millions (2015), enfin *KCG Holdings* est valorisé à 1,4 milliard (2017) lors du rachat par Virtu Financial ! * 2014 — Apple a dans son code source [deux lignes successives « `goto fail` »](https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug) ce qui a conduit à l’ajout de l’option [`-W misleading-indentation`](https://developers.redhat.com/blog/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail/) à [GCC 6](https://linuxfr.org/news/sortie-de-gcc-6#nouvelles-informations-sur-les-erreurs-et-alertes-à-la-compilation) (lire aussi le [journal](https://linuxfr.org/users/flagos/journaux/apple-le-ssl-les-goto-et-les-accolades)). * 2015 — Valve Steam dont son script d’installation pouvait effacer tout le `$HOME` sous GNU/Linux. # Et dans votre organisation ? Reconnaissez‑vous des aspects de vos projets ? Partagez vos propres expériences dans les commentaires.