Depuis quelque temps, on voit circuler la méthode BMAD. Présentée comme une manière plus structurée d’utiliser l’IA dans le travail produit.

• Business.
• Model.
• Architecture.
• Delivery.

Sur le papier, rien de révolutionnaire. Et c’est précisément ce qui la rend intéressante. BMAD ne promet pas d’aller plus vite. Elle impose surtout de ralentir avant de produire. De poser le contexte. De clarifier le besoin. De réfléchir aux usages avant d’écrire une ligne. Autrement dit : de faire correctement un travail qui, pendant longtemps, allait de soi.

🔍 Rien de nouveau sous le capot

Si on enlève l’IA de l’équation, BMAD ressemble à ce que beaucoup d’équipes ont déjà pratiqué :

• comprendre pourquoi on construit quelque chose,
• formuler un problème avant de chercher une solution,
• faire des choix d’architecture conscients,
• livrer quelque chose qui a un usage réel.

Ces étapes n’ont rien d’innovant. Elles ont simplement cessé d’être garanties par le cadre de travail. Ce travail-là n’a jamais été automatique. Il était simplement plus souvent pris en charge ailleurs.

• Tickets flous.
• Décisions non prises.
• Responsabilités diluées.
• Urgence permanente.

BMAD ne crée pas ces questions. Elle les réintroduit là où elles ont parfois disparu. Beaucoup d’organisations ont aujourd’hui des workflows clairs. Des process documentés. Des rôles bien définis. Le problème n’est pas leur existence. C’est ce qu’ils laissent à gérer quand tout ne se passe pas comme prévu.

🔁 Le point de bascule

Et c’est ici que le regard change. Si une méthode devient nécessaire pour rappeler qu’un produit a un usage, le problème n’est pas la méthode. Et je ne m’en exclue pas. BMAD m’aide moi aussi à mieux travailler. Pas parce qu’elle est brillante, mais parce qu’elle m’oblige à poser des questions que le cadre ne garantit plus. Ce que BMAD formalise, ce ne sont pas des bonnes pratiques “IA”. Ce sont des responsabilités classiques du travail produit. Lorsqu’elles ne sont plus prises en charge collectivement, elles finissent par être assumées individuellement.

👤 Travailler seul, avec une équipe… fictive

Là où je trouve BMAD particulièrement intéressante, c’est qu’elle donne à un développeur seul l’opportunité de travailler comme s’il avait une équipe complète. Pas une vraie équipe, évidemment. Mais une succession de rôles, de points de vue, de contre-questions. Avec une contrainte forte : ne pouvoir faire confiance à personne... pour une vingtaine d’euros par mois. BMAD n’exonère jamais le développeur de décider. Elle l’oblige même à le faire.

⚖️ Une opportunité… et un déplacement

BMAD peut clairement devenir un levier pour travailler en solo. Notamment pour des freelances capables de cadrer, structurer, décider et livrer proprement. Mais plus cette structuration devient individuelle, plus la question collective se pose.

❓ Quand un travail n’a plus d’endroit clair où vivre

Ce travail-là, comprendre, décider et transmettre, ne peut pas reposer sur des individus isolés. Tant qu’il n’est pas pris en charge collectivement, les méthodes continueront de pallier ce qui manque. Et ce ne sera jamais un problème de méthode.