Ce que le test d’un FSTD Boeing 777 de niveau D m’a appris sur les systèmes critiques pour la sécurité

Tester des systèmes critiques pour la sécurité n’a rien à voir avec les tableaux de bord, les pourcentages de couverture ou la vélocité.
C’est une affaire de jugement, de responsabilité et d’intégrité professionnelle.

Je l’ai appris à mes dépens en travaillant sur la vérification de simulateurs de vol à grande échelle, notamment sur les activités de qualification de simulateurs de vol complets Boeing 777 de niveau D. Ce ne sont pas des systèmes académiques. Ils servent à entraîner des pilotes à de vraies situations d’urgence. La fidélité doit être élevée. Les preuves doivent être crédibles. Et lorsque vous apposez votre signature sur des résultats de test et des documents, votre nom engage une vraie responsabilité.

Voici quelques-unes des leçons les plus importantes que j’ai tirées de ce travail, des leçons qui m’ont accompagné dans l’aéronautique, la défense et d’autres environnements réglementés.

1. Les compétences techniques sont importantes, mais les compétences humaines comptent plus qu’on ne le pense

Quand j’ai commencé à travailler sur de grands programmes de simulateurs, je pensais que les plus grands défis seraient techniques. En réalité, bon nombre des problèmes les plus difficiles étaient humains et organisationnels.

Ces systèmes sont construits par de nombreuses équipes spécialisées : ingénieurs avionique, développeurs logiciels, spécialistes des systèmes de mouvement, experts des systèmes visuels, ingénieurs du son, équipes d’intégration, techniciens, et bien d’autres. Les problèmes se rangent rarement proprement dans un seul domaine.

Au début, je me comportais comme beaucoup de testeurs : écrire un ticket, documenter le bug, attendre. Cela ne fonctionnait pas très bien. Ce qui marchait bien mieux, c’était d’aller voir les gens à leur bureau, de discuter du problème en face à face et de déboguer ensemble. Avec le temps, j’ai tissé des relations dans toute l’organisation. Les gens ont cessé de voir en moi « le pilote d’essai qui écrit des tickets » et ont commencé à voir quelqu’un qui les aidait vraiment à résoudre les problèmes.

Au moment de partir, j’avais serré la main de centaines de collègues. Cette confiance rendait tout plus rapide, plus fluide et plus efficace.

Leçon apprise :

1. La communication fait partie du système d’ingénierie.
2. De bonnes relations améliorent la qualité du système.

2. Dire « non » fait partie du métier et de son éthique

L’une des compétences les plus difficiles que j’ai dû développer, c’est de savoir quand dire non. Dans les environnements réglementés, la pression est constante :

• « Pouvez-vous exécuter tous les tests en trois jours ? »
• « Peut-on valider maintenant et corriger les problèmes plus tard ? »
• « A-t-on vraiment besoin de relancer cette campagne ? »

Mais lorsque vous signez de votre nom des artefacts de vérification susceptibles d’être examinés par les autorités de l’aviation, un « oui » a des conséquences. J’ai appris à répondre autrement :

• « Non, je ne peux pas exécuter tout cela en trois jours en toute sécurité. Nous devons discuter des compromis. »
• « Nous pouvons réduire le périmètre ici si nous acceptons formellement ce risque. »
• « Il nous faut plus de ressources, ou alors nous ajustons les attentes. »

Fait intéressant, dans les environnements aéronautiques matures, ce n’est pas perçu comme de l’obstruction. C’est perçu comme du professionnalisme.

Leçon apprise :

1. L’indépendance de la vérification n’est pas seulement une exigence de processus.
2. C’est une responsabilité professionnelle et éthique.

3. Les bons managers lèvent les obstacles, ils ne sont pas obsédés par les tableaux de bord

J’ai vu des organisations investir une énergie énorme dans les KPI, les tableaux de bord, les modèles de maturité et les structures de reporting. Une partie est utile. Mais d’après mon expérience, ce n’est pas cela qui crée la qualité. Les meilleurs managers avec qui j’ai travaillé se concentraient sur :

• lever les blocages ;
• clarifier les priorités ;
• résoudre les conflits entre équipes ;
• garantir l’accès aux bancs et aux environnements ;
• protéger l’équipe du bruit.

Ils ne demandaient pas de plus beaux graphiques. Ils demandaient ce qui nous ralentissait et aidaient à y remédier.

Leçon apprise :

1. Dans un travail de vérification complexe, le flux compte plus que les métriques.
2. La qualité du leadership se mesure aux obstacles levés, pas aux rapports produits.

4. Impliquer le test dès les exigences et la conception évite bien des souffrances plus tard

J’ai perdu le compte du nombre de fois où j’ai vu ce scénario :

• Les exigences semblent claires à leur auteur.
• L’architecture paraît élégante sur le papier.
• Tout semble « terminé ».
• Puis la vérification commence… et les problèmes explosent.

