BMAD-METHOD V6 guide pas à pas

Vous connaissez la scène : vous ouvrez votre assistant IA, vous décrivez une fonctionnalité en deux phrases, et vous croisez les doigts. L'IA génère du code, vous corrigez, vous relancez, et au bout d'une heure vous avez un empilement de rustines dont personne — ni vous, ni l'IA — ne maîtrise vraiment la logique. C'est ce qu'on appelle le vibe coding : demander du code sans cadre et espérer que ça tombe juste.

BMAD-METHOD (pour Breakthrough Method for Agile AI-Driven Development) propose exactement l'inverse : planifier avant de coder. Au lieu d'improviser, la méthode transforme votre assistant IA en une véritable équipe agile d'agents spécialisés (analyste, product manager, architecte, UX, développeur, rédacteur technique). Cette équipe produit d'abord des documents de planification — brief, PRD, architecture, epics, stories — qui deviennent un contexte préparé, versionné et transmis proprement à l'agent qui code.

Ce tutoriel couvre la version 6 (module BMM v6.x). Attention : la grande majorité des tutoriels que vous croiserez en ligne montrent encore la V4, aujourd'hui périmée. Les noms d'agents, les commandes et l'architecture ont changé. Ici, tout est V6.

Prérequis

Avant de commencer, assurez-vous d'avoir :

• Node.js ≥ 20 — le socle historique de BMAD.
• Python ≥ 3.10 et le gestionnaire de paquets uv — c'est la grande nouveauté de la V6. Certains workflows en dépendent désormais, alors que la V4 était purement npm. C'est aussi le principal point de friction en environnement verrouillé : pensez-y si vous travaillez sur une machine sur laquelle vous n'installez pas facilement des outils.

Installation (une fois par projet)

L'installation se fait par projet. En mode interactif, une seule commande suffit et l'assistant vous pose les questions :

# Installation interactive : BMAD vous guide pas à pas
npx bmad-method install

Si vous préférez tout enchaîner sans questions, la version non interactive installe directement le module cœur pour l'agent de code de votre choix :

# Installation non interactive dans un dossier précis
# --modules bmm  : le module cœur du cycle de dev
# --tools        : votre outil (ici claude-code)
# --yes          : accepte tous les défauts
npx bmad-method install --directory /chemin/projet --modules bmm --tools claude-code --yes

L'installation crée deux dossiers : _bmad/ (le framework et ses modules) et _bmad-output/ (là où atterriront tous vos artefacts). Bon à savoir : la sortie peut être configurée dans une autre langue, par exemple en français.

Les modules disponibles

BMAD est modulaire. Pour ce tutoriel, seul bmm nous intéresse, mais voici la liste officielle :

• bmm — BMad Method : le module cœur, 34+ workflows du cycle de développement. C'est celui qu'on installe ici.
• bmb — BMad Builder : pour créer vos propres agents et workflows.
• cis — Creative Intelligence Suite : innovation, brainstorming.
• tea — Test Architect : stratégie de test orientée risque.

La première décision : petite tâche ou grosse feature ?

Avant de dérouler quoi que ce soit, posez-vous une seule question : quelle est l'ampleur du travail ? BMAD V6 propose deux chemins, et choisir le bon vous évite de gaspiller du temps (et des tokens).

Petit rappel de vocabulaire : dans BMAD, on invoque les agents et les skills en langage naturel. Pas de slash-commands à mémoriser : vous dites simplement « parle à Mary » ou « run quick-dev ». La V6 repose sur une architecture de skills, pas de commandes rigides.

Voie rapide (quick lane) — pour une petite tâche

Un bug à corriger, un petit ajout, un refactor ciblé ? Inutile de sortir l'artillerie lourde. Une seule skill fait le travail : quick-dev. Elle implémente directement en respectant l'architecture et les conventions déjà présentes dans votre projet, sans PRD ni stories.

# Voie rapide : on décrit l'intention, BMAD implémente
run quick-dev — corrige le bug de validation du login

