BMAD-Method : le plan d’urbanisme qui apprivoise l’IA agentique dans votre SDLC

L’IA agentique promet de révolutionner le développement logiciel, mais sans cadre structuré, elle génère vite du « vibe coding » incontrôlé et de la dette technique. La méthode BMAD propose une réponse concrète : transformer ces nouveaux coéquipiers numériques en membres d’une équipe disciplinée, pilotée par des humains.

L’IA agentique est en train de rebattre les cartes du développement logiciel. On ne parle plus seulement d’auto‑complétion de code mais d’équipes mixtes où humains et agents collaborent pour concevoir, développer et maintenir des systèmes complexes. La méthode BMAD propose un cadre pour organiser ce nouveau « chantier ». C'est un plan d’urbanisme pour éviter que notre usage de l’IA ne se transforme en bidonville technologique.

Depuis l’arrivée des LLM, beaucoup d’équipes se sont mises à « coder au feeling » avec l’IA : on colle un prompt dans un outil, on récupère du code, on ajuste à la main, et on recommence. Sur le court terme, c’est grisant. Sur le long terme, c’est une dette explosive.

C’est un peu comme laisser chaque développeur négocier directement avec un entrepreneur pour agrandir sa maison : on finit avec des extensions partout, pas de plan d’ensemble et un réseau électrique prêt à prendre feu au premier orage.

La méthode BMAD part du principe inverse : si l’IA devient un acteur majeur du développement, alors il faut lui donner un cadre, des rôles, des règles du jeu et une vraie supervision.

Il est utile de voir BMAD comme un chantier de construction où les agents IA jouent le rôle de contremaîtres spécialisés :

• un agent qui clarifie le besoin et produit une vraie spécification, plutôt qu’un prompt flou

• un agent architecte qui propose des options d’architecture alignées avec nos standards

• des agents « artisans» qui génèrent le code, les tests, la documentation

• des agents contrôleurs qui traquent les défauts, la dette technique et les régressions.

L’humain, lui, reste l’architecte en chef et le maître d’ouvrage : il définit la vision, les contraintes non négociables (architecture, sécurité, conformité, performance) et tranche les décisions structurantes. La force de BMAD, c’est d’organiser cette collaboration humain‑agents comme un vrai processus, pas comme une succession de « coups de chance » avec l’IA.

Introduire BMAD dans une DSI de grand groupe ne veut pas dire réinventer tout le SDLC. C’est plutôt comme ajouter un turbo à un moteur déjà en place : si on le branche n’importe comment, on casse tout ; si on le connecte aux bons endroits, on démultiplie la performance.

Concrètement, on peut penser l’intégration en trois zones :

1. Amont – de l’idée au plan d’attaque

   Les agents aident à transformer une intention métier en PRD structuré : objectifs, hypothèses, contraintes, cas d’usage, risques. On sort du prompt improvisé pour revenir à une vraie spécification, mais produite beaucoup plus vite.

2. Milieu – de l’architecture au code et aux tests

   Les agents proposent des architectures, des designs d’API, des squelettes de services, puis génèrent le code et les tests dans le cadre défini. Le flux idéal : on ne demande pas à l’IA « écris‑moi une app », on lui demande « implémente ce module dans ce design précis ».

3. Aval – de la livraison à la dette technique

   Une fois en run, les agents surveillent, analysent les logs, remontent les problèmes récurrents et alimentent un backlog de dette technique priorisé. L’IA ne sert pas seulement à ajouter des fonctionnalités, mais aussi à tenir la maison en ordre.

   
   

La plupart des grandes DSI ont une cave pleine de dettes techniques accumulées : frameworks obsolètes, services monolithiques, scripts opaques. L’IA, mal utilisée, peut se contenter de repeindre les murs. BMAD pousse à faire l’inverse : ouvrir les murs, tirer de nouveaux câbles, documenter ce qui n’a jamais été documenté.

Une bonne manière de l’expliquer à ses équipes :

