Spec-driven development : écrire la recette avant de cuisiner

En bref. Le spec-driven development (SDD) consiste à écrire d’abord la spécification d’un logiciel, puis à faire produire le code par l’IA à partir d’elle : la spec devient la source de vérité partagée par l’humain et l’IA. La méthode se pratique à trois niveaux d’engagement, du plus léger au plus radical, et le risque monte à chaque marche. Sa règle d’or : quand la réalité diverge, corriger la spec avant le code. Son piège : croire qu’une pile de documents vaut contrôle.

Sans prérequis technique. Le texte principal se lit de bout en bout sans bagage particulier ; les encadrés « Pour aller plus loin » ajoutent le vocabulaire précis pour qui veut creuser.

Imaginez deux cuisiniers. Le premier improvise : une pincée de ceci, un trait de cela, au feeling. Ça sent parfois très bon, mais personne, pas même lui, ne saura refaire le plat demain. Le second écrit sa recette avant de cuisiner : les ingrédients, les étapes, les quantités. Le plat n’est plus une surprise ; c’est l’exécution fidèle d’un plan.

Faire coder une IA fonctionne de la même façon. Pendant deux ans, on l’a pilotée à l’intuition : on lance une demande, on voit ce qui sort, on rejette, on recommence. En 2026, une autre habitude s’installe : écrire d’abord la « recette » (la spécification), puis laisser l’IA cuisiner à partir d’elle. Cette méthode porte un nom, le spec-driven development (SDD). Toute sa subtilité tient dans une question : qui tient la recette à jour quand le plat change ?

Dans cet article, la « recette » désigne la spec, ce document qui décrit ce que le logiciel doit faire. La métaphore est une image pédagogique, absente des sources.

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

C’est une façon de développer avec l’IA où la spécification, écrite avant le code et tenue à jour, fait foi pour l’humain comme pour l’IA. On peut le situer sur un continuum, du plus instinctif au plus rigoureux :

Façon de faire	Ce qui compte vraiment	Ce qu’il en reste demain
On improvise (vibe coding)	La demande jetée au fil de l’eau	Rien : le plat existe, la recette a disparu
On garde la note (prompt-driven)	La demande, conservée comme trace	Une note, mais qui n’engage personne
On maintient la recette (spec-driven)	La recette elle-même, tenue à jour	Un document vivant qui fait foi

Le déplacement est total : on ne cherche plus la bonne formule à taper, on entretient le bon document.

Pour aller plus loin : le continuum en termes exacts Le point de départ est le vibe coding, expression lancée par Andrej Karpathy en février 2025 : piloter l’IA à l’intuition. Le continuum proposé ici, grille de lecture de l’auteur, va du vibe coding (prompt jeté, aucune persistance) au prompt-driven (prompt conservé, sans contrat) puis au spec-driven (spec versionnée, synchronisation explicite dans les deux sens). On peut le rapprocher d’un éventail plus large de méthodes « AI-native » (SDD, BMAD, GSD…), en lui donnant sa question de fond : où réside la vérité du système.

Pourquoi la spec fait-elle foi plutôt que le code ?

Parce que c’est elle qui exprime l’intention, et qu’elle est partagée par l’humain qui décide et l’IA qui exécute. Birgitta Böckeler (Thoughtworks), qui a analysé les outils du domaine sur le site de Martin Fowler, le résume ainsi : « La spec devient la source de vérité pour l’humain et pour l’IA. »

En clair, on écrit la recette avant le plat, et c’est la recette qui tranche en cas de doute. Là où le cuisinier qui improvise traite ses notes comme un brouillon jetable, le spec-driven en fait le document de référence : rangé, relu, mis à jour, et surtout partagé. La recette cesse d’être un pense-bête pour devenir le contrat que les deux consultent.

Quels sont les trois niveaux du spec-driven development ?

Spec-first, spec-anchored et spec-as-source : trois marches, de la plus légère à la plus radicale. La spec peut ne servir qu’à la tâche du jour, accompagner la fonctionnalité pendant toute sa vie, ou devenir l’unique source dont le code n’est qu’une projection, sans jamais être retouché à la main.

Marche	Ce que couvre la recette	Le plat, ensuite…
Spec-first	La tâche du jour seulement : la recette précède, puis on passe à autre chose	…le cuisinier le retouche librement
Spec-anchored	Elle dure : elle accompagne le plat pendant toute sa vie	…on le fait évoluer en repartant de la recette
Spec-as-source	Elle est tout : le plat n’en est qu’une projection	…personne n’a le droit d’y toucher à la main

Le vrai saut de risque se situe entre la deuxième et la troisième marche. Les deux premières gardent l’humain aux commandes du plat. La troisième le lui interdit : c’est un pari lourd sur la régularité d’une IA qui, justement, n’est pas régulière.

