Résumé
À la fin de «The Living Specification», j’avais écrit que les méthodes structurées de développement piloté par l’IA méritaient leur propre article, et que BMAD en était une. Le voici. J’ai fait tourner BMAD avec le plugin Superpowers de Claude Code sur une vraie fonctionnalité, un tableau de bord de revenus et de dépenses avec tendances et comparaisons de périodes, réparti entre deux dépôts: un backend Java et un frontend Angular.
La question de départ était simple: qu’apporte BMAD quand on a déjà une spécification qui fait foi ? Ma réponse: pas davantage de spécification, mais l’étage au-dessus de la story. Un contrat d’API gelé, qui rend légitime le découpage d’une fonctionnalité en une story backend et deux stories frontend menées en parallèle, sans s’intégrer sur la confiance. L’ordre des travaux. Et un lecteur du résultat qui ne l’a pas écrit: l’audit de conformité qui vérifie, une fois le code fusionné, qu’il respecte encore le contrat.
Le tout s’organise en trois étapes: BMAD pour cadrer et geler le contrat, Superpowers pour implémenter en TDD dans un worktree Git, BMAD à nouveau pour auditer. Trois semaines de travail pour cette fonctionnalité. Les deux méthodes se sont heurtées une fois, quand l’étape de brainstorming a rouvert une question que le contrat avait déjà tranchée; j’en ai tiré une règle: en implémentation, l’agent peut discuter du comment, jamais de ce que dit le contrat. Et quand l’audit trouve un écart, on corrige d’abord l’artefact amont, jamais le code.
Ce que je dirais à une équipe un lundi matin: adopter le contrat gelé et la frontière de session, qui ne coûtent presque rien; adapter les artefacts, en gardant une seule source de vérité durable et des échafaudages jetables; se passer de la méthode complète pour les petits changements, parce qu’une méthode appliquée à tout finit contournée. L’IA écrit le code, une méthode décide ce qui est construit; aucun des deux ne décide si c’est juste.
Idées clés
- BMAD n’ajoute pas de spécification: il ajoute l’étage au-dessus de la story, le contrat, l’ordre des travaux et un lecteur du résultat qui ne l’a pas écrit.
- Un contrat d’API gelé rend le parallélisme possible; laissé mou, chaque story devient une négociation. Mais un mauvais contrat tenu fermement donne deux moitiés bien testées d’une erreur.
- Epic, story et plan sont trois objets aux durées de vie différentes: la story est l’entrée, le plan est l’état.
- Les critères d’acceptation se vérifient une fois, les invariants pour toujours: ils doivent migrer dans la spécification durable.
- Un écart trouvé à l’audit se corrige d’abord dans l’artefact amont, la story, l’architecture ou le contrat, jamais dans le code en premier.
Pourquoi j’ai écrit cet article
Je l’avais promis à la fin de «The Living Specification»: les méthodes structurées méritaient leur article, et BMAD était l’une des approches notables que j’avais rencontrées. Je voulais partager mon raisonnement sur les cas où BMAD est utile et ceux où il faut absolument l’éviter, après deux mois de travail assisté par l’IA où l’habitude la plus coûteuse à perdre avait été de laisser la spécification vivre à plusieurs endroits à la fois.