Quand le spec-driven development est-il utile ?

Qu’est-ce que le spec-driven development ?

Quand vous confiez une tâche à un agent de codage, vous expliquez le plus souvent ce que vous voulez dans le chat. Si cela ne vit que dans le chat, cela disparaît à la fermeture de la session. Le spec-driven development (SDD) écrit cette intention dans un fichier avant le code. La spec, pour spécification, est le document qui dit ce que l’agent va faire et pourquoi. L’agent écrit d’abord la spec, puis un plan technique qui dit comment faire, puis une liste de tâches. Il produit le code en dernier, en s’appuyant sur ces documents.

Dans l’article de septembre 2025 qui annonçait Spec Kit, GitHub résume l’idée en une phrase : « We’re moving from “code is the source of truth” to “intent is the source of truth.” » Autrement dit, ce qui est juste n’est plus décidé par le code, mais par l’intention écrite. Le même article dit aussi ce qui revient au développeur : « Crucially, your role isn’t just to steer. It’s to verify. » Cet article-ci porte sur cette deuxième phrase.

Ce que devient la spec une fois le travail terminé dépend de l’approche. Les trois niveaux de l’article d’octobre 2025 dans lequel Birgitta Böckeler, de Thoughtworks, a essayé trois outils de SDD figurent aujourd’hui aussi dans la documentation de Spec Kit :

• Spec-first. La spec est écrite avant le code ; une fois le travail fini, on peut la jeter.
• Spec-anchored. La spec est conservée après le travail et sert pour les changements suivants.
• Spec-as-source. Les humains ne modifient que la spec ; le code est généré à partir d’elle et jamais modifié à la main.

Selon Böckeler, toutes les approches qu’elle a trouvées sont spec-first ; la façon d’entretenir la spec dans le temps reste souvent floue. Comme nous le verrons plus bas, c’est précisément ce flou qui complique le plus la revue de code.

Notre principale source sur l’usage réel est l’étude Spec-Driven Development as Prescribed and as Practiced, menée par des chercheurs de l’université Carnegie Mellon et de Google. Sa dernière version sur arXiv date du 15 octobre 2026. L’étude s’appuie sur des discussions Reddit, des entretiens avec 21 praticiens (dont 8 développent des outils) et 266 dépôts sur GitHub. Les deux pourcentages ci-dessus viennent aussi de cette étude.

Nous avons présenté les fichiers de règles des agents de codage dans l’article sur AGENTS.md et CLAUDE.md, et la façon d’examiner une pull request écrite par l’IA dans un article à part. Celui-ci place la spec entre les deux.

Par quelles étapes passe-t-on de la spec au code ?

Les outils ne donnent pas les mêmes noms aux étapes, mais l’ordre est le même : d’abord ce qu’il faut faire, puis comment le faire, puis les tâches, et le code en dernier. À la fin de chaque étape, vous relisez le document et le corrigez ; l’agent passe à l’étape suivante avec cette version.

Dans Spec Kit, on lance /speckit.constitution une fois par projet, puis, pour chaque fonctionnalité, specify, plan, tasks, implement et converge, dans cet ordre. La constitution contient les principes du projet, et chaque étape suivante est évaluée par rapport à eux ; elle ressemble au fichier de règles d’un agent de codage. clarify, checklist et analyze sont des contrôles de qualité facultatifs, à ajouter quand la tâche comporte des zones floues.

Dans Kiro, chaque spec se compose de trois fichiers : requirements.md, design.md et tasks.md. Les exigences s’écrivent selon un modèle appelé EARS : « WHEN [condition] THE SYSTEM SHALL [comportement attendu] ». L’ordre est exigences, conception, tâches ; si vous avez déjà une architecture en main, vous pouvez aussi commencer par la conception. Les fichiers de règles de Kiro se trouvent dans le dossier .kiro/steering/, et Kiro lit aussi le fichier AGENTS.md à la racine du dépôt.

