Le génie logiciel sans pouvoir redémarrer le serveur

Votre serveur web plante à 3 h du matin. Kubernetes le redémarre. Les utilisateurs voient une page d'erreur pendant quelques secondes. Personne ne se fait virer. Imaginez maintenant que votre serveur orbite autour de Mars, que le redémarrage prenne 45 minutes (pendant lesquelles vous n'avez plus de contrôle d'attitude, plus de régulation thermique et plus de communication), que l'« utilisateur » soit un vaisseau spatial à 2,5 milliards de dollars, et qu'il n'y ait pas de Kubernetes, juste votre code et le processeur durci contre les radiations sur lequel il tourne.

Le logiciel spatial évolue sous des contraintes qui font paraître le développement classique plutôt décontracté. Impossible de déployer un correctif à chaud. Impossible de se connecter en SSH pour regarder les logs. Impossible d'ajouter des serveurs quand la charge augmente. Chaque ligne de code doit être correcte avant le lancement, car une fois la sonde partie, le logiciel est livré à lui-même pendant des années, voire des décennies, sur un matériel que les radiations dégradent peu à peu, avec une liaison de communication qui accuse des délais de plusieurs minutes et un débit de quelques kilobits par seconde.

Les contraintes qui façonnent tout

Les radiations. Dans l'espace, des particules de haute énergie bombardent en permanence l'électronique. Une seule particule peut inverser un bit en mémoire (un single-event upset, ou SEU), corrompre un registre ou bloquer un processeur. Ce n'est pas rare : les satellites en orbite basse subissent des milliers d'inversions de bits par jour. Le matériel spatial utilise donc des composants durcis contre les radiations, plus lents, plus chers et en retard de plusieurs générations sur le matériel grand public. Le processeur du rover Mars Perseverance est un RAD750, à peu près l'équivalent d'un PowerPC de 1998 cadencé à 200 MHz.

Les délais de communication. Par radio, Mars est à 4 à 24 minutes de la Terre selon sa position orbitale. Jupiter, à 33 à 54 minutes. Ce n'est pas qu'une question de latence : le vaisseau doit gérer seul tout problème pendant au moins l'aller-retour, avant même que le contrôle au sol puisse constater l'anomalie, et a fortiori envoyer une commande. Lorsque les sondes Voyager rencontrent une anomalie à plus de 22 heures-lumière de la Terre, le logiciel prend ses propres décisions pendant près de deux jours.

Aucun accès physique. Impossible de remplacer un composant défaillant, d'ajouter de la RAM ou de changer un disque dur. Si l'ordinateur principal tombe en panne et que la sauvegarde ne fonctionne pas, la mission est terminée. Chaque mode de défaillance doit donc être anticipé dans le logiciel avant le lancement.

En quoi le code spatial est différent

Le logiciel spatial utilise des techniques qui seraient jugées absurdement surdimensionnées dans le développement classique.

La triple redondance modulaire (TMR). Les calculs critiques sont exécutés trois fois, sur trois processeurs indépendants. Un voteur compare les trois résultats et retient la réponse majoritaire. Si un processeur produit un résultat faux à cause d'un rayonnement, les deux autres le mettent en minorité. Certains systèmes vont jusqu'à cinq exemplaires (pentuple redondance) pour une sécurité supplémentaire.

Le scrubbing mémoire. Un processus en arrière-plan lit en continu la mémoire, la vérifie avec des codes correcteurs d'erreurs (ECC) et corrige les erreurs sur un seul bit avant qu'elles ne s'accumulent en erreurs multi-bits non corrigibles. Cela tourne en permanence : chaque octet de mémoire est vérifié et corrigé plusieurs fois par seconde.

