Quand vient le moment de formaliser ce qu’un projet doit livrer, deux techniques dominent la conversation: les user stories et les cas d’utilisation. La première est souvent associée aux méthodes agiles, la seconde aux approches plus traditionnelles. Cette opposition est trompeuse, car les deux techniques répondent à des besoins différents et le choix dépend avant tout du contexte du projet.
Deux outils, deux logiques
Une user story est une phrase courte qui exprime un besoin du point de vue de l’utilisateur, selon le format: “En tant que [rôle], je veux [fonctionnalité], afin de [bénéfice].” Par exemple: “En tant que responsable RH, je veux consulter le solde de congés d’un collaborateur afin de valider sa demande rapidement.” La force de ce format tient à sa concision: il ne décrit pas comment le besoin sera satisfait, il ouvre une conversation entre l’équipe et les parties prenantes (stakeholders). Les détails émergent au fil des échanges, pas du document lui-même.
Un cas d’utilisation (use case) décrit de façon structurée une interaction complète entre un acteur (une personne, un service, un système externe) et le produit ou le processus concerné. Il détaille le scénario nominal, c’est-à-dire le déroulement attendu quand tout se passe bien, ainsi que les scénarios alternatifs qui couvrent les exceptions et les cas limites. Pour reprendre l’exemple RH: le cas d’utilisation “Valider une demande de congé” préciserait les étapes depuis la réception de la demande jusqu’à la notification au collaborateur, en incluant les cas où le solde est insuffisant, où le manager est absent ou où la période demandée chevauche un pic d’activité.
Quand la user story suffit
Les user stories fonctionnent remarquablement bien lorsque l’équipe est petite, en contact régulier avec les utilisateurs ou leurs représentants, et capable de clarifier les détails au fil de l’eau. La conversation que la story provoque compense largement ce qu’elle ne formalise pas.
C’est le quotidien d’une équipe qui organise un événement d’entreprise, par exemple. “En tant que participant, je veux recevoir un plan d’accès personnalisé afin de trouver facilement le lieu.” L’équipe logistique sait immédiatement ce que cela implique, pose deux ou trois questions et met en place la solution. Formaliser un cas d’utilisation complet serait disproportionné.
Quand le cas d’utilisation devient nécessaire
La donne change quand le projet implique plusieurs équipes, des processus réglementés ou des interactions complexes entre différents acteurs. Dans ces situations, la brièveté de la user story devient un handicap: elle laisse trop de place à l’interprétation et les malentendus se découvrent tard, au moment le plus coûteux.
Prenons l’inscription à une formation en ligne. En user story, cela pourrait se résumer à: “En tant que participant, je veux m’inscrire à une formation afin de réserver ma place.” La phrase est claire, mais elle ne dit rien de ce qui se passe quand la session est complète, quand le paiement échoue, quand le participant souhaite changer de date après inscription ou quand une entreprise demande une facturation groupée pour plusieurs collaborateurs. Chacune de ces situations exige un traitement spécifique, et c’est précisément ce qu’un cas d’utilisation “S’inscrire à une formation” permet de cartographier: le scénario nominal, les embranchements, les règles métier qui s’appliquent à chaque cas de figure. La granularité de la description fait apparaitre des questions que la user story, par conception, ne pose pas.
Dans les secteurs réglementés (santé, finance, administration publique), les cas d’utilisation remplissent une fonction supplémentaire: ils constituent une trace documentée des exigences, souvent exigée par les audits de conformité.
Un faux dilemme, mais pas un choix anodin
L’idée qu’il faudrait choisir un camp repose sur un malentendu. Le Scrum Guide ne prescrit aucune technique particulière pour exprimer les éléments du Product Backlog. Le BABOK (Business Analysis Body of Knowledge), référentiel international en analyse métier, présente user stories et cas d’utilisation comme des techniques complémentaires, pas concurrentes. Le guide de pratique agile du PMI va dans le même sens.
Ivar Jacobson, l’inventeur même des cas d’utilisation dans les années 1990, a d’ailleurs publié Use Case 2.0, une version allégée et découpable en “slices” conçue explicitement pour les contextes agiles. C’est une preuve concrète que les cas d’utilisation ne sont pas figés dans une ère révolue: ils s’adaptent aux pratiques itératives quand on accepte de les faire évoluer.
Cela dit, la complémentarité des deux techniques ne signifie pas que le choix soit sans conséquence. En pratique, de nombreux projets combinent les deux avec profit: les user stories servent à alimenter le backlog et à prioriser le travail à court terme, tandis que les cas d’utilisation documentent les processus critiques qui nécessitent une compréhension partagée et détaillée. Cette cohabitation reflète simplement le fait qu’un projet a des besoins de communication variés selon les sujets et les interlocuteurs. Le vrai risque n’est pas de mélanger les formats, c’est de s’enfermer dans un seul par dogme méthodologique et de découvrir trop tard que la technique choisie ne portait pas assez de contexte pour les décisions à prendre.
Ce qui détermine le bon choix, c’est le niveau de complexité des interactions à décrire, le degré de proximité entre l’équipe et les utilisateurs et les exigences de traçabilité du projet. Quand l’équipe peut échanger quotidiennement avec les parties prenantes et que les interactions sont simples, les user stories sont efficaces et suffisantes. Quand les acteurs se multiplient, que les scénarios s’embranchent et que la documentation doit résister à un audit, le cas d’utilisation apporte une rigueur que la user story n’a pas vocation à fournir.