UML : diagramme de cas d'utilisation

Le diagramme de cas d’utilisation décrit ce que les utilisateurs peuvent faire avec le système, vu de l’extérieur. C’est le plus simple des diagrammes UML et le meilleur point de départ avec les utilisateurs : il ne parle ni de classes ni de technique.

Les éléments

Élément	Symbole	Rôle
Acteur	Bonhomme (ou boîte)	Rôle joué par un utilisateur ou un système externe (pas une personne précise)
Cas d’utilisation	Ellipse	Objectif utile qu’un acteur atteint avec le système
Frontière du système	Rectangle	Délimite ce qui est dans le système
Association	Ligne	Un acteur participe à un cas d’utilisation

┌──────────────────────── Boutique en ligne ────────────────────────┐
│                                                                    │
│    (Consulter le catalogue)                                        │
│            ▲                                                       │
│  Visiteur ─┤                                                       │
│       △    └──── (Créer un compte)                                 │
│       │                                                            │
│    Client ───────── (Passer une commande) ····«include»····> (S'authentifier) │
│       │                    ·                                       │
│       │                    ·«include»·····> (Payer)                │
│       └──────────── (Suivre ses commandes)           Banque ──────┘│
│                                                                    │
│  Gestionnaire ──── (Gérer le stock)                                │
│        └────────── (Traiter une commande)                          │
└────────────────────────────────────────────────────────────────────┘

(Schéma simplifié : un outil de dessin produit une mise en page plus lisible : voir Outils et PlantUML.)

Acteurs

Règle	Exemple
Un acteur est un rôle, pas une personne	« Client », pas « Alice »
Une même personne peut tenir plusieurs rôles	Un employé peut aussi être client
Un système externe est un acteur	`Banque` (service de paiement)
Acteur principal : déclenche le cas	`Client`
Acteur secondaire : sollicité par le système	`Banque`
Généralisation entre acteurs	`Client` est un `Visiteur` qui s’est identifié

Cas d’utilisation

Un cas d’utilisation est un objectif d’un acteur, nommé par un verbe à l’infinitif + complément : « Passer une commande », « Consulter le catalogue ».

Bon cas	Mauvais cas
Passer une commande	Cliquer sur le bouton Valider (action d’interface)
Suivre l’état d’une commande	Afficher la page 3
Gérer le stock	Mettre à jour la base (détail technique)

Un cas d’utilisation produit une valeur pour l’acteur ; il se termine quand l’objectif est atteint (ou abandonné).

Relations entre cas

Relation	Sens	Notation
`«include»`	Le cas de base inclut toujours l’autre (partage de comportement)	Flèche pointillée vers le cas inclus
`«extend»`	Le cas d’extension s’ajoute sous condition	Flèche pointillée vers le cas de base
Généralisation	Cas spécialisé d’un cas général	Flèche à triangle vide

(Passer une commande) ····«include»····> (S'authentifier)
(Passer une commande) ····«include»····> (Payer)
(Appliquer un code promo) ····«extend»····> (Passer une commande)
(Payer par carte) ──▷ (Payer)      // généralisation : une façon de payer
(Payer par virement) ──▷ (Payer)

Règle pratique : include quand plusieurs cas partagent une étape ; extend pour une variante facultative ; éviter de multiplier ces relations (un schéma trop découpé devient illisible).

Description textuelle d’un cas

Le diagramme n’est qu’un index : le contenu d’un cas se décrit par un texte structuré.

Rubrique	Contenu
Nom	Passer une commande
Acteur principal	Client
Acteurs secondaires	Banque
Préconditions	Le client est authentifié ; son panier contient au moins un article
Scénario nominal	1. Le client valide son panier. 2. Le système affiche le récapitulatif. 3. Le client choisit l’adresse de livraison. 4. Le client paie. 5. Le système enregistre la commande et envoie une confirmation.
Scénarios alternatifs	3a. Le client ajoute une nouvelle adresse. 4a. Le paiement est refusé : le système propose un autre moyen.
Exceptions	Article en rupture de stock : le système signale l’indisponibilité et propose de retirer l’article
Postconditions	La commande existe avec le statut « nouvelle » ; le stock est mis à jour
Règles de gestion	Une commande contient au moins un article ; la quantité est d’au moins 1

Cette description alimente directement les règles de gestion (modèle de données : Merise : introduction) et les scénarios de test (voir Vitest : écrire des tests).

Du cas d’utilisation aux exigences

Cas	Exigences fonctionnelles	Exigences non fonctionnelles
Passer une commande	Valider un panier, choisir une adresse, payer, recevoir une confirmation	Paiement sécurisé, réponse en moins de 2 secondes
Suivre ses commandes	Lister les commandes, afficher le statut	Données personnelles protégées
Gérer le stock	Ajouter, retirer, alerter sous un seuil	Journalisation des modifications

Utiliser les cas d’utilisation

Moment	Usage
Cadrage	S’entendre avec les utilisateurs sur le périmètre
Planification	Un cas ≈ une fonctionnalité à livrer (priorité, estimation)
Conception	Déduire les classes, les tables, les écrans
Tests	Un scénario = un test d’acceptation
Documentation	Parcours utilisateur

Dans les méthodes agiles, les récits utilisateur (« En tant que client, je veux … afin de … ») jouent un rôle voisin, plus léger : un cas d’utilisation détaille ce qu’un récit annonce.

Bonnes pratiques

Commencer par les acteurs, puis leurs objectifs.
Un diagramme pour un périmètre (une dizaine de cas au plus).
Nommer les cas du point de vue de l’acteur, pas du système.
Ne pas décrire l’interface ni la technique.
Décrire d’abord le scénario nominal, puis les variantes et les erreurs.
Faire relire par les utilisateurs.

Dépannage

Symptôme	Piste
Des dizaines de cas, minuscules	Cas trop fins (actions d’interface) : regrouper par objectif
Des cas qui ne sont pas des objectifs	« Se connecter » est souvent une inclusion, pas un objectif en soi
`include` et `extend` confondus	`include` = toujours ; `extend` = parfois, sous condition
Acteurs nommés par des personnes	Utiliser des rôles
Diagramme sans description des cas	Ajouter les scénarios : le diagramme seul est insuffisant
Un acteur sans cas	Acteur inutile, ou cas oublié

Ubuntu 24.04 et 26.04 : différences à connaître

Aucune.