BMAD, Spec-kit : quel framework choisir pour réussir en vibe coding ?

J’ai demandé à Claude Code d’ajouter l’authentification Magic Link (lien d’authentification à usage unique envoyé par email). Quatre cents lignes générées en deux minutes. Clé API exposée côté client, aucune limite de connexion, RLS (Row-Level Security) désactivée (accès à toute la table, au lieu des seules données concernant l’utilisateur). Code livré, surface d’attaque ouverte.

La semaine suivante, j’ai refait la même fonctionnalité avec une spec d’une page, un Security Gate STRIDE (une méthode de modélisation des menaces) et OWASP (référentiel de sécurité applicative), et un workflow structuré. Durée comparable (sur ce cas précis). Aucune vulnérabilité à corriger après le déploiement.

L’ordre des opérations était différent.

En 2026, une dizaine de frameworks structurent le développement assisté par IA : BMAD, Spec-kit, Kiro, GSD, Ralph Loop, OpenSpec… Le vrai clivage n’est pas le choix de l’outil, c’est la posture adoptée avant la première ligne de code. Ceux qui structurent en amont déplacent les bugs vers la spec. Les autres les découvrent en production.

La question que le vibe coding a rouverte

Le terme vibe coding a été inventé par Andrej Karpathy (co-fondateur d’OpenAI), en février 2025, pour caractériser la programmation « au ressenti » : le code devient quasi-gratuit, on décrit, l’IA produit. Le résultat est souvent fonctionnel, mais comme le résume une formule devenue virale sur Hacker News, « spec driven development doesn’t work if you’re too confused to write the spec ». Ce que le vibe coding a évacué, c’est la rigueur de l’intention, pas nécessairement sous forme de document, mais sous une forme quelconque.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

Les équipes d’Anthropic elles-mêmes disent ne plus avoir besoin de spécification formelle pour certains workflows, la génération de code va parfois plus vite que la pensée, et le code devient le brouillon depuis lequel l’intention émerge. Ce n’est pas une régression : c’est une forme d’exploration légitimée par la vitesse des outils. Il reste que des décisions structurantes (une migration de base de données, un choix d’architecture, un contrat d’API) demandent une intention avant l’exécution. L’ADR (Architecture Decision Record, note de décision structurée) existe précisément pour consigner ces choix structurels, même dans les équipes qui codent vite.

L’IA a rendu la question de l’intention plus coûteuse à ignorer.

Le mécanisme que les frameworks ne nomment pas

Plus d’une dizaine de frameworks ont émergé en 2025-2026 pour répondre à ce problème. Ils se présentent comme des méthodologies, des CLI (Command Line Interface, interface pour lancer des commandes), des IDE (Integrated Development Environment, environnement de développement intégré comme VS Code). Ils proposent des cycles, des artefacts, des jalons de validation humains (gate reviews). Mais leur différence fondamentale n’est pas là.

Le vrai clivage passe entre deux postures :

• La structuration amont : écrire ce qu’on veut avant de demander à l’agent de le faire. Spécification, constitution, CLAUDE.md (le fichier de paramétrage de Claude si c’est votre assistant de codage), user stories avec critères d’acceptation. Peu importe la forme. L’intention précède l’exécution.

• L’improvisation outillée : donner à l’agent un prompt, évaluer le résultat, corriger, itérer. L’intention se construit à travers le code.

La structuration amont déplace les coûts dans le temps : les problèmes se découvrent dans la spec, pas en production. Le vibe coding ne coûte pas moins cher (il facture plus tard si on se loupe).

Une précision de périmètre : cet article ne couvre pas les outils qui facilitent le vibe coding sans exposer le code (Lovable, Base44, Manus, Antigravity…). Ces produits occupent un espace pertinent entre le no-code et le vibe coding — les puristes m’en voudront, mais ils répondent à un vrai besoin. Ils ne font simplement pas partie du même paysage que les frameworks de structuration : leur promesse est différente, leur audience aussi.

C’est ce que Marc Brooker (AWS) appelle l’élévation du niveau d’abstraction : le SDD (Specification Driven Development, développement piloté par la spécification) ne concentre pas sur l’amont, il redistribue le travail intellectuel à un autre endroit du processus. La boucle de feedback passe de mois (spec figée en amont) à minutes (spec vivante itérable). Ce que Marmelab appelle « le retour du Waterfall » est en réalité une confusion de registre : c’est l’intention qui est traitée en amont, pas l’implémentation.

Cet article s’inscrit dans un fil de réflexion plus large sur le harness comme vrai produit d’un système agentique, la spec est l’une des couches de ce harness.

