Générateur de User Story
Rédigez des user stories avec critères d'acceptation, story points et priorités MoSCoW. Partez d'un jeu d'exemples, vérifiez chaque story selon INVEST et importez le backlog dans Jira.
Brouillon restauré depuis ce navigateur.
Chaque paragraphe se modifie directement dans le document.
Envoyé. Vérifiez votre boîte dans quelques minutes.
Envoyez-nous votre backlog et nous l'estimerons en un jour ouvré
Nous passerons en revue les stories, signalerons les lacunes et vous indiquerons la durée de la première version. Le texte de vos stories est joint automatiquement à la demande.
Merci ! Nous répondrons dans un jour ouvré.
En bref : une user story est une exigence d'une phrase, écrite du point de vue de l'utilisateur : qui a besoin de quoi, et pour quelle raison. Ajoutez deux ou trois critères d'acceptation en Étant donné que / Quand / Alors, une estimation et une priorité MoSCoW, et un développeur peut la prendre sans réunion de cadrage. Ce générateur fournit le modèle, cinq jeux d'exemples, un contrôle INVEST et un CSV que Jira importe en tickets de type Story.
L'outil s'adresse aux fondateurs, product owners et analystes qui veulent un backlog propre avant de consulter un prestataire. Des stories bien écrites sont aussi la base la plus rapide pour un chiffrage : si vous préparez un développement de MVP ou une collaboration plus longue en product engineering, envoyez-nous le backlog et vous recevrez une estimation sous un jour ouvré.
Le générateur fonctionne en quatre étapes, et tout reste dans votre navigateur :
- Produit. Nommez le produit ou la release, choisissez story points ou tailles de t-shirt et rédigez une Definition of Done commune.
- Jeu d'exemples. Boutique en ligne, livraison de repas, application de fitness, compte SaaS ou marketplace, huit stories chacun. Ou partez d'une liste vide.
- Stories. Modifiez rôles, actions, valeurs, critères, estimations, priorités et epics.
- Contrôle. Passez en revue les alertes INVEST, puis exportez en CSV pour Jira, DOCX, Markdown ou PDF.
Cette version ne rédige rien par IA : vous réécrivez un modèle ou un jeu d'exemples, et les stories décrivent votre produit, pas une boutique générique.
À quoi ressemble une bonne user story ?
Une bonne user story nomme un rôle précis, une seule action et une valeur défendable devant le décideur : « En tant que [rôle], je veux [action] afin de [valeur] ». Exemple complet pour une boutique en ligne :
Story : En tant que cliente fidèle, je veux repasser une ancienne commande en un clic afin de ne pas reconstituer mon panier.
- Étant donné que je suis connectée et que j'ai une commande livrée, quand je clique sur « Commander à nouveau », alors tous les articles disponibles sont ajoutés au panier dans les mêmes quantités.
- Étant donné qu'un article de cette commande est en rupture, quand je clique sur « Commander à nouveau », alors les autres articles sont ajoutés et je vois lequel manque.
- Étant donné que mon panier contient déjà des articles, quand je recommande, alors les nouveaux articles s'ajoutent sans rien remplacer.
Estimation : 3 points (M). Priorité : Should. Epic : Commandes.
Si la partie « afin de » reste vide, la fonctionnalité n'est sans doute pas utile.
Comment rédiger des critères d'acceptation en Étant donné que / Quand / Alors ?
Un critère couvre un scénario : Étant donné que décrit l'état avant l'action, Quand l'action elle-même, Alors un résultat que n'importe qui peut vérifier sans vous demander. C'est le format Given / When / Then du BDD. Commencez par le cas nominal, puis ajoutez ce qui casse souvent en production : données vides, erreur, droits insuffisants, perte de connexion. Trois à cinq critères, c'est une bonne fourchette ; au-delà de six, la story en cache généralement deux.
Les critères d'acceptation ne sont pas la Definition of Done. Les critères appartiennent à une story ; la Definition of Done vaut pour toutes (« revue de code faite, tests au vert, déployé en recette »). L'équipe QA peut transformer chaque ligne en cas de test.
Que signifie INVEST et que vérifie le générateur ?
INVEST est une grille de qualité en six critères. Le générateur signale ce qu'il peut détecter seul ; le reste se discute en équipe.
| Lettre | Question à se poser | Alerte du générateur |
|---|---|---|
| I — Independent (indépendante) | Peut-elle être livrée sans attendre une autre story ? | Non vérifié : relisez l'ordre du backlog |
| N — Negotiable (négociable) | La solution reste-t-elle ouverte ? | Non vérifié : retirez les détails d'interface et techniques |
| V — Valuable (utile) | Sait-on qui y gagne et pourquoi ? | Partie « afin de » vide, action absente ou rôle générique comme « utilisateur » |
| E — Estimable | L'équipe peut-elle la chiffrer ? | Non vérifié : si l'équipe ne peut pas estimer, il manque souvent des critères |
| S — Small (petite) | Tient-elle dans un sprint ? | 8 points (XL) ou plus de six critères |
| T — Testable | Peut-on prouver qu'elle fonctionne ? | Aucun critère Étant donné que / Quand / Alors complet |
Comment estimer et prioriser les user stories ?
L'échelle 1, 2, 3, 5, 8 compare les stories entre elles ; ce ne sont pas des heures. Les tailles de t-shirt vont plus vite pour un premier tour : le générateur les convertit en points (XS = 1, S = 2, M = 3, L = 5, XL = 8) pour que la colonne Jira reste numérique.
MoSCoW classe le backlog en Must, Should, Could et Won't (pas cette fois). Pour une première version, gardez le groupe Must assez réduit pour qu'il livre à lui seul quelque chose d'utilisable. Won't garde la trace de ce que vous écartez.
Comment importer des user stories dans Jira ?
Téléchargez « CSV pour Jira », puis dans Jira ouvrez Système → Importation depuis un système externe → CSV et associez les colonnes. Une ligne correspond à une story :
- Summary : l'action, assez courte pour une carte du tableau ;
- Description : la phrase « En tant que… je veux… afin de… » et les critères numérotés ;
- Issue Type : toujours Story ;
- Story Points : de 1 à 8 ;
- Epic Link : le nom de l'epic ; créez les epics avant ou utilisez des clés existantes ;
- Labels : la priorité MoSCoW (moscow-must, moscow-should…) et, en tailles de t-shirt, la taille.
Dans les projets gérés par l'équipe, associez l'epic au champ Parent au lieu d'Epic Link.
Quelle place pour les user stories à côté du PRD et du cahier des charges ?
Les stories décrivent le comportement ; les documents autour donnent le cadre. Objectifs, périmètre, risques et exigences non fonctionnelles vont dans le document d'exigences produit, que vous pouvez préparer avec le modèle PRD. Indiquez-y aussi la conformité RGPD attendue du prestataire : ce n'est pas une story à part. Si vous externalisez, joignez le backlog à un cahier des charges pour la consultation, puis comparez les réponses dans la grille d'évaluation des prestataires. Des devis chiffrés sur les mêmes stories se comparent bien mieux que des estimations faites sur un brief flou.
Questions fréquentes
Le générateur de user stories est-il gratuit ?
Oui. Il est gratuit, sans inscription, et le document se construit entièrement dans votre navigateur.
Les stories sont-elles rédigées par une IA ?
Non. Cette version ne génère pas de texte par IA : vous partez d'un modèle ou de l'un des cinq jeux d'exemples et vous adaptez les stories vous-même. Le backlog reste ainsi propre à votre produit.
Mes stories sont-elles envoyées quelque part ?
Non. Elles sont enregistrées uniquement dans ce navigateur. Rien n'est transmis tant que vous ne remplissez pas le formulaire et ne cliquez pas vous-même sur « envoyer ».
Quels jeux d'exemples sont proposés ?
Boutique en ligne, livraison de repas, application de fitness, compte SaaS et marketplace : huit stories chacun, avec critères, estimations et priorités. Choisissez le plus proche et réécrivez-le pour votre produit.
Dans quels formats puis-je exporter ?
CSV pour l'import Jira, DOCX, Markdown et PDF. Vous pouvez aussi copier le texte ou recevoir le document par e-mail.
Combien de critères d'acceptation par story ?
En général trois à cinq : le cas nominal plus les erreurs et cas limites les plus probables. Au-delà de six, il vaut mieux découper la story.
Quelle différence entre user story, epic et tâche ?
Une story est une unité de valeur pour l'utilisateur qui tient dans un sprint. Un epic regroupe des stories liées, par exemple « Commandes ». Les tâches sont les étapes techniques pour réaliser une story.