Guidage, navigation et contrôle : le système nerveux d’un véhicule martien

Guidage, navigation et contrôle : trois métiers qui ne doivent pas être confondus

Le sigle GNC réunit trois fonctions parce qu’elles travaillent ensemble, mais les confondre masque les responsabilités. La navigation estime l’état du véhicule : position, vitesse, attitude, biais et incertitudes. Le guidage décide où il faut aller et transforme l’objectif de mission en trajectoire admissible. Le contrôle compare cette trajectoire à l’état réel et produit les commandes destinées aux actionneurs.

Cette séparation permet de comprendre une panne. Si le véhicule croit être ailleurs qu’en réalité, le problème vient probablement de l’estimation ou des capteurs. Si l’état est bon mais l’objectif est mal converti en trajectoire, le guidage est en cause. Si la consigne est correcte mais le véhicule ne la suit pas, il faut regarder contrôle, moteurs, roues de réaction, freins ou autres actionneurs.

Un bon GNC n’est donc pas un « pilote automatique » monolithique. C’est une chaîne de modèles, mesures, décisions et actions avec des interfaces vérifiables. Cette modularité aide aussi la qualification et le mode dégradé : on peut changer de source de navigation sans réécrire toute la logique de guidage.

Sur Mars, le GNC ne concerne pas seulement les vaisseaux. Rovers rapides, grues, drones, convoyeurs, bras robotisés et véhicules de chantier possèdent tous des boucles où une mauvaise estimation peut devenir un accident physique.

La navigation répond à la question 'où suis-je et comment est-ce que je bouge ?'. Le guidage répond 'où dois-je aller et quelle trajectoire respecte mes contraintes ?'. Le contrôle répond 'quelle commande appliquer maintenant pour suivre cette trajectoire ?'. Mélanger ces fonctions rend les pannes difficiles à comprendre. Un véhicule peut connaître parfaitement sa position mais recevoir un objectif impossible ; ou posséder un excellent guidage mais ne plus disposer d’un actionneur capable de suivre la commande.

Cette séparation aide aussi à concevoir les responsabilités logicielles. Un estimateur de navigation peut publier un état et sa covariance ; le guidage peut construire une référence ; le contrôleur peut vérifier saturations et limites avant d’envoyer l’ordre. Des interfaces claires permettent de tester chaque couche et de mettre en place des solutions de repli différentes selon la panne.

L’état du véhicule : une vérité calculée à partir de mesures imparfaites

Un ordinateur de bord ne connaît jamais directement sa position ou son orientation. Il reçoit des mesures : accélérations, rotations, étoiles, images, altitude, vitesses radio, pression, positions mécaniques. Ces mesures possèdent bruit, biais et parfois des pannes. L’estimateur fusionne ces informations avec un modèle dynamique.

L’incertitude doit voyager avec l’état. Une position de 100,0 m affichée sans marge est trompeuse si la vraie incertitude est ±200 m. Les filtres de Kalman, filtres étendus et autres méthodes servent notamment à propager cette incertitude et à corriger la prédiction lorsque de nouvelles observations arrivent.

La cohérence entre capteurs est une défense. Si deux sources s’écartent, le système ne doit pas nécessairement voter à la majorité. Il examine la dynamique attendue, l’historique, la qualité de chaque mesure et les pannes connues. Une fausse donnée très précise peut être plus dangereuse qu’une donnée honnêtement incertaine.

Cette logique justifie le mot FDIR — Fault Detection, Isolation and Recovery. Détecter une anomalie ne suffit pas : il faut identifier autant que possible ce qui est fautif, isoler son influence puis reconstruire une fonction acceptable avec les ressources restantes.

L’état n’est pas une lecture unique. Position, vitesse, attitude, vitesses angulaires, masse, parfois vent ou paramètres de terrain sont estimés à partir de capteurs qui possèdent bruit, biais et délais. La navigation construit donc une vérité opérationnelle à partir d’informations imparfaites. La covariance indique à quel point cette vérité est incertaine et comment les erreurs sont corrélées.

Les valeurs doivent également être horodatées avec précision. Une position vieille de deux secondes n’est pas la position actuelle d’un véhicule rapide. C’est pourquoi PNT, réseau et GNC se rejoignent : mesure, temps de mesure et qualité de la mesure doivent voyager ensemble. Une donnée sans métadonnée d’incertitude peut être plus dangereuse qu’une absence de donnée.