Les familles de frameworks

Avant d’entrer dans le détail, trois familles structurent le paysage 2026.

1. Spec-Driven Development (SDD) : la spécification devient l’artefact central, le code en dérive. Spec-kit, Kiro, Tessl en sont les incarnations.
2. Multi-agent / multi-persona : plusieurs agents spécialisés (PM, Architecte, Développeur, QA) collaborent sur un workflow agile. BMAD pousse cette logique le plus loin, avec 12+ personas et un artefact dédié à chaque phase.
3. Context engineering pur : ni spec formalisée, ni équipe d’agents. Un CLAUDE.md bien architecturé, des règles cumulatives, des skills chargés à la demande.

Ces trois familles ne s’excluent pas : en 2026, la combinaison gagne sur le framework unique. Mon propre framework s’appuie essentiellement sur spec-kit mais en intégrant les apports pertinents des autres approches.

Structuration amont

Spec-kit (72K+ étoiles GitHub) incarne l’approche SDD la plus mature. Poussé par GitHub lui-même, ce n’est pas un projet communautaire sorti de nulle part : c’est un signal fort sur la direction que prend l’outillage de développement. Le cycle « Constitution → Specify → Plan → Tasks → Implement » force la structuration à chaque étape, avec des points de validation humains explicites. Agnostique du choix de l’agent par design (vous êtes libres d’utiliser n’importe quel outil du marché : Codex, Claude, DeepSearch…). Sa limite : sur une fonctionnalité simple, la surcharge documentaire (~800 lignes de spécification pour un projet moyen) génère de la friction.

BMAD (Breakthrough Method for Agile AI-Driven Development, 3600+ développeurs dans la communauté) pousse la logique plus loin en construisant une équipe agile virtuelle (Analyst, PM, Architecte, Dev, QA) avec 12+ personas spécialisés. Né dans la communauté open-source, sans adossement à un éditeur, il a été conçu précisément pour structurer ce que le vibe coding laisse en l’air : la coordination entre phases et la préservation du contexte entre sessions. Chaque phase produit un artefact (PRD, Product Requirement Document, architecture sketch, user stories) qui voyage vers la suivante. La limite : sur les petits projets, le workflow complet est surdimensionné.

AWS Kiro intègre le SDD directement dans un IDE (fork VS Code) avec des specs en notation EARS (Easy Approach to Requirements Syntax), des hooks event-driven, et Claude Sonnet (le modèle d’Anthropic) en moteur. L’expérience est fluide, mais la dépendance à un modèle unique limite son déploiement. Delta Airlines rapporte 94% de satisfaction sur le pilote, avec un glissement remarqué vers l’architecture plutôt que vers l’implémentation directe. Je ne l’ai pas testé.

OpenSpec occupe le segment léger du SDD : courbe d’apprentissage basse, overhead réduit (~250 lignes vs ~800 pour Spec-kit), brownfield-first (en partant d’une base de code existante, par opposition à greenfield). Utile comme point d’entrée avant d’adopter un framework plus complet, ou comme choix durable sur un périmètre solo. C’est le dernier framework que j’ai analysé en profondeur, et il a enrichi mon propre framework : j’en ai notamment tiré l’ajout d’un skill /explore mobilisable à n’importe quel moment du cycle de développement, pour sortir du flux d’exécution et reprendre de la hauteur. [Expérience directe]

GSD (Get Shit Done, 61K étoiles) prend le contre-pied de la formalisation. Pas d’artefact produit, pas de personas. Un unique fichier de méta-prompting qui guide l’agent pour qu’il décompose sa tâche, valide son intention avant d’agir, et gère explicitement la dégradation du contexte sur les longues sessions. Le résultat : un agent qui ne dérive pas sur les tâches longues sans imposer de surcharge à l’équipe. Utile en combinaison avec n’importe quel workflow SDD, ou seul sur des projets simples.

Le positionnement comparé des frameworks spec-driven :

Le cas particulier de Tessl

Tessl pousse le SDD à son extrême : la spec devient la source primaire, le code est marqué // GENERATED FROM SPEC. Le Spec Registry (spécifications vérifiées pour les librairies open-source) résout directement le problème des hallucinations d’API : un agent ne peut pas halluciner une API React 19 s’il a la spécification vérifiée devant lui.

Martin Fowler note le parallèle avec le MDD (Model-Driven Development, développement piloté par les modèles), qui n’a pas tenu ses promesses pour les applications métier. Son verdict : le risque est d’hériter des deux inconvénients à la fois, l’inflexibilité du MDD et le non-déterminisme des LLMs (à 2 requêtes identiques, dans les mêmes conditions, les LLMs peuvent générer 2 réponses différentes).

