BIBLE MARS — DOSSIER DE RÉFÉRENCE

Architecture système d’un vaisseau interplanétaire vers Mars : concevoir une machine qui doit survivre des mois

Mission, bus, charge utile, budgets, modes, interfaces, redondance, maintenance et validation : comprendre le vaisseau comme un système de systèmes plutôt que comme une fusée entourée de quelques boîtiers.

Architecture modulaire d’un vaisseau interplanétaire habité avec propulsion, modules pressurisés, énergie et interfaces d’amarrage. — Visualisation conceptuelle d’une architecture interplanétaire modulaire. La crédibilité d’un vaisseau Terre–Mars dépend moins d’une silhouette unique que de l’intégration des fonctions : propulsion, énergie, thermique, habitat, avionique, stockage, redondances et interfaces de maintenance.

FAIT ÉTABLIINGÉNIERIE ACTIVECHOIX PROSPECTIF

Pourquoi ce dossier est indispensable

Architecture du vaisseau : mission, interfaces et marges

1. Pourquoi l’architecture système mérite un chapitre entier

Un véhicule Terre-Mars n’est pas un seul objet technique. C’est une fédération de fonctions qui doivent rester compatibles pendant le lancement, la croisière interplanétaire, les corrections de trajectoire, les communications, les anomalies et l’arrivée. Structure, énergie, thermique, informatique, navigation, propulsion, communications et charge utile échangent en permanence masse, puissance, chaleur, données, efforts et contraintes d’exploitation. Une décision locale peut donc déplacer un problème ailleurs. Ajouter une antenne plus puissante améliore peut-être le débit, mais augmente consommation, masse, dissipation thermique et exigences de pointage. La discipline système consiste à voir ces effets avant qu’ils n’apparaissent en intégration.

2. Partir de la mission, jamais du catalogue. Une architecture sérieuse commence par les objectifs, la durée, les environnements, les performances, le niveau d’autonomie et les conséquences d’une panne. On transforme ces besoins en exigences vérifiables. Ce n’est qu’ensuite que l’on distribue les fonctions entre équipements. Cette séquence évite un travers fréquent : choisir d’abord une technologie séduisante puis inventer une justification. Pour une mission habitée, les exigences de survie, d’abandon, de maintenance et de retour influencent l’architecture dès l’origine. Pour un cargo, on peut accepter d’autres compromis. Deux véhicules allant tous deux vers Mars peuvent donc avoir des architectures radicalement différentes sans que l’un soit « faux ».

3. Architecture fonctionnelle et architecture physique. L’architecture fonctionnelle répond à la question : que doit savoir faire le système ? Produire de l’énergie, la distribuer, maintenir des températures, connaître sa position et son attitude, exécuter des commandes, propulser, communiquer, stocker des données, protéger la charge ou l’équipage. L’architecture physique répond ensuite : quels composants réalisent ces fonctions, où sont-ils placés et par quelles interfaces sont-ils reliés ? Garder ces deux niveaux séparés permet d’envisager plusieurs solutions matérielles pour une même fonction et de vérifier qu’aucune fonction vitale n’a été oubliée.

4. Les budgets sont la comptabilité physique du vaisseau. Masse, puissance, énergie, volume, surface de radiateur, débit de données, ergols et capacité de calcul sont limités. On construit donc des budgets, par sous-système et par mode. Une somme de masses est simple ; un bilan de puissance l’est moins, car tous les consommateurs ne fonctionnent pas simultanément. Les budgets doivent aussi intégrer des marges définies. Une marge n’est pas une décoration : elle représente une réserve face à la croissance du design et aux incertitudes. Plus le projet avance, plus la provenance de chaque kilogramme et de chaque watt doit être traçable.

5. Les modes de fonctionnement révèlent les vrais cas dimensionnants. Un vaisseau ne possède pas une consommation ou une température unique. Il existe des modes : lancement, croisière, recharge, communication, manœuvre, sommeil, maintenance, urgence, mode sûr. Chaque mode active une combinaison différente de fonctions. Une manœuvre peut produire un pic électrique et thermique ; une longue phase de sommeil peut être limitée par le froid ; un mode sûr doit préserver attitude, énergie et communication minimale. Les matrices modes-fonctions permettent de vérifier que le système complet reste cohérent et que les transitions ne créent pas un instant dangereux.

6. Interfaces : là où les systèmes se rencontrent et où les pannes naissent. Les interfaces transportent énergie, données, chaleur, efforts, fluides et responsabilités. Beaucoup de problèmes d’intégration viennent non d’un équipement défectueux, mais de deux équipements conformes à des hypothèses différentes : tension, format de message, tolérance mécanique, référence temporelle, convention de signe, séquence d’allumage. Un document de contrôle d’interface formalise ces frontières. Il doit évoluer avec la conception et être relié à des essais. Une interface non testée en configuration représentative reste une hypothèse.

7. Redondance, indépendance et défaillances de cause commune. Doubler un équipement n’est pas automatiquement doubler la sûreté. Deux voies partageant la même alimentation, le même logiciel, le même capteur de référence ou la même zone thermique peuvent disparaître ensemble. L’analyse cherche donc les causes communes et les points de panne unique. Parfois on sépare physiquement les voies ; parfois on diversifie les technologies ; parfois on crée un mode de secours volontairement plus simple. Pour Mars, la question supplémentaire est la réparabilité : une panne peut-elle être isolée, contournée ou réparée avec les moyens embarqués ?

8. La maintenance devient une exigence d’architecture. Sur une mission de longue durée, l’accès aux équipements, la standardisation des connecteurs, les pièces de rechange, les outils, la documentation et la capacité de diagnostic doivent être conçus, pas ajoutés après coup. Une unité inaccessible derrière plusieurs équipements peut transformer une petite panne en perte de fonction durable. La maintenance influence donc disposition, panneaux d’accès, modularité, réserves de câbles, moyens de levage et logiciel de diagnostic. Dans une future économie martienne, l’architecture du vaisseau et celle des ateliers de maintenance devront être pensées ensemble.

9. Vérifier, valider, puis savoir ce qui reste inconnu. La vérification démontre que les exigences sont respectées ; la validation démontre que le système répond au besoin réel. Analyse, inspection, essais, démonstrations, simulations et essais hardware-in-the-loop se complètent. Aucun essai terrestre ne reproduit exactement plusieurs mois de transit interplanétaire, de rayonnement et d’opérations. Une architecture mature distingue donc ce qui est mesuré, ce qui est corrélé par modèle et ce qui reste extrapolé. Cette honnêteté sur les limites est une condition de confiance, pas un aveu de faiblesse.

10. Une architecture martienne doit pouvoir évoluer. Le premier vaisseau ne sera pas le dernier. Si chaque génération change entièrement les tensions, connecteurs, protocoles, interfaces mécaniques et procédures, la colonie accumule des incompatibilités. Des standards stables permettent au contraire de remplacer un calculateur, ajouter un module, réutiliser une alimentation ou connecter une nouvelle charge utile. La standardisation ne doit pas bloquer l’innovation ; elle doit stabiliser les frontières les plus coûteuses à changer. C’est ainsi qu’une architecture de mission peut devenir progressivement une architecture de flotte puis une infrastructure industrielle.

11. Le centre de masse et l’architecture évoluent pendant la mission. Consommer des ergols, déplacer une cargaison, vider un réservoir d’eau ou changer la configuration d’un module déplace le centre de masse et peut modifier les inerties du véhicule. Ces variations influencent propulsion, GNC, structure et parfois thermique. Une architecture n’est donc pas une photographie figée du jour du lancement : elle doit décrire plusieurs configurations de masse et vérifier que les actionneurs, marges de pointage et charges restent compatibles dans chacune d’elles.

12. Human-rated : la présence humaine change la définition du risque. Un équipage ajoute support-vie, volumes habitables, protections, interfaces humaines, procédures, consommables et capacité d’intervention. Il ajoute surtout une exigence de maîtrise des dangers qui n’est pas équivalente à celle d’un cargo. Certains défauts tolérables sur une sonde deviennent inacceptables lorsqu’ils menacent une atmosphère pressurisée ou une capacité de retour. Les architectures habitées recherchent donc des barrières, des moyens de détection et des possibilités de récupération adaptées à la gravité des conséquences.

