Version du 02-12-05, Mise à jour le 03-07-22

FICHE TECHNIQUE

Les cas d’utilisation1 d’UML

“A use case is a collection of possible sequences of interactions between the system

under discussion and its external actors, related to a particular goal”2
Alistair Cockburn3

Le cas d’utilisation est une des techniques utilisées pour modéliser une organisation ou un système
d’information au moyen du langage de modélisation standardisé UML4 (Unified Modeling Language). Le cas
d’utilisation tire son origine de la méthode OOSE (Object-Oriented Software Engineering) de Ivar Jacobson,
un des trois créateurs d’UML.

Un cas d’utilisation décrit ce que fait un système (le quoi ) et non comment il le fait. Généralement, il
présente la vision qu’a un utilisateur externe d’un système et il aide à communiquer cette vision des
fonctionnalités du système aux autres acteurs. Il s’agit donc principalement d’une technique d’analyse centrée
sur l’usager. L’usage des cas a cependant été étendu pour montrer aussi des interactions internes au système,
avec les sous-systèmes et aux objets. Les cas d’utilisation sont présentés à la fois sous forme de diagramme et
sous forme de description textuelle standardisée.

Le cas d’utilisation sert principalement, à la phase de planification, à capturer et clarifier à les besoins
fonctionnels et techniques, notamment en servant d’outil de communication avec le client. Il est aussi à la
base de la conception, puisqu’il permet l’identification des classes, de leurs attributs, des opérations et la
segmentation du travail en modules. Il peut aussi servir à tester le système conçu à l’aide des scénarios
prioritaires.

Comme l’ensemble de l’approche de modélisation en UML, il met l’emphase sur la modularité, en

décomposant chaque processus en séquences d’actions et la réutilisation, en permettant de réutiliser ces
séquences dans d’autres cas ou d’utiliser de nouveau les cas pour un autre système. Il fait aussi partie d’une
démarche itérative, où on revient compléter l’information au fur et à mesure du développement, et
incrémentale, chaque élément étant affiné et détaillé à chaque itération.

Le cas d’utilisation n’est pas une technique aussi formalisée que les autres méthodes d’UML. Une des façons
de construire les cas d’utilisation est de :
1. Délimiter le système à l’étude. Il peut s’agir par exemple d’un système d’information ou d’un
processus.
2. Identifier qui utilisera le système : ce seront les acteurs du cas. Un acteur n’est pas une personne
mais un rôle joué par une personne ou un système. Un acteur primaire a besoin du système pour
accomplir un de ses buts. Le système est lui-même un acteur primaire. Les acteurs primaires peuvent
être externes. Il s’agira alors généralement de personnes, de groupes ou d’autres systèmes. Les
acteurs internes sont des sous-systèmes ou des objets du système. On identifiera comme acteurs
secondaires les autres participants; ce sont généralement des personnes ou systèmes qui reçoivent
ou fournissent de l’information5, ou s’occupent de la supervision ou de l’entretien du système.

1
Use Case en anglais.
2
Traduction : « Un cas d’utilisation est une collection de séquences d’interaction possibles entre le système à l’étude et ses acteurs
externes, en relation avec un but particulier »
3
Voir http://www.usecases.org/
4
Les termes en italique et en caractère gras renvoient à une autre fiche technique.
5
Ils sont parfois définis comme un acteur dont le système a besoin pour réaliser l’objectif.

© Gilles E. St-Amant
 2

On peut aussi choisir d’élaborer les cas d’utilisation en identifiant d’abord les événements externes au
système, liés ensuite aux acteurs.
3. Pour chaque acteur, établir ses objectifs6 ou, en d’autres mots, quels sont les résultats attendus par
l’acteur en cause de ce système. Les objectifs peuvent être formulés sous forme de questions de type:
« Comment l’acteur peut-il atteindre le résultat x ? »; par exemple : « Comment le client d’un
guichet automatique peut-il retirer de l’argent ? ». L’ensemble des scénarios liés à un objectif
constituera un cas d’utilisation. Le nombre de cas peut cependant devenir important. Il faut donc se
centrer, particulièrement dans cette première itération, sur les objectifs principaux.
4. Fixer l’événement déclencheur (début) et les conclusions possibles (fin) du cas. Chaque scénario
du cas se termine quand le but est réalisé ou abandonné.
5. Résumer le cas en quelques phrases, en spécifiant l’objectif poursuivi par l’acteur principal , ce qui
déclenche le cas et ce qui y met fin et les principales actions qui s’y déroulent, de façon à bien
communiquer, tant aux utilisateurs qu’aux programmeurs, l’intention et le contenu du cas.

