Un benchmark pratique de Spec Kit, OpenSpec, Superpowers, BMAD Method, GBrain, des skills de Matt Pocock, et de quelques challengers.

---

Quelque part entre « l’IA va remplacer les développeurs » et « l’IA écrit n’importe quoi », une histoire plus discrète s’est jouée : les développeurs ont arrêté de débattre des modèles pour débattre du processus. En 2025, la question était « quel agent utiliser ». En 2026, c’est « quel framework mettre autour de cet agent ».

J’ai fait tourner ces frameworks sur du vrai travail, et cet article est la carte que j’aurais aimé avoir : pourquoi ces frameworks existent, ce qu’ils sont réellement, et comment installer chacun d’eux, avec un benchmark honnête à la fin.

Partie 1 : le pourquoi

La gueule de bois du vibe coding

Les agents de code comme Claude Code, GitHub Copilot, Cursor ou Codex écrivent objectivement bien. Le problème n’a jamais été la vitesse de frappe. Le constat de GitHub au lancement de Spec Kit était sans détour : nous traitons les agents de code comme des moteurs de recherche, alors qu’il faudrait les traiter comme des binômes très littéraux, excellents en reconnaissance de motifs mais qui exigent des instructions sans ambiguïté.

Quiconque a utilisé un agent sérieusement a vécu ces modes d’échec :

• Le désalignement. Vous demandez un petit correctif, vous recevez un refactoring, trois nouveaux fichiers et des tests qui passent parce qu’ils ne testent rien. L’agent n’a jamais demandé ce que vous vouliez vraiment construire.
• L’amnésie. Chaque session repart de zéro. Les décisions du mardi s’évaporent le jeudi. Les exigences vivent dans un chat éphémère et meurent avec l’onglet.
• La dégradation du contexte. La qualité du modèle baisse à mesure que la fenêtre de contexte se remplit. Matt Pocock, reprenant l’image de Dex Horthy, parle de smart zone et de dumb zone : au-delà d’environ 100k tokens de contexte, la qualité du raisonnement chute de façon mesurable. Les fenêtres de contexte plus grandes livrent surtout une dumb zone plus grande.
• L’absence de discipline. Livré à lui-même, un agent code avant de tester, rustine les symptômes au lieu des causes, et recopie les pires patterns déjà présents dans votre repo, parce que ce sont ceux qu’il voit en premier.

Rien de tout cela n’est un problème de modèle. Ce sont des problèmes de processus. Et un problème de processus se résout par du processus : c’est exactement ce que vendent tous les frameworks de cet article.

L’argument économique

Il y a une deuxième raison, moins romantique, à leur décollage : le coût de la revue. Quand les agents produisent du code plus vite que les humains ne peuvent le relire, le goulot d’étranglement remonte en amont. Relire une spec markdown d’une page est plus facile que relire un diff de 800 lignes. L’équipe d’OpenSpec l’a bien formulé lors de son lancement chez YC : les équipes passent de la revue de code à la revue de plan, parce qu’un changement coûte peu dans une spec et cher dans le code.

Pour une banque, ou tout environnement régulé (j’y travaille), il y a une troisième raison : la traçabilité. Une spec versionnée dans git, qui relie exigences, tâches et commits, et qui survit à la session de chat, c’est quelque chose qu’un auditeur peut suivre. Un historique de prompts, non.

Partie 2 : le quoi

« Framework de développement piloté par l’IA » est un parapluie à saveur marketing. En dessous, je distingue quatre familles, et savoir à quelle famille appartient un outil compte plus que son nombre d’étoiles.

1. Les frameworks de spec-driven development (SDD). La spec est la source de vérité ; le code en découle. Vous écrivez (ou co-écrivez) une spécification, le framework la transforme en plan puis en tâches, l’agent implémente en s’y référant. Spec Kit, OpenSpec, Kiro.