13. Configuration et vérité technique. Une mission longue ne peut pas dépendre de plans qui ne correspondent plus au véhicule réel. Chaque modification de câble, logiciel, vanne, capteur ou fixation doit être tracée. Les équipes doivent savoir quelle version est installée, quels essais l’ont qualifiée et quelles pièces sont compatibles. Sur Mars, cette gestion de configuration deviendra également indispensable aux ateliers : fabriquer la bonne pièce dans la mauvaise version peut être aussi dangereux que ne pas avoir de pièce du tout.

14. Architecture et facteurs humains. Dans un vaisseau habité, les choix d’architecture doivent tenir compte des erreurs humaines possibles : commandes confuses, accès difficile, alarmes trop nombreuses, procédures ambiguës ou maintenance impossible avec les gants et outils disponibles. L’interface homme-machine est donc une interface système. Une bonne architecture aide l’équipage à comprendre l’état du véhicule, à prioriser les alarmes et à exécuter une récupération sans créer une deuxième panne.

15. De la mission unique à la flotte martienne. Lorsque plusieurs cargos, habitats et véhicules utilisent les mêmes standards, une pièce de rechange, un outil logiciel ou une procédure peut servir à plusieurs systèmes. Cette mutualisation réduit le stock et simplifie la formation. À l’inverse, une flotte composée de véhicules incompatibles crée une dette logistique. L’architecture de long terme doit donc distinguer ce qui peut évoluer librement de ce qui gagne à devenir un standard de civilisation : tension, connecteurs, formats, interfaces mécaniques, diagnostics et règles de sécurité.

Interfaces critiques et conséquences système souvent oubliées

Anatomie d’un vaisseau spatial : bus, charge utile et sous-systèmes

Du besoin de mission à l’architecture

Un vaisseau ne se dessine pas en commençant par choisir une batterie, un ordinateur ou un moteur. On commence par une mission : masse à transporter, destination, durée, précision de navigation, communications, environnement, autonomie, sécurité et éventuellement présence humaine. Ces besoins sont transformés en exigences mesurables. L’architecture fonctionnelle décrit ensuite ce que le véhicule doit savoir faire : produire et distribuer de l’énergie, maintenir ses températures, se connaître lui-même, communiquer, orienter sa poussée, protéger ses occupants ou sa charge utile. L’architecture physique vient seulement après : elle attribue ces fonctions à des équipements réels. Cette distinction évite le piège consistant à faire rentrer la mission dans une collection de matériels déjà choisis.

Bus, charge utile et modules : des frontières qui restent artificielles

Le mot bus est pratique mais il ne signifie pas qu’il existe un bloc unique portant une étiquette « bus ». Il regroupe les fonctions communes qui rendent la mission possible. La charge utile est ce qui accomplit directement l’objectif principal : instrument scientifique, cargaison, habitat, démonstrateur, etc. Dans un véhicule Terre-Mars, la frontière devient parfois floue : un système de support-vie est-il du bus ou une partie de la mission humaine ? Une antenne sert-elle au véhicule ou à l’expérience ? L’important n’est pas le classement administratif, mais la clarté des interfaces, responsabilités, budgets et modes. Une mauvaise frontière peut masquer une dépendance critique.

Les budgets sont des contrats entre sous-systèmes

Masse, puissance, énergie, volume, dissipation thermique, débit de données, ergols et temps de calcul sont des ressources partagées. Un budget n’est donc pas un tableau décoratif ajouté à la fin du projet : il sert à empêcher chaque équipe d’optimiser localement au détriment du véhicule complet. Si un instrument gagne 20 kilogrammes, la structure, la propulsion et parfois le lanceur en subissent les conséquences. Si une radio émet plus fort, elle réclame davantage de puissance et produit davantage de chaleur. Les marges doivent être explicitement définies : marge de croissance, réserve de programme, capacité de pointe ou marge de conception ne veulent pas forcément dire la même chose.

Modes de fonctionnement : un vaisseau n’a pas une seule consommation

Les besoins changent selon les modes : lancement, croisière, communication à haut débit, manœuvre, recharge, observation, sommeil équipage, urgence ou mode sûr. Additionner tous les équipements comme s’ils fonctionnaient ensemble peut surdimensionner le système ; calculer seulement une moyenne peut au contraire cacher un pic impossible à fournir. Une matrice modes-fonctions indique ce qui doit être allumé, ce qui peut être coupé, quelles redondances restent disponibles et quelles transitions sont autorisées. Dans un trajet Terre-Mars, la capacité à survivre longtemps dans un mode dégradé peut compter davantage qu’une performance maximale de quelques minutes.

La redondance n’est utile que si elle est réellement indépendante

Deux ordinateurs identiques alimentés par le même convertisseur ne constituent pas une protection contre la perte de ce convertisseur. Deux logiciels copiés bit pour bit peuvent partager le même défaut de conception. Deux capteurs installés au même endroit peuvent subir la même surchauffe ou le même choc. On distingue donc les pannes individuelles des défaillances de cause commune. Une architecture robuste cherche à éviter qu’un seul événement puisse supprimer toutes les voies nécessaires à une fonction vitale. Cela conduit parfois à séparer les alimentations, les chemins de données, les capteurs, les emplacements physiques ou même les technologies utilisées.

Penser à la maintenance avant le départ

Pour une mission proche de la Terre, une panne peut parfois être contournée par une intervention rapide au sol ou par un remplacement lors d’une prochaine rotation. Sur Mars, cette logique change radicalement. Il faut prévoir diagnostic, accès physique, pièces de rechange, outils, connecteurs, procédures, compatibilité logicielle et capacité à isoler un équipement en panne. Une architecture très compacte peut gagner de la masse mais rendre une réparation impossible. Une architecture modulaire peut coûter quelques kilogrammes supplémentaires mais simplifier la maintenance. La « meilleure » solution dépend donc de la durée, de l’équipage, du niveau d’autonomie et de la conséquence d’une panne.

La preuve compte autant que le dessin

Une architecture n’est pas crédible parce qu’un diagramme est élégant. Chaque exigence importante doit avoir une méthode de vérification : analyse, inspection, démonstration, essai ou combinaison de ces approches. Les interfaces doivent être testées dans des configurations représentatives ; les modes dégradés doivent être exercés ; les marges doivent être recalculées après chaque changement. La validation pose une question différente : même si le système est conforme à ses exigences, répond-il réellement au besoin de mission ? C’est la différence entre construire correctement le mauvais véhicule et construire le véhicule réellement utile.

Intégration : interfaces, budgets, vérification et validation

Intégrer, c’est gérer les frontières

Deux équipements peuvent fonctionner parfaitement séparément et échouer lorsqu’ils sont connectés. L’intégration vérifie interfaces mécaniques, électriques, thermiques, logicielles, radiofréquences, fluides et opérationnelles. Chaque interface possède des paramètres : connecteur, tension, protocole, dimensions, tolérances, conductance thermique, chronologie ou responsabilités. Un Interface Control Document - ICD - formalise ces échanges. Sa valeur vient du fait qu’il est maintenu à jour, pas de son existence initiale.

Les budgets évoluent jusqu’au dernier moment

La masse augmente souvent au fil des détails ; les puissances de pointe apparaissent ; les débits de données grossissent ; les températures calculées changent. Un système d’ingénierie suit donc budgets et marges dans le temps. Une marge consommée tôt n’est pas la même chose qu’une marge restante juste avant le lancement. Des règles de gestion précisent quand une modification exige approbation et quels sous-systèmes doivent réévaluer leurs analyses.

Vérification et validation ne sont pas synonymes

La vérification demande : « avons-nous construit le système conformément aux exigences ? ». La validation demande : « ces exigences et ce système répondent-ils réellement au besoin ? ». Un équipement peut passer toutes ses spécifications et rester inutilisable dans la vraie mission si l’exigence initiale était mal formulée. Les deux boucles sont donc nécessaires. Une vérification peut être faite par analyse, test, inspection ou démonstration ; la validation utilise souvent des scénarios représentatifs de mission.

Test as you fly, fly as you test

Le principe signifie qu’on cherche à rendre les essais aussi représentatifs que raisonnablement possible de la configuration et des séquences de vol, puis à éviter en vol des modes jamais testés. Il ne peut jamais être appliqué littéralement à 100 % : on ne reproduit pas tout un voyage vers Mars au sol. On combine donc essais d’environnement, simulations, bancs matériels, modèles et répétitions opérationnelles. L’important est de connaître ce qui a été réellement couvert et ce qui reste extrapolé.

