La user story : définition, format et exemples

Qu'est-ce qu'une user story ?

Une user story (récit utilisateur) est une courte description d'un besoin, exprimée du point de vue de l'utilisateur, généralement au format « En tant que [rôle], je veux [action] afin de [bénéfice] ». C'est l'unité de travail de base d'un backlog agile. Elle décrit un besoin à satisfaire, pas une solution technique, et sert de point de départ à une conversation entre l'équipe et le product owner.

La user story est née d'une idée simple mais puissante : on ne construit pas un logiciel pour cocher des fonctionnalités, on le construit pour rendre service à des gens. Plutôt que d'écrire une spécification qui dit « le système doit permettre l'export CSV », on écrit « En tant que comptable, je veux exporter mes écritures en CSV afin de les importer dans mon logiciel de compta ». La différence n'est pas cosmétique : la seconde formulation dit qui a le besoin et pourquoi, ce qui change complètement la façon de le traiter.

Une user story n'est pas un contrat détaillé, c'est une promesse de conversation. Elle tient volontairement en une phrase, souvent écrite sur une carte ou une ligne d'outil. Le détail vient plus tard, à l'oral, quand l'équipe s'apprête à la réaliser. Cette légèreté est un choix : elle évite de figer trop tôt une solution et laisse la place à l'expertise de ceux qui vont construire. La user story est l'un des éléments les plus courants d'un product backlog, aux côtés des correctifs de bugs et de la dette technique.

Le format d'une user story : En tant que… je veux… afin de…

Le format standard d'une user story tient en trois parties : « En tant que [rôle], je veux [action] afin de [bénéfice] ». Le rôle indique qui a le besoin, l'action décrit ce que la personne veut faire, et le bénéfice explique pourquoi. Cette structure relie chaque fonctionnalité à un utilisateur réel et à une valeur, ce qui évite de construire des choses inutiles.

Cette trame en trois temps, parfois appelée « template Connextra », est devenue le standard de fait. Chaque partie joue un rôle précis :

• En tant que [rôle] : la personne ou le type d'utilisateur concerné. « Utilisateur » est trop vague ; préférez un rôle précis (client, administrateur, visiteur non connecté), car un besoin dépend toujours de qui l'exprime.
• Je veux [action] : l'objectif fonctionnel, décrit en langage métier et non technique. On dit ce que l'utilisateur veut accomplir, pas comment le code doit s'y prendre.
• Afin de [bénéfice] : la valeur recherchée, la raison d'être de la story. C'est de loin la partie la plus importante et la plus souvent bâclée : sans le « afin de », on ne peut ni prioriser correctement, ni vérifier qu'on a résolu le bon problème.

D'après mon expérience, le meilleur test d'une bonne user story se cache dans le « afin de ». Si le bénéfice est une évidence creuse du type « afin d'utiliser la fonctionnalité », c'est le signal que personne n'a réfléchi au vrai besoin. Une story dont le bénéfice ne tient pas debout est une story qu'il faut sans doute écarter, pas développer.

Les critères d'acceptation d'une user story

Les critères d'acceptation sont les conditions concrètes qui permettent de dire qu'une user story est terminée et fonctionne comme prévu. Ils transforment un besoin exprimé en résultat vérifiable. On les rédige sous forme de liste de conditions ou au format Gherkin « Étant donné… quand… alors… ». Sans eux, une story reste ambiguë au moment de la recette.

Une user story sans critères d'acceptation, c'est une porte ouverte aux malentendus. Le rôle, l'action et le bénéfice disent quoi et pourquoi ; les critères d'acceptation disent à quoi on reconnaîtra que c'est fait. Reprenons l'exemple du rachat de commande :

• Le client connecté voit la liste de ses commandes passées, de la plus récente à la plus ancienne.
• Chaque commande affiche sa date, son montant et son statut.
• Un bouton « Racheter » ajoute au panier les produits encore disponibles.
• Si un produit n'est plus en stock, un message clair l'indique et n'ajoute que les autres.

Ces critères peuvent aussi s'écrire au format Gherkin, très utilisé pour les tests : « Étant donné un client connecté ayant déjà commandé, quand il clique sur Racheter, alors les produits disponibles sont ajoutés à son panier. » Peu importe la forme retenue ; ce qui compte, c'est que chaque critère soit vérifiable objectivement. Les critères d'acceptation ne doivent pas être confondus avec la définition de terminé (definition of done), qui s'applique elle à toutes les stories : tests écrits, code relu, documentation à jour. Les critères sont spécifiques à une story, la définition de terminé est une règle générale d'équipe.

