User story : définition, format et bonnes pratiques

Derrière la phrase « En tant que client, je veux pouvoir filtrer les produits par prix afin de rester dans mon budget » se cache le point de départ d'une conversation entre celles et ceux qui conçoivent, développent et testent de nouvelles fonctionnalités.

Mais la simplicité du format peut être trompeuse. Sans en comprendre l'intention, certaines équipes se retrouvent avec des user stories qui ressemblent davantage à des tickets techniques qu'à de véritables conversations sur la valeur à livrer.

Découvrez dans cet article ce qu'une user story recouvre vraiment, et comment en rédiger une que votre équipe pourra livrer sans ambiguïté ni allers-retours inutiles.

→ Commencez un essai gratuit de GitLab Ultimate.

Qu'est-ce qu'une user story ?

Une user story (ou récit utilisateur) est une description simple et concise d'un besoin, rédigée du point de vue de l'utilisateur final ; en une phrase, elle dit qui a besoin de quoi, et pourquoi.

Le concept de user story apparaît à la fin des années 1990 avec l'Extreme Programming, méthodologie initiée par Kent Beck, qui l'introduit sous forme de fiches libres sans gabarit imposé. C'est une équipe britannique, chez Connextra, qui formalise au début des années 2000 le format « En tant que… je veux… afin de… » aujourd'hui le plus répandu. Ce format sera ensuite largement popularisé par Mike Cohn, notamment via son ouvrage de référence User Stories Applied (2004), et adopté par les équipes Agile, en particulier celles pratiquant Scrum.

La user story décrit le quoi et laisse de côté le comment. En posant le besoin et la valeur attendue sans dicter la solution, elle rend à l'équipe de développement la liberté de choisir son implémentation. C'est ce qui la distingue fondamentalement d'un cahier des charges : là où l'un fige les décisions avant même que la conversation commence, l'autre les suspend intentionnellement, pour mieux les nourrir au fil des échanges.

Comment structurer une user story ?

Pour structurer une user story, le gabarit le plus répandu est celui formalisé par l'équipe britannique Connextra au tout début des années 2000 : En tant que [rôle], je veux [action], afin de [bénéfice]. Le rôle situe l'utilisateur, l'action indique ce qu'il cherche à faire, et le bénéfice, le fameux pourquoi, donne tout son sens à la phrase.

La dernière partie « afin de » est pourtant celle que l'on néglige le plus souvent, alors qu'elle porte l'essentiel de la valeur de la user story. Comparez « En tant qu'utilisateur, je veux un bouton d'export » et « En tant que comptable, je veux exporter mes écritures en CSV afin de les importer dans mon logiciel de compta sans ressaisie » : la seconde explique à l'équipe pourquoi la fonctionnalité existe, ce qui lui laisse la marge de proposer une meilleure solution si elle en voit une.

Ron Jeffries a résumé l'idée en trois C :

• la carte porte la phrase, forcément brève ;
• la conversation rassemble les échanges qui affinent le besoin ;
• la confirmation réunit les critères d'acceptation qui permettront de vérifier que le besoin est bien satisfait.

La carte n'a de valeur que si elle déclenche une conversation qui transforme un besoin écrit en solution partagée. Une user story qui ne génère aucun échange n'a rempli qu'une partie de son rôle.

Comment la user story s'intègre-t-elle dans le travail des équipes ?

Pour bien utiliser une user story, il faut d'abord comprendre où elle se situe : entre l'objectif stratégique que porte l'epic et le détail d'implémentation que décrit la tâche.

Ne pas confondre epic, user story et tâche

Au sommet de cette hiérarchie se trouve l'epic, un objectif large qui regroupe plusieurs user stories poursuivant le même but, comme « permettre à un visiteur de créer un compte ». La user story en extrait une portion concrète et livrable, par exemple « saisir mon adresse e-mail et un mot de passe afin de créer mon compte », tandis que la tâche descend au niveau de l'implémentation pure, sans utilisateur ni valeur propre, comme « valider le format de l'e-mail côté serveur ».

Chaque niveau obéit à sa propre échelle de temps. Les repères varient selon les équipes : le tutoriel Scrum de GitLab retient une itération pour l'epic, quelques jours pour la user story et quelques heures à une journée pour la tâche. D'autres organisations font courir leurs epics sur plusieurs itérations ; l'essentiel est que l'équipe partage la même convention.

La place de la user story dans le backlog

Dans un projet mené en développement Agile, toutes ces user stories viennent nourrir le backlog produit, la liste priorisée des besoins en attente de livraison. Le responsable produit les classe selon la valeur qu'elles apportent et les contraintes du projet, et l'équipe sélectionne les plus prioritaires au moment de planifier son sprint.

Qu'est-ce qui fait une bonne user story ?

