SVC-02 · Service
Un déploiement MBSE et une gouvernance qui survivent au pilote
Goujon Systems accompagne les organisations de l’aérospatial, du spatial et de la défense dans le déploiement du Model-Based Systems Engineering, pour que le modèle devienne la source unique de vérité du programme, et non un artefact parallèle qui s’éloigne discrètement des documents que tout le monde utilise réellement. L’intervention couvre la stratégie et le périmètre MBSE, le choix méthode-outil (Capella/ARCADIA, Cameo, SysML v1.x et v2), les conventions de modélisation, les règles de gouvernance, l’intégration de la chaîne d’outils, ainsi que la formation et l’accompagnement qui ancrent l’adoption.
La plupart des déploiements MBSE n’échouent pas sur l’outillage. Ils s’enlisent entre le pilote et le deuxième programme, parce que personne n’a écrit ce dont le modèle fait autorité, qui a le droit de le modifier, et quel livrable existant il remplace. C’est par ces trois questions que commence une mission, et y répondre vaut généralement plus cher que n’importe quel choix d’outil.
Pourquoi les déploiements MBSE s’enlisent
Le pilote se passe bien. C’est presque toujours le cas : un architecte motivé, un sous-système borné, aucun héritage. Puis la méthode rencontre le deuxième programme et s’arrête. Les causes sont assez constantes pour valoir d’être nommées.
- Le modèle double le document au lieu de le remplacer. Les ingénieurs maintiennent désormais les deux. Sous pression de planning, l’un des deux est abandonné, et ce n’est jamais celui que le client exige contractuellement.
- Aucune déclaration d’autorité. Quand le modèle et la spécification divergent, personne ne sait lequel fait foi ; on se rabat sur le document et le modèle devient décoratif.
- Les conventions laissées à chaque modélisateur. Deux architectes modélisent le même concept de trois façons différentes, et le modèle devient illisible d’une équipe à l’autre, ce qui détruit le seul bénéfice qui justifiait l’investissement.
- L’outil choisi avant la méthode. On achète des licences, puis l’organisation reconstitue à rebours une façon de travailler qui s’y adapte.
- Une formation sur les fonctionnalités, pas sur les décisions. Les participants ressortent capables de tracer un diagramme et incapables de décider lequel tracer.
- Aucun lien avec le calendrier des revues. Si aucune revue n’exige le modèle, le modèle est facultatif ; et les artefacts facultatifs meurent au premier glissement de planning.
Ce que comprend un déploiement
Séquencé pour que chaque étape rende la suivante moins coûteuse. La méthode avant l’outil, les conventions avant l’échelle, la gouvernance avant l’adoption.
- Vision & périmètre MBSE : un énoncé écrit de ce à quoi sert le modèle, des questions d’ingénierie auxquelles il doit répondre et, surtout, de celles auxquelles on n’attend pas qu’il réponde.
- Choix méthode & outil : ARCADIA/Capella, SysML avec Cameo ou une approche hybride, choisis selon vos contraintes réelles : actifs existants, exigences client, maturité des équipes et besoins d’intégration.
- Conventions & guide de style : nommage, profondeur de décomposition, jeu de diagrammes, règles de réutilisation et définition du « fini » pour un élément de modèle, afin que deux architectes produisent des modèles comparables.
- Autorité & gouvernance du modèle : quel artefact fait foi en cas de divergence, qui peut modifier quoi, comment les baselines sont figées, et comment les évolutions du modèle alimentent la gestion de configuration.
- Intégration de la chaîne d’outils : les interfaces entre outil d’exigences, modèle système, simulation et PLM, définies une fois, pour que la traçabilité soit une propriété de la chaîne et non une réconciliation manuelle mensuelle.
- Conception du pilote : un pilote sur un vrai sous-système, avec de vraies contraintes et une vraie date de revue. Les pilotes sur exemples d’école ne prédisent rien et ne prouvent rien.
- Formation & accompagnement : les décisions de modélisation d’abord, le maniement de l’outil ensuite, dispensés à l’équipe sur son propre modèle plutôt que sur un cas générique.
- Indicateurs d’adoption : un petit nombre d’indicateurs honnêtes (points de revue référencés au modèle, couverture de traçabilité, délai de réponse à une question d’impact), pour distinguer l’adoption réelle de la conformité de façade.
Les vrais défis d’un déploiement MBSE
Le choix de l’outil occupe les comités pendant des mois. Les trois sujets qui suivent décident du résultat, et ce sont eux que l’accompagnement travaille en priorité.
Comprendre ce que le MBSE est vraiment
Le MBSE ne consiste pas à dessiner des diagrammes. Un ou plusieurs modèles viennent concentrer la donnée d’ingénierie du programme (fonctions, interfaces, exigences allouées, budgets techniques) pour la connecter à d’autres usages : génération documentaire, analyses de sécurité et de fiabilité, simulation, vérification, gestion de configuration. C’est cette position de « source unique de vérité » (source of truth) qui rentabilise l’investissement : la donnée est saisie une fois, exploitée partout, et cesse de diverger d’un document à l’autre. Une organisation qui déploie l’outil sans viser cette position obtient un outil de dessin coûteux.
Former les équipes
Un déploiement tient ou casse sur la compétence des équipes, pas sur les licences. La formation utile porte d’abord sur les décisions de modélisation : quoi modéliser, à quelle profondeur, pour répondre à quelles questions ; le maniement de l’outil vient ensuite. Elle se fait sur le modèle du programme plutôt que sur un cas d’école, et elle s’inscrit dans la durée : quelques jours de cours ne créent pas une pratique, un cycle de modélisation accompagné, oui.
Un accompagnement par quelqu’un qui l’a vécu
Entre la formation théorique et la réalité d’un programme, il y a toutes les situations qu’aucun support de cours ne couvre : un modèle qui diverge de la spécification à trois semaines d’une revue, deux équipes qui modélisent le même concept de façons incompatibles, un client qui exige le livrable documentaire que le modèle était censé remplacer. L’accompagnement n’a de valeur que s’il vient de quelqu’un qui a dû gérer ces situations sur de vrais programmes. C’est le savoir-faire qu’apporte Goujon Systems : près de dix ans sur les programmes phares du spatial et de la défense européens, dont l’architecture système de l’atterrisseur lunaire Argonaut de l’ESA, et l’enseignement de l’ingénierie des systèmes spatiaux et du MBSE en Master 2 à l’Université Toulouse III.
Et le choix d’outil ?
Il compte, mais il se traite en quelques semaines une fois le périmètre et la gouvernance posés. Capella avec ARCADIA et Cameo avec SysML sont tous deux capables : ils échouent différemment et conviennent à des situations de départ différentes. L’arbitrage complet, critère par critère, est détaillé dans l’analyse « Capella ou Cameo : comment choisir l’outil MBSE de son programme ».
Côté SysML v2, l’Object Management Group a prononcé l’adoption définitive de la spécification en juillet 2025 et lancé un programme officiel de certification en juin 2026 : le langage n’est plus une cible mouvante, et la question utile n’est plus « quand sera-t-il prêt ? » mais « que nous coûte la migration ? ». Goujon Systems entretient un partenariat actif avec Sensmetry, dont les travaux portent directement sur la chaîne d’outils SysML v2, là où se trouve aujourd’hui une bonne part de la connaissance pratique, et non théorique, de la v2 en production.
Questions fréquentes
Les questions que l’on me pose avant de me contacter
Combien de temps avant qu’un déploiement MBSE produise quelque chose ?
Le mauvais jalon à planifier est la date de déploiement de l’outil. Le bon est la première revue de programme passée avec le modèle comme référence, car c’est le moment où le modèle cesse d’être facultatif. Un pilote cadré sur un vrai sous-système, et non sur un exemple d’école, peut devenir exploitable en un cycle de modélisation ; l’adoption à l’échelle de l’organisation se compte en cycles programme, pas en semaines.
Faut-il remplacer notre outil de gestion des exigences ?
En général non, et en général il ne faut pas. DOORS, Jazz ELM, Polarion et Valispace cohabitent très bien avec un modèle système, à condition que l’interface entre les deux soit définie une fois et tenue : qui possède le texte de l’exigence, qui possède l’allocation, et comment la traçabilité est synchronisée. Remplacer un outil d’exigences qui fonctionne en cours de programme est un coût élevé pour un bénéfice faible.
Faut-il passer directement à SysML v2 ?
Cela dépend de vos actifs SysML v1.x existants. SysML v2 a fait l’objet d’une adoption définitive par l’Object Management Group en juillet 2025, et l’OMG a lancé un programme officiel de certification SysML v2 en juin 2026 : le langage n’est plus une cible mouvante. Mais la v2 est un nouveau langage, avec sa notation textuelle et une API standard, pas une révision incrémentale. Reprendre un modèle existant est un travail de re-modélisation, pas une conversion de fichiers. Une équipe qui démarre a une décision bien plus simple qu’une équipe avec trois ans de modèles v1.x en production.
Capella ou Cameo : que choisir ?
Capella avec ARCADIA convient aux équipes qui se dotent d’une méthode pour la première fois, parce que la méthode est prescriptive et prend une grande partie des décisions à leur place. Cameo avec SysML convient aux organisations qui détiennent déjà des actifs SysML ou qui ont besoin d’une intégration profonde avec une chaîne d’outils plus large, au prix d’avoir à définir la méthode elles-mêmes. L’analyse « Capella ou Cameo » publiée sur ce site détaille l’arbitrage critère par critère.
Qui doit être impliqué dans notre organisation ?
Au minimum : un architecte système qui portera le modèle, un responsable des exigences, et quelqu’un ayant l’autorité de déclarer que le modèle prime sur un document. C’est ce troisième rôle qui manque le plus souvent, et son absence est le meilleur prédicteur d’un déploiement qui s’enlise.
Pouvez-vous aussi former nos équipes ?
Oui, et les deux sont difficiles à séparer utilement. Une formation qui traite les fonctionnalités de l’outil sans traiter les décisions de modélisation produit des ingénieurs qui savent manier l’outil et ne savent pas modéliser. Clément enseigne l’ingénierie des systèmes spatiaux et le MBSE en Master 2 à l’Université Toulouse III et a dispensé des formations à l’échelle d’un grand intégrateur spatial.
Services associés
Réservez un appel découverte gratuit.
Trente minutes, sans engagement, en français, anglais ou italien. Parlez-moi de votre programme et je vous dirai honnêtement si je suis la bonne personne pour vous aider.
Dernière mise à jour: