Tu as une idée. Quelque chose comme "une app pour gérer mes recettes" ou "un outil pour suivre mes clients". C'est flou, et c'est normal — tous les grands chantiers commencent par un croquis au dos d'une serviette. Mais avant de poser la première brique, ton géomètre va planter ses jalons. Il mesure le terrain, identifie les contraintes, te pose des questions que tu n'avais pas pensé à te poser. Et à la fin de cette matinée, tu as non plus un rêve, mais un dossier.
Dans cette fiche, tu transformes ton idée en deux documents de cadrage : un brief qui clarifie ta vision, et un PRD qui liste les fonctionnalités concrètes de ta V1.
Le scope creep, c'est l'ennemi numéro un des projets qui n'aboutissent jamais. Tu veux "juste ajouter une petite feature", puis une autre, puis encore une. Trois semaines plus tard, rien n'est fini. Le brief et le PRD servent à dessiner la frontière entre ce qu'on construit maintenant et ce qu'on garde pour plus tard.
Un brief tient sur une page. Il répond à trois questions : quel problème je règle, pour qui, avec quelle solution. Le PRD va plus loin : pour chaque fonctionnalité de ta V1, il décrit précisément ce que l'utilisateur peut faire. Pas comment c'est codé — ce que l'utilisateur fait.
Elle arrive toujours en cours de route. Quand elle arrive, dis simplement "V2". Le chef de projet te le rappellera autant qu'il le faudra.
L'Analyst, c'est le géomètre de ton équipe. Son job : prendre ton idée floue et la transformer en vision structurée. Tu ne fais pas le brief seul — tu le construis en dialogue avec lui.
Lance le workflow dans le terminal Claude Code :
L'agent Analyst se charge automatiquement. Il va te poser des questions pour creuser ton idée. Réponds avec tes mots, même si c'est approximatif — il reformule, tu corriges, il affine. Le brief n'est pas parfait au premier tour, c'est normal.
Tu viens de découvrir le premier document BMAD. Dans les prochaines étapes, d'autres agents en auront besoin. Plutôt que de tout réexpliquer, tu peux référencer un fichier avec le symbole @ :
Claude ira chercher le fichier et en comprendra le contenu. C'est comme tendre un dossier à un collègue plutôt que de tout lui re-raconter de mémoire.
Quand l'Analyst te présente le brief final, relis-le. Est-ce que ça capture bien ton intention ? Si oui, valide. Le fichier product-brief.md apparaît dans ton projet.
Le PM (chef de projet) transforme ta vision en programme immobilier — un document qui dit exactement ce que ton app va contenir, fonctionnalité par fonctionnalité.
Lance le workflow :
Donne-lui le brief :
Le cœur du PRD, ce sont les fonctionnalités. Chaque fonctionnalité est décrite du point de vue de l'utilisateur : "L'utilisateur peut créer une entrée", "L'utilisateur peut filtrer par catégorie".
C'est là que se joue le scope creep. Le PM va peut-être te proposer des features intéressantes. Ton rôle de maître d'ouvrage : décider ce qui va en V1 (ce qu'on construit maintenant) et ce qui va en V2 (plus tard).
V1 = le minimum qui fonctionne. L'app tient debout, les gens peuvent l'utiliser. Les extras, c'est la V2.Quand le PM te présente le PRD final, vérifie que chaque fonctionnalité est formulée en action utilisateur et que le périmètre reste raisonnable. Valide. Le fichier prd.md apparaît dans ton projet.
Tu as deux documents. Avant de passer à la suite, fais-les valider.
L'inspecteur de chantier, c'est /brik:corriger. Il ne juge pas la qualité de ta rédaction — il vérifie que ce que tu décris est réalisable dans la stack de la formation (Next.js + Supabase + Vercel) en 5 jours. S'il recadre, il propose toujours comment découper, jamais "c'est trop ambitieux".
Lance d'abord la vérification du brief :
Puis, quand le brief est validé, lance la vérification du PRD :
Suis les ajustements recommandés si l'inspecteur en propose. C'est lui qui connaît ce que la stack peut avaler.
Tu as deux fichiers texte. Tu mérites de voir ta vision prendre forme. Copie-colle ce prompt exact dans Claude Code :
Ouvre le fichier HTML généré dans ton navigateur. C'est la version visuelle de ta vision.
Ce fichier HTML n'est pas un livrable du projet. C'est juste pour toi, pour voir ton travail prendre forme.
| Symptôme | Cause probable | Solution |
|---|---|---|
| /create-product-brief n'est pas reconnu | BMAD n'est pas installé ou le projet n'est pas initialisé | Retourne à la fiche 1.x et vérifie que /workflow-init a été lancé |
| L'Analyst génère le brief directement sans poser de questions | Il manque de contexte | Relance avec "Je veux créer un brief pour [mon projet]. Pose-moi des questions avant de rédiger." |
| Le fichier product-brief.md n'apparaît pas | L'Analyst n'a pas encore finalisé | Attends qu'il confirme. Si ça bloque, demande "Génère le fichier product-brief.md maintenant." |
| Le PRD est énorme (plusieurs pages) | Scope trop large | Dis au PM "C'est une V1. Garde uniquement les fonctionnalités essentielles pour un MVP fonctionnel." |
| /brik:corriger dit que le projet est trop ambitieux | L'inspecteur recadre le scope | Lis attentivement sa réponse — il propose toujours comment découper. Applique et relance. |
| Le PM parle de technologies au lieu de fonctionnalités | Il confond PRD et Architecture | Dis "Pas de choix techniques ici. Concentre-toi sur ce que l'utilisateur peut faire." |
Le terrain est arpentée, le programme est écrit. L'équipe sait ce qu'on va construire. Maintenant, deux spécialistes vont se mettre au travail en parallèle : le décorateur pour imaginer comment les gens vont vivre dans ton app, et l'architecte pour dessiner la structure qui tient tout ça debout.
-> Fiche suivante : Imaginer et structurer