SysML & modélisation

Le diagramme de cas d'utilisation SysML : acteurs, sujet, include et extend

SysML & modélisation · Par la rédaction de Vue Système · Publié le 2026-11-11

Avant de décrire comment un système fonctionne, il faut savoir à quoi il sert, et pour qui. Le diagramme de cas d'utilisation répond à cette question de la façon la plus simple qui soit : des personnages, un cadre et quelques ellipses. C'est souvent le premier diagramme que l'on montre à un client ou à un chef de projet, et l'un des plus mal employés. Voici ce qu'il exprime vraiment, ses quelques relations, et la manière de s'en servir sans en faire un organigramme de fonctions.

Ce que montre un diagramme de cas d'utilisation

Le diagramme de cas d'utilisation (abrégé uc) fait partie des quatre diagrammes de comportement de SysML v1, avec les activités, les machines à états et les séquences ; notre panorama des neuf diagrammes de SysML les situe les uns par rapport aux autres. Il est repris d'UML sans modification de fond. La notion de cas d'utilisation elle-même remonte aux travaux d'Ivar Jacobson à la fin des années 1980, bien avant UML.

Il décrit le système vu de l'extérieur, comme une boîte noire. On n'y trouve ni composants, ni flux, ni chronologie : seulement les services que le système rend, et les entités extérieures qui en bénéficient ou y participent. C'est un diagramme de périmètre autant que de comportement : en traçant le cadre, on décide ce qui relève du système à développer et ce qui reste à l'extérieur.

Les quatre éléments de base

• Le sujet : le système étudié, représenté par un grand rectangle qui porte son nom. Il délimite le périmètre ; on l'appelle souvent, par abus de langage, la « frontière du système ».
• Les acteurs : les rôles joués par des entités extérieures au sujet qui interagissent avec lui. Un acteur se dessine en bonhomme, ou en rectangle marqué «actor». Ce n'est pas forcément une personne : un autre système, un réseau électrique ou un satellite peuvent être des acteurs.
• Les cas d'utilisation : des ellipses placées dans le sujet, chacune nommée par un verbe et un complément, « Acheter un billet », « Recharger le véhicule ». Un cas d'utilisation est un service complet, qui produit un résultat observable et utile pour au moins un acteur.
• Les associations : de simples traits entre un acteur et les cas d'utilisation auxquels il participe.

Un acteur est un rôle, pas une personne ni un poste. Le même agent de maintenance peut jouer le rôle de « Technicien » un jour et de « Voyageur » le lendemain ; à l'inverse, plusieurs équipements différents peuvent jouer le même rôle de « Système de supervision ». Distinguer l'acteur principal, celui qui déclenche le cas pour obtenir quelque chose, des acteurs secondaires, sollicités en cours de route, clarifie souvent la discussion.

Include, extend et généralisation

Trois relations permettent d'organiser les cas entre eux. Elles sont la source de la plupart des malentendus.

Le sens des flèches est le premier piège. Avec «include», le cas de base pointe vers le cas inclus : « Acheter un billet » inclut « Payer », parce qu'on ne peut pas acheter sans payer. Avec «extend», c'est l'inverse : « Imprimer un reçu » étend « Acheter un billet », sous la condition que le voyageur le demande, et le cas de base reste complet sans lui. Une règle mnémotechnique : la flèche part toujours du cas qui « sait » qu'il est lié à l'autre.

La généralisation sert surtout aux acteurs. Un « Voyageur abonné » est un « Voyageur » qui a accès, en plus, au cas « Renouveler l'abonnement ». Pour les cas eux-mêmes, elle est rarement nécessaire au niveau système.

Un exemple : le distributeur de billets

Pour un distributeur de billets de train, le sujet est le distributeur. Les acteurs sont le Voyageur, le Système bancaire, qui autorise les paiements par carte, le Système de réservation, qui attribue les places, et le Technicien, qui recharge le papier et vide la caisse. Les cas d'utilisation principaux s'écrivent « Acheter un billet », « Retirer un billet réservé en ligne », « Consulter les horaires » et « Assurer la maintenance ». « Payer » est inclus dans les deux premiers ; « Imprimer un reçu » étend « Acheter un billet ».

Ce petit diagramme suffit déjà à trancher des questions de périmètre : la consultation des horaires fait-elle partie du produit, ou est-elle assurée par un autre écran de la gare ? Le système bancaire est-il un acteur extérieur ou un module à développer ?

