Use case : définition, exemple rédigé, vs user story

Un use case, ou cas d’utilisation en français, est la description écrite et structurée d’un scénario complet d’interaction entre un acteur et un système. Il précise qui agit, dans quelles conditions de départ, selon quelle séquence d’étapes, et ce que devient le système une fois l’objectif atteint — ou manqué.

C’est un outil que l’agilité a longtemps rangé au grenier, au motif qu’il sentait le cahier des charges. Il en revient, et pas par nostalgie : sur un tunnel de paiement, un parcours soumis à une obligation réglementaire ou un enchaînement de systèmes tiers, la user story seule laisse trop de zones grises. Voyons ce qu’est exactement un use case, comment on le rédige, à quoi ressemble un exemple complet, et à quel moment il devient le bon outil.

Qu’est-ce qu’un use case ? Définition

Le use case répond à une question précise : qu’est-ce que cet acteur vient chercher auprès du système, et comment l’obtient-il ? La notion a été introduite à la fin des années 1980 par l’ingénieur suédois Ivar Jacobson, avant d’être absorbée par UML — Unified Modeling Language, le langage de modélisation normalisé par l’Object Management Group. C’est ce passage par UML qui explique une confusion tenace : beaucoup croient qu’un use case est un dessin. Le dessin, c’est le diagramme de cas d’utilisation, et il ne fait que cartographier les acteurs et leurs objectifs. Le use case, lui, est le texte qui décrit le déroulé.

L’acteur n’est d’ailleurs pas forcément humain. Un système de facturation qui déclenche un prélèvement, un service de transport qui envoie un statut de livraison sont des acteurs à part entière. On distingue par ailleurs l’acteur principal, celui dont l’objectif justifie l’existence du cas, des parties prenantes, qui ont un intérêt dans le résultat sans participer aux étapes : la comptabilité, le service juridique, le support client.

Cas d’utilisation ou cas d’usage : la nuance qui compte

Les deux traductions circulent, mais elles ont pris des chemins différents. Cas d’utilisation reste le terme d’analyse, hérité d’UML : il désigne l’objet documentaire décrit dans cet article. Cas d’usage a glissé vers le vocabulaire commercial, où il signifie « exemple d’application concrète » — on parle des cas d’usage d’un outil d’intelligence artificielle comme on parlerait de ses débouchés. Utile à savoir en réunion : quand un interlocuteur réclame « les cas d’usage », il attend souvent une liste d’exemples, pas un document structuré.

Les trois niveaux de granularité d’un use case

Un use case n’a de sens qu’à une altitude donnée. Alistair Cockburn, auteur de la référence sur le sujet — Writing Effective Use Cases, paru en 2000 — a proposé une échelle à trois niveaux qui reste le meilleur garde-fou contre les documents illisibles :

• Niveau résumé — « Gérer les comptes clients ». Trop large pour être développé, utile pour poser le périmètre d’un chantier.
• Niveau objectif utilisateur — « Payer une commande ». C’est le bon niveau, celui d’une tâche que l’acteur accomplit d’une traite et après laquelle il peut partir satisfait.
• Niveau sous-fonction — « S’authentifier ». Trop fin pour vivre seul : il sera appelé par plusieurs cas de niveau supérieur.

La règle pratique tient en une phrase : un use case se rédige au niveau objectif utilisateur. Au-dessus, il devient un intitulé de projet ; en dessous, il se réduit à un fragment technique qu’on répétera partout.

L’anatomie d’un use case : les rubriques à remplir

Il n’existe pas de format normalisé unique, mais les modèles sérieux convergent sur les mêmes rubriques. Les remplir dans l’ordre est la méthode la plus fiable pour écrire un use case : chaque case vide est une question qu’on n’a pas encore posée au métier.

• Nom — un verbe à l’infinitif et son objet, du point de vue de l’acteur : « Payer une commande », jamais « Module de paiement ».
• Portée et niveau — quel système est concerné, et à quelle granularité on se situe.
• Acteur principal — celui dont l’objectif est servi.
• Parties prenantes et intérêts — qui d’autre a quelque chose à gagner ou à perdre dans le résultat.
• Préconditions — l’état vérifié du système avant le déclenchement. Ce ne sont pas des souhaits : ce sont des faits garantis.
• Déclencheur — l’événement qui met le scénario en route.
• Scénario nominal — la séquence numérotée d’étapes quand tout se passe bien.
• Extensions et postconditions — les variantes, les erreurs, et l’état du système à l’arrivée.

Scénario nominal, alternatif, exception

C’est le cœur de la méthode, et ce qui fait la valeur d’un use case. Le scénario nominal décrit le chemin le plus court et le plus fréquent vers l’objectif : une dizaine d’étapes au maximum, alternant systématiquement une action de l’acteur et une réponse du système. On l’écrit d’abord, d’un trait, sans se préoccuper des exceptions.