L’estimation peut aussi inclure des paramètres qui ne sont pas directement observés : coefficient de frottement, vent effectif, masse restante ou biais d’un capteur. Ces variables dites augmentées permettent au système d’adapter son modèle à la réalité. Mais ajouter trop de paramètres peut rendre l’estimateur mal observable, c’est-à-dire incapable de distinguer plusieurs causes produisant des effets similaires. L’ingénierie consiste donc à choisir ce qu’il faut estimer et ce qu’il vaut mieux borner par conception.

La notion d’observabilité rappelle qu’un capteur n’est utile que par rapport à la question posée. Un altimètre mesure une distance au sol mais ne donne pas à lui seul une position horizontale ; un star tracker donne une attitude, pas une vitesse. La robustesse vient de la complémentarité des mesures, pas du simple nombre de capteurs.

Le guidage : transformer une intention en trajectoire physiquement possible

« Va jusqu’à ce point » n’est pas une commande directement applicable à un moteur. Le guidage doit générer un chemin compatible avec énergie, vitesse, terrain, charges, réserves et zones interdites. Pour un atterrisseur, il doit respecter corridor, carburant et capacité de poussée ; pour un rover, pentes, adhérence, obstacles et autonomie énergétique.

Le guidage travaille donc avec des contraintes. Une trajectoire optimale au sens mathématique peut être rejetée parce qu’elle laisse trop peu de marge à un capteur ou traverse une zone où aucune communication de secours n’est possible. Le mot « optimal » n’a de sens qu’après avoir déclaré ce que l’on optimise et ce que l’on interdit.

En situation dégradée, le guidage change d’objectif. Il peut renoncer à la destination et privilégier une zone sûre, une balise, un arrêt ou un retour. Cette reconfiguration doit être prévue avant la panne afin d’éviter qu’un algorithme nominal tente obstinément d’atteindre un objectif devenu dangereux.

À l’échelle d’une cité, des couches de guidage peuvent même intégrer règles de circulation, priorité aux secours, zones de poussière ou corridors réservés aux engins lourds. Le GNC devient alors une composante de l’infrastructure urbaine.

Un objectif humain peut être simple — 'atterris près de la base', 'rejoints le rover', 'maintien l’antenne vers la Terre'. Le guidage doit le traduire en une trajectoire compatible avec carburant, vitesse, pente, obstacles, chauffage, accélération et zones interdites. Il résout donc un problème de contraintes, pas seulement une ligne droite entre deux points.

Lorsque l’environnement change, le guidage peut replanner. Mais replanner n’est pas toujours autorisé : pendant certaines phases, un changement tardif crée plus de risque qu’il n’en réduit. Les architectures sérieuses définissent donc des fenêtres de décision, des critères d’abandon et des objectifs de secours. L’autonomie doit savoir quand modifier la mission et quand conserver un plan robuste.

Le contrôle : fermer la boucle assez vite pour que la physique n’ait pas déjà gagné

Le contrôle reçoit une consigne et un état estimé, calcule l’erreur puis demande une action. La fréquence de cette boucle dépend du phénomène. Un système thermique peut évoluer lentement ; un moteur, une attitude ou un drone exigent des décisions rapides. Le délai de calcul, de capteur et d’actionneur fait partie de la stabilité.

Une boucle à 10 Hz possède une période de 0,1 s. Même le plus petit délai Terre–Mars de plusieurs minutes correspond à des milliers de périodes : la boucle ne peut donc pas traverser la Terre. Les opérateurs terrestres définissent objectifs et limites, mais l’asservissement réel reste local.

Les actionneurs possèdent des saturations. Un moteur ne peut pas produire une poussée infinie, une roue de réaction peut saturer, un frein possède une limite thermique. Un contrôleur qui ignore ces limites peut commander quelque chose de physiquement impossible et accumuler une erreur dangereuse.

La validation doit donc inclure les non-linéarités, délais, saturations, bruit et scénarios hors nominal. « Le logiciel converge dans une simulation idéale » n’est que le début de la preuve.

Le contrôleur compare une consigne à l’état estimé et produit une commande. Sa fréquence dépend de la dynamique : stabiliser un véhicule en vol demande des décisions bien plus rapides que maintenir la température d’un réservoir. Une boucle trop lente laisse l’erreur grandir ; une boucle trop agressive peut exciter la structure, saturer les actionneurs ou devenir instable.