Une nuance toutefois sur le périmètre. Les Usage Specs (spécifications d’usage) de Tessl décrivent des librairies stables (React, Quarkus), pas des exigences métier changeantes. Le risque de dérive MDD est plus faible sur ce périmètre : qui maintient la spécification de React (une bibliothèque JavaScript/TypeScript pour le développement web) ? React lui-même. Sur les specs applicatives en revanche (celles qui capturent les exigences fonctionnelles d’une application particulière), le piège MDD s’applique intégralement. Le LLM lève la contrainte de génération de code, il ne lève pas la contrainte humaine : qui met à jour la spec quand les exigences changent ? C’est une question de gouvernance, et aucun framework n’y répond. Ce n’est pas adapté à mes projets.

Approches complémentaires

Superpowers (183K étoiles) n’est pas un framework SDD. C’est une méthodologie agentique complète (brainstorming → plan → sous-agents spécialisés → TDD (Test-Driven Development, concevoir le test avant le code) → validation git) qui opère comme une couche au-dessus des outils existants. Il ne remplace pas Spec-kit ou BMAD : il orchestre comment les agents collaborent une fois la spec posée. Ce que j’ai retenu : la discipline TDD intégrée et la décomposition systématique en sous-agents spécialisés. À 183K étoiles, c’est l’approche la plus adoptée du segment, ce qui ne la rend pas forcément la mieux documentée.

La Ralph Loop n’est pas un framework SDD au sens strict. Nommée en hommage à Ralph Wiggum, le personnage des Simpsons naïf et optimiste qui essaie sans se poser de questions, elle structure l’environnement cognitif de l’agent plutôt que le processus de développement. La logique dans un assistant de code est la suivante :

 Lis IMPLEMENTATION_PLAN.md.
 Choisis UNE seule tâche non faite.
 Implémente-la. Teste. Commite.
 Si tout est terminé, output <promise>COMPLETE</promise>.

Une seule tâche par itération : ça bourrine avec méthode. Il y a même un plugin officiel pour Claude Code.

Ces approches partagent un même constat empirique : le context rot identifié par Hamel Husain sur 18 modèles à l’état de l’art. La performance LLM se dégrade de façon non linéaire avec la longueur du contexte. Un workflow qui ne gère pas le contexte activement ne retrouvera pas à l’itération 20 la qualité de l’itération 2. Les frameworks qui ignorent ce phénomène produisent un biais de confiance : le code généré lors de la seconde itération fonctionne, mais la qualité régresse à mesure que le contexte se dégrade.

OpenSpec apporte ici une mécanique concrète. Le framework structure l’intention en quatre artefacts versionnés (proposal.md pour le pourquoi, specs/ au format delta (ADDED, MODIFIED, REMOVED) pour le quoi, design.md pour le comment, tasks.md pour la liste d’exécution). Avant l’implémentation, l’historique de chat est purgé et seuls ces artefacts (quelques milliers de tokens) sont injectés à l’agent. Le contexte reste propre par construction, pas par discipline.

Les approches complémentaires, ni SDD pur ni multi-agent, mais combinables avec les deux :

L’arbre de décision du praticien

La question « quel framework choisir ? » est souvent posée trop tôt. La bonne question est : quelle est ma situation ? Pour les cas où j’ai une expérience directe, voici ce que j’applique, ou ce que j’appliquerais. Pour les autres, ce sont des analyses depuis l’extérieur, à peser avec ce biais en tête.

• Je prototype un MVP rapidement. Vibe coding avec Claude Code + CLAUDE.md structuré. La surcharge documentaire du SDD ne se rentabilise pas à ce stade. [Expérience directe]

• Je construis une feature complexe dans un codebase existant. Spec-kit si vous êtes dans l’écosystème GitHub. Kiro si vous préférez une expérience IDE intégrée et acceptez le lock-in modèle. Le SDD léger apporte de la valeur sans l’overhead multi-agent. [spec-kit : expérience directe. Kiro : analyse externe]

• Je dois faire évoluer un legacy mal documenté. OpenSpec est conçu pour ce cas (brownfield-first) : la baseline de spec se construit progressivement à partir de l’existant, le format delta capture chaque évolution sans imposer de tout documenter d’emblée. [Analyse externe, non testé en production]

• Je lance un projet greenfield de taille moyenne+. BMAD pour la phase de planning (PRD, architecture, user stories), puis Claude Code pour l’implémentation. BMAD excelle dans le front-loading (concentration du travail intellectuel en amont). [Expérience directe]

