SysML & modélisation

Les neuf diagrammes de SysML v1, un par un

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

SysML v1 propose neuf types de diagrammes. C'est souvent par eux qu'on découvre le langage, et c'est aussi par eux qu'on s'y perd : faut-il tous les utiliser ? Dans quel ordre ? Ce guide les présente un par un, avec leur abréviation usuelle, ce qu'ils montrent, et les erreurs les plus fréquentes.

Une taxonomie en trois familles

La spécification SysML v1 classe les diagrammes en trois familles. Les diagrammes de structure décrivent de quoi le système est fait. Les diagrammes de comportement décrivent ce qu'il fait. Le diagramme d'exigences, à part, décrit ce qu'on attend de lui. Parmi ces neuf types, deux sont propres à SysML (le diagramme d'exigences et le diagramme paramétrique), d'autres sont repris d'UML avec des modifications (activité, définition de blocs, blocs internes), et les derniers sont repris d'UML sans changement majeur (séquence, machine à états, cas d'utilisation, paquetages).

1. Le diagramme d'exigences (req)

Il montre des exigences sous forme de boîtes, avec leur identifiant et leur texte, et surtout leurs relations : une exigence en contient d'autres, en dérive d'une exigence de niveau supérieur, est satisfaite par un bloc, est vérifiée par un cas de test, est raffinée par un cas d'utilisation. Dans la pratique, on ne dessine pas des centaines d'exigences dans des diagrammes : elles vivent dans des tableaux ou des matrices, et le diagramme sert à illustrer un point précis de la traçabilité.

Erreur fréquente : utiliser le diagramme comme seul support des exigences. Il devient vite illisible ; les vues tabulaires sont plus adaptées au volume.

2. Le diagramme de cas d'utilisation (uc)

Il délimite le système et montre les acteurs extérieurs (utilisateurs, opérateurs, autres systèmes) et les services qu'ils en attendent. C'est souvent la première vue d'un modèle, utile pour fixer la frontière du système et partager le périmètre avec le client.

Erreur fréquente : y décrire des fonctions internes. Un cas d'utilisation est un service rendu à un acteur extérieur, pas une étape de traitement.

3. Le diagramme d'activité (act)

Il décrit un comportement comme un enchaînement d'actions, avec des flux de contrôle (ce qui se passe ensuite) et des flux d'objets (ce qui circule entre les actions). SysML l'a enrichi par rapport à UML, notamment pour représenter des flux continus, comme un débit ou un signal physique. Les partitions, ou « couloirs », permettent d'indiquer quel élément de structure réalise chaque action : c'est une forme visuelle d'allocation.

Erreur fréquente : dessiner des organigrammes de programme très détaillés. Le diagramme d'activité système sert à comprendre les fonctions et leurs échanges, pas à spécifier un algorithme.

4. Le diagramme de séquence (sd)

Il montre des échanges de messages entre éléments, ordonnés dans le temps de haut en bas. Il est très efficace pour décrire un scénario précis : la séquence de démarrage d'un équipement, le traitement d'une panne, un dialogue entre un sol et un satellite. Il est en revanche mal adapté pour décrire tous les cas possibles à la fois.

5. La machine à états (stm)

Elle décrit les modes d'un système ou d'un composant (arrêt, initialisation, opérationnel, mode dégradé, maintenance…) et les événements qui provoquent les transitions entre eux. C'est l'un des diagrammes les plus utiles pour les systèmes embarqués et pour la sûreté de fonctionnement, car les situations dangereuses naissent souvent de transitions mal maîtrisées.

6. Le diagramme de définition de blocs (bdd)

C'est le diagramme central de la structure. Il définit les types d'éléments (blocs), leurs propriétés, leurs opérations, leurs ports, et les relations entre types : composition (un vélo se compose d'un cadre et de deux roues), généralisation (une batterie lithium est une sorte de batterie), association. Il dit « ce qui existe », sans dire comment les éléments sont câblés.

7. Le diagramme de blocs internes (ibd)

Il montre l'intérieur d'un bloc : ses parties, leurs ports et les connecteurs qui les relient, avec les flux qui y circulent (énergie, données, matière, efforts). C'est la vue des interfaces par excellence. Le couple bdd et ibd est détaillé dans notre article blocs, ports et flux.

Erreur fréquente : confondre bdd et ibd. Le premier décrit des types et leur décomposition, le second décrit des instances en contexte et leurs connexions.

8. Le diagramme paramétrique (par)

Il relie des propriétés de blocs (masse, puissance, vitesse) à des contraintes, c'est-à-dire des équations ou des inégalités. On peut ainsi exprimer qu'une masse totale est la somme des masses des parties, ou qu'une autonomie dépend de la capacité de la batterie et de la consommation. Ce diagramme prépare les études d'ingénierie et le lien avec la simulation ; c'est aussi l'un des moins utilisés, car il demande un modèle de structure déjà mûr.

9. Le diagramme de paquetages (pkg)

Il montre l'organisation du modèle lui-même : ses paquetages, leurs dépendances, les bibliothèques importées. Il ne décrit pas le système mais la manière de ranger sa description. Dans un modèle partagé par plusieurs équipes, c'est un outil de gouvernance indispensable.

Par où commencer ?

Il n'est ni nécessaire ni souhaitable d'utiliser les neuf diagrammes dans chaque projet. La plupart des démarches commencent par un petit noyau :

1. un cas d'utilisation ou un diagramme de contexte pour fixer la frontière du système ;
2. un bdd pour la décomposition de premier niveau ;
3. un ibd pour les interfaces entre sous-systèmes ;
4. quelques exigences clés reliées aux blocs qui les satisfont ;
5. un diagramme d'activité ou de séquence pour les scénarios principaux.

Les machines à états, les diagrammes paramétriques et les diagrammes de paquetages viennent ensuite, quand le besoin apparaît. Ce choix dépend aussi de la méthode adoptée, comme l'explique notre article sur la démarche MBSE.

Et avec SysML v2 ?

SysML v2 abandonne la liste fermée de neuf diagrammes au profit d'un mécanisme plus général de vues, définies à partir de points de vue, et d'une notation textuelle complète. Les grandes représentations familières (décomposition, interconnexion, états, actions, séquences, exigences) restent disponibles. Ce qui change, c'est que le modèle n'est plus pensé à partir des diagrammes, mais l'inverse. Voir notre article sur SysML v2.

À 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.

SysML & modélisation

Le MBSE, définition et mise en œuvre

Du document au modèle : définition, méthodes, normes de référence et étapes pour démarrer dans une équipe.