Compatibilité électromagnétique : l’ennemi invisible

Un équipement peut émettre du bruit qui perturbe un autre via câbles ou rayonnement. Convertisseurs de puissance, moteurs, radios et horloges numériques peuvent créer des interférences. À l’inverse, un capteur ou une ligne de données peut être trop sensible. Les essais EMC/EMI vérifient émissions et susceptibilité. Le routage des câbles, blindages, masses et filtres font partie de l’intégration, et des problèmes peuvent n’apparaître qu’en configuration complète.

Gestion des anomalies : ne pas refermer trop vite

Une anomalie constatée en essai doit être enregistrée, reproduite si possible, analysée et clôturée avec une justification. Remplacer une pièce sans comprendre pourquoi elle a cassé risque de masquer la cause. Une non-conformité peut être réparée, acceptée sous justification, ou conduire à une modification. La traçabilité est essentielle pour qu’un problème apparemment local soit recherché sur d’autres exemplaires ou interfaces similaires.

L’intégration martienne devient aussi logistique

Concevoir un vaisseau complet : modes, compromis, marges et décisions système

Concevoir le vaisseau complet signifie arbitrer

Aucun sous-système ne peut être maximisé indépendamment. Plus de blindage augmente la masse ; plus de puissance peut augmenter radiateurs et batteries ; plus de redondance augmente masse, coût et logiciel ; davantage de performances propulsion peut imposer stockage ou thermique plus complexes. L’ingénierie système compare donc des architectures, pas seulement des composants. Un compromis n’est pas forcément une concession médiocre : c’est le choix explicite de la meilleure combinaison au regard des objectifs et contraintes de mission.

Les exigences doivent former une hiérarchie traçable

Une exigence de haut niveau - par exemple assurer un retour sûr de l’équipage - se décompose en fonctions et exigences de sous-systèmes. Chaque exigence fille doit être reliée à sa raison d’être. Sinon, le projet accumule des spécifications orphelines. La traçabilité permet aussi de mesurer l’impact d’un changement : si la durée de mission augmente, quelles exigences thermiques, énergétiques, de stockage, de maintenance et de support-vie doivent être révisées ?

Maturité technologique et risque de développement

Une technologie très performante sur le papier peut être immature : fabrication difficile, faible historique d’essais, fournisseurs rares ou comportement incertain dans l’environnement réel. Choisir cette technologie transfère une partie du risque de la phase opérationnelle vers la phase de développement. Les démonstrateurs, prototypes et essais servent à faire monter la maturité avant de la rendre critique pour une mission. L’innovation utile est celle dont le chemin de qualification est compris.

Les marges sont une ressource qui se consomme

Au début, l’incertitude sur la masse ou la puissance est grande ; les projets conservent donc des réserves. À mesure que la conception se précise, certaines incertitudes diminuent, mais de nouveaux détails ajoutent souvent des besoins. Suivre seulement la valeur finale masque cette dynamique. Les équipes regardent la croissance, la marge restante et la tendance. Une marge n’autorise pas automatiquement à ajouter une fonction : elle protège d’abord contre ce qui n’est pas encore connu.

Maintenabilité, autonomie et durée

Une mission de quelques jours peut accepter un équipement non réparable si sa fiabilité et sa redondance suffisent. Une infrastructure martienne de plusieurs années ne peut pas appliquer la même philosophie partout. Diagnostic, accès, modularité, pièces de rechange, documentation, formation et capacité locale de fabrication prennent de la valeur. Cela peut justifier plus de masse initiale. Le compromis système doit donc intégrer la durée de vie du service, pas seulement le lancement initial.

Identifier les décisions irréversibles

Certaines décisions peuvent être modifiées tardivement ; d’autres ferment des options. Le diamètre d’un habitat, une tension de distribution, un standard de données ou une architecture de réservoir peut conditionner des dizaines d’interfaces futures. Les choix irréversibles doivent être reconnus tôt et entourés de davantage d’analyse. À l’inverse, les éléments faciles à remplacer peuvent rester ouverts plus longtemps. Cette gestion de l’irréversibilité évite de figer trop tôt ce qui n’est pas mûr.

La mission réelle est un ensemble de scénarios

Le vaisseau complet n’est pas dimensionné uniquement pour une journée nominale. Il doit traverser lancement, croisière, corrections, communications, incidents, approche, mise en sécurité et éventuellement retour. Chaque scénario active des fonctions et des risques différents. Les analyses de mission, matrices de modes, arbres de défaillance, FMEA/FMECA et essais d’opérations construisent une vision cohérente. La qualité d’une architecture se juge notamment à sa capacité à rester compréhensible lorsque plusieurs choses se passent mal en même temps.

Le vaisseau est un système de systèmes

Un vaisseau martien habité n’est pas seulement un réservoir avec des moteurs et une cabine. Pendant plusieurs mois, il doit simultanément tenir sa trajectoire, produire et distribuer de l’électricité, évacuer la chaleur, maintenir une atmosphère respirable, recycler l’eau, stocker la nourriture, protéger l’équipage, détecter les incendies et les fuites, communiquer, naviguer, résister aux micrométéoroïdes, gérer les déchets et permettre la maintenance. Cette simultanéité est la difficulté. Un excellent sous-système peut devenir dangereux s’il rejette de la chaleur, consomme une puissance de pointe ou exige une opération de maintenance incompatible avec les autres. L’architecture commence donc par les interfaces : qui fournit quoi, dans quelles limites, et que se passe-t-il lorsqu’une fonction disparaît ?

La méthode d’ingénierie système consiste à partir des exigences de mission : durée maximale, nombre de personnes, probabilité de retour, dose radiative acceptable, volume habitable, capacité de réparation, quantité de fret, niveau d’autonomie. Ces exigences se transforment en budgets : kilogrammes, watts, kilowattheures, mètres cubes, débit de données, litres d’eau, capacité de refroidissement et temps d’équipage. Chaque budget reçoit une marge parce qu’une mission de plusieurs centaines de jours ne peut être conçue au chiffre exact. La marge n’est pas du gaspillage ; c’est la reconnaissance quantifiée de l’incertitude.

La NASA décrit aujourd’hui douze sous-architectures Moon to Mars. Pour le vaisseau, plusieurs se superposent directement : habitation, systèmes humains, communications et positionnement, données, autonomie robotique, logistique, puissance et transport. Cette classification est utile car elle empêche de considérer l’habitat de transit comme une simple pièce de mobilier installée dans un étage propulsif. L’habitat est une infrastructure vitale dont la perte peut rendre le véhicule propulsivement sain mais humainement inutilisable.

Architecture intégrée ou modules séparés

Une architecture intégrée conserve le même volume habité, la même propulsion principale et une grande partie des systèmes du départ à l’arrivée. Elle réduit le nombre de rendez-vous et d’interfaces, mais oblige souvent à transporter pendant tout le voyage des structures qui ne servent qu’à une phase. À l’inverse, une architecture modulaire peut séparer étage de départ, habitat de transit, véhicule d’arrivée, atterrisseur et véhicule de remontée. La masse morte diminue parfois, mais les rendez-vous, amarrages, transferts de puissance, contrôles d’étanchéité et séparations deviennent des événements critiques supplémentaires. Le choix n’est donc pas « simple contre compliqué » : il déplace la complexité de la structure vers les opérations.

Pour une colonie, la réutilisation favorise certains modules durables : un habitat de transit très coûteux pourrait effectuer plusieurs rotations si sa structure, ses systèmes-vie et sa protection sont réellement inspectables et remplaçables. Mais la réutilisation interplanétaire est plus exigeante que la réutilisation d’un premier étage. Les composants accumulent des cycles thermiques, des heures de fonctionnement, des doses radiatives et des impacts pendant des années. La question clé n’est pas seulement la durée de vie nominale mais la capacité à diagnostiquer l’état réel d’un composant loin d’un atelier terrestre.

Une architecture crédible dessine donc les chemins de panne. Si un circuit de refroidissement fuit, existe-t-il une boucle indépendante ? Si une pompe CO₂ tombe en panne, peut-on la remplacer sans dépressuriser la cabine ? Si une antenne grand gain ne se déploie pas, quelle liaison de secours reste disponible ? Si un ordinateur de bord redémarre, les vannes critiques reviennent-elles dans un état sûr ? La redondance n’est pas identique partout : deux composants identiques peuvent partager le même défaut de conception. La diversité, la séparation physique et des modes manuels ou dégradés peuvent être plus efficaces qu’un simple doublement.

