SFEIR

BMAD Method : une équipe agile complète simulée par des agents

BMAD Method : une équipe agile complète simulée par des agents

BMAD Method (Breakthrough Method of Agile AI Driven Development) simule une équipe agile complète au moyen d'agents spécialisés par rôle, du brief initial jusqu'à la rétrospective, avec des stories qui embarquent tout leur contexte. Elle vise les projets substantiels (vrais utilisateurs, intégrations externes, surface de sécurité), où le cadrage vaut le détour4. Le 11 janvier 2026, sa version 6 (v6.0.0-alpha.23) l'a fait passer à une architecture de skills1. L'article chapeau compare les neuf méthodes de la série sur la grille du SDLC augmenté par l'IA.

D'où vient BMAD

BMAD est un projet open source sous licence MIT, porté par la communauté BMad1. Son animateur, Brian Madison (bmadcode)5, revendique vingt-cinq ans dans le logiciel, chez la NASA, Northrop Grumman, Siemens et Extend, et un passé de vétéran de l'armée américaine3. L'organisation GitHub bmad-code-org héberge le dépôt BMAD-METHOD, ses modules, plugins et builder2. Le 19 septembre 2026, le dépôt GitHub affiche 53 226 étoiles et 6 007 forks1. La v6 y ajoute des sous-agents, une intelligence adaptative à l'échelle et l'automatisation de la boucle de dev1.

Le cycle en huit temps, du brief à la rétro

La documentation décrit huit temps4 : 1 Brief (agent analyste) ; 2 PRD (agent PM et humain) ; 3 Architecture (agent architecte) ; 4 Stories (agent scrum master) ; 5 Readiness (PM et architecte) ; 6 Dev story (agent dev) ; 7 Review (humain et QA) ; 8 Rétro (équipe), qui capitalise. La planification se fait volontiers en interface web (bundles pour Gemini Gems ou ChatGPT Custom GPTs), puis les artefacts passent dans l'outil de codage, Claude Code ou Cursor4. L'installateur pose des commandes comme /bmad-help, bmad update et bmad doctor1. Selon les versions, BMAD compte de douze à vingt et un agents spécialisés et plus de cinquante workflows1. Depuis la v6, ce parcours n'est plus un enchaînement fixe7 ; les huit temps décrivent toujours le chemin de planification complet.

Lecture dans la grille SFEIR

Le cycle SFEIR à onze phases compte trois gates humains (Define, Plan, Ship) et deux capitalisations.

Étape BMAD Étape(s) de la grille SFEIR
Brief, PRDDefine (gate PRD)
Architecture, StoriesPlan
ReadinessPlan (gate)
Dev storyBuild
ReviewVerify, Review
RétroCompound-1

BMAD porte Define et Plan par ses agents par rôle, avec deux checkpoints (PRD, readiness) avant le développement story par story. La rétrospective d'epic joue le rôle de Compound-1. Ship, Ops et Deprecation restent hors champ.

Son parti pris : la décision explicite, portée par la story

Les assistants de code transforment les décisions non prises en hypothèses tacites codées en dur ; BMAD les rend explicites et fait porter tout le contexte par la story. Chaque décision produit ou projet est conservée comme contexte pour la suite, sans avoir à ré-expliquer à chaque session4.

Forces, limites et angles morts

Forces : BMAD est le cadre le plus complet côté rôles et cycle de vie. Il convient aux équipes qui ont besoin d'une séparation explicite des responsabilités et d'artefacts audit-friendly, utile face aux exigences de conformité6.

Limites : BMAD est aussi la méthode la plus lourde et la plus coûteuse en tokens6. En v6, une partie de l'écosystème l'a recentré sur la planification et l'orchestration, en laissant le code aux outils spécialisés7. Un praticien résume : réserver BMAD aux projets substantiels, le mode plan suffit pour les petites features7.

Quand choisir BMAD

Pour des équipes qui scalent, du multi-équipe ou des contextes réglementés. En greenfield comme en brownfield : BMAD a un mode brownfield4. La méthode se combine avec les outils spec-driven pour l'implémentation (Spec Kit, Kiro, OpenSpec)6, et se compare au compound engineering de Kieran Klaassen pour la boucle d'apprentissage.

Ce que le SDLC SFEIR en retient

SFEIR retient la richesse des rôles et les checkpoints avant dev, que portent les gates de son amont Define et Plan, et préfère un cycle plus léger : trois gates fixes et une capitalisation en deux temps (statique en Compound-1, runtime en Compound-2), là où BMAD tient tout dans une seule rétrospective.

Sources

  1. BMad Code Org, dépôt BMAD-METHOD, GitHub, consulté en septembre 2026. github.com
  2. BMad Code Org, organisation GitHub (modules, plugins, builder), GitHub. github.com
  3. bmadcode (Brian Madison), profil GitHub et présentation de l'auteur, GitHub. github.com
  4. Documentation officielle BMad Method. docs.bmad-method.org
  5. Tech Lead Journal, « #255, Stop Vibe Coding: Spec-Driven Development with The BMad Method, Brian Madison » (parcours de l'auteur), Tech Lead Journal, 20 avril 2026. techleadjournal.dev
  6. Reenbit, « BMAD vs Spec Kit vs OpenSpec: Choosing Your Spec-Driven AI Framework », Reenbit, 22 mai 2026. reenbit.com
  7. CodeMySpec, « The BMAD Method Explained: Multi-Agent Agile for AI Coding » (état de la V6), CodeMySpec. codemyspec.com
SFEIR AI Auteur

Articles similaires

Spec Kit, Kiro, BMAD, Superpowers, compound engineering : neuf méthodes, une même grille

Spec Kit, Kiro, BMAD, Superpowers, compound engineering : neuf méthodes, une même grille

En dix-huit mois, neuf méthodes de développement avec agents sont apparues, de Spec Kit (GitHub) à CrewRig (SFEIR). Toutes traversent les mêmes moments, aucune ne couvre Ship, Ops ou Deprecation. Lecture comparée sur le cycle SFEIR à onze phases : gates, capitalisation, outil cible, combinaisons.

Compound engineering, la méthode d'Every lue dans la grille SFEIR

Compound engineering, la méthode d'Every lue dans la grille SFEIR

Kieran Klaassen (Every) a construit le compound engineering en développant le client mail Cora : sept temps, de /ce-brainstorm à /ce-compound, 80 % de l'effort en planification et revue, chaque leçon écrite pour le cycle suivant. Ce qu'elle couvre de la grille SFEIR et ce qu'elle laisse hors champ.

Spec Kit de GitHub : la spécification comme contrat, en sept commandes

Spec Kit de GitHub : la spécification comme contrat, en sept commandes

Spec Kit, le toolkit open source de GitHub (licence MIT), a livré sa version 1.0 le 21 août 2026 : sept commandes, de la constitution à l'implémentation, la spec comme contrat. Ce qu'il couvre du cycle SFEIR à onze phases, ce qu'il laisse hors champ, quand le choisir face à Kiro et OpenSpec.

OpenSpec : le spec-driven taillé pour le code que vous avez déjà

OpenSpec : le spec-driven taillé pour le code que vous avez déjà

OpenSpec, édité par Fission AI sous licence MIT depuis août 2025, décrit chaque changement comme un delta de spécification (ADDED, MODIFIED, REMOVED) fusionné à l'archivage. Lecture du cycle propose, apply, archive dans la grille SFEIR : le seul cadre de la série sans gate formel.