Le vibe coding, c’est-à-dire écrire du logiciel en dialoguant avec une intelligence artificielle prompt après prompt, séduit par sa rapidité, mais s’effondre sur un vrai projet : le contexte se perd entre les sessions et les incohérences s’accumulent. BMAD (Breakthrough Method for Agile AI-Driven Development, méthode agile de développement piloté par l’IA) est un framework open source conçu pour résoudre exactement ce problème, en encadrant le travail de l’IA. Cet article explique comment il fonctionne, phase par phase et agent par agent. Il s’adresse aux architectes, aux consultants et aux décideurs techniques qui veulent industrialiser le développement assisté par IA.

• Qu’est-ce que BMAD, et quels agents le composent ?
• Comment se déroulent ses quatre phases de travail ?
• Comment garde-t-il en mémoire le contexte d’un projet sans le perdre ?
• Comment l’adapter à ses propres besoins ?

Qu’est-ce que BMAD ?

BMAD combine deux choses : une méthode agile et une bibliothèque d’agents IA spécialisés. Son principe fondateur tient en une phrase : les spécifications sont la source de vérité, et le code n’en est qu’un dérivé. Autrement dit, ce qui fait autorité sur le projet, ce sont les documents qui décrivent quoi construire, pas le code produit. La documentation officielle est disponible sur docs.bmad-method.org et le code source sur le dépôt GitHub du projet.

Pour organiser ce travail, BMAD reproduit une véritable équipe projet : six agents, chacun jouant un rôle précis.

Agent	Rôle	Intervient en
Mary, l’Analyst	Valide l’idée et le concept	Phase 1
John, le Product Manager	Définit quoi construire	Phase 2
Sally, l’UX Designer	Conçoit l’interface	Phase 2
Winston, l’Architect	Justifie les choix techniques	Phase 3
Amelia, la Developer	Implémente story par story	Phase 4
Paige, la Technical Writer	Maintient la documentation	Transverse

Ces six agents ne travaillent pas en même temps, mais en séquence, à travers quatre phases. Chaque phase produit des documents qui alimentent la suivante. Voici les quatre phases, formulées comme les questions auxquelles elles répondent :

1. Analyse : l’idée mérite-t-elle d’être construite ?
2. Planification : quoi construire, et pour qui ?
3. Design de la solution : comment la construire, et est-ce cohérent ?
4. Implémentation : comment produire du code de qualité, de façon itérative ?

Les workflows, le moteur de BMAD

Entre les phases et à l’intérieur de chacune, tout est orchestré par plus de trente-quatre workflows. Un workflow, dans BMAD, est un processus guidé étape par étape, défini dans un fichier au format YAML (un format de texte structuré et lisible, utilisé pour décrire des configurations), qui pilote le travail d’un agent sur une tâche précise. Ce n’est pas un simple prompt : c’est un scénario structuré que l’agent déroule en dialoguant avec l’utilisateur.

Chaque workflow réunit trois caractéristiques :

• Un agent porteur : le workflow est exécuté par un agent précis, dont la personnalité, les compétences et le style sont adaptés à la tâche.
• Un processus structuré : des étapes, des questions et des validations intermédiaires, et non une conversation libre.
• Un artefact en sortie : un fichier Markdown versionné qui devient le contexte de l’étape suivante.

Comment utilise-t-on BMAD au quotidien ?

BMAD s’utilise dans un environnement de développement comme Claude Code, Cursor, Windsurf ou Visual Studio Code. L’expérience est conversationnelle : l’utilisateur charge un agent, en ligne de commande (CLI, Command Line Interface, l’interface où l’on tape des instructions au clavier) ou dans le chat de l’éditeur, puis se laisse guider.

À tout moment, une commande d’aide analyse l’état du projet et recommande l’étape suivante, comme un GPS de projet. L’utilisateur s’exprime en langage naturel, les workflows le guident, et les artefacts s’accumulent dans Git, le système qui archive l’historique des versions du projet.

Les quatre phases en détail

Reprenons chaque phase dans l’ordre, avec l’agent qui la porte et le document qu’elle produit.

Phase 1 : analyse (optionnelle)

Mary, l’agent Analyst, facilite le brainstorming, mène la recherche sur le marché, le domaine et la technique, et propose deux chemins pour valider une idée avant de la planifier. Le but est de s’assurer que l’idée mérite d’être construite.

• Le Product Brief : une exploration guidée où l’agent aide à cristalliser la vision du produit (son audience, sa proposition de valeur, son périmètre). Ce chemin convient quand le concept est déjà clair.
• Le PRFAQ (Press Release and FAQ, communiqué de presse et foire aux questions) : une adaptation de la méthode « Working Backwards » d’Amazon. On rédige le communiqué qui annoncerait le produit fini, puis on répond aux questions les plus difficiles des clients.

Là où le Product Brief demande « qu’est-ce qu’on construit ? », le PRFAQ demande « est-ce que ça mérite d’être construit ? ». BMAD appelle ce second chemin le gauntlet, littéralement le « parcours du combattant » : si le communiqué de presse ne convainc pas, c’est que le produit n’est pas prêt. Les deux chemins mènent au même endroit : une idée validée, qui alimentera le document de spécifications de la phase 2.

Phase 2 : planification

John, l’agent Product Manager, produit un PRD (Product Requirement Document, le document qui rassemble les exigences du produit) complet. Ce document contient les exigences fonctionnelles et non fonctionnelles, les epics (les grands regroupements de fonctionnalités), les critères d’acceptation et les métriques de succès.

