Specs Driven Vibe Coding : 1/3 : BMAD

Il existe une façon de concevoir et développer du logiciel qui consiste à tout écrire avant de coder. Spécifications, architecture, user stories, tickets, tout est documenté, structuré, validé, attribué et planifié. Ensuite seulement, l'implémentation commence. C'est la façon qu'on utilise en entreprise, en équipe en général.

Mais justement, cette approche, on a voulu l'appliquer aussi au travail en solo. Ou pour être plus précis en solo mais accompagné par l'IA. On l'aura testée trois fois ces derniers mois, sur trois projets différents, avec trois méthodes distinctes.

Cette série en trois articles raconte ces expériences. Les bons côtés, les frictions, les impasses, les surprises. L'évolution aussi, on le verra.

1. Le premier article parle de BMAD, une méthode qui met en scène une équipe d'agents IA jouant chacun leur rôle de collègues virtuels
2. Le second article traitera des skills de Matt Pocock, qui sont une version un peu moins dense et plus orientée dev que BMAD
3. Dans le troisième, on essayera de créer notre propre workflow et on essayera Hermes et ses bots pour cela.

Contexte

BMAD on l'a testé notamment sur le site sur lequel vous êtes, puis spoiler alert on l'a assez vite abandonné.

Mais on l'a aussi retrouvé quelques mois plus tard, car c'est la méthode qu'a choisie Decathlon comme workflow de référence pour le développement agentique, avec l'app GitHub Copilot.

Et là, on en parlera plus tard, l'expérience est quand même bien supérieure à ce que je vais vous raconter, et c'est étonnant quand on avait pratiqué GitHub Copilot ces dernières années, preuve que nos outils évoluent à une vitesse assez folle et qu'il ne faut jamais rien déclarer comme acquis en matière d'IA.

On le verra d'ailleurs au cours des 3 articles, plus que le workflow "gestion de projet", c'est aussi l'outillage qui va évoluer au cours de l'année 2026. On commenca avec Claude code dans un terminal + un IDE où on controle presque ligne de code par ligne de code, on finira surement spoiler alert avec une app desktop comme Copilot ou Hermes, sur des modèles chinois pilotés par telephone depuis Discord.

Stack utilisée

Au cours des 3 articles, la stack va évoluer et pas seulement sur les frameworks. Les modèles, les providers, les machines hôtes même vont évoluer également.

Au moment de l'essai BMAD, en tous cas, notre stack était :

Intro : planifier pour mieux développer

Pour démarrer un développement, nous avons généralement 2 options :

• Partir tête baissée et découvrir le sujet en pratiquant
• Commencer par une conception, une planification des tâches et ensuite coder

Les 2 peuvent avoir leurs avantages selon la taille et surtout la complexité de la tâche. À savoir si on doit fixer un bug connu, développer une fonctionnalité complète, ou carrément démarrer un projet, la phase de planification / découpage sera plus ou moins nécessaire et poussée.

Pour les agents, c'est la même chose. Plus la tâche sera longue et nécessitera plusieurs sessions de travail, plus la planification sera indispensable. Mais cela est dû essentiellement à des limites techniques : la gestion de la mémoire, des fenêtres de contexte, l’efficacité qui décroît au-delà d’un certain temps au cours d’une même session…

Au global, l'agent codeur nous ressemblera, il sera plus productif sur des tâches courtes, bien définies et cadrées, il aura besoin de pauses (ou plutôt dans son cas d’arrêt complet pour reset), il aura besoin aussi et surtout de prendre des notes et d’avoir de la documentation à disposition, bien indexée, claire.

