Les apports croisés des mondes de l’IT et du spatial

Temps de lecture : 12 minutes

Vous vous sentez coupable d’avoir planté une application à cause d’un morceau de code copié-collé depuis Stack Overflow ? Dans cet article, vous apprendrez comment un bête copié-collé a provoqué l’autodestruction de la fusée Ariane 5. Nombreux sont les parallèles entre la conquête spatiale et le monde de l’IT, et si le spatial a apporté à l’IT, l’inverse est également vrai. Passionné depuis l’enfance par l’aviation et la conquête spatiale, et travaillant dans l’IT, j’ai toujours été surpris par les passerelles entre ces deux mondes qui semblent parfois si éloignés. Je vous propose ici un petit tour d’horizon des histoires croisées entre l’IT et le spatial, histoire de prendre un peu de hauteur !

Du spatial à l’IT … et à la vie courante !

Dans notre quotidien, nous devons beaucoup au spatial : la démocratisation du velcro et du téflon ? C’est grâce à la conquête spatiale.

Les IRM ? C’est aussi grâce à la conquête spatiale.

La technologie GPS de vos terminaux s’appuie sur un réseau satellitaire, qu’il n’aurait évidemment pas été possible de mettre en place si la conquête spatiale n’avait pas eu lieu. Il en va de même pour les différentes applications basées sur les satellites (télécommunications, prévisions météorologiques, etc).

Les capteurs CMOS de vos caméras numériques sont le fruit des recherches du JPL (Jet Propulsion Laboratory), dépendant lui aussi de la NASA.

Les microprocesseurs ont aussi connu des progrès importants grâce à la course à l’espace. Par exemple, l’AGC (Apollo Guidance Computer) est le premier ordinateur au monde à être doté de circuits intégrés. Il en va de même pour les langages de programmation de haut niveau, qui n’auraient probablement pas été inventés aussi tôt sans la conquête spatiale.

Et pour les plus techniques d’entre vous, le concept de priorisation des processus utilisé aujourd’hui dans tous les systèmes d’exploitation, a été inventé par Margaret Hamilton, programmeuse à la NASA, tout comme le concept d’interruptions et le multi-tâches.

Il y a aussi des objets plus courants aujourd’hui et moins « technologiques », qui sont des produits directement issus de la conquête spatiale. Parmi ceux-ci on peut citer les couvertures de survie en mylar, les oreillers à mémoire de forme, les airbags, les pompes à insuline ou encore les textiles ignifugés, et bien d’autres encore.

Les apports de la conquête spatiale ne se résument pas aux nouvelles technologies et aux biens manufacturés. D’un point de vue process, si les checklists ont été inventées dans l’aviation (un domaine pas si éloigné du spatial) dans les années 30, c’est bien le monde spatial qui l’a généralisé et popularisé. Le concept est tellement efficace qu’il a été repris dans le monde de l’IT ou encore dans le secteur hospitalier (opératoire).

L’industrie spatiale a donc apporté beaucoup de progrès et d’innovations à nos métiers, et nous pourrions continuer encore longtemps cet inventaire à la Prévert !

Mais l’IT apporte désormais aussi au spatial, notamment via les entreprises du « new space ».

De l’IT au spatial …

Les bugs!

Évacuons tout de suite ce sujet de crispations, qui pourrait parfois faire sourire.

Nos programmes informatiques sont rarement exempts de bugs et autres défaillances, causant des comportements imprévisibles et des résultats parfois inattendus et surprenants . Les programmes informatiques développés dans le secteur spatial ne sont malheureusement pas épargnés.

Ariane 5, ou comment « gaspiller » 370 millions de dollars en 37 secondes

Vous vous sentez coupable d’avoir planté une application à cause d’un morceau de code copié-collé depuis Stack Overflow ? Dans quelques lignes, vous devriez vous sentir mieux !

Le premier vol d’Ariane 5 a eu lieu le 4 juin 1996, et ce fut un échec criant :

