Une technique de 1987 face aux méthodes agiles
Quand Ivar Jacobson a présenté les cas d’utilisation (use cases) à la conférence OOPSLA en 1987, il les définissait comme “une séquence particulière de transactions, effectuée par un utilisateur et un système en dialogue”. Cette technique de description des interactions entre acteurs et systèmes a dominé l’ingénierie des exigences pendant plus de deux décennies. En 2013, 73% des entreprises interrogées dans une étude allemande les utilisaient encore, et 51% en Suisse selon une enquête SwissQ.
Les méthodes agiles ont profondément modifié cette dynamique. En 2001, Ron Jeffries a formulé la formule 3C (Card, Conversation, Confirmation) pour structurer les user stories: une description tenant sur une carte, clarifiée par le dialogue, validée par des critères d’acceptation. Les user stories étaient légères, conversationnelles, calibrées pour des itérations courtes. Les cas d’utilisation, avec leur documentation détaillée et leurs multiples scénarios, paraissaient appartenir à un autre paradigme.
Le vrai problème: la granularité, pas la technique
L’opposition entre user stories et cas d’utilisation est en partie un malentendu. Le problème des cas d’utilisation dans un contexte agile n’est pas leur approche (décrire le comportement du système du point de vue de l’utilisateur), qui reste pertinente quelle que soit la méthodologie. Le problème est leur granularité.
Un cas d’utilisation typique couvre un objectif complet: “Traiter une réclamation client”, “Gérer une commande fournisseur”. Cet objectif inclut le scénario nominal, les variantes et les exceptions, soit un volume de travail qui dépasse largement ce qu’un sprint de deux à trois semaines peut absorber. Convertir ce cas d’utilisation en user stories est possible, mais cela revient à traduire d’une langue vers une autre: on perd des nuances, on fragmente la cohérence, et on dépense de l’énergie sur la traduction plutôt que sur l’analyse.
Use Case 2.0: découper sans convertir
C’est exactement le problème qu’Ivar Jacobson a voulu résoudre avec Use Case 2.0, publié en 2011 avec Ian Spence et Kurt Bittner. La proposition est pragmatique: au lieu de convertir les cas d’utilisation en autre chose, on les découpe en Use Case Slices (tranches de cas d’utilisation).
Chaque slice isole un chemin spécifique à travers le cas d’utilisation. Le scénario principal devient le premier slice, puis chaque variante ou exception significative forme un slice supplémentaire. Un slice est suffisamment ciblé pour être développé, testé et livré dans un sprint, tout en restant rattaché au cas d’utilisation parent qui fournit le contexte global.
La différence avec un simple découpage en tâches est fondamentale: chaque slice livre une valeur fonctionnelle vérifiable. Ce n’est pas “coder l’interface” puis “coder la logique métier”, mais “permettre le traitement nominal d’une réclamation” puis “gérer le cas d’une réclamation avec pièces jointes manquantes”.
Ce qui a changé entre la version classique et la 2.0
Use Case 2.0 ne se contente pas d’ajouter le concept de slices aux cas d’utilisation traditionnels. La technique repose sur six principes qui marquent une rupture avec la pratique antérieure.
Le premier est la simplicité: Use Case 2.0 préconise des descriptions légères, pas des documents de spécification exhaustifs. Le deuxième exige de comprendre le contexte global (le “big picture”) avant de commencer le découpage, ce qui évite de créer des slices déconnectés. Le troisième impose de prioriser par la valeur métier, c’est-à-dire de développer d’abord le slice qui apporte le plus à l’utilisateur. Les trois derniers principes concernent la construction incrémentale, la livraison par incréments fonctionnels et l’adaptation au contexte spécifique de l’équipe.
En pratique, un cas d’utilisation Use Case 2.0 ressemble davantage à un récit structuré qu’à une spécification formelle. Il reste suffisamment détaillé pour préserver la traçabilité des exigences, mais suffisamment léger pour ne pas ralentir l’équipe.
Ce que cela change pour le chef de projet
Pour un chef de projet habitué aux user stories, les Use Case Slices offrent un avantage spécifique: la traçabilité native. Chaque slice sait d’où il vient (quel cas d’utilisation), ce qu’il couvre (quel scénario) et ce qui reste à faire (les slices non encore réalisés). Cette vision consolidée est particulièrement précieuse dans les projets où les parties prenantes exigent une visibilité sur la couverture fonctionnelle, comme les projets réglementés ou les systèmes critiques.
Pour les projets plus simples ou les équipes déjà rodées aux user stories, le passage à Use Case 2.0 n’est pas nécessairement pertinent. La technique prend tout son sens quand la complexité des interactions fonctionnelles dépasse ce que des user stories indépendantes peuvent structurer efficacement.