Cas d’utilisation : No et nom

Acteur principal : Acteur x
Acteurs secondaires : Nil
Type de cas: Primaire ou secondaire
Objectif Ex : Obtenir…
Début : Ce cas commence quand l’acteur x….
Fin Il se termine quand…
Résumé des actions Lorsque l’acteur principal a…., le système….

6. Construire le ou les diagrammes de cas d’utilisation. La représentation des cas d’utilisation est
simple. Le cas est placé dans un ovale. Chaque acteur prend la forme d’un bonhomme allumette et
chaque communication la forme d’un trait. Le système à l’étude est représenté par un rectangle.

Système à l’étude
Cas
d’utilisation
Acteur
7. Revoir les cas. Assurez-vous que chaque cas correspond bien à un objectif de l’utilisateur et non à
une simple modalité d’opération de votre système. N’oubliez pas qu’un cas représente une
fonctionnalité de haut niveau et non une opération marginale.
8. Établir la priorité des cas. On recommande généralement de développer d’abord les cas primaires
c’est-à-dire les processus majeurs, principalement ceux mettant en cause l’acteur principal « client ».
On déterminera ultérieurement les processus secondaires (ou mineurs) et les processus optionnels.
9. Valider avec le client. Les cas d’utilisation permettent un dialogue avec les clients et les usagers et
facilitent ainsi la compréhension des besoins et du système par toutes les parties prenantes. Comme
ils sont la base des développements ultérieurs, il est important qu’ils traduisent bien les opérations
voulues. De là, la nécessité de valider d’abord la pertinence des cas choisis..

6
Certains auteurs préfèrent d’abord définir les responsabilités des acteurs, puis les différents objectifs associés à chaque
responsabilité.

© Gilles E. St-Amant
 3

Une fois cette première itération complétée, il faut détailler les cas et donc développer leur description
textuelle. Pour chacun
10. Identifier les conditions de succès et d’échec (si…alors…autrement…). Chaque condition mènera à
deux ou plusieurs scénarios différents, l’ensemble constituant le cas d’utilisation. Il peut s’agir de
scénarios de succès (le but est atteint), d’échec (le but est abandonné) et, parfois, de succès partiel.
11. Développer le scénario principal. On développe d’abord le cheminement principal (main course)
c’est-à-dire la séquence d’interactions courante où tout se déroule comme prévu, sans échec. Une
séquence est un groupe d’interactions, manuelles ou automatisées, qui n’a pas d’alternatives ou
d’embranchements. Une interaction peut être un simple message. On peut donc identifier les
interactions à partir des messages. Les interactions décrivent un échange entre un acteur et un
système; généralement, ils auront donc la forme : « élément temporel » + « acteur
primaire »+ «action », suivie de «condition »+ « système » + « action ». Gardez la description à un
niveau général, sans tenir compte des particularités de l’interface (ex :.« après avoir consulté les
renseignements généraux, le client choisit une catégorie de produits », plutôt que : « après avoir
atteint l’index, le client appuie l’icône d’un produit »). Vous éviterez ainsi de faire trop hâtivement
des choix technologique et de design et garderez le texte lisible pour les non-initiés. Chaque
interaction est généralement numérotée et séparés par un bris de paragraphe. Le plus souvent, on
débute par des descriptions brèves qui seront détaillées dans des cycles ultérieurs. On ajoute donc au
tableau précédent une description qui peut prendre la forme suivante :

Version : No de la version et date de la mise à jour

Description : Étape Action
1.
2.
3.
Commentaires : Ex : sources consultées et/ou raison d’une modification
Fréquence prévue : Le nombre d’occurrences sur une période pré-déterminée
Auteur du cas : Nom du rédacteur

Une fois l’ensemble des scénarios principaux détaillés :