Des exemples concrets de user stories

Une bonne user story se reconnaît à sa clarté : un rôle précis, une action en langage métier, un bénéfice réel. Voici plusieurs exemples de user stories, du site e-commerce à l'application interne, pour illustrer le format et montrer la différence entre une story bien écrite et une story creuse.

Rien ne vaut des exemples pour ancrer le format. En voici quelques-uns, issus de contextes variés :

Ces stories partagent trois qualités : un rôle identifiable, une action que l'on peut se représenter, et un bénéfice qui justifie l'effort. Comparez avec une story faible du type « En tant qu'utilisateur, je veux une page de paramètres afin d'avoir des paramètres » : le rôle est générique, l'action est une solution déguisée en besoin, et le bénéfice tourne en rond. Devant ce genre de formulation, je pose toujours la même question : quel problème concret l'utilisateur cherche-t-il à résoudre ? La réponse fait souvent apparaître deux ou trois vraies stories cachées derrière une fausse.

Ce qui fait une bonne user story : la méthode INVEST

INVEST est un acronyme qui liste les six qualités d'une bonne user story : Independent (indépendante), Negotiable (négociable), Valuable (porteuse de valeur), Estimable (estimable), Small (petite) et Testable (vérifiable). C'est une grille de contrôle rapide pour savoir si une story est prête à entrer dans un sprint ou s'il faut encore la retravailler.

Écrire une story au bon format ne suffit pas : encore faut-il qu'elle soit exploitable. Le mémo INVEST, proposé par Bill Wake, résume les six critères d'une story saine :

• Independent (indépendante) : réalisable sans dépendre d'une autre story, pour pouvoir la prioriser et la livrer seule.
• Negotiable (négociable) : elle ouvre une discussion, elle n'est pas un contrat gravé dans le marbre. Le détail se négocie avec l'équipe.
• Valuable (porteuse de valeur) : elle apporte un bénéfice tangible à un utilisateur ou au métier. C'est le rôle du « afin de ».
• Estimable : l'équipe peut évaluer l'effort qu'elle représente. Si c'est impossible, c'est qu'elle est trop floue ou trop grosse.
• Small (petite) : elle tient dans un seul sprint. Trop grosse, on la découpe.
• Testable : on peut vérifier qu'elle est terminée grâce à ses critères d'acceptation. Une story qu'on ne sait pas tester n'est pas prête.

INVEST n'est pas une norme à appliquer à la lettre, c'est une checklist de bon sens. Sur mes projets, je m'en sers surtout comme d'un déclencheur d'alerte : dès qu'une story échoue sur l'un des critères, en particulier « Small » ou « Testable », je sais qu'elle n'est pas prête et qu'il faut la retravailler avant de l'engager dans un sprint.

User story, epic et tâche : les différences

Une epic (épopée) est un besoin large qui ne tient pas dans un sprint et que l'on découpe en plusieurs user stories plus petites. Chaque user story est ensuite décomposée en tâches techniques par l'équipe de développement. On va donc du plus grand au plus petit : epic, puis user story, puis tâche. Cette granularité est ce qui rend un backlog exploitable.

Ces trois niveaux répondent chacun à un besoin de pilotage différent. L'epic sert à regrouper : « Gérer son compte client » est une épopée qui peut contenir dix stories (se connecter, modifier son mot de passe, consulter ses commandes, etc.). On ne la développe jamais telle quelle ; elle donne une vision d'ensemble et structure le haut du backlog. La user story est l'unité que l'on estime et que l'on livre : assez petite pour tenir dans un sprint, assez porteuse de sens pour délivrer de la valeur. La tâche, enfin, est la décomposition technique interne à l'équipe : créer l'endpoint, écrire le test, intégrer l'écran. Une tâche n'a pas de valeur utilisateur en soi, c'est un moyen.

Bien découper est un art qui s'apprend : c'est le cœur du travail de raffinement du backlog. Une epic mal découpée donne des stories trop grosses qui débordent des sprints ; des stories trop finement coupées noient l'équipe dans une liste illisible. Pour approfondir la manière dont ces éléments s'organisent et se priorisent, je détaille tout cela dans mon guide sur le product backlog.

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des projets et des refontes en agile pour des grands comptes et des PME (TF1, SFR, Orange, SNCF), en faisant le lien entre les équipes techniques et la direction. Découvrir son approche.