Méthode BMAD : développer avec l’IA sans perdre le contrôle

Préambule

Le développement assisté par IA prend davantage d’ampleur au fur et à mesure que l’intelligence artificielle infiltre notre domaine d’expertise. Est-ce une bonne ou une mauvaise chose, là n’est pas la question, mais cette pratique entraîne, avec l’expérience, de nombreux problèmes :

• De cadrage du contexte :
  
  • Soit du fait d’une lacune humaine : c’est« facile », donc je me lance, et l’IA amplifie les trous de conceptions.
  • Soit du fait d’une contrainte technique : fenêtre de données du LLM trop petite, boucle d’hallucination, etc.
• De travail en équipe : comment travailler en parallèle sur plusieurs features si tout est dans la discussion de mon agent en local ? Sans parler des écarts de conventions ou des problèmes d'onboarding que cela implique.
• De maintenabilité : une fois mon application livrée, comment reprendre mon application dans 1semaine, 1 mois, 1 an si ma discussion est archivée depuis longtemps, ou qu’elle est reprise par quelqu’un d’autre ?
• De traçabilité : ma discussion reste dans le prompt de mon agent, comment savoir quelle(s)décision(s) ont été prises, à quel(s) moment(s) ?

 Constatant ces problèmes, des frameworks de développement par IA ont émergé, dont celui auquel nous allons nous concentrer dans cet article : BMAD.

La méthode BMAD en quelques mots

La méthode BMAD pour Build More Architect Dreams (Construire plus de rêves d’architectes) n’est pas une injonction à vous procurer des pierres de lunes magiques pour aligner vos chakras mais bien un framework, un ensemble de méthodes et d’outils d’aide pour un développement applicatif dirigé par l’intelligence artificielle.

Le principe est « simple », le framework fournit un ensemble de méthodes et d’outils pour accompagner le développement d’une application du début, dès sa conception, jusqu’à sa livraison en passant par le développement et la revue du code. Les commandes s’intègrent à votre client IA, que ce soit ClaudeAI, Codex, Cursor… Il est d’ailleurs conseillé d’utiliser au moins 2 clients différents.

Le framework se base sur un processus de construction d’une application en 4 phases :

• L’analyse du contexte de votre application par un brainstorming, la recherche, la création d’un résumé du cahier des charges, ainsi que de re-challenger le concept produit.
• La planification de l’application, créant le document d’exigences produit (Product Requirements Documents,ou PRD) pour planifier le développement futur.
• Le solutioning où on va créer l’architecture de l’application, générer les epics et stories
• Et enfin l’implémentation, où on va finalement demander à l’IA de générer l’application.

A savoir que chaque étape est indépendante et produit ou peut se baser sur de la documentation lisible par un humain, donc rien ne vous empêche de n’utiliser qu’une partie de ces phases (ex : challenger votre cahier des charges avec l’analyse et la planification, et rester dans une conception « classique » pour le reste).

Nous allons voir dans cet article les différents biais de développement par IA que permet de résoudre BMAD en utilisant les différentes méthodes du framework. Si vous souhaitez l’installer de votre côté, je vous invite à suivre le tutoriel présent sur le site officiel de BMAD.

Découvrez notre retour d’expérience complet dans cet article pour appréhender et comprendre le fonctionnement BMAD en 3 principes de conception pour aboutir au principe d’implémentation.

Principe 1 : L’analyse

Mettons-nous dans le contexte de développer une application avec l’IA. Imaginons… On souhaite créer une application comptant les poissons dans un aquarium grâce à une webcam et à l’IA, associé à une application mobile permettant de savoir en temps réel combien j’ai de poissons dans mon aquarium…

Une approche directe serait de lancer votre assistant, et de simplement lui demander :

« Code-moi une application qui compte les poissons dans mon aquarium avec une webcam et une app mobile »

Et, d’une certaine manière, ça marcherait. L’IA produirait probablement une architecture, quelques écrans, une première API, peut-être même un bout de pipeline de détection vidéo. Mais c’est précisément là que se trouve le piège : elle serait obligée d’inventer une grande partie du produit.

Car cette demande, apparemment simple, cache de nombreux angles morts. Que signifie réellement “compter un poisson” ? Compte-t-on les poissons visibles à l’instant T, ou cherche-t-on à reconnaître chaque individu ? Que se passe-t-il si deux poissons se croisent, si l’un passe derrière une plante, si l’eau est trouble ou si un reflet apparaît sur la vitre ? Une erreur de ±1 poisson est-elle acceptable ? Le traitement doit-il être fait localement, sur serveur ou dans le cloud ? Les images sont-elles stockées ? L’application mobile affiche-t-elle seulement un nombre, ou aussi un historique, des alertes, des statistiques ?

On pourrait se dire que tout cela se résoudra naturellement avec une boucle classique : “l’IA code”, “je teste”, “j’ajuste le prompt”. Sur un petit projet, pourquoi pas. Mais dès que l’application devient plus complexe, que plusieurs personnes interviennent, ou que des contraintes techniques, métier ou réglementaires apparaissent, cette méthode devient vite fragile.

Le risque n’est pas seulement que l’IA se trompe. Le risque est qu’elle comble elle-même les trous de notre réflexion, sans que ces décisions soient visibles, discutées ou documentées.

C’est précisément ce que la phase d’analyse de BMAD cherche à éviter.

Dans BMAD, l’analyse n’est pas une étape décorative avant le “vrai” développement. C’est le moment où l’on transforme une intuition produit en matière exploitable. La méthode met à disposition plusieurs workflows permettant de faire émerger, challenger et structurer les informations nécessaires avant de passer à la planification :

• bmad-brainstorming pour explorer l’idée, faire émerger les contraintes, les hypothèses, les risques et les questions ouvertes.
• bmad-market-research, /bmad-domain-research, et /bmad-technical-research pour approfondir respectivement le marché, le domaine métier et les enjeux techniques.
• bmad-product-brief pour synthétiser le concept une fois celui-ci clarifié
• bmad-prfaq pour mettre la proposition à l’épreuve et vérifier si elle tient face à des questions critiques.

Ces étapes prennent la forme d’un dialogue avec des agents spécialisés. L’intérêt n’est pas seulement d’obtenir une réponse, mais de provoquer une discussion structurée autour du produit. Chaque phase est optionnelle, mais plus l’analyse est sérieuse, plus la suite — planning, architecture, stories, implémentation — repose sur des bases solides.

En d’autres termes, BMAD ne remplace pas la réflexion produit. Il l’oblige à exister avant que l’IA ne commence à coder.

Mais concrètement, avec notre exemple, ça donne quoi ?

Et bien, après avoir créé un dossier pour le projet (bmad-fishcount), je lance la commande npx bmad-method install pour installer les méthodes bmad lance simplement claude

Voici un extrait d’échanges avec l’IA (l’export complet des 18 pages d’échanges disponible ici) :

> /bmad-brainstorming
[…]