Les limites physiques doivent donc être explicites. Une roue de réaction sature, un moteur ne descend pas forcément à zéro poussée, une vanne possède un temps de réponse, un rover ne peut tourner instantanément sur un terrain glissant. Un modèle de contrôle qui ignore ces limites peut être mathématiquement élégant et opérationnellement faux.

Les contrôleurs industriels et spatiaux utilisent souvent des structures hiérarchiques. Une boucle interne rapide stabilise attitude ou courant moteur ; une boucle plus lente suit trajectoire ou vitesse ; un superviseur encore plus lent modifie les objectifs. Cette architecture permet de respecter les différentes échelles de temps du système. Elle rejoint exactement la logique de la latence Terre–Mars : les décisions les plus rapides doivent se fermer localement.

La saturation mérite une attention particulière. Lorsque l’actionneur atteint sa limite, le contrôleur ne dispose plus de l’autorité supposée par ses équations. Si le logiciel continue d’intégrer l’erreur comme si la commande était réalisable, il peut accumuler une correction excessive. Les mécanismes d’anti-windup, les limites de commande et la gestion explicite de la réserve d’autorité sont donc des détails très concrets de sûreté.

FDIR et mode sûr : survivre à une mesure fausse plutôt qu’à une simple panne franche

Les pannes faciles sont celles qui annoncent clairement leur disparition. Les pannes difficiles continuent de produire des valeurs plausibles. Un capteur d’altitude bloqué, une caméra qui associe le mauvais terrain ou un actionneur partiellement dégradé peut tromper la logique pendant plusieurs secondes critiques.

FDIR organise la réaction : détecter qu’un comportement est incohérent ; isoler l’équipement ou la donnée suspecte ; reconfigurer vers une voie de secours ; vérifier que la fonction récupérée est suffisante. La décision peut aussi être de ralentir ou d’abandonner une manœuvre.

Le mode sûr n’est pas nécessairement « tout arrêter ». Dans l’espace, arrêter un chauffage peut tuer l’électronique ; pendant un atterrissage, arrêter les moteurs est impossible. Le mode sûr dépend donc de la phase et du temps disponible. Un rover peut se figer ; un atterrisseur doit continuer à agir.

Pour une base martienne, la philosophie FDIR s’étend aux systèmes industriels. Un convoyeur, une centrale électrique ou un robot de maintenance doit pouvoir se mettre dans un état qui limite le dommage sans attendre un diagnostic terrestre.

La panne franche est parfois la plus facile : un capteur cesse de répondre. Le cas difficile est le capteur qui continue à envoyer une valeur plausible mais fausse. Le FDIR compare capteurs, modèles et limites physiques pour détecter les incohérences, isoler la source et choisir une configuration de secours. La redondance n’aide que si les voies ne partagent pas toutes la même cause commune.

Le mode sûr doit être conçu avant la panne. Il ne signifie pas forcément 'arrêter tout'. Un véhicule peut orienter ses panneaux, conserver thermique et communication, réduire les mouvements et attendre un diagnostic. Un habitat peut isoler une boucle et maintenir les fonctions minimales. La sûreté vient de la capacité à réduire l’ambition tout en protégeant l’essentiel.

La panne la plus difficile est la donnée plausible et fausse

Un capteur qui ne répond plus est facile à identifier. Un capteur qui fournit une valeur cohérente mais biaisée est plus dangereux. Imaginez une centrale inertielle dont un axe dérive lentement, ou un capteur de position qui utilise une mauvaise référence temporelle. Le système peut continuer à produire une trajectoire « propre » tout en s’éloignant de la réalité.

Le FDIR — détection, isolation et récupération après panne — doit donc comparer des sources indépendantes et surveiller des résidus : la différence entre ce que le modèle prédit et ce que les capteurs observent. Une anomalie persistante peut entraîner la mise à l’écart d’un capteur, l’augmentation de l’incertitude ou le passage en mode sûr. La bonne réaction n’est pas toujours de continuer avec la meilleure estimation ; parfois il faut s’arrêter.

Le mode sûr n’est pas un bouton, c’est une philosophie de survie

