User story

Une user story (« histoire utilisateur ») est la description courte d’un besoin, écrite du point de vue de la personne qui l’exprime. Son format tient en une phrase : « En tant que [rôle], je veux [action], afin de [bénéfice] ». C’est l’unité de travail de référence des méthodes agiles, celle qui remplit le backlog et alimente chaque sprint.

Son intérêt n’est pas le gabarit de phrase. C’est le déplacement qu’il impose. Au lieu d’écrire « ajouter un bouton d’export », on écrit « les commerciaux veulent récupérer leurs contacts pour les charger dans leur CRM ». La première formulation prescrit une solution. La seconde décrit un problème et laisse l’équipe chercher la meilleure réponse, qui n’est pas toujours celle qu’on avait en tête au départ.

Une invention de l’Extreme Programming, pas de Scrum

La confusion est tenace et elle a des conséquences pratiques. Les user stories viennent de l’Extreme Programming, la méthode formalisée par Kent Beck à la fin des années 1990. Le Guide Scrum, lui, n’a jamais prescrit ce format : il parle d’éléments du backlog produit et laisse chaque équipe décider comment les écrire.

Pourquoi est-ce que ça compte ? Parce qu’une équipe persuadée de devoir tout écrire en user story finit par produire des phrases absurdes du type « en tant que développeur, je veux migrer la base de données, afin de migrer la base de données ». Une migration technique, un correctif de sécurité ou une mise en conformité sont des éléments de backlog parfaitement légitimes. Ils n’ont pas besoin d’être déguisés en besoin utilisateur. Le format sert quand il y a un utilisateur et un bénéfice à expliciter. Le reste du temps, il gêne.

La carte, la conversation, la confirmation

Ron Jeffries, un des auteurs de l’Extreme Programming, résume une user story en trois C : Card, Conversation, Confirmation. Les équipes qui n’en retiennent que le premier passent à côté de l’essentiel.

La carte : la phrase

Le rôle dit qui a le besoin. L’action dit ce que cette personne cherche à faire. Le bénéfice dit pourquoi. C’est ce troisième élément qu’on bâcle le plus souvent, alors que c’est lui qui pilote les choix de conception.

Prenons un exemple : « En tant que commercial, je veux exporter mes contacts en CSV, afin de les importer dans mon CRM. » Sans le bénéfice, l’équipe livre un export générique. Avec, elle peut proposer une synchronisation directe avec les CRM les plus répandus, ce qui règle le vrai problème et supprime deux manipulations.

La carte est volontairement courte. Elle tenait historiquement sur une fiche bristol, et cette contrainte physique avait un but : empêcher qu’on la transforme en cahier des charges.

La conversation

Une story n’est pas une spécification qu’on transmet, c’est une promesse de discussion. Le Product Owner porte le besoin, les développeurs posent les questions techniques, le designer soulève les cas limites. Cet échange a lieu avant le développement, pendant l’affinage du backlog ou au sprint planning.

Une story envoyée à un développeur comme un bon de commande perd l’essentiel de sa valeur. Ce n’est plus de l’agilité, c’est du cycle en V avec un vocabulaire à la mode.

La confirmation : les critères d’acceptation

Les critères d’acceptation disent à quelles conditions la story est terminée. Ils transforment une intention en engagement vérifiable : le fichier contient les colonnes nom, e-mail et téléphone ; l’export fonctionne au-delà de dix mille contacts ; l’utilisateur reçoit une notification quand le fichier est prêt.

Beaucoup d’équipes les écrivent en Given/When/Then, la syntaxe issue du behaviour-driven development : « Étant donné un carnet de 12 000 contacts, quand l’utilisateur lance un export, alors le fichier est disponible en moins de trente secondes. » L’avantage n’a rien de cosmétique : cette forme se traduit presque mot pour mot en tests automatisés. Un critère qu’on ne sait pas transformer en test est en général un critère mal écrit.

INVEST : six questions avant de lancer une story

Bill Wake a proposé en 2003 l’acronyme INVEST, resté la grille d’évaluation la plus utilisée.

• Independent. La story peut être développée seule, sans attendre qu’une autre soit finie. Sinon, l’ordre du backlog devient impossible à réorganiser.
• Negotiable. Le périmètre reste discutable jusqu’au dernier moment. Une story figée n’est plus une story.
• Valuable. Elle apporte quelque chose à un utilisateur ou au business. « Refactoriser le module X » est un travail légitime, mais ce n’est pas une user story.
• Estimable. L’équipe sait évaluer l’effort. Quand personne n’y arrive, le problème n’est pas l’estimation : la story est trop vague ou trop large.
• Small. Elle tient dans un sprint, idéalement en quelques jours. Au-delà, on découpe.
• Testable. Les critères d’acceptation permettent de trancher objectivement.

Ces six critères ne sont pas une checklist administrative à cocher en réunion. Dans la pratique, deux suffisent à repérer la grande majorité des stories problématiques : Small et Testable. Si une story passe ces deux-là, les quatre autres suivent presque toujours.

Épic, story, tâche : trois niveaux, trois horizons

L’épic est un objectif qui court sur plusieurs mois : « permettre la collaboration en temps réel dans l’éditeur ». Il se découpe en stories livrables en un ou deux sprints : voir le curseur des autres utilisateurs, éditer un document à plusieurs. Chaque story se découpe à son tour en tâches techniques : ouvrir le canal websocket, afficher les curseurs, tester avec dix sessions simultanées.

