Depuis mon arrivée en France, je lis davantage sur l’A320 avec mes réflexes d’architecte. Je ne travaille pas en aéronautique, alors je garde une certaine humilité, mais la question est fascinante : comment un système traite-t-il une commande quand un capteur peut se tromper et qu’on ne peut pas simplement redémarrer?

Avec le fly-by-wire, le manche ne déplace pas directement un câble relié à une gouverne. Des capteurs transforment le geste du pilote en signal. Plusieurs calculateurs reçoivent ce signal avec les mesures de vitesse, altitude, accélération et attitude. Selon la loi de pilotage active, ils calculent une consigne, puis des actionneurs hydrauliques déplacent les gouvernes. Des capteurs de retour confirment leur position.

Une commande traverse plusieurs arbitres

En loi normale, le déplacement du manche représente davantage une intention qu’un angle direct de gouverne. Le logiciel peut commander un taux de roulis ou un facteur de charge, stabiliser l’appareil et appliquer des protections d’enveloppe de vol. La chaîne ressemble à ceci :

manche → capteurs → calculateurs → loi de pilotage → servocommandes → gouvernes → réaction de l’avion → nouveaux capteurs

Cette boucle se répète rapidement. Le calculateur compare continuellement la réponse réelle à la consigne. Le dessin évite qu’une simple valeur corrompue commande immédiatement l’avion : plusieurs sources et voies de calcul permettent de détecter des désaccords.

La redondance ne signifie toutefois pas « trois copies identiques et on vote ». Trois composants partageant le même défaut de conception peuvent se tromper ensemble. L’indépendance demande des voies séparées, de l’alimentation distincte, des logiciels ou matériels diversifiés selon les fonctions et des modes de repli étudiés. Il faut aussi décider comment isoler une source jugée incohérente sans éliminer la bonne.

Le mode dégradé doit rester pilotable et compréhensible

Supposons que trois indications de vitesse ne concordent plus. Le système ne peut plus garantir certaines protections qui dépendent d’une vitesse fiable. Il peut dégrader la loi de pilotage, retirer des automatismes et avertir l’équipage. À ce moment, deux choses changent en même temps : le comportement réel de l’avion et le modèle mental du pilote.

L’interface doit donc indiquer ce qui a échoué, ce qui reste disponible et quelles actions sont attendues. Une alarme trop générale fait chercher; une avalanche d’alarmes secondaires peut cacher la cause. Les procédures et l’entraînement servent à reconnaître le mode, pas seulement la panne initiale.

Les ingénieurs analysent les scénarios par gravité et probabilité. Une fonction dont la perte pourrait être catastrophique reçoit des objectifs d’assurance, de séparation et de validation beaucoup plus exigeants qu’un affichage de confort. On teste les valeurs limites, les transitions de modes, les capteurs figés, les pannes intermittentes et les combinaisons crédibles. La question n’est pas seulement « le calcul donne-t-il la bonne valeur? », mais « le système complet reste-t-il contrôlable quand cette valeur manque? ».

Il existe aussi des contraintes physiques que le logiciel ne corrige pas : actionneur coincé, givre sur un capteur, dommage structurel ou alimentation perdue. Une protection est valable dans les conditions pour lesquelles ses entrées restent fiables. Lui attribuer une autorité absolue serait aussi simpliste que de dire que tout repose sur le pilote.

Dans un système critique, je documenterais chaque automatisme avec ses entrées, son autorité, ses hypothèses, son indication de défaillance et son repli. L’aviation rappelle une pratique utile bien au-delà du cockpit : une fonction sûre ne se contente pas de réussir normalement; elle annonce clairement quand elle ne sait plus réussir.