SysML v2 vs SysML v1.6 : Rupture Technologique, Migration et Enjeux pour l'Ingénierie Système Moderne

Introduction : Pourquoi SysML devait se réinventer

Depuis son adoption initiale par l'Object Management Group (OMG) en 2007, SysML s'est imposé comme le langage de référence du Model-Based Systems Engineering (MBSE). Conçu pour modéliser des systèmes complexes, qu'ils intègrent du matériel, du logiciel, des processus ou du personnel, il a accompagné pendant près de deux décennies la montée en puissance de l'ingénierie système numérique dans l'aéronautique, l'automobile, la défense et l'industrie spatiale.

Mais à mesure que les systèmes sont devenus plus complexes, interconnectés et soumis à des exigences de traçabilité toujours plus strictes, les limites structurelles de SysML v1.6 se sont révélées criantes. SysML v2 vise à corriger les nombreuses limitations de SysML v1 qui freinent l'adoption efficace du MBSE à grande échelle, avec le potentiel d'améliorer la qualité du développement système, les délais, les coûts et l'agilité.

Formellement adopté par l'OMG en septembre 2025, SysML v2 marque une reconception fondamentale du langage, visant à adresser des limitations profondes en termes d'expressivité, de précision et d'interopérabilité pour les défis d'ingénierie modernes.

Cet article examine en détail les différences entre SysML v1.6 et SysML v2, les chemins de migration disponibles, l'écosystème, l'outillage, les synergies avec l'IA et les jumeaux numériques, ainsi que les limites persistantes de la nouvelle version.

1. Les limites structurelles de SysML v1.6

1.1 Une dépendance à UML, héritage encombrant

La limitation la plus fondamentale de SysML v1.6 est sans doute son architecture : SysML 1.6 est fondamentalement une extension de profil UML 2, héritant de son métamodèle orienté logiciel, qui utilise des stéréotypes pour adapter les éléments UML, comme les classes, en blocs SysML à des fins d'ingénierie système.

Cette dépendance à UML, conçu à l'origine pour la modélisation logicielle, a engendré des frictions permanentes. La correspondance partielle de SysML v1 avec UML a créé des frictions avec les outils d'ingénierie non alignés avec la sémantique UML. En pratique, les ingénieurs système travaillant sur des systèmes physiques complexes devaient constamment composer avec un langage conçu pour un autre paradigme.

Le recours aux stéréotypes, mécanisme d'extension d'UML, pour exprimer des concepts d'ingénierie système natifs a conduit à une prolifération de constructions ad hoc, souvent incompatibles d'un outil à l'autre. Cette approche, bien qu'efficace pour l'adoption initiale, a conduit à des incohérences et des limitations dans la gestion des systèmes non logiciels, les sémantiques UML sous-jacentes n'étant pas toujours parfaitement alignées avec les besoins de l'ingénierie système.

1.2 Une sémantique floue, source d'ambiguïtés

SysML v1.6 présente des sémantiques vaguement définies, où des éléments comme les définitions et les usages sont appliqués de manière incohérente, nécessitant souvent une interprétation manuelle ou une documentation externe pour résoudre les ambiguïtés dans des modèles complexes. Ces ambiguïtés débouchent sur des malentendus entre équipes, une vérification difficile et une automatisation limitée.

La gestion des blocs, des ports et des flux d'items illustre parfaitement ces difficultés : en SysML v1, les flux d'items sont définis séparément du connecteur, on crée d'abord un connecteur entre deux blocs, puis on applique un flux d'items pour spécifier ce qui circule à travers ce connecteur. Ce découplage rend la lecture et la maintenance des modèles inutilement complexe.

1.3 Une gestion des variants insuffisante

La gestion de la variabilité, cruciale pour les lignes de produits (Product Line Engineering), représente l'une des faiblesses les plus significatives de SysML v1.6. Le langage ne dispose d'aucun mécanisme natif pour exprimer des variants de configuration, forçant les équipes à recourir à des profils personnalisés ou à des extensions propriétaires.

Les limitations de réutilisation et de modularité de SysML v1.6 conduisent à des anti-patterns de copier-coller et à des profils lourds à maintenir. Dans le contexte de systèmes embarqués modernes, où un même système peut exister en dizaines de variantes, cette lacune constitue un obstacle majeur à la scalabilité du MBSE.

1.4 Des modèles difficiles à versionner et à intégrer

