MBSE : l'ingénierie système basée sur les modèles, définition et mise en œuvre

SysML & modélisation · Publié le 2026-10-05

Des segments de miroir hexagonaux assemblés sur un banc d'essai, avec des techniciens en blouse — Segments de miroir du télescope James Webb préparés pour des essais cryogéniques. Photo : NASA / MSFC, domaine public.

MBSE, pour Model-Based Systems Engineering, désigne l'ingénierie système basée sur les modèles. L'idée est simple à énoncer : faire du modèle, et non plus du document, la référence de l'ingénierie. Sa mise en œuvre l'est beaucoup moins. Cet article fait le point sur la définition, ce qui change concrètement, les méthodes et normes disponibles, et la manière de démarrer.

Une définition

La définition la plus citée vient de l'INCOSE, l'association internationale d'ingénierie système, dans son document de prospective Systems Engineering Vision 2020 publié en 2007. Elle présente le MBSE comme l'application formalisée de la modélisation pour soutenir les activités d'exigences, de conception, d'analyse, de vérification et de validation du système, depuis la phase de conception préliminaire et tout au long du développement et des phases ultérieures du cycle de vie.

Trois mots comptent dans cette définition. Formalisée : le modèle obéit à un langage précis, avec une syntaxe et une sémantique, et pas à des conventions de dessin. Soutenir : le modèle n'est pas une fin en soi, il sert des activités d'ingénierie. Tout au long du cycle de vie : le modèle n'est pas un livrable de la phase de conception que l'on archive ensuite, il vit avec le système.

Du document au modèle : ce qui change

Dans une ingénierie fondée sur les documents, l'information est dispersée dans des spécifications, des dossiers de conception, des documents de contrôle d'interfaces et des plans de vérification. Chaque document est cohérent en lui-même ; c'est leur ensemble qui pose problème. Une interface modifiée dans un document doit être reportée à la main dans les autres, et rien ne garantit que ce sera fait.

Dans une démarche MBSE, ces informations sont stockées une seule fois, dans un modèle, et les documents deviennent des vues générées à partir de ce modèle. Les bénéfices attendus en découlent :

Cohérence : un élément modifié l'est partout où il apparaît.
Analyse d'impact : les relations explicites entre exigences, fonctions, composants et essais permettent de savoir ce qu'affecte un changement.
Détection précoce des erreurs : des règles de cohérence peuvent être vérifiées automatiquement (une interface sans définition, une exigence sans élément qui la satisfait).
Communication : des vues adaptées à chaque public, du client à l'équipe logicielle.
Réutilisation : des éléments de modèle peuvent être repris d'un projet à l'autre, avec leurs exigences et leurs justifications.

Ces bénéfices ne sont pas automatiques. Ils dépendent de la qualité du modèle, de la discipline de l'équipe et de l'intégration de l'outil dans les processus existants.

Le langage : SysML, mais pas seulement

SysML est le langage de référence du MBSE, publié par l'Object Management Group et repris par l'ISO pour sa version 1 sous la référence ISO/IEC 19514:2017. Il est présenté dans notre article SysML, expliqué simplement, et ses neuf diagrammes historiques dans notre guide des diagrammes.

D'autres langages coexistent : certaines méthodes ont leur propre langage, proche de SysML mais adapté à leurs points de vue ; les modèles de simulation physique (par exemple ceux écrits en Modelica) ou les modèles de sûreté de fonctionnement complètent le modèle d'architecture. Le MBSE n'impose pas un langage unique : il impose que les modèles soient formels et reliés entre eux.

Les méthodes

Un langage ne dit pas comment travailler. Les méthodes MBSE fixent les étapes, les points de vue et l'ordre dans lequel le modèle se construit. Parmi les plus documentées :