12. Déterminer les variations. Les variations sont le plus souvent des moyens alternatifs utilisés dans le
cadre du scénario, par exemple : un contact peut provenir d’un client actuel, passé ou d’un non-
client; un contact peut être fait par lettre, téléphone ou télécopieur.
13. Rédiger les extensions. Une extension se produit quand une interaction échoue ou, en d’autres mots,
si une condition ne se réalise pas. L’extension porte le nom de cette condition, par exemple : « Code
D’identification Erroné ».
14. Comparer les cas pour y trouver des inclusions ou fragments communs. Il s’agit d’éléments
communs à plus d’un cas qui contribuent à rendre les cas réutilisables. . Ils doivent être formulés
pour pouvoir s’imbriquer intégralement dans le cas
15. Valider, de nouveau, avec le client. Il est important que le client valide aussi les activités incluses
dans les cas. Il faut donc lui soumettre aussi les cas développés.
16. Détailler et compléter au besoin. Ne tentez toutefois pas de tout inclure dans les cas d’utilisation :
utilisez plutôt les autres modèles d’UML. Pour être utiles, les cas ne doivent pas devenir
démesurément complexes : ne détaillez que lorsque c’est clairement utile.
17. Compléter le diagramme de cas d’utilisation, en y ajoutant les extensions et les fragments
communs.

© Gilles E. St-Amant
 4

Exemple

Louis, informaticien chez Début, une jeune entreprise de formation multimédia, doit modéliser le système de
commande de formation par Internet que Début veut mettre en place. Comme certains des membres de son
équipe connaissent UML et qu’il s’agit là d’un standard reconnu, il décide de l’utiliser pour la modélisation,
en commençant par la définition des besoins au moyen de cas d’utilisation.
1. Le système à délimiter sera dans ce cas le système de commerce électronique de Début. Louis le voit
cependant comme plus large que le système informatisé et veut plutôt couvrir tout le processus qui
mène à la livraison d’une commande.
2. Parmi les acteurs à Identifier, Louis sait déjà qu’ils incluront des systèmes : les bases de données
internes de l’organisation sur ses clients et celles des banques qui traiteront le paiement des
transactions. Les autres acteurs comprendront bien entendu, comme acteurs primaires, les clients
externes. Louis se sert de certains éléments de l’analyse des parties prenantes pour identifier
d’autres utilisateurs potentiels. Pour compléter son identification des acteurs et commencer à
préciser leurs objectifs et les scénarios qui y sont liés, il rencontre les représentants des différents
services de Début touchés par le projet : Ahmed des ventes et Monique du soutien pour déterminer
les principaux scénarios liés aux clients, puis Lise des finances pour établir ceux liés au transit des
paiements, Frédéric de l’expédition pour clarifier les modes de livraison et ses propres collègues des
services techniques, pour établir les principales activités liées à la mise à jour et à l’entretien du
système. Après cette première discussion, il exclut les fournisseurs d’accès Internet de sa première
liste d’acteurs, mais y inclut, en plus des deux systèmes et des clients, la banque du client et celle de
Début, le webmestre qui concevra et mettra à jour le site, conjointement avec les concepteurs des
formations, le vendeur qui utilisera les données clients pour le solliciter, via le site ou autrement, le
commis à la livraison, qui prépare la commande et le transporteur qui la livre, de même que les
responsables du soutien aux usagers, qui répondent à leur demande.
3. Pour chaque acteur, il dresse une première liste d’objectifs. Ainsi, un client externe peut avoir pour
objectif d’obtenir de l’information, d’obtenir un produit ou d’obtenir de l’aide en relation avec le
produit. Chaque objectif peut se subdiviser en sous-objectifs. Par exemple, dans le deuxième cas, le
client voudra successivement commander, payer et recevoir le produit de formation. Louis se
demande s’il fera de cet objectif d’obtention du produit un seul cas ou plusieurs. Il décide de
développer le cas « commander » pour voir s’il sera d’un niveau trop ou pas assez détaillé.
4. Dans le cas « commander », l’événement débute lorsque le client indique qu’il veut commander et
se termine quand le client a soit complété son bon de commande, soit abandonné le processus de
commande.
5. Il résume le cas « commander » en utilisant le tableau ci-dessous et fait de même pour tous les
autres acteurs et objectifs identifiés.
Cas d’utilisation : 01- Commander un produit
Acteur principal : Client
Acteurs secondaires : Base de données client
Type de cas: Primaire
Objectif Se procurer facilement le produit voulu
Début : Ce cas commence quand le client indique au système qu’il est prêt
à commander….
Fin Il se termine quand le bon de commande est complété avec succès
ou que le client abandonne la commande
Résumé des actions Une fois le client prêt à commander, le système lui demande de
s’identifier, vérifie ou enregistre son identité, lui soumet un bon de
commande à compléter, fait le total de ses achats et lui demande de
le confirmer.

