Spec-Driven Development: origine, méthodologie, outils et ce que le hype ne dit pas

tl;dr — Le SDD est une réponse légitime à un problème réel lié aux agents IA. Le concept a du sens, les outils sont immatures, le coût est élevé et les preuves de ROI restent presque toutes anecdotiques. Ça vaut la peine de comprendre. Ça vaut la peine d’être sceptique.

Le problème à l’origine de tout cela

Pour comprendre pourquoi le Spec-Driven Development a émergé, il faut faire un pas en arrière.

En 2025, les agents IA comme Claude Code, Cursor et Codex ont cessé d’être de l’autocomplétion glorifiée pour commencer à exécuter des tâches complexes de façon autonome. C’est de là qu’est né le phénomène du vibe coding : vous décrivez ce que vous voulez en langage naturel, l’agent génère des centaines de lignes de code, et vous approuvez sans vraiment comprendre ce qui a été fait.

Le résultat ? Du code qui fonctionne jusqu’au moment où il faut le maintenir. Des décisions architecturales invisibles. De la dette technique accumulée à une vitesse industrielle.

L’étude la plus rigoureuse sur le sujet — menée par METR en 2025 avec des développeurs expérimentés sur de vrais projets open source — a conclu que les développeurs utilisant des outils IA étaient, en moyenne, 19 % plus lents qu’en travaillant sans eux. Pas plus rapides. La raison : des prompts non structurés créaient des boucles de débogage qui consumaient tout le temps gagné lors de la génération initiale de code.

Le Spec-Driven Development est la tentative de l’industrie de résoudre ce problème à la racine.

D’où vient l’idée

L’idée d’écrire des spécifications avant d’écrire du code n’est pas nouvelle. Elle est aussi ancienne que le génie logiciel lui-même.

1963 : Margaret Hamilton, en charge du logiciel des missions Apollo de la NASA, a forgé le terme « génie logiciel » parce que les programmes avaient grandi au-delà de la capacité de quiconque à les comprendre dans leur intégralité. Elle avait compris : c’est de l’ingénierie, ça a besoin de processus.

1968 : L’OTAN organisa une conférence à Berlin qui identifia formellement la Software Crisis : les ordinateurs permettaient désormais des programmes si complexes qu’ils ne pouvaient plus être gérés convenablement. Le volume de code avait dépassé la capacité humaine à raisonner dessus.

1972 : Dijkstra, dans sa leçon lors de la remise du prix Turing, résuma ainsi : « Tant qu’il n’y avait pas de machines, programmer n’était pas un problème. Quand nous avions quelques ordinateurs peu puissants, programmer devint un problème mineur. Maintenant que nous avons d’immenses ordinateurs, programmer est devenu un problème tout aussi immense. »

La réponse de l’époque fut le processus : le Waterfall comme norme DoD, puis Agile en 2001, puis CI/CD dans le cloud rendant l’Agile à l’échelle possible.

Nous sommes maintenant dans le prochain cycle. Drew Breunig, chercheur qui a popularisé le terme SDD en 2026, l’a décrit avec précision : « Notre crise logicielle actuelle est notre incapacité à gérer des bases de code complexes que les nouveaux modèles permettent de créer. Avant, le problème était que nous n’arrivions pas à garder tout le code en tête. Maintenant, nous n’arrivons même pas à lire tout notre code. »

Les agents IA permettent un volume waterfall à la cadence de l’agile. C’est le problème que le SDD tente d’adresser.

Qu’est-ce que le Spec-Driven Development

Le SDD est une méthodologie de développement qui traite la spécification comme l’artefact primaire — et non le code.

Au lieu du cycle traditionnel prompt → code → itération, le flux devient :

Spec → Plan → Tâches → Code

La spec définit l’intention, les contraintes, les critères d’acceptation et l’architecture avant toute implémentation. L’agent IA exécute ensuite à partir de cette entrée structurée plutôt qu’en interprétant une description vague.