Viennent ensuite les extensions, rattachées au numéro de l’étape qu’elles dévient. Elles se rangent en deux familles. Les scénarios alternatifs atteignent le même objectif par un autre chemin — payer avec une carte cadeau au lieu d’une carte bancaire. Les scénarios d’exception décrivent un échec et ce que le système en fait : paiement refusé, article devenu indisponible, service tiers injoignable. Cette dernière famille est celle qui rentabilise l’exercice, parce qu’elle force la décision là où elle est habituellement improvisée en cours de développement.

Exemple de use case entièrement rédigé

Les articles sur le sujet s’arrêtent presque tous au tableau des rubriques. Voici donc un cas complet, au niveau objectif utilisateur, sur un terrain volontairement exigeant : le paiement d’une commande sur un site marchand. C’est le type de parcours où trois lignes de user story ne suffisent pas.

Scénario nominal — le chemin le plus fréquent, sans incident :

1. Le client choisit le paiement par carte bancaire.
2. Le système réserve les articles du panier pour une durée limitée et crée la commande au statut « en attente de paiement ».
3. Le système redirige le client vers le formulaire sécurisé de la plateforme de paiement.
4. Le client saisit les informations de sa carte et confirme.
5. La plateforme de paiement déclenche l’authentification forte auprès de la banque émettrice.
6. Le client valide l’authentification.
7. La plateforme confirme l’autorisation au système, qui passe la commande au statut « payée » et décrémente définitivement le stock.
8. Le système affiche la confirmation, envoie le justificatif au client et transmet la commande à la préparation.

Extensions — les variantes et les échecs, rattachés au numéro de l’étape qu’ils dévient :

• 2a. Un article n’est plus disponible — le système en informe le client, met à jour le panier et le renvoie au récapitulatif. La commande n’est pas créée.
• 4a. Le client abandonne le formulaire — au terme de la réservation, le système libère le stock et passe la commande au statut « abandonnée ». Aucun encaissement.
• 6a. L’authentification échoue — le client peut réessayer deux fois, puis choisir un autre moyen de paiement. Au-delà, retour à l’étape 1.
• 7a. La banque refuse l’autorisation — le système affiche un motif compréhensible sans divulguer d’information bancaire, libère le stock et propose un autre moyen de paiement.
• 7b. La plateforme de paiement ne répond pas — le système conserve la commande « en attente de paiement », informe le client qu’aucun débit n’est confirmé, et vérifie le statut réel de la transaction avant toute relance. Le stock reste réservé jusqu’à l’expiration du délai.

Une fois écrit, ce document se lit en quelques minutes et se discute avec la comptabilité comme avec les développeurs. Regardez surtout l’extension 7b : le cas où l’on ne sait pas si le client a été débité. C’est le scénario qui coûte le plus cher en production, celui qui ne figure jamais dans une user story, et celui qu’un use case oblige à trancher avant d’écrire la moindre ligne de code.

Use case vs user story : scénario contre intention

La confusion vient de ce que les deux formats parlent d’un utilisateur qui veut quelque chose. Mais ils ne visent pas la même chose. Une user story énonce une intention : un besoin, un bénéfice, en une phrase, délibérément incomplète pour laisser place à la conversation. Un use case déroule un scénario : la même intention, mais instrumentée de bout en bout, avec ses conditions d’entrée, ses embranchements et ses échecs.

La formule la plus juste circule depuis longtemps dans les communautés francophones : une user story correspond souvent à un seul des scénarios d’un use case. L’exemple de paiement ci-dessus se découpe sans peine en plusieurs stories — une pour le chemin nominal, une pour le refus d’autorisation, une pour l’indisponibilité d’un article — chacune estimable et livrable séparément.

Critère	User story	Use case
Ce qu’elle décrit	une intention	un scénario complet
Format	une phrase, plus des critères d’acceptation	un document à rubriques
Cas d’erreur	implicites, traités à la conversation	énumérés et tranchés par écrit
Origine	Extreme Programming, fin des années 1990	Ivar Jacobson, fin des années 1980, puis UML
Où elle vit	le backlog produit	le dossier de cadrage
Ce qu’elle suppose	un accès facile au métier et à l’utilisateur	un besoin déjà stabilisé
Terrain de prédilection	livraison itérative, incertitude forte	complexité métier, exigence de traçabilité

Quand le use case est le bon outil

Le critère de décision n’est pas la taille du projet ni la méthode affichée : c’est le coût d’un cas non prévu. Quand oublier un embranchement se paie par un litige, un écart comptable ou un incident client difficile à rattraper, écrire le scénario en entier est un investissement rentable. Trois familles de sujets remplissent ce critère.

