Mon erreur à 500 millions de dollars sur le rover martien

• En février 2003, dans la salle blanche du JPL, le rover martien Spirit était à deux semaines de son transfert vers le site de lancement, et une simple erreur de connexion du break-out-box aurait pu endommager un engin spatial à 500 millions de dollars
• Spirit et Opportunity formaient une mission de rovers martiens jumeaux dans laquelle la NASA avait investi près de 1 milliard de dollars, avec très peu de marge dans le calendrier pour réparer une panne majeure
• Juste après qu’une impulsion électrique a été envoyée vers l’engin spatial au lieu du moteur, la télémétrie a été coupée, mais ni l’étendue des dégâts ni la cause n’ont pu être établies immédiatement
• Le lendemain, il a été confirmé que la perte de télémétrie venait du retrait des pointes d’un multimètre Fluke 87III, tandis que la véritable surtension restait à analyser sur le canal du driver moteur en H-Bridge
• Après plusieurs semaines d’analyse, le projet a jugé que le matériel pouvait être conservé Use As Is ; après correction de la procédure, le même essai a été poursuivi, et le moteur concerné de Spirit a fonctionné normalement sur Mars

---

L’incident d’essai sur Spirit juste avant le lancement

• En février 2003, dans la salle blanche Building 179 High Bay 1 du JPL de la NASA, le rover martien Spirit n’était plus qu’à deux semaines de son transfert vers Cape Canaveral
• Spirit et Opportunity étaient une mission de rovers martiens jumeaux, des engins spatiaux complexes dans lesquels la NASA avait alors investi près de 1 milliard de dollars
• Pendant les phases d’assemblage et d’essai, il fallait tester minutieusement tous les systèmes et vérifier leur bon fonctionnement avant de refermer définitivement l’engin sur Terre
• Les deux rovers embarquaient au total 62 moteurs brushed-type
  • propulsion et direction des roues
  • commande du bras robotique
  • orientation des caméras
  • pointage de l’antenne vers la Terre
  • déploiement et mise en configuration après l’atterrissage
• Ce soir-là, l’élément testé était le moteur RAT-Revolve du Rock Abrasion Tool (RAT) situé à l’extrémité du bras robotique de Spirit
  • le moteur RAT-Revolve sert à faire tourner la meule et la brosse sur les roches martiennes

Une procédure pour vérifier l’état d’un moteur via ses signaux électriques

• Après chaque essai environnemental, démonter le moteur pour en inspecter l’intérieur n’était pas une approche réaliste
• À la place, on isolait le moteur de l’engin spatial et on le connectait à une alimentation externe et à un strip chart recorder pour vérifier ses performances électriques
• Un moteur sain montre une diminution du courant en courbe exponentielle régulière pendant la montée en régime, tandis qu’une anomalie se manifeste par un blip dans le signal
• L’essai utilisait un break-out-box ; en cas de mauvais branchement, un courant important pouvait partir au mauvais endroit et provoquer des dégâts critiques
• Lors des vérifications préalables, l’interface de connexion, les réglages de l’alimentation, la configuration du strip chart et la brève impulsion de test sur un moteur de référence avaient tous été validés

L’impulsion électrique est partie dans la mauvaise direction

• Au moment d’envoyer de l’énergie au moteur RAT-Revolve, le strip chart a affiché un signal inhabituel, différent même du signal typique d’un moteur défaillant
• En suivant le câblage, il est apparu qu’à cause d’une erreur de break-out-box, l’impulsion électrique était partie non pas vers le moteur, mais vers l’engin spatial, dans la direction opposée à l’interface du connecteur
• Spirit était alors à deux semaines de son transfert pour la préparation du lancement, et il n’y aurait eu aucun temps pour se remettre d’un problème majeur
• L’incident a été signalé immédiatement au test conductor Leo, qui a en même temps répondu que la télémétrie de l’engin spatial venait de disparaître
• L’équipe a aussitôt exécuté la procédure d’arrêt d’urgence et a reçu l’ordre de quitter la salle blanche afin d’évaluer l’incident et ses conséquences

Perte de télémétrie et première évaluation

• Juste après l’incident, deux faits étaient établis
  • une forte impulsion électrique était partie à un endroit non prévu
  • la télémétrie de l’engin spatial s’était interrompue
• Le lien entre les deux n’était pas immédiatement évident
• L’équipe a estimé qu’il était probable que la surtension soit entrée dans le circuit de driver moteur en H-Bridge
  • le H-Bridge est traité ici comme un circuit qui contrôle le flux électrique
  • c’était aussi l’un des éléments conçus pour supporter une énergie supplémentaire en raison de la back-EMF sur le rover
