
Méthode BMAD : Comment j'ai créé un SaaS en 48h avec l'IA
Méthode BMAD : Comment j'ai créé un SaaS en 48h avec l'IA
Transformez le vibe coding chaotique en développement structuré. Guide complet avec mon retour d'expérience et workflow détaillé.
Comment j'ai créé un SaaS en 48 heures avec la méthode BMAD
La révolution du développement assisté par IA qui transforme le "vibe coding" chaotique en processus structuré et scalable
Il y a un peu plus d'un an, j'avais lancé un projet ambitieux : un SaaS qui automatiserait entièrement la stratégie SEO et la création d'articles de blog grâce à l'intelligence artificielle. Le concept était prometteur, le potentiel de marché évident. Pourtant, j'ai fini par mettre ce projet de côté. Non pas par manque de conviction, mais parce que d'autres priorités s'étaient imposées dans mon parcours entrepreneurial.
Quand j'ai décidé de reprendre ce projet récemment, je me suis retrouvé face à une réalité déconcertante : le code que j'avais écrit était devenu obsolète. Les modèles de langage avaient tellement évolué que mes approches d'il y a un an semblaient presque archaïques. Mon architecture était fragmentée entre deux repositories distincts — l'un en TypeScript pour le frontend, l'autre en Python pour le backend — créant une complexité de gestion qui ralentissait chaque itération.
C'est dans ce contexte que j'ai découvert la méthode BMAD. Et ce qui s'est passé ensuite a fondamentalement changé ma vision du développement logiciel assisté par IA.
En exactement 48 heures, j'avais un MVP fonctionnel. Un produit propre, structuré, documenté, pensé pour la production. Un produit qui aurait normalement nécessité des semaines de développement.
Cet article n'est pas une simple présentation de méthodologie. C'est le récit détaillé d'une transformation, accompagné de tout ce que vous devez savoir pour reproduire cette expérience.
Pourquoi le "vibe coding" ne suffit plus
Avant de plonger dans la méthode BMAD, il est essentiel de comprendre le problème qu'elle résout.
Le terme "vibe coding" a été popularisé par Andrej Karpathy, co-fondateur d'OpenAI, début 2025. Il décrit cette approche intuitive où le développeur interagit de manière informelle avec un assistant IA, improvisant ses prompts au fil des besoins immédiats. Cette méthode peut sembler séduisante : on "vibre" avec l'IA, on la laisse coder, on ajuste au feeling.
Le problème ? Cette approche s'effondre dès que le projet gagne en complexité.
Les trois failles fatales du vibe coding
La perte de contexte représente le premier écueil majeur. Les conversations avec les LLM ont une mémoire limitée. Plus votre projet avance, plus vous devez ré-expliquer le contexte, les décisions architecturales précédentes, les contraintes techniques. C'est comme travailler avec un développeur amnésique qui oublie tout ce que vous lui avez dit la veille.
L'incohérence architecturale constitue le deuxième piège. Sans vision d'ensemble structurée, chaque session de développement peut partir dans une direction différente. Les patterns de code deviennent inconsistants. Les conventions de nommage dérivent. L'architecture elle-même se fragmente au fil des interactions.
L'absence de scalabilité ferme cette trilogie de problèmes. Le vibe coding fonctionne pour des prototypes rapides ou des outils personnels. Mais dès qu'il faut collaborer, maintenir le code sur la durée, ou faire évoluer le produit, l'absence de structure se paie cash.
J'ai vécu ces trois problèmes avec mon projet SEO initial. Mon code était un patchwork de décisions prises au coup par coup, impossible à maintenir efficacement.
La méthode BMAD : une révolution structurée
BMAD signifie "Breakthrough Method for Agile AI-Driven Development" — Méthode révolutionnaire pour le développement agile piloté par l'IA. Ce n'est pas un simple framework technique ou un nouveau plugin. C'est une philosophie complète qui réorganise la collaboration humain-IA autour de principes agiles éprouvés.
Le concept fondamental
L'idée centrale de BMAD est de transformer l'IA d'un assistant générique en une équipe virtuelle d'agents spécialisés. Chaque agent a un rôle précis, des responsabilités définies, et des outputs attendus. Ces agents collaborent entre eux selon un workflow structuré, exactement comme le ferait une vraie équipe de développement.
Là où le vibe coding vous fait discuter avec un assistant unique qui jongle maladroitement entre analyse, architecture, développement et tests, BMAD vous donne accès à des personas distincts qui excellent chacun dans leur domaine.
Les deux innovations clés
La force de BMAD repose sur deux piliers complémentaires.
L'Agentic Planning représente la première innovation. Des agents dédiés — Analyst, Product Manager et Architect — collaborent avec vous pour créer des documents de planification détaillés et cohérents. Cette phase produit un PRD (Product Requirements Document) complet et une documentation d'architecture exhaustive avant qu'une seule ligne de code ne soit écrite.
Le Context-Engineered Development constitue la seconde innovation. L'agent Scrum Master transforme ensuite ces plans détaillés en "stories" de développement hyper-détaillées. Chaque story contient tout ce dont l'agent Developer a besoin : le contexte complet, les détails d'implémentation, les guidelines architecturales, et les critères de validation.
Cette approche élimine les deux plus gros problèmes du développement assisté par IA : l'incohérence de planification et la perte de contexte.
L'écosystème des agents BMAD
Comprendre les rôles de chaque agent est crucial pour maîtriser la méthode.
L'Analyst (Mary)
L'Analyst est souvent le premier agent que vous consultez. Son rôle est d'explorer l'espace des idées, de faire émerger les contraintes, et de produire un brief projet initial.
Concrètement, cet agent vous pose les bonnes questions : Quel est le problème que vous résolvez ? Qui sont vos utilisateurs cibles ? Quelles sont les contraintes techniques et business ? Quels risques faut-il anticiper ?
Le résultat de cette phase est un document de brief structuré qui capture la vision du projet de manière claire et actionnable.
Le Product Manager (PM)
Le PM prend le relais après le brief. Son expertise consiste à transformer cette vision initiale en spécifications produit détaillées.
Cet agent produit le PRD — Product Requirements Document. Ce document contient les exigences fonctionnelles (FRs), les exigences non-fonctionnelles (NFRs), les critères d'acceptation, les priorités, et la roadmap du produit.
Le PRD devient la source de vérité pour tout le reste du projet. Chaque décision technique future sera alignée sur ce document.
L'Architect
L'Architect est responsable de la vision technique. À partir du PRD, cet agent conçoit l'architecture complète du système.
Son output inclut la cartographie des composants, les flux de données, les choix technologiques, la stratégie d'intégration, et les patterns à utiliser. Ce document d'architecture devient le blueprint technique que tous les autres agents suivront.
Le Product Owner (PO)
Le PO joue un rôle d'alignement et de cohérence. Il vérifie que le PRD et l'architecture sont synchronisés, résout les conflits potentiels, et "sharde" les spécifications en unités plus petites et gérables.
Ce rôle est particulièrement important pour les projets d'envergure où le PRD peut devenir volumineux.
Le Scrum Master (SM)
Le Scrum Master est le pivot entre la planification et l'exécution. Son rôle est de transformer les épiques en stories de développement précises.
Chaque story créée par le SM est autonome : elle contient tout le contexte nécessaire, les critères d'acceptation, les dépendances, et les tests attendus. Quand un agent Developer ouvre une story, il a absolument tout ce qu'il faut pour implémenter la fonctionnalité sans ambiguïté.
Le Developer (Dev)
L'agent Developer implémente les stories. Armé du contexte complet fourni par le SM, il écrit le code et les tests associés.
L'avantage de cette approche : le Dev ne part jamais d'une page blanche. Il sait exactement ce qu'il doit construire, comment le construire, et pourquoi. Les décisions architecturales ont été prises en amont, documentées, et lui sont transmises.
Le QA (Quality Assurance)
L'agent QA intervient après le développement pour valider la qualité. Il review les stories, conçoit des cas de test supplémentaires, et évalue les exigences non-fonctionnelles.
Si le QA détecte des problèmes, la story retourne au Dev pour corrections. Ce cycle continue jusqu'à validation complète.
L'Orchestrator
L'Orchestrator est le chef d'orchestre qui coordonne les interactions entre tous les agents. Il gère les dépendances entre tâches, surveille la progression, et prévient les goulots d'étranglement.
C'est l'Orchestrator qui vous guide à travers les workflows et vous indique quel agent appeler à quel moment.
Mon parcours : de l'idée au MVP en 48 heures
Passons maintenant au récit concret de mon expérience avec la méthode BMAD.
Jour 0 : L'initialisation
J'ai commencé par créer un nouveau repository vierge. Mon ancien code était trop désordonné pour être récupéré — mieux valait repartir de zéro avec une base saine.
L'installation de BMAD s'est faite via npm :
npx bmad-method install
Cette commande installe les fichiers de configuration des agents, les workflows YAML, et la structure de dossiers nécessaire. La méthode crée automatiquement un dossier .bmad contenant toutes les définitions d'agents et les templates.
Le brainstorming avec l'Analyst
Ma première action a été d'invoquer l'agent Analyst. En tapant *analyst dans mon interface, j'ai initié une conversation structurée.
L'Analyst m'a guidé à travers une série de questions profondes sur mon projet :
- Quel problème précis mon SaaS résout-il ?
- Qui sont mes utilisateurs cibles et quels sont leurs pain points ?
- Quelles sont mes contraintes techniques et budgétaires ?
- Quels compétiteurs existent sur le marché ?
- Quelle est ma proposition de valeur unique ?
Cette conversation n'était pas superficielle. L'Analyst poussait chaque réponse, demandait des clarifications, suggérait des angles que je n'avais pas considérés.
Le résultat : un brief projet complet de plusieurs pages, structuré et actionnable.
L'analyse concurrentielle
Avant de passer au PRD, j'ai approfondi l'analyse de marché. L'agent m'a aidé à cartographier les solutions existantes, identifier leurs forces et faiblesses, et préciser mon positionnement.
Cette étape peut sembler superflue pour un développeur pressé, mais elle s'est révélée précieuse. Elle a clarifié des décisions produit qui auraient autrement été prises à l'aveugle.
La création du PRD
Le PM a ensuite pris le relais pour transformer le brief en PRD complet.
Ce document détaillait :
- Les user personas avec leurs besoins spécifiques
- Les fonctionnalités requises, classées par priorité
- Les exigences non-fonctionnelles (performance, sécurité, scalabilité)
- Les critères d'acceptation pour chaque fonctionnalité
- La roadmap en phases
Le PRD faisait une vingtaine de pages — suffisamment détaillé pour guider le développement, mais pas au point de devenir une usine à gaz.
L'architecture technique
L'Architect a ensuite conçu l'architecture du système à partir du PRD.
Pour mon SaaS SEO, l'architecture incluait :
- Un monorepo unifié (fini les deux repos séparés !)
- Un backend API en Python avec FastAPI
- Un frontend React avec TypeScript
- Une base de données PostgreSQL
- Des services d'intégration pour les APIs SEO externes
- Une architecture modulaire permettant l'évolution future
Chaque choix technique était justifié et documenté. Plus de décisions prises au feeling.
Le découpage en épiques et stories
Le Product Owner a aligné les documents, puis le Scrum Master a découpé le travail en épiques et stories.
Mon MVP a été structuré en 5 épiques :
- Infrastructure de base : setup du projet, configuration, déploiement
- Authentification : inscription, connexion, gestion des utilisateurs
- Analyse SEO : crawling, analyse de mots-clés, audit technique
- Génération de contenu : création d'articles optimisés par IA
- Dashboard : visualisation des données et rapports
Chaque épique contenait entre 3 et 8 stories, soit une trentaine de stories au total.
Le développement
C'est là que la magie opère vraiment.
J'ai pris chaque story dans l'ordre de priorité défini. Pour chacune, le workflow était le même :
- Ouvrir la story file
- Lire le contexte complet
- Invoquer l'agent Developer
- Le Dev implémente le code selon les spécifications
- L'agent QA review et valide
- Passer à la story suivante
La fluidité était remarquable. Parce que chaque story contenait tout le contexte nécessaire, il n'y avait pas de perte de temps à ré-expliquer le projet. Le Dev savait exactement ce qu'il devait faire.
Les bugs ? Quasiment inexistants. J'ai dû corriger manuellement peut-être 2-3 petits détails sur l'ensemble du projet. Le reste fonctionnait du premier coup.
Les clés du succès : ce qui rend BMAD si efficace
Après cette expérience, j'ai identifié les facteurs qui font de BMAD une méthode si puissante.
L'élimination de la perte de contexte
C'est le game-changer absolu. Dans le vibe coding, vous perdez constamment du contexte entre les sessions. Avec BMAD, tout est documenté. Le contexte est embarqué dans chaque story file.
Quand l'agent Developer ouvre une story, il n'a pas besoin de "se souvenir" du projet. Tout est là, noir sur blanc.
La spécialisation des agents
Un assistant générique fait tout moyennement. Des agents spécialisés excellent dans leur domaine.
L'Analyst pose de meilleures questions qu'un assistant générique. L'Architect prend de meilleures décisions techniques. Le QA fait des reviews plus rigoureuses.
La structure sans la rigidité
BMAD impose une structure, mais reste flexible. Vous n'êtes pas enfermé dans un carcan. La méthode s'adapte à votre projet, pas l'inverse.
Pour un prototype rapide, vous pouvez accélérer certaines phases. Pour un projet enterprise, vous pouvez approfondir chaque étape.
La traçabilité complète
Chaque décision est documentée. Chaque changement est versionné. Vous avez une trace complète du "pourquoi" derrière chaque ligne de code.
C'est inestimable pour la maintenance future ou l'onboarding de nouveaux contributeurs.
Guide pratique : implémenter BMAD sur votre projet
Vous êtes convaincu et voulez essayer ? Voici comment procéder concrètement.
Prérequis
- Node.js v20 ou supérieur
- Un IDE compatible ou un CLI tel que Claude Code ou Gemini CLI. Perso j'ai utilisé Opencode c'est très puissant
- Accès à un LLM puissant (Claude, GPT-4, etc.)
- Git pour le versioning
Installation
Créez un nouveau dossier pour votre projet et initialisez BMAD :
mkdir mon-projet
cd mon-projet
git init
npx bmad-method install
Cette commande installe tous les fichiers nécessaires dans votre projet.
Configuration
Explorez le dossier .bmad créé. Vous y trouverez :
- Les définitions des agents (fichiers .md)
- Les workflows (fichiers YAML)
- Les templates de documents
Vous pouvez personnaliser ces fichiers selon vos besoins.
Démarrage du workflow
Lancez votre premier agent :
*analyst
Ou utilisez l'Orchestrator pour être guidé :
#bmad-orchestrator
L'Orchestrator vous expliquera les commandes disponibles et vous guidera à travers le processus.
Les phases du workflow standard
Phase 1 : Agentic Planning (web UI recommandé)
*analyst— Créer le brief projet*pm— Transformer le brief en PRD*architect— Concevoir l'architecture technique
Phase 2 : Context-Engineered Development (IDE)
*po— Aligner et sharder les documents*sm— Créer les stories de développement*dev— Implémenter chaque story*qa— Valider la qualité
Bonnes pratiques
Committez régulièrement. Chaque artefact produit (brief, PRD, architecture, stories) devrait être versionné. Cela crée une trace auditable.
Ne sautez pas les étapes. La tentation de passer directement au code est forte. Résistez. La phase de planification fait gagner un temps considérable en aval.
Itérez sur les documents. Votre PRD initial n'est pas gravé dans le marbre. Affinez-le au fur et à mesure que votre compréhension du projet s'approfondit.
Utilisez les commandes d'aide. Tapez *help à tout moment pour voir les commandes disponibles.
BMAD vs vibe coding : la comparaison chiffrée
Pour illustrer concrètement la différence, voici une comparaison basée sur mon expérience.
Temps de développement
Vibe coding (mon premier projet SEO) : environ 3 semaines de travail intermittent, sans compter les sessions de debugging et de refactoring.
BMAD (le nouveau projet) : 48 heures concentrées, du brief au MVP fonctionnel.
Qualité du code
Vibe coding : code fonctionnel mais inconsistant. Patterns variables selon les sessions. Documentation quasi inexistante.
BMAD : code structuré, patterns cohérents, documentation intégrée. Prêt pour la production.
Maintenabilité
Vibe coding : reprendre le projet après quelques mois nécessite de "redécouvrir" l'architecture et les décisions passées.
BMAD : tout est documenté. N'importe qui peut reprendre le projet et comprendre le contexte.
Bugs rencontrés
Vibe coding : dizaines de bugs à corriger, certains subtils et difficiles à diagnostiquer.
BMAD : 2-3 ajustements mineurs sur l'ensemble du projet.
Les limites de BMAD : une analyse honnête
Aucune méthode n'est parfaite. BMAD a ses propres contraintes qu'il faut connaître.
La courbe d'apprentissage
BMAD nécessite de comprendre les agents, les workflows, et la philosophie sous-jacente. Pour un développeur habitué au vibe coding, la transition demande un effort initial.
Comptez quelques heures pour vous familiariser avec l'écosystème avant d'être productif.
L'overhead pour les petits projets
Pour un script de 50 lignes ou un prototype jetable, BMAD est overkill. La méthode brille sur les projets d'une certaine envergure où la structure apporte de la valeur.
La dépendance aux LLM puissants
BMAD exploite au maximum les capacités des meilleurs modèles de langage. Avec un LLM moins performant, les résultats peuvent être décevants.
Claude Opus 4.5 ou équivalent est recommandé pour une expérience optimale.
Au-delà du code : les cas d'usage étendus
BMAD n'est pas limité au développement logiciel. La méthode s'applique à tout domaine nécessitant une collaboration structurée avec l'IA.
Écriture créative
Des agents Writer's Room, Plot Generator et Editing Assistant peuvent orchestrer la création d'un roman ou d'un scénario.
Stratégie business
Des agents Market Analyst, SWOT Planner et Growth Strategist peuvent produire des analyses stratégiques complètes.
Éducation
Des agents Curriculum Designer et Tutoring Assistant peuvent créer des programmes de formation personnalisés.
Santé et bien-être
Des agents Wellness Planner et Habit Tracker peuvent accompagner des programmes de développement personnel.
Ces "Expansion Packs" transforment BMAD en framework universel pour toute collaboration humain-IA complexe.
L'avenir du développement assisté par IA
BMAD représente une évolution fondamentale dans notre façon de travailler avec l'IA. Ce n'est pas une amélioration incrémentale — c'est un changement de paradigme.
Du copilote à l'équipe virtuelle
Les premiers outils d'IA pour le code étaient des "copilotes" : des assistants passifs qui attendaient nos instructions. BMAD va plus loin en créant une équipe virtuelle proactive, où chaque agent a des responsabilités claires et des outputs définis.
Le Spec-Driven Development
BMAD s'inscrit dans un mouvement plus large vers le "Spec-Driven Development" — une approche où la spécification, et non le code, devient l'artefact principal. Le code devient l'implémentation concrète d'une spec rigoureusement définie.
La professionnalisation du vibe coding
Pour ceux d'entre nous qui avons adopté tôt le développement assisté par IA, BMAD offre un chemin vers la professionnalisation. On peut garder la vitesse et la créativité du vibe coding tout en ajoutant la rigueur et la structure nécessaires aux projets sérieux.
Conclusion : ma nouvelle réalité de développeur
Quarante-huit heures. C'est le temps qu'il m'a fallu pour passer d'une idée abandonnée à un MVP fonctionnel.
Ce n'est pas parce que les LLM sont devenus magiquement plus intelligents (même si Claude Opus 4.5 est effectivement impressionnant). C'est parce que BMAD m'a donné la structure pour exploiter cette intelligence de manière optimale.
Mon SaaS SEO, GetBlog, est maintenant en développement actif. Le code est propre, documenté, scalable. Je peux y ajouter des fonctionnalités en suivant le même workflow. Je peux éventuellement onboarder des contributeurs sans passer des heures à expliquer l'architecture.
Si vous êtes développeur et que vous n'avez pas encore exploré les méthodologies agentiques comme BMAD, vous vous privez d'un multiplicateur de productivité considérable.
Le futur du développement n'est pas l'IA qui code à notre place. C'est l'humain qui orchestre une équipe d'agents spécialisés, chacun excellent dans son domaine, tous alignés vers un objectif commun.
BMAD rend ce futur accessible aujourd'hui.
Ressources pour aller plus loin
- Repository officiel BMAD : BMAD-METHOD
Automatisez votre SEO avec Getblog
La solution IA développée par Kairia pour produire du contenu SEO en continu, sans effort technique.
Découvrir GetblogArticles liés

Méthode BMAD : structurer des agents IA pour développer des SaaS plus vite, proprement et à grande échelle
Découvrez la méthode BMAD pour organiser des agents IA comme une vraie équipe de développement : builder, manager, architect et developer. Une approche structurée pour industrialiser le vibe-coding et créer des SaaS scalables.
Lire l'article →
Vibecode : créer une vraie application mobile depuis son iPhone, en quelques minutes
Vibecode permet de développer des applications mobiles complètes directement depuis un iPhone grâce à l’IA. Analyse experte, usages, limites et avis professionnel.
Lire l'article →
Pourquoi 80 % des entreprises se trompent sur le ROI de l’IA
La plupart des dirigeants évaluent mal le retour sur investissement de l’IA. Voici les 5 erreurs les plus fréquentes et comment les éviter.
Lire l'article →