J'ai trié le paquet pour ne garder que cinq toolbox qui ne se contentent pas de copier la recette d'à côté. Chacune prend un pari opposé sur la même question : jusqu'où doit-on encadrer un agent avant que ça devienne contre-productif.
Le critère de tri
Je n'ai pas retenu les outils les plus installés, j'ai retenu les plus tranchés. Un outil qui dit "faites comme vous voulez, on vous aide un peu" n'apprend rien sur le sujet. Un outil qui prend une position radicale, quitte à fâcher une partie des devs, en apprend beaucoup plus.
1. BMAD-METHOD, la boîte à personas
github.com/bmad-code-org/BMAD-METHOD
BMAD (Breakthrough Method for Agile AI-Driven Development) ne voit pas l'agent comme un exécutant, mais comme une équipe entière déguisée en un seul outil. Analyste, Product Manager, Architecte, Scrum Master, Développeur, QA, UX, chacun est un persona distinct avec son rôle, ses livrables et son tour de parole. Avant la moindre ligne de code, un Product Brief, un PRD complet et un document d'architecture sortent de la chaîne. Le tout s'appuie sur une "intelligence adaptative à l'échelle" qui ajuste la profondeur de planification selon la taille du projet, un correctif de trois lignes ne déclenche pas le même protocole qu'une refonte complète.
Ce qui la différencie vraiment des autres, c'est le "Party Mode" : on peut convoquer plusieurs personas dans la même session pour qu'ils débattent entre eux avant de trancher. Personne d'autre dans ce top 5 ne simule un désaccord interne à l'équipe.
Mon avis : c'est l'outil le plus proche d'un vrai cadrage produit, et c'est justement sa limite. La story ultra détaillée que BMAD produit pour piloter l'agent devient vite un objet à maintenir en soi, un artefact de plus entre l'idée et le code. Si votre organisation a déjà des rituels agiles qui tournent, BMAD peut sembler redondant. Si vous partez de zéro sur la gouvernance produit, c'est probablement le cadre le plus complet du lot.
2. GitHub Spec Kit, le contrat avant le code
Spec Kit part d'un principe simple et un peu provocateur : le code n'est plus la source de vérité, la spec l'est. On écrit d'abord ce que le système doit faire, sans détail d'implémentation, puis on dérive un plan technique, on découpe en tâches, et seulement à ce moment-là l'agent écrit du code. Si les besoins changent, on modifie la spec et on régénère, pas l'inverse.
Ce que Spec Kit apporte de neuf par rapport à BMAD ou AIDD Framework, c'est le côté agnostique et institutionnel : porté par GitHub, pensé pour fonctionner avec n'importe quel agent (Copilot, Claude Code, Gemini CLI), et conçu pour s'étendre à des process métier qui dépassent le pur code.
Mon avis : la promesse ("la spec est le prompt") est séduisante sur le papier, mais elle rejoue un vieux débat du logiciel, celui du cahier des charges figé contre l'itération rapide. Le risque n'est pas théorique : plusieurs voix du milieu, dont Gojko Adzic, pointent le danger de retomber dans une rigidité que l'agilité avait justement cherché à casser. Utile sur des fonctionnalités mission-critical où la traçabilité compte plus que la vitesse. Overkill sur un MVP qu'on va jeter dans trois mois.
3. GSD (Get Stuff Done), le minimalisme du contexte propre
GSD ne cherche ni à simuler une équipe ni à imposer un contrat. Son seul combat, c'est la pollution du contexte. Le constat de départ : demander à un agent de planifier, coder et relire dans la même conversation revient à empiler trois tâches cognitivement différentes dans une seule fenêtre, et les performances s'effondrent à mesure que la session s'étire. GSD découpe donc tout en trois phases étanches, plan, exécution, revue, chacune avec sa propre fenêtre de contexte vierge et son objectif unique. La sortie d'une phase devient l'entrée de la suivante, rien ne traîne d'une phase à l'autre.
Mon avis : c'est la toolbox la plus modeste de ce top 5, et c'est un compliment. Elle ne prétend pas remplacer votre méthodologie, elle corrige un défaut d'ingénierie très concret sur les sessions longues. Le revers de la médaille, c'est qu'elle ne dit rien sur le TDD, la gouvernance produit ou la qualité du code produit, ce n'est pas son sujet. À combiner avec autre chose plutôt qu'à utiliser seule.
4. Claude Code PM, la traçabilité par les tickets
Claude Code PM (ccpm) attaque le problème sous un angle que personne d'autre dans cette liste ne prend : le travail en équipe. Son postulat, un agent qui bosse tout seul dans son coin devient un silo, même au sein d'une équipe humaine. La solution : utiliser les issues GitHub comme base de données du projet. Les PRD deviennent des epics, les epics deviennent des issues, les issues deviennent du code, avec un fil d'audit transparent visible par toute l'équipe et plusieurs instances de Claude qui peuvent travailler en parallèle sur des worktrees Git séparés.
Mon avis : c'est le seul outil du lot pensé d'abord pour le collectif plutôt que pour le duo dev-agent. La proposition "priorisation intelligente via une commande dédiée" est concrètement utile dès qu'on a plus d'un développeur qui délègue à Claude Code en parallèle. Par contre, si vous êtes seul sur votre projet, tout l'appareillage GitHub Issues devient une couche de cérémonie qui ne sert à personne.
5. Ralph Wiggum, le pari inverse de tous les autres
github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum
Et puis il y a Ralph. Nommé d'après le personnage des Simpsons, réputé pour persévérer joyeusement sans jamais mesurer l'ampleur du désastre. La technique, popularisée par Geoffrey Huntley puis officialisée en plugin par Anthropic, tient en une phrase : c'est une boucle bash. Un hook intercepte la sortie de session de Claude, réinjecte le même prompt, et Claude repart sur ce qu'il a laissé, fichiers modifiés et historique git compris, jusqu'à ce qu'une condition d'arrêt soit atteinte.
Là où BMAD, Spec Kit, GSD et ccpm ajoutent tous de la structure en amont, Ralph fait le pari inverse : peu de structure, beaucoup d'itérations, et on laisse converger. La philosophie revendiquée est presque provocatrice, mieux vaut échouer de façon prévisible que réussir de façon imprévisible.
Mon avis : c'est le plus fascinant et le plus dangereux des cinq. Ça marche remarquablement bien sur des tâches mécaniques à critère de succès clair, un refactor massif, une migration de dépendances, une couverture de tests à combler. Ça devient franchement risqué sur tout ce qui demande du jugement métier, où personne ne surveille les 40 itérations qui viennent de se dérouler pendant la nuit. Le garde-fou obligatoire, c'est le nombre maximum d'itérations, sans quoi la note d'API peut piquer.
Les coûts, l'angle mort de presque tout le monde
C'est le point que personne ne met en avant dans sa doc, et pourtant c'est souvent la première question qu'on devrait poser avant d'installer un de ces cinq outils : combien ça va coûter en tokens.
BMAD-METHOD est le pire élève sur ce terrain, malgré sa richesse. Des tests indépendants chiffrent un cycle complet de planification à implémentation à environ 200 dollars, et la cause n'est même pas le raisonnement du modèle, c'est le contexte. Dans un pipeline multi-agents BMAD, la majorité des tokens dépensés, parfois plus de 80 %, servent simplement à réinjecter les mêmes documents de référence, snapshots et définitions de skills à chaque invocation d'agent. Les Web Bundles récents (packager la planification en Gemini Gems ou GPT custom) contournent le problème plutôt que de le résoudre, ils déplacent juste la facture vers un abonnement forfaitaire.
GitHub Spec Kit ne traite quasiment pas le sujet dans sa doc. Sa promesse, c'est la traçabilité et la réduction du nombre de cycles "regénérer depuis zéro", ce qui a un effet indirect positif sur la facture, mais rien n'est pensé explicitement en termes de tokens ou de choix de modèle.
GSD est probablement le plus vertueux des cinq sans jamais le revendiquer comme argument marketing. En isolant chaque phase dans un contexte propre, il évite mécaniquement le scénario le plus cher de tous : une session qui dérive, qu'on corrige à coups d'allers-retours, et qui réinjecte à chaque fois tout l'historique de la conversation. Le bénéfice coût est un effet de bord de la discipline de contexte, pas un objectif affiché.
Claude Code PM a l'effet inverse. Le parallélisme sur worktrees Git, qui fait sa force pour le travail d'équipe, multiplie aussi le nombre d'instances Claude actives en simultané, donc la facture, sans mécanisme de régulation ou de priorisation par coût intégré à l'outil.
Ralph Wiggum est le plus honnête sur le sujet, et le moins équipé pour le régler. Toute sa documentation officielle répète le même avertissement : sans --max-iterations, la boucle peut tranquillement brûler tout votre budget. Les retours de terrain vont de 10 dollars l'heure à plusieurs centaines de dollars sur un run de 50 itérations mal cadré. La seule vraie parade recommandée par la communauté, c'est de brancher un outil de télémétrie token à côté pour couper la boucle avant la catastrophe. Ralph ne réduit pas le coût, il vous laisse juste le voir venir.
Dans les cinq, un seul réflexe existe vraiment ailleurs dans l'écosystème AIDD et vaut la peine d'être noté en creux : la logique de tiers de modèles, un modèle bon marché pour le mécanique, un modèle puissant réservé au raisonnement profond, qu'on retrouve par exemple dans AIDD Framework. Aucun des cinq outils de ce top ne fait ce calcul-là nativement. Tous partent du principe qu'on va lancer le même modèle, souvent le plus cher disponible, du brainstorming jusqu'au dernier commit.
Ultra dépendant de Claude, ou pas du tout
Deuxième angle mort, moins évident que les coûts mais tout aussi structurant : est-ce que l'outil vous enferme chez Anthropic, ou est-ce qu'il vous laisse la porte ouverte.
GSD est le plus ouvert des cinq, et de loin. Il tourne nativement sur une douzaine d'environnements, Claude Code, Codex, Gemini CLI, Cursor, Copilot, Windsurf, OpenCode et d'autres, avec un installeur qui détecte l'environnement et adapte l'arborescence de fichiers en conséquence. Rien dans sa logique de phases n'est spécifique à un modèle en particulier.
Spec Kit est presque aussi agnostique, par construction. Porté par GitHub et pas par Anthropic, il est pensé dès le départ pour fonctionner avec Copilot, Claude Code ou Gemini CLI indifféremment. La spec ne parle à aucun moment le langage d'un agent en particulier.
BMAD-METHOD se situe au milieu. Les personas sont distribués sous forme de fichiers Markdown et YAML, un format que n'importe quel agent capable de lire des instructions peut consommer, et le projet revendique une compatibilité avec Claude Code, Cursor et Codex CLI. Dans les faits, la communauté et la documentation restent très centrées Claude Code, ce qui rend la portabilité plus théorique que pratique pour qui n'a jamais testé ailleurs.
Claude Code PM est nettement plus attaché à son nom qu'il n'y paraît. Toute son orchestration s'appuie sur l'interface de commandes de Claude Code et le répertoire .claude/, ce n'est pas un détail cosmétique, c'est le squelette de l'outil. La partie GitHub Issues est bien agnostique en soi, mais la couche qui pilote les agents ne l'est pas.
Ralph Wiggum a un statut particulier : la technique elle-même, une boucle bash qui réinjecte un prompt, n'appartient à personne et a été reproduite pour Codex ou d'autres CLI par la communauté. Mais le plugin officiel dont on parle ici est publié par Anthropic sur son propre marketplace, pensé et maintenu pour Claude Code en premier. Si vous voulez la version portable, c'est un fork communautaire qu'il faut aller chercher, pas l'implémentation de référence.
Les sept en face à face
AIDD Framework et Superpowers ne sont pas repris dans les portraits ci-dessus puisqu'ils ont déjà eu droit à leur article dédié, mais les exclure du tableau aurait été absurde : ce sont deux références du genre, et elles donnent un point de comparaison direct sur les critères coût et dépendance qu'on vient d'ajouter.
Petite clé de lecture avant le tableau, pour que chaque ligne se juge sur le même critère d'un outil à l'autre :
Pari central : le principe sur lequel l'outil refuse de transiger, ce qui le définit.
Porté par : qui maintient le projet aujourd'hui.
Point fort : le problème qu'il résout mieux que les autres.
Point faible : le scénario où il devient un fardeau plutôt qu'une aide.
Coût token : est-ce que l'outil pense la facture API par conception, ou seulement en subit les conséquences.
Dépendance à Claude : peut-on le faire tourner tel quel avec un autre agent, ou est-il pensé et maintenu spécifiquement pour Claude Code.
Terrain de jeu idéal : le contexte où ça vaut le coup de l'installer.
AIDD Framework | Superpowers | BMAD-METHOD | Spec Kit | GSD | Claude Code PM | Ralph Wiggum | |
|---|---|---|---|---|---|---|---|
Pari central | Marketplace de plugins modulaires, on compose sa stack à la carte | Un seul chemin méthodologique imposé, TDD non négociable | Simuler une équipe agile complète | La spec fait foi, le code en découle | Isoler chaque phase dans un contexte propre | Les issues GitHub comme source de vérité partagée | Peu de cadrage, beaucoup d'itérations |
Porté par | Communauté AI-Driven Dev (France) | Jesse Vincent / Prime Radiant | BMad Code (communauté) | GitHub | Communauté indépendante | Automaze / communauté | Anthropic (plugin officiel) + variantes communautaires |
Point fort | Granularité totale, on installe uniquement les skills utiles | Discipline TDD stricte, red-green-refactor appliqué mécaniquement | Couverture produit de bout en bout, de l'idée au code | Traçabilité forte, conçu multi-agents dès le départ | Corrige concrètement la dégradation de contexte sur les longues sessions | Collaboration à plusieurs devs et plusieurs agents sur le même repo | Efficacité brute sur tâches mécaniques bien cadrées |
Point faible | Portabilité multi-agents limitée à des archives à installer à la main | Aucune marge de manœuvre, le projet refuse même les contributions de nouvelles skills | Story ultra détaillée qui devient un artefact à maintenir en soi | Peut rejouer la rigidité d'un cahier des charges classique | Ne dit rien sur la qualité du code ni la gouvernance produit | Toute la couche GitHub Issues devient de la cérémonie inutile en solo | Dérive non supervisée si le critère d'arrêt est mal défini |
Coût token | Bon : priorité CLI > MCP et tiers de modèles (T1/T2/T3) pensés dès la conception | Non traité dans la doc officielle, aucun tiering ni optimisation | Faible : ~200 $/cycle en pratique, surtout à cause de la réinjection de contexte | Non traité explicitement, seulement un effet indirect via moins de régénérations | Bon : effet de bord direct de l'isolation par phase | Faible : le parallélisme multiplie le nombre d'instances actives, donc la facture | Nul en soi, seulement un garde-fou externe ( |
Dépendance à Claude | Moyenne : natif Claude Code, portable ailleurs via archives à installer manuellement (Cursor, Copilot, Codex, OpenCode) | Faible : 9 harnais supportés nativement, chacun avec sa commande d'installation dédiée | Moyenne : fichiers Markdown/YAML portables, mais écosystème et doc très centrés Claude Code | Faible : conçu et maintenu par GitHub pour fonctionner indifféremment avec plusieurs agents | Très faible : une douzaine de runtimes supportés nativement | Forte : l'orchestration repose sur l'interface de commandes et le répertoire | Forte pour le plugin officiel (marketplace Anthropic) ; faible pour la technique elle-même, reprise par la communauté sur d'autres CLI |
Terrain de jeu idéal | Équipe qui veut composer sa propre stack pièce par pièce | Équipe qui veut une discipline TDD imposée sans négociation possible | Nouveau produit, gouvernance à construire | Fonctionnalités mission-critical | Sessions longues sur tâches complexes | Équipe de plusieurs devs sur le même repo | Refactors et migrations à grande échelle |
Alors, on prend quoi
Aucune de ces sept toolbox n'est faite pour vivre seule dans votre .claude. GSD corrige un problème d'ingénierie sur lequel presque personne d'autre ne dit rien, on peut l'empiler avec n'importe quel autre sans conflit. Ralph et BMAD (ou Ralph et Superpowers, même combat) sont à l'opposé l'un de l'autre sur le curseur structure contre autonomie, inutile de les faire cohabiter sur la même tâche. Spec Kit et ccpm se complètent plutôt bien si votre organisation a déjà basculé sur du spec-driven et veut en plus tracer le travail sur GitHub Issues. AIDD Framework, lui, se marie facilement avec les autres justement parce qu'il est pensé comme un marketplace de briques indépendantes plutôt que comme un bloc unique.
Le vrai enseignement de ce tour d'horizon, ce n'est pas "lequel est le meilleur", c'est que la question posée par chaque projet en dit long sur le problème qu'il a vécu en premier. Repérez celui qui ressemble le plus à votre douleur du moment, pas celui qui a le plus d'étoiles GitHub.
Et gardez un œil sur la facture, quel que soit votre choix. Aucun de ces cinq outils ne va le faire à votre place.