• L’engin spatial était déjà éteint, et l’équipe a décidé de vérifier si le problème disparaîtrait lors de la remise sous tension
• Peu avant minuit, l’incident a été remonté jusqu’au chef de projet Pete, avec la possible replanification d’un projet d’environ 1 000 personnes en jeu

Échec du redémarrage et vraie cause découverte le lendemain

• La procédure standard de mise sous tension de l’engin spatial a été relancée, mais même après le démarrage de l’électronique et du logiciel, la télémétrie n’est pas revenue
• Dans le rack des équipements de support au sol, un voyant rouge s’allumait normalement à chaque cycle d’horloge, comme un battement de cœur robotique à 8 fois par seconde
• L’alimentation montrait les paliers de tension et les variations de courant habituels, mais le voyant ne s’allumait pas et aucune télémétrie n’apparaissait
• En réexaminant le lendemain la chronologie de l’incident, le multimètre numérique Fluke 87III s’est révélé être l’indice clé
• En cherchant le multimètre nécessaire à l’essai la veille, les pointes d’un multimètre qui semblait mesurer la tension du bus près de l’engin spatial avaient été retirées
  • ce multimètre complétait en réalité le circuit d’alimentation de la télémétrie d’essai au sol de l’engin spatial
  • au moment où les pointes ont été retirées, la connexion d’alimentation de la télémétrie a été coupée

Spirit était vivant, et le matériel a été conservé tel quel

• L’équipe a remis le multimètre dans sa configuration initiale et rallumé l’engin spatial
• La télémétrie est revenue, confirmant que Spirit n’était pas mort
• La perte réelle s’est limitée à quelques heures, puis les essais ont repris
• Pendant les semaines suivantes, l’équipe a analysé le canal H-Bridge du moteur RAT-Revolve, avec une discussion détaillée sur la possibilité d’une demetallization en couche mince
• Au final, le projet a estimé que ce matériel pouvait être utilisé Use As Is
• La préparation au lancement du rover s’est poursuivie et, après l’arrivée de Spirit sur Mars, le moteur RAT-Revolve a fonctionné normalement

La manière de traiter l’expérience de l’échec

• Cet incident a renforcé l’idée que le partage d’expériences d’échec peut être une source d’apprentissage aussi bien pour celui qui raconte que pour celui qui écoute
• Chez Planetary Resources, on demandait aux candidats de partager leur failure story durant le recrutement et dans la culture d’équipe
• Au plus fort de la crise, Ernie a lancé : « La prochaine fois que tu devras approuver quelque chose comme acceptable, souviens-toi de ce que tu ressens maintenant »
• Après l’incident, certains estimaient qu’il fallait arrêter les essais risqués, mais l’importance de vérifier si le moteur fonctionnerait normalement sur Mars a conduit à leur poursuite
• Le chef de projet Pete a laissé la même personne continuer à diriger l’essai, en partant de l’idée que « nous avons payé sa formation, et c’est probablement la personne la moins susceptible de refaire cette erreur »
• La procédure a ensuite été corrigée pour éviter qu’une erreur identique se reproduise, et le même essai a été répété à plusieurs reprises
• Cette expérience est devenue un point de référence, rappelant la peur et les regrets ressentis alors chaque fois qu’il faut donner une approbation ou une garantie importante

[GN⁺]

Avis de Hacker News