Une distinction importante : avec des outils comme Spec Kit, Kiro et Tessl, la spec elle-même est générée par l’IA. Vous décrivez l’objectif en langage naturel, et l’agent produit les fichiers de spécification — typiquement requirements.md, design.md et tasks.md — qu’il utilisera lui-même comme contexte lors de l’implémentation. La spec n’est pas un document rédigé manuellement en amont par des analystes ; elle émerge de la conversation entre le développeur et l’agent, avant même le code.

Cela modifie le diagnostic des problèmes classiques liés aux spécifications : la distance entre spec et code n’est plus de l’ordre de semaines ni de celle entre équipes différentes. Spec et code sont générés dans le même cycle, par le même outil, à quelques minutes d’intervalle. Le problème qui persiste n’est pas la séparation temporelle — c’est le travail en amont, le coût en tokens, la dégradation du contexte au fil des itérations, et ce qui se passe après le déploiement quand la réalité diverge de ce qui avait été spécifié.

Il existe différents niveaux d’adoption du SDD :

Spec-first : la spec est générée avant l’implémentation et utilisée comme guide pour cette tâche. Une fois terminée, elle est abandonnée.

Spec-anchored : la spec est conservée après la tâche pour guider l’évolution et la maintenance future du système. C’est un artefact vivant qui accompagne le code.

Spec-as-source : le niveau le plus ambitieux. La spec est le code source. Le code généré n’est qu’un artefact compilé à partir de la spec, marqué // GENERATED FROM SPEC - DO NOT EDIT. Tessl cherche à rendre cela possible.

Le Triangle SDD — et pourquoi le cycle est plus difficile qu’il n’y paraît

La contribution la plus honnête au débat est venue de Breunig en mars 2026, après avoir construit le projet whenwords (une bibliothèque open source sans aucune ligne de code — uniquement une spec et 750 tests de conformité) et observé comment d’autres projets similaires avaient évolué.

Son enseignement central : le SDD n’est pas une équation linéaire. C’est un cycle de feedback.

Il propose le SDD Triangle : spec, tests et code sont trois nœuds qui doivent rester synchronisés en permanence. Quand le code avance, la spec doit être mise à jour. Quand la spec change, de nouveaux tests doivent être écrits. Quand les tests échouent, le code doit changer — et parfois la spec aussi était erronée.

Le problème est que maintenir ces trois nœuds synchronisés est difficile :

• Écrire des specs est difficile. Elles ne sont jamais exhaustives et sont rédigées avant que le logiciel ne rencontre le monde réel.
• Écrire des tests est difficile. Même avant les agents, personne n’aimait écrire des tests.
• Mettre à jour les specs et les tests après l’implémentation ressemble à de la surcharge, surtout quand on utilise des agents précisément pour aller vite.
• Les LLMs prennent des décisions silencieuses pendant l’implémentation. Ces décisions remontent rarement vers la spec.

Le résultat concret : la spec est rédigée, le code est généré, le produit est lancé. La spec est obsolète en quelques jours. Personne ne revient la mettre à jour. Le problème originel — intention perdue, décisions invisibles — a simplement migré de niveau.

L’écosystème d’outils

L’espace des outils SDD a explosé entre fin 2024 et début 2026. Il est utile d’en comprendre les couches :

Couche 1 — Frameworks de spec : définissent et gèrent les artefacts de spécification → Spec Kit, Tessl, Kiro, BMAD, OpenSpec, cc-sdd

Couche 2 — Systèmes de planification et de tâches : convertissent les specs en graphes de tâches exécutables → Taskmaster, Agent OS, Beads, Feature-Driven-Flow

Couche 3 — Agents d’exécution : écrivent et modifient le code → Claude Code, Cursor Agent, Codex, Devika, OpenDevin, CrewAI

Couche 4 — IDEs avec IA : intègrent toutes les couches dans un workflow unique → Kiro, Windsurf, Cursor, Claude Code, Copilot

La majorité des développeurs aujourd’hui n’utilisent que la Couche 3 — c’est exactement là que vit le problème du vibe coding.

Tableau des outils pertinents

Comment l’utiliser en pratique : Kiro comme exemple