OpenSpec range chaque changement dans un dossier à part : sous openspec/changes/<changement>/ se trouvent la justification (proposal.md), les exigences (specs/), une conception si besoin (design.md) et les tâches (tasks.md). Le cycle comprend exploration, proposition, revue, application et archivage. La spec d’un changement n’écrit que la différence : quelle exigence a été ajoutée, modifiée, supprimée ou renommée. À l’archivage, ces différences sont reportées dans les specs principales sous openspec/specs/ ; les specs principales décrivent l’état actuel du système. Voici un exemple de fichier delta tiré du README d’OpenSpec :

## ADDED Requirements

### Requirement: Theme selection
The app SHALL let users switch between light and dark themes,
defaulting to the system preference.

#### Scenario: User toggles dark mode
- **WHEN** the user clicks the theme toggle
- **THEN** the app switches to dark mode and persists the choice

Ce fichier delta est la partie la plus utile en review : dans une pull request, il montre d’un coup d’œil où l’intention a changé. Nous y reviendrons plus bas.

Quelle différence entre Spec Kit, Kiro et OpenSpec ?

Nous avons lu la documentation des trois outils le 18 octobre 2026. Le tableau montre les fichiers que chaque outil écrit, ce qu’il vérifie une fois le travail fini et ce qu’il propose pour les petites tâches :

Source : la documentation de chaque outil, 18 octobre 2026. L’écriture des commandes dépend de l’agent de codage que vous utilisez (par exemple /speckit.plan ou /speckit-plan). Selon la documentation de Kiro, les tests property-based ne fonctionnent que dans l’IDE. Dans Kiro, vous pouvez aussi faire analyser les exigences avant la conception pour y chercher incohérences et lacunes.

Les trois ne s’utilisent pas au même endroit. Spec Kit est une boîte à outils open source qui s’ajoute à votre agent de codage sous forme de commandes ou de skills. OpenSpec s’ajoute lui aussi aux outils que vous utilisez déjà ; son README annonce la prise en charge de 30+ outils. Kiro, lui, est un agent de codage doté de son propre IDE, d’une CLI et d’une interface web. Le README d’OpenSpec dit de Kiro qu’il est « limited to Claude models » ; la page des modèles de Kiro cite pourtant, au 18 octobre 2026, GPT-5.6 et des modèles à poids ouverts. Ce qu’un outil dit d’un concurrent mérite d’être vérifié dans la documentation du concurrent lui-même.

En 2025, cette liste comptait un nom de plus : Tessl. Böckeler l’avait essayé à côté de Kiro et de Spec Kit. En septembre 2025, Tessl a présenté ses premiers produits comme fondés sur le spec-driven development : un Spec Registry en bêta ouverte et le Tessl Framework en bêta fermée. Sa documentation actuelle décrit en revanche Tessl comme « an open platform for managing agentic development across your organization » et ne parle pas de spec-driven development. La méthode existe aujourd’hui sous la forme d’un plugin public dans le registry de Tessl. Nous n’avons pas trouvé de page récente qui dise où en est le Tessl Framework aujourd’hui.

Deux autres méthodes open source travaillent avec des specs. Dans Superpowers, l’agent commence par vous poser des questions pour cerner ce que vous voulez ; les petits changements se décident dans le chat, les projets ont droit à un document de conception écrit. Pendant l’implémentation, qui s’appuie sur des sous-agents, chaque tâche est examinée en deux temps : d’abord la conformité à la spec, puis la qualité du code. BMAD Method dit que son processus s’adapte à la taille du travail : les petits changements passent directement à la réalisation.

Pourquoi parle-t-on d’un « nouveau waterfall » ?

Le waterfall, ou modèle en cascade, est l’approche qui conçoit le travail à l’avance et enchaîne les phases dans un ordre strict : pas de conception tant que les exigences ne sont pas écrites et validées, pas de code tant que la conception n’est pas finie. Pour ses critiques, le spec-driven development ramène cet ordre avec des fichiers markdown. Deux articles le disent dès leur titre : « The Waterfall Strikes Back » et « Reinvented Waterfall? ». Mais ce que ces critiques ont en commun, c’est moins l’ordre des phases que la charge de review.