• L’article est vraiment très bien écrit.
  En tant qu’ingénieur logiciel, cela me rappelle encore une expérience similaire vécue au début de ma carrière. Il y a une dizaine d’années, j’avais passé plusieurs mois à créer une nouvelle version d’un service web pour un client en conseil, et j’étais chargé du déploiement le jour du lancement. À l’époque, les procédures de développement et de déploiement étaient presque entièrement manuelles. J’avais automatisé ce qui pouvait l’être avec des scripts et du SQL, et au moment où j’ai appuyé sur Entrée pour faire le dernier test avant le déploiement, j’ai réalisé que je venais de basculer sur les identifiants de production.
  Les erreurs s’accumulaient et le service ne répondait plus ; j’étais convaincu d’avoir détruit la base de données, mais quelques heures plus tôt quelqu’un avait terminé une sauvegarde en prévision du lancement, ce qui a permis de restaurer l’essentiel. Depuis, quand je manipule des bases de données et des systèmes de production, dire que je fais attention est un euphémisme, et je me suis juré de ne plus jamais recommencer.

  • Nous aussi, nous avons une architecture d’event sourcing, donc il est rare d’accéder directement à la base de données de production. Quand c’est nécessaire, on ouvre un tunnel via un bastion avec un script shell, qui expose les variables d’environnement standard pour configurer le client Postgres.
    La suite de tests supprime puis recrée ou vide les tables pendant son exécution. Un jour, le lead dev, après avoir investigué un correctif de bug sur la DB de production, a lancé make test. Le code de test a simplement suivi les variables d’environnement et s’est connecté à la production au lieu de Docker, puis a aussitôt supprimé et recréé ces tables de production des dizaines de fois.
  • Il y a une dizaine d’années, dans une mission de conseil, un employé interne responsable d’un autre produit était connecté à la fois à la DB de dev et à la base de données de production dans deux fenêtres différentes, et a supprimé la mauvaise : celle de production. En essayant de restaurer, on a découvert que les sauvegardes échouaient depuis des mois, ce qui a rendu très claire la raison pour laquelle ils avaient engagé des consultants pour aider sur le nouveau produit.
    Heureusement, chaque site client disposait d’une DB locale synchronisée avec la DB centrale, ce qui permettait au produit de fonctionner même avec une connexion interrompue. Il a ensuite enchaîné trois ou quatre longues journées de travail pour reconstruire la base maître en combinant une ancienne sauvegarde et les données des clients.
  • Il m’est arrivé de lancer une migration sur la base de données de production depuis Visual Studio. Avec le recul, c’était récupérable, mais au moment où toutes les tables ont commencé à disparaître dans l’arborescence de VS, j’ai cru que mon cœur allait s’arrêter.
    Une seconde plus tard, elles sont réapparues : la vue venait simplement d’être rafraîchie. Une UI vraiment atroce.
  • Il y a une quinzaine d’années, alors que je m’apprêtais à partir avant un long week-end, une collègue proche au marketing m’a demandé une modification rapide sur le site d’un client. C’était une petite entreprise d’une quinzaine de personnes, avec beaucoup trop de clients pour sa taille, et j’avais un accès à la base de données de production que je n’aurais pas dû avoir.
    Pour modifier le texte marketing d’un produit, j’ai écrit une courte requête UPDATE, et dès qu’elle ne s’est pas terminée immédiatement, j’ai su que j’étais fichu : j’avais mis à jour tout le contenu sans condition, modifiant des milliers de descriptions de produits. L’admin DB qui avait accès aux sauvegardes était dans un autre fuseau horaire et avait déjà quitté le bureau ; après plus d’une heure au téléphone, on a pu restaurer.
    La petite modification rapide en partant s’est transformée en plusieurs heures de réparation. Mon amie du marketing n’arrêtait pas de s’excuser, mais l’erreur était la mienne. Si les clients n’ont rien dit, je pense que c’est parce qu’on était vendredi à 17 h, au début d’un week-end férié.
  • Dans l’endroit où je travaillais il y a une vingtaine d’années, la règle voulait qu’avant d’appuyer sur Entrée pour exécuter une commande sudo, quelqu’un d’autre vérifie la commande. On peut appliquer une politique ou une pratique similaire à tout ce qui se fait en production.