Énergie, chaleur et atmosphère : les trois réseaux invisibles

L’électricité est le système circulatoire du vaisseau. Même un véhicule dont la propulsion principale est chimique dépend d’une production électrique continue pour l’avionique, les pompes, le support-vie, les communications, l’éclairage, les expériences et souvent le contrôle thermique. Le dimensionnement doit regarder la puissance moyenne mais aussi les pointes : une antenne, un compresseur ou un équipement médical peuvent demander des kilowatts au mauvais moment. Les batteries ne remplacent pas la source primaire ; elles absorbent les transitoires et fournissent une autonomie lors de configurations particulières. Une panne de distribution peut donc être plus dangereuse qu’une baisse de performance d’un panneau solaire.

Toute puissance consommée finit presque entièrement en chaleur dans l’habitat. Or, dans le vide, cette chaleur ne peut pas être évacuée par convection extérieure : il faut la transporter par fluides vers des radiateurs et la rayonner. Plus la distance au Soleil augmente, plus le chauffage externe change ; plus certains systèmes fonctionnent, plus le besoin de rejet augmente. Les radiateurs sont des surfaces vulnérables et leur orientation peut interagir avec la propulsion et les manœuvres. Concevoir la puissance sans le thermique est donc impossible.

Le troisième réseau est l’atmosphère. L’ECLSS doit maintenir pression totale, pression partielle d’oxygène, élimination du CO₂, humidité et contaminants. Une fuite change en même temps la masse de gaz, la pression et la disponibilité des réserves ; un incendie peut rendre une cabine chimiquement dangereuse même si sa structure reste intacte. Pour Mars, la durée interdit de penser le support-vie comme un consommable jetable. Les boucles de récupération d’eau, les cartouches, les filtres, les ventilateurs et les capteurs deviennent des équipements maintenus en opération, avec des pièces et des procédures de diagnostic.

Radiation, micrométéoroïdes et refuge

Une coque pressurisée protège contre le vide mais pas suffisamment contre tous les risques radiatifs. Le rayonnement cosmique galactique est difficile à arrêter complètement avec des masses raisonnables ; les événements de particules solaires peuvent en revanche justifier un refuge plus fortement protégé où l’équipage se regroupe pendant une alerte. La conception intelligente utilise des masses déjà nécessaires — eau, nourriture, déchets, consommables — autour de cette zone plutôt que d’ajouter partout une épaisseur uniforme. Cela ne supprime pas le risque : cela le redistribue en fonction de la physique et du temps d’exposition.

Les micrométéoroïdes sont un autre problème de faible probabilité mais forte conséquence. Une structure multicouche peut fragmenter et disperser un impact avant qu’il n’atteigne la coque pressurisée. La mission doit aussi pouvoir localiser une petite fuite, isoler une section et colmater. La vraie question d’architecture est le temps disponible : une fuite lente détectée par une baisse de pression n’a pas le même profil qu’une perforation rapide. Les capteurs, les compartiments et les kits de réparation doivent être pensés ensemble.

Le refuge sert enfin à plus qu’une tempête solaire. Une zone centrale peut être pensée comme volume de survie en cas de contamination partielle, de panne thermique ou de dépressurisation d’un autre compartiment. Mais plus on lui attribue de fonctions, plus il faut éviter le point de défaillance unique : un incendie dans le refuge ne doit pas rendre toute la mission inhabitable. La résilience vient de l’architecture spatiale autant que de la quantité d’équipements.

Concevoir pour réparer

Sur Terre, la fiabilité est souvent obtenue en remplaçant un appareil complet. Sur la route de Mars, la masse de pièces interdit d’emporter un exemplaire de chaque équipement. La maintenance doit donc être hiérarchisée : composants critiques redondants, pièces d’usure stockées, éléments communs standardisés, outillage partagé, électronique remplaçable au niveau du module, fabrication locale de pièces non critiques. La standardisation d’un ventilateur, d’un connecteur ou d’un type de pompe peut avoir plus de valeur qu’un gain de quelques pourcents de performance si elle réduit l’inventaire de rechange.

L’équipage devient une partie du système de maintenance. Chaque heure passée à réparer n’est pas disponible pour la science, l’exercice, le repos ou les opérations. Le temps humain doit donc apparaître dans les budgets au même titre que les watts. Une solution qui gagne cinq kilogrammes mais exige deux heures de maintenance par semaine pendant neuf mois peut être un mauvais échange. Les futurs véhicules devront enregistrer l’état de santé des équipements, aider au diagnostic et fournir des procédures utilisables hors connexion Terre.

Cette exigence rapproche le vaisseau martien d’un sous-marin ou d’une station polaire plus que d’un avion de ligne : l’équipage vit longtemps à l’intérieur du système qu’il doit lui-même entretenir. La différence est qu’aucun navire de secours ne peut arriver dans la journée. La maintenabilité n’est donc pas un chapitre ajouté après la conception ; elle doit modifier l’accessibilité des équipements, la disposition des conduites, le nombre de vannes d’isolement et même le choix des technologies.

L'architecture commence par des fonctions, des modes et des interfaces

Un vaisseau martien n'est pas une addition de sous-systèmes choisis séparément. La question d'architecture consiste à traduire une mission en fonctions : maintenir l'équipage en vie, fournir énergie et données, contrôler attitude et trajectoire, résister aux environnements, communiquer, détecter les pannes et permettre la maintenance. Ces fonctions sont ensuite réparties entre matériels, logiciels, procédures et équipage. La même fonction peut traverser plusieurs équipements ; inversement, un seul équipement peut satisfaire plusieurs fonctions. C'est la raison pour laquelle une architecture « par catalogue » échoue souvent : elle optimise chaque composant sans maîtriser les interactions.

Le Systems Engineering Handbook de la NASA insiste sur la continuité entre attentes des parties prenantes, exigences, conception logique et physique, vérification et validation. Pour une mission vers Mars, cette continuité doit aussi intégrer l'incertitude. Une valeur de masse n'est pas un fait éternel : elle possède une maturité et une marge. Un débit ECLSS, une puissance électrique ou une capacité de radiateur dépend d'un scénario. Les budgets ne sont pas seulement des tableaux ; ils sont les frontières communes entre équipes.

Les modes de fonctionnement révèlent ce que les moyennes cachent

Une architecture doit être jouée par modes : croisière nominale, sommeil équipage, maintenance, manœuvre, communication à haut débit, perte d'une chaîne de puissance, refuge, préparation d'arrivée. Pour chaque mode, on demande quels équipements sont actifs, quelles ressources ils consomment, quels capteurs les surveillent et quelles fonctions restent obligatoires. Un composant apparemment secondaire peut devenir dimensionnant dans un mode rare. Une pompe de secours n'est utile que si elle reçoit encore de l'électricité lorsque le défaut commun qui a arrêté la pompe principale a aussi affecté le bus.

Cette approche rend visibles les causes communes. Deux calculateurs identiques n'offrent pas une indépendance réelle s'ils partagent alimentation, logiciel, capteur ou refroidissement. Deux boucles d'eau qui passent par le même échangeur ne sont pas deux chaînes indépendantes. Le mot « redondance » doit donc être complété par une carte de dépendances. La question n'est pas seulement combien de chemins existent, mais quels événements peuvent les supprimer simultanément.

Les interfaces sont les endroits où une mission se gagne ou se perd

Une interface peut être mécanique, électrique, thermique, logicielle, humaine ou documentaire. Les valeurs critiques doivent être explicites : tension et courant admissibles, connecteur et brochage, conductance thermique, efforts mécaniques, protocole de données, précision temporelle, autorité de commande, procédure de maintenance. Quand une interface est ambiguë, chaque équipe peut produire un sous-système « correct » qui ne fonctionne pas une fois assemblé.

L'ingénierie numérique et le model-based systems engineering ne suppriment pas cette difficulté ; ils cherchent à la rendre traçable. Le NASA Systems Modeling Handbook 2025 formalise l'utilisation de SysML dans les processus d'ingénierie système. Pour une architecture martienne, l'intérêt n'est pas de dessiner des centaines de diagrammes, mais de conserver le lien entre exigence, fonction, élément physique, test et donnée de validation. Lorsqu'une exigence change — par exemple une mission plus longue ou un équipage plus nombreux — on doit savoir quels budgets et tests sont touchés.