Kiro est le point d’entrée le plus accessible pour les développeurs déjà sur VS Code. C’est un fork de Code OSS (le noyau open source de VS Code) construit par une petite équipe au sein d’AWS, délibérément positionné en dehors de l’écosystème AWS — vous n’avez pas besoin d’un compte AWS pour l’utiliser.

Installation

Rendez-vous sur kiro.dev et téléchargez l’installateur pour votre système d’exploitation. Connectez-vous avec GitHub ou Google.

Le workflow en trois étapes

Étape 1 — Exigences

Vous décrivez ce que vous souhaitez construire en langage naturel. Kiro traduit cela en notation EARS (Easy Approach to Requirements Syntax) :

WHEN usuário submete formulário de login
  AND credenciais são válidas
THEN sistema deve autenticar o usuário
  AND redirecionar para o dashboard
  AND registrar o evento de login com timestamp

Cette notation impose des contraintes explicites et lisibles par machine. Vous révisez et ajustez le requirements.md généré avant de passer à la suite.

Étape 2 — Design

Kiro analyse votre base de code existante et génère un design.md avec les décisions architecturales, les choix de stack et la structure des composants. Pour un projet React + Node.js, vous verrez quelque chose comme :

## Architecture

Frontend: React 18 com React Router v6
Backend: Express 4.x com middleware JWT
Database: PostgreSQL via Prisma ORM
Auth: bcrypt (salt rounds: 12) + JWT (access: 15min, refresh: 7d)
Testing: Jest + Supertest para integração

Vous révisez ce document avant qu’une seule ligne de code soit écrite. Les divergences avec l’architecture réelle du projet sont détectées ici — pas après 400 lignes générées.

Étape 3 — Tâches

Kiro génère un tasks.md avec des étapes d’implémentation discrètes, séquencées par dépendance :

- [ ] Task 1: Setup de banco de dados e schema de usuários
- [ ] Task 2: Endpoint POST /auth/register com validação Joi
- [ ] Task 3: Endpoint POST /auth/login com geração de tokens
- [ ] Task 4: Middleware de autenticação JWT
- [ ] Task 5: Endpoint POST /auth/refresh
- [ ] Task 6: Testes de integração para todos os endpoints

Vous contrôlez quelles tâches exécuter et à quel moment. L’agent implémente une tâche à la fois, avec des points de révision entre chacune.

Steering files

Au-delà des trois documents de spec, Kiro supporte les steering files — des fichiers de configuration persistants qui définissent des normes pour l’ensemble de la base de code :

# .kiro/steering/code-style.md
- Use TypeScript estrito, sem `any` implícito
- Prefira `async/await` sobre callbacks
- Nomes de variáveis em camelCase, constantes em SCREAMING_SNAKE_CASE
- Funções públicas devem ter JSDoc

Hooks

Kiro supporte des hooks basés sur des événements — des agents qui se déclenchent automatiquement en réponse à des déclencheurs définis :

{
  "hooks": [
    {
      "name": "security-audit",
      "trigger": "on-save",
      "agent": "Verifique vulnerabilidades de segurança no arquivo salvo"
    },
    {
      "name": "test-generator",
      "trigger": "on-file-create",
      "pattern": "src/**/*.ts",
      "agent": "Gere testes unitários para o novo arquivo"
    }
  ]
}

Ce qui fonctionne bien

• Réviser un document de design avant l’implémentation est fondamentalement différent de réviser 500 lignes de code généré après coup. Les problèmes émergent au bon niveau.
• Les steering files éliminent un volume considérable de prompts répétitifs sur le style et les conventions.
• Le flux de tâches séquentielles maintient le contexte de l’agent focalisé — un problème à la fois, pas un système entier.

Ce qui ne fonctionne pas bien

• Kiro a généré 16 critères d’acceptation pour un bug fix simple lors de tests indépendants. Pour les petits changements, la surcharge est bien réelle.
• La génération de spec pour des fonctionnalités de complexité modérée prend 30 à 45 secondes. Cela coupe dans le rythme de développement rapide.
• La notation EARS a une courbe d’apprentissage. Elle n’est pas intuitive pour quelqu’un qui n’a jamais travaillé avec des spécifications formelles.
• Kiro utilise le registre Open VSX pour les extensions (pas celui de Microsoft), ce qui signifie l’absence de support officiel pour C# — une limitation sérieuse pour les équipes .NET.
• Le mode Autopilot (exécution de plusieurs tâches sans supervision) produit des résultats moins prévisibles. La logique d’approbation par tâche est là où se trouve la vraie valeur.

