Un projet informatique démarre souvent par une phrase simple : « On voudrait que le système fasse ça. » Le problème, c’est que « ça » ne veut pas dire la même chose pour la personne qui exprime le besoin métier et pour celle qui va le traduire en lignes de code. Le use case, ou cas d’utilisation, est justement l’outil qui permet de poser une définition commune entre la MOA (maîtrise d’ouvrage) et la DSI (direction des systèmes d’information).
Comprendre ce qu’est un use case et savoir le rédiger correctement évite les malentendus qui se transforment en retards, en surcoûts ou en fonctionnalités inutiles. Voici comment les deux parties peuvent s’en servir pour parler le même langage.
A découvrir également : Webmail ia37 : accès rapide à votre messagerie Orléans-Tours
Use case : une définition concrète avant le jargon
Avant de parler d’UML ou de diagrammes, prenons un exemple. Vous travaillez dans une mutuelle. Un adhérent appelle pour modifier son adresse postale. L’opérateur ouvre l’application, saisit la nouvelle adresse, valide, et le système envoie un accusé de réception par courriel.
Cette séquence, du déclenchement (l’appel de l’adhérent) jusqu’au résultat attendu (le courriel envoyé), forme un use case. C’est la description d’une interaction entre un utilisateur (appelé « acteur ») et le système, pour atteindre un objectif précis.
A lire en complément : Log informatique : définition, usage et importance en langage informatique
La définition d’un use case tient en une phrase : un scénario décrivant ce que fait le système quand un acteur cherche à accomplir un but. Pas de détails techniques, pas de choix d’architecture. Juste le quoi, jamais le comment.
Pourquoi la MOA et la DSI lisent le même use case différemment
La MOA raisonne en processus métier. Quand elle lit « modifier l’adresse d’un adhérent », elle pense aux règles de gestion : faut-il vérifier que l’adhérent a un contrat actif ? Peut-il modifier l’adresse d’un tiers ? Que se passe-t-il si le code postal n’existe pas ?
La DSI, elle, pense interfaces, appels API, base de données. Elle veut savoir quel champ est obligatoire, quel service technique sera sollicité, quel format de données respecter.
Le use case bien rédigé répond aux deux lectures sans les mélanger. Il décrit le flux principal (le « chemin heureux ») et les flux alternatifs (erreurs, exceptions) dans un vocabulaire accessible. Un use case n’est ni un cahier des charges ni une spécification technique : il se situe entre les deux, comme un pont.
Rédiger un use case que les deux parties comprennent
Un use case utile ne ressemble pas à un roman. Il suit une structure répétable qui rassure la MOA (elle retrouve son vocabulaire métier) et la DSI (elle identifie les cas limites à traiter).
Chaque use case contient les éléments suivants :
- Acteur principal : la personne ou le système externe qui déclenche l’action (ex. : l’opérateur de la mutuelle, un flux batch nocturne)
- Objectif : ce que l’acteur cherche à accomplir, formulé avec un verbe d’action (« modifier une adresse », « générer un relevé mensuel »)
- Préconditions : ce qui doit être vrai avant le démarrage (« l’opérateur est authentifié », « l’adhérent existe dans le référentiel »)
- Scénario nominal : les étapes numérotées du chemin principal, de l’action initiale au résultat final
- Extensions : les variantes et erreurs (« le code postal est invalide », « l’adhérent a résilié son contrat »)
Un piège fréquent consiste à décrire les étapes du point de vue de l’interface graphique (« l’utilisateur clique sur le bouton Valider »). Ce niveau de détail appartient aux spécifications fonctionnelles, pas au use case. Préférez « l’opérateur confirme la modification » : la MOA comprend l’intention, la DSI reste libre du choix technique.
Le bon niveau de granularité
Vous avez déjà vu des documents où un seul use case couvre la totalité d’un module ? C’est trop large. À l’inverse, un use case par champ de formulaire est trop fin.
La bonne maille correspond à un objectif utilisateur autonome et vérifiable. « Gérer les adhérents » est trop vague. « Modifier l’adresse d’un adhérent » est testable : à la fin, soit l’adresse a changé, soit elle n’a pas changé. On peut écrire un critère d’acceptation dessus.
Erreurs fréquentes qui cassent le dialogue MOA-DSI
La première erreur est d’écrire les use cases trop tard. Quand la MOA livre un cahier des charges de cinquante pages en prose, la DSI doit « deviner » les cas d’utilisation enfouis dans le texte. Le travail de traduction génère des interprétations divergentes.
La deuxième erreur est l’inverse : la DSI rédige seule les use cases à partir d’ateliers trop rapides. Le résultat est techniquement propre mais déconnecté des vrais parcours des utilisateurs métier.
La troisième erreur concerne les extensions. Beaucoup de use cases décrivent le chemin nominal et s’arrêtent là. Les cas d’erreur, les exceptions métier, les flux dégradés sont absents. Ce sont pourtant ces scénarios qui provoquent la majorité des anomalies en recette.
- Rédiger les use cases ensemble, MOA et DSI dans la même salle (ou le même atelier visio), dès la phase de cadrage
- Relire chaque extension en se posant la question : « que fait le système si cette étape échoue ? »
- Valider chaque use case par un critère d’acceptation formulé en langage métier, pas en langage technique
Use cases et méthodes agiles : complémentaires, pas opposés
Dans un contexte agile, on entend parfois que les user stories remplacent les use cases. Les deux outils ne jouent pas le même rôle. La user story (« En tant que… je veux… afin de… ») capture un besoin à un niveau intentionnel. Le use case détaille le flux d’interaction complet.
En pratique, un use case peut se découper en plusieurs user stories pour alimenter un backlog. Le scénario nominal devient une première story, chaque extension significative en génère une autre. La MOA conserve la vision globale grâce au use case, et la DSI planifie son travail sprint par sprint grâce aux stories.
Cette articulation fonctionne à condition que le use case reste à jour. Un document figé en début de projet puis jamais relu perd toute valeur de référence commune.
Construire un référentiel de use cases partagé
Plutôt que de stocker les use cases dans des fichiers Word échangés par courriel, mieux vaut les centraliser dans un outil accessible aux deux parties. Un wiki interne, un espace Confluence ou même un tableur partagé suffisent, à condition que chaque use case porte un identifiant unique et un statut clair (brouillon, validé MOA, validé DSI).
L’identifiant permet de tracer le lien entre un use case, les user stories associées, les tests de recette et les éventuels incidents en production. Cette traçabilité est ce qui transforme un simple document en outil de pilotage pour la MOA comme pour la DSI.
Le use case n’a rien d’un formalisme dépassé. Bien utilisé, il reste le format le plus direct pour qu’une personne côté métier et une personne côté technique vérifient, en quelques minutes de lecture, qu’elles parlent exactement du même besoin.