Exemple : une augmentation de 20 % de puissance n'est jamais locale

Supposons qu'un nouvel équipement ajoute 2 kW à un bus qui transportait 10 kW. La croissance de puissance est 2 ÷ 10 = 20 %. Mais l'effet peut dépasser 20 % sur d'autres domaines : section des câbles, pertes I²R, chaleur à rejeter, taille de convertisseurs, énergie de batterie, contraintes de panneaux, besoins de refroidissement et masse. Si le nouvel équipement fonctionne seulement vingt minutes par jour, l'énergie quotidienne supplémentaire vaut 2 kW × 1/3 h ≈ 0,67 kWh ; le bus doit pourtant supporter la pointe de 2 kW. Cette distinction entre puissance et énergie illustre pourquoi les budgets sont couplés mais pas interchangeables.

Une architecture martienne doit être conçue pour changer sans perdre sa vérité technique

Les missions longues subissent des mises à jour logicielles, des réparations, des changements de configuration et des pièces remplacées. La « vérité technique » du véhicule doit rester connue : quel matériel est installé, quelle version logicielle le commande, quels tests ont été réalisés, quelles limitations sont ouvertes. Une réparation réussie mais mal documentée peut devenir le point de départ d'une panne future. Sur Mars, où l'aide terrestre arrive avec retard, la gestion de configuration devient une capacité opérationnelle.

Le vaisseau est donc autant une architecture de connaissances qu'une architecture de métal. Les modèles, procédures, schémas, historiques de panne et limites de qualification doivent voyager avec lui. La réussite d'une mission ne dépend pas uniquement d'un design initial brillant ; elle dépend de la capacité de l'équipage et des systèmes autonomes à comprendre ce qu'ils ont réellement entre les mains plusieurs mois après le départ.

Repères primaires

NASA Systems Engineering Handbook : processus de conception, intégration, vérification et gestion technique. NASA-HDBK-1009A, Systems Modeling Handbook, 2025 : intégration des modèles SysML aux processus NASA. Spacecraft Components : exemple concret des interfaces et sous-systèmes d'Orion.

Une architecture se juge à ce qu'elle rend possible quand le plan nominal disparaît

Le schéma fonctionnel d'un vaisseau est utile seulement s'il permet de répondre à des questions d'exploitation. Que reste-t-il après perte d'un bus ? Peut-on isoler une cabine ? Le véhicule peut-il naviguer si l'étoileur devient indisponible ? Combien de fonctions changent lorsqu'on ferme une boucle fluide ? Ces questions transforment l'architecture d'une liste de sous-systèmes en réseau de dépendances.

Les interfaces méritent un inventaire explicite. Une interface possède au moins une géométrie, une énergie, de la matière, des données et des responsabilités. Un connecteur mécanique peut aussi transporter mise à la masse et signaux ; une ligne fluide peut devenir un chemin de contamination ; un message logiciel peut déclencher un actionneur physique. Les accidents de système apparaissent souvent aux frontières que chaque équipe pensait appartenir à l'autre.

La marge doit être distinguée de la redondance. Vingt pour cent de puissance inutilisée ne remplace pas un convertisseur de secours ; deux ordinateurs identiques ne créent pas une vraie résilience s'ils partagent alimentation, horloge et logiciel fautif. L'architecture doit cartographier marge de capacité, voies alternatives et causes communes séparément.

Un exercice utile consiste à retirer successivement une fonction majeure. Sans communication Terre, le vaisseau doit continuer à naviguer et décider localement. Sans une cabine, l'équipage doit se regrouper ailleurs. Sans refroidissement principal, les charges doivent descendre vers un niveau compatible avec la boucle restante. Chaque scénario révèle quelles interfaces sont réellement critiques et quelles fonctions de repli doivent exister avant le vol.

La modularité n'est pas synonyme de multiplication des boîtes. Un module remplaçable doit avoir interfaces stables, accès physique, moyens de test et stock ou capacité de substitution. Sinon, le mot « modulaire » décrit seulement une architecture de dessin. La standardisation des interfaces peut être plus précieuse que la standardisation des composants eux-mêmes parce qu'elle permet d'introduire des remplacements futurs.

Enfin, l'architecture humaine inclut l'équipage comme élément de contrôle. Certaines pannes peuvent être gérées par procédure, d'autres exigent automatisation immédiate. Confier trop d'actions au logiciel crée une dépendance opaque ; tout confier aux humains surcharge l'équipage au pire moment. L'objectif est une répartition explicite de l'autorité, avec information compréhensible, automatisme réversible lorsque possible et preuve de l'état réel du véhicule.

Étude de cas : isoler un compartiment transforme l'ensemble du véhicule. Une fuite lente apparaît dans un compartiment non essentiel. La fermeture d'une cloison paraît être une action locale, mais elle modifie volumes pressurisés, circulation d'air, routage des câbles accessibles, distribution d'énergie, chemin de l'équipage et parfois position de stockage. L'architecture système doit connaître ces effets avant l'urgence. Chaque état d'isolement devrait posséder une configuration documentée plutôt qu'une improvisation.

Si le compartiment représente 15 % du volume habitable, son isolement réduit la capacité disponible mais peut aussi diminuer la masse d'atmosphère à maintenir. Les autres compartiments reçoivent davantage de personnes et de chaleur. Les concentrations de CO₂ peuvent monter plus vite et le niveau sonore augmente. Une décision prise pour sauver la pression crée donc une nouvelle charge ECLSS et humaine.

Le réseau électrique peut traverser la zone isolée. Une cloison fermée mécaniquement n'isole pas automatiquement les chemins de puissance ou de données. L'architecture doit décider si des pénétrations restent actives, si elles peuvent être coupées et si un défaut incendie ou liquide peut se propager à travers elles. La segmentation physique et logique doit correspondre aux frontières de sécurité.

La maintenance future devient également différente. Un équipement situé dans le compartiment perdu peut être fonctionnel mais inaccessible. Les stocks critiques doivent donc être répartis ; les fonctions vitales ne doivent pas dépendre d'un seul espace. Cette notion de « redondance géographique » est parfois plus importante que posséder deux exemplaires côte à côte.

Le scénario se clôt par une décision : réparer sous pression partielle, maintenir la zone condamnée ou reconfigurer durablement le véhicule. Chacune modifie masse, centre de gravité, consommables et psychologie de l'équipage. Un bon modèle d'architecture permet de recalculer ces conséquences et de vérifier les nouvelles marges. Le système est réellement robuste lorsqu'il peut changer de forme sans perdre la cohérence de ses budgets.

Concevoir le vaisseau comme une architecture de services vitaux

Architecture de services vitaux : les interfaces relient plusieurs sous-systèmes.

Un service traverse plusieurs sous-systèmes à la fois

La manière la plus sûre de lire un vaisseau martien consiste à oublier quelques instants les noms des équipements et à suivre les services rendus. Respirer exige une atmosphère respirable, mais aussi de l’électricité pour les ventilateurs et les capteurs, une capacité thermique pour évacuer la chaleur, de l’eau pour certains procédés, des données pour connaître l’état des boucles et une autorité de commande capable de décider en cas d’écart. Communiquer avec la Terre exige une antenne, mais aussi un pointage, une horloge, une puissance électrique, une gestion de fichiers, un calendrier de visibilité et une stratégie lorsque la liaison est interrompue. Chaque service utile est donc une chaîne interdisciplinaire.

Cette lecture évite un piège fréquent : croire qu’une redondance locale produit automatiquement une redondance système. Deux pompes ne servent à rien si elles partagent un capteur unique qui les arrête à tort. Deux calculateurs ne garantissent rien si leur logiciel interprète de la même façon une donnée corrompue. Deux chaînes électriques restent vulnérables si elles traversent la même zone d’incendie. L’architecture doit identifier le service, ses dépendances minimales, les causes communes et le chemin de récupération. Le dessin des boîtes vient ensuite.

La documentation Moon to Mars publiée par la NASA distingue des sous-architectures comme transport, puissance, communications et navigation, habitation, autonomie, logistique et données. Cette organisation ne décrit pas à elle seule un véhicule habité précis ; elle rappelle cependant que les éléments réels appartiennent souvent à plusieurs fonctions. Pour Delta-Sierra, la conséquence est claire : une interface importante doit être décrite par ce qu’elle transporte, par sa qualité requise et par le comportement attendu lorsqu’elle se dégrade.