Les chiens de garde (watchdogs). Ce sont des minuteurs matériels qui doivent être réinitialisés régulièrement par le logiciel. Si celui-ci se bloque (peut-être à cause d'un verrouillage provoqué par les radiations), le minuteur expire et déclenche une réinitialisation matérielle. Le logiciel doit donc être conçu pour survivre à des redémarrages imprévus à n'importe quel moment de son exécution : n'importe quel calcul peut être interrompu puis relancé.

// Simplified space software patterns
// Watchdog — must be kicked regularly or hardware resets
void main_loop(void) {
while (1) {
kick_watchdog();  // Reset the timer — we're alive
// All operations must complete within watchdog timeout
read_sensors();
kick_watchdog();
run_attitude_control();
kick_watchdog();
check_thermal_limits();
kick_watchdog();
process_ground_commands();
kick_watchdog();
}
}
// Critical value stored with redundancy
typedef struct {
int32_t value_a;  // Primary copy
int32_t value_b;  // Redundant copy
int32_t value_c;  // Third copy for voting
} RedundantInt;
int32_t read_redundant(RedundantInt *r) {
// Majority vote — tolerates one corrupted copy
if (r->value_a == r->value_b) return r->value_a;
if (r->value_a == r->value_c) return r->value_a;
if (r->value_b == r->value_c) return r->value_b;
// All three differ — flag anomaly
raise_anomaly(MEMORY_CORRUPTION);
return r->value_a;  // Best guess
}

Le test, c'est le produit

Le Jet Propulsion Laboratory de la NASA estime que les tests du logiciel spatial représentent 60 à 80 % de l'effort total de développement. Pas 60 % du temps, mais 60 % du coût total. Les tests coûtent plus cher que le développement, parce qu'ils doivent prouver la justesse du code à un degré que les tests logiciels classiques n'approchent même pas.

Chaque chemin d'exécution doit être testé. Pas une « couverture de code élevée » au sens où l'entendent les développeurs web, mais littéralement chaque chemin de chaque fonction, y compris les chemins d'erreur, les chemins de timeout et ceux qui gèrent les pannes matérielles. Une couverture de branches à 100 % n'est que le point de départ, pas l'objectif.

Au-delà des tests unitaires, le logiciel spatial passe par des tests hardware-in-the-loop (exécuter le vrai logiciel sur le vrai matériel de vol, en simulant l'environnement spatial), des tests de stress longue durée (tourner pendant des mois pour débusquer les bugs liés au timing) et des tests d'injection de fautes (corrompre volontairement la mémoire, tuer des processeurs et couper les liaisons de communication pour vérifier que le logiciel se rétablit).

La vérification formelle est de plus en plus utilisée pour les composants les plus critiques. Au lieu de tester que le code fonctionne pour des entrées précises, la vérification formelle démontre mathématiquement qu'il fonctionne pour toutes les entrées possibles. C'est coûteux et lent, mais pour le code qui contrôle l'attitude (l'orientation) d'un vaisseau ou gère sa propulsion, le coût se justifie.

Ce qui finit quand même par mal tourner

Malgré cette rigueur, le logiciel spatial échoue. Ces échecs sont instructifs, car ils montrent les limites même de l'ingénierie la plus soignée.

• Mars Climate Orbiter (1999) s'est écrasée parce qu'une équipe utilisait les unités impériales et une autre le système métrique. Le logiciel était correct, mais les spécifications étaient fausses. Aucune quantité de tests ne détecte une mauvaise spécification.
• Ariane 5, vol 501 (1996) a explosé parce qu'un flottant 64 bits a été converti en entier 16 bits, qui a débordé. Le code était repris d'Ariane 4, où cette valeur ne dépassait jamais la plage 16 bits. Le code était correct pour Ariane 4 et catastrophiquement faux pour Ariane 5.
• Mars Polar Lander (1999) s'est probablement écrasée parce que les vibrations d'un capteur pendant le déploiement des pieds ont été interprétées comme un contact avec le sol, ce qui a coupé les moteurs à 40 mètres d'altitude. Un problème d'interprétation de capteur lié au timing, que les tests n'ont pas détecté car ils ne reproduisaient pas fidèlement les caractéristiques des vibrations.
• Le défaut initial du miroir de Hubble (1990) n'était pas un bug logiciel : le miroir a été poli à la mauvaise forme à cause d'un instrument de test mal calibré. L'outil de test lui-même contenait un bug.

Le point commun : le code était conforme à sa spécification, mais la spécification ne correspondait pas à la réalité. C'est le type de bug le plus difficile à prévenir, car il se loge dans l'écart entre le modèle et le monde réel.

Ce que le logiciel terrestre peut apprendre

La plupart d'entre nous n'écrivons pas de logiciel spatial. Mais certaines de ces pratiques se transposent directement à la construction de systèmes fiables sur Terre.

Concevoir pour le redémarrage. Le logiciel spatial part du principe qu'il peut être redémarré à tout moment et doit revenir à un état connu et sain. Les services web devraient avoir la même propriété : si votre serveur plante puis redémarre, retrouve-t-il son fonctionnement sans intervention manuelle ? Reprend-il le traitement là où il s'était arrêté, ou perd-il du travail ? Les patrons de conception défensive que les ingénieurs spatiaux considèrent comme obligatoires sont souvent facultatifs en développement web, mais ils ne devraient pas l'être.

Tester les modes de défaillance, pas seulement les cas nominaux. Les tests du logiciel spatial injectent délibérément des pannes : tuer un processus, corrompre la mémoire, couper les connexions réseau, renvoyer des codes d'erreur pour chaque appel système. La plupart des tests d'applications web vérifient si les fonctionnalités marchent, pas si le système gère les pannes avec élégance.

De la redondance pour les données critiques. Si votre application stocke des données coûteuses à recréer (historiques financiers, contenus utilisateurs, état de configuration), stockez-les en redondance et vérifiez-les régulièrement. La réplication de base de données est l'exemple évident, mais une redondance au niveau applicatif (sommes de contrôle, validation, vérifications d'intégrité périodiques) détecte les corruptions que la réplication propage.

Des chiens de garde pour les processus critiques. Si un processus ne doit jamais se bloquer, surveillez-le. Pas seulement « le processus tourne-t-il ? », mais « le processus avance-t-il ? ». Les health checks qui vérifient que le système fonctionne réellement (traitement des requêtes, mise à jour de l'état, respect des délais) détectent les pannes que la surveillance au niveau du processus laisse passer.

Le nouveau logiciel spatial

L'industrie spatiale commerciale (SpaceX, Rocket Lab, Planet) bouscule certaines de ces traditions. SpaceX utilise Linux et C++ sur les calculateurs de vol de son Falcon 9, un sacrilège selon les standards traditionnels de l'aérospatial. Planet exploite des centaines de petits satellites et les traite davantage comme un système distribué que comme du matériel sur mesure : si un satellite tombe en panne, la constellation compense.

Cette évolution pose une question plus large : quel niveau de fiabilité vous faut-il vraiment ? Un rover martien à 2,5 milliards de dollars justifie cinq ans de tests. Un satellite de communication à 500 000 dollars, parmi des centaines dans une constellation, en justifie beaucoup moins. La pratique d'ingénierie doit correspondre au profil de risque, et non suivre aveuglément des traditions nées d'une autre époque.

Mais la leçon de fond reste valable, quel que soit le budget : un logiciel qu'on ne peut plus atteindre physiquement après déploiement doit être plus fiable qu'un logiciel accessible. Que vous lanciez un vaisseau, déployiez une flotte d'objets connectés ou fassiez tourner un réseau de calcul en périphérie, le principe est le même : si vous ne pouvez pas vous connecter en SSH pour le réparer, le logiciel doit savoir se gérer seul. Appliquée avec discernement, cette mentalité rend tous les logiciels meilleurs.