Comme nous, plus il perdra de temps à faire des recherches et à essayer de connecter à des outils auxquels il n’a pas d’accès, moins il sera créatif et productif, plus la journée passera trop vite, plus la motivation chutera et le stress augmentera, plus il sera bougon (non ça j'extrapole). Bref l’agent codeur est un développeur comme les autres, même s’il ne daignera jamais l’avouer et nous encore moins.

Il aimera bien ne pas tout avoir en tête, et pouvoir piocher dans des specs bien écrites et une documentation bien gaulée pour pouvoir s'arrêter dans les temps et reprendre sans douleur son travail.

One person team

Néanmoins, il faut reconnaître que la tentation de foncer tête baissée est souvent la plus forte, surtout avec l’IA. On est pressé d’essayer un prompt et d'avoir un résultat en quelques minutes, curieux aussi de voir si notre agent sera capable de répondre au défi.

Planifier est préférable dans presque toutes les situations, mais il faut reconnaître que c’est peut-être fastidieux, surtout pour un prototype ou une idée à essayer, et qu’on doit mesurer si ça vaut le coup d'engager quelques heures à planifier avant d'agir. Ça tombe bien, l’IA est plutôt douée pour cela, et dispose dans la plupart des cas d’un mode /Plan très efficace.

Le mode /plan sera pertinent et presque nécessaire pour des petites tâches comme des bugs, des petites améliorations, cela permettra de réaliser l’analyse, de lister les solutions, découper le travail et se rappeler du workflow souhaité à savoir par exemple l'écriture et l’implémentation de tests, différentes commandes pour builder, formater, etc… faire une review finale, et voire committer, pousser et ouvrir la PR. (cela dit, avec les modèles récents, écrire des markdown pour cadrer le workflow de développement, semble avoir de moins en moins de sens et les agents sont tout à fait capables de faire cela tout seuls).

Le plan vous aidera aussi à optimiser le prompt initial et le livrable en limitant les interactions, les retours et corrections et en tendant vers le plus possible vers le prompt initial unique et le one shot. Car si on accepte un plan bien gaulé, normalement tout s'enchaîne sans friction.

C’est parfait pour des petites tâches mais qu’en est-il pour des développements plus ambitieux, qui vont nécessiter plusieurs sessions / jours ? On a toujours la possibilité de s’interrompre et d’enregistrer notre plan mis à jour pour une reprise extérieure. Cela va fonctionner si vous avez par exemple un abonnement pro Claude, et vous disposez de la mémoire (et leur donnez toutes vos données au passage, mais bon…). Disons que pour le moment ce n'est pas encore hyper optimal.

Testons BMAD

On a donc testé BMAD au cours de quelques jours (ou plutôt quelques sessions de 5 heures entrecoupées de pauses fraîcheur) pour la conception et le développement du site sur lequel vous êtes.

Rien de bien compliqué mais un business modèle qui a évolué, pivoté, et surtout une direction artistique qu’on a pour la première fois confronté à l’IA. Le défi était ici de produire du contenu et une «patte graphique» la plus personnelle possible, en chassant au maximum le SLOP. On verra par la suite que ce fut un combat et une négociation permanente car avec BMAD ce n’est pas un seul agent qui travaillera avec vous mais une petite équipe de 6/7 personnes qu’il faudra manager, corriger, challenger et parfois même s’embrouiller.

On passera sur l’installation du framework, un peu lourde je pense car le système est beaucoup basé sur les fichiers texte. On va donc avoir des dizaines de dossiers, autant de sous-dossiers et des centaines (!) de fichiers markdown s’ajouter dans notre projet alors qu’on a encore rien fait d’autre que lancer npx bmad-method install.

Vous me direz ça ne change pas grand chose par rapport à un paquet npm classique, certes, mais si quand même un peu car on le verra on va aussi produire de la doc, des specs et tout un tas de fichiers qu'il faudra pour le coup garder et versionner, peut-être aussi séparer de la base de code tout en les synchronisant et cela pourra devenir un petit sujet de friction.

Bref, une fois installé, on se lance, assez facilement juste en démarrant une session et en chattant (sur Claude code, donc , pour le moment, on verra par la suite l’évolution vers d'autres modèles ).

Les premiers moments seront d’ailleurs consacrés au dialogue, on va poser les bases de notre projet, puis on va vite arriver à l'aspect le plus marquant peut-être de BMAD à savoir le mode « interview». On va subir des rafales de questions pour cerner et cadrer notre projet, on va se faire challenger, bousculer peut être on va couvrir la technique, le fonctionnel, le commercial, la sécurité, le SEO, le design, ... on va se projeter dans l’avenir, bref c’est assez dense, surtout si votre projet n’est encore qu’une vague idée.

Et ce n'est encore que le début.

Le brainstorming.

BMAD va vous demander de choisir parmi quelques techniques de brainstorming et vous poser tout un tas de questions parfois complètement abstraites pour pousser un peu plus vos concepts ou les recadrer. Personnellement j’ai essayé plusieurs techniques et la plupart ne m'ont pas convaincue. On peut même dire que certaines m'ont carrément ennuyé et agacé et j'ai dit STOP, changeons de technique, je ne vois pas l'intérêt de choisir entre bleu ou rouge, tempo rapide ou tempo lent, surface lisse ou rugueuse, non vraiment STOP.

Rencontre avec notre nouvelle équipe d'agents

Je ne me souviens plus exactement à quel moment intervient la rencontre avec l'équipe. John, Alexa, Sandy, Kevin, Pamela et Donald (les prénoms ont été modifiés), respectivement architecte, UX designer, dev back, dev front et tech lead, feront leur entrée dans le process via une réunion.

On passera en revue les premiers éléments de la demande selon chaque spécialité, ils reformuleront et ils noteront les points à creuser, challenger, ou carrément explorer. Ce qui est assez drôle dans cette « party mode » c’est que nos amis ne s'adressent plus forcément à nous, mais vont parler entre eux, parfois pendant de longues minutes.

On se contente alors de lire les dialogues, c'est un délire, on se croirait dans un RPG, et au bout de quelques minutes où pour être honnête on peut avoir décroché, une question enfin vous est adressée : es-tu d'accord avec cela JS ? ‘ Euh … scrollons un peu de 800 lignes vers le haut et relisons si tu veux bien.

Selon votre disponibilité, vous serez arrivés à la fin de cette partie au bout de une ou 2 sessions, inutile de vous dire que c'est donc chronophage et dense. Un peu étrange donc, ces longues réunions avec vos collègues agents, car rappelons-le, dans la vraie vous ne parlez qu'à votre ordinateur.

Rédaction des specs et démarrage des devs

Normalement si tout c’est bien passé (dans notre cas on aura quand même lutté surtout avec l’UX et le SEO), on pourra commencer à écrire les décisions d'architecture (ADR), les specs (PRD), puis le découpage en US.

Là, toute la magie opère, toute la doc s’écrit en quelques minutes, les tickets sont prêts, découpés, il n’y a plus qu’à, comme on dit. On pourra prendre les tickets 1 par 1 et lancer les implémentations dans des branches séparées, commiter, pousser, créer les PRs, merger, déployer en prod, tout se passe ensuite de façon assez fluide (tant qu'on ne parle pas design ou qualité de code).

Les failles

Bon, ça c'est évidemment si tout va bien et si votre plan a été parfaitement écrit. Dans la réalité, on fera face à quelques désillusions.

• Des erreurs ont été disséminées à de nombreux endroits à partir d'une seule mauvaise réponse ou quelque chose qui est resté en suspens. Les conséquences sont assez pénibles, on demande la correction de la référence et ce n’est accompli que partiellement malgré l'affirmation du contraire. On devra revenir à de nombreuses reprises sur cette méprise. En découle une certaine frustration, celle du Product Owner / chef de projet d'avoir laissé passer des specs incorrectes et de se confronter à la rigidité de nos devs. Le paradoxe étant qu'à la base c'est nous le dev, rappelons-le ! Le monde à l'envers, je vous dis.
• On plaide coupable: on a pas lu toute la littérature générée par le framework. En résulte des décisions qu'on n'a pas forcément validé ou qu'on aurait peut être formulé différemment, et par extension quelques déceptions sur le résultat fourni.
• La problématique de la longue session où on doit prendre 3000 décisions est réelle. Dans la vraie vie cela s'étale sur plusieurs semaines, ici on condense tout sur quelques heures. On pourrait stopper avant, certes, mais à l'époque où j'ai testé BMAD on y était pas encouragé. On ne pouvait pas vraiment faire stop et quitter la session dans la minute, le système rédigeant alors le résumé pendant un certain temps, et si on ne voulait pas recommencer à zéro dès le lendemain, on se sentait obligé d'aller au bout de la pénible session en une seule fois.
• Côté UX/design et aussi SEO, nos agents sont un peu trop scolaires. Difficile voire impossible de les faire aller vers quelque chose de créatif, original et avec ce fameux goût humain tant recherché. Ce n'est pas un pb lié uniquement à BMAD bien sûr, c'est lié évidemment mais les débats qu'on aura eu avec nos agents designers Sarah et Tristan ( désolé j'ai déjà oublié vos prénoms ) furent compliqués. Ce sont cela dit des experts et donc si le patron insiste, ils vont se plier à la demande, mais sans conviction. Ça ne serait pas un pb si leurs propositions étaient au niveau. Mais au final, on a dû se battre pas mal et leur faire revoir leur copie de nombreuses fois.
• On ne peut pas virer et recruter d’autres agents. Donc on a dû faire avec Sarah et Tristan jusqu'au bout...

La sortie de BMAD et les leçons pour la suite.

Ce qui s'est passé, aussi, il faut être honnête c'est qu'on a complètement pivoté assez vite. Et donc une grande part des specs qui avaient été écrites sont devenues obsolètes. On a gardé l'archi, la stack technique, mais pour tout le reste, on a fait reset et on a choisi d'avancer cette fois-ci sans plan. Par l'expérimentation, les essais.

Cela dit, on gardera quand même de BMAD un souvenir assez ému de quelques moments étonnants et drôles comme certaines questions "psy" de brainstorming, ou ces réunions de bots où on ne pouvait pas en placer une.

Et on cherchera à trouver un workflow plus personnel, plus souple pour pouvoir planifier et suivre un développement en solo, notamment pourquoi pas en branchant un système de suivi de ticket par exemple, en le branchant via MCP , tout comme Git.

On le trouvera un peu plus tard avec les skills de Matt Pocock, qu'on branchera à Linear et Gitlab pour une expérience un peu plus complète et convaincante.

Pour aller plus loin

• Documentation BMAD (FR) : https://docs.bmad-method.org/fr/
• GitHub BMAD-METHOD : https://github.com/bmad-code-org/BMAD-METHOD