Use Case 2.0: allier ingénierie des exigences et agilité

Le fossé des exigences dans les projets agiles

Les méthodes agiles ont transformé la manière dont les équipes logicielles livrent. Des cycles plus courts, une collaboration étroite avec les utilisateurs, le logiciel fonctionnel comme mesure principale du progrès. Ces principes ont remodelé le secteur. Mais le passage à l’agilité a laissé une question pratique sans réponse: que devient l’ingénierie des exigences?

Les user stories ont comblé le vide pour les petites équipes. Elles sont légères, conversationnelles et tiennent sur des fiches cartonnées. Ron Jeffries a formalisé cela en 2001 avec sa formule 3C: Card (un énoncé bref), Conversation (dialogue continu avec les parties prenantes) et Confirmation (critères d’acceptation). Le format fonctionne pour les équipes qui construisent des fonctionnalités sprint après sprint.

Le problème apparaît quand les projets grandissent. Les product owners qui gèrent des centaines de stories perdent le fil. Quelles stories sont liées entre elles? Quel comportement global le système doit-il offrir? Le backlog devient une liste plate d’éléments déconnectés plutôt qu’une description cohérente des fonctionnalités du système. Les équipes expriment régulièrement la même frustration: les user stories seules ne transmettent pas la vision d’ensemble.

Pourquoi Jacobson a repensé les use cases

Ivar Jacobson a introduit les use cases en 1987 comme des séquences d’interactions entre un utilisateur et un système visant à atteindre un objectif précis. Près de quatre décennies plus tard, le concept reste largement adopté. Une enquête de 2013 révèle que 73% des entreprises allemandes et 51% des organisations suisses les utilisent encore pour la spécification des exigences. La raison est simple: les use cases décrivent ce que fait un système du point de vue de ceux qui l’utilisent.

Un seul use case capture toutes les façons dont une interaction peut se dérouler, du scénario nominal aux chemins alternatifs jusqu’à la gestion des erreurs. Cela donne aux parties prenantes et aux développeurs une image complète d’une capacité métier. Mais Jacobson a reconnu que les use cases traditionnels avaient une limitation importante. Ils étaient monolithiques. Un seul use case décrivant un processus de gestion de commandes pouvait s’étendre sur des dizaines de pages. Aucune équipe agile ne pouvait implémenter cela en un sprint de deux semaines.

Use Case 2.0 est la réponse de Jacobson. Publié sous forme de livre blanc en accès libre, il reformate la puissance analytique des use cases dans un format compatible avec l’agilité. L’innovation centrale est le use case slice.

Qu’est-ce qu’un use case slice?

Un use case slice est une coupe verticale fine à travers le récit d’un use case. Il sélectionne des scénarios spécifiques du use case complet et les conditionne comme un élément de travail livrable. Chaque slice est implémentable et testable de manière indépendante en un seul sprint.

Prenons un use case « Passer une commande ». Le flux de base où un client sélectionne des articles, saisit ses coordonnées de paiement et reçoit une confirmation devient le premier slice. Le flux alternatif pour appliquer un code de réduction devient le deuxième. La gestion des échecs de paiement devient le troisième. Chaque slice livre une fonctionnalité significative tandis que le use case parent conserve la vue complète du fonctionnement des commandes.

On élimine ainsi l’étape de traduction maladroite avec laquelle beaucoup d’équipes se débattent: convertir les use cases en user stories. Les slices ne sont pas des artefacts isolés déconnectés de leur origine. Ils maintiennent un lien explicite avec le use case parent. Quand une équipe termine un slice, le récit du use case se met à jour pour refléter ce qui a été construit. Le use case devient un document vivant qui suit la progression au-delà des sprints individuels.

Six pratiques pour structurer le travail

Use Case 2.0 organise le travail autour de six pratiques, réparties entre le niveau produit et le niveau sprint:

• Identifier les acteurs et les use cases pour établir le périmètre du système et identifier qui interagit avec lui
• Découper les use cases en éléments de travail dimensionnés pour un sprint en sélectionnant des flux ou scénarios spécifiques
• Préparer un slice en détaillant les flux sélectionnés juste assez pour l’implémentation
• Analyser un slice pour comprendre son impact sur l’architecture du système et les composants existants
• Implémenter le slice sous forme de logiciel fonctionnel dans le sprint
• Tester le slice par rapport aux critères d’acceptation dérivés du récit du use case

Les deux premières pratiques opèrent au niveau produit. Elles fournissent une direction stratégique en cartographiant le périmètre du système et en le décomposant en incréments livrables. Les quatre suivantes opèrent au niveau sprint, reflétant la manière dont Scrum sépare le raffinement du backlog de l’exécution du sprint.

Ce que cela signifie pour les business analystes

Pour les business analystes, Use Case 2.0 résout un dilemme persistant. Dans les projets traditionnels, on produisait des spécifications détaillées que les développeurs ignoraient parfois. Dans les projets agiles, on facilitait les conversations mais sans moyen structuré de garantir la complétude. Use Case 2.0 offre une voie médiane pragmatique.

Le modèle de use cases fournit le cadre analytique que les business analystes sont formés à construire. Il relie les acteurs aux objectifs, les objectifs aux flux d’interaction, les flux aux règles métier. Cette approche systématique aide à détecter des lacunes que les méthodes basées sur les stories manquent. Quand une équipe se repose uniquement sur les user stories, on oublie facilement les chemins alternatifs qui gèrent les exceptions, les cas limites et les conditions d’erreur. Les use cases, par leur structure, forcent la question: que pourrait-il se passer d’autre ici?

En même temps, le découpage garantit que l’analyse reste juste en avance sur l’implémentation. On ne passe pas des mois à rédiger des spécifications pour des fonctionnalités qui ne seront peut-être jamais construites. On élabore chaque slice peu avant son entrée dans le sprint, gardant la boucle de feedback courte et la documentation pertinente.

Où Use Case 2.0 s’impose

Tous les projets n’ont pas besoin de cette approche. Les petites équipes construisant des applications simples trouveront peut-être les user stories parfaitement suffisantes. Use Case 2.0 montre sa valeur dans des contextes spécifiques: systèmes à logique métier complexe, environnements réglementés exigeant la traçabilité, projets à grande échelle où plusieurs équipes doivent coordonner leur travail et organisations en transition du traditionnel vers l’agile.

Pour les équipes déjà à l’aise avec les use cases, la transition est naturelle. La méthodologie ne demande pas d’abandonner la pratique existante. Elle demande de la découper différemment.