Écrire les modes avant d’écrire les automatismes

Un véhicule de longue durée doit savoir dans quel état il se trouve. Croisière nominale, correction de trajectoire, perte de communications, refuge radiologique, maintenance électrique, arrivée à Mars ou redémarrage après panne ne sont pas de simples étiquettes logicielles : chacun de ces modes change les priorités. Une pompe secondaire peut devenir critique pendant un transfert de fluide. Une antenne à fort débit peut être inutile pendant une urgence immédiate puis redevenir prioritaire dès que l’équipage doit transmettre un diagnostic. Une procédure d’architecture robuste commence donc par une table des modes, des transitions autorisées et des fonctions qui doivent rester disponibles.

Les transitions sont souvent plus dangereuses que les états stables. Au passage vers un mode refuge, plusieurs charges peuvent démarrer simultanément, des vannes changent de position, des logiciels changent d’autorité et l’équipage modifie son activité. Le risque est de provoquer une panne en cherchant à se protéger d’une autre. Il faut donc vérifier les appels de courant, les volumes de fluide déplacés, la chaleur produite, les temporisations et les conditions d’interverrouillage. Une transition doit être conçue comme une séquence vérifiable, pas comme un bouton abstrait intitulé « SAFE ».

La sortie du mode dégradé mérite la même rigueur. Le système ne doit pas supposer que la réparation ramène instantanément le véhicule à l’état nominal. Il faut confirmer les mesures, rétablir les protections, synchroniser les calculateurs, réintégrer les charges progressivement et vérifier que le défaut initial n’a pas laissé d’effet secondaire. Cette logique transforme la récupération en partie intégrante de l’architecture.

Faire vivre une marge jusqu’au niveau de la mission

Une marge n’a de sens que si l’on sait à quel niveau elle s’applique. Ajouter 20 % sur la puissance d’un équipement, puis 20 % sur un sous-système qui inclut déjà cette réserve, peut conduire à compter deux fois la même prudence. À l’inverse, une marge locale peut disparaître lorsqu’un convertisseur, un radiateur ou une batterie est dimensionné sans tenir compte de la réserve demandée en aval. Le budget doit donc identifier clairement la valeur de base, la marge, le rendement de conversion et la marge système éventuelle.

Prenons une chaîne simple : deux charges vitales de 3,0 kW chacune, une charge de diagnostic de 1,5 kW et 15 % de réserve opérationnelle. La puissance utile vaut 7,5 kW ; avec la réserve elle devient 8,625 kW. Si le chemin de conversion ne fournit que 91 % de rendement, la source doit fournir environ 8,625 ÷ 0,91 = 9,48 kW. Les quelque 0,86 kW perdus dans la conversion deviennent principalement de la chaleur. Ce petit calcul montre pourquoi puissance, thermique et marge ne doivent jamais être examinées séparément.

La masse suit une logique analogue. Un kilogramme ajouté à une protection peut en économiser d’autres dans une redondance ou une structure secondaire ; un kilogramme retiré d’un panneau d’accès peut coûter des dizaines d’heures de maintenance. L’architecture ne cherche donc pas le minimum de chaque budget mais un ensemble cohérent qui garde suffisamment de marge là où une réparation terrestre est impossible.

La vérification intégrée doit reproduire les mauvaises journées

Un essai nominal prouve rarement ce qui inquiète le plus. Le véhicule doit être confronté à des combinaisons réalistes : perte d’un capteur pendant une reconfiguration électrique, refroidissement réduit pendant une manœuvre, communication indisponible alors qu’une mise à jour logicielle doit être annulée, ou intervention de maintenance pendant laquelle une deuxième anomalie apparaît. Les essais intégrés doivent rechercher les dépendances inattendues et la capacité de l’équipage à comprendre la situation avec les informations réellement disponibles.

Le NASA Systems Engineering Handbook insiste sur le lien entre exigences, architecture, vérification et validation. Appliqué à Mars, ce lien signifie qu’une exigence comme « maintenir un environnement sûr après une panne simple » doit finir par produire une preuve concrète : analyse, simulation, essai, procédure et critère de réussite. Une phrase rassurante dans un document ne suffit pas. La preuve doit montrer quelles pannes ont été injectées, quelles hypothèses ont été retenues et quelles fonctions sont restées disponibles.

La validation pose une autre question : le système construit permet-il réellement à l’équipage d’accomplir la mission ? Une procédure parfaite sur papier peut échouer si l’accès matériel est impossible en combinaison, si le diagnostic exige un outil non disponible ou si les alarmes arrivent trop tard. Les essais humains, les maquettes et les campagnes de durée représentative deviennent alors des preuves d’architecture, pas des finitions ergonomiques.

Conserver une architecture compréhensible après plusieurs années de modifications

La durée transforme le vaisseau. Les batteries vieillissent, certains capteurs dérivent, des cartes sont remplacées, des logiciels sont corrigés et des procédures évoluent. La configuration réelle doit rester reliée aux schémas, aux modèles de performance et aux stocks de pièces. Une modification non enregistrée peut faire croire qu’un circuit possède encore une capacité ou une protection qu’il a perdue. La discipline de configuration est donc une condition de sûreté.

Une bonne architecture prépare aussi la modification. Les interfaces stables, les unités remplaçables, les points de mesure et les limites clairement documentées permettent de faire évoluer un élément sans invalider tout le véhicule. À l’opposé, un système dont les dépendances sont implicites devient de plus en plus fragile à chaque correction. Pour un trajet martien et, plus encore, pour des véhicules réutilisés, la capacité à changer sans perdre la preuve de sécurité devient une propriété de conception.

Le résultat recherché n’est pas un vaisseau figé ni une documentation gigantesque. C’est un système dont les fonctions, les modes, les interfaces et les preuves restent lisibles assez longtemps pour que l’équipage puisse encore répondre à la question essentielle : « si je change ceci aujourd’hui, quelles autres fonctions puis-je affecter demain ? »

Étude de cas intégrée : quarante-huit heures sans assistance terrestre

Un bon test d’architecture consiste à retirer volontairement le confort d’une équipe au sol disponible en permanence. Imaginons qu’une perturbation de communication empêche tout échange utile pendant quarante-huit heures, alors qu’une boucle thermique secondaire montre simultanément une dérive. Le véhicule reste pressurisé et le système principal fonctionne, mais l’équipage doit décider s’il continue les activités prévues, bascule certaines charges, prépare une réparation ou attend de meilleures mesures. La difficulté ne vient pas d’un composant spectaculaire : elle vient de l’interaction entre données incomplètes, énergie, thermique, calendrier et autorité humaine.

Le premier besoin est une image système lisible. Les opérateurs doivent connaître la puissance disponible, la capacité thermique résiduelle, l’évolution des températures, la réserve de batterie, l’état des pompes et les fonctions qui deviendraient critiques si la boucle se dégradait davantage. L’interface ne devrait pas seulement afficher cent mesures ; elle devrait montrer les dépendances. Si un calculateur scientifique peut être arrêté pour libérer 1,8 kW et réduire d’autant la chaleur interne, le bénéfice doit apparaître avec le coût opérationnel de cette décision.

Supposons que la boucle restante puisse rejeter 11 kW dans les conditions actuelles et que le véhicule dissipe 10,2 kW. La marge n’est que de 0,8 kW, soit environ 7,3 % de la capacité disponible. Couper une charge de 1,8 kW ramène la dissipation à 8,4 kW et porte la marge à 2,6 kW, environ 23,6 %. Le symbole « % » désigne un pourcentage. Le calcul ne prouve pas à lui seul que la configuration est sûre : il faut encore vérifier la localisation de la chaleur, la capacité des échangeurs et les transitoires. Mais il transforme une intuition en décision quantifiée.

La configuration choisie doit ensuite tenir quarante-huit heures sans épuiser d’autres réserves. L’équipage peut alterner certaines charges plutôt que les supprimer complètement, retarder une opération consommatrice, surveiller la dérive et préparer l’accès au module suspect. Chaque action doit être enregistrée afin que le modèle du véhicule corresponde à l’état réel. Lorsque la communication revient, le sol reçoit une chronologie structurée plutôt qu’un récit reconstruit de mémoire.

Le point le plus important survient si une deuxième anomalie apparaît. Si une batterie montre une température anormale, l’architecture doit permettre de réviser la stratégie sans perdre le refuge fonctionnel. Une conception robuste n’optimise donc pas la première panne jusqu’à la dernière marge disponible ; elle conserve une réserve de décision pour la panne suivante. Cette notion d’option résiduelle est une mesure particulièrement utile pour les systèmes habités éloignés de la Terre.

