Spec-Driven Development en 2026 : trois pratiques sous le même nom

Le Spec-Driven Development est partout en 2026. Conferences, threads LinkedIn, articles d’opinion : tout le monde semble avoir un avis. Mais derriere le buzz, trois pratiques radicalement differentes se font passer pour la meme chose, avec des promesses, des couts et des risques qui n’ont rien a voir.

Birgitta Bockeler (Thoughtworks) a clarifie le paysage en distinguant trois niveaux. Cet article resume ce qu’elle decrit, ajoute six mois de notre propre experience a livrer du code client avec ces approches, et conclut sur ce qui vaut vraiment la peine, ce qui est de l’over-engineering, et comment integrer juste ce qu’il faut dans Claude Code sans tomber dans la spec-mania.

Si vous evaluez Spec-Kit, Kiro ou un simple SPEC.md pour votre equipe, voici ce que vous devriez retenir avant de prendre votre decision.

Spec-first, spec-anchored, spec-as-source : trois philosophies expliquees

La distinction de Bockeler est utile parce qu’elle met le doigt sur ce qui change vraiment d’un outil a l’autre : ce n’est pas le format de la specification, c’est son role dans le cycle de vie du code.

Spec-first : la spec est l’input du processus. On redige une intention detaillee (un PRD, une user story enrichie, un cahier des charges leger), l’agent IA s’en sert pour planifier, puis pour generer le code. Une fois le code ecrit, la spec devient un artefact de reference, souvent abandonne dans un coin du repo. C’est l’approche de GitHub Spec-Kit. Benefice : demarrage cadre. Risque : la spec devie rapidement de la realite du code livre.

Spec-anchored : la spec est un contrat vivant. Elle est mise a jour quand le code change, et l’agent la consulte a chaque session pour rester aligne. C’est ce que vise Amazon Kiro avec sa structure steering folder + spec. Benefice : moins de derive, l’agent garde le contexte. Cout : il faut maintenir activement la spec, ce qui ajoute une charge cognitive non triviale.

Spec-as-source : la spec est la source de verite, le code devient un artefact compile qu’on regenere a partir d’elle. Tessl Framework parie la-dessus. Benefice theorique : zero derive, tracabilite parfaite. Realite : on herite de toutes les pathologies du Model-Driven Development des annees 2000, plus la couche d’incertitude des LLMs.

Le paper arXiv Spec-Driven Development: From Code to Contract in the Age of AI (fevrier 2026) formalise ces trois niveaux comme un spectre, pas comme des cases. C’est une lecture utile pour comprendre ou chaque equipe peut se positionner sans s’enfermer dans un dogme.

GitHub Spec-Kit : la spec-first orchestree

GitHub Spec-Kit est l’outil le plus visible aujourd’hui parce qu’il est porte par GitHub, donc par defaut sur des millions de repos via Copilot. Son principe : un workflow en trois etapes (specify, plan, tasks), une constitution qui definit les principes immuables que l’agent doit respecter, et des prompts configurables pour chaque etape.

Concretement, vous lancez la commande, l’agent vous fait preciser l’intention, puis genere un plan technique, puis le decoupe en taches. A chaque transition, vous validez. Le resultat : une feature demarree avec un cadre clair, et un historique de decisions documente.

La ou Spec-Kit brille : demarrer une feature de zero avec une equipe qui ne connait pas le domaine, ou un agent qui doit travailler en autonomie sur plusieurs heures. La ou il peche : la maintenance. Une fois la feature livree, qui met a jour la spec ? La reponse honnete : presque personne. Les fichiers spec deviennent des fossiles dans le repo, et les nouvelles features partent d’un nouvel elan, pas de l’historique.

Amazon Kiro : la spec comme contrat vivant

Kiro (Amazon) prend l’angle inverse. La spec n’est pas un livrable de demarrage, c’est un referentiel permanent. La structure steering folder centralise les conventions du projet (style de code, patterns architecturaux, vocabulaire metier), et chaque feature a sa propre spec qui reste synchronisee avec le code au fil des modifications.

Le pari de Kiro : si la spec est toujours a jour, l’agent IA n’a pas besoin de redecouvrir le contexte a chaque session. Il lit le steering folder, ouvre la spec de la feature, et travaille avec une comprehension aussi fine qu’un humain qui aurait participe au projet depuis le debut.

En pratique, ca fonctionne quand l’equipe accepte la discipline de mise a jour. Quand un developpeur fait un fix rapide sans toucher la spec, le contrat est rompu, et le prochain agent qui ouvre la feature recoit une information perimee. Kiro est puissant pour les bases de code regulees (sante, finance, defense) ou la tracabilite est obligatoire de toute facon. Pour une PME qui pivote tous les trimestres, la maintenance peut devenir un goulot.

Du Assess au harness engineering