2. Les enforceurs de méthodologie. Pas de pipeline, pas de hiérarchie d’artefacts. À la place, des « skills » composables qui forcent l’agent à se comporter en ingénieur discipliné : brainstormer avant de coder, écrire le test qui échoue d’abord, déboguer par la cause racine. Superpowers, les skills de Matt Pocock.

3. Les frameworks d’équipe d’agents / cycle de vie. Ils simulent une équipe de delivery complète : agent PM, agent architecte, agent développeur, agent UX, chacun avec ses workflows, du brainstorming au déploiement. BMAD Method, GSD.

4. Les couches de mémoire et de connaissance. Pas un workflow du tout, mais l’organe manquant : une mémoire persistante et interrogeable que n’importe quel agent peut lire et écrire, pour que le contexte survive aux sessions et aux repos. GBrain (avec son jumeau GStack).

Ces familles se composent. Vous pouvez faire tourner OpenSpec pour la planification, Superpowers pour la discipline d’implémentation et GBrain pour la mémoire. Personne ne vous oblige à choisir, même si votre fenêtre de contexte aura son mot à dire.

Partie 3 : le comment (les mains dans le cambouis)

Tout ce qui suit a été vérifié sur la documentation courante en juillet 2026. Les versions bougent vite ; prenez ces commandes comme la forme générale du setup et attendez-vous à ce que les repos aient évolué au moment où vous lirez ceci.

GitHub Spec Kit

Famille : SDD. Origine : GitHub, open-sourcé en septembre 2025, issu des recherches de John Lam pour rendre le développement piloté par LLM plus déterministe.

Spec Kit, c’est deux choses : le CLI specify (Python 3.11+, installé via uv) et un jeu de templates et de scripts déposés dans votre repo. Il n’y a délibérément aucune magie au-delà ; même le CLI est optionnel, puisqu’il se contente surtout de télécharger des paquets de prompts pré-cuisinés.

# Installer uv d'abord (https://docs.astral.sh/uv/), puis :
uv tool install specify-cli
specify init mon-projet --integration copilot   # ou claude, cursor, gemini...

Votre repo contient désormais .specify/ (templates, scripts et un dossier « memory » qui héberge la constitution) plus les fichiers de prompts pour votre agent. Depuis l’agent, le workflow est une chaîne de slash commands :

/speckit.constitution   # principes non négociables du projet, écrits une fois
/speckit.specify        # quoi construire et pourquoi (pas encore de stack)
/speckit.plan           # architecture et plan technique
/speckit.tasks          # découpage en tâches implémentables
/speckit.analyze        # contrôle de cohérence entre artefacts
/speckit.implement      # exécution

La constitution est la pièce sous-estimée. C’est là qu’une organisation encode une fois pour toutes « chaque service expose des health checks » ou « CLI-first, toujours », et chaque future fonctionnalité en hérite. Spec Kit supporte plus de 30 agents, propose maintenant un mode skills (--integration-options="--skills"), des extensions (Jira, Azure DevOps, threat modeling OWASP LLM) et des presets pour imposer des standards d’organisation.

Verdict d’usage : le plus complet et le plus cérémonieux des outils SDD. Excellent pour des fonctionnalités greenfield sur des bases de code sérieuses et pour des équipes qui veulent un processus partagé et opinionated. Lourd pour les petits correctifs ; personne n’écrit une constitution pour changer la couleur d’un bouton.

OpenSpec

Famille : SDD. Origine : Fission-AI, open source (MIT), passé par Y Combinator ; présent sur le Technology Radar de Thoughtworks ; plus de 28k étoiles GitHub début 2026.

OpenSpec est le contrepoint léger de Spec Kit. Son idée centrale : une bibliothèque de specs vivante plus un système de changes : chaque fonctionnalité reçoit une proposition, un design, des tâches et des deltas de spec montrant comment les exigences vont changer. À la livraison, les deltas fusionnent dans la bibliothèque de specs. Tout est en markdown, dans git, lisible par n’importe lequel des 30+ agents supportés.

