GSD vs BMAD : deux façons de faire tourner Claude Code sur un vrai projet

Je fais tourner Claude Code sur Odisei Play, une app React Native en production, depuis quelques mois. Mon workflow par défaut, c'est GSD (Get Shit Done). La semaine dernière, j'ai passé quelques heures à lire la documentation de la méthode BMAD pour comprendre ce que j'avais manqué, le cas échéant.

Voilà ce que j'ai trouvé.

Le problème que les deux méthodes résolvent

Quand tu donnes une longue tâche à Claude Code dans une session fraîche, il démarre bien. Au troisième ou quatrième fichier, il oublie les contraintes que tu avais posées plus tôt. Les patterns sur lesquels vous vous étiez alignés sautent. L'agent prend une décision qui contredit quelque chose qu'il a dit 40 messages plus tôt.

Le context rot est réel, et GSD comme BMAD y répondent structurellement. Ils l'abordent juste différemment.

GSD : des petits plans, des commits atomiques

GSD veut dire « Get Shit Done ». L'idée centrale : arrêter de traiter un fil de chat comme ton build system.

Le workflow :

1. Discuss - verrouiller les décisions produit avant de générer le moindre plan. Qu'est-ce qu'on build exactement ? Quelles contraintes ne bougent pas ? Ça se passe en conversation pure.
2. Plan - transformer les décisions en une spec de tâche petite et concrète. Une seule chose, clairement scopée.
3. Execute - Claude Code tourne la tâche dans un contexte frais contre cette spec.
4. Commit - un commit git atomique par tâche, pour pouvoir bisect quand quelque chose casse.

Le contexte frais par tâche, c'est la clé. Tu limites volontairement la dose d'historique que l'agent transporte, ce qui limite la dérive. Le fichier de spec voyage avec la session à la place.

Il y a aussi une gate de validation, l'idée étant qu'il te faut une boucle de feedback de test qui fonctionne avant que l'agent écrive du code. Sur un projet React Native, ça veut dire garder la spec assez serrée pour que je puisse vérifier l'output vite. Si quelque chose casse, je sais exactement quelle tâche a introduit le problème.

Je faisais une version de ça avant d'avoir un nom pour le nommer. Ce que GSD m'a donné, c'est la structure et le vocabulaire pour une pratique que je suivais déjà intuitivement.

Ce que ça donne en pratique

Sur Odisei Play, un cycle GSD typique pour une feature :

• Drafter un court fichier de tâche : deux ou trois paragraphes, les acceptance criteria, ce qu'il ne faut pas toucher
• Ouvrir une session Claude Code fraîche avec ce fichier comme contexte
• Claude tourne l'implémentation, je review le diff, on commit
• Feature suivante, nouvelle session

Overhead : 10-15 minutes d'écriture de spec par tâche. Ça aurait été 10-15 minutes de back-and-forth dans une session longue de toute façon, sauf que maintenant j'ai un document que je peux réutiliser.

La limite est évidente : ça scale avec moi. C'est moi qui écris les specs, qui review l'output, qui prends les décisions d'architecture. Pour un projet solo, ça passe. Pour quelque chose de plus gros, l'humain unique dans la loop devient le bottleneck.

BMAD : les agents avant le code

BMAD veut dire « Breakthrough Method for Agile AI-Driven Development ». Un framework plus lourd. L'idée, c'est de faire tourner des agents spécialisés (Analyst, PM, Architect, Dev, QA) qui se passent le relai à travers des documents structurés avant que la moindre implémentation commence.

Les phases :

1. Analyst - prend ton idée brute, fait de la recherche, produit une brief
2. PM - transforme la brief en PRD avec des stories et des acceptance criteria
3. Architect - design l'approche technique, produit des docs d'architecture
4. Dev - implémente story par story, scoppé contre ces docs
5. QA - valide contre les requirements d'origine

Chaque agent opère avec un system prompt spécifique qui limite ce qu'il voit et ce qu'il a le droit de faire. Un agent Scrum Master gère les fichiers de stories passés entre les agents. Ils communiquent à travers des fichiers structurés, pas à travers un context window partagé.

Le coût de setup est réel. Tu configures plusieurs agents, tu écris une PRD avant de toucher au code, et tu comptes sur les handoffs inter-agents pour fonctionner correctement. Pour un nouveau projet avec des requirements flous, ça paie. Le travail de planning qui se ferait autrefois de façon informelle, ou pas du tout, se fait explicitement avant que l'agent écrive quoi que ce soit.

Comparaison directe

	GSD	BMAD
Setup	Faible, un fichier de spec par tâche	Élevé, config multi-agent, PRD, docs d'architecture
Planning	Phase discuss informelle	Agents structurés (Analyst → PM → Architect)
Context	Session fraîche par tâche	Docs structurés passés entre les agents
Validation	Review manuelle + gate de test	Agent QA contre les requirements de la PRD
Meilleur fit	Solo dev, maintenance en production	Projets en team, builds greenfield
Overhead	10-15 min par tâche	Des heures upfront, puis coût par story plus bas

La différence clé n'est pas la complexité du workflow, c'est quand tu fais le gros de la réflexion.

GSD pousse les décisions dans de courtes sessions discuss avant chaque tâche. Tu réfléchis tâche par tâche. BMAD front-load tout : au moment où l'agent Dev touche au code, les décisions d'architecture sont déjà dans un document.

Aucune des deux approches ne te laisse skipper la réflexion. Elles la schedule juste différemment.

Laquelle utiliser

Utilise GSD si :

• Tu taffes seul ou en toute petite team
• Tu maintiens ou étends une codebase existante
• Tu veux ship de façon incrémentale sans planning lourd upfront
• Le scope de la feature tient dans un court fichier de spec

Considère BMAD si :

• Tu lances un nouveau projet et les requirements sont vraiment flous
• Plusieurs personnes taffent avec des agents IA sur la même codebase
• Tu as eu des problèmes d'agents qui prennent des décisions d'architecture contradictoires
• Tu veux que la phase de planning soit auditable et reproductible

Ce que je fais :

Je reste sur GSD pour Odisei Play. La codebase est établie, je connais l'architecture, et l'overhead de planning de BMAD me ralentirait sans gros payoff. Un fichier de tâche par feature, des sessions fraîches, des commits propres.

Mais si je démarrais un nouveau produit de zéro, pas de code existant, vraie ambiguïté sur les requirements, je considérerais sérieusement faire tourner d'abord une phase de planning style BMAD, même avec un setup d'agents simplifié. Les seules phases Analyst et PM me forceraient à écrire des décisions que je prendrais autrefois de façon informelle et oublierais.

Le vrai point

Les deux méthodes fontent la même chose : rendre les décisions implicites explicites. Tu externalises ce qui vivrait sinon uniquement dans ta tête, ou dans le context window de l'agent où ça va pourrir.

L'outil, c'est Claude Code. Les méthodes sont des façons différentes de structurer ce que tu lui files.

Choisis celle qui fit le projet que tu es réellement en train de builder là tout de suite.