Thoughtworks, octobre 2025. Böckeler a demandé à Kiro de corriger un petit bug. Le document d’exigences a transformé ce petit bug en 4 user stories totalisant 16 critères d’acceptation. Quand elle a essayé Spec Kit sur une fonctionnalité plus grande, elle a aussi trouvé les fichiers markdown à lire trop nombreux pour la taille du travail : « To be honest, I’d rather review code than all these markdown files. » Malgré tous ces fichiers, écrit-elle, elle a aussi souvent vu l’agent ne pas suivre toutes les instructions.

Scott Logic, novembre 2025. Colin Eberhardt a supprimé une fonctionnalité de son application de loisir, l’a fait reconstruire avec Spec Kit et a noté le temps passé à chaque étape. Il a construit la fonctionnalité en deux étapes : d’abord les écrans de gestion des circuits, puis le GPS. La première étape a produit 2 577 lignes de markdown et 689 lignes de code, dont la lecture et la review ont pris 3,5 heures ; la seconde, 2 262 lignes de markdown et environ 300 lignes de code, pour environ 2 heures de review. Quand il a construit la même fonctionnalité sans spec, à sa manière habituelle, il y a passé 24 minutes au total : 15 minutes de revue de code et 9 minutes de test. C’est la mesure d’Eberhardt lui-même : un seul développeur, une seule application de loisir, Spec Kit tel qu’il était en novembre 2025 ; l’étape converge n’apparaît pas dans cet article.

La différence n’est pas dans le code : sans spec, le code des deux étapes faisait environ 1 000 lignes au total. C’est le markdown qui a pris le temps. Eberhardt écrit qu’il était environ 10 fois plus rapide sans spec, et conclut : « For now, the fastest path is still iterative prompting and review, not industrialised specification pipelines. » C’est l’expérience d’un seul développeur sur une seule application, pas une mesure générale.

Marmelab, novembre 2025. Selon François Zaninotto, la spec technique contient déjà du code. Le développeur lit ce code avant de l’exécuter et, comme il y aura quand même des bugs, il lit aussi le code final : « As a result, review time doubles. » Dans l’exemple qu’il montre, l’agent avait marqué la tâche « verify implementation » comme terminée sans écrire un seul test unitaire.

Thoughtworks Technology Radar, novembre 2025. Le Radar a placé la méthode dans l’anneau « Assess » et a écrit que certains outils produisent « lengthy spec files that are hard to review ». Sa note se termine par cette phrase : « We may be relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn’t scale. » Cette note ne figure pas dans l’édition actuelle du Radar.

Toutes ces critiques parlent de la charge de review : plus de markdown à lire que de code, la même chose lue deux fois, un agent qui ne suit pas ce qui est écrit. Et toutes ont été écrites à l’automne 2025, sur les outils tels qu’ils étaient alors ; Böckeler note elle-même que les outils évoluent très vite.

Que voient différemment ceux qui le défendent ?

Meg Kretz, d’Atomic Object, dit dans son article de mai 2026 que la ressemblance est dans le document et la différence dans les comportements : « The difference comes down to four behaviors, which are observable, not philosophical. » Pour elle, le waterfall se sert des documents comme d’une porte : on les écrit, on les valide, on les fige, on les transmet. En spec-driven development, le document est au contraire un outil de travail, écrit et réécrit avec le code. Voici les quatre comportements qu’elle cite :

• Quand la spec change-t-elle ? Le jour où arrive une nouvelle information, souvent dans l’heure.
• Comment la conception et la spec avancent-elles ? L’une n’attend pas l’autre ; elles avancent ensemble, chacune modifiant l’autre.
• Quand le travail est-il fini ? Les exigences Must/Should/May de la spec sont les critères d’acceptation ; quand elles sont remplies, le travail est fini.
• Qui modifie la spec ? Le développeur qui bute sur une ambiguïté corrige la spec sur-le-champ ; la correction est commitée avec le code.

Ce que Kretz appelle le « test opérationnel » est, pour la review, le point central de cet article : la spec et le code sont commités dans la même pull request. « If specs lag code, the spec is documentation, not source of truth. »