Pour aller plus loin : les trois niveaux selon Böckeler Böckeler décrit ces trois paliers dans un article du 15 octobre 2025 : spec-first (une spec écrite d’abord, pour la tâche en cours), spec-anchored (la spec est conservée après la tâche, pour faire évoluer et maintenir la fonctionnalité), spec-as-source (la spec est l’artefact principal, l’humain ne touche jamais au code). Le saut de risque entre les deux derniers niveaux est la lecture de l’auteur ; Böckeler, elle, s’interroge ouvertement sur le réalisme du spec-as-source.

Kiro, spec-kit ou Tessl : quel outil de spec-driven development ?

Le marché a produit trois outils, chacun incarnant un style : Kiro, le plus léger, spec-kit (GitHub), le plus cérémonieux, et Tessl, le plus ambitieux, encore en bêta privée.

Outil	Style	En une phrase
Kiro	Le plus léger	Trois fiches de contexte suffisent ; la recette cadre, puis l’humain garde la main
Spec-kit (GitHub)	Le plus cérémonieux	Des règles « constitutionnelles », huit fichiers dans l’exemple étudié, une branche par spec
Tessl (bêta privée)	Le plus ambitieux	Chaque bout de plat marqué « ne pas toucher » : il vise les marches les plus hautes

Le contraste entre Kiro et spec-kit est parlant. Même ambition affichée (spec-first), mais l’un tient sur trois fiches quand l’autre en empile huit, avec règles et branche dédiée. Plus de cérémonie n’est pas plus de contrôle. Tessl, lui, vise le graal du plat « ne pas toucher », alors même que Böckeler, en le testant, a vu le non-déterminisme des IA à l’œuvre : une bêta sur le pari le plus risqué du domaine.

Pour aller plus loin : les workflows exacts Kiro : Requirements → Design → Tasks, critères d’acceptation GIVEN/WHEN/THEN en markdown, mémoire « steering » sur trois fichiers (product.md, tech.md, structure.md), principalement spec-first. Spec-kit (CLI de GitHub) : Constitution → Specify → Plan → Tasks, principes constitutionnels immuables, huit fichiers dans l’exemple analysé par Böckeler, une branche par spec. Tessl (framework, bêta privée) : correspondance un pour un entre spec et fichier, avec le marqueur // GENERATED FROM SPEC - DO NOT EDIT ; vise le spec-anchored et explore le spec-as-source.

Comment éviter que la spec et le code divergent ?

En corrigeant toujours la spec d’abord, puis le code. C’est la règle d’or du SPDD (Structured-Prompt-Driven Development), une variante proposée en avril 2026 par Wei Zhang et Jessie Jie Xia (Thoughtworks), qui traite les demandes faites à l’IA comme des documents versionnés et maintenus au même titre que le code.

Le SDD seul ne dit pas comment empêcher la recette et le plat de dériver l’un de l’autre. Le SPDD y répond par une règle qui vaut pour tout le domaine :

« Quand la réalité diverge, corrige d’abord le prompt, puis mets à jour le code. » (Wei Zhang et Jessie Jie Xia)

Autrement dit : corrige la recette d’abord, le plat ensuite. C’est cette discipline, et elle seule, qui transforme la recette d’un papier mort en source de vérité vivante. Sans elle, le plat évolue dans son coin, la recette prend la poussière, et six mois plus tard plus personne ne sait laquelle des deux dit vrai.

Pour aller plus loin : SPDD et le REASONS Canvas Le SPDD structure la spec avec le REASONS Canvas, sept dimensions en trois groupes : la partie abstraite (Requirements, Entities, Approach, Structure), la partie spécifique (Operations) et les standards communs, côté gouvernance (Norms, Safeguards). Il s’insère dans un déroulé en six étapes avec des points de contrôle humains, dont une étape de clarification avec le métier. La règle d’or vise à empêcher que l’intention et l’implémentation ne dérivent l’une de l’autre (intent drift).

Le spec-driven development donne-t-il une fausse impression de maîtrise ?

Il le peut, dans sa version cérémonielle. Des spécifications trop bavardes donnent l’illusion de tout contrôler, alors que l’IA ignore ou sur-interprète souvent les consignes qu’on lui empile. Ce contrepoids vient de Birgitta Böckeler elle-même, qui a pourtant posé la grammaire des trois marches.

« Je préfère relire du code plutôt que toute cette pile de fichiers markdown. » (Birgitta Böckeler)

Son alerte, formulée comme une question, porte un nom : la fausse maîtrise. Huit fichiers, des règles, des check-lists : on croit gouverner, on remplit des formulaires que le cuisinier lit de travers.

Le terrain va dans son sens. Une équipe de six développeurs, suivie de l’intérieur pendant huit mois, a évalué l’outil le plus cérémonieux, l’a jugé trop lourd et a adopté un workflow plus léger. Et une étude a montré qu’une recette écrite par une IA peut être presque illisible pour une autre.