• Cela me rappelle la phrase : si un stagiaire a supprimé la base de données de production, ce n’est pas un mauvais stagiaire, c’est un mauvais processus.
  Il n’est pas facile de trancher entre problème de processus et problème humain, notamment parce qu’on attend davantage d’un employé à temps plein, mais en me mettant à sa place, j’ai été ému en lisant la peur et la douleur au moment où il comprend ce qui s’est passé. Y compris cette sensation où l’espoir, après avoir échoué, revient à la vie. Je n’ai jamais été responsable d’un projet dont dépendaient autant de personnes.
  À mes yeux, ce sont tous des héros.

  • Dans une grande société de courtage, un script de test a touché la production par erreur et créé des millions de dollars de fausses transactions de test sur le marché des changes.
    Lors de l’appel de post-mortem, la première phrase a été : « Nous n’allons pas blâmer la personne qui a créé ces transactions. C’était une erreur honnête. Discutons plutôt de la raison pour laquelle un développeur pouvait appeler l’API de transactions de production sans authentification. »
  • Dans ce type d’échec organisationnel, il ne faut pas blâmer l’individu. Je vois deux problèmes de processus : si l’on pouvait brancher la prise à l’envers, il fallait soit rendre cela impossible dès le départ, soit identifier le risque et faire vérifier l’orientation par au moins deux personnes ; et un outil comme le multimètre utilisé ne devrait jamais pouvoir être déconnecté.
    Blâmer une personne ne fait que la faire licencier et affaiblit toute l’organisation. Cela revient à se séparer de la seule personne qui a appris une leçon coûteuse. On ne devrait tenir un individu pour responsable que lorsqu’il avait l’intention de nuire, et dans ce cas la justice peut intervenir.
  • À mon premier poste de développeur web après l’école, j’ai fait tomber le site web de production dès mon premier jour. Des dizaines de milliers de visiteurs ont été affectés et tous les leads commerciaux se sont arrêtés, mais nous l’avons remis en ligne en quelques minutes, après un moment difficile sous les yeux de toute l’équipe et du CEO dans la pièce d’à côté.
    Quelques années plus tard, au moment de partir, j’avais transformé ce site fragile et instable en un système avec tests automatisés, plusieurs niveaux de sauvegarde, bascule entre plusieurs datacenters, formation et onboarding des nouveaux développeurs. C’était les débuts d’AWS, pas l’époque où un site de production se déployait en un clic.
    Cette expérience m’a poussé à apprendre une bonne gestion de versions, les environnements de développement, Redis, le sharding et le clustering, les VM, la réplication Postgres et MySQL, les wikis, monit, DNS, les load balancers, les reverse proxies, etc. Parce que je ne voulais plus jamais faire tomber le site.
    C’était une petite entreprise qui avait confié son site web de production à un lycéen décrocheur avec un peu d’expérience WordPress, payé 15 dollars de l’heure ; mais après mon erreur, ils ne m’ont pas licencié, ils m’ont donné la liberté et la confiance d’apprendre sur le terrain et d’améliorer le système, et je leur en suis encore reconnaissant.
  • Ce cas est différent. C’était un rover unique sur mesure qui portait un nom pour la première fois, et même s’il y avait déjà toutes sortes de processus, on ne peut pas tout prévoir. Ils ont probablement corrigé le processus ensuite, mais il faut se rappeler que c’était aussi une première pour eux.
    Plus de règles et de meilleurs processus ne sont pas toujours bénéfiques. Parfois, la bureaucratie ralentit encore davantage une NASA déjà lente. Pour une mission d’un type inédit, il arrive qu’il faille s’appuyer sur les personnes plutôt que sur les processus, et accepter le risque.
  • Je ne peux pas m’empêcher de penser à ce qui se serait passé si le rover avait réellement été détruit. Ce qui l’a évité semble relever purement de la chance, et il aurait très bien pu être branché sur une autre mauvaise broche dépourvue de circuit de protection.
    Autrement dit, une partie de l’issue échappait aux compétences de l’auteur, et il y avait tout autant de chances qu’il reste à jamais dans les mémoires comme la personne qui avait ruiné le rover, exactement comme il le craignait.

• Cela résonne fortement avec ma propre expérience. Dans une grande compagnie aérienne, je prenais souvent en charge les projets les plus difficiles et les plus risqués ; l’un d’eux consistait à implémenter rapidement un nouveau prestataire de paiement pour le site web. Ce site vendait chaque jour pour des millions d’euros de billets.
  Quelques secondes après le déploiement, nous avons découvert que j’avais manqué une différence entre l’environnement de test et la production, et qu’une variable clé était vide en production. C’était quelque chose que j’aurais pu anticiper si j’avais lu davantage la documentation et mieux préparé le déploiement : les ventes se sont complètement arrêtées, et j’ai eu un choc. Après une longue procédure de rollback, les ventes ont été interrompues pendant plusieurs heures, des clients furieux ont afflué, et la perte s’est élevée à plusieurs millions d’euros.
  J’ai attrapé le CEO dans l’ascenseur pour lui dire que c’était entièrement ma faute et que j’accepterais toutes les conséquences, y compris un licenciement. Il a souri et m’a répondu en substance : « Pourquoi vous laisserais-je partir ? Nous venons de dépenser des millions pour vous former. Vous ferez mieux votre travail qu’hier. » Cette expérience a été formatrice à bien des égards, notamment sur ce qu’est un vrai leadership, et j’ai ensuite mené à bien de nombreux projets à haut risque.

  • Les phrases sont trop lisses, et certains détails — le fait d’être allé voir directement le CEO, ou l’association entre « meilleur élément » et « l’entreprise a perdu des millions » — paraissent un peu peu crédibles : on dirait que ça a été écrit par un LLM, ou au moins enjolivé.
  • J’ai souvent l’impression que les pages de réservation de billets d’avion sont cassées quelque part plus de la moitié du temps. Pas forcément jusqu’à afficher un écran entièrement blanc, mais assez souvent au point qu’il est impossible de réserver un billet ; à la limite, je préférerais un écran blanc, ça m’éviterait de perdre 30 minutes.
    Internet dans son ensemble est souvent cassé aussi. Pendant un paiement de Black Friday, le webshop de Nike plante, et la solution du helpdesk, c’est en gros : « utilisez l’app ».
  • Les pertes n’étaient peut-être pas aussi importantes qu’on l’imagine. Comme personne ne pouvait acheter de billets pendant quelques heures, on peut dire en théorie que l’entreprise a perdu plusieurs millions de chiffre d’affaires sur cette période, mais cela suppose que les gens ne réessaient pas plus tard.
    En réalité, je ne pense pas qu’une période d’interruption se transforme telle quelle en perte. Les débuts de Twitter étaient souvent indisponibles à cause de sa popularité et de son architecture, mais les gens n’ont pas cessé d’utiliser Twitter pour autant.
    Pour un service en ligne, une panne n’est pas forcément une catastrophe ni la fin de l’entreprise. C’est différent pour du matériel spatial ou pour un logiciel de trading haute fréquence qui peut faire couler une entreprise, mais c’est précisément là qu’il devrait y avoir des garde-fous plus stricts. En théorie, du moins ; en pratique, les secteurs du spatial et du trading haute fréquence font parfois moins bien qu’un service web CRUD bancal construit à partir de bonnes pratiques apprises ailleurs.
  • Si j’étais responsable dans une compagnie aérienne, j’aurais sans doute souhaité une réaction plus proche de l’esprit d’une analyse post-accident aérien : chercher et corriger les causes systémiques.
    Les déploiements en production auraient peut-être besoin d’une personne qui vérifie avec vous, comme un copilote, et qui a le pouvoir d’arrêter le rollout, en plus des protections DevOps habituelles.
  • Ça me rappelle une vieille blague qui se termine par : « Pourquoi vous licencierais-je ? Je viens de dépenser des millions pour vous former ! »
    Les personnes qui prennent en charge des projets à haut risque sont souvent sous-estimées. Beaucoup de managers préfèrent des employés qui ne produisent de manière stable aucune valeur à des employés dont l’espérance de valeur est positive mais avec de la variance.