Cote Thoughtworks, le Technology Radar Vol. 33 de novembre 2025 a classe SDD en Assess : a surveiller, pas pret pour adoption generalisee. Le verdict etait prudent : interessant, mais trop d’inconnus sur la maintenance et le cout cognitif.

Six mois plus tard, le Radar d’avril 2026 (Vol. 34) a fondu SDD dans un concept plus large : le harness engineering. L’idee : ne plus voir SDD comme une pratique isolee, mais comme un des leviers (avec Agent Skills, le mutation testing, le context engineering) pour construire un harnais autour de l’agent qui le force a livrer du code fiable sans supervision constante.

Le shift est important : on passe de comment ecrire la bonne spec a comment outiller l’agent pour qu’il echoue de facon visible et corrige tout seul. C’est la meme logique que les agents IA qui appellent des APIs au lieu de cliquer sur des boutons : la valeur n’est plus dans l’interface ou la spec elle-meme, elle est dans le harnais qui les rend fiables. ⚙️

Verdict honnete : ou SDD apporte vraiment de la valeur

Apres six mois a utiliser ces approches sur du code client (refontes WordPress, integrations e-commerce, automatisations metier), notre lecture est nette :

Vraie valeur :

• Features multi-fichiers qui touchent plusieurs couches (modele, controleur, vue, tests). La spec force a penser le contrat avant de plonger dans le code.
• Sessions longues d’un agent autonome (overnight runs, batch de migration). Sans spec, l’agent derive.
• Codebases auditees ou chaque decision doit etre tracable. La spec devient une preuve d’intention.
• Onboarding d’un nouveau developpeur ou d’un nouvel agent. La spec est le resume que la documentation ne fournit jamais.

Over-engineering pur :

• Bug fix de dix lignes : ecrire une spec pour ca, c’est doubler le temps de la fix.
• Spike jetable pour valider une hypothese : la spec n’est pas l’artefact, le code lui-meme l’est.
• Domaine deja maitrise par l’equipe : la boucle test, review, merge est plus rapide que la boucle spec, review, code, merge.
• Boucle de feedback courte : si vos tests tournent en deux minutes, la spec ralentit.

La matrice de Bockeler resume bien : SDD apporte de la valeur quand le probleme est complexe et clair. Quand c’est petit ou flou, c’est de la friction.

Conseil pratique pour Claude Code

Pour Claude Code specifiquement, pas besoin d’un framework a dix-sept fichiers. Un seul SPEC.md leger a la racine du dossier de la feature suffit, avec quatre sections :

• Objectif : une phrase qui dit ce que la feature accomplit pour l’utilisateur.
• Contraintes : ce qu’on ne peut pas casser (compatibilite, performances, securite).
• Criteres d’acceptation : 3-5 cas concrets, observables, testables.
• Hors-scope : ce qu’on ne fait pas dans cette iteration, et pourquoi.

L’agent le lit a chaque run, vous l’editez ensemble quand le scope evolue, il vit avec le code dans le meme PR. Pas d’outillage externe, pas de constitution, pas de steering folder. Juste un fichier qui force a clarifier l’intention avant d’ecrire la premiere ligne.

Questions frequentes

Faut-il adopter Spec-Kit, Kiro ou rester sur un SPEC.md leger ?

Ca depend du contexte. Spec-Kit pour demarrer une feature de zero avec une equipe ou un agent qui ne connait pas le domaine. Kiro pour des codebases ou la tracabilite est obligatoire (regule, audit). Un SPEC.md simple pour la majorite des PME et des projets agiles. Commencez par le plus leger, montez en complexite seulement si vous sentez le besoin.

Le Spec-Driven Development ralentit-il la livraison ?

Sur les petites features, oui. Sur les features complexes ou multi-fichiers, il accelere parce qu’il evite le va-et-vient avec l’agent. Mesurez sur trois sprints avant de juger.

Est-ce compatible avec Claude Code ?

Parfaitement. Claude Code lit n’importe quel fichier markdown dans le repo. Un SPEC.md a la racine du dossier de la feature est tout ce dont il a besoin pour rester aligne sur l’intention.

Le Spec-Driven Development bien fait, c’est documenter juste assez pour donner un cap a l’agent, sans transformer chaque feature en projet de spec. La discipline n’est pas dans le format, elle est dans la decision quotidienne d’arreter d’ecrire quand la spec a rempli son role.

Et vous, ou placez-vous le curseur entre Spec-Kit, Kiro et un simple SPEC.md ?

Lecture liee : notre analyse precedente sur la fin de l’interface et l’arrivee des agents IA, le contexte plus large dans lequel s’inscrit le SDD. Et nos services d’IA et d’automatisation si vous voulez integrer ces approches dans votre stack.

Sources : Birgitta Bockeler, SDD: 3 Tools Compared · Post de Martin Fowler · Paper arXiv Spec-Driven Development: From Code to Contract in the Age of AI (fev. 2026) · Thoughtworks Technology Radar Vol. 33 et avril 2026.