37 secondes après le décollage, le pilote automatique déclenche une violente correction de trajectoire. La fusée part en virage serré, dérape, des morceaux des boosters sont arrachés, et le mécanisme d’autodestruction préventive se déclenche.

Mais que s’est-il passé ? La fusée Ariane 4 a servi de modèle de programmation pour la fabrication d’Ariane 5. Plus précisément, du code aurait été récupéré et intégré tel quel dans le programme Ariane 5. Sauf qu’Ariane 5 est beaucoup plus grosse, beaucoup plus lourde qu’Ariane 4.

Les valeurs remontées par les capteurs étaient bien plus élevées sur Ariane 5, et ont causé un integer overflow sur certaines variables : les valeurs en entrée de l’ordinateur de bord étaient donc incohérentes, poussant ce dernier à ordonner des corrections de trajectoire à la fois aberrantes et excessives.

Et donc, ce nouveau lanceur valant 370 millions de dollars sera détruit en 37 secondes, tout cela à cause d’un copier-coller !

Sur une note positive : on a pu valider que le système d’autodestruction fonctionne correctement. Ouf !

Autre exemple plus récent : celui du démonstrateur européen Schiaparelli, qui devait atterrir sur Mars en 2016 dans le cadre de la mission ExoMars. Les choses ne se sont pas passées comme prévues, et l’atterrisseur s’est violemment crashé à la surface de la planète rouge. En cause : des tests d’acceptance “oubliés” et d’autres tests incomplets, et la sonde finit par se retrouver dans un “cas imprévu”, le programme étant incapable d’évaluer sa situation effective et de donner les bonnes directives de contrôle … la suite est assez savoureuse ! 

Pour plus de détails, vous pouvez consulter l’excellent fil Twitter “Techniques Spatiales.

De cette mésaventure, nous pouvons déduire que les tests d’acceptance, c’est vital ! Que celui d’entre nous qui n’a jamais négligé le moindre test (par exemple sous la pression d’un calendrier projet), me jette la première pierre … 

A la NASA aussi

En décembre 1998, la NASA lance la sonde Mars Climate Orbiter vers la planète rouge.

En septembre 1999, alors que le vaisseau devait arriver en orbite martienne, le contact est perdu. L’enquête montrera qu’en fait d’orbite, la sonde s’est vraisemblablement directement crashée sur Mars.

La cause de ce crash a été imputée à une erreur logicielle : la partie développée par la NASA l’a été en utilisant des unités métriques, tandis que la partie du code utilisée par le sous-traitant Lockheed-Martin utilisait … des unités impériales  !

Plusieurs années de travail et de recherches ont donc été réduites à néant, pour une bête erreur de conversion d’unités.

Et les russes ?

Un autre exemple, un peu plus lié au matériel ? En 2013, une fusée russe Proton s’est crashée, donnant lieu à des images impressionnantes.

Les circonstances semblent assez comparables à ce qui s’est passé avec Ariane 5. Ici point d’erreur logicielle, mais plusieurs capteurs d’attitude auraient été montés incorrectement. Ils indiquaient à l’ordinateur de bord que la fusée était dans une position différente de sa position réelle, et l’ordinateur a essayé de corriger.

Tout ceci peut prêter à sourire. Mais qui n’a jamais introduit le moindre bug dans un programme, que celui-ci soit trivial ou complexe ? Bien entendu, les bugs ne sont pas le seul ni le meilleur apport de l’IT au domaine spatial, et heureusement.

Les méthodologies AGILE

Un peu de contexte …

Commençons par une petite remise en perspective. 

Depuis l’arrêt de la navette spatiale en 2011, les USA patinent en matière de vols spatiaux habités. De nombreuses sociétés se sont engouffrées sur ce marché émergent, mais SpaceX est aujourd’hui le seul opérateur américain capable d’envoyer des humains dans l’espace.

La NASA compte aussi s’appuyer sur la capsule Starliner de Boeing : le programme lancé en 2010, la capsule n’a fait qu’un seul volume (non habité) en 2019 et ce fut un échec. Pour l’instant on attend toujours le premier vol habité.

Blue Origin poursuit son programme de développement, mais n’en est qu’aux vols suborbitaux (habités) pour l’instant.

