Ce que SpaceX fait de ses échecs

Récemment, j’ai construit un petit outil personnel : un tableau de bord des vols SpaceX, à partir des données publiques de Launch Library 2. Rien d’ambitieux. Je voulais surtout un endroit propre pour suivre les prochains lancements et fouiller les archives.

En remplissant la base, j’ai fini par parcourir la liste complète, du premier Falcon 1 en 2006 à aujourd’hui. Et ce qui m’a frappé, c’est la quantité d’échecs qu’il y a derrière les succès récents. Falcon 1 a raté ses trois premiers vols. Les prototypes de Starship ont explosé les uns après les autres, en direct. Pour une entreprise qu’on présente comme une machine à gagner, le tableau de chasse est surtout fait de ratages.

Ça m’a fait repenser à la façon dont SpaceX travaille, et à ce que ça devrait changer dans ma manière de faire du logiciel.

Ce qu’on crédite, et ce qui compte vraiment

Le moteur Raptor, la récupération des étages, un booster qu’on fait revoler dix fois : ce sont de vraies prouesses, et elles comptent. Qu’Elon Musk ait mis sa fortune et sa réputation dans la balance compte aussi. Rien de tout ça n’est un détail.

Ce dont on parle moins, c’est de la méthode qui a rendu ces prouesses atteignables. SpaceX s’est donné une boucle où rater tôt coûte peu et apprend beaucoup. Le Raptor et la réutilisation sont le produit de cette boucle. C’est elle qui m’intéresse ici, parce que c’est la partie qui se transpose à d’autres métiers.

Regarde Falcon 1. Quatre tentatives entre 2006 et 2008, trois échecs. Le premier vol part en fumée à la première minute, une ligne de carburant qui lâche. Au deuxième, le second étage s’arrête trop tôt, un problème de contrôle en roulis. Au troisième, les deux étages se percutent après la séparation. Le quatrième, le 28 septembre 2008, atteint l’orbite. D’après la presse spatiale de l’époque, SpaceX était alors à court d’argent et ce vol était le dernier que la boîte pouvait se payer. Trois échecs assumés en public, puis la survie qui tient à un seul lancement.

Starship, c’est la même logique poussée plus loin. On construit un prototype, on le pousse jusqu’à la casse, on regarde ce qui a lâché, on construit le suivant. Fin 2025, une dizaine de vols d’essai intégrés, plusieurs explosions complètes, et le premier étage rattrapé au vol par la tour de lancement à trois reprises. SpaceX assume la méthode ouvertement : on teste, on casse, on apprend, on recommence.

Compare avec le SLS de la NASA. Plus de dix ans entre le lancement du programme et le premier vol. L’inspecteur général de la NASA chiffre un lancement du système SLS plus Orion autour de quatre milliards de dollars. À ce prix, tu n’as pas le droit de rater. Tu valides tout sur plan, tu testes chaque sous-ensemble au sol, tu voles une fois tous les deux ou trois ans, et le premier vol doit être le bon.

SpaceX a fait un autre pari : rendre un ratage assez peu cher pour pouvoir en encaisser souvent. Ce pari a été pris en amont, avant la première soudure. C’est là qu’est le coup de génie, au sens propre. Quelqu’un a regardé une industrie entière et a décidé de changer sa boucle de développement. Une grande part du reste, la technique comprise, a pu se construire parce que ce choix avait été fait en premier.

La condition qu’on saute presque toujours

Cette boucle se transpose au logiciel, et sur le principe on la connaît déjà : livrer souvent, tester en continu, avancer par petits pas. Sauf qu’on saute presque toujours l’étape qui rend tout le reste possible.

SpaceX ne lance pas tôt par insouciance. Avant de faire exploser un Starship, l’engin est couvert de capteurs. Quand il part en morceaux, les équipes savent quelle vanne a lâché, à quelle seconde, sous quelle pression. L’explosion coûte un prototype et elle rapporte un rapport d’incident complet. Le ratage est bon marché, et il est lisible.

En logiciel, cette étape a un nom : l’outillage qui rend un incident peu cher. Un rollback qui tient en une commande. Des feature flags pour couper une fonctionnalité sans redéployer. Des logs et des traces qui racontent ce qui s’est passé quand personne ne regardait. Rien de tout ça ne produit une fonctionnalité visible. C’est pour cette raison qu’on le repousse, sprint après sprint, jusqu’au jour où un déploiement casse à 23h.

Ce jour-là, il y a deux situations. Dans la première, tu lis trois lignes de log et tu sais quoi corriger. Dans la seconde, il n’y a rien à lire : pas d’erreur, pas de trace, juste un comportement faux quelque part. Le premier incident se règle en trente minutes. Le second te prend la soirée et une bonne dose de doute.

Les deux pannes peuvent être aussi graves l’une que l’autre. La différence, c’est que l’une parle et l’autre non. Rendre l’échec lisible, c’est le travail qu’on fait avant de se donner le droit d’aller vite. Livrer par petits pas participe du même calcul : un changement minuscule qui casse se comprend et s’annule en quelques minutes.

Ensuite, brancher le réel le plus tôt possible

Une fois que rater est bon marché et lisible, on peut connecter la réalité tôt. Sur ce point je suis devenu assez strict : je code contre des données réelles dès que possible, pas contre des fixtures que j’ai fabriquées.

Une fixture, c’est pratique. Elle est propre, stable, elle tient dans un fichier. Elle a aussi un défaut de fond : elle reflète ma compréhension du problème au moment où je l’écris. Les dates sont bien formées, les champs obligatoires sont remplis, les cas limites sont ceux auxquels j’ai pensé. Autrement dit, elle contient exactement mes angles morts, et rien d’autre.

Les vraies données, elles, arrivent avec les cas que je n’ai pas imaginés. Une source tierce qui renvoie une précision variable d’un enregistrement à l’autre. Un champ censé être unique qui ne l’est pas. Deux informations que je croyais liées et qui sont publiées séparément. Ces surprises coûtent une demi-journée quand elles apparaissent en développement. Elles coûtent un incident quand elles apparaissent en production parce que j’ai validé six mois sur des fixtures trop gentilles.

Tester tôt sur du réel, c’est accepter de voir ces cas tant qu’ils coûtent encore peu.

Là où cette boucle ne marche pas

Cette approche a une limite, et elle est nette. Le jour, je travaille sur du logiciel médical. Un bug qui part en production sur une aide à la prescription, tu ne le rejoues pas pour voir. Il n’existe pas de version jetable d’une ordonnance. Dans ce contexte, le coût d’un échec ne baisse pas, quoi que tu fasses côté outillage. La boucle s’inverse : tu paies le prix de la validation avant, lourdement, parce que tu ne pourras pas le payer après. La méthode de SpaceX suppose qu’un ratage est récupérable. Quand il ne l’est pas, elle ne s’applique pas telle quelle.

La question que je garde

Je n’aurais pas prévu qu’un petit tableau de bord des vols SpaceX me laisse une question de fond sur mon métier. C’est pourtant ce qui s’est passé.

D’habitude, on juge une équipe à sa vitesse : le nombre de tickets, la fréquence des déploiements, le backlog qui descend. Je me demande si la vraie mesure n’est pas ailleurs. Quand quelque chose casse, est-ce que ça coûte un après-midi ou un trimestre ? Est-ce que la panne s’annonce toute seule, ou est-ce qu’il faut une journée pour comprendre ce qui s’est passé ?

Une équipe qui a de bonnes réponses à ces deux questions peut se permettre d’aller vite. Les autres gagneraient à ralentir le temps de s’équiper.