La méthode BMAD : développer avec des agents IA sans perdre le fil

Demandez à un assistant de code IA d'écrire une fonction : le résultat est souvent bluffant. Demandez-lui de construire un produit complet sur plusieurs semaines : il oublie les décisions de la veille, réinvente ce qui existe déjà et dérive peu à peu de l'intention de départ. Le problème n'est pas la qualité du code, c'est la continuité du contexte.

BMAD en une phrase

BMAD (Breakthrough Method for Agile AI-Driven Development) est une méthode open source, sous licence MIT, qui organise le travail avec des agents IA comme celui d'une équipe agile : des rôles spécialisés, des livrables écrits, et des décisions qui restent explicites d'une étape à l'autre. Elle s'installe dans votre projet sous forme de fichiers (agents, workflows, modèles) et fonctionne avec les principaux assistants de code. La version stable est la v6 ; une v7 est en préversion.

Les principes

1. Des rôles spécialisés plutôt qu'un assistant à tout faire

Analyste, chef de produit, designer UX, architecte, développeur, testeur : chaque agent a un périmètre, une posture et des livrables. On ne demande pas à l'architecte d'écrire du code, ni au développeur de redéfinir le produit.

2. Le contexte vit dans des documents, pas dans la conversation

Brief produit, PRD (le cahier des exigences), architecture, décisions d'architecture (ADR), stories : chaque étape produit un document versionné avec le code. L'agent suivant part de ces documents plutôt que d'une conversation qu'il n'a pas vue. Les décisions ne sont pas réexpliquées à chaque session.

3. Planifier avant de construire

La méthode enchaîne quatre temps : analyse (idée, marché, brief), planification (exigences, expérience utilisateur), conception (architecture, découpage en epics et stories), puis implémentation, story par story, avec revue et rétrospective.

4. Un processus proportionné

Une correction mineure n'a pas besoin d'un PRD. BMAD adapte la profondeur de planification à la taille du travail : circuit court pour les petits changements, planification complète pour un produit.

5. L'humain garde la main

Les agents proposent, l'humain arbitre. Les hypothèses non validées sont signalées comme telles, et les décisions du responsable produit sont tracées.

Le test : UWH-Tracker

Pour me faire un avis, j'ai appliqué BMAD (v6.12, avec Claude Code) à un projet personnel exigeant : UWH-Tracker, un capteur de cheville pour le hockey subaquatique. Le boîtier enregistre la profondeur et les mouvements pendant l'entraînement, puis décharge la séance en Bluetooth vers une application iPhone au vestiaire, puisque le Bluetooth ne passe pas sous l'eau. Le projet mêle firmware embarqué (microcontrôleur nRF52840, capteur de pression, mémoire flash), protocole Bluetooth et application iOS : un bon terrain pour voir si la méthode tient la complexité.

La planification : une journée, et des documents solides

En une journée de travail avec les agents analyste, chef de produit et architecte, le projet disposait de :

• un PRD d'une quarantaine d'exigences fonctionnelles, avec parcours utilisateurs, indicateurs de succès et un index de 35 hypothèses à valider ;
• une architecture et une première décision formalisée (ADR) sur le protocole Bluetooth et le format de stockage en flash ;
• un découpage en 5 epics et 50 stories, dont 9 repoussées en V2, chacune avec ses critères d'acceptation et la liste des exigences qu'elle couvre.

Le plus utile n'a pas été le volume, mais les questions. Les agents ont fait remonter des choix que j'aurais tranchés trop tard : la fréquence d'échantillonnage du capteur de mouvement (fixée à 52 Hz), la source de la fréquence cardiaque (Apple Health plutôt qu'une intégration directe), la précision d'horloge nécessaire pour aligner les données. Chaque décision est datée dans le PRD.

L'implémentation : story par story, avec une revue adverse

Les trois premières stories (squelette du firmware et banc de test sur la carte, pilote de la mémoire flash, lecture, écriture et effacement) ont suivi le même cycle : une spécification courte qui fige l'intention, l'implémentation, puis une revue par un agent distinct, chargé de chercher les failles.

Sur la troisième story, cette revue a produit onze remarques. La plupart ont été corrigées (un test qui pouvait réussir à tort, des délais mal documentés), deux ont été réfutées preuves à l'appui, et une a été reportée dans un registre de « travail différé » plutôt qu'oubliée. Le développement a aussi documenté une vraie surprise technique : le contrôleur SPI de la puce ignore silencieusement les données qui ne sont pas en mémoire vive, ce qui imposait une copie intermédiaire.

Ce qui n'est pas encore prouvé

Soyons précis : ces trois stories sont en revue. Elles compilent et leurs tests sur ordinateur passent, mais les tests sur la carte réelle restent à exécuter. Les agents l'ont d'ailleurs écrit noir sur blanc dans leurs notes, sans le maquiller. La méthode n'a donc pas encore été éprouvée sur la durée du projet.

Ce que j'en retiens

• La valeur est dans les documents. Un PRD et une architecture tenus à jour rendent chaque session d'IA productive dès la première minute, et restent lisibles par un humain qui rejoint le projet.
• La traçabilité change la relation à l'IA. Chaque story renvoie à des exigences, chaque écart est consigné : on peut auditer ce que l'agent a fait, et pourquoi.
• La revue par un agent distinct est l'atout le plus sous-estimé. Elle trouve de vrais défauts, à condition que l'humain arbitre ses remarques.
• Ce n'est pas magique. La méthode produit beaucoup de texte, qu'il faut lire et valider. Sur un petit script, c'est disproportionné ; sur un produit, c'est un investissement rentable.
• Le rôle humain se déplace vers la décision, l'arbitrage et la vérification, ce qui demande justement de la séniorité.

Et pour vos projets data ?

Les projets data souffrent des mêmes maux que le développement assisté par IA : intentions floues, décisions perdues, dérive entre ce qui était prévu et ce qui est livré. Les principes de BMAD s'y appliquent directement : formaliser les exigences et les définitions avant de construire, documenter les décisions d'architecture, découper en livrables vérifiables, faire relire par un regard indépendant.