Tarifs

Pendant la préversion publique : gratuit (avec des limites d’interactions). GA : Free (50 interactions/mois) · Pro 19 $/mois (1 000 interactions) · Pro+ 39 $/mois (3 000 interactions)

Les problèmes réels

1. Le travail en amont va à l’encontre de l’instinct du développeur

La promesse du SDD avec IA est que la spec est générée rapidement — et c’est effectivement le cas. Mais « rapidement » ne signifie pas « gratuitement ». Avant la moindre ligne de code utile, vous passez par plusieurs cycles de révision : vous révisez la spec générée, corrigez les intentions mal interprétées, ajustez le plan architectural, approuvez ou rejetez des tâches. Chaque cycle exige une attention humaine réelle.

Pour une fonctionnalité de complexité moyenne, cette surcharge peut être inférieure au coût de débogage d’un code vibe-coded après coup. Pour un bug fix ponctuel, le coût dépasse le bénéfice de loin — Kiro a généré 16 critères d’acceptation pour une correction simple lors de tests indépendants. Le travail en amont ne disparaît pas parce que l’IA génère la spec ; il change de nature. Au lieu d’écrire, vous révisez et décidez. C’est moins coûteux, mais ce n’est pas nul.

2. Le coût en tokens multiplié à chaque phase

Chaque phase du SDD (spec → plan → tâches → implémentation) consomme des tokens avant qu’une seule ligne de code de production soit écrite. Avec les modèles de raisonnement, l’usage agentique peut être 100 fois plus élevé que l’usage standard.

Les sessions intensives de SDD avec Claude Code atteignent régulièrement la limite de contexte. Le processus de compactage automatique prend entre 3 et 12 minutes. Le coût n’est pas seulement financier — il est aussi en temps et en interruption de flux. Aucun benchmark public ne compare le coût total (tokens + temps de révision humaine) du SDD par rapport au développement direct.

3. La dégradation du contexte au fil des itérations

C’est le problème le moins discuté et peut-être le plus sérieux. Les specs générées par IA sont réinjectées dans l’IA lors de la phase d’implémentation. Chaque cycle de compactage ou redémarrage de session perd des nuances. L’agent qui implémente le code n’a pas accès plein aux décisions que l’agent de spécification avait enregistrées.

Le résultat : le code commence à dériver subtilement de la spec au fur et à mesure que le contexte se dégrade. La boucle entre spec et code, qui devrait être synchrone, devient une série de téléphones arabe — chaque phase amplifie les petits bruits de la phase précédente.

4. Les specs deviennent trompeuses après le déploiement

Avec les outils modernes de SDD, la spec n’est pas « loin du code » — elle est générée dans le même cycle, par le même outil, quelques minutes avant l’implémentation. Le problème classique des spécifications rédigées par des analystes déconnectés de la réalité technique ne s’applique pas ici.

Le problème qui persiste est différent : ce qui se passe après le déploiement. Les cas limites n’apparaissent qu’en production. Le comportement réel des utilisateurs diverge de celui qui avait été modélisé. Les problèmes de performance émergent sous charge. La spec n’est pas mise à jour. Si elle est utilisée pour guider la maintenance et l’évolution future (spec-anchored), une spec obsolète devient activement trompeuse : l’agent s’y fie, génère du code basé sur une réalité qui n’existe plus, et le développeur ne s’en rend compte que lorsque le système tombe en panne.

L’outil Plumb de Breunig tente d’y remédier : un CLI qui se connecte à git commit, lit les traces de l’agent, extrait les décisions prises pendant l’implémentation et demande l’approbation du développeur avant de mettre à jour la spec. C’est un PoC, pas de la production — mais ça pointe dans la bonne direction.

5. La prolifération d’artefacts sans véritable curation