• Le paiement et les flux financiers — l’état intermédiaire, celui où l’on ne sait pas encore si la transaction a abouti, doit être décidé avant le développement, pas pendant.
• La conformité et le réglementaire — consentement, droit d’accès aux données, obligations sectorielles : il faut pouvoir démontrer que chaque cas prévu par le texte est couvert. Une liste de stories dispersées dans un backlog produit ne le démontre pas.
• Les systèmes interconnectés — dès qu’un enchaînement traverse un système de gestion des commandes, un progiciel de gestion intégré et un transporteur, les cas d’erreur ne sont plus des détails : ce sont les trois quarts du travail.

À l’inverse, sur une fonctionnalité dont on ignore encore si elle intéresse quelqu’un, le use case est un contresens : il documente précisément une hypothèse non validée. C’est le terrain du product discovery et des petites itérations, pas celui de la spécification détaillée.

Les deux ensemble, plutôt que l’un contre l’autre

L’opposition est largement un artefact de querelle méthodologique. Signe qui ne trompe pas : Alistair Cockburn, celui-là même qui a écrit la référence sur les use cases, a publié en 2025 un ouvrage intitulé Unifying User Stories, Use Cases, Story Maps. Le débat est tranché par l’auteur du camp adverse supposé.

L’articulation la plus courante est séquentielle. Le use case sert au cadrage : on l’écrit avec le métier pour comprendre le déroulé réel et débusquer les cas oubliés. Il alimente ensuite la spec produit, puis se découpe en user stories qui entrent au backlog, chacune munie de ses critères d’acceptation. Le use case reste alors le document de référence auquel on revient quand une question surgit six mois plus tard — au backlog refinement, il évite de rejouer trois fois la même discussion sur le comportement attendu en cas d’échec.

La user story dit ce que l’utilisateur veut. Le use case dit ce qui se passe quand il ne l’obtient pas.

Mon avis, après plus de dix ans passés entre e-commerce et éditeurs de logiciels : le use case a été jeté avec l’eau du bain du cycle en V, et il manque à beaucoup d’équipes. Non pas comme livrable contractuel de trois cents pages, mais comme exercice de rédaction — deux heures avec le métier sur un parcours critique, et il en ressort presque toujours deux ou trois cas d’erreur que personne n’avait vus. Pour une vue d’ensemble complémentaire, côté vécu utilisateur plutôt que côté système, le customer journey map et la grille des 5W se marient très bien avec ce travail.

FAQ — Tout savoir sur le use case

Comment traduire use case en français ?

La traduction consacrée est cas d’utilisation, terme issu d’UML et employé en analyse fonctionnelle. « Cas d’usage » est aussi correct mais a pris un sens plus large dans le langage commercial, où il désigne un exemple d’application concrète d’un produit ou d’une technologie.

Écrit-on use case ou use cases au pluriel ?

En anglais, le pluriel est use cases. Dans une phrase française, l’usage professionnel garde généralement le s anglais (« les use cases du parcours »), mais la forme invariable se rencontre. Le plus sûr en rédaction soignée reste d’employer le français : « les cas d’utilisation ».

Quelle différence entre un use case et un test case ?

Le use case décrit ce que le système doit faire ; le test case vérifie qu’il le fait. Un même use case engendre plusieurs cas de test : au minimum un par chemin, nominal et extensions comprises. C’est d’ailleurs l’un de ses bénéfices secondaires les plus appréciés des équipes de recette.

Quelle différence entre un use case et un scénario ?

Un scénario est un seul déroulé possible, du début à la fin. Un use case est l’ensemble des scénarios qui poursuivent le même objectif : le nominal, les alternatifs et les exceptions réunis dans un même document. Le scénario est le fil, le use case est la pelote.

Un use case est-il forcément un diagramme UML ?

Non, et c’est la confusion la plus répandue. Le diagramme de cas d’utilisation est une vue d’ensemble : des acteurs, des ovales, des relations. Il ne contient aucune étape. Le use case est le texte structuré qui décrit le déroulé, et il s’écrit très bien sans le moindre diagramme.

Faut-il des critères d’acceptation dans un use case ?

Ce n’est pas nécessaire, car les rubriques du use case jouent déjà ce rôle : les postconditions énoncent le résultat vérifiable et les extensions le comportement attendu en cas d’écart. Les critères d’acceptation restent en revanche indispensables sur les user stories issues du découpage.

Existe-t-il un template de use case à réutiliser ?

Oui, et le plus diffusé reste celui d’Alistair Cockburn, dont les rubriques sont reprises dans la section « anatomie » de cet article. Un modèle plus léger — nom, acteur, préconditions, scénario nominal, extensions, postconditions — suffit dans la plupart des contextes produit. Au-delà d’une page et demie, le document cesse d’être lu.