BMAD expliqué aux coachs agiles

Les équipes que nous accompagnons développent de plus en plus avec des assistants de codeOutil d'IA qui écrit, modifie et explique du code dans le projet : Claude Code, Cursor, Codex, Copilot… BMAD s'installe à l'intérieur de ces outils.. Certaines le font « au feeling », c'est ce qu'on appelle le vibe codingDemander du code à une IA « au feeling », sans cadrage ni spécification, et accepter ce qui sort. Rapide pour un prototype, risqué pour un vrai produit.. D'autres cherchent un cadre, et l'un des plus en vue s'appelle BMADMéthode open source (licence MIT) pour développer du logiciel avec des assistants d'IA, en reprenant les rôles et les étapes de l'agilité. Le nom vient de « Breakthrough Method for Agile AI-Driven Development ».. Il a une particularité qui devrait intéresser tout coach agile : il reprend nos rôles, nos artefacts et nos rituels, et les confie à des agentsDans BMAD, une IA à qui l'on donne un rôle, un nom, des principes et un menu de tâches (Mary l'analyste, John le chef de produit…). C'est toujours le même modèle d'IA, cadré différemment. d'IA.

Cet article donne la vue d'ensemble. Trois parties détaillent ensuite les agents, les phases et la façon d'accompagner une équipe. Les mots soulignés en pointillés affichent leur définition au survol, ou au toucher sur un téléphone.

BMAD en une phrase

BMAD est une méthode open source¹ qui fait passer une idée de l'intuition au logiciel livré, en faisant travailler l'IA comme une équipe agile : chaque étape produit un document qui sert de contexte à la suivante, et les décisions importantes restent explicites.

C'est une approche spec-drivenDéveloppement guidé par la spécification : on écrit d'abord ce qu'il faut construire et pourquoi, puis l'IA code à partir de ce document. BMAD en fait partie. : on dit d'abord quoi construire et pourquoi, puis comment, et seulement ensuite on code. La méthode ajuste la quantité de cadrage à la taille du travail : une petite correction part directement en développement, une nouvelle application passe par toutes les étapes.

Ce qui va parler au coach

BMAD emprunte beaucoup à l'agilité :

• Des rôles. Une analyste, un chef de produit, une designer UX, un architecte, une développeuse : chacun est un agent avec un prénom, des principes et un menu de tâches. Voir les agents en détail.
• Des artefacts. Product briefRésumé d'une ou deux pages qui pose la vision du produit : pour qui, quel problème, quelle valeur, quel périmètre., PRDProduct Requirements Document : le document de référence du produit. Objectifs, utilisateurs, exigences, contraintes et critères de succès., architecture, epicsGros morceau de valeur, trop grand pour une itération, que l'on découpe en plusieurs stories. et storiesUser story : un petit besoin exprimé du point de vue de l'utilisateur, assez petit pour être réalisé et vérifié rapidement. : les documents que nos équipes connaissent, rédigés avec l'IA.
• Des rituels. Un contrôle de préparation« Implementation readiness » dans BMAD : avant de coder, on vérifie que PRD, architecture et stories sont cohérents. Verdict : OK, réserves ou échec. Proche d'une Definition of Ready. avant de coder, une rétrospectiveMoment où l'équipe regarde comment elle a travaillé, pour décider quoi améliorer. Dans BMAD, elle a lieu à la fin de chaque epic. à la fin de chaque epic, et un correct courseWorkflow BMAD pour gérer un changement important en cours de route : il propose un plan mis à jour ou une réorientation, plutôt que de continuer sur l'élan. quand le plan ne tient plus.
• De la confrontation. Le party modeMode de BMAD qui réunit plusieurs agents dans une même conversation : ils répondent chacun dans leur rôle, se contredisent et rebondissent sur les idées des autres. met plusieurs agents autour de la table, et l'élicitation avancéeOutil BMAD qui « pousse » un brouillon pour le sortir de la réponse la plus probable : pré-mortem, avocat de l'autre camp, questions socratiques, audit des hypothèses… challenge un brouillon avec des techniques que les coachs utilisent déjà : pré-mortemImaginer que le projet a échoué, puis raconter pourquoi. Fait remonter les risques que l'optimisme du départ cache., steelmanL'inverse de l'homme de paille : reformuler l'argument adverse sous sa forme la plus solide avant d'y répondre., questions socratiques.