Cette critique, à mon sens, ne disqualifie pas le spec-driven, mais sa version cérémonielle. Empiler des documents n’est pas une sécurité ; c’en est parfois le déguisement. La règle simple qui en découle : une recette ne vaut que par le risque qu’elle écarte réellement, pas par le nombre de pages qu’elle compte.

Pour aller plus loin : la critique mot à mot Böckeler s’interroge sur un false sense of control : les workflows verbeux rassurent sans réduire le risque, car les agents ignorent ou sur-interprètent les instructions empilées. Son parallèle historique est le Model-Driven Development (MDD), qui promettait déjà de générer le code depuis un modèle et a buté sur son inflexibilité ; le SDD risquerait de combiner l’inflexibilité du MDD avec le non-déterminisme des LLM, le pire des deux mondes. Elle pose la question d’un mot allemand : Verschlimmbesserung, « améliorer en aggravant ». Deux échos en 2026. Sur le terrain, Nik Malykhin (Thoughtworks, 16 septembre), référent IA d’une équipe de six développeurs pendant huit mois, raconte avoir évalué spec-kit, l’avoir trouvé trop lourd, puis avoir adopté un workflow plus léger. En mesure, une étude d’ingénieurs d’EPAM Systems (arXiv 2608.21208, août 2026), sur une migration d’Oracle vers PostgreSQL, montre qu’une spec produite par Kiro et lue par Gemini ne donne que 2,33 % de SQL syntaxiquement valide : la spec n’est pas neutre d’un agent à l’autre.

Quel niveau de spec-driven development choisir ?

Commencer léger, en spec-first, pour l’immense majorité des équipes ; monter vers le spec-anchored quand le projet le mérite ; et se méfier du tout-spec, pas encore mûr. Le spec-driven est réel et utile, mais sa maturité est très inégale selon la marche.

Marche	Verdict	Pour qui
Spec-first pragmatique	À adopter. Le meilleur rapport entre discipline et effort : la recette cadre, l’humain garde le plat.	Toute équipe qui bute sur le « mur » de l’improvisation
Spec-anchored	À piloter. Payant sur les projets qui durent ; exige une vraie discipline de mise à jour.	Équipes mûres, projets pérennes
Spec-as-source	Méfiance. Le plat « ne pas toucher » parie sur une régularité que les IA n’ont pas.	Expérimentation surveillée, pas la production

C’est souvent le chemin suivi par nécessité : quand l’improvisation heurte un mur (conventions qui dérivent, contrats qui cassent), le sauvetage consiste à écrire la recette avant de cuisiner.

Une recette lisible plutôt qu’un rituel rassurant

L’improvisation jetait la recette après le plat. Le spec-driven la garde, la range, la partage, et fait le pari qu’une recette lisible en amont vaut mieux qu’un contrôle bricolé après coup. Sur les deux premières marches, le pari est gagnant, et le terrain le confirme. Sur la troisième, il reste ouvert : l’outil qui la vise est encore en bêta, et les IA restent irrégulières.

Une pile de fichiers markdown n’est pas une preuve de maîtrise. Commencez léger, tenez la recette à jour, et méfiez-vous du rituel qui rassure sans rien sécuriser.

Sources

• Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, martinfowler.com (15 octobre 2025) : https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• Wei Zhang et Jessie Jie Xia, Structured-Prompt-Driven Development (SPDD), martinfowler.com (28 avril 2026) : https://martinfowler.com/articles/structured-prompt-driven/
• Birgitta Böckeler, The role of developer skills in agentic coding, martinfowler.com : https://martinfowler.com/articles/exploring-gen-ai/13-role-of-developer-skills.html
• Thoughtworks, What is spec-driven development?, podcast avec Birgitta Böckeler et Laura Tacho (28 mai 2026) : https://www.thoughtworks.com/insights/podcasts/technology-podcasts/what-is-spec-driven-development
• Nik Malykhin, Quantifying AI adoption: From initial challenges to doubling speed, Thoughtworks (16 septembre 2026) : https://www.thoughtworks.com/insights/blog/machine-learning-and-ai/quantifying-ai-adoption-from-initial-challenges-to-doubling-speed
• Grynets, Ilchuk, Zatulna et Lyashkevych, Specification Portability Across LLM Development Agents, arXiv:2608.21208 (août 2026) : https://arxiv.org/abs/2608.21208

Et chez vous ?

Vos équipes utilisent déjà l’IA pour développer. La question n’est plus de savoir si, mais avec quel cadre : quelles consignes en amont, quels capteurs en aval, et qui les fait évoluer.

Chez Atecna, nous accompagnons les équipes de développement sur ce terrain : diagnostic de maturité, mise en place des guides et des capteurs, industrialisation multi-projets avec notre offre de développement IA, et montée en compétence des équipes.