• Mon équipe souffre des hallucinations sur les APIs tierces. Tessl Registry, combinable avec n’importe quel autre framework via MCP (Model Context Protocol, protocole d’intégration d’outils pour LLMs). [Analyse externe, non testé en production]

• Je suis solo CTO ou consultant, je veux le contrôle maximal. Architecture CLAUDE.md personnalisée, enrichie progressivement. Éventuellement combinée avec Tessl Registry pour les specs de librairies. [Expérience directe]

• Je veux maximiser l’autonomie agent avec des garde-fous. Un harness de production (sécurité intégrée, skills cadrés) + spec-kit ou BMAD pour la structuration du workflow. Attention à la surcharge du CLAUDE.md : au-delà d’un certain seuil de tokens, les modèles commencent à déprioriser les règles en fin de contexte : le chiffre exact dépend du modèle et n’est pas documenté, mais la dégradation est réelle (c’est le context rot). [Expérience directe]

Ce marquage permet au lecteur de pondérer correctement, et au praticien de ne pas confondre conviction et expérience. Pour ceux que ça intéresse, j’ai formalisé l’intégralité du framework que j’utilise quotidiennement.

Le périmètre de validité

L’objection légitime : pour un POC de trois pages sans suite, la structuration coûte plus qu’elle ne rapporte. C’est vrai, et je ne le conteste pas.

Trois situations rendent la spec contre-productive :

1. une correction ponctuelle sur une ligne,
2. un prototypage purement exploratoire dont la finalité est de jeter le code à la fin,
3. le travail hautement visuel où la manipulation directe (déplacer un bouton, ajuster une marge) communique plus vite qu’une description.

Sur ces périmètres, la structuration formelle ralentit sans valeur ajoutée.

La structuration n’est pas une règle universelle : c’est une décision calibrée à la taille du problème. Quand on écrit un mail de trois lignes, on n’a pas besoin de faire un plan. Quand on écrit un essai de trente pages, c’est mieux. La question n’est pas « spec ou pas spec », c’est « quel est mon projet, quelles proportions peut-il prendre ? »

Deux points nuancent cependant la frontière. D’abord, les projets « simples » tendent à devenir pérennes. Dans ma pratique, j’ai replacé sur les rails de spec-kit des projets initialement traités comme des prototypes jetables, parce qu’ils avaient trouvé une utilité, un utilisateur, une roadmap. Le prototype qui fonctionne devient le produit. Ce n’est pas une loi, mais c’est suffisamment fréquent pour mériter d’être anticipé.

Ensuite, même pour un projet effectivement jetable, la structuration légère coûte moins que le rework à chaud. Un CLAUDE.md bien écrit ne prend pas une heure. Une note d’intention d’une page non plus. Le seuil de rentabilité est plus bas qu’il n’y paraît.

La dette technique fonctionne comme le refoulé freudien : ce qui n’est pas traité en amont remonte toujours, sous une forme plus coûteuse.

« Le vrai choix en 2026 n’est pas BMAD ou spec-kit ou Kiro. C’est de décider, avant d’écrire la première ligne, si vous voulez trouver les problèmes dans la spec ou en production. »

Ce que j’en retiens

Le clivage structurant du développement assisté par IA n’est pas technologique : il est temporel. Les frameworks qui structurent l’amont ne réduisent pas le travail total. Ils le déplacent là où il coûte moins cher.

Le choix de l’outil vient après cette décision. Personnellement j’ai adapté Spec-kit, que je préfère à BMAD dont la logique de vouloir recréer des rituels humains pour une IA me gêne, même si j’en comprends la logique. J’anticipe le travail de spécification par l’identification des principaux parcours utilisateurs et le design system (qui force les formes graphiques), et j’y ajoute une pincée de TDD (Test Driven Development, où l’on conçoit le test avant le code). Je détaille tout cela dans mon framework.

Les outils cités dans cet article

• Claude Code — agent de codage d'Anthropic
• Spec-kit — SDD avec cycle Constitution → Implement
• BMAD — workflow multi-agent / multi-persona
• AWS Kiro — IDE avec SDD intégré, hooks event-driven
• Tessl — Spec Registry pour librairies open-source
• OpenSpec — SDD léger, brownfield-first
• GSD — meta-prompting léger, gestion de la dégradation de contexte
• Superpowers — méthodologie agentique complète (brainstorming → TDD → subagents)
• Ralph Loop — plugin Claude Code, itération par tâche unique