BMAD : structurer un projet de développement en quatre phases

Écrire du code avec une IA n’est plus le problème. Le problème, c’est qu’on obtient très vite beaucoup de code, dans un ordre discutable, sans trace de la raison pour laquelle il existe. Trois semaines plus tard, personne ne sait pourquoi tel écran fonctionne comme ça, ni quelle décision a été arbitrée quand.

BMAD répond à ce problème précis. Ce n’est pas un générateur de code, c’est un cadre de méthode qui s’installe dans votre environnement de développement et qui vous force à cadrer avant de produire. Cet article explique ce qu’il fait, ce qu’il coûte en cérémonie, et quand il ne sert à rien.

Précision d’entrée : je l’utilise sur mes propres projets, dont ce site. Ce qui suit vient de l’usage, pas de la documentation.

Le problème que ça règle

Sans cadre, une session de développement assistée par IA ressemble à ceci. Vous décrivez une fonctionnalité, l’IA propose une implémentation, vous acceptez, vous enchaînez. Chaque étape est raisonnable. L’ensemble ne l’est pas.

Trois symptômes reviennent systématiquement.

• Les décisions ne sont écrites nulle part. Le choix d’une bibliothèque, d’un modèle de données ou d’un comportement d’interface vit dans l’historique d’une conversation, qui disparaît.
• L’ordre est dicté par l’enthousiasme. On code ce qui est agréable à coder, pas ce qui débloque le reste.
• Le périmètre glisse en silence. La fonctionnalité livrée n’est plus tout à fait celle qui était demandée, et personne ne sait à quel moment ça a dérapé.

Un cadre de méthode ne rend pas l’IA plus intelligente. Il rend le projet relisible.

Ce que fait BMAD, concrètement

BMAD est une méthode qui s’installe dans un projet et qui déroule un cycle en quatre phases. À chaque phase correspondent des workflows, et chaque workflow produit un fichier markdown versionné dans le dépôt. C’est le point important : la sortie n’est pas une réponse dans un chat, c’est un document qui vit à côté du code et qui se relit dans six mois.

La phase qui change le plus les habitudes est la quatrième. Le principe est qu’on n’écrit pas de code sans story. Si une story n’existe pas pour ce qu’on s’apprête à coder, on l’écrit d’abord : contexte, critères d’acceptation, plan d’implémentation. Cinq minutes de rédaction qui évitent une demi-journée de dérive.

La règle qui fait tout le travail

Toutes les autres règles découlent de celle-là : une story par unité de travail, et rien en dehors.

Ce n’est pas de la bureaucratie. Une story bien écrite fait trois choses qu’aucun prompt ne fait. Elle fige le périmètre avant qu’on ait envie de l’élargir. Elle donne des critères d’acceptation vérifiables, donc une définition non négociable de « c’est fini ». Et elle laisse une trace consultable quand quelqu’un, vous compris, demandera dans six mois pourquoi ce comportement est celui-là.

Le corollaire est qu’il faut une échappatoire, sinon la méthode se retourne contre vous. Corriger une faute de frappe ne mérite pas un cycle complet. BMAD prévoit un flux court pour ces cas, avec une spécification minimale et une exécution directe. La discipline consiste à ne pas en abuser : dès qu’un changement touche plus d’un fichier ou demande une décision de conception, on repasse par le flux complet.

L’installation

Une commande, dans le dossier du projet.

npx bmad-method install

L’installateur pose quelques questions, dont le choix de votre environnement de développement. Le dépôt officiel est github.com/bmad-code-org/BMAD-METHOD.

Ensuite, il n’y a pas de syntaxe à retenir. On décrit ce qu’on veut faire en langage naturel, et le cadre oriente vers le workflow correspondant. La méthode est organisée en modules selon le type de travail, du cadrage produit à l’implémentation en passant par les phases créatives, et chaque module expose ses propres agents et workflows.

Ce que ça coûte, et quand ça ne vaut pas le coup

Soyons honnêtes sur le prix à payer. La phase de cadrage prend du temps réel avant que la première ligne de code n’existe. Sur un projet de deux jours, c’est une perte sèche : vous aurez passé un quart du budget à documenter un travail que vous auriez fini avant d’avoir fini de le décrire.

Le seuil de rentabilité, tel que je l’observe, se situe à peu près là :

• Projet de moins d’une semaine, un seul intervenant, périmètre stable : n’installez rien. Un fichier de notes suffit.
• Projet de plusieurs semaines, ou repris plus tard, ou à plusieurs : le cadre se rembourse dès la première reprise de contexte.
• Projet livré à un client qui devra le maintenir : la documentation produite vaut autant que le code, parfois plus.

Le second coût est plus insidieux : la tentation de la cérémonie pour la cérémonie. Produire une story de quarante lignes pour un changement de couleur, c’est avoir raté l’objectif. Le cadre sert la relisibilité du projet, pas l’inverse.

Pourquoi ça compte au-delà du développement

La logique vaut pour n’importe quel chantier d’automatisation, y compris quand il n’y a pas une ligne de code à écrire.

Une automatisation métier livrée sans document de cadrage est une boîte noire. Elle fonctionne tant que rien ne bouge, puis un fournisseur change une interface, et plus personne ne sait ce que la chaîne était censée faire. Le document qui dit quelle tâche a été automatisée, quelles décisions ont été prises et pourquoi vaut, sur la durée, plus cher que l’automatisation elle-même.

C’est la raison pour laquelle je travaille de cette façon sur les projets clients : ce qui est livré doit rester compréhensible par quelqu’un d’autre que celui qui l’a construit. Si vous avez un chantier en tête et que la question de sa maintenabilité vous préoccupe autant que sa mise en route, c’est exactement le genre de sujet qu’on peut regarder ensemble.