© Gilles E. St-Amant
 5

6. Il construit le diagramme de cas d’utilisation principal. Il prévoit le détailler en construisant un

diagramme plus étoffé pour chaque acteur.

Concevoir
Site

Système de commerce Concepteur

électronique Enregistrer
Solliciter
Webmestre Client
Client
Mettre à jour
Vendeur
Information
Valider
Commande
Obtenir
Information Base Données
Clients Autoriser
livraison
Commander
Préparer
Commande
Payer Commis Livreur
Confirmer
Paiement
Vérifier le
Client
crédit

Banque Transférer
Client fonds
Banque Compagnie
Avoir du
soutien

Recevoir le
produit
Transporteur
Soutien

7. Louis revoit les cas. Il constate par exemple que le transporteur est un acteur secondaire du cas
« Préparer Commande » et donc qu’un lien devrait être ajouté du cas à l’acteur.
8. Il établit la priorité des cas. Il prévoit développer dans une première phase les cas centraux à la
commande électronique, c’est-à-dire les cas commander et payer du client et les trois cas reliés de la
base de données clients. Il développerait ensuite « obtenir de l’information », les clients ayant déjà
accès à des sources alternatives de renseignements, reverrait en troisième lieu l’arrimage des
modules liés à la livraison, puisqu’ils son intimement liés à la satisfaction du client. et compléterait
le système en développant les modules de ventes et de soutien, les cas liés au paiement étant impartis
aux banques.
9. Il valide avec son client, qui est ici son patron , Paul, le directeur des services informatiques et la
directrice des ventes, Diane, qui a initié le projet. Paul croit que le diagramme devrait aussi prévoir
le lien avec la production, c’est-à-dire avec le service qui reproduit les formations, pour qu’il puisse
ajuster rapidement la production aux commandes. Par ailleurs, il souhaite que le système fournisse
aussi des données sur l’information consultée et sur les commandes abandonnées. On ajoute donc un
objectif –et donc un cas- « Recueillir Données » au webmestre. Diane s’interroge plutôt sur les
priorités : elle croit qu’il faut développer le cas «Obtenir Information » en priorité : une information
complète et bien structurée contribuerait selon elle aux ventes, même si le module de commande
électronique n’est pas encore installé.

À la suite de cette réunion, Louis et son équipe entreprennent de développer la description textuelle, en
débutant par le cas « Commander ». Ainsi :

© Gilles E. St-Amant
 6

10. Il identifie les conditions de succès du cas, c’est-à-dire si : le client s’identifie correctement, si la
vérification de son identité réussit, s’il confirme la commande, etc. Il développera la liste des
conditions et leurs alternatives dans les étapes suivantes.
11. Il développe le scénario principal en utilisant le format suivant :

Version : Cas 01, version 1, 15 décembre 2002

Description Étape Action
: 1. Le client indique au système qu’il désire commander
2. Le système lui demande les renseignements nécessaires à
son identification
3. Si le client connaît ses identificateurs, il les transmets au
système
4. Le système vérifie la validité de l’information entrée
5. Si la vérification est réussie, le système affiche les
renseignements détenus sur le client
6. Le système demande de confirmer l’exactitude des
renseignements
7. Si le client confirme l’exactitude des renseignements, le
système vérifie si le client a déjà placé des marchandises
dans son panier (voir cas 02)
8. Si le client a des marchandises dans son panier, le système
les affiche
9. Le système affiche la liste des autres marchandises
disponibles
10. Le client indique les quantités désirées de chaque produit
11. Le système demande de confirmer l’exactitude des
quantités entrées
12. Si le client confirme l’exactitude des quantités, le système
affiche les quantités commandées et le montant de la
commande (le bon de commande)
13. Le système demande au client s’il veut procéder au
paiement
14. Si le client accepte de procéder au paiement, la procédure
de paiement est initiée
Commentaires : Produire un prototype à tester avec un groupe d’usagers
Fréquence prévue : Environ 100 commandes par jour
Auteur du cas : Louis Ramirez

