J'ai testé BMad sans savoir coder

La première fois qu'on m'a parlé de BMad, j'ai entendu « be mad ». Une méthode pour devenir folle ? Après l'avoir testée, je vous rassure : elle ne rend pas folle. Elle oblige surtout à réfléchir avant de coder.

Première fois dans un terminal

Je travaille dans le produit depuis 10 ans, entourée de développeurs, sans avoir écrit une ligne de code. J'utilise l'IA générative depuis la sortie de ChatGPT. Pourtant, je n'avais jamais « vibe codé » : mon ancrage produit me retenait de partir sans aucune documentation, en improvisant prompt après prompt.

C'est justement ce qui m'a séduite dans BMad : une méthode documentée, qui reprend les cycles de développement agile que nous accompagnons chez nos clients grands comptes.

Mon terrain de jeu était tout trouvé : la refonte du site NEXTON, un projet brownfield. Restait à installer BMad. Je n'avais jamais ouvert le terminal de mon ordinateur, ni utilisé d'éditeur de code. Avec l'aide de mon collègue Laurent (expert IA chez NEXTON), j'ai tout mis en place : BMad, l'environnement technique du site et Cursor. La marche semblait haute, mais avec de la volonté et un peu d'aide, elle se franchit.

BMad en deux mots

BMad, pour Breakthrough Method for Agile AI-Driven Development, est un framework open source créé par Brian Madison. Il fait jouer à des agents IA les rôles d'une équipe produit : analyste, product manager, UX designer, architecte, scrum master, développeur, testeur. Chaque agent produit un document qui nourrit le suivant.

Le cycle s'organise en quatre phases. D'abord une discovery optionnelle, où l'analyste anime brainstorming, recherche et product brief. Vient ensuite la définition du produit : le PM rédige le PRD et l'UX designer conçoit l'interface si le produit en a une. L'architecte prend le relais pour poser l'architecture, et le PM découpe le tout en epics et stories. Enfin, l'implémentation avance en boucle, story par story : le scrum master prépare la story, le développeur la code, une revue de code (idéalement menée par un autre LLM) la valide ou la renvoie, et une rétrospective clôt chaque EPIC.

J'ai utilisé la version 6.0.4. Le schéma ci-dessus montre le parcours standard en greenfield. Sur mon brownfield, une analyse du code existant s'ajoute. Depuis, la méthode s’est simplifiée : dans la version actuelle (6.12.1), certaines étapes ont disparu, comme la vérification de « readiness » avant le développement, et le niveau de process s’ajuste à la taille du changement.

Ce qui m'a convaincue

Tout est documenté. Chaque décision est écrite et versionnée dans le projet. Je pouvais reprendre le sujet après plusieurs jours sans tout réexpliquer, et l'IA relisait ces documents avant de toucher au code. Le risque de casser ce qui fonctionnait diminue d'autant.

Une lecture fine de l'existant. J'ai donné aux agents le code du site actuel. Quand j'ai voulu modifier une fonctionnalité et en ajouter une autre, ils ont compris où intervenir sans que j'aie à décrire le fonctionnement en langage naturel. Une partie du mérite revient au modèle et à Cursor, mais le cadre BMad impose cette analyse avant d'agir.

Des perspectives que je n'aurais pas eues seule. Le « party mode » réunit plusieurs agents autour d'une même question, chacun avec son regard d'expert. Venant du produit, je ne pense pas spontanément comme l'analyste : l'échange m'a fait regarder mon sujet sous des angles que je n'aurais pas explorés seule. L'agent PM, lui, propose des indicateurs de réussite intéressants : chacun est relié à un objectif produit, avec un horizon et un rythme de suivi. Aucun KPI ne se contente de compter les visites, tous cherchent à savoir si le site produit l'effet attendu. J'avais un cadre de mesure prêt à être challengé plutôt qu'une page blanche.

Ce qui m'a freinée

Tout est documenté. Oui, c'était mon premier avantage. En cours de route, les maquettes ont changé, et j'ai dû demander à BMad de mettre à jour toute la documentation : PRD, epics, stories. C'est long, et chaque mise à jour consomme des tokens. La doc qui me rassurait au départ devenait un poids dès que le projet bougeait. Mon constat : la méthode convient moins aux contextes où les exigences évoluent sans cesse.

Un process lourd. Suivre le workflow pas à pas demande du temps. J'ai passé plus de 4 heures à discuter avec les agents, rien que pour la discovery et la définition du produit, avant de voir la moindre ligne de code. Pour une petite évolution, le rapport entre l'effort et la valeur se discute, même si un mode rapide existait déjà pour ce cas. J'ai volontairement suivi le parcours complet pour tester la méthode de bout en bout. Depuis, la méthode s'est nettement allégée, signe que cette lourdeur n'était pas qu'un ressenti personnel. Le schéma affiché aujourd'hui par BMad est d'ailleurs bien plus léger :

L'IA exécute ce qu'on lui donne. J'avais connecté mes maquettes Figma via MCP. Elles étaient imparfaites, le résultat l'a été aussi. BMad a traduit fidèlement en code un travail amont fragile.

Une équipe simulée n'est pas une équipe

Reste un ressenti que je n'avais pas anticipé : je me suis sentie seule derrière mon écran. Les agents sont impressionnants, ils argumentent, se contredisent, proposent. Mais ils ne remplacent pas le développeur qui lève un sourcil, la designer qui revient avec une meilleure idée, l'utilisateur qui ne réagit pas comme prévu.

BMad n'est pas la seule méthode. Spec Kit, OpenSpec, GSD ou Superpowers partagent le même socle (des agents, des workflows, des skills) et diffèrent surtout par le degré de structure qu'ils imposent : spécification verrouillée avant tout code, cadre léger sur l'existant, exécution en parallèle, TDD imposé. Le bon choix dépend du produit et de l'équipe.

BMad simule une équipe. Le meilleur usage de ces méthodes est peut-être de libérer du temps à la vôtre, pour ce que seuls les humains savent faire ensemble.

Malory REINHARDT, Head of Product