● Bienvenue Mathieu ! Je suis ravi de faciliter ta session de brainstorming. Je vais te guider à travers des techniques de créativité éprouvées pour générer des idées innovantes et des solutions percutantes.

  Mon état d'esprit pour cette session :
  - 🎯 Je vais te pousser à rester en mode exploration générative aussi longtemps que possible
  - 🔄 Je changerai consciemment de domaine créatif tous les 10 idées pour éviter le clustering sémantique
  - 📈 Objectif quantité : 100+ idées avant toute organisation — la magie se produit entre les idées 50 et 100

  Mettons en place ta session pour une créativité et une productivité maximales :

  ---
  Questions de découverte

  1. Sur quoi allons-nous brainstormer ?
  (Le sujet ou le défi central — par exemple, le projet bmad-fishcount, une fonctionnalité spécifique, un problème à résoudre, etc.)

  2. Quels résultats spécifiques espères-tu obtenir ?
  (Types d'idées, solutions ou insights — par exemple : nouvelles fonctionnalités, approches techniques, stratégies UX, modèles métier, etc.)

  Prends le temps de répondre — plus tu seras précis, mieux je pourrai sélectionner les techniques adaptées. 🎨

> 1. Le projet bmad-fishcount consiste à compter, à partir d’une webcam, le nombre de poissons dans un aquarium, et de retransmettre en temps réel le nombre de poissons.
2. Il s’agit d’un projet fictif pour la rédaction d’un article, une mise en pratique des méthodes BMAD. Le but réel est donc surtout d’illustrer toutes les étapes d’un développement par l’IA en utilisant la méthode bmad.

[...]

● Excellent contexte, merci ! Voilà qui change tout — nous avons une double dimension à explorer.

  ---
  Analyse de la session
  
  D'après tes réponses, je comprends que nous nous concentrons sur :

  Sujet principal : Le projet bmad-fishcount — un système de comptage de poissons en temps réel via webcam dans un aquarium.

  Contexte réel : Projet pédagogique fictif servant de fil rouge pour un article démontrant la méthode BMAD appliquée au développement assisté par IA.

  Paramètres de session :

  - Focus thématique : Idéation sur les multiples facettes du projet fishcount (fonctionnel, technique, UX, business, edge cases) — pour avoir suffisamment de
   matière à montrer chaque étape BMAD.
  - Objectifs principaux :
    - Générer un volume riche d'idées que les agents BMAD pourront ensuite trier, prioriser, transformer en PRD, architecture, stories, etc.
    - Illustrer la phase "Analyst / Brainstorming" du flux BMAD avec un exemple concret et démonstratif.
    - Produire un livrable qui sera visuellement intéressant à montrer dans l'article (variété de techniques, idées surprenantes, cheminement clair).

  Implication méta : Comme c'est un projet pédagogique, on peut se permettre d'aller dans des directions inattendues, voire absurdes — cela rendra l'article plus vivant et démontrera la puissance de la divergence créative.

  Est-ce que cela capture bien ce que tu veux accomplir ?

  Si oui, passons à la sélection de l'approche :

  ---
  Prêt à explorer les approches de techniques ?
  
  [1] Techniques sélectionnées par l'utilisateur — Parcourir notre bibliothèque complète de techniques
  [2] Techniques recommandées par l'IA — Obtenir des suggestions personnalisées selon tes objectifs (recommandé pour un article démonstratif)
  [3] Sélection aléatoire de techniques — Découvrir des méthodes créatives inattendues
  [4] Flux progressif de techniques — Commencer large, puis affiner systématiquement le focus (idéal pour montrer une progression narrative dans ton article)

  Quelle approche te séduit le plus ? (Entre 1-4)

❯ Oui, c'est bien ça que je veux accomplir. J'ajouterais également qu'on ne va pas s'attarder sur toutes les étapes facultatives, tels que les études de marchés ou une étude trop approfondis de l'ux, par exemple. Pour l'approche technique, partons sur le [2], laissons l'IA me recommander l'approche technique.

[… Claude crée déjà des fichiers à ce moment là]

● Analyse de tes objectifs de session :

  - Topic : Système de comptage de poissons via webcam — projet pédagogique BMAD
  - Goals : Volume riche d'idées multi-facettes pour alimenter PRD, architecture, stories + livrable narratif pour l'article
  - Contraintes : Pas de phases lourdes (marché, UX profonde) — focus sur ce qui rend l'article démonstratif
  - Type de session : Génératif divergent → progressif, avec besoin de variété visible dans le livrable

  Chargement de la bibliothèque de techniques (62 techniques sur 11 catégories)…

  ---
  Mes résultats d'analyse IA

  Pour ton article, j'ai sélectionné une séquence en 3 phases qui produit visuellement des outputs contrastés — chaque technique génère un type d'idée différent, ce qui rendra ta démonstration BMAD beaucoup plus parlante.

  Phase 1 — Divergence ouverte (Fondation)

  🌀 What If Scenarios (créatif — ~20 min, énergie haute)

  - Pourquoi ça colle : parfait pour ouvrir grand le champ des possibles dès le départ. On questionne toutes les hypothèses du projet ("Et si la webcam voyait à travers l'aquarium ?", "Et si les poissons se comptaient eux-mêmes ?", "Et si c'était un aquarium géant de 10 000 espèces ?"). Génère des idées  provocantes et photogéniques pour l'article.
  - Résultat attendu : ~25-30 idées brutes, variées, qui défient les évidences. Idéal comme "moment éclatement" en début d'article.

  Phase 2 — Exploration systématique

  🔧 SCAMPER Method (structuré — ~25 min, énergie modérée)

  - Pourquoi ça enchaîne : après le grand large créatif, on passe à une méthode structurée à 7 lentilles (Substitute / Combine / Adapt / Modify / Put to other uses / Eliminate / Reverse). Couvre méthodiquement technique, fonctionnel, produit, business. Pour ton article, c'est le contraste parfait : montrer que BMAD utilise à la fois la divergence libre et la rigueur méthodique.
  - Résultat attendu : ~35 idées systématiques exploitables — un terreau riche pour le PRD et l'architecture.

  Phase 3 — Stress test & angles cachés

  💥 Chaos Engineering (wild — ~15-20 min, énergie haute)

  - Pourquoi ça conclut bien : on retourne le projet sur la tête — comment faire échouer ce système ? Webcam coupée, reflets sur la vitre, poissons cachés derrière une roche, panne réseau, espèce inconnue, eau trouble… Ça extrait les edge cases, NFR (non-fonctionnels), et risques techniques qui alimenteront directement les phases architecture/QA de BMAD. Climax narratif inattendu pour l'article.
  - Résultat attendu : ~25-30 modes de défaillance et contraintes cachées qui structureront la robustesse du système.

  ---
  ⏱️  Temps estimé total : 60-75 minutes de facilitation
  🎯 Objectif idées : 90-100+ avant organisation
  📐 Focus session : Couverture multi-facettes (fonctionnel, technique, edge cases) avec progression narrative claire — divergence ouverte → structure →
  stress test

  ---
  Options

  [C] Continuer — On démarre avec ces 3 techniques recommandées
  [Modifier] — J'aimerais ajuster la sélection (ex : remplacer une technique, en ajouter une 4ᵉ comme Role Playing pour les personas, ou raccourcir à 2)
  [Détails] — Tu veux que je creuse une technique en particulier
  [Retour] — Revenir au choix de l'approche

  Que choisis-tu ?

> C

● 🌀 Phase 1 — What If Scenarios

  Excellent ! On démarre la première technique en mode facilitation collaborative.

  Je vais te proposer un scénario "What If" à la fois. Pas la peine de tout résoudre — partage tes premières intuitions, on construit ensemble. Plus c'est  brut, mieux c'est. Et si une piste t'allume, on creuse avant de passer au suivant.

  Quelques règles du jeu :
  - Pas de filtre, pas de "ça ne marchera pas"
  - Si je sens une idée prometteuse, je te propose des extensions
  - Tu peux dire "suivant" à tout moment pour passer au prochain "What If"
  - Tu peux dire "technique suivante" pour passer directement à SCAMPER
  
  Énergie cible : haute, divergente, légèrement inconfortable

  ---
  🎯 Scénario d'ouverture #1

  "Et si la webcam n'existait pas ? Et si tu devais compter les poissons SANS jamais les voir ?"

  C'est volontairement provocant — ça force à reconsidérer le cœur même du projet. Tu n'as pas le droit à la vision. Que reste-t-il ?

  Quelques angles pour t'amorcer (mais ne te limite pas) :
  - 🔊 Le son ? Les vibrations dans l'eau ?
  - 🌡️  La consommation d'oxygène ? La température ?
  - ⚖️  Le poids de l'aquarium ? Les mouvements de la surface ?
  - 📡 Une puce sur chaque poisson ?
  - 🧪 La composition chimique de l'eau (CO2, ammoniac) ?
  - 🤖 Demander aux poissons ?

  Quelle est la première chose qui te vient à l'esprit ? Lance ce qui te traverse — même si ça paraît absurde. C'est souvent là que se cachent les meilleures  pistes.

❯ Le but est vraiment de compter visuellement. Si la webcam est indisponible, alors l'application doit entrer en erreur. Aucun autre capteur ne doit être utilisé, l'application devant s'adapter à tout type d'aquarium, du petit aquarium à poisson rouge sans filtre à la machine de guerre.

‍

Comme vous avez pu le constater, cet échange est long et s’articule par différentes étapes de conception qu’on pourrait catégoriser en 4 étapes :

• un ensemble de « What If ? »
• la méthode SCAMPER.
• du chaos engineering.
• l’organisation des idées.

Il est possible de le rendre bien plus rapide en lui disant explicitement, mais dites-vous bien que plus vous y consacrez de temps et plus la base de votre application sera solide.

On voit également que le sujet a été vraiment creusé profondément :

• Par des questions volontairement absurdes.
• En précisant certains termes (ex : Chaos 1 à propos de ce qu’on appelle « apprentissage »).
• Revenir sur des concepts en cours de route (ex : Chaos 4 - on a redéfinit la valeur de confiance).

Là, nous sommes seuls derrière le clavier, mais dans le cadre d’un projet client, on peut très bien imaginer d’inviter le Product Owner, un responsable business client et un expert métier ayant des connaissances approfondies du besoin.

Cette phase nous a donc créé un fichier de brainstorming dans _bmad-output/brainstorming/brainstorming-session-xxx.md qui sera relu par les autres processus. D’ailleurs, il est conseillé de faire une nouvelle discussion à chaque étape justement pour forcer l’agent à relire les documents plutôt que de se baser sur sa mémoire. Cela permet :

• De minimiser les boucles d’hallucination.
• De permettre de répartir les processus. En faisant comme ça, si un fichier est modifié/compléter, une autre personne peut très bien continuer le travail.
• Contrôler le processus de raisonnement. Les fichiers générés sont totalement lisibles par un humain simplement, donc peuvent très bien être revus.
• Compléter avec d’autres éléments (ex : retour client) directement dans des fichiers pour garder tous l’historique & réflexion.

Ce travail peut être encore approfondi en utilisant les commandes research, mais on ne va pas les faire ici, on a déjà quelque chose de très solide pour une application de test…

Pour résumer, l’analyse BMAD ne rend pas le projet plus simple. Elle rend sa complexité visible plus tôt.

Le bénéfice de BMAD n’est donc pas de supprimer l’incertitude. Il est de l’exposer suffisamment tôt pour qu’elle puisse être discutée, arbitrée et documentée avant de devenir du code.

Principe 2 : la planification

Maintenant que notre analyse est faite, il faut traduire cette matière en plan de construction. Cela peut paraître étrange de parler de planification dans un développement assisté par IA : après tout, si l’agent peut coder, pourquoi ne pas simplement lui demander de construire l’application ?

Justement parce que, sur une application complexe, l’agent ne pourra pas tout faire correctement d’une traite.

La phase de planification sert à transformer les idées, hypothèses, contraintes et décisions issues de l’analyse en exigences structurées. Dans BMAD, c’est notamment le rôle du PRD : produire un document suffisamment clair pour expliquer ce que l’on veut construire, pourquoi, pour qui, avec quelles priorités et quelles limites.

Cette étape permet de cadrer le développement avant l’implémentation. Elle facilite le découpage du travail, l’itération, la correction des choix passés et la collaboration entre plusieurs personnes ou plusieurs agents. Elle limite aussi un problème fréquent du développement assisté par IA : demander à l’agent de garder trop de choses en mémoire dans une simple conversation.

En documentant le besoin dans un artefact lisible, versionnable et réutilisable, on réduit la dépendance à la fenêtre de contexte du modèle. L’agent n’a plus à deviner ou à se souvenir : il peut relire le PRD, s’appuyer dessus, et produire la suite du projet à partir d’une base explicite.

Le biais combattu ici est donc le biais de continuité : croire qu’une conversation avec l’IA suffit à porter durablement toute la logique produit.

Pour générer ce fichier PRD, on lance simplement dans une nouvelle conversation la commande /bmad-prd create. On le lance dans une nouvelle conversation afin d’obliger l’agent à se ré-appuyer sur les artefacts générés, plutôt que sur le fil de discussion précédent. Cela réduit le risque que l’agent continue sur une mémoire conversationnelle approximative, et l’encourage à repartir des fichiers réellement présents dans le projet :

> /bmad-prd create

● Salut Mathieu 👋

  J'ouvre une nouvelle session PRD — intent : Create pour bmad-fishcount.

  📁 Espace de travail : _bmad-output/planning-artifacts/prds/prd-bmad-fishcount-2026-05-21/
  - prd.md (squelette, status: draft)
  - .decision-log.md (mémoire canonique de la session)
  - Sortie finale : English (selon ta config BMM) ; on discute en français.

  Avant de commencer, deux pistes à garder en tête pour cette session :
  - bmad-party-mode à tout moment si tu veux des perspectives multi-agents sur une section
  - bmad-advanced-elicitation pour creuser une section spécifique (socratique, pre-mortem, red team…)

  ---
  Ce que j'ai déjà en main

  J'ai chargé en contexte :
  - Tes 11 cadres produits issus du brainstorming (vision-only, multi-aquarium, comptage agrégé, pause forcée si caméra indispo, zéro auth, archi
  client-serveur LAN/PWA, ML libre + specs minimales doc., cibles = animaux aquatiques en mouvement, distinction animaux/décor non-négociable, "learning" =  boucle correction utilisateur, confiance relative)
  - 107 idées brainstorming dans _bmad-output/brainstorming/brainstorming-session-2026-05-21-0953.md (What If, SCAMPER, Chaos Engineering)
  - La nature pédagogique du projet (article BMAD ; on évite de s'enliser dans phases lourdes)

  Tu as déjà donné énormément d'amont. Beaucoup de décisions produit sont déjà cristallisées — le PRD va surtout les structurer pour les phases aval (UX,
  architecture, epics).

  ---
  Phase Discovery — Brain dump
  
  Avant de choisir le mode de travail, je te pose la question rituelle, même si on a déjà beaucoup :

  Est-ce qu'il y a quoi que ce soit d'autre que je devrais lire ou que tu veux verbaliser avant qu'on attaque le PRD ?

  Par exemple :
  - des notes/croquis UX que tu aurais commencés ailleurs ?
  - des contraintes que tu n'as pas mises dans le brainstorming (deadline d'article, longueur cible du PRD pour l'article, sections que tu veux absolument montrer/éviter…) ?
  - un angle narratif pour l'article qui devrait teinter ce PRD (genre "je veux que ce PRD montre comment on gère les NFR transverses" ou "je veux qu'il  illustre la rigueur des FR numérotés") ?
  - ou simplement : "non, tout est dans la brainstorming + la mémoire, fonce" ?

  Un simple "rien de plus" suffit et on enchaîne sur le calibrage des enjeux + choix du mode de travail.

> J’aimerais que le développement se fasse en TDD. Que l’AI code d’abords les tests en KO, puis développe ensuite pour les rendre OK. Est-ce dans le prd qu’il faut le mettre ?

● Bonne question — réponse courte : non, pas dans le PRD.

  Pourquoi

  Le PRD répond à quoi et pourquoi : ce que le produit fait, pour qui, sous quelles contraintes produit. Le TDD répond à comment l'équipe construit. C'est une convention d'ingénierie, pas une exigence produit.

  Si on le met dans le PRD :
  - ça brouille la frontière PM / Architecte / Dev (et ton article veut justement montrer ces frontières)
  - chaque phase aval qui lit le PRD doit re-filtrer ce qui la concerne
  - on crée une zone grise où d'autres "comment" vont s'inviter (langage, frameworks, branching strategy…)

  Où ça doit aller

  Trois bons emplacements en BMAD, par ordre de pertinence pour ton cas :

  1. project-context.md (généré par bmad-generate-project-context) — c'est LE fichier "règles AI" qui suit chaque appel de codage. Tu y dictes : "toute story est implémentée en TDD strict : tests rouges d'abord, puis code minimal pour passer au vert, puis refacto". C'est précisément ce que bmad-dev-story lit avant de coder.
  2. Phase Architecture (bmad-create-architecture) — section "Test Strategy" où on documente le cycle, les outils, la pyramide.
  3. Template de story (workflow bmad-create-story / bmad-dev-story) — la convention TDD peut être tissée dans les Definition-of-Done.

  Pour ton article

  Le geste pédagogique propre c'est exactement ça : montrer que le PRD reste agnostique de la méthode de codage, et que la décision TDD apparaît au moment opportun (project-context ou architecture). Ça illustre la séparation des préoccupations BMAD — ce qui est plus fort narrativement que de tout empiler dans le PRD.

  Ce que je te propose maintenant

  1. Je logge la décision dans .decision-log.md ("TDD = convention d'ingénierie, à capturer dans project-context et/ou architecture — explicitement hors PRD")
  2. Je peux sauvegarder en mémoire projet ta préférence TDD pour qu'elle resurgisse automatiquement dans les futures sessions (architecture, story creation, dev).
  3. On reprend le brain dump : tu as autre chose à ajouter, ou je peux enchaîner sur calibrage des enjeux + mode de travail ?

  Ça te va ?

> Oui

‍

Comme vous voyez, je n’ai pas hésité à poser des questions pour la bonne tenue du process. Le TDD n’est pas dans le PRD, mais il a tout de même logger ma requête pour les étapes suivantes. On peut également voir qu’il retrouve bien le contexte du brainstorming, non pas parce qu’il se souvient magiquement de la discussion précédente, mais parce qu’il relit les artefacts générés lors de l’étape d’analyse.

Ensuite, il me propose 2 approches pour générer le PRD :

● Logué dans .decision-log.md + sauvegardé en mémoire projet (project_tdd_convention). Les phases aval (bmad-generate-project-context,
  bmad-create-architecture, bmad-dev-story) verront automatiquement la consigne TDD.

  ---
  Calibrage des enjeux
  
  Je calibre court : ton projet est pédagogique (article BMAD), donc :
  - Enjeux : produire un PRD démonstratif, pas un PRD de lancement. Rigueur méthodologique > exhaustivité produit.
  - Audience aval : tes lecteurs d'article + les phases BMAD suivantes (UX, archi, epics, stories).
  - Profondeur : moyenne — assez riche pour que les phases aval aient de quoi mordre, mais pas alourdie de sections sans valeur narrative.

  Si tu n'es pas d'accord, dis-le ; sinon j'enchaîne.

  ---
  Choix du mode de travail
  
  Deux options. Dans ton cas pédagogique, les deux ont du sens pour des raisons différentes :

  🚀 Option A — Fast path

  Je te pose 1-2 questions consolidées pour combler les derniers trous, puis je drafte tout le PRD d'un coup, avec tags [ASSUMPTION] partout où j'infère. Tu  relis et on itère.
  - Pour : rapide, tu vois vite la forme finale, tu corriges chirurgicalement.
  - Contre : moins narratif pour l'article (le PRD émerge "d'un bloc", pas section par section).

  🎓 Option B — Coaching path

  On parcourt les sections-clés ensemble, je te fais réfléchir en mode PM, on construit progressivement. Tu choisirais aussi entre deux points d'entrée :
  - Vision + Features (capability-first — adapté à un produit technique comme fishcount)
  - Personas + Journeys (user-first — adapté si tu veux donner du poids aux personas dans l'article)
  - ou je te propose le plus pertinent
  - Pour : très démonstratif pour l'article — chaque section devient une mini-scène pédagogique du raisonnement PM. Idéal si tu veux montrer "à quoi ressemble une vraie facilitation PRD".
  - Contre : plus long.
  
  Ma recommandation pour un article BMAD : Coaching path, entrée Vision + Features. Tu as déjà fait l'élicitation utilisateur via la brainstorming ; le coaching ici va surtout faire ressortir le structurant produit que le brainstorm n'a pas encore organisé (groupement features, FRs numérotés, NFRs transverses, métriques). C'est exactement le genre de moment "regardez comment un PM/PRD discipline le chaos créatif" qui fait briller l'article.

  Tu choisis quoi ?

‍

On ne va pas l’écouter et prendre l’option A, ce serait bien trop long de faire un « coaching path », et cet article est déjà bien complet. Mais parlons malgré tout de cette seconde option qui permet encore de challenger le résultat.

Avec l’option B, le workflow ne se contente pas de transformer mécaniquement le brainstorming en PRD. Il accompagne la réflexion étape par étape, comme le ferait un Product Manager, en posant des questions de cadrage, en regroupant les fonctionnalités, en clarifiant les priorités, les utilisateurs, les contraintes et les zones d’incertitude.

On retrouve donc une logique assez proche de celle du brainstorming : un échange guidé, pédagogique, parfois un peu long, mais dont le but est de challenger la matière existante avant de la figer dans un document de planification.

> L'Option A. Dans l'article j'ajouterais une ligne pour expliquer l'option B, mais l'article est déjà bien long.

Logué. Choix narratif intéressant d'ailleurs — la Fast path produit un PRD lourd en [ASSUMPTION], ce qui est en soi pédagogique pour l'article : tu peux montrer "voici comment un PM trace explicitement chaque inférence pour révision". Bonus walkthrough.

  ---
  Avant que je drafte — mes inférences à valider (3 points)
  
  Je batche tout en une question. Stampe "OK" ou corrige seulement ce qui cloche.

  1. Persona principal

  Aquariophile engagé, niveau intermédiaire à avancé, bac communautaire multi-espèces où le comptage manuel devient pénible (poissons qui se cachent, plusieurs espèces, individus mobiles). À l'aise avec smartphone / PC / Wi-Fi local. Mentions secondaires possibles hors MVP : éducateurs (aquariums scolaires), pros aquaculture.

  2. Coupe MVP

  IN MVP :
  - Calibration visuelle (premier lancement + re-déclenchable)
  - Comptage continu avec score de confiance (agrégé + décomposition par individu détecté)
  - Gestion caméra indisponible (pause forcée + dernier comptage affiché + auto-resume)
  - Boucle de correction utilisateur ("apprentissage" = recalibrage scaling, pas re-training ML)
  - Historique local (stockage serveur)
  - Multi-client PWA via LAN
  - États d'erreur explicites quand vision impossible

  OUT MVP (v2+) :
  - Alertes / notifications sur changement de population
  - Détection d'anomalies (mort, stress, maladie)
  - Plusieurs aquariums par serveur (1 serveur = 1 caméra = 1 aquarium en MVP)
  - Identification individuelle (déjà cadre #3, rappel)
  - API publique / overlay OBS (déjà cadre #5, rappel)
  - Auth / rôles / multi-user (déjà cadre #5, rappel)

  Point flou que je tranche par défaut : le système de réputation utilisateur (idée WhatIf #6 — correction fausse dégrade temporairement la confiance des résultats de CET utilisateur). Je l'inclus MVP car couplé intimement à la boucle de correction. À sortir si tu veux alléger.

  3. Tone / aesthetic

  Clean dashboard, video-first, chrome minimal. Le comptage + la confiance sont les héros visuels. Ni kitsch aquatique, ni industriel froid — utilitaire calme. Couleurs sobres ; éventuellement un accent qui signale la qualité de la confiance (vert/jaune/rouge).

  ---
  OK pour drafter sur ces bases, ou tu corriges 1-2 points avant ?

> 1. Nickel
  2. Oui, le système de réputation est un MVP.
  3. Ok

‍

L’agent va alors créer 2 fichiers dans _bmad-output/planning-artifacts/prds/prd-bmad-fishcount-*** : addendum.md et prd.md.

Le PRD, pour Product Requirements Document, est le document qui décrit ce que l’on veut construire avant de décider comment on va le construire. Ce n’est pas encore une architecture technique, ni une liste de tâches de développement. C’est plutôt le contrat produit du projet : quel problème on cherche à résoudre, pour quels utilisateurs, avec quelles fonctionnalités, quelles limites et quels critères de réussite.

Dans notre cas, le PRD généré par BMAD reprend donc la matière issue de l’analyse pour la transformer en exigences plus structurées. On y retrouve notamment la vision du produit, le périmètre du MVP, les utilisateurs visés, les fonctionnalités principales, les exigences fonctionnelles, les contraintes non fonctionnelles, les cas limites, les hypothèses retenues, ainsi que ce qui est explicitement hors périmètre.

L’intérêt est important pour la suite : l’agent IA n’a plus seulement une idée générale du type “faire une application qui compte des poissons”. Il dispose d’un document de référence qui précise ce que cette phrase signifie réellement. Par exemple, le PRD peut indiquer que l’application doit compter les animaux aquatiques visibles, afficher un indice de confiance, fonctionner en local, ne pas nécessiter d’authentification ou encore exclure l’identification individuelle des poissons.

Le fichier addendum.md, lui, joue plutôt le rôle de document complémentaire. Il conserve des éléments utiles au raisonnement, mais qui ne doivent pas forcément apparaître directement dans le PRD final : hypothèses intermédiaires, précisions issues de l’échange, arbitrages, remarques ou informations de contexte. C’est une sorte de mémoire de travail qui permet de ne pas perdre la richesse de la discussion tout en gardant un PRD exploitable.

Résumé

L’approche directe donne l’impression de gagner du temps parce qu’elle saute immédiatement vers l’implémentation. La planification BMAD, elle, accepte de ralentir pour transformer une idée analysée en base de travail stable. Sur un projet réel, ce n’est pas une étape administrative : c’est ce qui permet à l’IA de ne pas coder sur du flou.

Principe 3 : le solutioning

Grâce à la planification, nous avons maintenant un document, le PRD, qui définit ce que nous voulons faire. Maintenant, il faut définir COMMENT le faire, c’est le rôle de cette étape de solutioning.

Dans cette étape on va charger des agents, des rôles qui permettent de définir tel ou tel aspect de l’implémentation de notre application, comme dans la « vraie vie » en fait. Quand un projet est validé, avant de commencer la phase de développement, vous allez voir les experts pour savoir comment vous allez faire les choses :

• L’architecte pour savoir sur quelle architecture technique vous allez faire tourner votre application, quels technos, quels protocoles…
• Le chef de projet, lead dev pour savoir comment vous allez découper l’implémentation pour la confier à vos équipes de dev derrière.
• Etc.

Avec BMAD, c’est exactement ça. BMAD possède un ensemble d’agents pour faire ça :

• John le product manager / Chef de Projet digital (celui utilisé pour la génération du PRD coachée)
• Amelia la lead dev.
• Mary la strategic business analyst (bmad-agent-analyst)
• Winston l’architecte (bmad-agent-architect)
• Paige la spécialiste de la doc technique (bmad-agent-tech-writer)
• Sally l’ux designer (bmad-agent-ux-designer)

Et on peut même en créer des nouveaux, mais on ne va pas s’attarder là dessus aujourd’hui. Ceux qui nous intéressent dans cette étape de solutioning sont juste Winston pour l’architecture et John pour la planification des épics et stories.

Ce travail par agents, plutôt qu’un travail direct avec un prompt unique comporte de très gros avantages :

• Le chat va spécialiser dans un domaine, pour être plus précis et « expert », là ou un prompt général risque de partir dans tous les sens.
• Dans un process de travail en équipe, cela nous permet de séparer les tâches pour inviter les bonnes personnes autour de la tables, là où une seule personne derrière son chat pourrait faire des erreurs, ou ne pas distinguer les erreurs faites par l’IA.

Architecture

Dans un premier lieu, on va définir l’architecture, car de celle-ci peut découler de nombreuses décisions. On appelle donc simplement Winston, et lui demandons de créer le fichier de base de l’architecture :

❯ /bmad-agent-architect                                                                                                                                       

● Bash(python3 /home/mwambre/Development/DGARDEN/bmad-fishcount/_bmad/scripts/resolve_customization.py --skill
      /home/mwambre/Development/DGARDEN/bmad-fishcount/.claude…)
  ⎿  {
       "agent": {
         "name": "Winston",
     … +30 lines (ctrl+o to expand)

  Searched for 1 pattern, read 1 file, listed 2 directories (ctrl+o to expand)

● 🏗️  Bonjour Mathieu ! Winston à l'appareil — l'architecte système prêt à transformer le PRD et l'UX en décisions techniques solides pour bmad-fishcount.

  Petit rappel : tu peux invoquer bmad-help à tout moment si tu veux des conseils sur la suite à donner à la session.

  J'ai noté quelques contraintes structurantes en mémoire pour ce projet :
  - Vision-only counting (pas de capteurs de secours)
  - Adaptable à n'importe quel type d'aquarium
  - TDD strict (red→green→refactor) — vit dans l'architecture & le project-context, pas dans le PRD
  - Projet pédagogique pour un article BMAD → on saute les étapes optionnelles lourdes

  Menu

┌──────┬──────────────────────────────────────────────────────────────────────────────────────────┐
│ Code │                    Description                     │               Action                │ ├──────┼────────────────────────────────────────────────────┼─────────────────────────────────────┤
│ CA   │ Workflow guidé pour documenter les décisions       │ bmad-create-architecture            │
│      │ techniques et garder l'implémentation sur rails    │                                     │ ├──────┼────────────────────────────────────────────────────┼─────────────────────────────────────┤
│ IR   │ Vérifier que PRD, UX, Architecture et Epics &      │ bmad-check-implementation-readiness │
│      │ Stories sont alignés                               │                                     │   └──────┴────────────────────────────────────────────────────┴─────────────────────────────────────┘

  Que veux-tu attaquer ? Vu qu'on a un PRD daté du 21/05 dans _bmad-output/planning-artifacts/prds/ et les livrables UX dans design-artifacts/, CA (création d'architecture) semble la suite logique — mais dis-moi ce que tu vises.

> /bmad-create-architecture

● 🏗️  J'ai parcouru l'arborescence du projet pour réunir le contexte d'architecture. Voici ce que j'ai trouvé :

  Documents découverts

┌────────────────────┬───────────────────────────────────────────────────────┬────────────────────┐
│        Type        │                        Statut                         │ Emplacement        │  ├────────────────────┼───────────────────────────────────────────────────────┼────────────────────│  
│PRD                 │ ✅ Trouvé (complet, status: final)                    │ …/prd.md           │ ├────────────────────┼───────────────────────────────────────────────────────┼────────────────────┤
│ PRD Addendum       │ ✅ Trouvé (décisions repoussées à l'Architecture)     │ …/addendum.md      │ ├────────────────────┼───────────────────────────────────────────────────────┼────────────────────┤
│ Brainstorming      │ ✅ Trouvé (107 idées, 11 contraintes)                 │ …/brainstorming-   │
│ source             │                                                       │   session-2026-05- │
│                    │                                                       │   21-0953.md       │  ├────────────────────┼───────────────────────────────────────────────────────┼────────────────────┤
│ UX Design          │ ❌ Pas encore produit                                 │ —                  │
│                    │ (design-artifacts/C-UX-Scenarios/ vide)               │                    │ ├────────────────────┼───────────────────────────────────────────────────────┼────────────────────┤
│ Project context    │ ❌ Pas encore produit                                 │ —                  │ ├────────────────────┼───────────────────────────────────────────────────────┼────────────────────┤
│ Project docs       │ ❌ Aucun fichier dans docs/ ou design-artifacts/      │ —                  │  └────────────────────┴───────────────────────────────────────────────────────┴────────────────────┘

  Mémoire persistante chargée

  - Vision-only counting, pas de capteur de secours
  - Doit s'adapter à n'importe quel type d'aquarium
  - TDD strict (red→green→refactor) — vit dans l'architecture, pas dans le PRD
  - Projet pédagogique pour article BMAD → on saute les étapes optionnelles lourdes

  Validation des entrées requises

  - ✅ PRD présent (exigence dure)
  - ⚠️  Pas d'UX Design — pas bloquant pour démarrer (le PRD §10 et l'addendum portent déjà les contraintes UX structurantes : dual confidence display, history  journal, lean PWA), mais à garder à l'esprit. La décision Architecture peut précéder l'UX détaillée puisqu'on est dans le mode pédagogique.

  Décisions ouvertes notables (issues du PRD §12 et addendum)

  L'addendum confirme déjà que ces choix sont explicitement à trancher en phase Architecture :
  1. Choix ML : détecteur classique (YOLO/RT-DETR) vs VLM/multimodal
  2. Transport push : WebSocket vs SSE+REST
  3. Scope du User Reputation Score (localStorage / device fingerprint / IP)
  4. Fenêtre de smoothing serveur (5–15s)
  5. Specs hardware minimales (dépend du choix ML)
  6. Heuristique de détection mouvement animal vs décor (NFR-4 ⭐ — load-bearing)

  ---
  Avant de créer le document d'architecture et d'enchaîner sur l'analyse du project context :
  
  As-tu d'autres documents que je devrais charger ? Notamment :
  - Des contraintes hardware spécifiques (machine cible déjà choisie ?)
  - Des préférences de stack (langage, framework, base de données) que tu veux poser dès maintenant ?
  - Un article ou un repo de référence dont s'inspirer ?

  Sinon, on peut partir directement sur le PRD + addendum + mémoire — c'est largement assez de matière.

  [C] Continuer vers l'analyse du project context (création du document architecture.md et démarrage de l'atelier)

> Pas de contexte hardware spécifique, de préférence de stack ou inspiration. Tu peux [C] Continuer

‍

L’architecte va donc prendre plusieurs décisions, que vous allez pouvoir valider ou compléter. Je ne vais pas copier toute la discussion qui n’a pas grand intérêt dans cet article, mais comme l’étape précédente, il est possible de procéder sous forme de « party mode » pour challenger les choix et la lecture du PRD.

Dans notre cas, l’agent a même utilisé la recherche web pour comparer différentes solutions. C’est donc puissant, mais potentiellement gourmand en tokens. Il nous a choisi un server en Python/FastAPI/ML/Sqlite et un client en TypeScript/Vite/React/PWA. Pourquoi pas, c’est cohérent, python est un choix cohérent côté serveur, car l’écosystème ML/vision y est très mature., et un client vite est facilement compatible sur tout sorte d’interface client.

On peut surtout voir qu’il a bien pris les contraintes que nous avons définis avant :

• Définition de configuration minimales pour le serveur.
• Stockage des historiques dans une base de données.
• Sélection d’algorithmes de comptage pour nos poissons.
• Etc.

Toutes ces décisions sont ensuite consignées dans un fichier architecture.md, qui, comme les artefacts précédents, reste lisible par un humain, amendable et versionnable.

Epic & Stories

Maintenant que notre architecture est définie, on peut maintenant faire appel à John pour générer nos epic & stories.

> /bmad-agent-pm
● 📋 Salut Mathieu ! John à l'appareil — ton PM de service.

  Le planning est bouclé côté PRD et architecture (cf. mémoire du 2026-05-21), donc on est probablement à l'étape de découpage en epics/stories ou de  vérification d'alignement avant d'attaquer l'implémentation. Petit rappel : tu peux invoquer bmad-help à tout moment si tu veux qu'on te recommande la  prochaine étape.
[…]  Vu où on en est (PRD + archi prêts, prochaine étape = epics/stories puis implémentation), je te recommanderais CE pour générer la liste des epics et stories. Mais tu décides — quel code on lance ?

> /bmad-create-epics-and-stories

‍

Étape très similaire à la précédente. John va vous lister les différents épics et stories qu’il retire des documents générés précédemment (PRD, architecture…), que vous pourrez modifier, agrémenter, supprimer… Et comme précédemment, il nous est possible de rentrer dans un « party mode » où on peut faire appel aux autres agents pour challenger la lecture des documents. A vous de voir quel niveau de solidité vous souhaitez pour ces étapes, ici j’ai fait au plus simple, en vérifiant manuellement et lui demandent de continuer par lui-même.

L’agent a créé un fichier epics.md contenant nos stories & epics. Ce fichier sert ensuite de backlog de référence. Il permet de suivre ce qui doit être développé, de préparer les stories une par une et de répartir plus facilement le travail. Selon l’organisation choisie, l’état d’avancement peut être suivi dans ce fichier, dans les stories générées ensuite, ou dans un outil externe comme Jira, GitHub Issues, Linear, etc.

Implementation Readiness Check

Ici on va voir quelque chose d’intéressant avec BMAD, qu’on va beaucoup voir dans l’implémentation : le fait de vérifier la validité d’une étape précédente.

John a généré les epics et stories à partir du PRD et de l’architecture. Mais avant de passer à l’implémentation, il reste une question importante : est-ce que tout est bien aligné ? Est-ce que les stories couvrent réellement le PRD ? Est-ce qu’elles respectent les choix d’architecture ? Est-ce qu’il reste des contradictions ou des zones floues ?

On va donc vérifier avec Winston qu’il n’a pas fait de « bêtise ». Et afin de consolider encore d’avantage cette vérification, je vais passer sur un agent IA différent : Codex. Cela ne garantit évidemment pas une vérité absolue, mais cela permet d’ajouter un regard différent et de limiter le risque qu’un même modèle valide ses propres angles morts.

> /bmad-agent-architect
[…]
> /bmad-check-implementation-readiness

‍

L’agent va alors vérifier la cohérence entre tous les documents. Dans mon cas, l’agent n’a pas relevé de problème bloquant, y compris en changeant de modèle, mais cette étape est fortement recommandée. Les documents générés (prd.md, epics.md et architecture.md) vont être utilisés tout au long du développement. Donc s’il y a une incohérence, elle risque de se retrouver dans notre application finale, ce serait dommage.

Résumé

L’approche directe laisse souvent l’IA choisir l’architecture au fil de l’eau. BMAD, lui, force à rendre ces choix visibles avant qu’ils ne deviennent du code. Le solutioning ne sert donc pas seulement à préparer l’implémentation : il évite que l’application repose sur une accumulation de décisions techniques implicites.

Principe 4 : l’implémentation

Nous avons maintenant tous ce qu’il faut pour commencer, enfin, le développement de notre application. Mais même pour cela, nous n’allons pas simplement dire à claude « développe moi l’application en prenant les documents générés dans _bmad-output. Certes, ça pourrait fonctionner, mais BMAD implémente un processus bien plus solide, à l’aide de l’agent développeur (Amelia) :

• bmad-create-story : Va créer un fichier de story isolant et détaillant d’avantage ce qui va être fait dans la story, et potentiellement re-challenger la story à l’aide des agents.
• bmad-dev-story : qui va implémenter la story.
• bmad-code-review : facultatif mais recommandé, qui va vérifier que ce qui est implémenter correspond bien à ce qui a été défini dans la story.

Mais avant cela, il faut lancer le sprint planning, voici ce que ça donne :

> /bmad-agent-dev
[…]
> /bmad-sprint-planning
[…]
● 💻 Sprint status généré avec succès

  ┌───────────────────┬──────────────────────────────────────────────────────────┐
  │     Métrique      │                          Valeur                          │
  ├───────────────────┼──────────────────────────────────────────────────────────┤
  │ Fichier           │ _bmad-output/implementation-artifacts/sprint-status.yaml │
  ├───────────────────┼──────────────────────────────────────────────────────────┤
  │ Total épics       │ 5                                                        │
  ├───────────────────┼──────────────────────────────────────────────────────────┤
  │ Total stories     │ 29                                                       │
  ├───────────────────┼──────────────────────────────────────────────────────────┤
  │ Épics en cours    │ 0                                                        │
  ├───────────────────┼──────────────────────────────────────────────────────────┤
  │ Stories terminées │ 0                                                        │
  ├───────────────────┼──────────────────────────────────────────────────────────┤
  │ Retrospectives    │ 5 (optional)                                             │
  └───────────────────┴──────────────────────────────────────────────────────────┘

  Répartition par épic :
  - Epic 1 — Live Count Foundation : 10 stories (1.1 → 1.10)
  - Epic 2 — Camera Resilience & Connection State : 3 stories (2.1 → 2.3)
  - Epic 3 — Progressive Calibration & User Corrections : 6 stories (3.1 → 3.6)
  - Epic 4 — History Journal & Events : 5 stories (4.1 → 4.5)
  - Epic 5 — Operational Control & Deployment : 5 stories (5.1 → 5.5)
  
  Validation :
  - ✅ Tous les épics et stories des epics.md sont présents
  - ✅ Chaque épic a une entrée retrospective
  - ✅ YAML valide (39 items)
  - ✅ Tous les statuts initiaux sont légaux (backlog / optional)

  Prochaine étape recommandée : lancer CS (bmad-create-story) pour matérialiser Story 1.1 — Project Skeleton Initialization — avec tout le contexte requis, puis DS (bmad-dev-story) pour implémenter en TDD strict. Tu veux que j'enchaîne sur la création de la 1.1 ?

‍

On peut voir que l’agent a créé le fichier  _bmad-output/implementation-artifacts/sprint-status.yaml, Dans ce fichier, on peut retrouver toutes nos epic et stories, ainsi que leur état (toute en backlog pour le moment). C’est très intéressant, ce fichier peut être partagé sur Git pour donner une vision commune de l’avancement. En revanche, dans un vrai projet à plusieurs développeurs, il faudra rester vigilant aux conflits de merge, ou éventuellement synchroniser cet état avec un outil de suivi externe.

On va ensuite, dans un nouveau chat, générer un fichier contenant le contexte d’implémentation de la première story :

> /bmad-agent-dev
[…]
> /bmad-create-story
● 💻 🎯 ULTIMATE BMAD Method STORY CONTEXT CREATED, Mathieu !

  Story Details:
  - Story ID: 1.1
  - Story Key: 1-1-project-skeleton-initialization
  - File: _bmad-output/implementation-artifacts/1-1-project-skeleton-initialization.md
  - Status: ready-for-dev
  
  Ce qui a été contexté :
  - 11 ACs numérotés et citables, chacun référencé à epics.md / architecture.md ligne par ligne.
  - 6 Tasks alignées sur les ACs, avec commandes exactes (uv add ..., npm install -D ...) et les contenus de fichiers verbatim (FastAPI stub,
  .pre-commit-config.yaml complet).
  - Guardrails architecturaux : two-init no-workspace, cv2 confiné à capture/, SSE event types lockés, wire format snake_case, datetime ISO 8601 Z, IDs entiers.
  - Carve-out TDD explicite (AC-11) : Story 1.1 est infra-only — pas de pair red:/green: ici, mais la pipeline qui imposera cette discipline à partir de Story 1.2 est entièrement câblée et vérifiée verte.
  - Versions May 2026 documentées (FastAPI 0.136+, Vite 6, react-router-dom v7, Python 3.12, uv 0.11.x, YOLO26).

  Sprint status : epic-1 → in-progress, 1-1-project-skeleton-initialization → ready-for-dev.

  Next Steps :
  1. Relis le fichier story et confirme qu'il dit bien ce que tu veux.
  2. Lance bmad-dev-story (menu code DS) pour que j'implémente le squelette.
  3. Optionnel : bmad-story-automator pour enchaîner toutes les stories de l'épique 1 en autonome.

‍

À la suite de cette commande, on remarque 2 choses :

Dans le fichier précédemment généré, _bmad-output/implementation-artifacts/sprint-status.yaml, la 2 lignes ont changé :

• epic-1 est passée de backlog à in-progress
• 1-1-project-skeleton-initialization est passée de backlog à ready-for-dev.

La création d’un fichier _bmad-output/implementation-artifacts/1-1-project-skeleton-initialization.md contenant les détails d’implémentation de la première story, avec entre autres :

• Les critères d’acceptation.
• La liste des tâches / sous-tâches à implémenter, sous forme de liste à coches. Ces coches sont censées permettre de suivre l’état d’avancement de la story, même si nous verrons plus loin que leur mise à jour dépend aussi de la manière dont l’agent applique le workflow.
• Les standards et critères à suivre pour le développement.
• Les références vers nos fichiers d’analyse, solutioning, epics.

Dans le processus décrit précédemment, on devrait lancer un bmad-dev-story, mais que se passe-t-il si on lance un nouveau bmad-create-story ?

> /bmad-agent-dev
[…]
> /bmad-create-story
● 💻 Bonjour Mathieu ! On enchaîne avec la création de la prochaine story.
  Statut sprint : 1-1-project-skeleton- nitialization est déjà ready-for-dev, donc la prochaine story backlog est 1-2-history-table-alembic-baseline. Je lance l'analyse exhaustive des artefacts.
[…]
● 💻 🎯 Story Context Story 1.2 créé, Mathieu !

  Détails de la story :
  - Story ID : 1.2
  - Story Key : 1-2-history-table-alembic-baseline
  - Fichier :  _bmad-output/implementation-artifacts/1-2-history-table-alembic-baseline.md
  - Status : ready-for-dev
  - Sprint status : mis à jour (last_updated 2026-05-22)

  Couverture de la story :
  - 9 ACs explicites : modèle SQLModel History, engine + WAL via event.listens_for, Alembic init + baseline 0001_initial_schema.py, upgrade/downgrade round-trip, 4 tests d'intégration (dont le test structurel NFR-14 « snapshot_id qui recule ne casse pas le id monotone »), garde « pas d'autres tables », discipline TDD red→green commit-level, et settings via pydantic-settings + .env.example.
  - 5 tasks linéaires avec subtasks copy-paste-friendly (commandes uv run  alembic, snippets Python complets pour History, db.py, env.py).
  - Garde-fous critiques : PK auto-increment NON timestamp, WAL au niveau engine (pas migration), ts_server UTC tzinfo, indexes ix_history_snapshot_id +  ix_history_ts_server pour FR-17 downstream.
  - Dépendances explicites sur la story 1.1 (encore non implémentée — flag  noté).

  Prochaines étapes :
  Vous pouvez vouloir d'abord faire bmad-dev-story sur la story 1.1 (qui est en ready-for-dev depuis le 2026-05-21), sinon la 1.2 ne peut pas atterrir

‍

Si on regarde les modifications encore une fois, on voit que comme précédemment la story 1.2 vient de changer d’état en ready-for-dev, et un fichier de story a été créé. Cela met en évidence la possibilité de paralléliser les développements. Par exemple, un développeur peut demander à son agent de développer la première story, avec le code review, et en parallèle un second développeur peut faire de même avec la seconde, sous réserve que les 2 stories ne soient pas interdépendantes (ce qui est malheureusement le cas ici). C’est une chose qui serait bien difficile à faire avec une approche directe.

La liste des tâches / sous-tâches à implémenter, sous forme de liste à coches. Ces coches sont censées permettre de suivre l’état d’avancement de la story, même si nous verrons plus loin que leur mise à jour dépend aussi de la manière dont l’agent applique le workflow.

Lançons maintenant la commande bmad-dev-story.

L’agent va alors passer, dans le fichier sprint-status.yaml, passer l’état du sprint 1 de « ready-for-dev » à « in-progress », puis lire l’artefact lié à la story généré précédemment, et développer une par une les tâches et sous-tâche listés. J’ai dû bien évidemment lui autoriser d’exécuter des commandes sur ma machine, il est donc primordial de bien relire les commandes effectuées. Ce n’est pas spécifique à BMAD d’ailleurs, c’est valable pour tous développement par IA.

Petite subtilité : chez moi, la commande n’a pas coché dans le fichier 1-1-project-skeleton-initialization.md les tâches au fur et à mesure du développement, mais seulement en fin de story. Ce n’est pas forcément absurde : BMAD impose de ne cocher une tâche qu’une fois celle-ci réellement terminée et validée. En revanche, cela pose une vraie question de reprise en cas de coupure. Si l’état d’avancement n’est pas régulièrement reporté dans le fichier de story, une partie du contexte reste dans la conversation plutôt que dans les artefacts du projet.

C’est un risque avec les agents : même lorsqu’ils suivent globalement le workflow, leur interprétation pratique peut ne pas être celle que vous souhaitez. Mais on peut très bien les reconfigurer, par exemple en relançant l’agent dev et en lui indiquant quel comportement prendre, tout en lui demandant de sauvegarder ça en mémoire :

> /bmad-agent-dev
[…]
> J'ai développé la story 1 dernièrement, et j'ai pu voir que les tâches on été "cochées" comme validées qu'à la fin du dev. Pourrais tu changer ta logique, à savoir cocher les tâches/sous-tâches une fois celle-ci validés, au fur et à mesure que chaque tâche, sous-tâche est validé, afin de faciliter la reprise en cas de coupure en cours de développement de story. Met ça en mémoire pour que ce soit le cas pour tous les futurs développements.

● 💻 Noté et mis en mémoire (feedback_incremental_task_checkoff.md).

  À partir de maintenant, pour chaque story :
  - [ ] → [x] immédiatement après validation de chaque sous-tâche (tests verts + AC satisfait), avant de passer à la suivante.
  - Idem pour les tâches parentes une fois tous leurs enfants cochés.
  - Plus de batch final — la story file devient un journal de reprise fiable.

  Prêt pour la suite : DS pour enchaîner sur la prochaine story ?

‍

On voit que notre story est passée en « review »,indiquant qu’on peut y faire la dernière étape, le code review. Pour être plus robuste, je lance dans codex plutôt que claude :

> /bmad-agent-dev
> /bmad-code-review● 💻 Bonjour Mathieu ! Amelia à l'appareil — votre Senior Software Engineer pour la phase d'implémentation. Je travaille en TDD strict (red → green → refactor), tâches dans l'ordre, AC vérifiés.

  État actuel du sprint :
  - 1-1-project-skeleton-initialization → review (prêt pour CR)
  - 1-2-history-table-alembic-baseline → ready-for-dev (prêt pour DS)

[…]

> /bmad-code-review
[…]

● Je lance les 3 reviews adversariales en parallèle.

● 3 background agents launched (↓ to manage)
   ├ Blind Hunter review
   ├ Edge Case Hunter review
   └ Acceptance Auditor review
     
● 3 reviews lancées en parallèle :
  - 🔍 Blind Hunter (diff seul)
  - 🪤 Edge Case Hunter (diff + lecture projet)
  - ✅ Acceptance Auditor (diff + spec + AC)
  
[…]

‍

On voit que l’agent a fait appel à plusieurs sous-agents pour vérifier le code généré. Dans mon cas, la seule « problématique » qui a été détectée était un fichier .gitignore trop strict, mais on voit que même sur une simple story, il peut y avoir des écarts avec l’attendu. Alors imaginez sur un vibe coding direct sur une grosse application sans faire de review…

Résumé

L’approche directe donne l’impression d’aller plus vite parce qu’elle supprime presque toute la préparation avant le code. BMAD, au contraire, impose de ralentir l’implémentation pour la rendre plus contrôlable : une story, des critères d’acceptation, des tests, une trace, puis une review. Ce n’est pas seulement une manière de coder avec l’IA, c’est une manière de garder le développement IA auditable et reprenable.

‍

Synthèse comparative approche IA directe vs BMAD

‍

Conclusion sur l'usage de BMAD

Si la méthode BMAD est bien plus coûteuse en termes de temps et plus contraignante qu’un développement direct par intelligence artificielle, on a pu voir qu’elle permet de résoudre plusieurs problèmes majeurs :

• Le cadrage du besoin : BMAD force à clarifier le problème avant de coder, à faire émerger les hypothèses implicites, les angles morts, les contraintes et les cas limites.
• La continuité du contexte : le raisonnement ne reste pas enfermé dans une conversation avec l’agent. Il est transformé en artefacts lisibles — brainstorming, PRD, architecture, epics, stories — que l’on peut relire, versionner et réutiliser.
• La cohérence des décisions : chaque étape s’appuie sur la précédente, tout en pouvant la challenger. Le PRD définit le “quoi”, l’architecture le “comment”, les stories le “par quoi commencer”, et les checks permettent de vérifier que tout reste aligné.
• Le travail en équipe et la reprise du projet : les documents produits permettent à un PO, un architecte, un développeur ou un client de comprendre les choix réalisés, de les corriger, puis de reprendre le projet sans dépendre de la mémoire d’un chat ou d’une seule personne.

Par cette méthode, nous avons aussi pu voir autre chose : non, contrairement à ce que le marketing de certains des acteurs de l’intelligence artificielle veut nous faire croire, l’intelligence artificielle ne peux pas développer seule une application de A à Z, du moins une application fiable, évolutive et de qualité. Si elle permet de faciliter certaines tâches et change indéniablement les métiers du développement informatique, il sera toujours nécessaire d’avoir des experts, des développeurs, des architectes, des PO pour la guider et prendre les bonnes décisions en connaissance de causes. Ceci est encore plus vrai au fur et à mesure de sa démocratisation, et au fur et à mesure que des personnes mal intentionnées arrivent à la manipuler pour injecter dans les applications générées sans prise de recul du code malveillant.

Finalement, la méthode BMAD ne rend pas le développement par IA magique, ni même forcément plus rapide à court terme. Son intérêt est ailleurs : il transforme une pratique conversationnelle, volatile et souvent individuelle en un processus structuré, documenté et vérifiable. Là où l’approche directe cherche à maximiser la vitesse immédiate, BMAD cherche à maximiser la maîtrise du projet dans la durée.

‍

Pourquoi se faire accompagner par une agence experte IA sur ce type de méthode ?

BMAD, comme tout framework de développement assisté par IA, n'a de valeur que par la manière dont on l'utilise. Le télécharger prend deux minutes. L'installer dans Claude Code, Codex ou Cursor en prend dix. Mais l'intégrer réellement dans une équipe de développement, l'articuler avec vos contraintes de qualité, vos exigences sécurité, votre dette technique existante et vos processus de revue : c'est un tout autre sujet.

Confier un projet à une équipe qui maîtrise ce type de méthode, ce n'est pas chercher à "aller plus vite avec l'IA". C'est s'assurer que :

• les décisions produit et techniques restent les vôtres, documentées, auditables, reprenables et pas enfouies dans la mémoire d'un chat ;
• le code généré est revu, testé et challengé par des développeurs seniors qui savent reconnaître une hallucination d'une vraie décision d'architecture ;
• votre projet ne dépend pas d'un outil ni d'une personne : si demain vous reprenez la maintenance en interne, si vous changez de prestataire, si vous voulez faire évoluer la solution dans deux ans, les artefacts produits (PRD, architecture, epics, stories, decision logs) restent lisibles et exploitables ;
• les usages de l'IA sont cadrés, y compris du point de vue sécurité, propriété intellectuelle et conformité, un point sensible que peu d'équipes traitent sérieusement aujourd'hui.

L'enjeu est de savoir qui pilote, qui valide, qui documente, et qui sera capable de reprendre le projet dans six mois.

Pourquoi une agence avec une vraie démarche R&D fait la différence

Les outils d'IA appliqués au développement évoluent chaque semaine. Entre les frameworks émergents (BMAD, mais aussi d'autres approches qui apparaissent en continu), les nouveaux modèles, les protocoles comme MCP, les agents spécialisés, les outils de revue automatisée, etc. il est impossible pour une équipe interne, déjà occupée à livrer, de tout tester sérieusement.

C'est pour cette raison que cet article existe : ce REX n'est pas un exercice de communication, c'est une vraie mise en pratique réalisée par nos équipes, avec les difficultés, les limites et les ajustements que nous avons rencontrés. C'est ce que nous appelons une posture de R&D appliquée : se confronter à la réalité d'un outil avant de prétendre en faire un argument commercial.

Si vous avez un projet web, applicatif ou e-commerce à mener, nos équipes intègrent ces approches dans leurs missions de conception, développement et intégration. L'IA y est un outil de plus dans la boîte, utilisé là où elle apporte vraiment quelque chose.

‍

‍