• Je travaille dans la télévision. Il y a 30 ans, lors de mon premier poste dans une petite chaîne locale, j’ai été formé comme opérateur de bandes pour le journal télévisé. Les bandes de diffusion étaient empilées en gros tas, et il y avait quatre magnétoscopes de lecture. Mon travail consistait à insérer chaque bande et à la caler au point de preroll d’une seconde.
  Quand la lecture d’une bande était terminée et qu’il fallait l’éjecter, il était très facile d’appuyer sur le bouton d’éjection du magnétoscope actuellement à l’antenne, au lieu de celui qui venait de finir. La personne qui me formait produisait un grand signal d’alarme en serrant les dents et en inspirant bruyamment chaque fois que je tendais la main vers le bouton d’éjection ; ce bruit me faisait m’arrêter, vérifier deux ou trois fois, puis seulement éjecter la bande.
  C’était vraiment agaçant, mais efficace pour me conditionner à faire attention. La politique de la chaîne était la suivante : la première éjection d’une bande en direct valait une journée de suspension sans solde, la deuxième une mise à l’épreuve, la troisième un licenciement. Quelques collègues ont perdu leur travail et ruiné des journaux télévisés à cause d’une inattention chronique. Grâce à ce formateur pénible, j’ai appris à vérifier et revérifier, et je n’ai jamais éjecté une bande à l’antenne.

  • Cela explique pourquoi les vieilles compilations d’incidents à l’antenne populaires à la télé au début des années 80 ressemblaient à ça : un journaliste disait quelque chose, tandis que les images en arrière-plan montraient une scène complètement sans rapport.