Un mode sûr doit réduire le nombre de choses qui peuvent empirer. Pour un véhicule orbital : stabiliser l’attitude, garantir l’énergie, maintenir le thermique et préserver une voie de communication. Pour un rover : s’arrêter sur un terrain acceptable, conserver de l’énergie, protéger les batteries et attendre une meilleure solution de navigation. Pour une infrastructure urbaine : isoler une vanne, désactiver une commande automatique et maintenir les fonctions vitales.

Chaque mode sûr doit lui-même être testé comme un système réel. Une logique de sauvegarde rarement utilisée peut contenir un défaut latent. La simulation et les essais hardware-in-the-loop sont donc essentiels : ils confrontent le logiciel à du matériel, des délais et des erreurs qui ne ressemblent pas à un modèle parfait.

Tester le GNC : du modèle mathématique au matériel qui chauffe, vibre et vieillit

La validation progressive évite de découvrir trop tard qu’un algorithme correct dépend d’un capteur irréaliste. On commence par modèles et simulations, puis software-in-the-loop, hardware-in-the-loop, essais de composants, intégration, campagnes environnementales et scénarios d’anomalies injectées. Chaque niveau cherche une famille différente d’erreurs.

Les bancs hardware-in-the-loop sont précieux parce qu’ils connectent le logiciel de vol à du matériel réel ou représentatif tandis qu’un simulateur reproduit le monde extérieur. On peut imposer des retards, pertes de capteurs, saturations et défauts sans sacrifier un véhicule.

La configuration doit être figée : version logicielle, tables, calibration, paramètres de filtre, firmware, capteurs et actionneurs. Une réussite avec une configuration A ne qualifie pas automatiquement la configuration B. Cette discipline devient encore plus importante lorsque des pièces locales ou réparées apparaissent sur Mars.

À long terme, la base devra posséder ses propres moyens de test. Réparer un actionneur sans pouvoir vérifier sa réponse dynamique ne donne pas une vraie autonomie. Le GNC relie donc logiciel, métrologie et industrie locale.

La simulation pure permet d’explorer des milliers de scénarios, mais elle ne reproduit pas automatiquement les délais de bus, les saturations, les quantifications, les défauts de câblage et les comportements thermiques. Les essais hardware-in-the-loop remplacent une partie du modèle par du matériel réel tout en simulant le reste du véhicule. Ils permettent de découvrir des erreurs d’interface qui n’existent pas dans un modèle idéal.

La validation doit aussi inclure les cas dégradés : capteur intermittent, donnée retardée, moteur moins puissant, masse différente, image aveuglée, réseau saturé. Une architecture robuste ne prouve pas seulement qu’elle fonctionne dans le cas nominal ; elle cartographie les régions où elle cesse d’être fiable et définit ce que le système doit faire en approchant de ces frontières.

La campagne de test doit construire une chaîne de confiance. Simulation Monte-Carlo pour explorer les dispersions, tests logiciel-in-the-loop pour vérifier l’algorithme, hardware-in-the-loop pour les interfaces, essais sur banc pour les actionneurs et finalement démonstrations intégrées. Chaque niveau révèle une famille différente de défauts. Aucun niveau isolé ne suffit à qualifier le comportement global.

La maintenance logicielle après arrivée pose une autre question : comment modifier un système dont la sécurité dépend précisément de ce qui a été validé ? Les mises à jour doivent être versionnées, testées sur une représentation de référence, déployées progressivement et réversibles. Une colonie ne peut pas traiter le logiciel de vol comme une application qui se met à jour automatiquement pendant la nuit.

Tester l’autonomie revient à chercher les cas où elle a raison pour les mauvaises raisons

Un test classique vérifie qu’une commande produit la trajectoire attendue. L’autonomie nécessite une question supplémentaire : le système a-t-il choisi cette action pour les bonnes raisons ? Un algorithme peut atteindre l’objectif malgré un capteur mal calibré grâce à une compensation accidentelle. Le test doit donc injecter pannes, valeurs plausibles mais fausses, délais, messages contradictoires et changements de mission.

Les scénarios les plus précieux sont ceux qui obligent l’algorithme à renoncer. Une autonomie crédible sait quand elle ne possède plus assez d’information pour agir. Cette propriété — refuser une action malgré la pression de l’objectif — est souvent plus difficile à démontrer que la performance nominale.

L’autonomie décisionnelle : déplacer l’intelligence sans déplacer aveuglément l’autorité

