*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.
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.
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 : 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.
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. 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.
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.
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
