SysML & modélisation

SysML v2 : ce qui change par rapport à SysML v1

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

Après environ sept ans de travaux, l'Object Management Group a approuvé en 2025 la version 2.0 de SysML. Ce n'est pas une révision de plus : le langage change de fondations, gagne une notation textuelle et s'accompagne d'une interface de programmation normalisée. Pour les équipes qui ont investi dans SysML v1, la question n'est plus de savoir si la transition aura lieu, mais quand et comment.

Le calendrier : de l'appel à propositions à l'adoption

Le communiqué de l'OMG daté du 21 juillet 2025 annonce l'approbation pour adoption finale de trois spécifications : SysML 2.0, le Kernel Modeling Language (KerML) 1.0, et la spécification Systems Modeling API and Services 1.0. L'historique publié sur le site de l'OMG date la version formelle 2.0 de septembre 2025. Le communiqué indique que l'effort a duré environ sept ans et cite les nombreux membres de l'OMG qui y ont contribué.

Le dépôt public de l'implémentation pilote, maintenu par l'équipe de soumission, précise par ailleurs que les spécifications formelles ont été mises à jour en mars 2026, sur le plan éditorial, en vue de leur soumission à l'ISO. Côté ISO, une norme multipartie ISO/IEC 19514 consacrée à SysML v2 est en préparation ; la version 1 du langage reste couverte par l'ISO/IEC 19514:2017.

Une nouvelle fondation : KerML

SysML v1 était un « profil » d'UML : il réutilisait la mécanique d'UML et y ajoutait des stéréotypes. Cette construction a facilité son adoption, puisque les outils UML existants pouvaient le prendre en charge, mais elle a laissé des ambiguïtés. Certains concepts propres à l'ingénierie système s'exprimaient mal dans un cadre pensé pour le logiciel, et deux outils pouvaient interpréter différemment le même modèle.

SysML v2 rompt avec UML. Il repose sur KerML, un langage noyau dont la sémantique est définie formellement. L'OMG présente KerML comme la fondation sémantique et syntaxique de SysML v2. Concrètement, cela signifie que la signification d'un modèle est définie de manière plus précise et que les outils ont moins de latitude pour l'interpréter à leur façon : un gain important pour l'échange de modèles et pour l'analyse automatique.

Deux notations pour un même modèle

C'est le changement le plus visible. Le communiqué de l'OMG souligne que SysML v2 offre des représentations textuelles et graphiques complémentaires du modèle sous-jacent. On peut donc écrire un modèle comme on écrit du code, le relire dans un éditeur de texte, en suivre les différences avec un outil de gestion de versions, et l'afficher aussi sous forme de diagrammes.

Voici, à titre d'illustration, un petit modèle écrit en notation textuelle. Il décrit un vélo à assistance électrique composé d'un cadre, de deux roues et d'une batterie, et déclare une exigence d'autonomie :

package VeloElectrique {
    private import ScalarValues::*;

    part def Velo {
        part cadre : Cadre;
        part roues : Roue[2];
        part batterie : Batterie;
    }
    part def Cadre;
    part def Roue;
    part def Batterie {
        attribute capacite : Real;
    }
    requirement def AutonomieMinimale {
        doc /* Le vélo parcourt au moins 50 km avec une charge complète. */
    }
}

Pour un ingénieur habitué aux diagrammes de définition de blocs, la lecture est immédiate : part def joue le rôle du bloc, part celui de la propriété de partie, et la multiplicité [2] se lit comme en v1. La notation textuelle n'est pas destinée à remplacer les diagrammes, mais elle change la façon de travailler : revue de modèle ligne par ligne, fusion de branches, génération automatique de variantes.

Définitions et usages : une distinction systématique

SysML v2 généralise un principe que SysML v1 n'appliquait qu'à moitié : la séparation entre la définition d'un élément et son usage dans un contexte. On définit une fois ce qu'est une roue (part def Roue), puis on l'utilise deux fois dans le vélo (part roues : Roue[2]). Le même schéma s'applique aux ports, aux attributs, aux actions, aux états, aux exigences et aux contraintes.

Cette symétrie rend le langage plus régulier et plus facile à apprendre une fois le principe compris. Elle permet aussi de modéliser plus proprement les variantes et les configurations : un usage peut redéfinir ou spécialiser certaines caractéristiques de sa définition sans toucher à celle-ci. Les mécanismes de blocs, ports et flux sont détaillés dans notre article sur la description d'une architecture.

Une API normalisée pour les outils

La troisième spécification adoptée, Systems Modeling API and Services, définit une interface standard pour accéder à un dépôt de modèles : lire, créer et modifier des éléments, gérer des versions et des branches, interroger le modèle. L'objectif est que des outils différents (modeleur, gestionnaire d'exigences, outil de simulation, tableau de bord de projet) puissent travailler sur le même modèle sans export manuel.

C'est une réponse directe à l'une des principales critiques adressées à SysML v1 : l'échange de modèles par fichiers XMI, souvent imparfait d'un outil à l'autre. Avec SysML v2, l'interopérabilité est pensée dès la spécification, et non ajoutée après coup.

Ce qui ne change pas

Les grands concepts de l'ingénierie système restent les mêmes. On continue de modéliser des exigences, une structure, des comportements, des allocations et des contraintes. Les ingénieurs qui maîtrisent SysML v1 retrouveront leurs repères : la décomposition en parties, les ports et les connexions, les machines à états, les cas d'utilisation, la relation de satisfaction d'une exigence.

Les vues graphiques restent d'ailleurs proches de celles de la version 1 sur bien des points, même si la liste figée de neuf diagrammes de SysML v1 laisse la place à un mécanisme plus général de vues et de points de vue. Notre article sur les diagrammes de SysML v1 reste donc une bonne base pour comprendre ce que l'on représente.

Préparer la transition

Pour une organisation qui utilise SysML v1, il n'y a pas d'urgence à tout migrer, mais il y a des décisions à préparer :

• Faire l'inventaire des modèles : lesquels sont vivants et devront évoluer pendant des années, lesquels sont figés et peuvent rester en v1 ?
• Nettoyer les modèles v1 : un modèle cohérent, avec des conventions respectées, se convertira beaucoup mieux qu'un modèle où chacun a modélisé à sa manière. La spécification SysML v2 comporte un document consacré à la transformation des modèles v1.
• Former par la notation textuelle : écrire quelques modèles en mode texte est souvent le moyen le plus rapide de comprendre la logique définition/usage.
• Interroger les éditeurs d'outils sur leur feuille de route : prise en charge de la notation textuelle, de l'API, de la conversion des modèles v1.
• Expérimenter avec des outils libres, qui permettent de se faire une idée sans engagement : voir notre article sur les outils libres pour SysML v2.

La transition prendra plusieurs années, comme toute évolution de langage dans des industries où les programmes durent des décennies. Mais elle ouvre une perspective intéressante : des modèles d'ingénierie système enfin aussi faciles à versionner, à relire et à échanger que du code source.

À lire ensuite

Plus dans SysML & modélisation

SysML & modélisation

SysML, expliqué simplement

Origine, versions, ce que le langage décrit et ce qu'il ne fait pas : les bases pour bien démarrer.

SysML & modélisation

Blocs, ports et flux

Blocs et parties, bdd et ibd, ports, interfaces et flux : la grammaire de la structure, avec un exemple pas à pas.

Outils libres

SysML v2 en open source

Implémentation pilote, notebooks Jupyter, API et SysON : de quoi pratiquer SysML v2 sans licence.