La friction liée au contrôle de version est réelle : les diagrammes binaires se comparent difficilement (diff), rendant la revue de code aléatoire. L'absence de notation textuelle standardisée prive les équipes d'ingénierie des pratiques DevOps modernes, branches, pull requests, revues automatisées, qui sont pourtant monnaie courante dans le développement logiciel.

L'intégration de composants versionnés en SysML v1.6 est limitée, confinant souvent les modèles à des environnements isolés sans méthodes d'accès standardisées, ce qui freine la collaboration inter-domaines.

2. SysML v2 : une refonte fondamentale du langage

2.1 L'émancipation d'UML : KerML comme nouveau socle

La rupture architecturale la plus importante de SysML v2 est son abandon complet d'UML comme fondation. Le métamodèle de SysML v2 étend le Kernel Modeling Language (KerML). L'ancien SysML v1 utilisait une fondation différente, le métamodèle UML, créé principalement pour la modélisation logicielle.

KerML est ancré dans une sémantique formelle conçue spécifiquement pour le MBSE. Cela garantit que les modèles sont sémantiquement précis et cohérents entre les outils, réduisant les ambiguïtés qui émergeaient fréquemment en v1. KerML repose sur la logique de premier ordre, ce qui ouvre la voie à des analyses formelles et à une vérification automatique des modèles.

2.2 Notation textuelle et graphique synchronisées

Alors que SysML v1 n'autorisait qu'une notation graphique standardisée, SysML v2 introduit une notation textuelle en plus de la notation graphique. Cette approche offre une toute nouvelle façon de créer ou d'éditer des modèles, y compris de manière automatisée.

Cette dualité représente un changement de paradigme : les modèles deviennent des artefacts textuels versionnables, analysables par des scripts, intégrables dans des pipelines CI/CD. La notation textuelle permet un contrôle de version, une fusion et une comparaison plus efficaces, tout en permettant aux ingénieurs de définir des modèles avec plus de précision textuelle.

2.3 La distinction Définition / Usage : clarté et réutilisabilité