npm install -g @fission-ai/openspec@latest   # Node.js >= 20.19
cd votre-projet
openspec init                                # choisissez vos agents à l'invite

Puis, depuis votre agent :

/opsx:explore    # partenaire de réflexion sans enjeu : lit le code, pèse les options
/opsx:new        # démarre un change : proposition, design, tâches, deltas de spec
/opsx:continue   # implémente pas à pas en suivant la checklist de tâches
/opsx:verify     # vérifie l'implémentation contre la spec
/opsx:archive    # fusionne les deltas dans la bibliothèque de specs

Le cycle de vie est honnête sur la réalité du développement : proposer, appliquer, archiver. L’étape design.md attrape régulièrement les mauvaises approches avant qu’une ligne de code n’existe, ce qui est tout l’intérêt. Une fonctionnalité Stores (en bêta) déplace les specs dans leur propre repo pour la planification multi-repos et partagée en équipe. Une note pour les usages en entreprise : OpenSpec collecte une télémétrie anonyme (noms de commandes) ; export OPENSPEC_TELEMETRY=0 la désactive.

Verdict d’usage : le meilleur ratio effort/structure de la famille SDD. Là où Spec Kit ressemble à l’adoption d’une méthodologie, OpenSpec ressemble à l’ajout d’une couche de planification sur le workflow que vous avez déjà. Ma recommandation par défaut pour les équipes qui débutent en SDD.

Superpowers

Famille : enforceur de méthodologie. Origine : Jesse Vincent (obra), créateur de Request Tracker. Publié en octobre 2025, le jour même où Anthropic lançait le système de plugins de Claude Code, et aujourd’hui parmi les projets les plus étoilés et les plus installés de cet écosystème (environ 987k installations sur la page officielle du plugin).

Superpowers ne vous donne pas de pipeline. Il installe une bibliothèque de skills composables plus l’orchestration qui force l’agent à les utiliser vraiment. Les skills se déclenchent automatiquement : l’agent détecte que vous construisez quelque chose et démarre une session de brainstorming socratique au lieu d’écrire du code. L’implémentation passe par un TDD red-green-refactor imposé, où le test doit échouer avant que l’implémentation n’existe. Le débogage suit une méthodologie en quatre phases qui exige l’investigation de la cause racine avant tout correctif. Le travail se fait dans des git worktrees isolés, avec du développement par sous-agents et une revue de code intégrée.

# Dans Claude Code :
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
/skills          # vérifier ce qui est chargé

C’est tout le setup. Pas de scaffolding projet, pas de hiérarchie d’artefacts.

Verdict d’usage : ce qui se rapproche le plus d’un binômage entre votre agent et un senior intransigeant. La discipline est réelle et parfois agaçante, c’est à ça qu’on voit qu’elle fonctionne. C’est natif Claude Code ; les autres harnais demandent une copie manuelle des skills. Idéal pour les développeurs qui croient déjà au TDD et veulent qu’il soit imposé, pas suggéré.

BMAD Method

Famille : équipe d’agents / cycle de vie. Origine : la communauté BMad Code (bmad-code-org), « Breakthrough Method of Agile AI-Driven Development », aujourd’hui en v6.

BMAD est l’option maximaliste : plus de 12 agents spécialisés (PM, architecte, développeur, UX, et d’autres), des workflows structurés couvrant analyse, planification, architecture et implémentation, et même un « party mode » qui met plusieurs personas d’agents dans une même session pour qu’ils débattent entre eux. La v6 a ajouté une architecture de skills, des équipes d’agents multi-plateformes et l’automatisation de la boucle de dev.

npx bmad-method install     # Node.js 20+, installateur interactif
# sélectionnez les modules (BMM = la méthode cœur) et vos outils (claude-code, cursor...)

Puis dans votre IDE ou agent :

/bmad-help                  # détecte les modules installés et vous dit quoi faire ensuite

