BMAD : Quand l'IA apprend à travailler en équipe

Auteur : Luigi Mulè

Comment passer du vibe coding chaotique à une ingénierie pilotée par des agents IA et ce que ça change vraiment.

Le génie sans mémoire

Imaginez que vous ayez accès au développeur le plus brillant jamais rencontré. Il comprend votre demande en quelques secondes, écrit du code à une vitesse vertigineuse, et ne rechigne jamais à la tâche. Ce développeur, c'est l'IA.

Cependant, malgré toutes ces qualités, au bout de trois semaines, votre projet devient un amoncellement de morceaux dénué de toute logique et empli de bugs.

Pourquoi ?

La réponse est en fait très simple : ce développeur de génie travaille sans spécification, sans plan, sans architecture. Il improvise à chaque session, puis oublie tout dès qu'elle se termine.

Bienvenue dans le quotidien de presque tous ceux qui codent avec l'IA aujourd'hui :

• On colle une idée dans un prompt.
• L'IA génère du code.
• On recolle la réponse dans un autre prompt.
• On corrige un bug.
• On perd le fil après vingt messages.
• On recommence dans une nouvelle fenêtre, depuis zéro, parce que le contexte s'est évaporé.

Ce sont les principaux défauts du vibe coding.

Coder à l'instinct, au feeling, sans discipline, c'est rapide, séduisant, mais c'est structurellement fragile.

On incrimine donc l'IA, sauf que la vérité est ailleurs : on confie le travail à l'IA sans lui donner de rôle. On lui demande de tout faire à la fois : analyser, concevoir, implémenter, vérifier. Tout cela dans une seule conversation qui finit par s'effondrer sous son propre poids.

Et si je vous disais que l'IA pouvait travailler autrement, avec des rôles définis, des décisions validées, et ce avant d'écrire la moindre ligne ? Et si on lui ajoutait une mémoire qui survit à la fin de la session ? Ça laisse rêveur ?

Eh bien c'est exactement ce que BMAD propose.

Qu'est-ce que BMAD ?

La solidité à long terme d'une application ne repose pas sur le talent d'un seul contributeur, mais sur une organisation structurée : des rôles précis, des décisions partagées et une chaîne de responsabilité claire.

C'est là que BMAD (Breakthrough Method of Agile AI-Driven Development) intervient, en appliquant cette organisation à votre travail avec l'IA.

Concrètement, BMAD est un framework open source. Cela signifie que son code est public, gratuit, et que chacun peut l'utiliser, le modifier ou le redistribuer comme il l'entend. C'est ce que garantit sa licence MIT.

Son principe tient en une idée : structurer le développement logiciel autour d'agents IA spécialisés. Chaque agent porte un rôle, produit des livrables précis, et ne déborde jamais sur le terrain des autres.

Derrière l'acronyme officiel, les créateurs glissent une seconde lecture, un brin plus rêveuse :

Build More Architect Dreams.

On pourrait résumer la philosophie de ce framework en une phrase :

Aucune ligne de code avant que les fondations soient posées.

Posées, ne signifie pas figées pour autant : ces fondations sont des documents versionnés, que l’on fera évoluer avec le projet. L’important est qu’elles existent avant que l’IA ne commence à coder.

ATTENTION !

BMAD n'est pas un chatbot amélioré : vous ne discutez pas avec une intelligence unique qui répond à tout. Ce n'est pas non plus un générateur de prompts. Il ne s'agit pas d'optimiser une formulation pour obtenir une meilleure réponse. Et surtout, ce n'est pas un substitut à la réflexion. BMAD organise et aiguille votre pensée, il ne la remplace pas.

Les rôles d'une équipe BMAD

Plutôt qu'une liste figée, voyez BMAD comme une équipe que vous dirigez. Le framework embarque cinq agents qui portent tous des prénoms, comme l'Analyste Mary ou l'Architecte Winston, pour rendre la collaboration plus naturelle. Voici, à titre illustratif, les grands archétypes que l'on retrouve dans le pipeline :

À ces rôles s'ajoutent deux fonctions assurées par le pipeline plus que par un agent unique :

• la vérification, qui contrôle la conformité du code aux critères d'acceptation,
• la documentation, produite au fil du développement plutôt qu'après coup.

Dans les premières versions, des agents dédiés s'en chargeaient. Aujourd'hui, elles sont intégrées au flux : chaque implémentation passe par une revue avant d'être présentée, et les documents produits en amont (PRD, architecture, spécifications) font office de documentation.

Une fois l'équipe en place, reste à savoir comment elle travaille.

Et c'est là que BMAD impose sa règle d'or.

Planifier avant de coder

Comme nous l'avons évoqué précédemment, BMAD repose sur une règle qu'il n'enfreint jamais :