Il y a aussi le programme SLS (« Space Launch System ») de la NASA, avec la capsule Orion : lancé en 2011, le premier vol était initialement prévu en 2017. Maintenant on l’espère pour 2022, et le premier vol habité ne devrait pas avoir lieu avant 2024 pour ce programme qui a déjà coûté plusieurs milliards de dollars (et dont chaque lancement pourrait coûter jusqu’à 2 milliards) !

On pourrait donc se demander : comment a fait SpaceX, pour réussir là où tous les autres semblent sinon échouer … disons, accumuler les retards, les non-qualités et les dépassements de budget ?

La success-story de SpaceX

Pour répondre à cette question, faisons un petit retour en arrière sur l’histoire et le développement de cette société.

Une partie de la réponse provient de la nature même de l’entreprise : SpaceX est une startup, quand la NASA est une administration devenue très bureaucratique, et Boeing est un conglomérat non moins bureaucratique.

L’image de SpaceX est aujourd’hui indissociable de celle de son patron, Elon Musk. On ne le présente plus : Elon Musk a fait carrière (et fortune) dans l’IT, en étant notamment l’un des fondateurs de Paypal. Il n’est pas du « sérail » du spatial, et là où Boeing et la NASA tentent de moderniser l’approche utilisée dans les années 60 avec le programme Apollo. Elon Musk part d’une page blanche. 

En 2002, il fonde SpaceX.

Il commence par développer un lanceur léger, dénommé Falcon1. Ce premier lanceur ne fera que 5 vols seulement (3 échecs, 2 succès) entre 2006 et 2009. Soit moins de 5 ans après le démarrage du projet … à comparer avec les autres programmes de lanceurs évoqués précédemment !

Ils enchaînent rapidement sur le programme Falcon9. Le premier étage de ce nouveau lanceur est propulsé par 9 moteurs du lanceur Falcon1 (d’où le nom). Le second étage utilise une version légèrement modifiée (pour fonctionner dans le vide) du même moteur. La première version de Falcon9 volera dès 2010, et ce premier vol sera un succès. Un lanceur c’est comme un programme informatique. C’est vivant, et ça évolue au cours de sa carrière : les sous-versions suivantes de Falcon9 voleront en 2013 et 2015.

En 2013, SpaceX commencera à essayer de récupérer le premier étage de sa fusée, avec plus ou moins de succès (1 échec en 2013, 2 réussites en 2014, avant de connaître véritablement le succès à partir de 2015). 

Depuis, sur une centaine de récupération d’étages, seules 10 ont été des échecs. Excusez du peu !

Et à ce jour, ce sont encore les seuls opérateurs à utiliser des lanceurs orbitaux réutilisables (si l’on exclut la “défunte” navette spatiale). La première Falcon9 reconditionnée a volé en 2017, et c’est d’ailleurs l’une d’entre elles qui a emmené Thomas Pesquet sur ISS, début 2021. Certains lanceurs totalisent aujourd’hui plus de 10 lancements !

SpaceX prévoit en 2022 de procéder à un tir par semaine. Les derniers échecs du lanceur remontent au printemps 2020, et restent à nuancer : la mission a été accomplie et les charges ont bien été mises sur une orbite correcte, mais la récupération des étages a échoué.

Et l’histoire ne s’arrête pas là !

En 2018, SpaceX effectue le premier vol de son lanceur lourd Falcon Heavy

Celui-ci n’est autre que l’assemblage de 3 premiers étages de Falcon9, déjà éprouvés. Et au-dessus, le reste, vous connaissez.

Le vol est un succès, et les 3 éléments du premier étage sont récupérés, donnant lieu à des images d’atterrissage que même les fans de SF n’auraient pas imaginé voir en vrai !

Quant à la capsule habitée Crew Dragon

Le projet a démarré en 2010 (comme le Starliner de Boeing, en réponse au même appel d’offres), et elle est en fait dérivée du cargo Dragon, qui ravitaille l’ISS depuis 2012.

