BMAD avec de petits modèles : le modèle propose, le code décide
BMAD est une méthode pour mener des agents IA à travers un projet : découper le travail en stories, donner à chaque story ses scénarios d'acceptation, faire implémenter les stories une par une. Avec un modèle de pointe, une version souple suffit. Avec un modèle de 9B ou 27B sur votre propre carte, ça dérive en moins d'une heure. Voici la version stricte que nous faisons tourner, où tout ce qui peut être vérifié l'est par du code.
Ce que vous y gagnez. De petits modèles locaux qui livrent de vrais projets, story après story, sans dériver : parce que tout ce qui peut être vérifié l'est par du code, et que vous gardez le dernier mot.
0. La méthode BMAD en une minute
BMAD (une méthode libre de développement agile piloté par l'IA) confie chaque phase d'un projet à un agent spécialisé, chacun produisant un document que le suivant lit :
- Analyste : explore l'idée et écrit un cadrage du projet.
- Chef de produit : transforme le cadrage en exigences (un PRD).
- Architecte : conçoit le système qui y répond.
- Scrum master : découpe ces documents en petites stories autonomes.
- Développeur et QA : implémentent une story à la fois, puis la relisent.
Sa force, c'est la chaîne de documents : chaque agent part d'un contexte écrit, pas d'une discussion floue. Sa faiblesse avec de petits modèles, c'est que chaque passage de relais est jugé par un autre modèle. Voici comment nous avons gardé la chaîne et remplacé par du code chaque jugement qui n'a qu'une bonne réponse.
1. Des stories avec un schéma
Une story n'est pas un paragraphe. C'est un enregistrement avec des champs : un identifiant, une justification, les fichiers qu'elle peut toucher, les stories dont elle dépend, ses scénarios. Nous écrivons le backlog en TOML et le validons avec un petit programme, un vérificateur de stories, qui refuse en le nommant :
- un champ manquant, un mauvais type, un identifiant en double ;
- une dépendance inconnue ou circulaire ;
- plus d'une story en cours ;
- une story sans justification ;
- un fichier ni présent dans le dépôt ni déclaré nouveau, ou déclaré nouveau alors qu'il existe déjà.
Le vérificateur n'a ni réseau ni modèle : lancez-le trois fois, vous obtenez trois fois les mêmes octets.
2. Le modèle propose le découpage, vous l'approuvez
Découper un projet a beaucoup de bonnes réponses, ça reste donc le travail d'un modèle. Mais sa sortie est une proposition : le vérificateur la contrôle, puis vous l'approuvez, liste de fichiers comprise. Une contrainte écrite par un modèle et appliquée sans relecture n'est qu'une suggestion bien élevée.
3. Une seule story vivante à la fois
La story suivante ne démarre que quand la précédente est fusionnée. Et l'état du backlog n'est jamais stocké : il est dérivé à chaque appel des runs qui citent chaque story. Un « en cours » stocké survit à un run mort et ment en silence ; un état dérivé ne le peut pas.
4. Les scénarios sont des données, lancées par pytest
Pas de framework BDD, pas d'appariement d'une phrase à une étape. Un scénario est un petit objet, Étant donné / Quand / Alors, posé à côté du code qui l'exécute, et la suite les lance en pytest paramétré. Le verdict est celui de pytest : réussi ou échoué, avec la ligne qui échoue.
Scenario("S4", given="une story avec une dépendance circulaire",
when="le vérificateur lit le backlog",
then="il refuse et nomme les deux stories")5. La fusion reste humaine
La fusion automatique est une exception, désactivée par défaut, avec une liste de zones interdites : le juge des tests lui-même, le code qui détient les droits Git, le bac à sable. Une modification là attend toujours un humain.
Pièges
Relisez les règles à chaque tâche. Un agent garde sa liberté d'implémentation et perd sa liberté de dériver seulement si la doctrine est devant lui à chaque fois, pas une fois au début.
Un scénario qui n'échoue jamais ne prouve rien. Cassez le code exprès et vérifiez qu'il passe au rouge (voir les tests validés par mutation).
Sources
Utile ? Dites-nous ce qu'il faut mesurer ensuite.