On ne génère pas de code tant que les décisions structurantes ne sont pas prises et validées.

Le travail se déroule en deux phases, et l'ordre n'est pas négociable : d'abord on planifie, ensuite on construit.

Phase 1 : Poser les fondations avant la première ligne de code

L'objectif de cette première phase est brutalement simple : ne rien implémenter avant d'avoir des réponses solides à trois questions.

1. Quoi construire ? C'est le rôle du PRD.
2. Comment le construire ? C'est le rôle du document d'architecture.
3. Dans quel ordre ? C'est la décomposition en epics, stories et tasks.

Mais ces réponses ne tombent pas du ciel, et l'IA ne vous les sert pas toutes faites. Cette première phase est avant tout une conversation, un véritable aller-retour où l'agent vous interroge, vous pousse dans vos retranchements, et vous oblige à formuler ce que vous aviez laissé dans le flou. C'est là que la vision se précise, que la direction se choisit, que le périmètre se dessine.

Concrètement, ça ressemble à ça. Vous écrivez « je veux une application de suivi de dépenses ». L'Analyste ne répond pas « d'accord, je m'y mets » : il vous questionne. Pour qui : des particuliers, des équipes ? Que se passe-t-il si deux personnes modifient la même dépense en même temps ? Le mode hors-ligne est-il indispensable, ou un simple confort ? Qu'est-ce qui, dans six mois, vous fera dire que le projet est réussi ? Et, la question qu'on oublie toujours, qu'est-ce qui est explicitement hors périmètre ?

Chaque question referme une zone d'ombre. Vous tranchez le scope, vous nommez les cas limites, vous écartez les fausses bonnes idées. Ce n'est pas l'IA qui décide à votre place : c'est elle qui vous force à décider, là où, seul, vous auriez foncé tête baissée. À la fin de l'échange, vous n'avez pas seulement un document, vous avez une pensée claire.

Chaque étape transforme alors un peu plus cette intention, désormais nette, en plan exécutable :

Phase 1 : De l'idée au plan exécutable

Chaque étape produit un document.

Ce qu'il faut retenir de ce schéma, ce n'est pas tant la liste des étapes que la forme des livrables. Tous ces documents sont des fichiers Markdown, rangés dans votre dépôt, que vous versionnez au même titre que le code. Ce ne sont donc pas des messages perdus dans une fenêtre de chat ou des notes qui disparaissent à la session suivante, mais de vrais documents traçables que l'on peut relire, commenter et faire évoluer.

Phase 2 : Donner à chaque agent uniquement son contexte

La seconde phase repose sur une idée qui peut sembler contre-intuitive : chaque agent ne reçoit que ce dont il a besoin, et jamais tout le contexte.

Exemple : l'agent Développeur. Il reçoit la story qu'il doit implémenter, l'architecture validée en amont et les critères d'acceptation. Il ne reçoit pas les autres stories, ni l'historique des discussions, ni les pistes abandonnées en cours de route.
Pourquoi le priver d'informations ? Notre instinct nous dit qu'un agent mieux informé travaillera mieux. C'est vrai, mais seulement jusqu'à un certain point. Au-delà, un modèle de langage noyé sous des dizaines de milliers de tokens se met à dériver : il hallucine, invente des liens entre des éléments qui n'en ont pas, et finit par prendre des décisions que personne n'a validées. En lui donnant un périmètre précis, on s'assure qu'il fait ce qu'on lui demande, et seulement ça.
BMAD va d'ailleurs assez loin dans cette logique, puisqu'il calibre la taille de ses spécifications : un seul objectif par spécification, pour une cible de 900 à 1 600 tokens. En dessous, on risque l'ambiguïté. Au-dessus, l'agent chargé d'implémenter commence à perdre le fil.
Cette discipline porte un nom : le context engineering. L'idée est simple : donner à chaque agent ce qu'il lui faut pour faire son travail, ni plus ni moins.
Voyons ce que ça donne en pratique ?

Pour y voir plus clair, installons BMAD et regardons-le travailler sur un cas concret.

L'installation

Avant toute chose, vérifions les prérequis : Node.js 20.12 ou plus, Python 3.10 ou plus, ainsi que le gestionnaire de paquets uv. Ensuite, une seule commande suffit pour installer le framework dans votre projet :

npx bmad-method install

