Le Salon du Bourget vient de se terminer et l’aéronautique européenne est difficile à ignorer depuis Paris. Je ne travaille pas dans ce domaine, mais le fly-by-wire m’intéresse comme architecture : la panne n’est pas un ticket qu’on ouvre après le vol, c’est une entrée du design.

Une commande du pilote devient un signal lu par plusieurs calculateurs. Ceux-ci reçoivent aussi vitesse, altitude, attitude et accélération, appliquent la loi active, puis commandent des actionneurs. Des capteurs de position ferment la boucle. La fonction utile dépend donc de plusieurs chaînes d’énergie, de mesure, de calcul et d’affichage.

Le vote ne suffit pas

Supposons trois sondes mesurant une grandeur. Les valeurs sont 250, 251 et 410. Une logique de comparaison peut isoler 410 et retenir les deux valeurs cohérentes. Si deux sondes givrent de la même façon et indiquent 180, le vote majoritaire peut toutefois rejeter la seule bonne. Il faut considérer les défaillances de cause commune, pas seulement compter les composants.

Une stratégie de détection combine plusieurs vérifications :

1. comparer les sources entre elles;
2. vérifier la vitesse de variation et les limites physiques;
3. confronter la mesure à d’autres capteurs indépendants;
4. marquer chaque valeur avec un état de validité;
5. retirer les fonctions qui ne peuvent plus garantir leurs hypothèses.

Quand les données nécessaires manquent, le système passe d’une loi normale à un mode dégradé. Certaines protections disparaissent et la relation entre le manche et les gouvernes change. Le logiciel doit effectuer cette transition sans produire une commande brutale; le cockpit doit annoncer le nouveau mode assez clairement pour que l’équipage adapte son pilotage.

Le repli fait partie de l’interface

Une alarme n’est pas seulement un message. Elle doit permettre de distinguer la cause des conséquences. Une panne de capteur peut déclencher plusieurs défauts secondaires; les présenter sans priorité surcharge l’équipage. Les procédures associent donc des configurations connues à des actions et limitations connues.

Les essais doivent injecter des pannes : valeur figée mais plausible, intermittence, perte d’alimentation, calculateur silencieux, bus corrompu et combinaison de défaillances crédibles. On vérifie le résultat fonctionnel, le temps de détection, la transition de loi et ce que l’équipage voit. Tester uniquement chaque composant isolé manquerait les interactions.

La diversité matérielle ou logicielle réduit certains défauts communs, mais complique la validation. Deux implémentations indépendantes peuvent aussi diverger aux limites. Chaque voie doit avoir une autorité définie et une façon sûre d’être isolée.

Une preuve attendue à chaque transition

Pour valider ce repli, je ne regarderais pas seulement la sortie du calculateur. Je synchroniserais les trames reçues, l’état de validité des capteurs, la loi choisie, la commande envoyée aux actionneurs et l’indication du cockpit. Le test injecte une panne à un instant connu, puis compare le délai de détection et l’ordre des événements. Une horloge décalée entre composants pourrait faire croire que l’alarme précède la faute. Les journaux doivent donc partager une référence temporelle et rester disponibles pour l’analyse de maintenance. Cette chaîne de preuve permet de distinguer un mauvais capteur, une décision logicielle erronée et une indication arrivée trop tard.

La leçon que j’emprunte à l’aviation est pratique : pour chaque automatisme critique, écrire ses entrées valides, son comportement nominal, les preuves de désaccord, le mode de repli et le signal présenté à l’humain. Une architecture tolérante aux pannes ne promet pas que rien ne cassera; elle s’assure que la prochaine action reste possible et compréhensible.