Au-dela du débat user stories contre cas d'utilisation

Une brève histoire de l’expression des besoins

Les exigences logicielles ont toujours été un problème de traduction. Les parties prenantes savent ce qu’elles veulent en termes métier. Les développeurs ont besoin de ces connaissances exprimées sous une forme exploitable. Les méthodes utilisées pour cette traduction ont changé environ une fois par décennie, et chaque transition a produit le même argument: la nouvelle approche rend l’ancienne obsolète.

Les cas d’utilisation sont apparus dans les années 1990, popularisés par Ivar Jacobson et formalisés par Alistair Cockburn. Ils ont remplacé les déclarations abstraites « le système doit » par des scénarios concrets: un acteur effectue une action, le système répond, et l’interaction se poursuit jusqu’à ce que l’objectif soit atteint ou abandonné. Les cas d’utilisation ont rendu les exigences lisibles et vérifiables.

Puis l’agilité est arrivée. Les user stories ont émergé de l’Extreme Programming au début des années 2000 et se sont répandues via Scrum dans la pratique courante. Le format était délibérément minimal: un rôle, un souhait et une raison, écrits sur une fiche cartonnée. Kent Beck et Ron Jeffries ont conçu les stories comme des déclencheurs de conversation, pas comme des spécifications finies.

La mauvaise lecture qui a tout changé

Le Manifeste Agile dit « un logiciel fonctionnel plutôt qu’une documentation exhaustive. » Le mot « exhaustive » porte tout le poids de cette phrase. Il vise le cahier des charges de 500 pages qui prend six mois à rédiger et qui est dépassé avant la première ligne de code. Il ne vise pas un cas d’utilisation de deux pages décrivant comment un client retourne un produit défectueux.

De nombreux praticiens ont lu le manifeste comme « pas de documentation » et ont adopté les user stories comme seul artefact d’exigences. Pour des projets simples avec des product owners impliqués et de petites équipes, cela a fonctionné. Pour tout le reste, cela a créé un vide documentaire que les équipes ont comblé avec des connaissances tribales, des messages Slack et des suppositions.

Ce qui se perd sans le détail

Les user stories excellent dans la capture de l’intention. Elles répondent à la question stratégique: de quoi cette personne a-t-elle besoin et pourquoi est-ce important? Elles sont moins efficaces pour capturer le comportement: que se passe-t-il exactement quand on clique sur ce bouton, et que se passe-t-il quand quelque chose tourne mal?

Prenons un flux de paiement e-commerce. La story est nette: « En tant que client, je veux finaliser mon achat pour recevoir ma commande. » Derrière cette story se cache un labyrinthe de décisions. Validation du paiement, vérification du stock, validation de l’adresse, calcul des taxes, options de livraison, application de coupons et gestion des erreurs pour chacune de ces étapes. Une seule story ne peut pas contenir cette complexité. Un ensemble de stories peut la décomposer, mais la décomposition sans un récit unificateur laisse les développeurs assembler un puzzle sans l’image sur la boîte.

Les cas d’utilisation fournissent cette image. Ils décrivent le flux complet, y compris les chemins d’exception que les stories abordent rarement avant qu’un testeur ne les découvre en sprint review.

La vraie question

Le débat entre user stories et cas d’utilisation pose mal le problème. Il demande « quel artefact devrait-on utiliser? » alors que la question productive est « quel niveau de détail cette exigence nécessite-t-elle? »

Certaines exigences ne nécessitent qu’une phrase. Un changement mineur d’interface, une option de configuration, un simple affichage de données. Une user story gère cela efficacement. D’autres exigences décrivent des interactions complexes avec plusieurs acteurs, des logiques de branchement et des scénarios d’échec. Celles-ci ont besoin du détail structuré que les cas d’utilisation apportent.

Le BABOK Guide de l’IIBA adopte cette vision pragmatique. Il répertorie les user stories et les cas d’utilisation comme des techniques d’élicitation et d’analyse sans déclarer l’une supérieure à l’autre. De même, le référentiel CPRE de l’IREB traite les cas d’utilisation comme une technique principale pour spécifier les exigences fonctionnelles, reconnaissant que les pratiques agiles complètent l’ingénierie des exigences structurée plutôt qu’elles ne la remplacent. Les deux standards reconnaissent que les exigences existent en différentes tailles et formes.

Comment les équipes modernes combinent les deux

Les équipes agiles efficaces ont dépassé le débat du « soit l’un soit l’autre. » On utilise les stories dans le product backlog pour la priorisation et la planification de sprint. Quand une story révèle une complexité cachée pendant le refinement, on documente l’interaction détaillée dans un cas d’utilisation ou un format structuré similaire.

Un scénario typique: pendant le refinement du backlog, l’équipe discute d’une story sur la réinitialisation de mot de passe. Le product owner mentionne que les clients entreprise nécessitent une authentification multi-facteurs, des verrouillages temporaires après des tentatives échouées et des capacités de déblocage administrateur. La BA reconnaît que cette story a dépassé ce qu’une simple fiche peut transmettre. Elle rédige un cas d’utilisation qui capture le flux principal, trois chemins alternatifs et deux scénarios d’exception. La story reste dans le backlog comme unité de planification. Le cas d’utilisation devient la spécification sur laquelle les développeurs et les testeurs travaillent.

Cette approche hybride préserve l’accent agile sur la rapidité et l’adaptabilité tout en fournissant la précision que les logiciels complexes exigent. L’analyste métier devient le pont, traduisant entre les priorités du product owner et le besoin de clarté de l’équipe de développement.

Les exigences comme un spectre

L’évolution des pratiques d’exigences suit un schéma. Chaque nouvelle méthode corrige les excès de sa prédécesseure. Les cahiers des charges étaient trop lourds, alors les cas d’utilisation ont rendu les exigences scénarisés. Les cas d’utilisation pouvaient devenir bureaucratiques, alors les user stories ont réduit les exigences à leur essence. Aujourd’hui, les stories trop dépouillées manquent parfois du détail dont les équipes ont besoin.

La réponse n’est pas de choisir un camp. C’est de reconnaître que la documentation des exigences existe sur un spectre, du léger au détaillé. Le niveau approprié dépend du projet, de l’équipe, du domaine et de l’exigence spécifique. Un analyste métier compétent lit le contexte et choisit en conséquence.

L’agilité n’a pas tué les cas d’utilisation. Elle a tué l’hypothèse selon laquelle un seul format de documentation convient à toutes les situations. C’est une leçon plus utile que n’importe quelle guerre méthodologique ne pourrait offrir.