L’épic porte la vision et alimente la roadmap produit. La story porte la promesse de livraison. La tâche porte le travail. Mélanger les niveaux est la source de désordre la plus banale dans un backlog : une épic traitée comme une story déborde systématiquement, une tâche promue en story encombre la liste de lignes dont personne ne lit la valeur.

Pour découper, deux axes fonctionnent presque toujours : l’étape du parcours et la règle métier. Un objectif comme « améliorer l’onboarding » ne se planifie pas tel quel. Découpé en cinq stories (message de bienvenue personnalisé, guidage vers la première action utile, relance par e-mail à 24 heures, tutoriel interactif, mesure du taux de complétion), il devient un plan estimable. Nous détaillons cette mécanique dans notre guide sur l’onboarding SaaS qui convertit.

D’où viennent les bonnes stories

Pas d’une salle de réunion. Une équipe qui rédige ses stories à partir de ses seules hypothèses internes construit des fonctionnalités que personne n’ouvre. Celles qui tiennent sortent de la discovery produit : entretiens, observation du travail réel, lecture des données d’usage.

Le piège classique consiste à prendre au mot ce que les utilisateurs déclarent. Ils décrivent la solution qu’ils imaginent, rarement le problème qu’ils vivent. « Je veux pouvoir exporter en Excel » cache souvent « je n’arrive pas à rapprocher ces chiffres de ma compta », et ce n’est pas du tout la même story.

Ce que l’IA a changé à la rédaction des stories

Depuis que les assistants de code écrivent une part significative de l’implémentation, la qualité des critères d’acceptation pèse plus lourd qu’avant. Une story floue donnait autrefois du code approximatif qu’un développeur corrigeait au fil de l’eau. Elle produit désormais du code plausible, abondant et faux, en quelques minutes.

C’est toute la logique du spec-driven development, où la spécification devient la source de vérité et le code un artefact généré. Dans ce cadre, une story assortie de critères en Given/When/Then n’est plus seulement un support de discussion : c’est l’entrée de la chaîne de génération. Une précaution s’impose, et nous l’avons apprise à nos dépens : un agent peut très bien cocher un critère d’acceptation sans avoir écrit le test correspondant. Chaque critère doit se matérialiser en test exécutable, et un humain doit vérifier que ce test existe vraiment.

Les erreurs fréquentes

Des critères invérifiables. « L’interface doit être claire » est un souhait. « L’utilisateur termine le formulaire sans aide lors d’un test d’utilisabilité » est un critère.

Une story qui ne rentre pas dans un sprint. C’est une épic déguisée. On la découpe, on n’espère pas qu’elle rentre.

Le bénéfice absent. « En tant qu’admin, je veux un bouton de suppression » ne dit rien du problème à résoudre. Supprimer pour libérer de l’espace, pour corriger une saisie ou pour répondre à une demande RGPD conduit à des interfaces différentes.

Les besoins non fonctionnels oubliés. Performance, sécurité et accessibilité passent à la trappe parce qu’ils ne ressemblent pas à « un utilisateur qui veut quelque chose ». Pourtant « en tant qu’utilisateur malvoyant, je veux naviguer au lecteur d’écran » est une story valide, et souvent la plus critique du lot.

Un backlog transformé en bibliothèque. Des stories écrites six mois à l’avance vieillissent mal : le contexte bouge, les priorités aussi, et personne ne les relit avant de les redécouvrir périmées. Un backlog court et vivant vaut mieux qu’un inventaire exhaustif.

FAQ user story

Quelle différence entre une user story et une spécification fonctionnelle ?

La spécification décrit la solution en détail avant le développement et vise l’exhaustivité. La user story décrit le besoin et assume son incomplétude : le détail se construit dans la conversation entre le Product Owner et l’équipe. Une spécification se lit, une story se discute. Les deux peuvent coexister sur un même projet, à condition de savoir laquelle fait foi.

Qui écrit les user stories ?

Le Product Owner en est responsable, mais l’écriture est rarement solitaire. Les meilleures stories sortent d’un atelier court où le PO apporte le besoin et le contexte, le designer les contraintes d’usage et les développeurs les questions techniques. Dans une startup, le fondateur tient souvent ce rôle, et c’est plutôt une bonne chose : personne ne connaît mieux le pourquoi.

Faut-il estimer chaque user story en story points ?

Non, aucun cadre ne l’impose. L’estimation sert à décider ce qui rentre dans un sprint, pas à produire un indicateur de performance. Beaucoup d’équipes comptent simplement le nombre de stories de taille comparable livrées par sprint et obtiennent une prévisibilité équivalente, pour beaucoup moins de cérémonie.

Comment Polara Studio écrit ses user stories

Chez Polara Studio, chaque story est rédigée avec le fondateur ou le responsable produit, jamais à sa place. Nous tenons deux règles.

La première : pas de story sans critères d’acceptation écrits, et pas de critère qu’on ne sait pas transformer en test. C’est ce qui nous permet de dire « terminé » sans ambiguïté, et c’est devenu indispensable depuis que l’IA produit une partie du code.

La seconde : toute story qui ne tient pas dans un sprint est découpée avant d’entrer en développement, sans exception. Les fondateurs trouvent parfois le découpage artificiel les premières semaines. Au troisième sprint, ils l’apprécient, parce qu’il devient possible de changer d’avis sur la suite sans jeter ce qui a déjà été livré.