Vaisseau spatial : apprendre à penser en système
Un vaisseau interplanétaire n’est pas une collection d’équipements. C’est un système de systèmes : énergie, thermique, structure, avionique, propulsion, communications, support-vie et équipage partagent masse, volume, chaleur, puissance, données et modes de panne. Ce module apprend à lire une architecture par ses budgets et ses interfaces.
1. Commencer par les fonctions, pas par la liste des composants
Avant de choisir une batterie ou un ordinateur, on définit les fonctions : produire et distribuer l’énergie, contrôler la température, connaître l’état du véhicule, communiquer, commander les actionneurs, stocker les consommables, protéger l’équipage et survivre aux pannes. Une fonction peut avoir plusieurs solutions techniques ; cette séparation évite de confondre besoin et produit.
Décomposer les fonctions avant de choisir le matériel
Un vaisseau peut être décrit par quelques fonctions fondamentales : maintenir une trajectoire, produire et distribuer l’énergie, contrôler la température, communiquer, connaître son état, protéger l’équipage ou la charge utile et exécuter les changements de mode. Cette décomposition empêche de partir trop tôt d’un catalogue d’équipements. Par exemple, « connaître l’attitude » peut mobiliser viseurs d’étoiles, centrales inertielles et logiciel d’estimation ; « modifier l’attitude » peut utiliser roues, propulseurs ou autres actionneurs. Le besoin est d’abord exprimé en performance, disponibilité et précision. Ce n’est qu’ensuite que le matériel est choisi. Cette méthode révèle les fonctions qui dépendent d’une même ressource et donc les pannes communes que la simple liste des composants masque.
2. Le budget de masse ferme la première boucle
La masse totale inclut charge utile, structure, sous-systèmes, consommables et marges. Une marge n’est pas « de la masse gratuite » : elle reconnaît qu’un design préliminaire évolue. Lorsque le projet mûrit, les marges sont consommées ou libérées à mesure que les inconnues diminuent.
Exercice A — budget de masse
Un véhicule dispose d’une limite de 50 t. Structure 10 t, propulsion sèche 5 t, énergie 4 t, thermique 2 t, avionique/communications 2 t, habitat/équipage 12 t et consommables 8 t. Quelle marge reste-t-il ?
Somme = 43 t. Marge = 50 − 43 = 7 t, soit 14 % de la limite. Cette marge ne prouve pas que le véhicule est bon : le volume, le centre de gravité et les performances propulsives doivent aussi fermer.
3. Un budget de puissance comporte moyenne, pointe et énergie
La puissance, en watts, est un débit d’énergie. Une charge de 5 kW pendant 8 h consomme 40 kWh. Une batterie doit fournir cette énergie tout en respectant profondeur de décharge, rendement, température et puissance de pointe. Additionner seulement les puissances nominales peut masquer un scénario où plusieurs charges critiques démarrent simultanément.
Exercice B — réserve batterie
Une fonction critique demande 5 kW pendant 8 h. Si seulement 80 % de l’énergie nominale de la batterie est utilisable et que le rendement global est 90 %, quelle capacité nominale minimale faut-il ?
Énergie utile = 5 × 8 = 40 kWh. Capacité nominale = 40 ÷ (0,80 × 0,90) ≈ 55,6 kWh. On ajouterait encore les marges de vieillissement et de température.
Fermer ensemble masse, puissance et énergie
Un budget de puissance en watts ne suffit pas à dimensionner une batterie. Il faut aussi l’énergie, en wattheures ou joules. Si une charge de 800 W fonctionne pendant 3 h sans production, elle demande idéalement E = Pt = 800 × 3 = 2 400 Wh, soit 2,4 kWh. Avec seulement 80 % de profondeur de décharge utilisable, la capacité nominale doit dépasser 2,4/0,8 = 3,0 kWh avant même d’ajouter vieillissement et marge. Cette énergie devient masse de batterie et chaleur à évacuer. Une architecture crédible boucle donc puissance moyenne, pics, durée des modes, capacité de stockage, rendement des convertisseurs et dissipation thermique. Les marges doivent être associées à une incertitude identifiable plutôt qu’empilées arbitrairement.
4. Toute puissance électrique finit presque en chaleur
Dans un vaisseau, les ordinateurs, pompes, éclairages et électroniques dissipent de la chaleur. Dans le vide, cette chaleur doit finalement être rayonnée. Le thermique et l’énergie sont donc couplés : augmenter la puissance d’un équipement peut exiger plus de radiateur, donc plus de masse et de surface.
Puissance consommée et chaleur rejetée sont presque la même histoire
Dans un vaisseau, l’énergie électrique consommée finit en grande partie sous forme de chaleur, directement ou après avoir produit un service. Un ordinateur de 300 W, une pompe de 200 W et des équipements de cabine de 1 500 W représentent déjà environ 2 kW de chaleur à gérer lorsque cette puissance ne quitte pas le véhicule sous une autre forme. En régime stationnaire, le contrôle thermique doit rejeter une puissance moyenne comparable. Mais les transitoires comptent : un équipement peut fonctionner dix minutes à forte puissance puis rester éteint. La masse thermique et les boucles fluides lissent ces variations. Le budget électrique doit donc fournir au thermique une chronologie, pas seulement une moyenne annuelle.
5. L’avionique doit connaître, décider et pouvoir revenir en arrière
Les capteurs produisent des mesures ; les calculateurs estiment l’état ; le logiciel décide ; les actionneurs modifient le véhicule. Le FDIR — Fault Detection, Isolation and Recovery — surveille les écarts, isole des fautes et place le système dans un état récupérable. Un safe mode n’est pas simplement « éteindre le maximum » : il conserve énergie, thermique, attitude et communications dans une configuration stable.
6. Les modes rendent les interfaces visibles
Transit nominal, manœuvre, occultation, tempête solaire, perte d’énergie, safe mode, approche de Mars : chaque mode active des charges et des priorités différentes. Une matrice modes × fonctions révèle les dépendances : une antenne haut gain peut être indisponible pendant une manœuvre d’attitude ; un radiateur peut imposer une orientation ; une propulsion peut perturber des capteurs.
7. La panne la plus dangereuse est souvent commune
Deux ordinateurs identiques ne protègent pas contre un bug logiciel commun. Deux pompes sur la même alimentation ne protègent pas contre la perte du bus. La fiabilité exige de chercher les ressources communes : énergie, refroidissement, logiciel, capteur de référence, vanne, connecteur, procédure humaine.
Les modes sont une architecture visible
Un vaisseau n’utilise pas tous ses sous-systèmes de la même façon en croisière, correction de trajectoire, sommeil équipage, communication à haut débit ou situation de survie. Une table de modes indique quelles fonctions sont actives, quelles ressources elles consomment, quels changements sont autorisés et quelles conditions permettent d’en sortir. Cette table expose immédiatement les interfaces : un mode sûr qui coupe un bus de données peut aussi retirer le capteur nécessaire pour comprendre la panne. Le FDIR doit donc préserver une chaîne minimale de commande et de télémétrie. Une bonne récupération ne consiste pas à redémarrer tout le vaisseau ; elle revient par étapes dans une configuration connue, avec confirmation de chaque ressource critique.
8. Vérification et validation : prouver le système complet
Tester un équipement seul ne prouve pas l’interface. Les essais d’intégration vérifient données, alimentation, thermique, mécanique et séquences. Les simulations hardware-in-the-loop mettent de vrais calculateurs face à des environnements simulés. Les essais doivent inclure les modes dégradés et la restauration, pas seulement le scénario nominal.
Vérifier et valider ne répondent pas à la même question
La vérification demande si une exigence définie est satisfaite : tension dans une plage, capacité de batterie, précision de pointage, résistance mécanique. La validation demande si l’ensemble d’exigences et la solution répondent réellement au besoin de mission. Un système peut donc être parfaitement vérifié et néanmoins mal adapté à l’usage. Les essais d’un vaisseau martien combinent niveaux : composants, logiciels, sous-systèmes, interfaces et scénarios intégrés. Comme on ne peut pas reproduire sur Terre toute une mission de plusieurs années, les preuves mélangent essai, analyse, simulation et héritage. Chaque argument doit préciser ce qui est directement démontré et ce qui reste extrapolé.
9. Attention aux états de l’art
Le rapport NASA 2026 sur les petits véhicules spatiaux est très utile pour les familles de composants — énergie, GNC, thermique, avionique, communications — mais son périmètre est explicitement SmallSat. Il ne qualifie pas un vaisseau humain martien. Un cours sérieux distingue l’état de l’art d’un composant de la preuve d’une architecture complète.
10. Vérification
- Expliquez la différence entre fonction et composant.
- Refaites l’exercice A avec 3 t supplémentaires de blindage.
- Expliquez pourquoi 5 kW et 40 kWh ne désignent pas la même chose.
- Donnez un exemple de panne de cause commune.
- Expliquez ce qu’un safe mode doit préserver.
11. Construire une matrice d’interfaces
Prenez cinq sous-systèmes : énergie, thermique, avionique, propulsion et communications. Placez-les en lignes et colonnes d’un tableau. Pour chaque intersection, écrivez ce qui traverse l’interface : watts, chaleur, données, couple mécanique, fluide, synchronisation, commande. La matrice révèle rapidement les dépendances invisibles. Par exemple, communications reçoit de l’énergie, rejette de la chaleur, demande une attitude et fournit des données à l’avionique.
Une interface doit avoir un propriétaire, une unité, une plage nominale et des conditions dégradées. « Bus 28 V » ne suffit pas si l’on ignore ondulation, courant de pointe, transitoire, tolérance et comportement en sous-tension.
Une interface possède aussi un propriétaire et un essai
La matrice d’interfaces n’est utile que si chaque ligne conduit à une exigence mesurable. Pour une alimentation, on indique tension, courant, transitoires, protections et connecteur ; pour des données, protocole, débit, latence, synchronisation et comportement après perte ; pour une interface thermique, flux admissible et conditions de contact. Un responsable doit accepter les deux côtés de l’interface et un moyen de vérification doit exister. Cette discipline devient cruciale lors des modifications : remplacer un ordinateur peut changer consommation, chaleur, masse, connectique et logiciel simultanément. La gestion d’interface empêche une amélioration locale de devenir une panne d’intégration.
12. Dimensionner un radiateur avec Stefan-Boltzmann comme première intuition
Un radiateur idéal suit approximativement P = εσAT⁴. P est puissance rayonnée en W, ε l’émissivité sans unité, σ ≈ 5,670×10⁻⁸ W/m²/K⁴, A l’aire en m² et T la température absolue en kelvins. L’environnement réel ajoute vue vers le Soleil, planète, autres surfaces et conductances internes, mais la loi montre l’effet très fort de T.
Exercice C — aire idéale
Pour P = 5 000 W, ε = 0,85 et T = 300 K, estimez A en supposant une vue parfaite vers l’espace froid.
εσT⁴ ≈ 0,85 × 5,67×10⁻⁸ × 300⁴ ≈ 390 W/m². A ≈ 5 000/390 ≈ 12,8 m². Un vrai radiateur aura d’autres échanges et des marges.
13. Données : débit, latence et criticité ne sont pas la même chose
Une caméra peut produire beaucoup de données mais ne pas être critique à la milliseconde. Une centrale inertielle produit moins de données mais avec des délais stricts. Le réseau avionique doit donc classer trafic et délais, gérer perte de paquets, saturation et priorité. Un bus redondant ne protège pas d’un logiciel qui inonde simultanément les deux voies.
14. Configuration : savoir exactement quelle version vole
Un vaisseau long-courrier peut recevoir des mises à jour. La configuration doit relier matériel, firmware, logiciel, paramètres, tables de calibration et procédures. Après une mise à jour, le système doit savoir revenir à une version précédente si les tests embarqués échouent. La capacité de rollback fait partie de la sûreté logicielle.
La configuration relie matériel, logiciel et preuve
Dire qu’un vaisseau a été testé ne suffit pas ; il faut savoir quelle configuration l’a été. Numéro de série, version logicielle, calibration, paramètres, câblage et modifications doivent être reliés aux résultats. Si un correctif de logiciel change une logique FDIR après un essai thermique, certaines preuves restent valides et d’autres doivent être rejouées. La configuration sert aussi en vol : face à une anomalie, l’équipage et la Terre doivent savoir exactement quelle version tourne et quelles dérogations ont été acceptées. Sur une longue mission martienne, où plusieurs mises à jour peuvent être installées, cette traçabilité devient une composante directe de la sûreté.
15. FDIR : détecter, isoler, récupérer
Détecter : constater qu’une observation sort d’une enveloppe ou qu’un modèle ne prédit plus correctement. Isoler : déterminer quelle partie est fautive, avec un niveau de confiance. Récupérer : reconfigurer pour maintenir les fonctions prioritaires. Ces étapes ont des temps différents ; certaines pannes exigent une réaction en millisecondes, d’autres permettent une analyse sur plusieurs minutes.
Exercice D — faux consensus
Deux calculateurs identiques donnent la même valeur, tandis qu’un capteur indépendant la contredit. Peut-on conclure que le capteur est faux ?
Non. Les deux calculateurs peuvent partager le même code, la même donnée d’entrée ou la même erreur de configuration. Il faut chercher une preuve indépendante : autre capteur, modèle physique, mesure manuelle, historique ou test actif.
16. Verification matrix : exigence → preuve
Chaque exigence doit pointer vers une méthode : analyse, inspection, essai ou démonstration. « Le véhicule doit survivre à une perte de bus » n’est vérifié que si l’on définit le bus, la perte, l’état initial, les fonctions devant rester actives et les critères de réussite. Une vérification floue fabrique un faux PASS.
La validation pose une question différente : même si le système respecte toutes ses exigences, répond-il réellement au besoin de mission ? Un véhicule peut être parfaitement conforme à une mauvaise spécification.
La matrice d’interfaces empêche les dépendances invisibles
Pour chaque paire de sous-systèmes, on note ce qui traverse l’interface : puissance, données, chaleur, fluide, effort mécanique, radiofréquence ou autorité de commande. Une interface possède une plage normale et des cas de panne. Un calculateur peut recevoir une tension correcte tout en ne recevant plus une référence temporelle cohérente ; un radiateur peut être sain mais perdre la circulation de fluide qui lui apporte la chaleur. La matrice doit aussi identifier le propriétaire de chaque exigence et le moyen de vérification. À mesure que le design évolue, cette discipline évite qu’une modification locale transforme silencieusement la marge d’un autre sous-système. C’est l’un des liens les plus directs entre ingénierie système et prévention des causes communes.
17. Mini-projet — revue d’architecture en mode panne
- Dessinez cinq services : énergie, thermique, avionique, communication, propulsion.
- Ajoutez leurs interfaces.
- Supprimez le bus électrique principal.
- Listez ce qui doit rester actif durant 30 minutes.
- Calculez l’énergie de secours nécessaire.
- Vérifiez que le thermique reste compatible.
- Définissez le minimum de télémétrie à transmettre.
- Expliquez comment revenir au service normal.
Ce mini-projet vous oblige à penser en système : une panne électrique devient une question thermique, logicielle, de communication et de procédure.
18. Niveau suivant : de la feuille de calcul au modèle système
Lorsque les interfaces deviennent nombreuses, des outils de MBSE — Model-Based Systems Engineering — peuvent structurer exigences, fonctions et interfaces. Ils ne remplacent pas le raisonnement. Un modèle détaillé contenant une unité fausse ou une dépendance oubliée reste faux. La Space Academy utilise donc d’abord des bilans simples et traçables, puis passe aux outils lorsque le problème justifie leur complexité.
Studio d’ingénierie — fermer masse, puissance et marge
Le vaisseau d’exercice possède une masse cible de 60 t, une production électrique disponible de 18 kW dans le mode étudié et 14 kW de charges déjà engagées. Une nouvelle informatique ajoute 0,4 t et 1,2 kW. La marge de puissance passe alors de 4,0 kW à 2,8 kW, soit une diminution de 30 %. Le calcul oblige à suivre deux budgets à la fois : la masse en tonnes et la puissance instantanée en kilowatts ; aucune de ces grandeurs ne peut être échangée directement contre l’autre.
Dans le mode dégradé, un convertisseur impose encore 0,8 kW de pertes. L’élève doit décider quelles charges peuvent être délestées sans perdre navigation, thermique ou communications de sécurité. Il doit aussi rechercher les effets secondaires : plus de chaleur à rejeter, une batterie sollicitée plus longtemps et éventuellement une masse de radiateur ou de câblage supplémentaire. Le capstone fait ainsi apparaître le vaisseau comme un système couplé.
Budget couplé — un kilowatt supplémentaire devient aussi de la masse et de la chaleur
Imaginons une charge utile demandant 1 kW en continu. Avec un rendement de conversion de 90 %, le réseau amont doit fournir environ 1,11 kW et près de 0,111 kW deviennent des pertes. Sur 24 heures, cela représente environ 2,67 kWh d’énergie dissipée que le contrôle thermique doit rejeter ou stocker. Le calcul est élémentaire, mais il montre une règle système : une modification électrique est en même temps une modification thermique et souvent une modification de masse.
Ajoute ensuite une autonomie batterie de deux heures sans génération. La batterie doit couvrir la charge utile, les pertes de conversion et ses propres marges ; sa masse modifie à son tour la structure et les manœuvres. Un budget de vaisseau est donc un réseau de grandeurs couplées. L’objectif n’est pas de trouver une batterie « parfaite », mais de suivre la propagation d’une exigence dans plusieurs sous-systèmes.
Sources et références
NASA — 2026 State-of-the-Art of Small Spacecraft Technology · NASA Johnson Engineering · NASA/JPL — Mission to Mars Unit.
FDIR : la récupération doit être démontrée, pas seulement nommée
FDIR signifie Fault Detection, Isolation and Recovery : détection, isolation et récupération après défaut. Détecter consiste à reconnaître qu’un état n’est plus cohérent ; isoler cherche quelle fonction ou chaîne est responsable ; récupérer place le système dans un état sûr ou utile. Les trois étapes n’ont pas besoin d’être parfaites au même instant. Une anomalie peut être détectée rapidement puis isolée plus tard, à condition que le mode provisoire protège les ressources critiques. Les essais injectent des défauts réalistes — capteur bloqué, donnée incohérente, perte de bus, actionneur lent — et vérifient non seulement l’alarme mais l’état final du véhicule. Une logique FDIR qui génère une cascade d’actions incompréhensibles peut être plus dangereuse que le défaut initial.