Cette étude de cas relie plusieurs chapitres sans les dupliquer : thermique, puissance, avionique, communications et opérations conservent leurs propres détails techniques ; l’architecture système montre comment leurs contraintes se rencontrent dans une décision unique. C’est précisément ce que doit fournir une monographie d’architecture : non pas répéter chaque discipline, mais rendre visibles les dépendances qui n’existent qu’entre elles.

Transformer l’architecture en contrat vérifiable entre fonctions, modes et interfaces

Un vaisseau interplanétaire ne devient pas sûr parce que chacun de ses sous-systèmes possède une bonne fiche technique. Il devient exploitable lorsque les fonctions qui traversent ces sous-systèmes sont décrites de manière cohérente et vérifiable. « Maintenir l’équipage en vie », par exemple, mobilise simultanément l’alimentation électrique, le contrôle thermique, l’atmosphère cabine, l’eau, l’avionique, les capteurs, les alarmes, les procédures et parfois la propulsion si une manœuvre doit être différée. L’architecture système sert précisément à rendre ces dépendances visibles avant qu’une panne ne les révèle au pire moment.

La méthode la plus robuste consiste à partir des états de mission plutôt que des équipements. Le même convertisseur électrique n’a pas la même importance pendant une phase de croisière stable, une correction de trajectoire, une occultation des communications, un refuge radiologique ou une préparation d’arrivée. L’architecture doit donc associer à chaque état une liste de fonctions indispensables, de fonctions délestables et de fonctions qui peuvent être temporairement arrêtées. Cette matrice de modes devient plus instructive qu’un schéma où toutes les boîtes semblent avoir la même importance.

Le principe est proche de l’approche de l’ingénierie système décrite par la NASA : partir des attentes, des fonctions et des exigences, puis relier conception, vérification et validation. La documentation Moon to Mars de 2026 renforce cette lecture en organisant l’architecture autour de sous-architectures — transport, puissance, communications et PNT, habitation, autonomie, logistique, données — qui se recoupent dans les éléments réels. Pour un véhicule martien, cela signifie qu’une interface n’est pas une ligne secondaire sur un dessin : elle représente un transfert de matière, d’énergie, d’information, d’autorité ou de responsabilité.

Une interface bien spécifiée répond à des questions très concrètes. Quelle tension et quelle qualité de puissance arrivent ? Quel débit maximal et quelle température de fluide sont garantis ? Qui fournit l’horodatage ? Quelle donnée est considérée comme autoritaire lorsque deux calculateurs ne sont pas d’accord ? Quel équipement décide de l’arrêt d’une pompe ? Quel état doit être conservé après un redémarrage ? Une architecture qui ne répond pas à ces questions peut sembler complète au niveau des composants tout en restant dangereusement ambiguë au niveau du véhicule.

Les budgets couplés : masse, puissance, chaleur, données et temps équipage

Le mot « budget » ne désigne pas seulement une marge financière ou un tableau de masse. Il s’agit d’une comptabilité physique. Une décision locale déplace presque toujours plusieurs budgets à la fois. Ajouter un ordinateur plus puissant augmente la masse de l’avionique, mais aussi sa consommation électrique, la chaleur à rejeter, parfois le débit de données, le besoin de blindage radiatif et le temps consacré à la validation logicielle. À l’inverse, un matériel plus lourd mais passif peut réduire les besoins de puissance et de maintenance. L’architecte doit donc comparer les conséquences croisées plutôt qu’optimiser chaque discipline séparément.

Un calcul simple permet de voir comment les marges peuvent se cumuler. Imaginons un équipement dont la puissance nominale vaut 4,0 kW. Si l’on applique une marge de conception de 20 %, le besoin réservé devient 4,8 kW. Si le convertisseur alimentant cette charge fonctionne à 92 % de rendement, la puissance appelée en amont vaut environ 4,8 / 0,92 = 5,22 kW. Les 0,42 kW de différence ne disparaissent pas : ils deviennent principalement de la chaleur à gérer. Une décision qui semblait être « ajouter 0,8 kW de marge » se traduit donc par plus d’un kilowatt supplémentaire à produire et à rejeter par rapport à la charge utile initiale.

Le symbole « / » signifie ici une division. Le rendement de 92 % est un exemple pédagogique, pas une valeur imposée à un futur véhicule. L’intérêt du calcul est architectural : la réserve doit traverser les chaînes de conversion. Une marge ajoutée au mauvais niveau peut être comptée deux fois ou, au contraire, oubliée à une interface. Le même raisonnement s’applique à l’eau, aux gaz, au stockage de données et à la bande passante.

Le temps équipage mérite d’être traité comme un budget de même dignité. Supposons que douze opérations de maintenance prévues demandent chacune 2 h par mois et que deux astronautes soient requis pour des raisons de sécurité. Le coût n’est pas 24 h mais 48 h-personnes par mois. Si l’on ajoute préparation, dépressurisation éventuelle, remise en configuration et documentation, le coût réel peut devenir nettement supérieur. Une architecture « légère » en masse qui multiplie les interventions peut donc être très lourde en travail humain.

Concevoir les dépendances pour qu’une panne reste locale

La redondance est souvent représentée par deux boîtes parallèles. Cette image est insuffisante. Deux équipements peuvent être matériellement distincts mais partager la même alimentation, le même logiciel, le même capteur de référence, le même refroidissement ou le même connecteur. Une défaillance commune peut alors neutraliser les deux voies. L’architecture doit identifier ces dépendances invisibles et décider lesquelles doivent être réellement indépendantes.

L’indépendance totale est rarement possible et serait souvent trop coûteuse. Il faut donc protéger en priorité les fonctions dont la perte crée une évolution rapide vers une situation irréversible. Un circuit de survie électrique peut, par exemple, conserver un ensemble minimal de charges : calculateur de commande, communications de détresse, circulation atmosphérique, capteurs essentiels, éclairage minimal et moyens de redémarrage. Le reste est délestable. Cette hiérarchie transforme une panne électrique générale en plusieurs états contrôlés plutôt qu’en un unique basculement « nominal / mort ».

La notion de « safe haven », ou refuge fonctionnel, élargit ce raisonnement. Le refuge n’est pas forcément une pièce unique. Il peut être une combinaison temporaire de volumes, d’alimentations, de réserves et de fonctions numériques permettant de préserver l’équipage pendant que le véhicule est réparé. L’architecture doit alors vérifier qu’une cause commune — incendie dans une baie, perte d’une boucle thermique, contamination d’un circuit — ne prive pas simultanément le refuge et le système principal du même service.

Un scénario utile consiste à perdre une des deux boucles de refroidissement alors que l’équipage prépare une correction de trajectoire. La première décision n’est pas nécessairement de réparer immédiatement. Il faut d’abord savoir si la boucle restante peut absorber la charge du calculateur de guidage, des actionneurs et de l’avionique pendant la manœuvre. Si la réponse est oui avec une marge faible, la mission peut maintenir la fenêtre de manœuvre puis réparer dans une configuration plus stable. Si la réponse est non, l’architecture doit offrir une autre option : réduire la charge, différer la manœuvre ou utiliser une chaîne de secours. Le scénario révèle donc une relation entre thermique, navigation, propulsion et calendrier orbital.

La configuration technique : savoir exactement quel vaisseau on possède aujourd’hui

Un véhicule de plusieurs années ne restera pas identique à son état de lancement. Des pièces seront remplacées, des cartes échangées, des versions logicielles mises à jour, des paramètres recalibrés, des réparations provisoires deviendront peut-être permanentes. La « configuration » est la mémoire organisée de ces changements. Sans elle, les procédures, les modèles de performance et les diagnostics finissent par décrire un vaisseau qui n’existe plus.

La gestion de configuration doit relier matériel, logiciel, câblage, consommables et documents. Lorsqu’un convertisseur est remplacé par une révision différente, il faut savoir si ses limites thermiques ont changé, si son firmware est compatible, si le stock de rechange reste interchangeable et si les modèles de consommation doivent être corrigés. Sur Terre, une organisation peut parfois compenser une documentation imparfaite en appelant le fabricant. À des dizaines de millions de kilomètres, cette dépendance devient beaucoup moins confortable et parfois trop lente pour la décision opérationnelle.