Le diagramme ne suffit pas : écrire le cas

Le diagramme n'est que l'index. La valeur d'un cas d'utilisation tient dans sa description textuelle, que SysML ne normalise pas mais que la plupart des outils permettent d'attacher à l'élément de modèle. Une description utile comporte au minimum :

1. L'objectif de l'acteur principal, en une phrase.
2. Les préconditions : ce qui doit être vrai avant le déclenchement (le distributeur est en service).
3. Le scénario nominal, en une dizaine d'étapes au plus, alternant actions de l'acteur et réponses du système.
4. Les scénarios alternatifs et d'erreur : paiement refusé, papier épuisé, délai dépassé.
5. Les postconditions : ce qui est garanti à la fin, en cas de succès et d'échec.

Chaque scénario se modélise ensuite, si besoin, par un diagramme de séquence entre les acteurs et le système vu comme une boîte noire, comme nous le montrons dans notre article sur le diagramme de séquence SysML. Puis, en passant à la boîte blanche, les messages se répartissent entre les composants internes.

Cas d'utilisation et exigences

Un cas d'utilisation n'est pas une exigence, mais il en fait naître beaucoup. Chaque étape du scénario nominal suggère une exigence fonctionnelle (« le distributeur doit permettre de choisir une gare de destination »), chaque scénario d'erreur une exigence de robustesse, et chaque attente implicite de l'acteur une exigence de performance (« le billet doit être délivré dans un délai donné après la validation du paiement », délai à chiffrer avec le client). En SysML v1, ces exigences sont reliées au cas d'utilisation qu'elles servent par une relation de raffinement («refine») ou de traçabilité («trace»). Les règles de rédaction sont détaillées dans notre article pour écrire une bonne exigence.

Le lien vaut dans les deux sens : un cas qu'aucune exigence ne raffine signale un oubli ; une exigence rattachée à aucun cas, une fonction que personne n'a demandée.

Et en SysML v2 ?

SysML v2 fait du cas d'utilisation un élément de modèle à part entière, avec une syntaxe textuelle. On y déclare une définition de cas d'utilisation, son sujet, ses acteurs et son objectif, ce dernier étant lui-même une exigence. L'inclusion s'écrit directement dans le corps du cas :

use case def AcheterBillet {
    subject distributeur : Distributeur;
    actor voyageur : Voyageur;
    objective {
        doc /* Le voyageur obtient un titre de transport valide. */
    }
    include use case payer : Payer;
}

La différence avec la version 1 est de fond : un cas d'utilisation v2 est une sorte de cas, au même titre qu'un cas de vérification ou d'analyse, et ses étapes peuvent être décrites par des actions du même langage. Le lien entre le service attendu, le comportement qui le réalise et l'essai qui le vérifie devient explicite. Les autres évolutions de la version 2 sont présentées dans notre article SysML v2 : ce qui change.

Cinq erreurs à éviter

1. Décomposer en fonctions. Un diagramme où « Acheter un billet » se décompose en « Saisir la destination », « Choisir la date » et « Valider » à grands coups d'«include» est une décomposition fonctionnelle déguisée. Ces étapes appartiennent à la description du cas, pas au diagramme.
2. Abuser d'extend. La relation a une sémantique précise, avec condition et point d'extension. Dans le doute, un scénario alternatif dans la description textuelle est plus clair.
3. Mettre des composants internes en acteurs. Un acteur est extérieur au sujet ; si le « module de paiement » fait partie du produit, il n'a rien à faire en bonhomme.
4. Oublier les acteurs non humains et les cas de maintenance. Installation, mise à jour, maintenance et mise au rebut sont des cas d'utilisation à part entière, souvent révélateurs d'exigences coûteuses.
5. Dessiner sans écrire. Sans description textuelle, un diagramme de cas d'utilisation se résume à une liste de titres : il ne permet ni de valider le besoin ni de préparer les essais.

À lire ensuite

Plus dans SysML & modélisation

SysML & modélisation

Le diagramme de séquence SysML

Lignes de vie, messages, fragments alt, loop et par, contraintes de temps : décrire un scénario d'échanges, en SysML v1 comme en v2.

Exigences & architecture

Écrire une bonne exigence

Les qualités attendues, des gabarits de phrase, des exemples réécrits et les pièges à éviter.

SysML & modélisation

Les neuf diagrammes de SysML

Exigences, blocs, activités, états, séquences… à quoi sert chaque diagramme, et par lesquels commencer.