Chaque fonctionnalité génère plusieurs fichiers markdown. La promesse implicite que « l’agent maintient la spec à jour » ne tient pas — quelqu’un doit réviser chaque modification de la spec avec la même rigueur qu’il révise le code. En pratique, cela n’arrive pas. Les specs s’accumulent, divergent du code, et deviennent du bruit plutôt que du signal.

6. Les spécifications n’éliminent pas le non-déterminisme

Une même spec peut produire des implémentations différentes selon les exécutions. Une plus grande précision réduit la variation mais augmente le coût de rédaction. Et les specs mal rédigées — le résultat le plus probable quand la méthodologie est nouvelle pour l’équipe — produisent du code bien organisé qui fait la mauvaise chose.

7. Le risque du waterfall avec l’IA dans la boucle

La critique la plus structurelle vient de Thoughtworks et d’analyses indépendantes : le SDD tel qu’il est pratiqué actuellement risque d’être du waterfall avec l’IA dans la boucle. Vous définissez encore tout en amont et espérez que la réalité coopère. Pour le développement exploratoire avec des exigences genuinement inconnues, les approches orientées contexte s’adaptent mieux.

Quand il est pertinent de l’utiliser

Le SDD dans sa forme actuelle est pertinent pour :

• Les équipes enterprise développant sur de grandes bases de code existantes où la dérive architecturale est coûteuse
• Les environnements réglementés où les pistes d’audit et la traçabilité des exigences sont obligatoires (EU AI Act, secteur financier, santé)
• Les domaines stables avec des contrats clairs : APIs, schémas de données, règles de conformité
• Les équipes maîtrisant TDD ou BDD qui souhaitent étendre cette discipline à la couche IA
• L’émulation et la portabilité : le cas d’usage où le SDD brille le plus est la réimplémentation d’un système existant dans un autre langage, en utilisant les tests du système d’origine comme spécification

Le SDD est probablement excessif pour :

• Les projets solo et les prototypes rapides
• Le développement exploratoire où les exigences sont genuinement inconnues
• Les petites corrections ou les bugs isolés
• Les équipes sans la discipline de maintenir les specs à jour après l’implémentation

Le diagnostic honnête

Le SDD est une réponse légitime à un problème réel. Le vibe coding génère du code plus vite que les équipes n’arrivent à le gouverner. Les spécifications sont un outil pour restaurer cette gouvernance.

Mais le parallèle avec le TDD est instructif. Le TDD a 25 ans, dispose d’une preuve empirique extensive, et l’adoption réelle sur le marché tourne autour de 8 % au sens strict (écrire les tests avant le code, de façon consistante). Le SDD génère du hype parce qu’il résout un problème visible de l’ère des agents, mais il hérite du même défi fondamental : les développeurs préfèrent livrer. Toute méthodologie qui ajoute du travail en amont va lutter contre cet instinct.

L’absence de critique publique facile à trouver est elle-même un signal. Quand les bénéfices sont triviaux à trouver et les compromis ne le sont pas, une méthodologie est encore dans sa phase de marketing, pas de maturité. Le Spec-Driven Development n’a pas encore payé ce ticket d’entrée.

Les outils à suivre : Spec Kit pour sa flexibilité open source et son indépendance vis-à-vis des IDEs, Kiro pour ses workflows structurés en IDE, Tessl pour la vision la plus ambitieuse de spec-as-source (encore non prouvée), et Plumb comme référence du problème le plus difficile et non résolu — maintenir les specs vivantes après l’implémentation initiale.

Références

• The Rise of Spec Driven Development — Drew Breunig
• The Spec-Driven Development Triangle — Drew Breunig
• Spec-Driven Development Is Eating Software Engineering — Vishal Mysore
• Spec-Driven Development: Unpacking 2025’s key new practice — Thoughtworks
• Spec-Driven Development: When Architecture Becomes Executable — InfoQ
• Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl — Martin Fowler’s blog
• The Limits of Spec-Driven Development — Isoform
• GitHub Spec Kit
• Kiro IDE
• Tessl
• Measuring AI Impact on Experienced Developer Productivity — METR, 2025