Les praticiens font eux aussi état de gains, mais avec prudence. La plupart des participants de l’étude de Carnegie Mellon disent que les specs rendent le travail de l’agent plus fiable, mais ils ne peuvent pas séparer ce gain des progrès des modèles sur la même période. Une équipe qui a utilisé la méthode pendant des mois a écrit qu’elle ne pouvait pas prouver qu’elle avait amélioré le code. Selon l’étude, le SDD ne supprime pas le coût : il déplace les tokens, le temps et la charge mentale de l’implémentation vers la planification.

Les outils aussi ont changé depuis ces articles. Spec Kit a ajouté en juin 2026 une extension facultative de correction de bugs et a documenté, en juin 2026 également, comment conserver les specs une fois le travail terminé. La documentation de Kiro propose aujourd’hui Quick Spec, sans étape de validation, et le mode Plan, qui n’écrit aucun fichier. Kiro décrit ainsi l’un des cas où il recommande Quick Spec : « You've been defaulting to Vibe mode because the standard Spec flow felt too heavy ».

Quand est-il utile, et quand devient-il un fardeau ?

Le résultat de l’étude de Carnegie Mellon est net : la plupart des praticiens n’utilisent pas le SDD pour toutes les tâches, mais selon leur taille. Ils s’en passent pour les petites tâches, les bugs et les scripts ponctuels. Pour un correctif urgent en production, un participant dit : « there is no time for spec-driven development and the whole flow ». D’autres décident selon le risque : si une erreur coûte cher et que l’intention est claire, ils écrivent une spec.

Les traces laissées dans les dépôts vont dans le même sens. Les chercheurs ont fait étiqueter par un modèle de langage un échantillon de 1 000 specs ; selon leur estimation, 82,0 % des specs décrivent une nouvelle fonctionnalité. La documentation des outils fait la même distinction :

La marche du milieu compte. Kiro recommande le mode Plan pour les tâches de 15 à 60 minutes, pour lesquelles une spec formelle serait de trop. Le plan reste dans le chat et aucun fichier de spec n’entre dans le dépôt ; il n’y aura donc pas non plus de document par rapport auquel examiner le code plus tard. Pour une petite tâche, ce n’est pas un problème : vous examinez cette pull request comme d’habitude, à partir du diff et de la description.

Pour les corrections de bugs, Spec Kit propose une voie à part : diagnostic, correction et vérification restent séparés, et une correction non vérifiée ne compte pas comme une réussite. Kiro, lui, juge suffisante une correction rapide dans le chat pour une faute de frappe ou un changement d’une ligne bien compris.

Comment le code et la spec divergent-ils avec le temps ?

La plupart des participants de l’étude de Carnegie Mellon ont raconté que le code et la spec s’étaient éloignés l’un de l’autre. Les chercheurs distinguent deux façons dont cela arrive et leur donnent un nom : implementation drift (le code s’écarte de la spec) et spec decay (la spec devient obsolète). Leur exemple est la durée pendant laquelle une session reste ouverte :

Dans les deux cas, le code dit 60 minutes et la spec 30 minutes ; un outil qui compare le code et la spec voit les deux cas de la même façon. Ce qui fait la différence, c’est lequel des deux a tort. L’étude l’écrit clairement : des reviews planifiées par des agents ou des tests de bout en bout dans la CI peuvent montrer que le code et la spec ne concordent pas, mais pas lequel a tort. C’est au propriétaire de l’intention d’en décider.

L’implementation drift se produit dans la pull request où le code est écrit. L’étude recommande aux créateurs d’outils de transformer les critères d’acceptation en tests que l’agent doit réussir ; le fait que Kiro génère des tests property-based à partir de ses exigences EARS en est un exemple. Le spec decay se produit plus tard, dans une autre pull request : un changement qui modifie un comportement ne touche pas à la spec qui décrit ce comportement. L’étude l’observe surtout dans les specs vivantes (living specs), quand un changement touche aussi un comportement décrit par d’autres specs.

