Le rythme du NewSpace, la preuve du spatial : raccourcir un programme de lanceur ou de petit satellite sans sauter la vérification

Les entreprises du NewSpace se battent sur le calendrier. Un opérateur de petits satellites qui atteint l'orbite un an plus tôt gagne des clients ; un lanceur qui vole plus tôt remplit son carnet de missions. Dans le même temps, ni la physique ni la supervision ne sont devenues plus tolérantes. Les autorités de lancement, les assureurs et les clients attendent toujours la preuve que le matériel respecte ses exigences.

La réponse habituelle consiste à adapter les normes. Les normes ECSS sont conçues pour être adaptées à chaque projet, et les programmes NewSpace utilisent cette liberté. Mais l'adaptation décide de la quantité de vérification à mener. Elle ne rend pas la vérification restante plus rapide. Cet article regarde où part réellement le temps dans un programme de lanceur ou de petit satellite, et comment le regagner sans retirer de preuve.

Où part le temps

Quand les équipes d'ingénierie font le bilan d'un programme, le calendrier est rarement parti dans le travail de conception lui-même. Il est parti dans trois formes d'attente.

Attendre l'information. Un ingénieur a besoin de la masse actuelle d'un ensemble, de la dernière révision d'une interface ou de l'état d'un essai. La réponse existe, mais dans le tableur ou la boîte mail de quelqu'un d'autre.

Attendre la cohérence. Avant une revue, des documents qui ont divergé doivent être réconciliés : les exigences, les documents de contrôle d'interface, la nomenclature, la matrice de vérification. C'est une reprise d'un travail déjà fait.

Attendre les découvertes tardives. Une modification faite des mois plus tôt touche une interface ou un essai que personne n'a revérifié. Le coût de cette découverte grandit chaque mois où elle reste cachée.

Aucune de ces attentes n'est une étape de vérification. Ce sont les trous entre les étapes, et c'est là qu'un programme peut regagner des mois.

Les interfaces, là où les programmes dérapent

Un lanceur ou un satellite est un ensemble de sous-systèmes construits par différentes équipes et différents fournisseurs, tenus ensemble par des interfaces : mécaniques, électriques, thermiques, de données. L'ECSS-E-ST-10-24C, la norme ECSS de gestion des interfaces, décrit comment les interfaces doivent être identifiées, spécifiées dans des documents d'exigences et de contrôle d'interface, et maîtrisées au fil des modifications.

Dans beaucoup de programmes, les documents de contrôle d'interface sont des fichiers échangés entre équipes. Quand un côté change un connecteur, un motif de fixation ou un budget de puissance, l'autre côté l'apprend à la publication suivante du document, ou à l'intégration.

Quand les interfaces sont des éléments d'un modèle partagé, avec les exigences de chaque côté liées à elles, une modification d'interface montre immédiatement les sous-systèmes, exigences et essais qu'elle touche des deux côtés. La découverte passe de l'intégration au jour de la modification. C'est la plus grande source de temps regagné dans la plupart des programmes matériels.

Le périmètre des fournisseurs, sans échange de fichiers

Les programmes NewSpace achètent une grande part de leur matériel. Chaque échange avec un fournisseur par mail et tableur ajoute un délai et un risque d'écart. Dans Koddex, chaque fournisseur travaille dans son propre périmètre du modèle partagé : il voit les interfaces et exigences de son équipement, met à jour ses propres données, et le maître d'œuvre voit le résultat sans ressaisie. Les droits d'accès sont définis par partenaire, et chaque modification est enregistrée avec son auteur.

Garder la vérification continue

La vérification est souvent traitée comme une phase qui commence quand la conception est presque finie. Les programmes qui avancent vite la traitent comme une activité continue :

• —Chaque exigence reçoit sa méthode de vérification au moment où elle est écrite.
• —Chaque essai et chaque analyse sont liés aux exigences qu'ils vérifient.
• —L'état de la vérification est une vue à jour du modèle, pas un document préparé pour chaque revue.

Quand la vérification est continue, les revues deviennent des points de contrôle plutôt que des jalons qui arrêtent le travail pendant des semaines. Le cycle en V est toujours là, avec sa branche de définition et sa branche de preuve ; il tourne simplement en boucles plus courtes.

Ce que les agents IA retirent à l'équipe

Les attentes décrites plus haut sont en grande partie faites de travail répétitif : recouper, mettre à jour, lister, réconcilier. C'est ce travail que prennent les agents Koddex, comme des coéquipiers plutôt que comme des outils. Quelques tâches typiques :

• —« Un fournisseur a modifié l'interface de fixation du senseur stellaire. Lister chaque exigence et chaque essai touchés et rédiger la demande de modification. »
• —« Avant le dossier de CDR, vérifier que chaque exigence du sous-système propulsion a une méthode de vérification et une activité liée. »
• —« Comparer le budget de masse de la baseline actuelle avec la précédente et expliquer l'écart. »

L'ingénieur assigne la tâche, l'agent travaille sur une branche, commente ce qu'il a trouvé et prépare la mise à jour, et l'ingénieur la relit et la fusionne, comme une équipe de développement relit une pull request. Les agents agissent dans les droits de leur compte, et chaque action est enregistrée. Les décisions d'ingénierie restent aux ingénieurs.

À quoi ressemble le gain

Sur des déploiements accompagnés, les équipes qui travaillent ainsi ont mis leurs nouveaux produits sur le marché jusqu'à 30 % plus vite, et passé jusqu'à deux fois moins de temps sur les tâches d'ingénierie répétitives. Ce sont des observations de déploiement, pas des garanties : le gain dépend de la part du temps que le programme perd aujourd'hui dans les trous entre les étapes. Pour le savoir sur votre programme, il faut mesurer un périmètre.

Par où commencer

Choisissez l'endroit où votre programme perd le plus de temps aujourd'hui. Pour beaucoup d'équipes NewSpace, c'est une interface entre deux sous-systèmes, ou la matrice de vérification d'un sous-système avant une revue.

• —Modéliser cette interface ou ce sous-système dans Koddex, avec ses exigences et sa vérification.
• —Connecter le fournisseur ou l'autre équipe au même périmètre.
• —Y faire passer une vraie modification et mesurer le temps qu'il a fallu pour en établir l'impact.

Pour aller plus loin : Koddex pour les programmes spatiaux, la gestion des exigences, ou l'analyse d'impact sur des données partagées.