• Je suis d’accord pour dire qu’une personne qui a fait ce genre d’erreur ne refera jamais la même. Donc licencier quelqu’un qui a techniquement fait une erreur et qui en souffre manifestement est généralement un mauvais choix.
  Mais je ne pense pas que ce soit la « vraie » leçon. Au vu du coût et du risque, la leçon est plutôt que les composants testés avec une forte surtension doivent avoir des connecteurs de test dédiés, incompatibles avec les composants susceptibles de partir en fumée.
  Ce n’est pas un petit projet sur breadboard, mais un énorme projet réalisé par de nombreuses personnes dans une agence gouvernementale, où les procédures officielles coûtent beaucoup de temps et d’argent et suscitent parfois des moqueries. La logique consistant à dire « confions à un jeune de 28 ans un robot à 500 millions de dollars qui peut exploser s’il trébuche » paraît très étrange.

  • Oui, cela aurait dû être conçu de façon à empêcher un mauvais branchement. Je suppose d’ailleurs que la plupart des éléments l’étaient effectivement, mais il peut toujours exister des configurations incorrectes qui n’ont pas été envisagées à la conception.
    En particulier pendant les tests, on manipule souvent des câbles, connecteurs et circuits sur mesure, différents de la « configuration normale ». À mon avis, la leçon est d’appliquer autant que possible le principe des quatre yeux aux opérations critiques. Le fait qu’une personne effectue l’opération et qu’une autre vérifie chaque étape avant de continuer est très efficace pour repérer les « erreurs stupides » comme celle de l’article.
    Cela dit, sous la pression du planning, etc., il n’est pas toujours possible d’avoir deux personnes sur un même test ; dans la réalité, ce genre d’erreur arrive donc. Il faut rendre l’ensemble du système robuste.
  • Au début, je pensais la même chose. Mais si l’on parle d’un équipement à usage unique qui ne sert que pendant un cycle de test ponctuel, le jugement devient difficile.
    En informatique aussi, il existe beaucoup d’opérations similaires, effectuées une seule fois dans le cadre d’une mise à niveau ou d’une migration, sur une base de données de production ou une configuration de routeur. Parfois, le coût de création de garde-fous est supérieur à celui consistant simplement à faire attention dès le départ. Nous ne sommes pas toujours parfaitement attentifs, mais nous ne construisons pas non plus toujours des garde-fous parfaits, et il arrive qu’on fasse une erreur similaire parce qu’on a fait confiance à un garde-fou défectueux.
    Dans la situation racontée, il aurait peut-être fallu l’équivalent matériel du pair programming : un partenaire dont le seul rôle était de vérifier que tout ce que faisait l’auteur était correct. Pas une assistante comme Mary, qui aide en se répartissant les tâches, mais quelqu’un dont l’unique mission est de suivre et de contrôler.
  • En lisant attentivement, l’alimentation est entrée par les fils de sortie de puissance du pont en H, et comme le pont en H est une électronique robuste, rien n’a finalement été endommagé. L’arrêt n’avait rien à voir.
    Si elle était entrée dans les lignes de données du contrôleur moteur, quelque chose aurait très probablement grillé. On ne peut pas exclure que les types de connecteurs aient été différents, mais les deux connecteurs mal raccordés avaient bien été attribués au même type.
  • Lorsque l’humanité a atterri pour la première fois sur la Lune, l’âge moyen des ingénieurs de Mission Control était de 28 ans.
  • Comme je travaille dans ce secteur, je peux expliquer comment ce genre de chose peut arriver. Même sur des projets coûteux, on ne peut pas imposer des connecteurs uniques partout. Les exigences sont en concurrence les unes avec les autres.
    Les connecteurs, en particulier, sont soumis à beaucoup d’exigences conservatrices : produits déjà certifiés, derating précis, pas entre broches, backshell mis à la masse, etc. Au final, seules quelques séries de connecteurs sont utilisées et stockées, et quel que soit le coût engagé, il n’est pas réaliste d’éviter totalement les recouvrements. En général, on standardise les mêmes signaux, ou bien on essaie de les rendre uniques pour qu’ils ne se chevauchent pas.
    Par exemple, les connecteurs externes d’un engin spatial doivent être de type femelle pour éviter les courts-circuits pendant la manipulation, tandis que les faisceaux intermédiaires ne sont jamais retirés et peuvent avoir des connecteurs mâles symétriques. Puis, lorsqu’on a besoin d’une boîte de dérivation de test, il devient possible de la brancher à l’envers.
    Ou bien un côté de la boîte de dérivation peut être un connecteur 100 broches, tandis que l’autre doit être relié à 25 équipements de test. Il n’existe pas forcément 25 connecteurs différents parmi lesquels choisir, et on ne peut pas non plus imposer des exigences sur mesure à tous les équipements de test.
    Les engins spatiaux évoluent de plus en plus vers des microcontrôleurs locaux et des diagnostics locaux, donc ce type d’équipement de test pour tous les signaux analogiques est en train de diminuer. Aujourd’hui, le moteur serait aussi probablement brushless, et au lieu d’une telle boîte de dérivation, on se serait appuyé sur la télémétrie du driver moteur pendant les tests et en vol.
    Les connecteurs aéronautiques et spatiaux deviennent eux aussi plus configurables au moment de la commande, comme dans d’autres secteurs, et l’on peut ajouter des détrompeurs pour que même avec 10 connecteurs « identiques », chacun ne puisse être branché qu’à sa place. Mais exiger que tous les équipements de test soient configurés ainsi reste irréaliste.