Vous pouvez lui passer une description en texte, une URL d'issue, ou un fichier d'intention. Il existe aussi une variante « contrat léger » : une skill de type spec qui distille votre intention en un court document structuré (Why / Capabilities / Constraints / Non-goals / Success), sans aller jusqu'au PRD complet. Un bon compromis quand la tâche mérite un minimum de cadrage mais pas le pipeline entier.

Pipeline complet — pour une vraie fonctionnalité

Nouvelle feature d'ampleur, avec des écrans, des règles métier, des choix d'architecture ? Là, le pipeline en 4 phases prend tout son sens. C'est le cœur de la méthode, et c'est ce qu'on déroule maintenant.

Conseil : faites chaque phase dans un chat neuf. Cela évite de polluer le contexte de l'agent avec les échanges des phases précédentes.

Le pipeline en 4 phases

Chaque phase est portée par un ou plusieurs agents nommés, et produit un artefact rangé dans _bmad-output/. Pour chaque étape, retenez trois choses : QUI le fait, CE QUE VOUS DITES, et CE QUE ÇA PRODUIT.

Phase 1 — Analyse & cadrage (optionnel)

Qui : Mary, l'analyste. En appui, Paige, la rédactrice technique, pour la documentation et les diagrammes.

Ce que vous dites :

parle à Mary — j'aimerais cadrer une nouvelle fonctionnalité d'export de rapports

Mary organise un brainstorming, mène un cadrage, et rédige un product brief : le document qui pose le pourquoi et les grandes lignes du besoin. Cette phase est facultative selon l'ampleur : sur une feature dont le périmètre est déjà clair, vous pouvez démarrer directement au Planning.

Phase 2 — Planning : le besoin

Qui : John, le product manager. En renfort, Sally, l'UX designer.

Ce que vous dites :

parle à John — crée le PRD à partir du brief de la fonctionnalité d'export

