> ## Content Index
> Fetch the complete content index at: https://www.sfeir.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# BMAD, du greenfield au brownfield : mon retour d'expérience
- URL: https://www.sfeir.dev/ia/bmad-du-greenfield-au-brownfield-mon-retour-dexperience/
- Published: 2026-10-01T12:18:53.000Z
- Updated: 2026-10-01T12:18:53.000Z
- Description: J'ai utilisé BMAD en équipe au Hackathon SFEIR AI, en greenfield, puis sur ma mission, en brownfield. Dans les deux cas, le découpage par domaine a aidé. Sur l'existant, la part de changements organisationnels qu'implique la méthode ne doit pas être sous-estimée.
- Author: Louca Mendy
- Tags: IA, BMAD, SSD, DDD

\*BMAD fournit une équipe d'agents spécialisés (Analyst, Project Manager, Architect, Developer, QA, etc.) qui orchestrent le cycle de développement logiciel en quatre phases : Analysis, Planning, Solutioning et Implementation. À chaque phase, ils produisent des documents sur lesquels s'appuie toute la suite.

[BMAD Method : comment révolutionner le développement avec l'IA agentique ?La méthode BMAD révolutionne le développement logiciel en orchestrant des agents IA spécialisés pour chaque étape du cycle de production.sfeir.devHamadi Jabloun](https://www.sfeir.dev/ia/bmad-method-comment-revolutionner-le-developpement-avec-lia-agentique/)

*L'effort se déplace donc en amont du développement. On passe l'essentiel de son temps à cadrer et à itérer avec les agents pour construire le PRD (Product Requirements Document) et les ADR (Architecture Decision Records). C'est une logique de spec-driven development (SDD). Les spécifications deviennent le contrat de référence, et les agents BMAD l'exécutent en le respectant.*

[Oubliez le vibe coding, passez au SDD !M définit la mission, Q prépare les gadgets, Bond agit.sfeir.devErwan Le Tutour](https://www.sfeir.dev/ia/oubliez-le-vibe-coding-passez-au-sdd/)

## Greenfield : un cadre construit pour BMAD

Le hackathon, organisé sur quatre semaines, nous a offert un cadre idéal pour expérimenter BMAD et y optimiser son usage. Pas de legacy, pas de dette technique, pas de processus existant. Nous avons pu mettre en place les règles qui favoriseraient son usage en équipe.

### Des ADR avant la première ligne de code

Avant d'écrire la moindre ligne de code, nous avons rédigé et validé ensemble les ADR (Architecture Decision Records), de sorte à obtenir un socle architectural commun, partagé par toute l'équipe. À partir de ce socle, nous avons pu découper les différentes tâches et isoler les responsabilités de chacun.

### Un domaine par package, un package par développeur

Nous avons mis en place une architecture « microservices like » sans la complexité opérationnelle d'un déploiement distribué, inadaptée au contexte court du hackathon. Notre compromis :

> Un package = un microservice = un domaine.

Chaque domaine métier avait son package, et les epics produites par BMAD étaient suffisamment isolées pour être traitées en parallèle. Chacun travaillait sur un périmètre clairement délimité. Résultat : très peu de conflits lors des merges.

### Un suivi poussé sur `main` à chaque story

Les artefacts de suivi produits par BMAD (avancement des sprints, statuts des stories, métriques, etc.) étaient poussés dès qu'un dev démarrait une story/nouvelle epic.

> Dès qu'une story passait en *in progress*, on poussait sur `main`.

BMAD s'appuyait sur cet état pour proposer la prochaine feature à prioriser, en fonction de l'avancement réel.

### Un SaaS livré en quatre semaines

En quatre semaines, nous avons livré un SaaS de gestion de projet avec, entre autres :

- des agents spécialisés (PM, Scrum Master, Dev) branchés sur le contexte réel du projet
- une mise à jour automatique des tickets via un serveur MCP
- des dailys générés automatiquement en fonction de l'avancée de la veille
- la détection de tickets en doublon
- une remontée automatique des points de blocage
- le coût de chaque feature exprimé en tokens

Tout avait été optimisé pour que notre cadre de travail s'adapte à BMAD, et non l'inverse. Le résultat a été très satisfaisant. Mais qu'en est-il lorsque le cadre préexiste, sur un projet déjà en production, avec un backlog, des contraintes techniques et organisationnelles héritées ?

## Brownfield : cette fois, c'est BMAD qui s'adapte au cadre

Au cours de ma mission, il a été décidé de mettre en place BMAD sur une partie de nos projets. Le contexte : une PWA métier dans le secteur de l'énergie. Deux lots en production et un troisième en cours de développement.

L'équipe est organisée par stack, front et back.

Côté front, l'application est découpée en micro-frontends Angular. Côté back, tout est serverless sur AWS et découpé par bounded context : chaque domaine a son propre repository, déployé indépendamment, et chaque use-case a sa Lambda. Nous avons installé BMAD v6, l'avons intégré à Claude Code, et nous l'utilisons pour le dernier lot.

## Côté back, le DDD nous avait préparé le terrain

Chez le client, l'existant n'a pas été un obstacle, il a fourni le découpage dont BMAD avait besoin. Lors du hackathon, nous avions dû créer nous-mêmes l'isolation par domaine. Chez mon client, le DDD (Domain-Driven Design) avait déjà posé ces frontières.

Le repository par domaine joue le rôle qu'avait le package au hackathon. Les agents travaillent sur un périmètre défini et isolé.

Chaque use-case possède sa propre Lambda, donc chaque story générée par BMAD porte sur un élément applicatif bien délimité. Elle commence dans une Lambda précise et s'arrête aux limites de son périmètre fonctionnel, sans déborder sur les autres domaines. En brownfield, le risque est souvent de se perdre dans une base de code large et implicite. Ici, la correspondance entre use-case métier et Lambda isolée donne à BMAD des frontières nettes.

Chaque développeur peut donc travailler sur un use-case. Cette isolation a permis de lancer BMAD en parallèle, y compris sur le même domaine.

## Parcours complet ou `quick-dev` : on dose selon le changement

Nous avons rapidement cessé d'appliquer le même parcours à tous les changements.

Les fonctionnalités importantes suivent le parcours BMAD complet : PRD, ADR, Stories, Implémentation, puis Revue.

Les petits développements passent par un parcours allégé : une spécification courte, puis l'implémentation via le skill `quick-dev`.

BMAD produit là aussi une spécification technique courte en Markdown, versionnée avec le code, qui assure la traçabilité des petits changements et alimente la même boucle de capitalisation que les PRD et les ADR du parcours complet.

## Chaque feature nourrit la suivante

Les PRD, stories et ADR sont versionnés dans Git. Ce qui est produit pour une feature sert est utilisé dans le contexte des stories suivantes. L'agent qui travaille sur la feature N+1 s'appuie sur les décisions prises pour la feature N. Le développeur qui rejoint l'équipe dispose de la même trace. C'est le principe du [context flywheel](https://www.sfeir.com/concepts/context-flywheel/?ref=sfeir.dev) : chaque tâche enrichit le contexte des sessions suivantes.

## Les freins : un chantier organisationnel

BMAD a été bien reçu, mais l'adoption s'est arrêtée à l'équipe back. Le front est pourtant lui aussi découpé en micro-frontends. Le découpage et l'isolation des composants sont un facilitateur, mais d'autres éléments organisationnels ont été sous-évalués.

La mise en place de BMAD a été introduite comme un sujet d'outillage, mais c'est avant tout un sujet de change management. Une présentation à l'équipe dev peut donner envie, elle ne fait pas changer de posture. Il aurait fallu un accompagnement dans la durée pour optimiser son adoption.

## Mener le chantier : mes propositions

Le découpage était là. Ce qui a manqué se situe autour de l'outil : le portage par la direction/management, la montée en compétence progressive, la forme du backlog, l'organisation des équipes et le suivi.

### Porter le changement au-delà des développeurs

Cet accompagnement ne peut pas reposer sur la seule envie d'une partie de l'équipe tech. Il faut que la direction accompagne les équipes pour organiser une réelle conduite du changement.

### Former par la pratique avant BMAD

Avant d'utiliser BMAD, je formerais toute l'équipe au développement agentique, pas à pas par la pratique : automatisation de tests, documentation vivante, mise en place de skills, de workflows agentiques. Le but : une montée en compétence progressive avant l'utilisation d'une méthode aussi riche que BMAD, permettant à toute l'équipe de comprendre les enjeux. BMAD viendrait ensuite industrialiser et uniformiser des pratiques déjà acquises.

[Les Skills : donner un vrai métier à votre agent IALes tools permettent à un agent IA d'agir. Les skills lui apprennent à bien agir.sfeir.devErwan Le Tutour](https://www.sfeir.dev/ia/les-skills-donner-un-vrai-metier-a-votre-agent-ia/)

### Adapter le backlog à la maille de BMAD

Sur le hackathon, le backlog était composé d'epics produites par BMAD. Chez mon client, il est prédécoupé par stack, front d'un côté, back de l'autre. Or BMAD, comme toute autre méthode de SDD, n'est pas calibré pour ce niveau de découpage. Le travail à l'échelle de la feature fonctionnelle et full stack est plus pertinent.

### Organiser les équipes par domaine, vers la Sandwich Team

Si le backlog est pensé en features full stack, l'équipe qui les porte doit pouvoir les livrer de bout en bout. Se pose alors la question du dimensionnement et du périmètre de chaque équipe : un découpage par domaine devient possible et plus pertinent. Ce qui peut constituer en un premier pas vers la [Sandwich Team](https://www.sfeir.com/concepts/sandwich-team/?ref=sfeir.dev). Ce découpage permettrait également d'avancer un plus grand nombre de sujets en parallèle, même s'il demande un gros travail au préalable pour identifier les dépendances.

[La fin de la pizza team : ce que l'IA change vraiment pour les développeursDidier Girard, DG de SFEIR, partage sa vision de la transformation du métier de développeur à l'ère de l'IA générative.sfeir.devCharlotte Ryssen](https://www.sfeir.dev/tendances/la-fin-de-la-pizza-team-ce-que-lia-change-vraiment-pour-les-developpeurs/)

Le sujet est davantage organisationnel que technique. Il suppose de revoir le découpage en amont avec les experts métier et de vérifier que les frontières de domaines sont suffisamment claires.

### Après la carte blanche, mesurer le coût par feature

Pendant le hackathon, notre produit exprimait le coût de chaque feature en tokens. Sur la mission, nous avons eu carte blanche : aucune limite de tokens. Pour une expérimentation, c'est justifié. Mais ce n'est pas pérenne, et sans mesure, impossible de savoir ce que coûte une feature passée par le parcours complet, donc impossible d'industrialiser.

Je suivrais dès le départ le temps passé par étape ainsi que la consommation de tokens par feature, en tentant d'y intégrer le cadrage et la revue. Sans ces données, difficile de distinguer un vrai gain de vitesse d'un simple déplacement de l'effort vers la conception et la validation.

[FinOps Claude Code : comment optimiser sa consommation de tokensClaude Code coûte en moyenne 6 $ par jour et par développeur.sfeir.devThomas Gruson](https://www.sfeir.dev/ia/finops-claude-code-comment-optimiser-sa-consommation-de-tokens/)

## Ce que j'en retiens : un sujet autant organisationnel que technique

Pendant le hackathon comme sur le projet en production, des limites bien définies entre les domaines ont permis de limiter le contexte à gérer, de réduire les conflits et de paralléliser les développements. En greenfield, on a construit un cadre pour BMAD. Sur l'existant, ces prérequis nous ont permis une mise en place sereine du spec-driven development.

Bien que ces changements de paradigme puissent apparaître comme une problématique technique, la part de changements organisationnels qu'ils impliquent ne doit pas être sous-estimée. Celle-ci doit entrer dans un cadre de gouvernance plus globale.

Si vous voulez tenter BMAD en équipe, commencez par examiner votre découpage, vos contrats et la façon dont votre backlog représente les fonctionnalités