Certaines exigences se révèlent ambiguës dès qu’on essaie de les tester.
Certaines architectures sont logiquement cohérentes mais, en pratique, impossibles à tester.
Certains systèmes manquent d’observabilité, si bien que les défaillances sont impossibles à diagnostiquer.

Dans les projets où la vérification était impliquée tôt (pendant la rédaction des exigences, les discussions sur les interfaces, les choix d’architecture), les problèmes en aval diminuaient de façon spectaculaire.

Leçon apprise :

1. La testabilité n’est pas une question de test.
2. C’est une propriété de la conception.

5. À un moment donné, j’ai cessé de trop me fier au planning de test

Au début de ma carrière, j’ai mis beaucoup d’énergie dans la rédaction de plannings de test détaillés. Avec le temps, la réalité n’a cessé de me prouver une chose dérangeante : le planning ne survivait presque jamais intact. Le plan de test, le document qui décrit les outils, les processus, les responsabilités et la stratégie de vérification, restait stable. C’était voulu. Mais pour le planning, c’était une autre histoire :

• La maturité du matériel changeait.
• L’ordre d’intégration changeait.
• Des outils tombaient en panne.
• Les dépendances évoluaient.
• Des comportements inattendus apparaissaient.

J’ai fini par changer d’approche. Au lieu de surinvestir dans des plannings figés, je me suis davantage concentré sur l’évaluation continue de la situation :

• Quel est le plus grand risque en ce moment ?
• Qu’est-ce qui a changé depuis la semaine dernière ?
• Où avons-nous besoin de profondeur, et où un test superficiel est-il acceptable ?

Cet état d’esprit a conduit à de meilleures décisions que de suivre aveuglément des plans dépassés.

Leçon apprise :

1. La discipline, ce n’est pas suivre le planning.
2. La discipline, c’est s’adapter en continu au risque et à la réalité.

6. L’analyse des causes racines distingue les équipes matures des équipes simplement occupées

Sous la pression du temps, il est facile de se contenter de corriger les symptômes. Mais dans les environnements critiques pour la sécurité, c’est une habitude dangereuse. J’ai appris la valeur d’une documentation précise des défauts et d’une classification qui a du sens. Au lieu d’écrire « Erreur logicielle », nous notions :

• « Pointeur hors limites dans une boucle »
• « Race condition pendant l’initialisation du bus »
• « Timeout sur un socket sous charge »

Ce niveau de précision permettait une vraie analyse. Des schémas émergeaient. Les causes racines étaient traitées. Les récurrences diminuaient.

Leçon apprise :

1. De bonnes données sur les défauts, ce n’est pas de la bureaucratie.
2. C’est de l’apprentissage organisationnel.

7. Le travail sur des systèmes critiques change votre façon de penser, pour de bon

Travailler sur des systèmes d’avion, des simulateurs et dans des environnements réglementés vous transforme. Vous devenez moins tolérant envers :

• les exigences vagues ;
• les hypothèses non vérifiées ;
• la documentation faible ;
• la conformité de façade.

Et plus attentif à :

• la traçabilité ;
• les preuves ;
• la clarté ;
• la responsabilité ;
• les conséquences à long terme.

Cet état d’esprit ne vous quitte plus. Il fait partie de la manière dont vous abordez n’importe quel système complexe, quel que soit le domaine.

Leçon apprise :

1. L’expérience des systèmes critiques n’est pas seulement une expérience technique.
2. Elle façonne le jugement professionnel.

Pourquoi ces leçons comptent toujours

Les outils évoluent. Les technologies évoluent. Les méthodes évoluent. Mais les réalités fondamentales, elles, ne changent pas.

• Les systèmes complexes sont construits par des humains.
• Les humains font des hypothèses.
• Les hypothèses doivent être remises en question.
• Les preuves doivent être tenues à jour.
• La responsabilité doit être prise au sérieux.

Qu’il s’agisse d’aéronautique, de défense, de dispositifs médicaux ou d’infrastructures critiques, le schéma sous-jacent est le même. La qualité d’un système reflète en fin de compte la maturité des personnes qui le construisent et le vérifient.

Réflexion finale

Travailler sur des simulateurs de Boeing 777 m’a fait connaître l’avion en profondeur. Mais surtout, cela m’a appris ce que signifie vraiment la responsabilité en ingénierie.

Elle ne réside pas dans les outils.
Elle ne réside pas dans les tableaux de bord.
Elle ne réside pas dans les frameworks de processus.

Elle réside dans la manière dont les ingénieurs :

• communiquent ;
• s’opposent quand il le faut ;
• décident ;
• documentent ;
• collaborent ;
• assument leurs responsabilités.

C’est ce qui protège les utilisateurs au bout du compte, qu’il s’agisse de pilotes dans un cockpit, d’opérateurs dans une salle de contrôle ou de quiconque compte sur des systèmes critiques pour la sécurité pour fonctionner correctement au moment où cela compte le plus.