Skip to main content

BMAD : cadrer un projet avant de laisser un agent coder

Avant chaque projet, je fais tourner BMAD avec Claude. Ce que c'est, comment on l'a outillé chez Domaine du Net, et le pont concret avec Mediator.

Julien Trotoux
Julien Trotoux
Tableau blanc avec des post-its de planification classés par colonnes (backlog, cette semaine, en cours)
Photo : cottonbro studio on Pexels

Avant chaque nouveau projet, je passe par la même étape : je fais tourner BMAD, avec Claude. Pas pour écrire du code — pour ne pas en écrire trop vite. BMAD force à répondre à des questions qu'on préfère souvent sauter : qu'est-ce qu'on construit exactement, pour qui, sur quelles hypothèses, et qu'est-ce qui est déjà tranché versus ce qu'on suppose.

Cette étape ne produit rien de visible pour un client ou un lecteur de cette newsletter. C'est justement pour ça qu'elle mérite un article : parce qu'elle a fini par ressortir ailleurs, dans un endroit qu'on n'attendait pas.

Le problème que BMAD règle : le hors-sujet piloté par IA

Un agent IA code vite. C'est là le piège. Il code vite même quand la question posée n'est pas la bonne, même quand une hypothèse de départ n'a jamais été vérifiée, même quand le scope a doublé sans que personne ne le décide explicitement. Sans cadrage, un agent produit du code fonctionnel pour un problème mal posé — et le mal posé ne se voit qu'une fois que tout est déjà écrit.

Le réflexe naturel serait de tout spécifier soi-même avant d'ouvrir Claude. Mais écrire une spec complète à la main, c'est long, et ça ne capture pas les questions qu'on ne s'est pas posées. BMAD propose l'inverse : un processus structuré, mené avec l'IA elle-même, qui force à clarifier avant de construire — pas un document qu'on rédige seul dans son coin, une conversation cadrée.

Ce qu'est BMAD-METHOD

BMAD-METHOD est un framework open source — le nom officiel complet est Breakthrough Method for Agile AI-Driven Development. Ce n'est pas un produit Domaine du Net : c'est un outil qu'on utilise, comme on utilise Claude Code lui-même.

Le README schématise le principe avec ce qu'il appelle la « delivery loop » ; la documentation officielle reprend la même logique en quatre temps : Clarify (faire émerger une idée claire à partir d'une notion vague), Plan (la détailler), Build and verify (construire et vérifier), puis Learn and adjust, qui reboucle vers la planification. Les projets simples peuvent sauter directement à la construction ; les projets plus complexes bénéficient d'un passage plus long dans les deux premières phases. Dans la manière dont je l'utilise, je ramène surtout BMAD à quelque chose de simple : clarifier, planifier, construire et vérifier, puis apprendre de ce qui vient d'être produit.

Concrètement, le framework mobilise des « perspectives spécialisées » — produit, architecture, UX, développement, test — convoquées selon le besoin plutôt que systématiquement. Et il s'appuie sur des documents structurés (briefs, spécifications, architecture) qui portent les décisions d'une itération à l'autre, pour ne pas avoir à réexpliquer le contexte à chaque nouvelle session. C'est cette discipline-là qui m'intéresse : moins la définir sur le papier, plus l'utiliser pour ne pas repartir de zéro à chaque conversation avec un agent.

Un exemple, loin d'un projet logiciel

Ces quatre questions se retrouvent même là où on ne les attend pas. Un père écrit à un médiateur IA : « Il ne décroche jamais, je passe mes soirées à me battre contre un écran. » Les clarifier revient à poser :

  • Ce qu'il cherche à obtenir : pas que le temps d'écran tombe à zéro, mais retrouver un moment où on se parle vraiment le soir.
  • D'où il parle : il compare à l'enfant qu'il connaissait il y a deux ans, pas à l'ado d'aujourd'hui.
  • Ce qu'il tient pour acquis sans l'avoir vérifié : « il ne décroche jamais » — un chiffre existe, dans Family, pour vérifier si c'est vraiment le cas tous les soirs ou seulement certains.
  • Ce qui est déjà réglé : en réalité, aucune règle explicite d'heure de coupure n'a jamais été posée — seulement une attente qui n'a jamais été dite à voix haute.

La formulation qui en ressort, une fois validée par le père, n'a plus grand-chose à voir avec la phrase de départ : « J'aimerais qu'on ait un moment ensemble le soir, sans écran, même court. » C'est ça que le fils reçoit — pas l'accusation, la demande qu'elle cachait.

Le pont concret : l'Intake de Mediator

Ce médiateur IA n'est pas un exemple abstrait : c'est Mediator, dont j'ai parlé dans un article dédié. Et ces quatre questions ne sont pas une image pour cet article : elles sont littéralement la première phase d'une conversation dans Mediator, l'Intake. Dans le prompt système du médiateur, un commentaire du code les décrit comme « the BMAD lens Julien asked for » — ma grille BMAD, transposée.

C'est exactement le même geste que le cadrage d'un projet logiciel, appliqué à une conversation humaine. Cadrer un projet avant de coder revient à poser : qu'est-ce qu'on construit, pour qui, sur quelles hypothèses non vérifiées, qu'est-ce qui est déjà décidé. Cadrer une conversation difficile avant de la faire avancer revient à poser exactement les mêmes questions, sur une brouille plutôt que sur un backlog. Je n'ai pas copié une checklist BMAD dans un prompt Mediator — j'ai reconnu que la structure qui m'aide à ne pas partir dans le mauvais sens sur un projet est la même structure qui aide à ne pas partir dans le mauvais sens sur une dispute.

Du côté outillage : ddn bmad

Chez Domaine du Net, BMAD n'est pas resté une lecture. C'est devenu une commande de premier niveau de notre CLI interne : ddn bmad installe ou met à jour automatiquement le framework sur n'importe quel repo, configuré pour tourner avec Claude Code. L'idée est simple : faire du cadrage une étape normale du workflow, pas un rituel qu'on saute quand on est pressé.

Une discipline, pas une promesse

BMAD ne garantit rien. Ça reste un cadrage — pas une assurance que le projet ira bien, ni que la conversation dans Mediator se terminera en accord. Ce que ça fait, plus modestement, c'est retarder d'une étape le moment où on laisse un agent avancer, pour vérifier qu'on avance sur la bonne chose. Sur un projet logiciel piloté par IA, cette étape coûte quelques minutes. Ne pas la faire coûte, plus tard, un refactor entier ou une fonctionnalité construite pour le mauvais besoin.

C'est la même logique que celle détaillée dans notre méthode de travail avec Claude : Claude exécute vite et bien sur un périmètre clair. Le travail humain, c'est de rendre ce périmètre clair avant de lui donner la main. BMAD est l'un des outils qui sert exactement à ça — avant un projet, et visiblement, avant une conversation aussi.

À très vite, Julien

Les articles précédents sont dans la newsletter Domaine du Net.