Générateur de user stories IA
Transformez une demande de fonctionnalité en user stories avec critères d’acceptation Given/When/Then, en Markdown ou en JSON.
Votre clé reste dans votre navigateur.Elle part directement chez le fournisseur, jamais sur nos serveurs, et nous ne la journalisons ni ne la conservons. Utilisez une clé dédiée avec un plafond de dépenses et supprimez-la dans la console du fournisseur une fois terminé.
Entrée
Résultat
Le résultat apparaîtra ici.Une demande de fonctionnalité arrive généralement sous forme de paragraphe dans un ticket ou une discussion : qui la demande, à peu près ce qu’il veut, une règle ou deux. Avant que quiconque puisse l’estimer, elle doit devenir des user stories — « En tant qu’administrateur de facturation, je veux…, afin de… » — chacune avec des critères d’acceptation que la QA peut vérifier. Collez la demande, choisissez en combien de stories la découper, et l’outil les rédige avec des scénarios Given / When / Then couvrant le parcours principal et au moins un cas d’échec ou cas limite par story, plus une ligne de notes lorsqu’il existe une vraie dépendance. Choisissez JSON plutôt que Markdown quand les stories doivent aller dans Jira, Linear ou un script via une API plutôt que dans un document.
Comment ça marche
- Deux patterns de Fabric sont fusionnés : create_user_story fournit la structure Description / Critères d’acceptation et son interdiction des clichés et du remplissage, et agility_story fournit les critères Given/When/Then et la forme de la sortie JSON.
- Les stories sont découpées selon la valeur qu’elles apportent à un utilisateur plutôt que par couche frontend et backend, et chacune reste assez petite pour tenir dans une itération — la règle empirique INVEST.
- Une entrée en français reçoit les mots-clés Gherkin français Soit, Quand, Alors et Et, une entrée en chinois les mots-clés 假如, 当, 那么 et 而且 ; Cucumber et les autres outils Gherkin les acceptent, si bien que les scénarios peuvent servir de base à de vrais fichiers feature.
- Le texte de la demande est envoyé de cette page au fournisseur choisi, authentifié avec votre propre clé — une clé distincte et plafonnée, réservée à ce genre d’outil, est plus sûre que la clé qui fait tourner votre produit.
Où vont vos données
Avec votre propre clé, votre saisie et la clé partent de votre navigateur directement chez le fournisseur choisi, sans passer par Hysen Labs. En mode hébergé, votre texte transite par notre serveur jusqu’à notre fournisseur (DeepSeek) et est facturé en crédits ; pour la facturation, nous conservons le nombre de tokens et le coût de chaque exécution, jamais le texte ni la réponse. Le traitement du texte par le fournisseur relève de sa propre politique de confidentialité.
Cet outil manipule des clés et des identifiants : rien n’est enregistré sur une exécution, pas même dans votre propre historique.
À propos de votre clé API
Nous ne collectons, ne stockons et ne divulguons pas votre clé : elle ne vit que dans la mémoire de cette page (sauf si vous cochez « mémoriser dans cet onglet ») et disparaît à la fermeture. Restez prudent malgré tout avec toute clé collée dans une page web : créez une clé dédiée avec un plafond de dépenses, puis supprimez-la ou renouvelez-la dans la console du fournisseur une fois terminé.
Ce que ça coûte
Cet outil est gratuit, sans connexion ni points.
Questions fréquentes
- Pourquoi chaque story comporte-t-elle un scénario d’échec ?
- Parce que le parcours nominal est la partie sur laquelle tout le monde est déjà d’accord. Les questions qui provoquent des reprises — que se passe-t-il avec une plage de dates vide, qui peut voir le bouton, que dit l’e-mail quand l’export échoue — n’apparaissent que lorsque quelqu’un doit écrire le cas d’échec. S’il ne s’applique pas, supprimez-le ; c’est moins coûteux que de le découvrir en QA.
- Puis-je importer le JSON dans Jira ?
- Pas directement : les importateurs de Jira acceptent le CSV ou le format de sa propre API REST. Le JSON est un format intermédiaire propre — un tableau de topic, story, criteria et notes — qu’un court script peut envoyer via l’API de Jira ou de Linear, ou que vous pouvez convertir en CSV.
- Les stories contiennent des règles que je n’ai jamais données. Pourquoi ?
- Le prompt demande au modèle de placer une règle manquante dans les notes en tant qu’hypothèse plutôt que de l’affirmer comme un fait, mais les modèles dérapent parfois. Lisez les critères d’acceptation comme des questions : chaque nombre ou autorisation que vous n’avez pas fourni est à confirmer auprès de la personne qui a demandé la fonctionnalité.
- En combien de stories une demande doit-elle être découpée ?
- En autant qu’il y a d’éléments ayant une valeur propre. L’exemple — un export de factures avec filtres, autorisations et une tâche d’arrière-plan pour les gros exports — se divise naturellement en trois. Si le modèle n’en trouve pas autant, il en écrit moins plutôt que de remplir ; si une story ressemble encore à une semaine de travail, augmentez le nombre et relancez.
L’open source derrière
Le prompt de cet outil est adapté de danielmiessler/Fabric (MIT) et s’exécute sur le modèle de votre choix. Pour la même fonction en ligne de commande ou dans votre propre programme, partez de ce projet.
danielmiessler/FabricAussi appelé
- générateur de user stories
- critères d’acceptation exemple
- modèle user story
- given when then exemple
- critères d’acceptation gherkin
- user story jira