John produit le PRD (Product Requirements Document) : le document qui décrit précisément ce que doit faire le produit, les besoins et les exigences. En V6, une seule skill, bmad-prd, couvre la création, la mise à jour et la validation du PRD. (Note : la vieille commande V4 bmad-create-prd est dépréciée — n'y touchez plus.)

Si la fonctionnalité comporte des écrans qui le justifient, on enchaîne avec Sally :

parle à Sally — rédige la spécification UX pour l'écran d'export

Sally produit une spécification UX/UI. Le PRD atterrit dans _bmad-output/planning-artifacts/PRD.md.

Phase 3 — Solutioning : l'architecture et le découpage

Qui : Winston, l'architecte.

Ce que vous dites :

parle à Winston — conçois l'architecture pour la fonctionnalité décrite dans le PRD

Winston rédige le document d'architecture (les décisions techniques). Puis vient le découpage : génération des epics et des user stories.

• Un epic est un gros bloc de fonctionnalité (par exemple « Système d'export »).
• Une user story (ou « story ») est une unité de travail concrète et livrable qui découle d'un epic (par exemple « Exporter un rapport au format CSV »).

Cette phase produit aussi le project-context : un ensemble de règles et de faits persistants qui seront chargés dans chaque story. Enfin, un contrôle de « implementation readiness » tranche en go / no-go : le PRD, l'UX, l'architecture et les epics sont-ils complets et cohérents ? Tant que ce n'est pas au vert, on ne code pas.

Voici à quoi ressemble l'arborescence produite :

votre-projet/
├── _bmad/                                # installation (framework + modules)
├── _bmad-output/
│   ├── planning-artifacts/
│   │   ├── PRD.md                        # le besoin
│   │   ├── architecture.md               # décisions techniques
│   │   └── epics/                        # epics et stories
│   ├── implementation-artifacts/
│   │   └── sprint-status.yaml            # suivi de sprint
│   └── project-context.md                # règles d'implémentation (optionnel)

Phase 4 — Implémentation : la boucle par story

Qui : Amelia, la développeuse.

Tout démarre par un sprint planning, qui produit le fichier sprint-status.yaml — le tableau de bord du sprint :

# extrait simplifié de sprint-status.yaml
sprint: 1
stories:
  - id: EXP-1
    title: "Exporter un rapport au format CSV"
    status: in-progress
  - id: EXP-2
    title: "Ajouter un filtre par date à l'export"
    status: todo

Ensuite, on avance story par story :

1. Création du story file — un fichier autonome pour la story à traiter.
2. Développement par Amelia, en TDD (Test-Driven Development : on écrit d'abord le test, puis le code qui le fait passer).

   parle à Amelia — implémente la story EXP-1 en suivant le story file

3. Revue de code — une revue adversariale qui traque les cas limites et vérifie les critères d'acceptation.

En appui de cette boucle, BMAD propose un suivi de sprint (identification des risques), une correction de trajectoire en cours de sprint, et une rétrospective une fois l'epic terminé.

Le concept clé : le story file auto-suffisant

C'est LE point qui distingue BMAD du vibe coding, alors insistons. Chaque user story est un fichier qui embarque tout son contexte :

• les tâches à réaliser,
• les critères d'acceptation,
• les notes d'architecture pertinentes,
• un Dev Agent Record (le journal de l'agent développeur),
• une File List (les fichiers touchés),
• un Change Log.

Conséquence directe : l'agent développeur n'a pas besoin de relire tout l'historique de conversation pour coder proprement. Le contexte utile est déjà dans la story. On évite ainsi la dérive de contexte, cette lente dégradation où l'IA « oublie » les décisions prises trois messages plus tôt. Le story file, c'est en somme une fiche de mission complète et refermable sur elle-même.

Le tableau des personas

À savoir honnêtement

Un bon tutoriel ne vend pas du rêve. Voici trois vérités à garder en tête.

1. Le coût en tokens peut être élevé. Le pipeline complet fait travailler plusieurs agents et recharge de gros documents (PRD, architecture, project-context, story files) à chaque étape. Pour un simple bugfix, c'est de l'overkill : vous paieriez cher un cadrage inutile. C'est précisément pour ça que la quick lane existe — servez-vous-en sans culpabiliser pour les petites tâches.

2. La confusion V4/V6 est partout. Beaucoup de vidéos et d'articles montrent encore l'ancienne V4, avec d'autres personas et des commandes différentes. Si un tuto vous parle de slash-commands ou de personas que vous ne retrouvez pas dans le tableau ci-dessus, il est périmé. En V6 : des skills en langage naturel, et les six personas Mary, Paige, John, Sally, Winston, Amelia.

3. Le vrai atout, c'est le story file auto-suffisant. Au-delà de l'orchestration multi-agents qui impressionne, la valeur durable de BMAD tient dans ce fichier qui encapsule son contexte. C'est ce qui rend le code généré reproductible, traçable et robuste face à la dérive de contexte — là où le vibe coding s'effondre dès que la conversation s'allonge.

Conclusion : quand utiliser BMAD ?

La règle est simple. Sortez le pipeline complet quand vous attaquez une vraie fonctionnalité : plusieurs écrans, des règles métier, des choix d'architecture, un travail qui s'étale sur plusieurs stories. L'investissement en planification est alors largement rentabilisé par la qualité et la lisibilité du résultat.

Restez sur la quick lane — voire sur votre workflow habituel — pour un bug isolé, un petit refactor ou un ajustement cosmétique. Le cadrage lourd n'apporterait rien.

Et si vous hésitez sur la marche à suivre, BMAD embarque une aide intégrée. La skill bmad-help analyse l'état de votre projet et vous recommande la prochaine skill à lancer :

run bmad-help — par où commencer ?

Pour approfondir, explorez le dépôt officiel : github.com/bmad-code-org/BMAD-METHOD. Vous y trouverez la documentation à jour de la V6, les workflows du module bmm, et de quoi construire vos propres agents avec bmb. Bonne planification — et surtout, arrêtez de deviner.