Un use case décrit une interaction complète entre un acteur et un système pour atteindre un objectif métier. Dans un projet agile, cette description pose un problème concret : elle produit souvent un document trop dense pour tenir dans un sprint de deux semaines. L’enjeu n’est pas de choisir entre use cases et user stories, mais de comprendre comment les use cases se découpent, se tracent et se limitent dans un cadre itératif.
Use case et user story en projet agile : ce que chaque format capture
| Critère | Use case | User story |
|---|---|---|
| Granularité | Scénario complet (flux nominal + exceptions) | Besoin utilisateur unitaire (une phrase) |
| Préconditions / postconditions | Explicites, documentées | Rarement formalisées |
| Couverture des cas d’erreur | Flux alternatifs et d’exception détaillés | Traitée via critères d’acceptation, souvent partielle |
| Acteurs multiples | Gestion native (acteur principal, acteurs secondaires) | Un seul rôle par story (« En tant que… ») |
| Maintenance documentaire | Lourde si le document n’est pas vivant | Légère, portée par le backlog |
| Adapté à la logique métier complexe | Oui (intégrations multi-acteurs, règles métier) | Limité sans documentation complémentaire |
Le use case ne remplace pas la user story. Il intervient quand la logique métier exige de délimiter le périmètre et couvrir les exceptions de manière explicite, ce qu’une story seule ne garantit pas sur des processus impliquant plusieurs acteurs ou systèmes.
A lire aussi : Limites de WordPress : découvrir ses possibilités infinies !
Découper un use case trop gros pour un sprint sans perdre la traçabilité métier
Un use case qui couvre un processus complet (inscription, paiement, gestion d’erreur, notification) dépasse presque toujours la capacité d’un sprint. Le réflexe classique consiste au transformer en user stories indépendantes. Le risque : perdre la vision d’ensemble et oublier des flux d’exception en route.
A découvrir également : UC : définition, caractéristiques et utilité en informatique
Use Case 2.0 : le découpage par slices
L’approche Use Case 2.0, proposée par Ivar Jacobson et Alistair Cockburn, répond directement à ce problème. Elle conserve le use case comme conteneur de la logique métier globale, mais le découpe en slices : des tranches verticales qui traversent le flux nominal ou un flux alternatif, chacune livrable dans un sprint.
Chaque slice correspond à un chemin précis dans le use case. Le flux nominal produit une première slice. Chaque branche d’exception ou flux alternatif génère une slice distincte. La traçabilité est maintenue parce que chaque slice reste rattachée au use case parent.
- Slice 1 : flux nominal complet (le chemin « tout se passe bien »), livré en premier pour valider la structure
- Slice 2 : premier flux alternatif (par exemple, un moyen de paiement refusé), qui ajoute une branche au scénario existant
- Slice 3 : cas d’erreur critique (timeout d’un service externe, données manquantes), traité en priorité si le risque métier est élevé
- Slices suivantes : variantes d’acteurs secondaires, règles métier spécifiques à un contexte réglementaire
Ce découpage évite le piège du document monolithique. Chaque slice est estimable, testable et démontrable en revue de sprint. Le product owner conserve le use case complet comme référence pour vérifier que l’ensemble des chemins a été couvert au fil des itérations.
Traçabilité dans le backlog
En pratique, chaque slice devient un item du backlog produit. Le lien avec le use case parent se matérialise par un tag, un epic ou un champ personnalisé dans l’outil de gestion (Jira, Azure DevOps, GitLab). Le use case complet ne vit pas dans un document Word séparé : il est intégré au backlog comme élément structurant, mis à jour à chaque sprint quand une slice modifie un flux.
Cette approche suppose une discipline : l’équipe met à jour les préconditions et postconditions du use case parent à chaque livraison de slice. Sans cette maintenance, le use case devient obsolète en quelques sprints, ce qui annule son intérêt.
Limites des use cases en contexte agile : quand la documentation devient un frein
La rigueur du use case a un coût. Plusieurs écueils reviennent systématiquement dans les équipes qui tentent de combiner use cases et sprints courts.
Le premier concerne la surcomplexification. Un use case trop détaillé dès le départ fige des choix de conception avant que l’équipe ait reçu du feedback utilisateur. Dans un cadre agile, les exigences évoluent à chaque itération. Un use case rédigé comme une spécification définitive entre en conflit direct avec ce principe.
Le deuxième tient à la maturité de l’équipe. Maintenir un use case comme documentation vivante demande que chaque développeur, testeur et product owner comprenne la notation, mette à jour les flux après chaque sprint, et sache distinguer un flux alternatif d’un critère d’acceptation. Sans cette compétence partagée, le use case devient un artefact mort en quelques semaines.
Le troisième piège est l’effet tunnel documentaire. Une équipe qui passe deux sprints à rédiger des use cases exhaustifs avant de coder quoi que ce soit reproduit, sous un autre nom, le cycle en cascade qu’elle cherchait à éviter.
Exemple concret : use case de commande en ligne découpé en slices agiles
Prenons un use case « Passer une commande » sur une plateforme e-commerce. L’acteur principal est le client. Les acteurs secondaires sont le système de paiement et le service logistique.
Le use case complet couvre : ajout au panier, choix de livraison, paiement, confirmation, gestion des erreurs de stock, échec de paiement, adresse invalide.
Découpage en slices pour le backlog
Slice 1 (sprint 1) : le client ajoute un produit, choisit la livraison standard, paie par carte, reçoit une confirmation. Flux nominal pur, sans gestion d’erreur.
Slice 2 (sprint 2) : le paiement est refusé. Le système affiche un message, propose de réessayer ou de changer de moyen de paiement. Précondition mise à jour dans le use case parent.
Slice 3 (sprint 3) : le produit n’est plus en stock après ajout au panier. Le système propose une alternative ou un remboursement. Postcondition ajoutée au use case.
À la fin du sprint 3, l’équipe a livré trois incréments fonctionnels. Le use case parent documente l’ensemble des chemins couverts et ceux qui restent à traiter. Le product owner peut prioriser les slices restantes (adresse invalide, timeout logistique) en fonction du feedback réel des utilisateurs.
Critères pour décider entre use case et user story dans un projet agile
Le choix dépend de la complexité du processus, pas de la taille de l’équipe ou du framework utilisé.
- Si le processus implique un seul acteur et un flux linéaire sans branche d’exception critique, la user story suffit
- Si plusieurs acteurs interagissent avec des règles métier conditionnelles (paiement, validation réglementaire, workflow d’approbation), le use case apporte une couverture que la story seule ne garantit pas
- Si l’équipe n’a pas l’habitude de maintenir une documentation structurée, commencer par des user stories enrichies de critères d’acceptation détaillés est plus réaliste que d’imposer des use cases complets
Les deux formats coexistent dans la majorité des projets agiles matures. Le use case sert de carte du territoire pour les processus complexes. Les user stories servent de GPS sprint par sprint.
L’arbitrage se fait au niveau du backlog refinement : si une story génère plus de trois questions sur les cas limites lors de l’estimation, c’est un signal que le périmètre mérite un use case structuré, même minimal.