Le délai interplanétaire force certaines décisions à bord, mais il ne justifie pas une autonomie sans limites. Une architecture peut séparer décisions réflexes, décisions tactiques et décisions stratégiques. Les réflexes restent dans les boucles de contrôle ; le tactique peut appartenir au véhicule ou à l’équipage ; le stratégique peut être partagé avec la Terre selon le temps disponible.

Cette hiérarchie rend l’autonomie vérifiable. On peut définir ce qu’un robot a le droit de faire seul, quelles ressources il peut engager, quels seuils imposent un arrêt et quelles situations exigent l’autorisation humaine. Les journaux permettent ensuite d’expliquer pourquoi il a choisi une action.

NASA expérimente depuis des années des opérations plus autonomes précisément parce que le délai de communication augmente avec la distance. Les travaux d’autonomie ne cherchent pas seulement à remplacer des humains : ils cherchent à préserver une mission lorsque les humains ne peuvent pas intervenir assez vite.

Pour une cité, cette question devient politique : quelles décisions sont automatisables, quelles décisions doivent rester humaines, et quelles décisions peuvent être prises localement sans la Terre ? Le GNC technique conduit naturellement à une réflexion sur l’autorité.

Mars exige que beaucoup de décisions descendent vers le véhicule ou l’équipage, mais toutes les décisions n’ont pas la même portée. L’autonomie de perception peut être très large : détecter un obstacle, diagnostiquer un capteur, estimer une route. L’autonomie d’action peut être limitée par des enveloppes : contourner dans un corridor, réduire la puissance, entrer en mode sûr. Les décisions irréversibles ou consommant des réserves stratégiques peuvent rester humaines.

Cette approche par niveaux d’autorité évite deux caricatures : le robot passif attendant la Terre et l’intelligence artificielle souveraine gérant seule une colonie. Une architecture crédible attribue à chaque fonction un domaine de décision, des limites, une capacité d’explication et un mécanisme de reprise humaine. La latence impose l’autonomie ; elle n’abolit pas la responsabilité.

AutoNGC : de l’autonomie de navigation à l’autonomie d’exécution

NASA présente désormais autoNGC comme une suite logicielle destinée à fournir navigation embarquée, planification autonome de manœuvres, décision exécutive et fonctions de contrôle lorsque la dépendance au sol devient trop lente ou impossible. Le point important n’est pas de rendre un véhicule « intelligent » au sens vague. Il s’agit de déplacer certaines boucles de décision au plus près de la physique.

Un véhicule qui détecte une dérive de trajectoire peut calculer une correction, vérifier qu’elle respecte les contraintes, planifier l’allumage et l’exécuter sans attendre plusieurs échanges radio. Mais cette capacité exige une hiérarchie d’autorité : quelles manœuvres sont autorisées automatiquement ? Quels seuils déclenchent un arrêt ? Quand faut-il demander l’accord humain ? Une autonomie sûre est une autonomie dont les frontières sont explicitement dessinées.

Le logiciel doit savoir distinguer “possible”, “permis” et “souhaitable”

Une trajectoire peut être physiquement possible mais interdite parce qu’elle traverse une zone de sécurité. Une manœuvre peut être autorisée mais inutile. Un algorithme peut optimiser le carburant tout en augmentant un risque opérationnel. L’autonomie doit donc manipuler plusieurs couches de contraintes : physique, mission, sûreté, règles de trafic et intention humaine.

Cette séparation devient encore plus importante dans une ville. Un rover de secours peut avoir le droit d’entrer dans une zone normalement interdite ; un véhicule de livraison non. Une situation d’urgence peut lever certaines contraintes et en renforcer d’autres. L’autorité doit donc être codée de manière auditable, pas cachée dans une fonction d’optimisation opaque.

AutoNGC : l’autonomie embarquée sort du vocabulaire de science-fiction

Un système GNC classique sépare conceptuellement trois fonctions. La navigation estime l’état : position, vitesse, attitude et incertitudes. Le guidage décide où aller : trajectoire, cible, contraintes. Le contrôle transforme cette décision en commandes vers moteurs, roues, freins ou autres actionneurs. Sur Mars, les délais de communication imposent d’ajouter une quatrième idée : l’autonomie exécutive, c’est-à-dire la capacité à choisir et replanifier sans attendre la Terre.

