La méthode BMAD — Build More Architect Dreams — est un cadre de développement assisté par l’IA. Son objectif est de remplacer le prompt vague suivi d’une longue génération de code par un processus progressif : clarifier le besoin, produire des livrables, valider les décisions, implémenter par étapes et revoir le résultat.
BMAD appartient à la famille du Spec-Driven Development : l’intention, les exigences et le plan deviennent des artefacts versionnés que l’agent utilise comme contexte. Le code n’est plus produit directement depuis une conversation improvisée.
Le problème que BMAD cherche à résoudre
Un agent de code peut produire rapidement une fonctionnalité qui semble fonctionner tout en :
- interprétant mal le besoin ;
- choisissant une architecture non souhaitée ;
- oubliant un parcours utilisateur ;
- modifiant trop de fichiers à la fois ;
- perdant le contexte entre deux sessions ;
- validant son propre travail avec des critères trop faibles.
BMAD construit le contexte progressivement et introduit des points d’approbation humains. La méthode ne rend pas le modèle infaillible : elle rend ses décisions plus visibles et donc plus faciles à corriger.
Les quatre phases de BMAD
La carte officielle du BMad Method Module organise le travail en quatre phases.
1. Analyse — facultative
Cette phase sert à explorer un problème encore flou : utilisateurs, contraintes, opportunité, domaine et options. Elle est utile pour un nouveau produit ou une fonctionnalité structurante, mais excessive pour corriger une faute de frappe.
Livrable attendu : un brief ou un ensemble d’éléments suffisamment clairs pour décider ce qui mérite d’être construit.
2. Planification
Le besoin devient un PRD ou une spécification produit : objectifs, périmètre, parcours, exigences fonctionnelles et critères de réussite. Les ambiguïtés doivent être résolues avant l’architecture.
Un bon critère d’acceptation décrit un comportement observable. « L’interface doit être moderne » est trop vague ; « le formulaire affiche une erreur associée au champ et place le focus sur la première erreur » peut être testé.
3. Solutioning — conception de la solution
L’agent transforme le besoin en décisions techniques : architecture, modèles de données, contrats d’API, dépendances, sécurité et découpage en epics ou stories. Le développeur approuve ces décisions avant la génération massive de code.
Le principal bénéfice est la traçabilité : une décision technique doit répondre à une exigence, pas seulement refléter la préférence momentanée du modèle.
4. Implémentation
Les stories sont implémentées l’une après l’autre. Chaque unité possède son contexte, ses critères d’acceptation et ses vérifications. La documentation BMAD prévoit également revue et rétrospective fondées sur les preuves produites par les tests et le résultat réel.
Deux niveaux d’utilisation
BMAD n’oblige pas à lancer le processus complet pour chaque changement.
Pour une petite modification dans un dépôt existant, le skill bmad-build peut clarifier la demande, proposer un plan, attendre l’approbation, modifier le code et vérifier son travail.
Pour un projet plus important, les phases d’analyse, PRD, architecture et stories créent une chaîne de livrables plus formelle. Le choix du niveau de cérémonie est essentiel : une méthode trop lourde finit par être contournée.
Installer BMAD
La documentation actuelle demande Node.js 20.12 ou plus récent, Git et un outil de code compatible.
~~~bash npx bmad-method install --directory . --modules bmm --tools claude-code --yes ~~~
Pour une installation interactive :
~~~bash npx bmad-method install ~~~
L’installateur ajoute les agents, workflows, tâches et configurations au dépôt. Il génère les skills adaptés à l’outil choisi. Utilisez le canal stable et versionnez les fichiers produits ; en CI ou en entreprise, épinglez les modules externes afin qu’une réinstallation reste reproductible.
Commencez sur un changement peu risqué :
~~~text /bmad-build ajouter une validation accessible au formulaire d’inscription ~~~
Lisez les questions, corrigez le plan, puis approuvez l’implémentation. Le premier essai sert à évaluer la méthode, pas à lui confier immédiatement une migration critique.
Exemple de workflow concret
Prenons l’ajout d’un système de favoris.
- Intention : un utilisateur connecté peut enregistrer un article et retrouver ses favoris.
- Clarification : suppression possible, synchronisation multi-appareils, pas de favoris anonymes.
- Critères : le bouton reflète l’état, l’action est accessible au clavier, un doublon est impossible, un utilisateur ne lit pas les favoris d’un autre.
- Conception : table avec contrainte unique utilisateur/article, route authentifiée, mise à jour optimiste avec retour arrière.
- Tâches : migration, repository, route, composant, tests, métriques.
- Implémentation : une tâche et un diff relu à la fois.
- Validation : tests d’autorisation, concurrence, clavier, erreur réseau et rollback.
Cette chaîne est plus importante que le nom de l’outil. Une équipe peut l’appliquer sans BMAD.
Les alternatives à BMAD
GitHub Spec Kit
GitHub Spec Kit suit un workflow Constitution → Specify → Clarify → Plan → Tasks → Analyze → Implement → Converge. La constitution centralise les principes du projet ; chaque phase produit un artefact Markdown transmis à la suivante.
Choisissez Spec Kit si vous voulez un cadre explicitement centré sur les spécifications, compatible avec de nombreux agents et extensible par des quality gates. Il convient particulièrement aux équipes qui veulent formaliser leurs règles d’architecture et leurs contrôles.
OpenSpec
OpenSpec organise le changement selon Explore → Propose → Review → Apply → Archive. Une proposition contient le plan et les tâches ; une fois livrée, sa différence est absorbée dans les spécifications décrivant le système réellement construit.
OpenSpec est intéressant pour un produit existant : il met l’accent sur les deltas, l’historique des changements et le maintien d’une source de vérité après l’implémentation.
Kiro Specs
Kiro Specs génère trois artefacts principaux : requirements.md, design.md et tasks.md. Les Feature Specs cadrent une fonctionnalité, les Bug Specs analysent le défaut et les comportements à préserver, et Quick Spec compresse le processus.
Kiro convient si vous préférez une expérience intégrée où l’agent prépare la spécification, implémente les tâches et ouvre une pull request. Le compromis est une dépendance plus forte à l’environnement Kiro.
Claude Code en mode plan
Claude Code peut démarrer avec le mode plan, analyser le dépôt, proposer des étapes puis attendre l’autorisation avant d’éditer. Associé à un fichier CLAUDE.md, une spécification versionnée, des tests et une checklist de revue, il couvre une version légère du même besoin.
Cette approche convient aux petites équipes qui veulent peu de structure additionnelle. Elle dépend davantage de la discipline humaine : aucun workflow complet ne vous oblige à maintenir les artefacts.
SDD léger fait maison
Pour beaucoup de dépôts, quatre fichiers suffisent :
~~~text docs/changes/nom-feature/ ├── spec.md ├── design.md ├── tasks.md └── review.md ~~~
Ajoutez une règle : pas d’implémentation avant validation des critères ; une tâche correspond à un diff relisible ; les tests prouvent les critères ; la revue met à jour la spec si la réalité a changé.
Ce choix minimise la dépendance à un outil, mais l’équipe doit maintenir templates et qualité elle-même.
Tableau de choix
| Approche | Point fort | Coût de méthode | À privilégier pour |
|---|---|---|---|
| BMAD | Rôles, workflows et contexte progressif | Élevé sur le parcours complet | Projets complexes, équipe voulant un cadre guidé |
| GitHub Spec Kit | Spécifications et règles d’architecture | Moyen à élevé | Gouvernance, multi-agents, processus extensible |
| OpenSpec | Changements et specs maintenues dans le temps | Moyen | Produit existant et évolution incrémentale |
| Kiro Specs | Expérience intégrée de la spec à la PR | Moyen | Équipe utilisant déjà Kiro |
| Claude Code + plan | Souplesse et faible installation | Faible | Petites fonctionnalités et équipe expérimentée |
| SDD maison | Contrôle et indépendance | Variable | Organisation avec méthode interne stable |
Quand BMAD devient trop lourd
N’utilisez pas toutes les phases pour une correction locale dont le comportement attendu est évident. Les signes de surprocessus sont : davantage de temps à synchroniser les documents qu’à vérifier le résultat, répétition des mêmes informations, stories artificiellement découpées et validations approuvées sans lecture.
Adaptez la profondeur au risque. Un changement de texte peut suivre demande → diff → test. Une authentification ou une migration de données mérite exigences, menaces, architecture, plan de migration et rollback.
Limites communes à toutes ces méthodes
- Une spécification détaillée peut être fausse.
- L’agent peut produire des tests qui confirment sa propre interprétation.
- Les documents peuvent diverger du code si aucun rituel ne les met à jour.
- Plus de rôles agents ne signifie pas plus de perspectives réelles : ils peuvent partager les mêmes angles morts.
- Les workflows augmentent tokens, temps et surface de dépendances.
La protection vient des critères observables, de la revue humaine, de tests indépendants, de petits diffs et d’un déploiement réversible.
Méthode recommandée pour commencer
- Choisissez une fonctionnalité de deux à quatre heures.
- Rédigez cinq critères d’acceptation.
- Faites analyser le dépôt avant tout plan.
- Corrigez et approuvez le plan.
- Implémentez une tâche à la fois.
- Exigez tests et résumé du diff.
- Mesurez temps, défauts, retours en arrière et qualité de la documentation.
- Décidez ensuite si le processus complet apporte une valeur suffisante.
FAQ
BMAD remplace-t-il Scrum ou un product manager ?
Non. Il emprunte des concepts agiles et structure le travail de l’agent, mais ne remplace ni la découverte utilisateur, ni la priorisation, ni la responsabilité d’équipe.
BMAD est-il réservé à Claude Code ?
Non. L’installateur prend en charge plusieurs outils de code. Les skills générés dépendent de l’intégration sélectionnée.
Quelle est la différence entre BMAD et le vibe coding ?
Le vibe coding part souvent d’une intention courte et juge le résultat après génération. BMAD rend clarification, plan, architecture, tâches et revue explicites avant et pendant l’implémentation.
Quelle alternative choisir pour un dépôt existant ?
OpenSpec est naturellement orienté changements incrémentaux. BMAD et Spec Kit restent possibles si vous commencez par documenter le contexte réel du dépôt et limitez la première expérimentation à une fonctionnalité.
Peut-on automatiser BMAD sans validation humaine ?
Certains workflows permettent davantage d’autonomie, mais elle doit être réservée aux tâches réversibles, bien testées et exécutées dans un environnement isolé avec budgets et limites.