Une user story bien écrite se reconnaît à quelques critères vérifiables dès la rédaction, bien avant la moindre ligne de code. On les résume souvent par l'acronyme INVEST, formalisé par Bill Wake en 2003.

Les six qualités résumées par la méthode INVEST

• Independent (indépendante) : elle peut être développée sans attendre une autre user story. À noter : cette indépendance s'entend au niveau métier, et non au niveau technique, où des dépendances restent normales.
• Negotiable (négociable) : elle peut évoluer jusqu'au moment où l'équipe s'engage à la développer.
• Valuable (porteuse de valeur) : elle apporte un bénéfice concret pour l'utilisateur ou le métier.
• Estimable (chiffrable) : l'équipe peut évaluer la complexité et l'effort qu'elle représente, le plus souvent en points de complexité (les story points).
• Small (petite) : elle représente au plus quelques jours de travail.
• Testable (testable) : des critères d'acceptation permettent de vérifier, sans ambiguïté, que le besoin est bien satisfait.

Critères d'acceptation : transformer le besoin en condition vérifiable

Les critères d'acceptation décrivent les conditions précises qui valident une user story. Ils sont souvent écrits au format « Étant donné / Lorsque / Alors », issu du Behaviour-Driven Development (BDD) de Dan North et formalisé par la syntaxe Gherkin : « Étant donné [contexte], lorsque [action], alors [résultat attendu] », mais une liste de conditions simples est tout aussi valable.

Pour la user story du filtre par prix, l'un des critères d'acceptation serait le suivant : « Étant donné une liste de produits, lorsque je fixe un prix maximum, alors seuls les articles dont le prix est inférieur ou égal à ce maximum s'affichent. »

Certaines équipes négligent pourtant ce maillon et de nombreuses user stories arrivent en développement sans le moindre critère d'acceptation. La user story reste alors ambiguë, chacun interprète le résultat attendu à sa façon, et les allers-retours coûteux s'enchaînent en fin de sprint. Quelques critères bien formulés, généralement entre trois et cinq, suffisent à aligner l'équipe sur le résultat attendu.

Comment rédiger une user story ?

Écrire une bonne user story obéit toujours à la même logique, quel que soit le produit.

1. Identifiez l'utilisateur réel via un persona précis, pour permettre une meilleure projection.
2. Cernez son objectif, ce qu'il cherche à accomplir dans son contexte.
3. Formulez le bénéfice, le fameux « afin de », en vous demandant pourquoi cet objectif compte pour lui.
4. Rédigez votre user story selon le gabarit, dans un langage simple, en vous abstenant de toute prescription technique.
5. Définissez les critères d'acceptation qui établiront les conditions de validation de la user story.

Appliquée à une application bancaire, cela donne : « En tant que titulaire d'un compte, je veux réinitialiser mon mot de passe oublié afin de retrouver l'accès à mon espace sans appeler le support. »

Le rôle est clairement identifié, l'action ne prête pas à confusion et le bénéfice est concret, si bien que les critères d'acceptation en découlent naturellement : réception d'un lien par e-mail, expiration après un délai défini, conformité du mot de passe à la politique de sécurité. Bien formulée, elle facilite le développement et les tests, sans ralentir le reste du sprint.

Quelles sont les erreurs à éviter ?

La première erreur consiste à maquiller une tâche technique en user story. « En tant qu'utilisateur, je veux une base PostgreSQL avec une table indexée sur le titre » exprime un besoin d'implémentation et non un besoin utilisateur. Dès que le « en tant que » dissimule un rôle technique et que le « afin de » renvoie à une décision d'implémentation, la user story perd tout ancrage utilisateur.

La deuxième erreur fréquente est la user story trop volumineuse. Dès qu'une user story devient difficile à estimer ou impossible à terminer dans le sprint, c'est souvent le signe qu'elle en contient plusieurs.

Pour la découper, pensez au découpage vertical (le vertical slicing) : plutôt que de diviser le travail par couche technique (le back-end d'un côté et le front-end de l'autre), suivez le parcours de l'utilisateur et extrayez des tranches fonctionnelles autonomes, chacune testable et vérifiable indépendamment. La création de compte illustre bien cette logique avec trois user stories distinctes : saisie de l'e-mail, choix du mot de passe, puis validation finale.

Comme repère de dimensionnement, le tutoriel Scrum de GitLab suggère qu'une équipe puisse terminer environ quatre à dix user stories par sprint, chaque user story étant suffisamment petite pour être réalisée par une personne en un ou deux jours. Si votre équipe en termine nettement moins, vos user stories sont peut-être trop volumineuses, ou nécessitent encore d'être clarifiées ou découpées. Si elle en termine beaucoup plus, vérifiez qu'elles apportent toujours une valeur utilisateur propre et qu'elles ne sont pas devenues de simples étapes techniques.