Le NASA Systems Modeling Handbook publié en 2025 formalise l’intérêt de relier attentes, exigences, mesures de performance, vérification et validation dans un modèle cohérent. Pour Mars, cette idée prend une dimension opérationnelle : le modèle du vaisseau doit devenir un outil vivant, capable de représenter l’état réellement installé. L’enjeu n’est pas d’imposer un logiciel de modélisation particulier mais de préserver les relations de preuve entre ce que l’on croit posséder et ce qui est effectivement à bord.

Vérifier l’architecture par des preuves croisées plutôt que par une collection de tests isolés

La vérification d’un composant prouve qu’il satisfait une exigence dans des conditions définies. Elle ne prouve pas automatiquement que le système intégré se comportera correctement. Un essai d’architecture doit chercher les interactions : démarrage après longue dormance, basculement de bus pendant une forte charge, perte d’un capteur pendant une manœuvre, mise en refuge avec un équipage réduit, reprise après une mise à jour logicielle ou maintien d’un service lorsque plusieurs équipements demandent simultanément une ressource rare.

La hiérarchie des preuves peut être pensée comme une échelle. En bas : calcul analytique et simulation. Puis viennent l’essai de composant, l’essai de sous-système, l’essai d’interface, l’essai intégré, les répétitions représentatives de la durée et enfin l’expérience opérationnelle. Aucune marche ne rend les autres inutiles. Une simulation permet d’explorer des milliers de cas qu’un essai ne pourra jamais reproduire ; un essai révèle des comportements physiques oubliés par le modèle. Le but est de faire converger ces preuves jusqu’à ce que les grandes inconnues résiduelles soient identifiées et acceptées en connaissance de cause.

Pour un vaisseau martien, une preuve supplémentaire est essentielle : la capacité de revenir à un état maîtrisé après une intervention. Une réparation n’est pas terminée lorsque la pièce est remontée ; elle l’est lorsque l’équipe a démontré que la fonction est revenue, que les protections sont restaurées, que la configuration est enregistrée et que les systèmes voisins n’ont pas été dégradés. Cette discipline transforme la maintenance en prolongement de l’ingénierie système.

Repère de calcul. Si une architecture comporte dix fonctions critiques, chacune disponible 99,9 % du temps et que leur indisponibilité était réellement indépendante, la disponibilité simultanée de l’ensemble serait approximativement 0,999¹⁰ ≈ 0,990, soit environ 99,0 %. Ce calcul simplifié montre pourquoi une excellente disponibilité locale ne suffit pas lorsque de nombreuses fonctions sont requises en série. Dans la réalité, les dépendances et causes communes rendent l’analyse plus complexe ; l’hypothèse d’indépendance doit donc être explicitement démontrée avant d’utiliser ce produit.

Repères documentaires utilisés pour cette extension : NASA Systems Engineering Handbook, NASA-HDBK-1009A — Systems Modeling Handbook, Moon to Mars Architecture — Components et Architecture Definition Documents. Ces références décrivent des méthodes et architectures NASA ; les scénarios chiffrés Delta-Sierra ci-dessus restent des exercices d’ingénierie explicitement prospectifs.

Étude de cas — une modification locale consomme plusieurs budgets

Un vaisseau de 28 t de masse sèche, 8 t de consommables et 22 t d’ergols atteint 58 t avant marge. Une réserve de 10 % appliquée à la masse sèche ajoute 2,8 t : m_plan = 60,8 t. Le symbole t désigne ici la tonne métrique. La marge doit rester visible pour éviter qu’elle soit dépensée deux fois.

Un calculateur plus puissant augmente simultanément consommation électrique, chaleur à rejeter, masse de câblage ou de batterie et parfois exigences de refroidissement. Le mode sûr teste si les chaînes réellement survivantes restent cohérentes après la perte d’un bus.

La recette système enchaîne démarrage à froid, bascule de puissance, perte d’horloge, recharge après éclipse et redémarrage logiciel afin de vérifier les interfaces plutôt que des boîtes isolées.

Changer une interface sans casser silencieusement le reste du véhicule

La vie réelle d’un système complexe est faite de changements : un capteur n’est plus disponible, un fournisseur remplace une carte, une pompe de rechange possède une courbe différente, une version logicielle change un protocole ou une limitation thermique impose un nouveau mode. Le danger n’est pas seulement que le nouvel élément soit mauvais. Il peut être excellent pris isolément et rendre fausse une hypothèse utilisée ailleurs. L’ingénierie d’interface sert à suivre cette propagation.

Une modification de débit illustre le mécanisme. Si une nouvelle pompe peut fournir 15 % de débit supplémentaire, la conduite accepte-t-elle la vitesse plus élevée ? Le filtre supporte-t-il la perte de charge ? La puissance électrique de pointe reste-t-elle disponible ? Le refroidissement de la pompe est-il suffisant ? Le capteur conserve-t-il sa plage ? Une phrase comme « pompe plus performante » n’a donc aucune signification architecturale tant que ces conséquences ne sont pas vérifiées.

La modification doit être associée à une liste d’hypothèses impactées, aux analyses à rejouer et aux essais nécessaires. Le modèle système peut aider à retrouver ces dépendances, mais la responsabilité reste humaine : il faut décider quelles relations sont assez importantes pour être maintenues explicitement. Un graphe énorme de toutes les dépendances serait inutilisable ; un ensemble plus petit d’interfaces critiques peut au contraire servir pendant une urgence.

Le changement logiciel possède la même logique. Modifier la fréquence d’un message peut augmenter l’occupation d’un bus, la charge processeur, le stockage de télémesure et parfois la consommation électrique. Une nouvelle variable peut sembler locale et modifier le format d’un paquet utilisé par plusieurs outils. La gestion de configuration doit donc relier la modification à ses consommateurs et conserver la possibilité de revenir à une version connue.

Sur Mars, cette discipline protège surtout contre l’érosion lente de la connaissance. Après plusieurs années de réparations, l’équipe ne doit pas dépendre de la mémoire de quelques personnes pour savoir pourquoi une limite existe. Une interface documentée, une raison de conception et un essai de retour au service constituent une mémoire transmissible à l’équipage suivant.

La maturité d’une architecture peut ainsi se mesurer par une question très concrète : lorsqu’un élément change, peut-on expliquer rapidement quelles preuves deviennent suspectes ? Si la réponse exige de relire tout le projet depuis zéro, l’architecture n’est pas suffisamment structurée pour une exploitation longue. Si l’on peut identifier les interfaces, les budgets et les modes concernés, le véhicule possède une véritable capacité d’évolution contrôlée.

Le critère final : conserver des options lorsque le modèle cesse d’être parfait

Une architecture interplanétaire n’est jamais démontrée par le fait que tout fonctionne comme prévu. Sa valeur apparaît lorsque la situation réelle sort du modèle : capteur incohérent, pièce remplacée par une autre révision, ressource moins abondante, équipage fatigué ou communication interrompue. Le véhicule doit alors continuer à offrir des états compréhensibles et des chemins de récupération. Une conception qui possède d’excellentes performances nominales mais une seule manière de fonctionner reste fragile.

Cette idée peut être traduite par trois questions lors des revues. Quel service vital est réellement menacé ? Quelles dépendances peuvent propager le défaut ? Quelles options restent si la première récupération échoue ? Ces questions évitent de confondre la santé d’un composant avec la santé de la mission. Elles obligent aussi à conserver des marges de puissance, de thermique, de temps équipage et de configuration pour les situations non nominales.

Le nombre d’options ne doit pas devenir un nouvel indicateur artificiel. Certaines options ne sont que théoriques si elles exigent une pièce absente, une compétence indisponible ou une manœuvre impossible à la date considérée. La preuve d’une option comprend donc les ressources, l’accès, la procédure, la limite physique et le temps nécessaire pour l’exécuter.

À cette condition, l’architecture devient la mémoire de ce qui rend la mission récupérable. Elle ne cherche pas à prédire toutes les pannes ; elle organise assez bien les fonctions et les interfaces pour que l’équipage puisse encore raisonner lorsque survient une panne qui n’avait pas été écrite exactement dans le scénario.

Sources et références

Sources NASA primaires

Ces références servent de garde-fou documentaire ; elles ne transforment pas les choix prospectifs discutés ici en architecture officielle NASA.

Sources primaires et repères de recherche

Sources de référence vérifiées le 14 août 2026.