Trois calculateurs donnent-ils vraiment trois protections? Le chiffre rassure sur un diagramme, mais ne dit pas si les trois reçoivent la même mauvaise donnée, partagent la même alimentation ou exécutent le même défaut logiciel. La redondance protège seulement contre les pannes réellement indépendantes.

Une chaîne de commande de vol comprend capteurs, bus, calculateurs, alimentation, actionneurs et affichage. Dupliquer le calculateur sans séparer les autres maillons laisse des points uniques. L’analyse doit donc partir de la fonction — garder l’appareil contrôlable — et remonter toutes les façons de la perdre.

Chercher les causes communes

Prenons trois sources d’une mesure :

1. la première est alimentée par le bus A;
2. la deuxième par le bus B;
3. la troisième possède une alimentation de secours;
4. les câbles suivent des routes physiques distinctes;
5. les calculateurs comparent valeur, tendance et plausibilité.

Cette diversité réduit la panne unique. Elle ne protège pas contre un givre qui touche les trois sondes ou une exigence mal comprise implémentée dans tous les logiciels. Une autre grandeur physique, un chauffage indépendant ou une procédure d’équipage peut fournir un repli plus utile qu’une quatrième copie identique.

Une matrice de défaillances indique pour chaque composant l’effet local, la détection, l’effet système et la mitigation. On teste ensuite une valeur figée, une dérive lente, un message corrompu, une perte intermittente et une panne silencieuse. La dérive plausible est souvent plus difficile à repérer qu’un zéro brutal.

La récupération change la charge de l’humain

Lorsqu’un automatisme se retire, l’équipage reçoit davantage d’autorité et davantage de travail. L’interface doit annoncer la loi active, les protections perdues et les paramètres à surveiller. Une cascade de messages secondaires peut cacher la première cause. Le temps disponible fait partie du design : un repli techniquement possible mais incompréhensible en quelques secondes reste mauvais.

Les changements de mode exigent eux aussi une transition contrôlée. Si le calculateur cessait d’un coup de compenser une commande, l’appareil pourrait réagir avant que le pilote comprenne. Les états, priorités et conditions de retour doivent être déterministes et testables.

La maintenance ferme la boucle. Un composant déclaré en panne doit être isolé, remplacé et vérifié sans que le système parte avec une redondance réduite inconnue. Les journaux de maintenance enregistrent les désaccords et permettent de voir une panne intermittente que le test au sol ne reproduit pas.

Quantifier la couverture sans additionner naïvement

Deux composants fiables à 99,9 % ne donnent pas automatiquement 99,9999 % si leurs pannes sont corrélées. Je représenterais les alimentations, capteurs et logiciels dans un arbre de défaillance. Une porte ET décrit deux pannes nécessaires; une porte OU, une seule suffisante. Les probabilités ne sont multipliées que lorsque l’indépendance est défendable. Les essais et données de maintenance ajustent ensuite les hypothèses. Ce calcul ne prédit pas chaque incident, mais il révèle qu’un câble, une source électrique ou une exigence commune domine encore le risque malgré trois calculateurs affichés dans le diagramme.

Je n’utiliserais donc jamais « redondant » comme propriété autonome. Je demanderais quelle fonction, contre quelle panne, avec quelle indépendance, quelle détection et quel mode dégradé. Cette grille vaut pour un avion, mais aussi pour deux centres de données alimentés par le même réseau ou trois services qui dépendent du même annuaire.