Deux dernières erreurs viennent compléter ce tableau : le « afin de » survolé ou omis, qui prive l'équipe du pourquoi, et l'absence de critères d'acceptation, déjà évoquée plus haut. Aucune de ces erreurs n'est en soi rédhibitoire, mais leur accumulation transforme un backlog en liste de tâches opaques impossible à prioriser ou à estimer.

Comment intégrer une user story dans un outil de planification ?

Là où un post-it suffit à porter une user story sur un tableau physique, un outil de planification Agile lui confère une existence structurée. Elle devient un objet que l'on peut prioriser, estimer et suivre jusqu'en production.

Dans GitLab, il n'existe pas d'objet « user story » dédié. Une user story y prend la forme d'un ticket, rédigé selon le gabarit classique ou selon un format alternatif : la job story. Ce ticket peut tout aussi bien porter sur un bogue ou une tâche, et c'est à chaque équipe de définir ses propres conventions. Notre tutoriel Scrum propose par exemple de les distinguer par des labels à portée (type::story, type::bug, type::maintenance).

Formalisée par Alan Klement, la job story met l'accent sur la situation vécue plutôt que sur le profil de l'utilisateur : « Quand je découvre une nouvelle application, je veux créer un compte rapidement afin de pouvoir l'utiliser sans délai. » Partir d'une situation concrète plutôt que d'un rôle générique permet souvent de mieux cerner la motivation réelle de l'utilisateur et d'affiner la valeur attendue. C'est d'ailleurs ce format que privilégie notre tutoriel « Utilisez GitLab pour faciliter la mise en œuvre de Scrum ».

GitLab structure cet environnement autour de plusieurs fonctionnalités complémentaires : les epics qui regroupent les tickets relevant d'un même objectif, le champ de poids qui quantifie l'effort estimé en tenant lieu de story points, les itérations qui structurent les sprints, et les tableaux de tickets qui permettent de faire progresser chaque ticket de « prêt pour le développement » jusqu'au statut « terminé ». À noter que certaines fonctionnalités relèvent des offres GitLab Premium et GitLab Ultimate.

À noter : l'activation du report automatique transfère tout ticket non clôturé vers l'itération suivante à la fin du sprint, évitant ainsi qu'une user story ne soit perdue en cours de route.

Chez GitLab, les équipes s'appuient sur ces récits utilisateurs pour maintenir une vision claire de l'impact réel des fonctionnalités qu'elles priorisent. Centraliser la planification, le développement et le suivi de projets au sein d'un environnement unifié libère les réunions d'équipe de la gestion d'un écosystème d'outils disparates et les recentre sur ce qui compte vraiment : la prise de décisions.

Retenir l'idée juste

Une user story est un récit centré sur l'utilisateur : elle formule un besoin et sa valeur, puis ouvre la conversation dont naîtra une fonctionnalité. Le format « En tant que… je veux… afin de… » aide à formuler un besoin, les critères INVEST à en vérifier la qualité, et les critères d'acceptation à définir les conditions de réussite. Le reste s'apprend en écrivant, en découpant les user stories trop volumineuses, et en maintenant le dialogue avec les parties prenantes.

Quand votre équipe sera prête à passer du post-it au backlog outillé, une bonne méthodologie Agile et une plateforme comme GitLab, qui réunit planification, développement et livraison en un seul endroit, vous accompagneront à chaque étape.

→ Commencez un essai gratuit de GitLab Ultimate.

FAQ sur la user story

Qui écrit les user stories ?

Les user stories sont généralement écrites par le responsable produit (Product Owner), car il est le mieux placé pour connaître la valeur attendue et la priorité des besoins. Mais une bonne user story se construit collectivement : les développeurs et les testeurs l'enrichissent lors des sessions de « backlog refinement » (affinage du backlog), et rien n'interdit à un membre de l'équipe de proposer une user story.

Quelle différence entre une user story et un cas d'utilisation ?

Un cas d'utilisation (use case) décrit en détail toutes les interactions entre l'utilisateur et le système, y compris les cas d'erreur, dans un document détaillé. La user story reste volontairement brève et centrée sur un besoin et sa valeur, et confie le reste à la conversation et aux critères d'acceptation.

Combien de critères d'acceptation faut-il par user story ?

Il n'y a pas de règle absolue, mais trois à cinq critères suffisent le plus souvent à lever les ambiguïtés. Si vous en alignez dix, la user story est probablement trop volumineuse et gagnerait à être scindée.

Une user story doit-elle tenir dans un seul sprint ?

Oui, et même largement en deçà : le critère « Small » d'INVEST parle de quelques jours de travail. Une user story qui dépasse le cadre du sprint doit être scindée en user stories plus restreintes, chacune livrant une part de valeur.