Les quatre phases de BMAD, document par document

L'idée centrale de BMAD tient en une phrase : une IA travaille mieux quand on lui donne un contexte clair. La méthode construit donc ce contexte étape par étape. Chaque phase produit des documents que la phase suivante lit.

Phase 1 : Analyse (facultative)

La question : pourquoi faire ce produit, et pour qui ?

On y explore le problème avant de s'engager. Plusieurs outils, tous facultatifs :

• Le brainstorming, animé par l'agent comme un facilitateur : il pose des questions et fait sortir les idées, plutôt que de les inventer à votre place.
• Les recherches : marché, domaine métier, faisabilité technique.
• Le 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., une ou deux pages pour poser la vision.
• La 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., pour tester l'idée selon l'approche Working Backwards« Travailler à rebours » : partir de l'expérience du client final et remonter vers ce qu'il faut construire. C'est l'esprit de la PRFAQ..

Dans une équipe agile, cela correspond à la discovery : ateliers d'idéation, entretiens utilisateurs, cadrage de la vision.

Phase 2 : Planification

La question : que faut-il construire, et pour qui ?

Le document clé est le PRDProduct Requirements Document : le document de référence du produit. Objectifs, utilisateurs, exigences, contraintes et critères de succès., qui rassemble les objectifs, les utilisateurs et les exigences fonctionnellesCe que le système doit faire (FR). On les distingue des exigences non fonctionnelles (NFR) : performance, sécurité, fiabilité, accessibilité… et non fonctionnelles. L'agent chef de produit sait le créer, le mettre à jour quand quelque chose change, ou le valider à l'aide d'une liste de contrôle. Si l'expérience utilisateur compte, l'agent UX produit sa conception.

On y retrouve la vision produit, les objectifs et le backlog de haut niveau.

Phase 3 : Conception de la solution

La question : comment le construire, et en quels morceaux ?

C'est le solutioningPhase 3 de BMAD : décider comment construire (architecture, choix techniques) avant de découper le travail. Évite que plusieurs agents fassent des choix contradictoires., la phase que BMAD défend le plus. L'architecte fixe les choix techniques dans un document d'architecture, avec des ADRArchitecture Decision Record : une courte fiche qui garde la trace d'une décision technique, de son contexte et de ses conséquences.. Le travail est ensuite découpé en epicsGros morceau de valeur, trop grand pour une itération, que l'on découpe en plusieurs stories. et en storiesUser story : un petit besoin exprimé du point de vue de l'utilisateur, assez petit pour être réalisé et vérifié rapidement., puis 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. vérifie que l'ensemble est cohérent avant d'écrire la moindre ligne de code.

La raison est très concrète. Sans architecture partagée, deux agents qui développent deux epics peuvent faire des choix incompatibles, par exemple deux styles d'API différents. La documentation de BMAD affirme qu'un problème d'alignement se corrige dix fois plus vite à ce stade que pendant le développement. C'est un ordre de grandeur bien connu des équipes, pas une mesure.

Côté agile, on reconnaît l'affinage du backlog, les décisions d'architecture et la Definition of ReadyCritères partagés par l'équipe pour décider qu'un élément du backlog est assez clair pour être commencé..

Phase 4 : Implémentation

La question : construire, vérifier, apprendre.

Tout converge vers une seule commande de développement, qui accepte une demande directe, un ticket ou une story planifiée. Elle décide elle-même du niveau de clarification, de planification et de revue nécessaire. Viennent ensuite :

• la revue de code, qui approuve ou demande des changements ;
• le 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 un changement important arrive en cours de route ;
• la 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.

La juste dose de cadrage

BMAD ne demande pas de tout faire à chaque fois. La méthode le dit clairement : un changement simple et clair peut aller directement en phase 4, et seule une initiative importante passe par toutes les étapes.

Le travail	Le parcours conseillé
Petite correction, bien comprise	Directement le développement
Fonctionnalité qui touche plusieurs parties liées	PRD léger, architecture si le risque de coordination est réel
Plusieurs epics, plusieurs systèmes	Les quatre phases
Projet réglementé ou à fort risque	Les quatre phases, avec la gouvernance exigée

Pour un coach, c'est le point à surveiller de près. Une équipe qui découvre l'outil a souvent tendance à tout passer par la totalité des phases, « pour bien faire ». On retrouve alors une petite cascade, avec beaucoup de documents et peu de retours d'utilisateurs.

Le pense-bête

Phase	La question	Le document clé	L'équivalent agile
1. Analyse	Pourquoi ?	Product brief	Discovery
2. Planification	Quoi, pour qui ?	PRD	Vision et backlog
3. Conception	Comment, en quels morceaux ?	Architecture, epics, stories	Affinage, Definition of Ready
4. Implémentation	Construire et apprendre	Code revu	Sprint, revue, rétrospective