Le "vibe coding", c'est écrire du code à l'instinct, en espérant que l'IA devine vos intentions. Ça marche très bien pour démarrer. Puis le projet grossit, le contexte se fragmente entre les sessions, l'architecture se contredit elle-même, et vous passez plus de temps à corriger qu'à construire. En 2026, des frameworks structurés ont émergé pour répondre à ce problème précis : transformer un assistant IA en équipe de développement disciplinée. Ce guide vous explique comment ils fonctionnent, ce qui les distingue, et comment choisir selon votre profil. ## Qu'est-ce que le Spec-Driven Development (SDD) ? Le Spec-Driven Development (développement piloté par les spécifications) est une méthodologie qui inverse l'ordre habituel : au lieu de prompter directement pour obtenir du code, vous commencez par rédiger une spécification structurée, c'est-à-dire un document formel décrivant ce que le code doit faire, comment il doit s'intégrer, et quels critères permettent de valider qu'il fonctionne. Ce document devient la source de vérité unique. L'agent IA génère ensuite le code en se basant sur ce contrat, pas sur votre prompt approximatif du moment. La différence est fondamentale : un prompt vague produit un code plausible mais incohérent, une spec précise produit un code vérifiable et maintenable. Il existe en réalité trois niveaux d'engagement dans le SDD, identifiés par Birgitta Böckeler (Thoughtworks) dans son analyse de référence. Le niveau **spec-first** consiste à rédiger une spec avant de coder, puis à la jeter une fois la feature livrée. Le niveau **spec-anchored** conserve la spec comme document vivant, mis à jour à chaque évolution du code. Le niveau **spec-as-source** va plus loin : la spec devient le seul artefact que l'humain édite, le code n'étant plus qu'une sortie générée. La plupart des frameworks actuels opèrent en spec-first ou spec-anchored. Le spec-as-source reste expérimental, porté par des plateformes comme Tessl. Le SDD répond à trois problèmes concrets du développement IA assisté. Le premier est le "context rot" : après quelques échanges, l'IA perd le fil de l'architecture globale et produit du code qui contredit les décisions précédentes. Le deuxième est le "hallucinated intent" : l'IA infère vos intentions depuis un prompt incomplet et prend des décisions arbitraires. Le troisième est la dette de documentation : dans un workflow conversationnel, aucune trace des décisions d'architecture n'est conservée. Une spec formelle résout les trois simultanément. ## Quels sont les principaux frameworks SDD disponibles ? Six frameworks dominent le paysage en 2026, chacun avec une philosophie distincte. **BMAD Method** (Breakthrough Method for Agile AI-Driven Development) est le plus complet et le plus ambitieux. Il simule une équipe Agile entière avec des agents spécialisés : un Business Analyst, un Product Manager, un Architecte, un Scrum Master, un Développeur, un QA Engineer, un UX Designer. Chaque agent a un rôle précis, des responsabilités délimitées, et communique avec les autres via des artefacts Markdown versionnés dans le dépôt. Un projet BMAD passe par quatre phases séquentielles : Analyse, Planification (PRD, user stories), Architecture (choix techniques, design système), Implémentation (développement story par story, avec validation continue). Le framework est 100% open source, gratuit, et compatible avec tous les assistants IA du marché depuis sa version 6 stable — Claude Code, Cursor, Kiro, Windsurf, Codex, et 22 autres outils. Son intelligence "scale-adaptive" ajuste automatiquement le niveau de détail selon la complexité du projet, d'un simple bug fix jusqu'à un système enterprise. **Kiro** (développé par AWS) adopte une approche différente : c'est un IDE complet, fork de VS Code, qui intègre nativement le SDD. Quand vous décrivez une fonctionnalité en langage naturel, Kiro la traduit automatiquement en exigences structurées selon la notation EARS (Easy Approach to Requirements Syntax), génère un document de design architectural, puis crée un plan d'implémentation avec des tâches discrètes ordonnées selon leurs dépendances. Les "hooks" permettent de déclencher des agents automatiquement sur des événements comme la sauvegarde d'un fichier, pour générer des tests unitaires ou mettre à jour la documentation en continu. **GSD** (Get Shit Done) est un système de meta-prompting conçu spécifiquement pour Claude Code. Son workflow tient en quatre mots : Discuss, Plan, Execute, Verify. La spécificité de GSD est de lancer chaque phase dans une fenêtre de contexte fraîche avec ses propres sous-agents, ce qui élimine le context rot par conception. Idéal pour un développeur solo qui veut la rigueur du SDD sans la cérémonie de BMAD. **GitHub Spec Kit** est le framework de GitHub, distribué en CLI. Workflow : Constitution (règles globales du projet) puis cycle Specify, Plan, Tasks pour chaque feature. Le plus portable, le plus personnalisable, mais il nécessite une réconciliation manuelle si la spec dérive de l'implémentation. **OpenSpec** adopte une approche "proposal-first" : avant toute modification du code, l'agent soumet une proposition de changement pour approbation humaine. Parfait pour les environnements où la documentation de chaque évolution est obligatoire. **TaskMaster** est orienté équipes de 3 à 8 développeurs, avec support MCP pour 13 IDEs différents et gestion avancée des dépendances entre tâches en parallèle. | Framework | Profil cible | Niveau de cérémonie | IDE-agnostic | Atout principal | |---|---|---|---|---| | BMAD v6 | Teams / Enterprise | Élevé | Oui | Simulation équipe Agile complète | | Kiro | Solo à team | Moyen | Non (IDE propre) | SDD natif, zero config | | GSD | Dev solo | Faible | Claude Code | Anti-context-rot par design | | GitHub Spec Kit | GitHub users | Faible | Oui | Portabilité maximale | | OpenSpec | Brownfield | Très faible | Oui | Validation avant chaque changement | | TaskMaster | Teams 3-8 devs | Moyen | Oui | Multi-dev, dépendances | ## Comment choisir le bon workflow selon son contexte ?  La première question à se poser n'est pas "lequel est le meilleur" mais "quelle est la taille et la durée de vie de mon projet". Un framework comme BMAD génère une valeur décuplée sur un projet de 3 à 6 mois avec plusieurs développeurs, mais représente un surcoût réel pour un bug fix ou un prototype de weekend. La règle pratique : si le projet nécessite plus de 3 à 5 jours de développement, affecte plusieurs modules du système, ou doit être maintenu dans le temps, le SDD paye. En dessous, le prompting direct reste souvent plus rapide. Pour un développeur solo travaillant sur des projets de taille moyenne, GSD est le point d'entrée naturel. Il impose la discipline sans la lourdeur administrative de BMAD, et son intégration avec Claude Code le rend particulièrement efficace dans un workflow terminal. Pour un fondateur technique qui veut aller vite sans CTO, Kiro offre le meilleur ratio simplicité/structure : l'IDE se charge de générer la spec, le design et le plan de tâches depuis votre description en langage naturel, sans configuration préalable. Pour une équipe technique avec des processus Agile existants, BMAD est le choix le plus cohérent car ses agents reproduisent exactement les rôles d'une équipe Scrum. Un facteur souvent négligé est la compatibilité avec votre stack existant. BMAD est model-agnostic et IDE-agnostic, il s'installe en une commande (`npx bmad-method install`) et fonctionne aussi bien avec Claude Code, Cursor que Windsurf. Les frameworks peuvent aussi se combiner : BMAD pour la planification stratégique et l'architecture, Spec Kit ou GSD pour l'exécution tactique des stories individuelles. ## Peut-on créer son propre workflow SDD ? C'est précisément ce que Claude Code rend possible avec son système de **skills** : des fichiers Markdown placés dans `.claude/skills/` qui définissent un workflow complet, invocable avec une commande slash. Un skill Claude Code est structurellement identique à un mini-framework SDD : vous y décrivez les étapes, les artefacts attendus à chaque phase, les règles de validation, et les sous-agents à orchestrer. La communauté autour de Claude Code a rapidement transformé cette fonctionnalité en terrain d'expérimentation, avec des développeurs qui publient leurs skills sur GitHub comme autant de workflows personnalisés. Ce mouvement illustre une liberté que les grands frameworks n'offrent pas : adapter précisément le niveau de cérémonie à votre stack, votre rythme, et vos contraintes. Là où BMAD impose une structure complète et Kiro fixe un workflow d'IDE, un skill maison peut combiner les phases qui vous apportent de la valeur (analyse parallèle, planification file-by-file, validation automatisée) en supprimant ce qui alourdit inutilement votre pipeline. Les bonnes pratiques de la communauté convergent vers quelques principes communs : chargement progressif des étapes pour préserver le contexte, sauvegarde des outputs dans le dépôt pour reprendre une tâche interrompue, et lancement de sous-agents en parallèle pour la phase d'analyse. Vous pouvez partir d'un framework existant comme BMAD ou GSD, en extraire uniquement les étapes pertinentes, et les adapter à votre contexte, ce que permet explicitement le module BMAD Builder qui automatise la création de vos propres agents et workflows sur la même infrastructure. C'est aussi l'approche la plus compatible avec les formations orientées agents, comme [Automatiser ses workflows et créer des agents IA](https://www.travelearn.fr/formation/automatiser-ses-workflows-et-crer-des-agents-ia), dont les objectifs couvrent précisément la conception d'agents autonomes avec mémoire, logique et supervision. > "La valeur des specs n'est pas dans la documentation qu'elles produisent, mais dans les erreurs d'interprétation qu'elles éliminent avant la première ligne de code." > — Cian Clarke, NearForm (spécialiste BMAD en production) ## Quelles sont les limites réelles du Spec-Driven Development ? Le SDD n'est pas une solution universelle. La première limite est la dérive de la spec : les frameworks statiques produisent des documents qui peuvent diverger de l'implémentation réelle au fil du développement, nécessitant une réconciliation manuelle. Les plateformes à "living spec" tentent de résoudre ce problème mais sont plus récentes et moins éprouvées. La deuxième limite est le coût d'entrée : une semaine de montée en compétence est réaliste pour BMAD. La troisième limite est la pertinence sur les codebases existants : le SDD brille sur du greenfield, mais retrofitter une spec formelle sur un codebase legacy de 100 000 lignes reste laborieux. Enfin, le SDD suppose que votre spec de départ soit correcte. Une spec vague produit des artefacts vagues et du code incohérent, simplement avec plus de cérémonie. C'est pourquoi les frameworks matures incluent des agents de clarification avant même de commencer à rédiger la spec, pour s'assurer que ce qui est documenté reflète réellement l'intention du commanditaire. ## FAQ **Est-ce que BMAD fonctionne avec ChatGPT ou Gemini, ou seulement avec Claude Code ?** BMAD est conçu pour être model-agnostic. Il fonctionne avec Claude Code (son intégration la plus optimisée), mais aussi avec Cursor, Windsurf, VS Code avec GitHub Copilot, Codex, et même en mode Web Bundle directement dans ChatGPT ou Claude.ai sans installation. Le framework s'adapte aux capacités du modèle utilisé, mais tire le meilleur parti des modèles avec une grande fenêtre de contexte. **Le SDD ralentit-il vraiment le démarrage d'un projet ?** Oui, les premières heures d'un projet SDD sont plus lentes qu'un démarrage en vibe coding. La phase de planification avec BMAD peut prendre de 30 minutes à quelques heures selon la complexité. En contrepartie, les équipes qui l'ont adopté en production rapportent une réduction de 40 à 60% des bugs en production et une diminution de 50% du temps de refactoring sur des projets de plus d'un mois. L'investissement initial est réel, le retour sur investissement aussi. **Peut-on combiner plusieurs frameworks dans le même projet ?** Oui, et c'est même recommandé dans certains contextes. L'approche hybride la plus documentée consiste à utiliser BMAD pour la planification stratégique (PRD, architecture, user stories) et GSD ou un skill personnalisé pour l'exécution des stories individuelles. BMAD génère le "quoi" et le "pourquoi", le skill maison prend en charge le "comment" avec l'isolation contextuelle adaptée à votre stack spécifique. --- **Sources** - [BMAD-METHOD — GitHub officiel](https://github.com/bmad-code-org/BMAD-METHOD) - [Kiro — Site officiel](https://kiro.dev/) - [Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl — Martin Fowler / Birgitta Böckeler](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) - [6 Best Spec-Driven Development Tools for AI Coding in 2026 — Augment Code](https://www.augmentcode.com/tools/best-spec-driven-development-tools) - [Agentic Coding Tools 2026 — Obvious Works](https://www.obviousworks.ch/en/agentic-coding-tools-2026-the-7-frameworks-that-take-your-development-to-a-new-level/) - [Spec-Driven Development : 6 Frameworks AIDD — Hoko Blog](https://www.hoko.team/blog/spec-driven-development-frameworks-aidd-2026) - [Why Faster AI Development Often Increases Rework — Tessl / Cian Clarke](https://tessl.io/podcast/why-faster-ai-development-often-increases-rework-cian-clarke/)