Les contrôles intégrés aux outils interviennent en fin de travail. L’étape converge de Spec Kit compare le code à la spec, au plan et aux tâches de la fonctionnalité, et se contente d’ajouter les tâches manquantes ; après un résultat « Converged », la documentation vous oriente vers la review ou l’ouverture d’une pull request. L’étape verify d’OpenSpec compare le code aux documents du changement avant l’archivage et se contente d’un rapport. Dans Kiro, vous pouvez demander dans le chat, avec #spec, si le travail remplit ses critères d’acceptation, et faire cocher les tâches terminées avec Sync Files.

Tous ces contrôles sont lancés par l’agent de codage qui a fait le travail ; la documentation que nous avons lue ne dit pas si le contrôle doit être fait par un autre modèle ou dans une session séparée. L’étude écrit aussi qu’elle n’a pas pu établir si l’un de ces outils vérifie, une fois le travail terminé, que la spec et le code concordent toujours. La documentation de Spec Kit nomme le risque : « The main risk is silent divergence. »

Comment examiner le code par rapport à sa spec ?

Nous avons décrit dans un article à part les étapes générales pour examiner une pull request écrite par l’IA : fait-elle ce que dit la description ? qu’a-t-elle changé qu’elle n’aurait pas dû ? les tests testent-ils vraiment quelque chose ? Dans une équipe qui travaille avec des specs, quelques questions propres à la spec s’y ajoutent :

La spec et le code doivent être dans la même pull request. Spec Kit recommande d’examiner ensemble le code et les changements de documents, et OpenSpec de commiter le dossier du changement avec le code. Si la spec arrive dans une pull request séparée, ou n’arrive pas du tout, vous ne pouvez pas voir si l’intention a changé.

Lisez d’abord le diff de la spec. OpenSpec dit que specs/ est ce qu’il y a de plus utile à lire quand on relit le plan, et pose une seule question : « Would you accept these requirements as done? » Dans une pull request, vous posez cette question au diff : quel critère d’acceptation a été ajouté, lequel a changé, lequel a été supprimé. L’étude recommande aussi aux outils de montrer les changements de critères d’acceptation sous forme de diff. Vous lisez le code par rapport à la nouvelle spec qu’apporte la pull request, et le changement de spec par rapport à son ancienne version sur la branche cible. Les tests et les outils peuvent vérifier si le code correspond à la spec ; seul le propriétaire de l’intention peut dire si le changement de spec est juste.

Une personne doit écrire ou valider les critères d’acceptation. L’étude le recommande directement : « Practitioners should write or approve acceptance criteria even when agents produce the rest. » Vous n’avez pas besoin de lire toute la spec avec le même soin ; selon l’étude, l’énoncé du problème, les décisions clés et les critères d’acceptation expriment l’intention, le reste est du contexte pour l’agent. Les participants qui fixaient les critères d’acceptation ou relisaient les tests de l’agent n’ont pas cité la vérification comme un problème ; les chercheurs ajoutent qu’ils ne peuvent pas montrer que cela a évité des défauts.

Chaque critère doit avoir un test. Une case cochée dans la liste de tâches n’est pas un test : dans l’exemple de Zaninotto, l’agent avait clos la tâche de vérification sans écrire de test. Associez chaque critère d’acceptation à un test. Un critère sans test est une promesse sans rien derrière dans le code.

Le contrôle ne doit pas être fait par l’agent qui a fait le travail. Selon l’étude, quand un seul agent écrit la spec, le code et les tests, un seul malentendu peut se retrouver dans les trois ; c’est pourquoi certains participants disent « an agent must not review its own implementation ». Spec Kit trace la même limite pour ses propres checklists : l’étape d’implémentation ne doit pas les valider d’elle-même. L’étude dit aussi ce que coûte le fait de laisser entièrement la review de la spec à un agent : « Delegating spec review to an agent removes the one point where a person decides what the system should do. »