Cette commande crée un dossier dédié qui contient la configuration de la méthode, et installe dans votre outil les agents et les workflows sous forme de skills. On y retrouve les définitions des agents (c'est-à-dire les prompts qui leur donnent leur rôle) ainsi que les templates de PRD, d'architecture et de stories. Les documents produits, eux, sont rangés dans un dossier de sortie séparé. Pas de magie ici : ce sont de simples fichiers texte, que vous pouvez lire et modifier comme bon vous semble.
Côté compatibilité, l'installateur prend en charge plus d'une quarantaine d'outils, parmi lesquels Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI ou encore Windsurf. Vous n'avez donc pas à changer d'outil : c'est votre façon de travailler avec qui change.

Cas concret : une API de gestion de tâches

Prenons une demande comme on en reçoit tous les jours :

« Je veux une API pour gérer des tâches. Les utilisateurs peuvent créer, éditer, supprimer des tâches. Il y a des priorités. »

Le besoin est mal spécifié, trop superficiel. L'Analyste va donc chercher à préciser la demande et à la cadrer. Pour ce faire, il va poser de nombreuses questions :

« Y a-t-il plusieurs utilisateurs ? On parle de priorités, cela implique-t-il une notion de date limite ? Les utilisateurs doivent-ils recevoir des notifications ? » Etc.

Une fois les réponses données, notre vision de départ, qui était floue, se précise et devient exploitable. L'Analyste la consigne dans un brief : un document court qui résume le besoin, les utilisateurs visés et le périmètre du projet.

C'est alors au Product Manager de prendre le relais. À partir du brief, il rédige le document de référence du produit : le PRD (Product Requirements Document). Il va décrire ce que l'application doit faire, pour qui, et selon quels critères on considérera qu'elle remplit son rôle. Dans le cas de notre API, on y trouvera par exemple la création et la modification des tâches, la gestion des priorités ou encore l'authentification des utilisateurs.

Vient ensuite le tour de l'Architecte. Il aide à déterminer la stack (Node.js ou Java, PostgreSQL…), dessine le schéma de la base de données avec ses tables, et fixe les conventions de notre API. Toutes ces décisions sont consignées dans le document d'architecture, à côté du PRD.

Il ne reste plus qu'à découper le travail. Le PRD et l'architecture sont décomposés en epics et en stories, chacune accompagnée de ses critères d'acceptation. Voici à quoi ressemble l'une d'elles :

Epic 1 : Authentification

Story 1.1 : Inscription utilisateur

En tant qu'utilisateur, je veux m'inscrire pour accéder à mon espace.
Critères d'acceptation :

• [ ] Email unique validé
• [ ] Mot de passe hashé (bcrypt)
• [ ] JWT retourné en réponse

Comme vous pouvez le voir, chaque story exprime une intention claire, avec des critères vérifiables. La formule « il faut une authentification sécurisée », bien trop vague, devient trois conditions que l'on peut cocher… ou non. L'exigence devient donc contrôlable.

C'est seulement à ce moment-là que le Développeur entre en jeu. Il reçoit la Story 1.1, le schéma de base de données et les conventions d'API, puis il implémente la story. Il commence par écrire les tests qui traduisent les critères d'acceptation, puis le code qui permet de les faire passer. Enfin, avant de vous rendre la main, le changement passe en revue.

Quand les agents débattent : le Party Mode

Mais que faire lorsqu'aucune option ne s'impose ? C'est là qu'intervient le Party Mode. Ce mode réunit plusieurs agents (ou des personas que vous définissez vous-même) dans une même conversation, pour qu'ils confrontent leurs points de vue. L'un va défendre la solution la plus simple, un autre jouer l'avocat du diable, un troisième pointer la dette technique qui se profile. À vous ensuite de trancher.
Nous avons maintenant vu comment BMAD fonctionne. Reste une question que tout lead finira par se poser : qu'est-ce que ça change vraiment, et qu'est-ce que ça ne réglera pas ?

Les gains réels et les illusions à éviter

BMAD apporte de vrais changements, mais ce n'est pas une solution miracle. Il est important d'avoir les deux en tête pour ne pas être déçu.

Ce que BMAD ne résout pas

Un coût de démarrage réel

Il faut installer le framework et ses prérequis, rédiger un PRD complet, valider une architecture : tout cela représente plusieurs heures de travail avant d'écrire la moindre ligne de code. BMAD propose désormais des parcours allégés pour les petits changements, mais le circuit complet reste lourd. Pour un proof of concept d'une journée, il est clairement disproportionné.

Garbage in, garbage out

La qualité de toute la chaîne dépend de la qualité de la demande de départ. Un brief vague donnera un PRD vague, puis une architecture floue, et au bout du compte un code qui ne répond à rien. BMAD ne transforme pas une mauvaise idée en bon logiciel : il reproduit fidèlement ce qu'on lui donne, en bien comme en mal. Cela a toujours existé, certes. Un développeur avec un ticket mal rédigé fait des erreurs et c'est la même chose avec l'IA. Ce n'est pas une solution miracle.

BMAD ne réfléchit pas à votre place

Avoir un agent Architecte ne vous dispense pas de comprendre ce qu'il vous propose. Une architecture peut sembler cohérente et être pourtant complètement inadaptée à votre contexte. Si vous validez sans lire, vous laissez l'IA décider pour vous, ce qui est précisément ce que la méthode cherche à éviter.

Les documents ne se mettent pas à jour tout seuls

Si vous ne faites pas évoluer les artefacts quand les besoins changent, ils deviennent obsolètes. Et une spécification obsolète est pire que pas de spécification du tout, car on continue à lui faire confiance. BMAD fournit bien un workflow pour réviser le plan en cours de route (PRD, architecture ou découpage), encore faut-il penser à le lancer.

Une courbe d'apprentissage

Le premier projet avec BMAD est lent, le deuxième un peu moins, et ce n'est souvent qu'au troisième que la méthode devient naturelle. Il faut accepter cet investissement de départ.

Un framework qui évolue très vite

Entre mars et octobre 2026, BMAD est passé de la version 6.1 à la 6.12. Entre-temps, certains agents ont disparu (le Scrum Master et le QA dédiés) et plusieurs workflows ont été renommés ou fusionnés. C'est plutôt bon signe pour un projet open source, mais c'est aussi une contrainte pour une équipe : chaque mise à jour mérite d'être lue avant d'être appliquée, et une procédure interne rédigée il y a six mois peut déjà ne plus être valable.

Pour les tech leads : la traçabilité des décisions

Pour un tech lead, c'est probablement l'argument le plus fort. Chaque choix technique est consigné dans l'architecture, chaque fonctionnalité répond à une story, chaque story à un epic, et chaque epic au PRD. On peut donc remonter de n'importe quelle ligne de code jusqu'au besoin métier qui l'a justifiée.
Quand un nouveau développeur rejoint l'équipe, il n'a plus besoin de demander « pourquoi avez-vous fait ça ? » : la réponse est écrite quelque part dans le dépôt.

Quand utiliser BMAD et quand s'en passer ?

BMAD n'est pas fait pour tous les projets. Voici une checklist pour vous aider à savoir s'il est adapté au vôtre.

✅ BMAD est fait pour vous si :

• Votre projet s'étend au-delà de deux semaines.
• Plusieurs développeurs, ou plusieurs agents, travaillent sur le même codebase.
• La maintenabilité à long terme est une vraie contrainte pour vous.
• Vous devez tracer vos décisions, pour des raisons de conformité, d'audit ou d'onboarding.
• Vous voulez structurer votre usage de l'IA sans perdre en vélocité.

⚠️ BMAD n'est probablement pas adapté si :

• Vous faites une modification évidente et sans risque.
• Vous construisez un proof of concept jetable en moins de deux jours : les parcours allégés de BMAD peuvent suffire, mais le circuit complet serait du gaspillage.
• Vous êtes seul, le périmètre est clair, et vous connaissez la stack par cœur.
• Votre équipe refuse toute discipline documentaire. Attention toutefois : BMAD peut justement servir de prétexte pour l'introduire en douceur. C'est donc un risque à anticiper, pas forcément une raison de renoncer.

🚨 Les signaux qui, après coup, montrent que BMAD vous aurait aidé :

• Vous refactorisez quelque chose qui « fonctionnait », parce que ce n'était prévu nulle part.
• Vous ne savez plus pourquoi une fonctionnalité a été implémentée de cette façon.
• Chaque session avec l'IA repart de zéro, parce que le contexte s'est perdu en route.
• L'IA a « décidé » d'une implémentation que personne n'avait validée.

Si cette dernière liste vous parle, c'est sans doute le signe que BMAD mérite d'être essayé.

Le développeur n'a pas disparu. Il a changé de métier.

BMAD ne remplace pas le développeur, il fait évoluer son rôle. Plutôt que d'enchaîner les prompts, il devient celui qui dirige l'équipe : il définit les rôles, valide les décisions, arbitre les désaccords entre agents et garde la main sur ce qui compte vraiment.
L'IA écrit du code bien plus vite que n'importe quelle équipe humaine, mais elle ne produit que ce qu'on lui demande. La valeur du développeur ne se mesure donc plus au nombre de lignes qu'il écrit, mais à sa capacité à poser les bonnes questions, à valider les bonnes décisions et à prendre le temps de réfléchir avant de lancer la machine.
Le vibe coding misait tout sur la vitesse, au détriment de la cohérence. BMAD fait le pari inverse : accepter d'aller un peu moins vite au départ pour garder le cap sur la durée. Ce n'est pas une recette miracle, et ce n'est pas adapté à tous les projets, mais quand il est utilisé à bon escient, il permet de transformer une suite d'improvisations brillantes en un projet qui tient debout.
Notre génie sans mémoire du début, lui, n'a pas changé. Il a désormais un rôle, un plan et une mémoire qui survivent à la fin de la session.

Structurez d'abord. Codez ensuite.