BIBLE MARS — DOSSIER RISQUE & RÉSILIENCE
Panne de cause commune : pourquoi deux systèmes de secours peuvent tomber ensemble
La redondance protège contre des pannes indépendantes ; elle protège beaucoup moins lorsque les secours partagent la même faiblesse.
Une cité martienne pourrait multiplier les doublons et rester fragile. Si deux pompes identiques ont le même défaut, si deux ordinateurs partagent le même logiciel ou si trois lignes électriques passent dans le même local, une seule cause peut éliminer toute la redondance.
Redondance ne veut pas dire indépendance
Une panne de cause commune produit plusieurs défaillances à partir d’un même événement ou d’un même processus. NASA souligne qu’une cause commune peut éliminer tout un ensemble redondant et que l’ajout d’unités identiques apporte alors de moins en moins de fiabilité.
La première question à poser à toute architecture « N+1 » est donc : qu’est-ce qui est réellement différent ? Même alimentation, même logiciel, même fournisseur, même local, même refroidissement et même procédure de maintenance sont autant de dépendances cachées.
Exemple pédagogique : trois pompes identiques
Supposons trois pompes capables chacune d’assurer la circulation d’eau. Si leurs pannes aléatoires sont indépendantes, trois pompes offrent une bonne tolérance. Mais si un lubrifiant inadapté, un contaminant ou un défaut de conception attaque les trois, la troisième pompe n’est pas une troisième barrière : elle répète la même vulnérabilité.
C’est pourquoi la diversité peut compter autant que le nombre : technologies différentes, fournisseurs différents, séparation physique ou solution de secours plus simple et réparable.
Causes communes physiques, numériques et humaines
Une inondation locale, un incendie, une surtension ou un choc peuvent toucher plusieurs équipements voisins. Un bug logiciel peut agir simultanément sur tous les calculateurs qui exécutent le même code. Une procédure de maintenance erronée peut introduire la même erreur sur plusieurs équipements.
Même l’équipage peut être une cause commune : fatigue, formation insuffisante ou mauvaise documentation peuvent conduire plusieurs opérateurs à répéter la même action incorrecte.
Diversité + séparation + réparabilité
La réduction du risque passe par la diversité des composants lorsque justifiée, la séparation physique, l’évitement des bus communs inutiles, la protection contre les événements externes et la capacité à passer à un mode plus simple.
NASA a aussi étudié la redondance diversifiée pour le support-vie : l’idée est qu’un secours différent puisse survivre à la cause qui détruit l’équipement principal. Sur Mars, cette logique doit être couplée à la réparation locale.
Audit de cause commune
Chaque fonction vitale doit être dessinée sous forme de graphe de dépendances. On marque les nœuds partagés : alimentation, logiciel, salle, refroidissement, réseau, capteur de référence, maintenance, consommables. Puis on provoque mentalement la perte de chaque nœud.
- ne pas compter deux fois une redondance partageant le même maillon ;
- séparer les fonctions réellement critiques ;
- introduire une voie de secours diversifiée ;
- tester l’erreur de maintenance et le bug commun ;
- conserver une solution manuelle ou simplifiée quand elle apporte une vraie indépendance.
Petit calcul de fiabilité : indépendance contre cause commune
Dans un exemple volontairement simplifié, si deux équipements ont chacun 1 % de probabilité de panne et que leurs pannes sont réellement indépendantes, la probabilité qu’ils tombent tous les deux en panne est 0,01 × 0,01 = 0,0001, soit 0,01 %. Mais si une cause commune possède à elle seule une probabilité de 0,1 %, le risque total ne peut pas descendre en dessous de ce plancher simplement en ajoutant des copies identiques. Les nombres sont pédagogiques ; le mécanisme est le point important.
Le dossier doit aussi conserver une séparation stricte entre une donnée mesurée, une valeur publiée, une hypothèse de conception et un scénario d’enseignement. Mélanger ces statuts donnerait une précision trompeuse.
Du calcul au plan d’action
Ce qu’il faut tester avant d’en dépendre
Les résultats alimentent ensuite les stocks, les procédures et la conception. La sûreté devient ainsi une boucle d’apprentissage et non un document figé produit avant la mission.
Questions de décision propres à ce risque
- Les secours utilisent-ils réellement des alimentations différentes ?
- Même fournisseur, même lot de fabrication ou même défaut de conception ?
- Même logiciel, même configuration ou même capteur de référence ?
- Même local, refroidissement, maintenance ou consommable ?
- Quelle voie simplifiée et diversifiée fonctionne encore si toutes les copies identiques sont considérées perdues ?
Ce dossier dans la cité
Sources scientifiques et techniques
Les sources ci-dessous qualifient les phénomènes et briques de sûreté ; l’architecture de cité reste une synthèse prospective explicitement signalée.
- NASA NTRS — Common Cause Failures Dominate and Defeat Redundancy
- NASA NTRS — Diverse Redundant Systems for Reliable Space Life Support