NASA présente en 2026 autoNGC comme une approche combinant navigation autonome, planification de manœuvres, prise de décision exécutive et contrôle. L’intérêt n’est pas de supprimer l’humain, mais de déplacer la frontière temporelle. Un véhicule peut gérer une correction urgente, vérifier ses contraintes et proposer un nouveau plan avant qu’un opérateur terrestre n’ait le temps de répondre.

L’autonomie n’autorise pas tout. Une architecture sérieuse définit des enveloppes. Le logiciel peut modifier une trajectoire dans une zone permise, mais ne pas consommer une réserve stratégique sans autorisation ; il peut arrêter une pompe sur surpression, mais ne pas condamner un habitat habité ; il peut contourner un obstacle, mais pas entrer dans une zone de protection planétaire. Les règles de sûreté deviennent donc des contraintes formelles du guidage.

Cette séparation est essentielle pour une cité. À mesure que les véhicules et robots se multiplient, personne ne peut téléopérer chaque décision. Le défi n’est plus d’automatiser une machine ; il est de prouver qu’une population de machines autonomes partage des règles compatibles avec la sécurité collective.

Estimation d’état, covariance et confiance : savoir ce que le système ignore

Le mot 'position' donne une illusion de certitude. En réalité, un système possède une estimation et une incertitude. Le même principe vaut pour la vitesse, l’attitude, la charge d’une batterie ou la santé d’un capteur. Le GNC moderne conserve donc une représentation de la confiance accordée à ses données. La covariance permet notamment de suivre comment les erreurs évoluent et comment une nouvelle mesure réduit certaines composantes d’incertitude.

Cette information change le comportement. Si la position d’un rover est connue à un mètre, il peut suivre une route étroite ; si l’incertitude grandit à cinquante mètres, le même ordre devient dangereux. Un atterrisseur ne doit pas seulement estimer qu’il vise une zone sûre : il doit savoir si son erreur de navigation est compatible avec la taille de cette zone. Le contrôle de l’incertitude devient donc une contrainte opérationnelle.

Les pannes complexes commencent lorsque plusieurs capteurs se contredisent. Une IMU indique un mouvement, la caméra ne le confirme pas et une mesure radio arrive en retard. Le système doit diagnostiquer la source probable, isoler un capteur si nécessaire et élargir son incertitude. La bonne réaction n’est pas toujours de choisir une valeur : elle peut être de ralentir, d’entrer en mode sûr ou de demander une observation supplémentaire.

Cette philosophie doit être expliquée au grand public parce qu’elle éclaire un point central de l’autonomie : une machine fiable n’est pas celle qui prétend tout savoir. C’est celle qui sait quand son modèle du monde devient trop incertain pour continuer normalement.

FDIR, mode sûr et autorité locale : survivre à une erreur sans la transformer en catastrophe

FDIR signifie Fault Detection, Isolation and Recovery : détecter une anomalie, isoler sa cause ou son domaine, puis récupérer une fonction acceptable. Dans un véhicule martien, le FDIR surveille des capteurs, des calculateurs, des actionneurs et des alimentations. Dans une ville, la même philosophie s’étend à des réseaux complets : énergie, pompes, rovers et centres de données.

Le mode sûr n’est pas nécessairement l’arrêt. Un rover loin de la base peut avoir besoin de conserver chauffage et communications. Un drone peut devoir atterrir. Une centrale peut réduire sa puissance plutôt que s’éteindre. La définition du refuge dépend du contexte, de l’énergie disponible et du temps avant assistance. Le GNC doit donc être conçu avec les autres systèmes, pas comme un logiciel indépendant.

La validation devient difficile parce que les pannes possibles sont combinatoires. Il faut tester capteur bloqué, bruit, latence, perte d’une horloge, désaccord cartographique, actionneur faible, liaison coupée et erreurs logicielles. Les simulations hardware-in-the-loop et les campagnes analogues sont indispensables, mais elles ne démontrent jamais toutes les situations. D’où l’importance d’enveloppes conservatrices et de procédures de reprise simples.

Sur Mars, une commande terrestre peut arriver après que le véhicule s’est déjà mis en sécurité. Le système doit alors déterminer si l’ordre est encore valide. Cette capacité à refuser une instruction devenue obsolète est l’un des marqueurs les plus intéressants de l’autonomie interplanétaire : l’autorité n’est pas seulement une question de hiérarchie, elle est aussi une question de temps.