Arcadia: Développée par Thales entre 2005 et 2010, cette méthode structure l'ingénierie en perspectives successives : analyse du besoin opérationnel, analyse du besoin système, architecture logique, architecture physique, puis contrats de développement des composants. Elle a été enregistrée par l'AFNOR sous la référence XP Z67-140 en 2018. Elle est outillée par Eclipse Capella, présenté dans notre article dédié.
OOSEM: L'Object-Oriented Systems Engineering Method, issue de travaux industriels puis diffusée par un groupe de travail de l'INCOSE, s'appuie directement sur SysML et propose une démarche allant de l'analyse des besoins des parties prenantes à l'architecture.
Les démarches internes: De nombreux industriels ont formalisé leur propre démarche, souvent inspirée des précédentes et adaptée à leurs produits, à leur organisation et à leurs exigences réglementaires.

Le choix d'une méthode compte davantage que celui de l'outil : c'est elle qui détermine quelles vues produire et quand une architecture peut être considérée comme suffisamment définie. Le passage entre architectures fonctionnelle, logique et physique, commun à la plupart des méthodes, en est un bon exemple.

Les normes de référence

Plusieurs normes internationales encadrent la démarche. L'ISO/IEC/IEEE 15288:2023 décrit les processus du cycle de vie d'un système, indépendamment de toute technique de modélisation. L'ISO/IEC/IEEE 42010 définit ce qu'est une description d'architecture, avec ses points de vue et ses vues. L'ISO/IEC/IEEE 24641:2023, plus récente, porte spécifiquement sur les méthodes et les outils de l'ingénierie des systèmes et du logiciel basée sur les modèles : elle propose un modèle de référence des processus MBSSE et décrit les capacités attendues des outils. Le catalogue de l'ISO présente le domaine d'application de chacune.

Introduire le MBSE dans une équipe : les étapes

Définir l'objectif. Que doit apporter le modèle à ce projet ? Une spécification d'interfaces toujours à jour, une analyse de couverture des exigences, la génération de documents contractuels ? Un objectif précis évite de modéliser pour modéliser.
Choisir un projet pilote de taille raisonnable, avec une équipe volontaire et un sponsor qui accepte un démarrage plus lent.
Fixer la méthode et les conventions : points de vue retenus, niveau de détail, règles de nommage, organisation du modèle en paquetages.
Choisir l'outil en fonction de la méthode, de l'intégration avec les outils existants (gestion des exigences, gestion de configuration, simulation) et des capacités d'échange.
Former les modélisateurs, mais aussi les lecteurs : chefs de projet, spécialistes, clients. Un modèle que personne ne sait lire ne sert à rien.
Mesurer : temps passé, défauts détectés plus tôt, effort de mise à jour des documents. Ces données servent à convaincre pour la suite.

Les écueils classiques

Les retours d'expérience publiés convergent sur quelques difficultés : un modèle trop détaillé trop tôt, que personne n'a le temps de maintenir ; un modèle parallèle aux documents, qui double le travail au lieu de le remplacer ; une dépendance à quelques experts, qui rend le modèle inexploitable quand ils changent de poste ; une sous-estimation de l'effort de formation. La réponse est presque toujours organisationnelle avant d'être technique.

Et la suite ?

L'adoption de SysML v2 en 2025, avec sa notation textuelle et son API normalisée, devrait faciliter l'intégration du modèle dans les chaînes d'outils : gestion de versions, intégration continue, liens avec la simulation et les essais. Le MBSE tend ainsi à rejoindre des pratiques familières du génie logiciel, sans perdre ce qui fait sa spécificité : une vue d'ensemble du système, partagée par tous ceux qui le conçoivent.

Sources

INCOSE, Systems Engineering Vision 2020, 2007 (définition du MBSE).
ISO/IEC/IEEE 24641:2023, Ingénierie des systèmes et du logiciel — Méthodes et outils pour l'ingénierie des systèmes et du logiciel basée sur les modèles.
ISO/IEC/IEEE 15288:2023, Processus du cycle de vie du système ; ISO/IEC/IEEE 42010, Description de l'architecture.
Eclipse Capella, présentation de la méthode Arcadia ; AFNOR, XP Z67-140 (2018).
Object Management Group, communiqué du 21 juillet 2025 sur SysML v2.