• Pour mémoire, j’ajoute aussi mon histoire. Mon premier emploi après l’université était dans une startup de content marketing qui utilisait PHP et PerconaDB (MySQL). Je n’avais pas beaucoup d’expérience en PHP, mais j’avais la confiance infondée d’un débutant. Comme je n’avais pas trouvé de travail pendant six mois après mon diplôme, j’avais aussi très envie de faire bonne impression.
  On m’a chargé de mettre à jour un feature flag afin d’activer une nouvelle fonctionnalité pour tous les clients, à l’exception de ceux qui avaient explicitement demandé à la désactiver. Le flag était stocké dans la base de données sous forme d’un tableau de chaînes contenant les entiers 4 et 5.
  Pour faire ce qu’il fallait, j’ai utilisé la fonction PHP array_reverse, mais je n’avais pas lu la documentation et j’ignorais que, sans second argument, elle inverse les valeurs et non les clés. Résultat : la base de données a été corrompue exactement à l’inverse de ce qu’il fallait, et, bizarrement, c’est passé en QA.
  Je m’en suis rendu compte quelques heures plus tard, et comme à l’époque j’avais près de trois heures de trajet aller, la direction était déjà impliquée à ce moment-là. Un script inverse permettait de corriger facilement le problème, mais cela a révélé plusieurs autres soucis, comme des problèmes de QA et un échec des sauvegardes DB.
  Je me souviens encore, avec gratitude, que le lendemain l’architecte principal est venu me dire que c’était le genre d’erreur qui faisait partie du rite de passage quand on travaille avec PHP, et qu’il l’avait lui-même commise au début de sa carrière. J’ai finalement été licencié ; cela m’a aidé à progresser comme ingénieur, mais sur le moment, et pendant les semaines qui ont suivi, ça m’a clairement démotivé.

  • Ils t’ont licencié pour cette erreur avec array_reverse ?

• Le récit était prenant, mais aussi déroutant
  Cette équipe semble avoir commis non pas une seule erreur, mais plusieurs. On ne sait pas clairement si le résultat aurait pu réellement endommager le vaisseau, ou s’ils ont seulement perdu du temps et semé la confusion en cherchant pourquoi le vaisseau ne s’allumait pas
  La première erreur a été de ne pas comprendre que le multimètre ne faisait pas que mesurer : il fermait le circuit. Cela ressemble à une très mauvaise conception, et si c’était vraiment indispensable, il ne fallait absolument pas toucher à ce multimètre. Ce n’est pas l’erreur d’une seule personne, mais un problème impliquant au minimum deux personnes, ceux qui les encadraient, et les responsables qui avaient autorisé un tel système
  La deuxième erreur concerne la breakout box. Ils ont considéré que l’alimentation avait été envoyée par erreur vers le vaisseau et, quand celui-ci ne s’est pas allumé, ils ont conclu qu’une surtension l’avait endommagé. Mais ils n’étaient pas certains de l’endroit où le courant était réellement passé ni de ce qui avait été endommagé, et au final ils se trompaient
  La raison pour laquelle le vaisseau ne s’allumait pas était qu’ils avaient retiré le multimètre du circuit avant l’incident. La phrase indiquant que plusieurs semaines d’analyse du canal du pont en H du moteur RAT-Revolve et de discussions sur une possible démétallisation de film mince ont suivi reste déroutante : cela voulait-il dire qu’ils pensaient que la surtension erronée avait pu passer par ce canal et l’endommager ?

  • Il manque aussi le fait que Leo, chargé de la télémétrie, n’ait pas signalé la perte de télémétrie avant de dire au narrateur qu’il avait fait une erreur. N’aurait-il pas fallu annuler tous les tests jusqu’au rétablissement de la télémétrie ?
  • Le vaisseau lui-même s’allumait très bien. Comme le multimètre reliait le circuit de télémétrie, ils ne recevaient simplement aucune information tant que ce circuit n’était pas rétabli
    Le courant est effectivement entré dans ce circuit, et ils essayaient de déterminer s’il avait pu l’endommager. Mais comme le driver moteur est censé supporter le courant renvoyé par le moteur, ils ont probablement estimé qu’il n’avait pas été endommagé

