User story : exemples rédigés et modèle de backlog à télécharger
Une user story est la description d’un besoin utilisateur en une phrase, de la forme « en tant que {rôle}, je veux {action}, afin de {bénéfice} », complétée par les critères vérifiables qui disent quand elle est terminée.
Page mise à jour le 12 septembre 2026. Modèle relu et remis à jour à chaque millésime.
Une user story tient en une phrase et décide pourtant de la moitié du budget d’un projet. Mal écrite, elle produit un écran que personne n’avait imaginé ainsi, et une facture d’avenant. Bien écrite, elle se teste, elle se chiffre et elle se livre. Voici vingt-quatre exemples rédigés pour une application mobile, avec leurs critères d’acceptation, et le tableur qui sert de backlog.
La forme d’une user story, et pourquoi cette forme
Le gabarit est connu : « en tant que client fidèle, je veux retrouver ma commande habituelle en un geste, afin de commander avant de sortir de chez moi ». Trois morceaux, trois fonctions. Le rôle dit à qui on s’adresse, ce qui évite de concevoir pour un utilisateur moyen qui n’existe pas. L’action dit ce que la personne veut obtenir. Le bénéfice dit pourquoi, et c’est ce troisième morceau qui permet d’arbitrer plus tard.
La partie « afin de » est celle que les équipes suppriment en premier, et c’est celle qui coûte le plus cher à perdre. C’est elle qui permet de dire, six mois après, qu’une fonctionnalité prévue ne sert plus l’objectif et peut sortir du lot. Sans bénéfice écrit, toutes les stories se valent, et le backlog devient une liste de courses que personne n’ose raccourcir.
Une user story décrit un résultat, pas une solution. « Je veux un bouton rouge en bas de l’écran » n’est pas une user story, c’est une décision de conception déguisée. La formulation correcte décrit ce que l’utilisateur cherche à obtenir, et laisse l’équipe proposer la meilleure façon d’y arriver. C’est la principale différence entre un backlog qui produit un bon produit et un backlog qui produit une maquette exécutable.
Le repère classique pour juger une story tient en six critères : elle est indépendante des autres autant que possible, négociable dans ses détails, porteuse de valeur pour l’utilisateur, estimable par l’équipe, assez petite pour tenir dans une itération, et vérifiable. Une story qui échoue sur « estimable » ou sur « vérifiable » n’est pas une story, c’est un sujet à creuser.
Les critères d’acceptation : là où le projet se gagne ou se perd
Une user story sans critères d’acceptation est une promesse orale. Les critères sont les conditions vérifiables qui permettent de dire, sans discussion, que le travail est terminé. Ils se rédigent avant le développement, pas après, et ils se rédigent avec la personne qui recettera.
La forme la plus lisible reste la plus simple : étant donné une situation de départ, lorsque l’utilisateur fait quelque chose, alors le système produit tel résultat. Une phrase par cas. Le fait de nommer la situation de départ oblige à penser aux états dans lesquels l’application peut se trouver, et c’est précisément là que se cachent les oublis.
- Le cas nominal, celui que tout le monde a en tête.
- Les cas limites : panier vide, créneau complet, boutique fermée, produit épuisé pendant la commande.
- Les cas d’erreur : réseau coupé, paiement refusé, session expirée, application mise en arrière-plan pendant l’opération.
- Les règles de gestion chiffrées : durée de validité d’un créneau, montant minimum, nombre maximum d’articles, délai avant retrait.
- Ce qui est explicitement hors sujet pour cette story, quand le risque de confusion existe.
Sur mobile, trois familles de cas reviennent systématiquement et sont systématiquement oubliées à la première rédaction. La perte de réseau en cours d’action, parce qu’un téléphone change de réseau en marchant. Le retour dans l’application après plusieurs heures en arrière-plan, avec une session peut-être expirée et des données peut-être périmées. Et le refus d’une permission système, notification ou localisation, qui doit laisser l’application utilisable au lieu de la bloquer.
Un raccourci utile pour juger la qualité d’un lot de stories avant de le confier à une agence : comptez le nombre de critères d’acceptation par story. En dessous de trois, il manque presque toujours les cas d’erreur. Au-dessus de dix, la story est trop grosse et doit être découpée.
Découper, estimer, ordonner
Une story trop grosse ne se chiffre pas. Le réflexe qui fonctionne est de découper par parcours utilisateur ou par règle de gestion, jamais par couche technique. « L’écran », « l’interface de programmation », « la base de données » ne sont pas trois stories : ce sont trois morceaux d’une même story, dont aucun ne livre de valeur seul. En revanche, « commander un produit unique », puis « commander plusieurs produits », puis « modifier une commande avant le retrait » sont trois stories qui se livrent et se testent séparément.
Pour l’estimation, l’unité importe moins que la constance. Beaucoup d’équipes utilisent des points relatifs plutôt que des jours, ce qui évite de confondre la complexité d’un travail et la disponibilité de la personne qui le fait. Le tableur proposé accepte les deux et calcule les totaux par priorité. Ce qui compte, c’est que la même échelle serve du début à la fin du projet.
L’ordre, enfin, ne se décide pas story par story. Il se décide par priorité, et la méthode la plus rapide à mettre en place est la grille en quatre niveaux, obligatoire, souhaitable, possible, exclu de ce lot. Elle fait l’objet d’une ressource dédiée, avec sa matrice et sa règle de plafond. Le backlog reprend simplement le résultat de cet arbitrage dans une colonne.
Le document
Les fichiers ci-dessous sont libres d’usage, y compris pour un projet commercial. Ils portent le nom du site en pied de page, rien d’autre : ni logo imposé, ni mention à conserver. Le formulaire plus haut sert à les recevoir par courriel, le téléchargement direct fonctionne sans rien laisser.
Un exemple rempli : le cas fictif Rondo
Les stories ci-dessous viennent du cas d’école fictif Rondo, une application inventée pour la démonstration : un réseau de soixante-deux boulangeries indépendantes qui propose la commande à l’avance et une fidélité dématérialisée. Le tableur à télécharger en contient vingt-quatre, avec leurs critères d’acceptation complets. En voici cinq, dans leur forme exacte.
- US-04 · Commande
- En tant que client pressé, je veux choisir un créneau de retrait, afin d’arriver quand ma commande est prête. Étant donné une boutique ouverte, lorsque je sélectionne un créneau de 15 minutes disponible, alors la commande est confirmée et le créneau est décompté. Étant donné un créneau devenu complet pendant ma saisie, lorsque je valide, alors l’application me propose les deux créneaux suivants sans perdre mon panier.
- US-07 · Commande
- En tant que client, je veux retrouver ma commande habituelle en un geste, afin de commander en moins de trente secondes. Étant donné au moins trois commandes passées à la même boutique, lorsque j’ouvre l’accueil, alors ma commande la plus fréquente est proposée en premier avec son montant. Étant donné un produit devenu indisponible, lorsque je reprends cette commande, alors il est signalé et retiré du panier avant paiement.
- US-11 · Fidélité
- En tant que client fidèle, je veux voir mon solde de points à l’ouverture, afin de savoir si je peux en profiter aujourd’hui. Étant donné un compte actif, lorsque j’ouvre l’application, alors le solde affiché date de moins de cinq minutes. Étant donné une absence de réseau, lorsque j’ouvre l’application, alors le dernier solde connu est affiché avec sa date de mise à jour.
- US-16 · Boutique
- En tant que responsable de boutique, je veux suspendre un produit épuisé en deux touches, afin de ne pas vendre ce que je n’ai plus. Étant donné un produit au catalogue, lorsque je le marque épuisé, alors il disparaît de la commande client en moins d’une minute. Étant donné une commande déjà payée contenant ce produit, lorsque je le marque épuisé, alors le client reçoit une notification et le remboursement du produit est déclenché.
- US-21 · Compte
- En tant qu’utilisateur, je veux supprimer mon compte depuis l’application, afin de ne pas avoir à écrire un courriel. Étant donné un compte connecté, lorsque je demande la suppression et que je confirme, alors le compte est désactivé immédiatement et les données sont effacées dans le délai annoncé dans la politique de confidentialité. Étant donné une commande en cours, lorsque je demande la suppression, alors l’application indique la date à partir de laquelle elle sera possible.
Deux détails méritent d’être remarqués. La story US-16 ne décrit pas un écran d’administration, elle décrit un résultat attendu en moins d’une minute côté client, ce qui contraint l’architecture sans imposer de solution. Et la story US-21 existe parce que la suppression de compte depuis l’application est exigée par les deux magasins d’applications pour toute application permettant la création d’un compte : c’est le genre de story qui manque dans les backlogs et qui fait refuser une publication.
Les erreurs qui coûtent le plus cher
- La story qui décrit une solution. « Je veux une liste déroulante avec les boutiques » impose la solution avant d’avoir posé le besoin. Écrivez le résultat cherché, « je veux choisir la boutique la plus proche de moi », et laissez l’équipe proposer la meilleure interface. La deuxième formulation ouvre des options, la première les ferme.
- Le bénéfice supprimé pour gagner du temps. Sans la partie « afin de », plus rien ne permet d’arbitrer quand le budget se tend. Toutes les stories deviennent également indispensables, et c’est exactement la situation qu’un backlog doit éviter.
- Des critères d’acceptation écrits après le développement. Écrits après, ils décrivent ce qui a été fait au lieu de ce qui était attendu. Écrits avant, ils tiennent lieu de contrat de recette et se transforment directement en cas de test.
- Un découpage par couche technique. Trois stories nommées écran, interface de programmation et base de données ne livrent rien tant que les trois ne sont pas terminées, et aucune ne se teste seule. Découpez par parcours ou par règle, pas par couche.
- Les cas d’erreur oubliés. Réseau coupé, session expirée, permission refusée, paiement rejeté : sur mobile, ces quatre cas représentent une part importante du travail réel. Une story qui ne les mentionne pas sera chiffrée sans eux, et ils reviendront en avenant.
User stories et devis : ce que le prestataire en fait
Un backlog de stories avec critères d’acceptation change la nature d’un devis. Sans lui, une agence chiffre une intention et protège son risque par une marge. Avec lui, elle chiffre des éléments identifiables, et vous pouvez lui demander la ventilation ligne par ligne. C’est la façon la plus simple de rendre deux devis comparables : le même backlog, les mêmes lignes, deux montants.
Ces stories deviennent ensuite les cas de test de la campagne de vérification, presque sans réécriture. Chaque critère d’acceptation donne un cas, avec son résultat attendu déjà écrit. C’est le principal gain caché du format : ce que vous écrivez au cadrage sert encore au moment de valider la livraison.
Pour la vue d’ensemble du projet, le cahier des charges d’application mobile reste le document de référence, et la grille de lecture d’un devis explique poste par poste ce que vous devez retrouver en face de ce backlog.
Les autres modèles de la rubrique
Ce que contient le modèle Excel
| Onglet | Contenu | À quoi il sert |
|---|---|---|
| Mode d’emploi | Règles de rédaction, échelle d’estimation, code des priorités | À lire une fois, à diffuser à l’équipe |
| Backlog | Identifiant, rôle, action, bénéfice, priorité, estimation, écran, critères d’acceptation, statut | Le tableau de travail, avec listes déroulantes |
| Exemple rempli | 24 user stories du cas fictif, critères compris | Le modèle à imiter, à supprimer ensuite |
| Récapitulatif | Totaux par priorité et par statut, calculés automatiquement | Le point d’avancement en une image |
| Glossaire | Les termes employés, définis en une ligne | Pour les lecteurs qui ne font pas de produit |
User story exemple : questions fréquentes
Comment écrire une user story ?
En une phrase de la forme « en tant que {rôle}, je veux {action}, afin de {bénéfice} », complétée par trois à dix critères d’acceptation vérifiables. Le rôle désigne une personne précise, pas un utilisateur générique. L’action décrit un résultat, jamais une solution d’interface. Le bénéfice explique pourquoi, et c’est lui qui permettra d’arbitrer plus tard.
Quelle est la différence entre une user story et une spécification ?
La spécification décrit le comportement du système de façon exhaustive et sert de référence contractuelle. La user story décrit un besoin du point de vue de l’utilisateur et sert d’unité de travail. Les deux coexistent sans se remplacer : le cahier des charges pose le cadre, les stories découpent la livraison à l’intérieur de ce cadre.
Combien de user stories pour une application mobile ?
Il n’existe pas de nombre attendu, et un backlog gonflé n’est pas un bon signe. Ce qui compte est la taille de chacune : une story doit tenir dans une itération et se tester seule. Le cas d’école fourni avec le modèle en compte vingt-quatre pour une première version de commande et de fidélité, ce qui donne un ordre de grandeur pour un périmètre de départ raisonnable.
Qui écrit les user stories, le client ou l’agence ?
Les deux, et pas au même moment. Le client écrit les premières, celles qui portent le besoin et le bénéfice, parce que personne d’autre ne connaît son métier. L’agence les reprend, les découpe, signale les cas manquants et propose les critères d’acceptation techniques. Une agence qui écrit seule les stories écrit en réalité sa propre interprétation du besoin.
Faut-il estimer les user stories en jours ou en points ?
Les points relatifs présentent un avantage pratique : ils mesurent la complexité d’un travail sans la mélanger à la disponibilité de la personne qui le fera. Les jours restent plus lisibles pour une direction. Le choix compte moins que la constance : gardez la même échelle du premier au dernier jour du projet, sinon les comparaisons perdent leur sens.
Un avis technique sur votre périmètre en trente minutes ?
Décrivez votre application en quinze minutes : vous repartez avec un avis technique sous 48 h. Périmètre, technologies pertinentes et ordre de grandeur budgétaire. Sans engagement.
Ou par téléphone 06 32 64 24 80
Les modèles de documents de projet
Expression de besoin, note de cadrage, user stories, matrice de priorisation, roadmap produit : les documents s’enchaînent, et le même cas d’école fictif les traverse tous.