L'un des apports conceptuels les plus significatifs de SysML v2 est la séparation formelle entre définition et usage. SysML v2 introduit une séparation claire entre les définitions (qui décrivent le type d'un composant) et les usages (qui représentent comment les instances de ce type apparaissent au sein d'un système). Par exemple, une "roue" peut être définie comme une définition de part, tandis qu'un véhicule peut avoir quatre instances de cette part.

Cette distinction, systématiquement appliquée dans tout le langage, élimine les ambiguïtés récurrentes sur l'instanciation dans les grands modèles v1.6.

2.4 Gestion native des variants et de la variabilité

SysML v2 apporte enfin une réponse structurée à la gestion de la variabilité. SysML v2 rend la généralisation et la spécialisation plus explicites en fournissant des constructions directes pour les relations d'héritage. Une définition de part "Vehicle" peut explicitement se spécialiser en "ElectricVehicle" ou "HybridVehicle" avec une syntaxe plus claire et une meilleure traçabilité.

Ce mécanisme, combiné aux bibliothèques de modèles standardisées, permet de gérer des lignes de produits complexes avec des configurations multiples, sans recourir à des copies de modèles ou à des extensions propriétaires.

2.5 Flux d'items intégrés et ports simplifiés

En SysML v2, les flux d'items font directement partie de la définition de la connexion. Cela réduit les étapes et garantit que le flux est intégral à la connexion elle-même, rendant le modèle plus intuitif.

2.6 Une API standardisée pour l'interopérabilité

SysML v2 répond au problème d'intégration outillage avec une API REST/OSLC standardisée qui permet des opérations complètes de création, lecture, mise à jour et suppression (CRUD) sur les modèles de manière programmatique. Cette API est définie dans la spécification Systems Modeling API and Services, publiée par l'OMG en 2025.

3. Plan de migration de SysML v1.6 vers SysML v2

La migration n'est pas triviale : SysML v2 ne dispose pas de rétrocompatibilité avec les modèles SysML v1.6, nécessitant des stratégies de reconstruction ou de migration. L'OMG a cependant anticipé cette problématique.

3.1 Les ressources officielles de transition

La spécification de transformation OMG SysML v2 définit les règles de transformation normatives et les mappings requis pour migrer les modèles depuis SysML v1.x vers SysML v2, en garantissant la cohérence sémantique et la traçabilité. Ce document, publié en septembre 2025, constitue la référence officielle pour toute migration.

Des orientations sont disponibles sur le MBSE Wiki, développées dans le cadre d'un projet sponsorisé par le DoD (Département de la Défense américain), intitulé "SysML v1 to SysML v2 Transition Guidance Project". Ce projet fournit une orientation initiale pour aider les organisations, projets et praticiens à effectuer la transition.

3.2 Les quatre étapes d'une migration réussie

Étape 1, Audit et cartographie du modèle existant Avant toute migration, il convient de réaliser un inventaire complet des modèles v1.6 existants : diagrammes, stéréotypes personnalisés, profils propriétaires, et dépendances inter-outils. Cette phase permet d'identifier les éléments sans équivalent direct en v2 et les zones de risque sémantique.

Étape 2, Formation et montée en compétence La guidance du DoD recommande de commencer par un plan stratégique pour la transition de l'équipe, de se familiariser avec la notation textuelle de SysML v2 et son API, puis d'acquérir de l'expérience via un modèle de pratique et un projet pilote. La formation à la notation textuelle (syntaxe KerML/SysML v2) représente une rupture significative pour des équipes habituées aux seuls diagrammes.

Étape 3, Migration pilote sur un sous-système représentatif Si vous peinez à comparer des modèles (diff/review), si la réutilisation est bloquée par la complexité des profils, si la traçabilité se dégrade sous le changement ou si vous avez besoin d'automatisation, génération de documents, exécution de vérifications, intégration de tests en CI, c'est le bon moment pour adopter v2. Commencer sur un sous-système limité en risques permet de valider l'outillage choisi et les nouvelles pratiques de modélisation.

Étape 4, Migration incrémentale et parallélisme transitoire Les organisations sont invitées à adopter une approche progressive, en maintenant temporairement les deux versions en parallèle. Il est anticipé que SysML v1 continuera à être utilisé pendant plusieurs années, le temps que l'industrie, le milieu académique et les administrations effectuent leur transition vers SysML v2.

3.3 Correspondances clés v1.6 → v2

SysML v1.6	SysML v2
Block Definition Diagram (BDD)	General View
Internal Block Diagram (IBD)	Interconnection View
Stéréotypes `«Block»`	`part def` / `item def`
Stéréotypes `«Requirement»`	`requirement def` (natif)
Profils personnalisés	Bibliothèques de modèles
FlowPort / ProxyPort	Port unifié
ItemFlow sur connecteur	Flow intégré à la connexion

4. Outils supportant SysML v2 aujourd'hui

L'écosystème outillage autour de SysML v2 est en pleine construction. L'émergence de SysML v2, finalisé par l'OMG en 2025 en tant que langage basé sur KerML avec une notation textuelle améliorée et une extensibilité pilotée par API, a stimulé le développement de plus de 23 outils compatibles en 2025.

4.1 SysON (Eclipse Foundation), open source

SysON implémente la spécification OMG SysML v2 : concepts du langage, API REST et format d'interopérabilité textuelle. Il propose des éditeurs graphiques, formulaires et tableaux utilisables depuis un navigateur web, sans installation spécifique sur le poste utilisateur.

Développé par Obeo et le CEA, hébergé par la Fondation Eclipse, SysON vise à faciliter le travail des ingénieurs système avec SysML v2 et Capella, avec un échange natif de modèles d'architecture Capella. Distribué sous licence Eclipse Public License v2, il constitue aujourd'hui la référence open source de l'écosystème.

4.2 SysIDE, extension Visual Studio Code

SysIDE est une extension pour VS Code qui apporte le support de la notation textuelle SysML v2 directement dans l'environnement de développement. SysIDE peut être utilisé comme extension Visual Studio Code, intégré à d'autres outils logiciels, ou utilisé en mode autonome (headless). Son approche DevOps-native en fait un choix pertinent pour les équipes souhaitant intégrer la modélisation système dans leurs flux de travail Git.

4.3 Siemens Systems Modeler for SysML v2

Annoncé en mai 2025, le Siemens Systems Modeler for SysML v2 (anciennement Teamcenter) positionne la solution PLM de référence de Siemens en tant que plateforme d'ingénierie système v2. En adoptant une approche basée sur les modèles avec SysML v2 et en l'alignant avec Teamcenter et ses robustes capacités PLM, les organisations se positionnent pour relever les défis d'ingénierie complexes.

4.4 Dalus

Dalus propose des workflows SysML v2 textual-first avec des fonctionnalités avancées de traçabilité, d'intégration Git-native et d'automatisation pour les flux de certification (IEC 61508, DO‑178C, ISO 26262). C'est l'une des solutions commerciales les plus avancées pour les secteurs soumis à des exigences réglementaires strictes.

4.5 Intercax Syndeia

Syndeia est la plateforme de digital thread pour l'ingénierie basée sur les modèles. Elle supporte l'API SysML v2 en production, avec une vision cloud-native et API-first pour construire des threads fédérés.

4.6 Tom Sawyer SysML v2 Viewer

Tom Sawyer propose un outil de visualisation avancée pour les modèles SysML v2, avec rendu graphique riche. Il complète les environnements de création textuelle en offrant des vues architecturales lisibles par les parties prenantes.

4.7 Outils en cours d'intégration

Plusieurs éditeurs majeurs, Sparx Systems (Enterprise Architect), MathWorks (System Composer), IBM (Rhapsody Systems Engineering) et Ansys (System Architect), ont annoncé leur support futur de SysML v2. Sparx Systems a annoncé qu'il supporterait SysML v2 à l'avenir, ce support n'est pas encore disponible à ce jour.

5. SysML v2, Intelligence Artificielle et Jumeaux Numériques

L'une des motivations majeures de la refonte de SysML est de préparer le langage à l'ère de l'ingénierie numérique, où l'IA et les jumeaux numériques jouent un rôle central.

5.1 L'API SysML v2 comme vecteur d'intégration IA

SysML v2 introduit une API standardisée permettant une intégration transparente avec d'autres outils MBSE, logiciels de simulation, et même des plateformes d'analyse pilotées par l'IA, permettant l'échange ou la transformation automatisée de modèles entre SysML et d'autres outils d'ingénierie.

L'interopérabilité programmatique via l'API REST ouvre des perspectives concrètes : génération automatique de modèles à partir de cahiers des charges en langage naturel, validation de conformité par des agents IA, optimisation de configurations de variantes par apprentissage automatique.

Des travaux de recherche récents Des travaux de recherche récents illustrent ce potentiel. Des approches ont été proposées combinant LLM (Large Language Models) et constructions SysML v2 pour assister l'alignement et l'intégration sémantiques de modèles MBSE multi-organisations. Ces approches utilisent des prompts structurés pour guider des modèles comme GPT-4o dans l'extraction, le rapprochement et la vérification d'éléments de modèles SysML v2.

5.2 SysML v2 comme fondation pour les jumeaux numériques

Les jumeaux numériques servent de représentations virtuelles des systèmes, permettant la surveillance intelligente, le contrôle en temps réel, la prise de décision et l'analyse prédictive. SysML v2 fournit les fondations sémantiques nécessaires pour générer et maintenir ces jumeaux.

Des travaux récents ont exploré la génération automatique de modèles Asset Administration Shell (AAS), standard industriel Industry 4.0 pour les jumeaux numériques, à partir de modèles SysML v2. Cette approche propose un mapping implémentable entre SysML v2 et AAS, permettant la génération automatisée de modèles AAS à partir de modèles SysML v2, en préservant les hiérarchies structurelles et les sémantiques comportementales.

L'intégration avec des environnements de simulation (OMNeT++, MATLAB/Simulink) est également documentée. L'intégration de SysML v2 avec OMNeT++ crée un flux de travail homogène qui soutient l'ensemble du cycle de vie du développement produit, améliorant les capacités de modélisation et fournissant des insights détaillés sur les performances et le comportement du produit.

5.3 DSL pour jumeaux numériques

SysML v2 ajoute des mécanismes pour la spécification intégrée de concepts spécifiques au domaine et d'extensions du langage. Cette fonctionnalité promet de faciliter la création de langages spécifiques au domaine (DSL) et d'interfaces avec des conceptions techniques existantes.

Des équipes académiques ont déjà mis en pratique ce potentiel, comme le projet DarTwin qui formalise la notation de gestion de l'évolution des jumeaux numériques directement en SysML v2, ouvrant la voie à des templates d'évolution standardisés et outillés.

6. Limitations de SysML v2 : sémiotique et sémantique

Malgré ses avancées, SysML v2 présente des limites importantes, tant sur le plan sémiotique (la manière dont les signes et représentations fonctionnent) que sémantique (la signification formelle des constructions du langage).

6.1 Complexité conceptuelle et sur-ingénierie

Les sémantiques de typage et de sous-classement peuvent se chevaucher d'une façon qui brouille les frontières conceptuelles. Les distinctions entre définition, usage, spécialisation et appartenance à une feature tendent à être académiques, subtiles et non intuitives pour les ingénieurs dans la pratique.

Cette sur-ingénierie abstraite est confirmée par des experts de référence : les mécanismes d'extension par bibliothèques de SysML v2 peuvent être excessivement lourds pour une personnalisation domaine de routine, les auteurs d'extensions doivent maîtriser les sémantiques du métamodèle, passant d'une extensibilité sous-conçue à une extensibilité sur-conçue.

6.2 Absence de sémantique exécutable unifiée

L'une des lacunes sémantiques les plus profondes de SysML v2 concerne la sémantique d'exécution. SysML v2 introduit une sémantique plus riche pour la modélisation comportementale, mais son utilité reste limitée par un manque de sémantique exécutable, une faible interopérabilité, et l'absence de support natif pour la vérification formelle et l'exploration de l'espace de conception.

SysML v2 ne propose pas de fondation sémantique d'exécution unifiée entre ses paradigmes comportementaux (Actions, États, Interactions). Bien qu'influencé par UML et fUML, il ne définit pas un seul modèle sémantique harmonisé couvrant tous les paradigmes comportementaux. Cette fragmentation engendre une faible confiance dans les résultats de simulation et une génération de code pour le moins incohérent entre outils.

6.3 La tyrannie du textuel : lisibilité et communication

Sur le plan sémiotique, la priorité accordée à la notation textuelle pose un problème de communication. Bien que des projections graphiques existent, l'emphase de la spécification et les premières implémentations sont fortement textuelles. Des exemples simples nécessitent des volumes textuels importants, sur de grands programmes, la verbosité excessive va même à l'encontre des principes fondamentaux du MBSE: utiliser des diagrammes pour faciliter la communication et la prise de décision ! "Une image vaut 1000 mots !"

Le paradoxe est réel : SysML v2 a été conçu pour améliorer la communication entre disciplines, mais sa syntaxe textuelle dense peut créer de nouvelles barrières à l'entrée pour les ingénieurs non familiers avec les langages formels.

6.4 Gestion des systèmes à logiciel prépondérant

SysML v2 simplifie les interfaces orientées matériel ancrées dans les métaphores de flux physiques (flux d'atomes, d'électrons, de photons). Cependant, il n'accentue pas également les interfaces centrées logiciel basées sur des métaphores de dépendance contractuelle,créant un déficit important pour les systèmes de systèmes à logiciel prépondérant.

6.5 Versionnement sémantique et gestion de configuration absents

SysML v2 ne dispose d'aucun versionnement sémantique natif ni de gestion de configuration. La spécification définit très bien la structure du modèle, mais laisse l'évolution temporelle sans réponse. Or dans les secteurs aéronautique et automobile, la capacité à reconstituer des configurations précises à plusieurs années d'écart est une obligation réglementaire non négociable.

6.6 Imaturité de l'écosystème et risque de transition

À l'heure actuelle, le passage de SysML v1 à v2 est à haut risque et à faible bénéfice immédiat pour les programmes critiques. Sans sémantique d'exécution unifiée pour le langage d'actions, les machines à états ou les interactions, sans validation industrielle à grande échelle avec des suites de tests de conformité, sans outillage mature supportant les futurs jumeaux numériques, et sans feuilles de route architecturales alignées entre fournisseurs, la transition à grande échelle introduit une incertitude substantielle.

Conclusion : SysML v2, un saut générationnel à apprivoiser

SysML v2 représente sans conteste la mutation la plus significative du MBSE depuis l'introduction du langage en 2007. L'abandon d'UML au profit de KerML, l'introduction d'une notation textuelle versionnnable, la formalisation de la sémantique et la standardisation de l'API constituent des avancées majeures qui repositionnent SysML comme un langage natif de l'ingénierie numérique.

Pour les organisations industrielles, la transition impose cependant une réflexion stratégique sérieuse. La migration n'est pas automatique, l'écosystème reste en construction, et les limitations sémantiques identifiées, notamment l'absence de sémantique exécutable unifiée et la complexité croissante du langage, méritent une attention particulière avant tout déploiement à grande échelle.

Les organisations les mieux positionnées seront celles qui commencent dès aujourd'hui à former leurs équipes, à expérimenter sur des projets pilotes et à contribuer à la maturation de l'écosystème open source autour de SysML v2, en particulier via des outils comme SysON, SysIDE ou Dalus.

L'ingénierie système entre dans une nouvelle ère. SysML v2 en est le langage. Reste à en maîtriser la syntaxe (textuelle ou graphique) et la sémantique.