Le premier vol sans équipage aura lieu en 2019, et le premier vol de démo (avec équipage) en 2020.

La seconde capsule a emmené (et ramené) Thomas Pesquet sur ISS.

Et il y a quelques semaines, c’est le 3ème vol habité Crew Dragon qui vient de partir sur ISS, vols auxquels il faut ajouter le premier vol orbital privé réalisé à l’automne 2021.

Et pendant ce temps, la capsule de Boeing n’a effectué qu’un vol non habité !

Alors … Venons-en (enfin) aux faits : quelle est la méthode SpaceX ?

Et bien c’est la même méthode que nous appliquons tous (ou que nous essayons d’appliquer) : le recours aux méthodes agiles !

Quoi que l’on puisse penser d’Elon Musk (dont beaucoup de “faits d’arme” peuvent être sujets à discussion), la première considération est probablement la plus importante : rien n’aurait probablement pu arriver sans l’impulsion et le leadership d’un entrepreneur qui a une vision et qui n’a pas peur de faire tomber des murs, de transgresser les habitudes.

La légende raconte qu’en 2006 il serait arrivé à un congrès d’astronautique et qu’il se serait présenté en ces termes : “Je m’appelle Elon Musk, je suis le patron de SpaceX. Dans cinq ans, vous êtes tous morts.” 

Rappelons qu’à cette époque, son premier lanceur n’a même pas encore volé.

Si la formule paraît extrême et qu’elle a beaucoup fait sourire à l’époque, les faits semblent lui avoir donné raison : Falcon9 a réalisé son vol inaugural en 2010, les premières récupérations ont été réussies, et le lanceur est devenu en 2017 celui réalisant le plus de lancements dans l’année.

SpaceX a dynamité le coût des mises sur orbite, et aujourd’hui toutes les agences spatiales réfléchissent à la conception de lanceurs réutilisables (un concept défriché par SpaceX).

Si SpaceX occupe la place qu’elle occupe aujourd’hui, c’est parce qu’elle a su transposer les principes du Lean IT et les méthodes AGILE, par exemple en acceptant et adoptant une approche itérative dans le monde du spatial, en acceptant le « fail fast » que la plupart de ses concurrents préfèrent éviter.

Un autre pilier de l’approche SpaceX est (on en a parlé juste avant) la réutilisabilité des matériels (on l’a vu : Falcon Heavy réutilise les éléments de Falcon9, etc) mais aussi des process, des outils et des idées.

Et depuis quelques mois, on parle aussi beaucoup du nouveau programme Starship, le lanceur (très) lourd qu’Elon Musk veut envoyer vers la Lune et vers Mars.

Les méthodes restent les mêmes, et se réclament de la “pensée systémique » (systems thinking) si chère aux DevOps : plutôt que de construire des sous-ensembles et les assembler dans un monolithe en espérant que tout se passe bien, on conçoit un démonstrateur / MVP, que l’on teste et que l’on modifie jusqu’au succès, et une fois le succès obtenu, on itère et on améliore/complète le vaisseau. Quitte à modifier les exemplaires déjà en cours de fabrication sur le pipeline de production.

Assez ironiquement c’est exactement la démarche qu’a eue la NASA dans les années 60 avec les programmes lunaire américain, et la succession des programmes Mercury/Gemini/Apollo, avec le succès que l’on connaît : Mercury a permis de défricher le vol habité, Gemini a permis d’expérimenter les vols de longue durée, les sorties extra-véhiculaires et de développer des techniques plus complexes (telles que les rendez-vous orbitaux), et enfin Apollo a permis d’envoyer des humains sur la Lune et de les ramener sains et saufs …

On remarquera d’ailleurs que Blue Origin – la société de Jeff Bezos – a le même modèle de fonctionnement et la même démarche, simplement avec des objectifs et un calendrier différents.

On notera aussi que les programmes SpaceX ont eux aussi pris du retard, ils ont aussi coûté plus cher que prévu, mais juste … “moins que les autres”.

Encore un parallèle avec les projets IT ? 😉

Commentaires :

A lire également sur le sujet :