BIBLE MARS — RISQUE & RÉSILIENCE
Anomalie logicielle pendant un blackout Terre-Mars : décider sans téléassistance
Une erreur logicielle critique devient plus dangereuse lorsque le délai ou la coupure de communication empêche toute intervention immédiate de la Terre.
Le défi n’est pas seulement de corriger un logiciel : il faut conserver le système dans un état sûr pendant que le diagnostic est incomplet et que l’expertise terrestre reste hors de portée.
1 — Le délai transforme l’organisation du contrôle
Une équipe terrestre peut analyser, mais elle ne peut pas piloter une boucle d’urgence à la seconde avec des dizaines de minutes aller-retour.
Le véhicule ou la base doit détecter, protéger et stabiliser localement.
2 — Safing : préserver avant d’optimiser
Un mode sûr réduit les fonctions non essentielles et place le système dans un état connu autant que possible.
Le but n’est pas de continuer la mission nominale mais de conserver énergie, thermique, communication et intégrité.
3 — Le logiciel de secours doit être réellement indépendant
Une copie identique possédant le même défaut n’est pas une diversité. Version précédente, chemin simplifié ou contrôleur indépendant peuvent offrir une défense différente selon l’architecture.
La gestion de configuration doit permettre de savoir exactement quelle version tourne.
4 — Les capteurs peuvent rendre le diagnostic ambigu
Si logiciel et capteurs sont tous deux suspects, le système a besoin de mesures croisées et de tests de cohérence.
Une alarme unique ne doit pas déclencher automatiquement une action irréversible sans logique adaptée.
5 — Journaliser pour la Terre sans attendre la Terre
Les données d’événement doivent être conservées afin que l’équipe distante reconstruise la chronologie plus tard.
Mais la décision immédiate appartient aux protections locales et à l’équipage.
6 — Reprendre progressivement
Après stabilisation, réactiver une fonction à la fois limite le risque de réintroduire l’anomalie.
Le retour nominal doit être une procédure testée, pas un simple redémarrage complet.
Scénario combiné — le logiciel doute de ses capteurs pendant que la Terre est muette
Le scénario le plus dangereux n’est pas toujours un ordinateur totalement arrêté. Il peut s’agir d’un logiciel qui continue à fonctionner tout en recevant des mesures incohérentes. Si, au même moment, la liaison Terre-Mars est interrompue, l’équipage ne peut pas attendre qu’une équipe distante tranche le diagnostic.
La première exigence est de séparer « je ne sais pas » de « je sais que c’est dangereux ». Un système bien conçu doit pouvoir déclarer une incertitude, conserver les données brutes et entrer dans un état sûr sans transformer automatiquement chaque capteur douteux en ordre irréversible.
La deuxième exigence est la traçabilité de configuration. Les opérateurs doivent savoir quelle version logicielle tourne, quelles tables de paramètres sont chargées, quelles modifications ont été effectuées et quel paquet de secours a été validé. Revenir à une version antérieure n’est sûr que si cette version est compatible avec l’état actuel du matériel.
La troisième est la possibilité de comparer des chaînes indépendantes. Une mesure de pression peut être confrontée à un débit, une température ou un autre capteur physiquement différent. L’objectif n’est pas de voter aveuglément à la majorité, mais de comprendre quel ensemble de mesures reste cohérent avec la physique du système.
Enfin, toute action locale doit laisser une histoire exploitable lorsque la communication revient : journaux, horodatage, décisions humaines, états avant/après. Sans cette mémoire, l’équipe terrestre ne peut ni comprendre la crise ni corriger durablement la cause.
Ce qu’un mode autonome doit permettre sans assistance terrestre
Le mode autonome doit d’abord conserver les fonctions vitales dans une enveloppe prudente. Cela peut signifier réduire les performances, interdire certaines manœuvres ou arrêter un équipement non essentiel plutôt que chercher immédiatement le rendement nominal.
Il doit ensuite offrir une voie de commande compréhensible par l’équipage. Un opérateur ne peut pas décider correctement si l’interface masque les hypothèses du logiciel. Les capteurs exclus, les seuils actifs et les automatismes désactivés doivent être visibles.
Une troisième barrière est la restauration contrôlée : sauvegarder l’état, vérifier l’intégrité du paquet logiciel, revenir à une configuration connue, puis réintroduire les fonctions une par une. Le redémarrage « tout ou rien » rend le diagnostic plus difficile et peut recréer la panne.
Le système doit aussi tolérer une période sans horloge parfaite ou sans données externes. Les décisions qui dépendent d’informations terrestres indisponibles doivent être identifiées à l’avance, avec une règle locale de substitution ou de suspension.
Enfin, les exercices doivent combiner réellement anomalie logicielle et perte de communications. Tester séparément « le logiciel tombe » puis « l’antenne tombe » ne démontre pas que l’équipage sait gérer les deux en même temps.
Calcul pédagogique — rendre la marge visible
HYPOTHÈSE PÉDAGOGIQUE : délai aller=20 min. Une question envoyée à la Terre exige au minimum ~40 min pour recevoir une réponse, sans compter analyse ni transmission.
Si le système atteint un seuil irréversible en 8 min, attendre la Terre est physiquement impossible : la protection locale doit agir avant.
Même avec 5 min d’analyse au sol, réponse minimale≈45 min. Ce calcul explique pourquoi autonomie et safing ne sont pas des options “premium”.
Questions à ne jamais oublier
- Quel état sûr peut être atteint sans confirmation terrestre ?
- Quelle version logicielle de secours partage le même code ou les mêmes bibliothèques ?
- Quels capteurs indépendants confirment l’anomalie ?
- Combien de minutes avant le premier seuil irréversible ?
- Quelles données doivent être conservées pour l’analyse différée ?