BMad-Method est un framework AI complet et bien structuré pour piloter un projet tech. Elle repose sur un système d’agents spécialisés qui ont chacun un nom, un rôle défini, et leur propre ensemble de commandes. Cette organisation donne un aspect humain à l’interaction et reproduit la dynamique d’une vraie équipe projet, avec une séparation claire des responsabilités.

Chaque agent peut être interrogé pour clarifier, expliquer ou approfondir les tâches en cours. L’interface permet une grande interactivité, ce qui est appréciable pour bien comprendre les étapes et adapter la réflexion au fil de l’eau.

GitHub – bmadcode/BMAD-METHOD: Breakthrough Method for Agile Ai Driven Development

Je l’ai testée sur un nouveau projet, avec principalement Claude Opus lors de la phase de conception puis Claude Sonnet lors du développement des premières fonctionnalités.

Étapes clés de la méthode

1. Définition du brief

J’ai opté pour une saisie vocale du brief, pour aller plus vite. L’agent “analyst” dédié aide ensuite à clarifier, enrichir et structurer ce brief. On peut également lancer une analyse marketing et business en parallèle avec un autre agent.

2. Réalisation du Product Requirements Document (PRD)

C’est une phase centrale. Le PRD peut être généré automatiquement (mode YOLO) ou construit pas à pas (mode interactif, que j’ai choisi). L’agent “pm” (product manager) guide alors section par section, posant des questions pour affiner les besoins, challenger les choix et structurer l’ensemble. C’est long, fastidieux, mais indispensable.

3. Réalisation du documents d’architecture

Une fois le PRD validé, on enchaîne sur la conception technique : stack, base de données, schémas API, etc. Là encore, c’est détaillé, progressif et bien structuré grace à l’agent “architect”.

4. Découpage des stories

Ce découpage intervient une fois le PRD et les documents d’architecture validés. Les fonctionnalités sont réparties par Epic, puis découpées en Stories successivement par les agents “po” (product owner) et “sm” (scrum master). Chaque story représente une unité de travail cohérente, complète et prête à être implémentée.

5. Implémentation

L’agent “dev” (developer) se charge d’implémenter la fonctionnalité et de produire le code. L’agent “qa” (quality assurance), lui, assure la revue, le respect des critères d’acceptance et la qualité globale. De nombreux allers-retours peuvent être nécessaires entre les deux et cette dynamique peut ralentir le process si on cherche une exécution rapide d’autant plus qu’il faut mettre régulièrement la main à la patte entre les deux.

Le cycle d’exécution est en réalité beaucoup plus complexe et complet. Il est défini sur la documentation officielle ici https://github.com/bmadcode/BMAD-METHOD/blob/main/bmad-core/user-guide.md#the-planning-workflow-web-ui

Points forts

• CLI bien pensée : tous les fichiers essentiels sont intégrés dans le projet selon l’environnement de dev choisi.
• Approche incrémentale : chaque étape est interactive, avec des options pour approfondir, reformuler ou compléter.
• Documentation solide : un vrai plus d’avoir un document d’architecture clair, qui sert de référence aux agents codeurs (évite de devoir parser toute la codebase).
• Sharding intelligent : les gros documents (PRD, architecture) sont automatiquement segmentés, facilitant leur traitement par les agents.

Points faibles

• Processus initial lourd : avant d’écrire une seule ligne de code exploitable, il faut jongler entre plusieurs agents, ce qui ralentit considérablement le démarrage.
• Consommation de tokens élevée : j’ai régulièrement dépassé les limites journalières et de 4h du plan Claude Max.
• Fragilité du système : une contrainte oubliée au départ peut casser la fluidité du process. Revenir en arrière en pleine implémentation est laborieux.
• Code généré perfectible : les premières versions contiennent souvent des micro-dettes techniques. Il faut plusieurs itérations pour avoir un résultat propre.
• Allers-retours fréquents : ce besoin d’ajustements en continu va un peu à l’encontre de la promesse initiale : prendre le temps de bien spécifier pour ensuite dérouler automatiquement.

La BMad-Method est pertinente pour structurer des projets complexes, où l’on a besoin d’une vision claire, documentée et rigoureuse dès le départ. Elle excelle sur la phase amont : PRD, architecture, stratégie.

En revanche, tout s’écroule lorsqu’on doit modifier des éléments structurants défini sur la phase de conception. Aussi la phase de delivery est en décalage avec le soin apporté à la préparation. Après tout ce travail, on s’attend à ce que l’implémentation soit plus fluide. Or, il faut encore repasser derrière les agents pour corriger, ajuster, ce qui limite un peu l’intérêt du dispositif pour des équipes réduites ou des projets à forte vélocité.

Bref retour sur BMad-Method was originally published in ekino-france on Medium, where people are continuing the conversation by highlighting and responding to this story.