« Notre SI est un immeuble ancien. L’IA peut être un super décorateur d’intérieur, mais ce dont on a besoin, c’est d’un ingénieur structure et d’un électricien. BMAD nous oblige à traiter la structure : architecture, dette, qualité, pas seulement la couche de peinture. »

Dans la pratique, cela veut dire :

• utiliser les agents pour cartographier le code, identifier les zones à risque et proposer des plans de refactorings progressifs ;

• systématiser la génération de tests et de documentation pour résorber le passif ;

• intégrer la réduction de dette comme un flux continu, pas comme un « projet à côté ».

La question implicite dans toute discussion sur BMAD, c’est : « que va devenir le rôle du développeur, du QA, de l’architecte ? ».

L'analogie est celle de passer du pilotage manuel au pilotage automatique dans l’aviation.

Le pilote n’a pas disparu. Son travail a changé : moins de gestes répétitifs, plus de gestion des situations complexes, de la navigation et de la sécurité globale. Le pilote qui refuse toute assistance finit par être dangereux. Celui qui délègue tout à la machine l’est tout autant.

Avec BMAD :

• les développeurs deviennent des designers de solutions et des reviewers exigeants du travail des agents ;

• les architectes orchestrent un système où les contraintes d’entreprise sont « injectées » dans les agents (guidelines, patterns, check‑lists) ;

• les product et les managers apprennent à cadrer le problème et à évaluer la valeur produite par une chaîne hybride humain‑IA.

Ne pas encadrer l’usage de l’IA, c’est laisser chaque équipe expérimenter dans son coin. Sur le papier, c’est « agile ». En réalité, c’est comme laisser chaque équipe choisir sa propre monnaie interne : au bout d’un moment, plus personne ne comprend les échanges.

Sans méthode type BMAD :

• la qualité devient aléatoire, dépendante du talent individuel à « parler » aux modèles ;

• les architectures dérivent, avec des choix technos incohérents sur un même domaine ;

• la sécurité et la conformité deviennent impossibles à auditer, car personne ne sait vraiment qui a généré quoi ni sur quels critères.

BMAD, ou un cadre similaire, ne garantit pas la perfection. Mais il impose une colonne vertébrale : des rôles, des étapes, des artefacts, des points de contrôle. C’est la différence entre une ville qui s’est construite autour de plans d’urbanisme, et un bidonville qui a poussé au fil des opportunités.

Si on devait résumer l’approche :

1. Commencer par les règles du jeu, pas par les outils

   Avant de choisir telle ou telle implémentation de BMAD, clarifier : quels sont nos standards d’architecture, de sécurité, de qualité ? Qu’acceptons‑nous – ou pas – de déléguer à des agents ?

2. Choisir quelques cas d’usage pilotes très concrets

   Par exemple : modernisation d’un service legacy, création d’un micro‑service from scratch, refactorisation d’un module critique. L’objectif n’est pas de « mettre de l’IA partout », mais de prouver que la méthode tient dans des contextes réels.

3. Mesurer et raconter

   Mesurer le temps gagné, la qualité obtenue, l’impact sur la dette technique, mais aussi la perception des équipes. Puis partager ces histoires en interne : la transformation culturelle se fait autant par les récits que par les outils.

4. Accepter que BMAD évoluera

   Les modèles, les agents, les pratiques vont bouger vite. La force d’un cadre de type BMAD, c’est justement de pouvoir encaisser ces changements, comme un bon plan d’urbanisme permet de rénover une ville sans tout raser à chaque fois.

L’IA agentique ne va pas remplacer nos équipes. Elle va, en revanche, mettre en lumière ce qui, dans nos pratiques de développement, relève de la simple exécution reproductible – donc automatisable – et ce qui relève du jugement, du design et de la responsabilité. La méthode BMAD est une tentative de répondre sérieusement à cette question : « comment faire entrer ces nouveaux coéquipiers dans l’atelier sans mettre le feu à la menuiserie ? ».