BMad-Help est un vrai bon design d’onboarding : au lieu de mémoriser des workflows, vous lui demandez « je viens de finir l’architecture, je fais quoi maintenant ? » et il vous aiguille. BMAD propose trois pistes de planification selon la complexité du projet et trois flux (Full Method, Quick Dev, BMad Loop), donc pas de cérémonie agile complète imposée pour une tâche bien bornée.

Verdict d’usage : la simulation la plus complète d’une équipe de delivery, et la plus lourde. Les développeurs solo qui construisent un produit de zéro en tirent le plus ; il brille quand vous avez réellement besoin de PRD, de docs d’architecture et de planification par étapes. Si votre travail arrive sous forme de tickets bien cadrés, ce sera comme mettre un costume pour écrire un script shell.

GBrain (et GStack)

Famille : couche de mémoire / connaissance. Origine : Garry Tan, président et CEO de Y Combinator, qui a open-sourcé (MIT) le système de mémoire de ses propres agents de production : au dernier pointage, environ 146k pages, 24,5k personnes, 5,3k entreprises et 66 cron jobs autonomes.

À strictement parler, GBrain n’est pas un framework de code. C’est une couche de connaissance markdown-first adossée à Postgres : une récupération hybride combinant graphe de connaissance typé, recherche vectorielle et grep, avec un graphe câblé automatiquement sans appels LLM. Sa philosophie de design : « thin harness, fat skills », un runtime minimal et l’intelligence logée dans des fichiers de skills markdown lisibles. Son projet jumeau GStack est le setup Claude Code réel de Tan, une vingtaine de rôles spécialisés couvrant les workflows de CEO à QA.

Pourquoi l’inclure ici ? Parce que le problème d’amnésie de la Partie 1 est exactement ce qu’il résout, et qu’il se branche aux agents de code via MCP (74 outils exposés) :

# Après installation de GBrain (voir le repo) et initialisation du store Postgres :
claude mcp add gbrain -- gbrain serve
# Cursor / Windsurf / Claude Desktop : config MCP JSON standard
#   { "mcpServers": { "gbrain": { "command": "gbrain", "args": ["serve"] } } }

Votre agent peut alors search, get_page, put_page, parcourir les backlinks et répondre depuis la connaissance accumulée avant de tenter un appel externe.

Verdict d’usage : l’engagement d’infrastructure le plus lourd de cette liste (Postgres, ingestion, maintenance) et le plus niche. Si votre douleur est « mon agent oublie tout ce qui n’est pas du code », c’est la réponse sérieuse. Si votre douleur est le processus, regardez ailleurs d’abord. Un GBrain.io hébergé existe pour ceux qui ne veulent pas l’opérer eux-mêmes.

Les skills de Matt Pocock (et son framework anti-framework)

Famille : enforceur de méthodologie, avec une philosophie qui rejette en partie cet article. Origine : Matt Pocock, connu pour Total TypeScript et AI Hero ; le repo mattpocock/skills est son répertoire personnel de skills, publié tel quel, devenu l’une des collections les plus installées de l’écosystème Claude Code (plus de 160k étoiles GitHub et des millions d’installations mi-2026).

npx skills@latest add mattpocock/skills
# choisissez vos skills et vos agents cibles ; incluez setup-matt-pocock-skills
# puis, dans votre agent :
/setup-matt-pocock-skills   # une seule fois : tracker (GitHub, Linear, local), labels, chemin des docs

Les skills s’enchaînent en pipeline complet si vous le souhaitez :

/grill-me     # l'agent VOUS interviewe jusqu'à ce que le design soit réellement partagé
/to-prd       # transforme la compréhension alignée en PRD
/to-issues    # découpe en tickets exécutables indépendamment
/tdd          # implémentation red-green-refactor imposée
/diagnosing-bugs, /triage, /git-guardrails-claude-code ...