En parallèle, Sally, l’agent UX Designer (UX pour User Experience, l’expérience utilisateur), produit les spécifications de l’interface. Le but de cette phase est de définir quoi construire, et pour qui, sans ambiguïté.

Phase 3 : design de la solution

Winston, l’agent Architect, documente chaque choix technique à l’aide d’ADR (Architecture Decision Records, des fiches de décision d’architecture). Un ADR est un document court qui capture une décision technique importante : le contexte qui l’a motivée, les options envisagées, celle qui a été retenue, et la raison de ce choix. C’est la mémoire des choix d’architecture du projet.

Ensuite, les agents Product Manager et Architect découpent les exigences de la phase 2 en stories implémentables. Une story est un petit lot de travail autonome, assez précis pour être développé et testé indépendamment des autres.

La Quality Gate avant le code

Avant de passer au code, une étape de contrôle nommée Quality Gate vérifie la cohérence de tous les documents produits jusque-là. Cette étape pose quatre questions de vérification :

• Chaque story est-elle reliée à une exigence du PRD ?
• L’architecture couvre-t-elle toutes les exigences, fonctionnelles et non fonctionnelles ?
• Les critères d’acceptation sont-ils réellement testables ?
• Existe-t-il des contradictions entre les spécifications ?

Le résultat de ce contrôle prend l’une des trois valeurs suivantes.

Verdict	Signification	Suite à donner
PASS	Tout est cohérent	On passe à l’implémentation
CONCERNS	Points d’attention identifiés	Les corriger ou avancer en connaissance de cause
FAIL	Incohérences majeures	Retour obligatoire en phase 2 ou 3

En clair, le verdict CONCERNS signale un point à surveiller : par exemple un critère d’acceptation ambigu, ou un NFR (Non Functional Requirement, une exigence non fonctionnelle comme la performance ou la sécurité) couvert par l’architecture mais absent des stories. On peut le traiter tout de suite, ou l’accepter en connaissance de cause. Le verdict FAIL signale une incohérence bloquante : par exemple des stories qui contredisent l’architecture, ou un PRD trop vague pour être implémenté. Le but de cette étape est d’empêcher de construire sur des fondations bancales.

Phase 4 : implémentation

Amelia, l’agent Developer, implémente le projet story par story, dans un cycle itératif : créer la story, développer la story, puis passer une revue de code. Cette revue est une seconde Quality Gate, qui vérifie que le code suit bien les spécifications et les règles de développement.

Chaque story contient tout le contexte nécessaire pour coder sans deviner. Le but de cette phase est de produire du code de qualité production, et non des prototypes fragiles.

La documentation, en transverse

En parallèle des quatre phases, Paige, l’agent Technical Writer, maintient la documentation à jour tout au long du projet. Elle génère des diagrammes Mermaid (un outil qui dessine des schémas à partir de texte) à la demande, et vérifie en continu la cohérence et la qualité de la documentation.

Les modes spéciaux

En dehors du parcours principal, BMAD propose deux modes de travail particuliers.

• Quick Dev : un parcours parallèle qui saute les phases 1 à 3 pour les petits travaux bien compris, comme les corrections de bugs ou les petits scripts. C’est le minimum de structure, sans la cérémonie complète.
• Party Mode : une session où plusieurs agents collaborent et débattent ensemble. Le Product Manager et l’Architect confrontent leurs arbitrages avant de figer une décision, comme dans une réunion d’équipe.

Context engineering : le secret de l’efficacité

Un problème de fond du vibe coding est que la fenêtre de contexte, c’est-à-dire la mémoire de travail limitée de l’IA, se remplit d’informations peu utiles. L’IA finit alors par « oublier » les décisions importantes, les règles et les consignes.

BMAD répond à ce problème par sa conception même, selon trois mécanismes.

1. Chaque phase produit des artefacts Markdown versionnés dans Git : la mémoire du projet est sauvegardée en permanence.
2. Chaque agent ne reçoit que les artefacts utiles à sa tâche, et non tout l’historique : sa fenêtre de contexte reste dégagée.
3. Un fichier project-context.md joue le rôle de « constitution » du projet (stack technique, conventions, règles de sécurité) et est chargé automatiquement par tous les workflows.

Grâce à ces trois mécanismes, tous les agents prennent des décisions cohérentes, même sur un projet de grande ampleur.

Personnaliser BMAD

BMAD n’est pas une boîte noire. Il autorise trois niveaux de personnalisation, du plus léger au plus profond.

1. Par agent : on injecte une persona métier, une mémoire persistante et des actions au démarrage. Par exemple, un Product Manager spécialisé dans la conformité DORA (Digital Operational Resilience Act, le règlement européen sur la résilience numérique du secteur financier), qui vérifie les exigences réglementaires au fil de l’eau.
2. Par projet : on impose la stack technique, les conventions de code et les règles de sécurité que tous les agents doivent respecter.
3. Par agent sur mesure : avec le BMAD Builder, on crée des agents entièrement nouveaux, dotés de leurs propres workflows, empaquetés en modules partageables.

Reste une question ouverte : comment BMAD se compare-t-il aux autres frameworks de développement agentique qui émergent, comme Superpowers ? Ce sera le sujet d’un prochain article. En attendant, la discussion se poursuit sur mon profil LinkedIn.