Premier matin sur le terrain. Les plans sont validés, les matériaux commandés, les autorisations obtenues. Ton équipe est prête. Mais le chef de chantier ne dit pas "allez, tout le monde au boulot !" et ne laisse pas chacun choisir ce qu'il fait. Il étale les plans sur la table, désigne les lots de travaux, et décide : cette semaine, on attaque les fondations et les murs extérieurs. Le reste attendra. Sur un chantier sérieux, l'ordre dans lequel on travaille compte autant que la qualité du travail.
Dans cette fiche, tu découpes ton projet en epics et stories avec le chef de chantier, tu choisis par quoi commencer, et tu valides ta première story avec le correcteur avant de lancer le dev.
Tu sors de la Phase 2 avec des docs complets : brief, PRD, UX, architecture, et un ensemble de fonctionnalités à construire. Peut-être 10, peut-être 20 choses à faire. La tentation naturelle, c'est de commencer par ce qui paraît "logique" — souvent l'authentification ou la base de données, parce qu'on pense que tout dépend d'elles.
Erreur classique. Ce n'est pas comme ça que fonctionne un chantier.
Commence par ce qui se voit. Pas par la plomberie cachée dans les murs — par la façade, les fenêtres, ce qui donne envie d'entrer. Dans une app, c'est l'interface principale : le kanban, la vue produit, le tableau de bord. Ce que tu pourras ouvrir dans le navigateur et dire "ça marche" dès le premier jour.
L'effet wow vient de ce qu'on voit. L'authentification viendra après — quand tu auras déjà quelque chose à protéger.
Tes fonctionnalités vont être organisées en lots de travaux (epics) et tâches de chantier (stories). Lance le chef de chantier pour structurer tout ça :
Le SM va lire tes documents de Phase 2 et créer une structure claire :
Si le SM propose un découpage qui ne te convient pas, dis-le : "Je voudrais séparer X et Y en deux epics distincts." C'est toi le maître d'ouvrage.
Le SM va te proposer un ordre de départ. Voici la règle à retenir :
La première epic doit être visible dans le navigateur dès le premier jour.Concrètement : commence par construire l'interface principale, même vide, même sans données réelles. Un kanban avec des colonnes fixes, une liste avec des éléments de test, un tableau de bord avec des chiffres en dur. Quelque chose qui s'affiche, qui ressemble à ton app, sur lequel tu pourras construire la suite.
L'authentification et la base de données, c'est pour après. Si tu attaques ça en premier, tu passes deux jours sur de la plomberie invisible — et tu n'as rien à montrer.
Non. Tu peux construire l'interface avec des données fictives, puis la connecter à la vraie base ensuite. Le SM sait dans quel ordre séquencer ça. Fais-lui confiance.
Un sprint, c'est une semaine de chantier — une sélection de stories sur lesquelles tu te concentres, dans l'ordre. Lance :
Le SM va analyser tes stories, leurs dépendances, et te proposer une sélection réaliste pour commencer. Pas 15 stories en même temps — 3 à 5 stories bien séquencées, qui produisent un résultat visible à la fin de la semaine.
Tu peux ajuster : "Je préfère commencer par celle-ci", "Celle-là me paraît trop grosse". Mais évite la tentation de mettre trop de stories dans le premier sprint. Sur un chantier, finir 3 murs proprement vaut mieux qu'en commencer 10.
Avant de donner le premier coup de marteau, une étape clé. Lance le correcteur sur ta première story :
Pourquoi ? Parce qu'une story trop vague, c'est l'assurance d'un résultat approximatif. Si tu donnes à Claude "créer la vue principale de l'app", il va improviser — et peut-être pas dans la direction que tu veux. Si tu lui donnes une story avec des critères d'acceptation précis, il suit la feuille de route.
Une story ready-for-dev contient :
Le correcteur te dira si ta story est prête, ou te guidera pour la compléter. Ce n'est pas un test à passer — c'est une aide pour éviter de partir dans tous les sens.
Il connaît ta stack (Next.js + Supabase + Vercel) et tes documents de Phase 2. Il évalue si ta story est réaliste dans ce cadre, et te propose toujours une alternative si quelque chose sort du scope.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Le SM ne trouve pas les docs de Phase 2 | Fichiers manquants ou mal nommés | Vérifie que brief.md, prd.md, architecture.md existent dans ton projet. Lance /workflow-status pour voir l'état des documents |
| Les stories créées sont trop vagues | Les docs de Phase 2 manquent de détails | Demande au SM : "Détaille davantage les stories de l'epic X" |
| /sprint-planning propose trop peu de stories | Comportement normal, le SM est conservateur | C'est voulu. Finir 3 stories proprement vaut mieux qu'en commencer 8 |
| /brik:corriger story dit que ma story n'est pas prête | La story manque de critères d'acceptation | Réponds au correcteur : "Comment compléter cette story ?" Il te guidera étape par étape |
| Je ne sais pas par quelle epic commencer | Hésitation entre plusieurs options | Règle simple : quelle fonctionnalité tu veux voir dans ton navigateur à la fin de la journée ? Commence par celle-là |
| La commande /create-epics-stories ne répond pas | BMAD n'est pas correctement installé | Vérifie que le dossier _bmad/ existe. Sinon, relance npx bmad-method@alpha install |
Le sprint est planifié, la première story est validée. Il est temps de construire — story par story, brique par brique.
-> Fiche suivante : Construire brique par brique