Vérifiez qu’aucune autre spec n’a été cassée. C’est souvent là que commence le spec decay. Selon l’étude, un agent qui modifie une fonctionnalité peut ajouter un comportement qui remplit la tâche en cours et passe ses tests, mais enfreint une contrainte d’une spec plus ancienne. Si d’autres specs décrivent le comportement modifié, elles doivent elles aussi être mises à jour dans la même pull request.

Dans les traces des dépôts open source, les humains apparaissent peu à ces étapes. Dans l’échantillon de 266 dépôts de l’étude, 98,3 % des 36 888 fichiers de spec dont l’historique est enregistré n’ont qu’un seul auteur, et 68,5 % des 1 731 commentaires en ligne sur des specs ont été écrits par des bots. Pour reprendre les mots des chercheurs, le deuxième lecteur d’une spec, s’il existe, est généralement un bot. Ces chiffres ne montrent pas avec quelle attention les humains lisent les specs, ni si la review se fait ailleurs ; ils montrent seulement que peu de participation humaine est enregistrée.

Qu’est-ce qu’un outil de review voit de la spec ?

diffox est un outil de revue de code composé de 17 agents spécialisés. Il ne lit pas les dossiers de specs (specs/, .kiro/specs/, openspec/) ; il apporte deux textes à la review. Le premier est le fichier de règles à la racine du dépôt : il cherche d’abord AGENTS.md et, à défaut, CLAUDE.md. Il lit ce fichier non pas dans la branche de la pull request, mais dans la branche où elle sera mergée, tel qu’il était au point où la branche s’en est séparée ; une pull request qui modifie le fichier de règles est donc examinée selon les anciennes règles jusqu’à son merge.

diffox ne garde du fichier de règles que les phrases qui expriment une obligation (comme « must », « never », « doit », « jamais ») et les donne aux agents de la review comme les règles qui définissent ce qui compte comme une erreur. L’un des agents, House Rules Agent, cherche parmi les lignes modifiées celle qui enfreint l’une de ces règles, et n’invente aucune règle absente de la liste. Le second texte est la description de la pull request : elle entre elle aussi dans le contexte que lisent les agents.

Pour une équipe qui travaille avec des specs, cela veut dire que les obligations que vous voulez voir vérifiées dans chaque pull request ont leur place dans le fichier de règles. Une phrase comme « Every database migration must include a rollback plan. », tirée de l’exemple de constitution que Spec Kit donne pour les projets existants, sert de règle dans la review si elle figure dans le fichier de règles ; en revanche, diffox ne lit pas le fichier de constitution de Spec Kit sous .specify/memory/. Écrivez aussi dans la description de la pull request quelle spec vous avez implémentée et quels critères d’acceptation ont changé ; la personne qui fait la review lit la même description.

Par où commencer dans votre projet ?

Plutôt que d’étendre la méthode à tout le dépôt d’un coup, commencez petit :

1. Choisissez une seule grosse fonctionnalité. Une nouvelle fonctionnalité dont l’intention est claire et où une erreur coûte cher. Continuez à traiter les corrections de bugs et les petites tâches comme d’habitude.
2. Écrivez vous-même les critères d’acceptation, ou validez-les un par un. L’agent peut écrire le reste. Un modèle comme EARS ou WHEN/THEN aide à traduire un critère en test.
3. Décidez dès le départ comment la spec va vivre. Spec Kit décrit trois modèles et n’en fait aucun le modèle par défaut : flow-back, où chaque document peut mettre à jour les autres ; flow-forward, où chaque changement ouvre un nouveau dossier ; et living spec, où la spec est la seule source. Notez le modèle choisi dans la constitution ou dans les notes d’accueil de l’équipe.
4. Envoyez la spec et le code dans la même pull request. Commencez la review par le diff de la spec.
5. Confiez le contrôle à un autre regard. Le résultat de converge ou de verify de l’agent qui a fait le travail est un début ; une personne doit aussi regarder les critères d’acceptation et le diff de la spec.

Au bout d’un moment, regardez deux choses : les specs continuent-elles d’évoluer avec le code, et où part le temps de review ? Le critère de Kretz est simple : si la spec est en retard sur le code, ce n’est plus la source de vérité, c’est de la documentation.