grill-me est l’idée qui se détache : elle inverse l’interaction, l’agent devenant un relecteur exigeant qui creuse les embranchements, les cas limites et les décisions non tranchées avant qu’une ligne ne soit écrite. Le désalignement, mode d’échec numéro un, est attaqué frontalement.

Mais voici le twist qui rend Pocock digne d’écoute : il plaide explicitement contre les frameworks lourds, y compris contre le spec-driven development lui-même. Dans son workshop AI Engineer 2026, sa position est que le champ de bataille, c’est le code, pas la spec ; un PRD est un repère de référence, pas une entrée de compilateur. Il recommande /clear plutôt que /compact (le « principe memento » : un état vide et déterministe vaut mieux qu’un résumé bruité), un system prompt minuscule pour rester dans la smart zone, et de posséder toute sa stack plutôt que d’installer un framework qu’on ne sait pas déboguer quand il déraille. À la question directe « faut-il installer spec-kit ? », sa réponse est non : possédez votre processus pour savoir quoi réparer quand il casse.

Verdict d’usage : le meilleur kit de démarrage de cet article, et son meilleur correctif philosophique. De petits fichiers markdown lisibles et modifiables, zéro lock-in, une valeur immédiate rien qu’avec grill-me et tdd. Une réserve honnête venue du terrain : les skills sont probabilistes ; les agents les sautent parfois sous charge, et l’application s’améliore nettement quand on les combine avec des hooks.

À connaître aussi : Kiro et GSD

Deux entrées de plus méritent une mention, même sans section complète.

Kiro est l’IDE agentique d’AWS (un fork de Code OSS, sans compte AWS requis) avec le spec-driven development intégré au produit : exigences, design et tâches sont des objets de première classe dans l’interface, et des hooks d’agents événementiels déclenchent des garde-fous qualité (tests, docs, scans de sécurité) à la sauvegarde des fichiers. C’est le SDD en tant que produit plutôt qu’en surcouche, avec un routeur automatique entre plusieurs modèles frontière. Si votre équipe vit dans un IDE et veut une structure imposée par l’outil lui-même, c’est l’option la plus solide.

GSD (Get Shit Done) est l’alternative légère et sans cérémonie à BMAD : un système de méta-prompting et de context engineering spec-driven, principalement pour Claude Code, installable via npx get-shit-done-cc@latest. Il est passé du premier commit (décembre 2025) à plus de 61k étoiles GitHub en environ cinq mois, porté par une orchestration multi-agents qui donne à chaque chercheur, planificateur, exécuteur et vérificateur parallèle une fenêtre de contexte fraîche. Le nom résume la philosophie.

Partie 4 : le benchmark

	Spec Kit	OpenSpec	Superpowers	BMAD Method	GBrain	Skills Pocock	Kiro	GSD
Famille	SDD	SDD	Méthodologie	Équipe d’agents	Couche mémoire	Méthodologie	SDD (IDE)	Équipe d’agents (léger)
Porté par	GitHub	Fission-AI (YC)	Jesse Vincent / communauté	Communauté BMad	Garry Tan / communauté	Matt Pocock / communauté	AWS	Communauté
Installation	uv tool install specify-cli	npm i -g @fission-ai/openspec	Plugin Claude Code	npx bmad-method install	Repo + Postgres + MCP	npx skills add mattpocock/skills	Télécharger l’IDE	npx get-shit-done-cc
Agents supportés	30+	30+	Natif Claude Code	Claude Code, Cursor, etc.	Tout client MCP	Claude Code, Cursor, Windsurf, Codex	Intégré	Claude Code + 8 autres
Cérémonie	Élevée	Moyenne	Faible (auto-déclenchement)	Élevée	N/A (infra)	Faible	Moyenne (imposée par le produit)	Moyenne-faible
Temps de setup	~10 min	~5 min	~2 min	~15 min	Des heures	~5 min	~10 min	~5 min
Artefacts persistants	Constitution, specs, plans, tâches	Bibliothèque de specs + deltas	Aucun (processus pur)	PRD, architecture, stories	Graphe de connaissance	PRD, issues, docs de contexte	Exigences, design, tâches	Specs, plans
Terrain idéal	Standard SDD d’organisation, features greenfield	Équipes ajoutant une couche de planification	Adeptes du TDD sur Claude Code	Dev solo construisant un produit de bout en bout	Agents qui doivent tout retenir	Devs individuels, premier framework	Équipes IDE voulant une structure imposée	SDD rapide solo/petite équipe
Point faible	Lourd pour les petits changements	Écosystème plus jeune	Lock-in Claude Code	Surdose de cérémonie	Coût d’infrastructure	Déclenchement probabiliste	Lock-in IDE	Moins de gouvernance