Les quatre phases

1. Analyse (facultative) : explorer le problème, faire des recherches, écrire un product brief ou une PRFAQExercice inventé chez Amazon : écrire le communiqué de presse et la foire aux questions du produit avant de le construire, pour tester si l'idée tient..
2. Planification : rédiger le PRD et, si besoin, concevoir l'expérience utilisateur.
3. Conception de la solution : fixer l'architecture, découper en epics et stories, vérifier que tout est prêt.
4. Implémentation : développer, revoir le code, faire la rétrospective.

Voir les phases et leurs documents en détail.

La place du coach

Le point le plus intéressant pour nous est un absent. Les premières versions de BMAD avaient un agent Scrum Master. Il a été fondu dans l'agent développeur en avril 2026, avec la version 6.3² : la planification de sprint est devenue une tâche technique parmi d'autres. L'outil prend en charge le suivi, mais pas la facilitation, la dynamique d'équipe ou le sens.

C'est là que le coach a un rôle à jouer :

• Garder l'humain aux commandes. BMAD le revendique : l'IA rend les décisions explicites, mais c'est l'équipe qui décide. Encore faut-il qu'elle relise vraiment, et qu'elle ose dire non.
• Éviter le cargo cultReproduire les rituels d'une méthode sans en comprendre le sens, en espérant obtenir les mêmes résultats.. Produire un PRD de trente pages parce que « BMAD le fait » n'a pas de sens pour une correction de deux lignes.
• Faire vivre les vraies conversations. Un party mode entre agents ne remplace pas un affinage avec les utilisateurs.

Voir comment accompagner une équipe qui adopte BMAD.

Regard critique

Côté forces, BMAD donne un cadre là où beaucoup d'équipes improvisent. Il garde une trace écrite des décisions, et il remet l'analyse et l'architecture à leur place, avant le code. Ses outils de confrontation sont réellement utiles, y compris hors de l'informatique.

Côté vigilance, l'enchaînement des documents peut glisser vers une petite cascade, si l'on oublie de livrer tôt et d'écouter les utilisateurs. Une équipe d'agents qui « débattent » reste un seul modèle d'IA qui joue plusieurs rôles : il ne remplace pas la diversité de vrais points de vue. Enfin, l'outil évolue très vite. La version stable est la 6.12 (septembre 2026), la version 7 est annoncée pour la mi-novembre 2026, et des rôles apparaissent ou disparaissent d'une version à l'autre. C'est une raison de plus pour s'attacher aux principes plutôt qu'aux noms des agents.

Le pense-bête

À retenir	En une ligne
Ce que c'est	Une méthode open source pour développer avec l'IA comme une équipe agile
Le principe	Chaque étape produit un document qui sert de contexte à la suivante
Les rôles	Des agents nommés : analyste, chef de produit, UX, architecte, développeur
Le grand absent	Le Scrum Master, fondu dans le développeur en 2026
La place du coach	Facilitation, sens, humain aux commandes, juste dose de cadrage

Sources

1. Dépôt officiel de la méthode BMAD, GitHub, en anglais. La page d'accueil du projet : ce qu'est la méthode, les versions disponibles (stable et en préparation), l'installation et la licence. ↑

2. Historique des versions de BMAD, en anglais. Le détail de chaque version, avec leur date : on y lit par exemple la fusion de l'agent Scrum Master dans l'agent développeur (version 6.3). La documentation officielle est en anglais ; la version 6 en propose une traduction française, que la version 7 en préparation ne prévoit plus. ↑