• En tant qu’ingénieur en mécanique et en aérospatiale, j’aimerais que mes histoires les plus terrifiantes se limitent au risque de transformer en brique l’ordinateur principal d’un rover inhabité à 500 millions de dollars
  J’étais responsable senior des approbations critiques pour la sécurité sur des systèmes transportant des vies humaines. Après un crash, en regardant des photos de pièces brisées, il fallait encaisser des pensées comme : « et si c’était mon calcul qui était faux ? », « et si c’était mon assemblage qui avait glissé ? », « et si c’était dû à une procédure d’essai inadéquate pour la prédiction de durée de vie en fatigue accélérée ou la fissuration par corrosion sous contrainte ? », « et si on avait précipité la mise en production et qu’on ne l’avait pas détecté avant l’expédition ? »
  Lire des récits d’échecs dans des domaines similaires est intéressant, mais les histoires partagées publiquement sur HN me font penser que le PTSD déclenché par le travail n’est pas une compétition. Pour certains, cela coûte simplement plus cher en thérapie

  • Cela me rappelle un passage d’un roman d’une autrice que j’aime. Un instructeur en soudage vient de raconter une anecdote d’analyse post-mortem, au sens assez littéral, liée à des inspections de sécurité falsifiées, puis dit ceci

    He gathered his breath. “This is the most important thing I will ever say to you. The human mind is the ultimate testing device. You can take all the notes you want on the technical data, anything you forget you can look up again, but this must be engraved on your hearts in letters of fire.

    “There is nothing, nothing, nothing more important to me in the men and women I train than their absolute personal integrity. Whether you function as welders or inspectors, the laws of physics are implacable lie-detectors. You may fool men. You will never fool the metal. That’s all.”

    He let his breath out, and regained his good humor, looking around. The quaddie students were taking it with proper seriousness, good, no class cut-ups making sick jokes in the back row. In fact, they were looking rather shocked, staring at him with terrified awe.
    -- Lois McMaster Bujold, Falling Free

  • J’ai eu la même pensée à propos du dernier paragraphe. Dans le texte original, le passage où il écrit : « je retourne instantanément à ce moment — la pièce, l’éclairage, la chaise sur laquelle j’étais assis, la table, la sensation que l’estomac se vide… » sonnait comme une réaction traumatique
    Tant mieux s’il a pu canaliser cette énergie pour s’améliorer, mais tout le monde ne réagit pas au traumatisme de la même manière, et il n’est pas facile de comparer ces réactions. Par exemple, comme question de recrutement, j’ai l’impression qu’il y a trop de variables sociales en jeu
  • Je me demande si le passage disant qu’il fallait regarder les photos de pièces brisées après un crash en se demandant « et si c’était mon calcul qui était faux ? » finit inévitablement par retomber sur quelqu’un
    Même si c’était un détail que les procédures ne pouvaient pas détecter, il y a bien quelqu’un chargé de créer de bonnes procédures. Il peut y avoir de nombreux facteurs, mais au bout du compte, il semble qu’une personne finisse par porter une responsabilité assez directe
    C’est intéressant à envisager dans des contextes comme l’ingénierie logicielle, ou la société en général, où les erreurs individuelles sont imputées à un collectif
  • J’aimerais sincèrement qu’il y ait davantage de personnes comme vous dans l’aérospatiale, et moins de personnes parmi celles qui ont conçu, implémenté et approuvé le MCAS du Boeing 737 MAX
  • Je suis surpris qu’il n’existe pas de thérapie de groupe pour les ingénieurs, ou alors elle est difficile à trouver. Je ne travaille pas dans un domaine à haut risque, mais j’ai souvent été en position d’écouter des gens de l’aéronautique ou du ferroviaire
    Si l’on a de l’empathie et qu’on n’adopte pas l’attitude « une fois que la fusée est partie, l’endroit où elle retombe n’est pas le problème de mon service », cela peut être assez dur. Ce serait bien qu’il existe des groupes de soutien entre pairs pour les personnes qui conçoivent des systèmes critiques pour la sécurité ou qui gèrent leurs contrecoups. Les entreprises ne fournissent pas toujours un bon accompagnement psychologique
    Les associations d’ingénieurs ou les organismes d’ingénieurs agréés pourraient proposer ce type de service avec les cotisations, mais certains hésiteraient peut-être à y recourir par crainte de perdre leur licence ou leur certification. Autrefois, on aurait peut-être évacué cela au bar avec des collègues en se saoulant, mais la dépendance à l’alcool et les difficultés au travail le lendemain ne sont pas une bonne chose, et la culture du bar n’est plus ce qu’elle était

• Cela me rappelle l’incident où le satellite NOAA-N Prime est tombé parce qu’il n’y avait pas assez de boulons pour le fixer au banc d’essai.
  La cause profonde — corrigez-moi si je me trompe — était que les boulons inspectés aux rayons X utilisés pour fixer le satellite étaient si chers qu’ils avaient été « empruntés » par un autre projet et n’avaient pas été remis en place. Quand le satellite a été basculé à l’horizontale, il est tombé au sol, et les réparations ont coûté 135 millions de dollars.
  https://en.m.wikipedia.org/wiki/NOAA-19

  • Si un erratum ou un addendum à la procédure de basculement ajoute « vérifier les boulons », a-t-on le droit à un peu de sarcasme ?

• Il est intéressant de voir qu’un meilleur tri chronologique dès le départ aurait permis d’éviter l’inquiétude. En comparant l’horodatage des valeurs lues lors du test avec le dernier horodatage du système de télémétrie, on aurait su que la télémétrie avait déjà échoué avant l’exécution du test.
  Le fait de ne pas avoir utilisé d’horodatages précis, au profit de formulations approximatives comme « on dirait que toute la télémétrie du vaisseau spatial vient de se couper il y a un instant », a aussi joué un rôle. La leçon, c’est qu’il faut vérifier correctement comment les événements d’un incident sont exactement reliés. En voyant deux signaux différents, on suppose facilement une causalité dans un sens donné, alors qu’en réalité cela peut être l’inverse.