Trois observations transversales après les avoir fait tourner :

1. La cérémonie doit correspondre à la taille des lots. Chaque framework SDD taxe les petits changements. Les équipes les plus heureuses avec Spec Kit ou BMAD sont celles dont le travail arrive naturellement par blocs de la taille d’une fonctionnalité. Pour un correctif d’une ligne, tout framework de cette liste est de l’overhead, et les bons (les profils d’OpenSpec, la piste Quick Dev de BMAD) l’admettent en offrant des raccourcis.

2. L’imposition bat la suggestion. La différence mesurable entre « l’agent a un skill TDD » et « l’agent ne peut pas avancer sans un test qui échoue » fait tout. Superpowers et les skills Pocock adossés à des hooks sont du bon côté de cette ligne ; les fichiers d’instructions nus sont du mauvais.

3. Les artefacts servent aussi aux humains. Le bénéfice inattendu du SDD en équipe : les specs sont devenues notre surface de revue, nos docs d’onboarding et, dans un environnement régulé, notre piste d’audit. Cette valeur existe même les jours où l’agent n’écrit rien.

Partie 5 : comment choisir

Mon arbre de décision honnête, après avoir vécu avec :

• Vous êtes un développeur individuel, nouveau dans tout ça : commencez par les skills de Matt Pocock. grill-me + tdd changeront votre façon de travailler en un après-midi, et vous pouvez lire chaque ligne de ce que vous avez installé.
• Vous êtes sur Claude Code et voulez une discipline d’ingénierie imposée : Superpowers.
• Votre équipe veut des specs qui survivent aux sessions de chat, avec un minimum de cérémonie : OpenSpec.
• Votre organisation veut un processus SDD standard et auditable sur de nombreux repos et agents : Spec Kit, en prenant la constitution au sérieux.
• Vous êtes un fondateur solo qui construit un produit de zéro : BMAD Method (ou GSD si BMAD ressemble trop à un costume).
• L’amnésie de vos agents est le vrai goulot d’étranglement : GBrain, en connaissance de cause côté infrastructure.
• Vous voulez la structure, mais dans un produit IDE : Kiro.

Et gardez l’avertissement de Pocock scotché sur votre écran : un framework que vous ne savez pas expliquer est un framework que vous ne savez pas déboguer. Quoi que vous adoptiez, lisez le markdown qu’il installe. Tous ces outils ne sont, au fond, que des prompts dans des dossiers. Ce n’est pas une critique ; c’est la raison pour laquelle vous avez le droit de les comprendre.

Sources et lectures complémentaires

• GitHub Spec Kit : repo · docs · annonce sur le blog GitHub · le récit de l’intérieur par Den Delimarsky
• OpenSpec : repo · lancement YC · entrée au Radar Thoughtworks
• Superpowers : page officielle du plugin · tutoriel DataCamp
• BMAD Method : repo · getting started
• GBrain : tutoriel pratique MarkTechPost · revue indépendante
• Matt Pocock : repo skills · notes du workshop AI Engineer 2026 · synthèse du workflow
• Panorama : MarkTechPost : les 9 meilleurs outils SDD en 2026

---

Commandes et versions vérifiées en juillet 2026. Ce domaine bouge tous les mois ; vérifiez les repos avant de copier-coller en production.