Dans un projet IT, les malentendus commencent souvent par une demande trop vague comme « gérer les incidents » ou « améliorer le suivi client ». Un use case transforme cette intention en interaction concrète entre un acteur et un système, avec un objectif vérifiable. Je montre ici comment le construire, l’utiliser pour cadrer un projet et le relier à la qualité, aux tests et aux décisions de management.
Un cas d’utilisation relie un objectif métier à un résultat mesurable
- Point de départ : un acteur, un besoin précis et un résultat attendu.
- Structure efficace : préconditions, scénario principal, variantes, erreurs et résultat final.
- Valeur projet : réduire les ambiguïtés et mieux arbitrer le périmètre.
- Qualité : transformer chaque scénario en critères d’acceptation et en tests.
- Erreur fréquente : décrire des boutons ou des écrans au lieu de décrire un objectif utilisateur.
Comprendre ce que décrit réellement un cas d’utilisation
Un cas d’utilisation décrit une interaction orientée vers un objectif. L’acteur peut être un collaborateur, un client, un administrateur, un service externe ou même un autre système. Le système répond à ses actions pour produire un résultat qui a une valeur concrète.
La différence avec une simple fonctionnalité est importante. « Envoyer une notification » décrit une capacité technique. « Informer un client que sa demande a été prise en charge » décrit un objectif métier. Dans le second cas, on comprend mieux pour qui le service existe, dans quelle situation il intervient et comment vérifier qu’il fonctionne.
Je conseille toujours de formuler le nom avec un verbe et un résultat, par exemple « déclarer un incident », « valider une facture » ou « suivre une demande de congé ». Un titre comme « écran incident » ne dit rien de l’intention et enferme trop tôt l’équipe dans une solution d’interface.
Les éléments indispensables
- Acteur principal : celui qui poursuit l’objectif.
- Déclencheur : l’événement qui lance l’interaction.
- Préconditions : ce qui doit être vrai avant de commencer.
- Scénario nominal : le déroulement lorsque tout se passe normalement.
- Flux alternatifs : les variantes prévues du parcours.
- Exceptions : les situations d’échec ou de blocage.
- Postconditions : l’état obtenu à la fin du processus.
Cette structure n’a pas besoin d’être lourde. Pour un sujet simple, une page suffit souvent. Pour un processus réglementé ou critique, une description plus détaillée devient nécessaire, notamment afin de conserver la traçabilité des décisions et des contrôles.
Partir de l’objectif métier plutôt que de la solution
La meilleure façon de rédiger un cas d’utilisation consiste à interroger le besoin avant de parler de logiciel. Je demande généralement à l’équipe trois choses. Qui agit ? Que veut-il obtenir ? Comment saura-t-il que l’objectif est atteint ? Ces questions simples évitent une grande partie des exigences floues.
Prenons une plateforme de gestion des incidents. Le besoin n’est pas forcément de créer un formulaire. L’objectif peut être de permettre à un salarié de signaler rapidement une interruption de service, avec assez d’informations pour qu’un technicien puisse la qualifier et la prioriser.
Exemple de scénario métier
Acteur principal : salarié. Objectif : déclarer une interruption de service. Le salarié s’identifie, décrit le problème, indique son niveau d’urgence et joint éventuellement une capture d’écran. Le système vérifie les informations, attribue un numéro de suivi et confirme la prise en compte.
Le flux alternatif est tout aussi utile. Si le service concerné est déjà connu pour une panne en cours, le système peut proposer de rattacher la demande à l’incident existant. Si les informations sont insuffisantes, il doit expliquer ce qui manque au lieu de laisser l’utilisateur face à un message vague.
Ce type de détail révèle des exigences qui resteraient invisibles dans une liste de fonctionnalités. Il fait apparaître les règles de gestion, les responsabilités, les données nécessaires et les moments où l’expérience utilisateur risque de se dégrader.
Un niveau de détail adapté au projet
Je recommande de conserver un cas d’utilisation à un niveau où un responsable métier peut encore le relire sans aide technique. Les écrans, les API et la structure de la base de données appartiennent à une documentation différente. Le cas doit expliquer ce que le système permet d’accomplir, pas dicter prématurément comment il sera développé.
Dans une première version, cinq à neuf étapes principales suffisent souvent pour rendre le parcours lisible. Si le scénario devient une procédure interminable, il faut probablement le découper en plusieurs objectifs liés, plutôt que de produire un document impossible à maintenir.
Décrire les scénarios pour couvrir le réel
Un parcours nominal ne représente qu’une partie de l’expérience. Dans la pratique, les incidents, les droits insuffisants, les données manquantes et les interruptions réseau sont souvent à l’origine des défauts les plus coûteux. Une description utile doit donc répondre à la question que les équipes oublient le plus souvent : que se passe-t-il quand le déroulement prévu échoue ?
| Élément | Question à poser | Exemple de résultat |
|---|---|---|
| Précondition | Que faut-il avant le début ? | L’utilisateur dispose d’un compte actif. |
| Flux principal | Comment l’objectif est-il atteint normalement ? | La demande est saisie, contrôlée et enregistrée. |
| Variante | Quelle autre voie reste acceptable ? | La demande est rattachée à un incident existant. |
| Exception | Que se passe-t-il en cas de problème ? | Le système signale le champ manquant et conserve la saisie. |
| Postcondition | Quel état doit être garanti ? | Un numéro de suivi est créé et communiqué. |
Je distingue toujours la variante acceptable de l’erreur. Choisir une livraison à domicile au lieu d’un retrait en magasin est une variante. Fournir une adresse invalide est une exception. Cette distinction aide les équipes à concevoir des tests pertinents et à éviter de traiter tous les chemins avec la même priorité.
Pour les processus sensibles, j’ajoute aussi les acteurs secondaires et les systèmes externes. Un paiement, une signature électronique ou une vérification d’identité peut interrompre le scénario sans que l’utilisateur en soit responsable. Le cas doit alors préciser qui reprend la main, quelle information est conservée et si l’opération peut être relancée sans créer de doublon.
Faire du cas d’utilisation un outil de qualité
Un bon scénario ne sert pas uniquement à rédiger un cahier des charges. Il devient une base commune pour la conception, le développement, la recette et le support. Chaque étape peut être associée à une condition d’acceptation observable, c’est-à-dire un résultat que l’on peut vérifier sans interprétation.
Passer du scénario aux critères d’acceptation
Pour une demande d’achat, le scénario peut préciser que le système bloque une validation lorsque le montant dépasse le seuil d’autorisation du demandeur. Le critère n’est pas « la gestion des droits fonctionne ». Il devient « un utilisateur sans délégation ne peut pas valider une demande supérieure à 5 000 euros » si ce seuil correspond réellement à la règle de l’organisation.
Cette précision permet de tester à la fois le comportement attendu et ses limites. Je conseille de couvrir au minimum le parcours nominal, une variante métier et une exception importante. Les équipes n’ont pas besoin d’écrire des dizaines de tests artificiels si les quelques scénarios choisis représentent réellement les risques du processus.
Lire aussi : Ordonnancement de production - Évitez les erreurs courantes
Mesurer la qualité avec les bons indicateurs
La qualité ne se limite pas à l’absence de bug. Selon le service, il faut aussi examiner le temps nécessaire pour atteindre l’objectif, le taux d’abandon, la fréquence des reprises manuelles, le nombre d’erreurs ou la satisfaction des utilisateurs.
- Efficacité : l’objectif est-il atteint jusqu’au bout ?
- Performance : combien de temps l’interaction demande-t-elle ?
- Fiabilité : le résultat reste-t-il correct après une interruption ?
- Accessibilité : le parcours reste-t-il utilisable par les publics concernés ?
- Sécurité : chaque acteur peut-il seulement voir et modifier ce qui lui est autorisé ?
Un cas d’utilisation bien rédigé aide aussi à dialoguer avec une démarche qualité ou un système de management. Il rend les exigences plus traçables, facilite les audits internes et montre le lien entre une règle de l’entreprise et un comportement concret du système.
Éviter les erreurs qui rendent les cas inutilisables
La première erreur consiste à confondre un cas d’utilisation avec une description d’écran. Si le document énumère des boutons, des menus et des couleurs, il vieillira dès que l’interface changera. Je préfère décrire l’intention et le résultat, puis laisser l’équipe de conception choisir la meilleure interaction.
La deuxième erreur est de réunir plusieurs objectifs dans un seul scénario. « Créer, modifier, supprimer et exporter une facture » peut sembler pratique, mais ces opérations n’ont pas forcément les mêmes acteurs, risques ni critères de qualité. Des cas séparés sont plus faciles à prioriser et à tester.
La troisième erreur est de rédiger sans les utilisateurs concernés. Une équipe projet peut imaginer qu’un champ est évident alors qu’il est incompréhensible pour un agent de terrain. Une courte séance avec deux ou trois utilisateurs représentatifs révèle souvent davantage qu’une longue réunion centrée sur la solution.
Enfin, un cas trop détaillé peut devenir contre-productif. Je me méfie des documents qui décrivent chaque clic alors que le besoin n’est pas stabilisé. Il faut garder une granularité proportionnée au risque : beaucoup de précision pour une opération financière ou réglementaire, moins pour une consultation interne sans conséquence critique.
Faire vivre ces scénarios dans le pilotage du projet
Un cas d’utilisation n’est pas terminé quand il est rangé dans un dossier de spécifications. Il doit évoluer avec les décisions du projet, les retours de recette et les changements de processus. Je recommande de lui attribuer un propriétaire métier, une version et un statut clair, par exemple « à clarifier », « validé », « en développement » ou « accepté ».
Les cas peuvent ensuite aider à prioriser le périmètre. Un scénario qui bloque la facturation ou expose une donnée sensible passera avant une amélioration de confort. Cette approche donne au comité de pilotage une base plus solide que le simple volume de demandes exprimées par chaque service.
Ils sont également utiles dans les ateliers de conception. En faisant jouer le rôle de l’utilisateur, du système et des acteurs externes, l’équipe repère les décisions manquantes. Cette simulation est particulièrement efficace pour les processus transverses, où une demande passe d’un service à l’autre et où les responsabilités peuvent se diluer.
Après la mise en production, le scénario sert encore. Les tickets de support peuvent être rattachés à une étape précise, les indicateurs peuvent être comparés au résultat attendu et les évolutions peuvent être évaluées sans perdre la logique métier initiale. C’est cette continuité qui transforme un simple document en outil de gouvernance opérationnelle.
Un scénario bien écrit devient une décision mieux maîtrisée
Pour juger rapidement la qualité d’un cas d’utilisation, je vérifie quatre points. Un acteur identifiable poursuit un objectif unique, le résultat final est observable, les principaux chemins d’échec sont décrits et les critères de qualité sont mesurables. Si l’un de ces éléments manque, le projet risque de découvrir trop tard une attente pourtant prévisible.
Le bon niveau de détail n’est donc ni le plus court ni le plus technique. C’est celui qui permet au métier, au produit, à la qualité et à l’équipe de développement de parler de la même situation avec les mêmes mots. Une fois cette base posée, les arbitrages deviennent plus nets, les tests plus utiles et les utilisateurs beaucoup moins souvent surpris par le résultat livré.