12. Il détermine ensuite les variations. Dans ce cas-ci, les variations ont trait au point un, c’est-à-dire au
type de client et au moyen choisi pour indiquer son désir de commander. Ainsi, contrairement aux
individus, les institutions d’enseignement connues, en plus de bénéficier de tarifs spéciaux, ne paient
que sur livraison. Par ailleurs, si on veut modéliser tout le processus de commande et non seulement
le commerce électronique, on inclurait le téléphone, le télécopieur, le courrier électronique et les
visites en personne comme moyen de commande. Si Louis voulait formaliser ces variations, elles
pourraient être d’abord résumées comme dans le tableau suivant, puis détaillées sous forme
textuelle.

© Gilles E. St-Amant
 7

Variations : Cas 01, version 1, 15 décembre 2002

Description : Étape Action
1 1,1 Le client est :
• 1,11 Une institution d’enseignement connue
• 1,12 Une institution d’enseignement non encore
enregistrée
• 1,13 Un individu ou autre

1 1,2 L’intention d’achat est exprimé

• 1,21 Par le bouton commander maintenant
• 1,22 Par courrier électronique
• 1,23 Par téléphone
• 1,24 Par télécopieur
• 1,25 En personne

13. Il rédige ensuite les extensions, c’est-à-dire ce qui se produit quand les conditions ne se réalisent
pas. Il aura alors une longue liste d’énoncés, comprenant :

Extensions : Cas 01, version 1, 15 décembre 2002

Description : Étape Action
3a Client Sans Identificateur (nouveau client)
3a1 Le système lui demande d’entrer ses coordonnées
complètes
3a2 Le client entre toutes ses coordonnées
3a3 Le système vérifie les coordonnées
3a4 Le système attribue un identificateur
3a5 Le système enregistre les données dans la base de données
clients
3b Identificateurs Oubliés
3b1 Le système lui demande des renseignements pour retrouver
ses identificateurs
5a Identificateur Incorrect
5a1 Le système indique que l’identification est erronée et
demande de réessayer
5a2 Si l’entrée est de nouveau incorrecte, voir 3a1
7a Renseignements Non Valides
7a1 Le système permet aux clients de les modifier
Etc. Détailler de la même façon pour chaque condition non
remplie

© Gilles E. St-Amant
 8

14. L’équipe peut d’ores et déjà penser à des inclusions ou fragments communs7. Par exemple, on a
prévu, dans le cas « obtenir soutien », que les clients devraient s’identifier pour accéder à l’aide
pertinente. Les étapes 2 à 4 du cas « commander » seraient donc un fragment commun à plus d’un
cas.
15. Les cas sont validés, de nouveau, avec le client. Par exemple, Diane soulève la question « Qu’arrive-
t-il si les articles de la commandes ne sont pas en stock ? ». Louis ajoute donc une étape, en
remplacement de l’étape 9, à l’effet que le système vérifie les marchandises disponibles et en affiche
la liste.
16. La remarque de Diane l’amène aussi à compléter ses cas. Il ajustera le cas « Obtenir Information »
pour que les marchandises en rupture de stock soient indiquées et ne puissent être ajoutées au panier.
Il se rend aussi compte qu’il devra en conséquence mettre en place à l’interne un meilleur système
de contrôle des stocks, à jour en tout temps.
17. Il complète le diagramme de cas d’utilisation, en y ajoutant les extensions et les fragments. Par
exemple, en incluant les extensions et des inclusions déjà repérées, le diagramme client pourrait
s’être enrichi de la façon suivante.

Système de commerce électronique

Obtenir
Information
Identificateur
NonValide
««étend »»

Commander
««étend»»
Renseignements Base Données
Erronés Clients
««inclut»»

Payer

S’identifier Banque
Client
Client

««inclut»»

Obtenir Recevoir
Soutien Produit
Transporteur

Soutien

7
En anglais, on utilise les termes « uses » ou « includes » pour désigner les fragments communs.

© Gilles E. St-Amant