Le Spec-Driven Development commence à s’installer dans le paysage du développement assisté par IA. L’idée générale est séduisante : plutôt que de multiplier les prompts éphémères et de laisser progressivement le code devenir la seule description réelle du logiciel, on conserve l’intention dans des spécifications explicites, vivantes et révisables.
Microsoft décrit aujourd’hui le SDD comme une approche dans laquelle les spécifications deviennent une source de vérité partagée entre humains et IA, reliant l’intention métier, les contraintes, l’architecture, l’implémentation et la validation. Microsoft recommande d’ailleurs explicitement de commencer léger et d’étendre le processus uniquement lorsqu’il apporte une valeur claire.
Jusque-là, tout paraît assez simple.
Puis arrive GitHub Spec Kit.
Et soudain apparaissent commandes, templates, CLI, scripts, presets, extensions, workflows et différentes structures documentaires.
D’où une question assez naturelle :
si le SDD repose principalement sur des fichiers que les humains et les agents savent lire et modifier, pourquoi faut-il toute cette plomberie ?
La réponse est intéressante, parce qu’elle permet à la fois de mieux comprendre Spec Kit et de mieux comprendre ce que SDD n’impose pas.
SDD n’est pas Spec Kit
La première distinction à faire est probablement la plus importante.
Le SDD est une manière d’organiser le développement autour d’une intention explicite et durable. GitHub Spec Kit est une manière particulière de matérialiser cette approche.
Microsoft lui-même présentait dès 2025 Spec Kit comme une implémentation apportant notamment une CLI de bootstrap, des templates et des scripts auxiliaires. Les documents produits restent essentiellement des fichiers Markdown que l’on peut consulter et modifier directement.
Autrement dit, on pourrait tout à fait pratiquer une forme de SDD avec seulement quelques artefacts :
PROJECT.md
RULES.md
SPEC.md
STATUS.md
et un agent auquel on donne des instructions explicites pour les lire, les maintenir et travailler à partir d’eux.
Il n’existe pas de nécessité conceptuelle imposant une CLI, GitHub ou une chaîne complexe de commandes (et encore moins python ou des scripts powershell).
Spec Kit ajoute autre chose.
Il ajoute de la reproductibilité.
À quoi sert alors toute cette plomberie ?
Le workflow SDD actuel de Spec Kit peut aller de la constitution jusqu’à la convergence, en passant par la spécification, la clarification, le plan, les tâches, les checklists, l’analyse et l’implémentation.
Une partie importante de ce fonctionnement ne consiste pas à « comprendre le logiciel ». Elle consiste à automatiser une mécanique autour des artefacts :
- initialiser correctement un projet ;
- installer les commandes adaptées à l’agent utilisé ;
- retrouver les bons fichiers ;
- déterminer la feature courante ;
- appliquer les bons templates ;
- vérifier les prérequis entre étapes ;
- maintenir des conventions communes ;
- fournir les mêmes procédures à différents agents et différentes équipes.
Ce travail n’est pas inutile. Au contraire.
Il déplace hors du LLM tout ce qui peut être rendu déterministe.
Le principe est sain :
raisonnement et sémantique → agent / LLM
mécanique reproductible → code
intention durable → artefacts
La question n’est donc pas de savoir si Spec Kit est bien ou mal conçu.
La question est : de quelle quantité de cette infrastructure avons-nous réellement besoin ?
La complexité traitée par Spec Kit n’est pas seulement celle du logiciel
C’est probablement là que se trouve la clé.
Une petite équipe composée de quelques développeurs expérimentés travaillant ensemble depuis longtemps peut avoir un logiciel techniquement très complexe tout en ayant peu de problèmes de coordination.
À l’inverse, une application relativement banale répartie entre plusieurs équipes, prestataires, technologies et agents IA peut devenir extraordinairement difficile à gouverner.
Spec Kit apporte surtout de la valeur lorsque le nombre de points de coordination augmente :
x nombre d'acteurs
x hétérogénéité des acteurs
x parallélisme
x turnover
x durée du projet
x contraintes organisationnelles
Lorsque ce produit devient important, transformer une manière de travailler en protocole reproductible a beaucoup de sens.
La plomberie réduit alors la variance.
L’équipe A ne travaille plus totalement différemment de l’équipe B. Un nouvel agent retrouve les mêmes conventions. Un intervenant qui arrive six mois plus tard dispose des mêmes structures. Une organisation peut appliquer certaines règles de manière homogène.
Dans ce contexte, Spec Kit ne constitue pas une complication accidentelle.
Sa complexité répond à une complexité organisationnelle réelle. Mais on verra plus loin que cela peut être illusoire...
Le parallèle avec GitHub est frappant
On retrouve ici un phénomène déjà observable depuis longtemps autour des outils de gestion de sources.
Git, GitHub, les Pull Requests, les workflows automatisés, les branches, les checks, CODEOWNERS, les issues et toute l’infrastructure qui les accompagne sont extraordinairement adaptés à certains contextes.
Pour un grand projet open source réunissant des centaines ou des milliers de contributeurs répartis autour de la planète, le problème de coordination est immense. La plomberie est justifiée.
Cela ne signifie pas que chaque équipe de quatre développeurs travaillant sur trois applications métier ait besoin du même niveau de processus. Subversion était parfaitement taillé pour ces contextes par exemple.
La généralisation d’une solution conçue pour résoudre les problèmes d’une grande échelle peut transformer une excellente architecture organisationnelle en bureaucratie.
Spec Kit pose exactement la même question.
Il ne faut pas confondre :
« Cet outil sait coordonner un environnement complexe »
avec :
« Toute équipe doit adopter cet environnement complexe pour travailler correctement ».
Le retour du coût de confiance
Il existe également une autre dimension, plus rarement discutée : celle de la chaîne de confiance.
Spec Kit n’impose désormais plus Git dans tous les cas ; la documentation actuelle indique que Git est optionnel et principalement requis lorsque l’extension correspondante est utilisée. En revanche, l’installation officielle de Spec Kit demande actuellement Python 3.11+ ainsi que uv ou pipx.
Le problème n’est évidemment pas Python.
Une équipe Python ne se poserait même pas la question.
Mais considérons une équipe entièrement .NET.
Son environnement maîtrisé peut être constitué de :
.NET SDK
PowerShell
Visual Studio / Rider
quelques packages connus
ses propres applications
L’adoption d’un outil externe ajoute alors une nouvelle chaîne :
Python
→ gestionnaire de packages Python
→ specify-cli
→ dépendances
→ templates
→ scripts
→ mécanismes de mise à jour
Encore une fois, cela peut être parfaitement justifié.
Mais il faut le justifier.
Et le justifier par "c'est parce que tout le monde le fait", n'est pas une justification acceptable.
Une règle élémentaire d’architecture devrait également s’appliquer à l’outillage :
Toute dépendance ajoutée à la chaîne de production doit apporter davantage de valeur que le coût de confiance, de compréhension et de maintenance qu’elle introduit.
Or l’un des messages centraux de la gouvernance des agents consiste précisément à ne pas déléguer aveuglément : rendre les règles visibles, connaître le contexte fourni à l’agent, contrôler ce qu’il peut faire, vérifier ses résultats et comprendre les mécanismes automatisés.
Installer un outil de gouvernance sans comprendre ce qu’il gouverne serait donc assez paradoxal.
Ce n’est cependant pas un défaut intrinsèque de Spec Kit
Il serait injuste d’en conclure que Spec Kit est opaque par nature.
Ses artefacts, templates et scripts sont inspectables. Il est possible d’épingler des versions, d’adapter les templates et de modifier les conventions. Je modulerai malgré tout le côté "inspectable" : des développeurs .NET n'iront pas mettre leur nez dans le code Python, et ils ne devraient pas avoir à le faire. De fait c'est comme ces gros packages de contrôles pour WinUI, ASP.Core ou autre qui vous indiquent fièrement que leur code source est fourni, comme élément de confiance. C'est un leurre, avez-vous déjà mis le nez dans ce type de code source de dizaines de milliers de lignes ou plus (surtout qu'on achète ces contrôles souvent parce qu'on ne saurait pas les écrire !) ? Personne ne le fait, bien entendu. Donc quand Spec-kit se dit "inspectable", cela est réservé éventuellement au petit monde des devs Python, mais semble plus être un argument marketing dès qu'on s'adresse à des devs Java ou C#...
GitHub a également introduit un preset lean qui réduit explicitement le workflow à l’essentiel : spécification, plan, tâches et implémentation, avec des fichiers Markdown beaucoup plus directs.
Le système de presets permet en outre de remplacer les templates, commandes et terminologies sans modifier le cœur de l’outil. Déjà là on se sent paumé et pourtant c'est la version "pour les nuls" !
Cela montre justement que Spec Kit reconnaît plusieurs niveaux de cérémonie possibles. Mais cela reste des cérémonies tout de même, et elles ne sont pas forcément justifiée dans tous les cas.
On se moque souvent, et La Fontaine l'a fait avec habileté, de la grenouille que veut se faire aussi grosse que le boeuf, spoiler alert : ça finit mal. S'il avait été notre contemporain Spec-Kit lui aurait peut être inspiré une autre fable tout aussi moralisatrice sur le boeuf qui voulait se faire aussi petit que la grenouille. Et ça finirait mal aussi... Spec-Kit comme GitHub ont été conçu comme des boeufs, dès le départ, pour tirer de lourdes charges. Ils sont utiles et même précieux dans ce cas précis. Mais vouloir les miniaturiser pour les rendre moins impressionnant ne marche pas. Sur les routes on n'utilise pas des "mini locomotives" on a inventé les voitures. Non pas que les locos étaient mal conçues ou inutiles, juste parce qu'en faire des versions miniatures n'avait aucun sens, il fallait repenser le produit tout simplement...
Une organisation peut parfaitement adopter une version donnée de Spec-Kit, l’auditer, la figer, éventuellement la forker, puis l’intégrer à sa propre chaîne d’outillage. C'est possible, c'est souple. Mais, du coup (horrible expression à la mode), un autre paradoxe apparait : Qu'en est-il de la fameuse uniformité qu'apporterait Spec-kit si chacun peut en bricoler une version différente ?
Mais on pourrait dire : dans ce cas, il n’y a aucune contradiction avec les principes de gouvernance.
Au contraire : l’outil de gouvernance est lui-même gouverné.
Sauf qu'il en existe autant de versions que d'équipes et donc adieu l'argument principal d'uniformisation du process ! On a un borderl mais gouverné. C'est possible. Les pays qui n'ont pas suivi la pudibonderie ridicule de la France et qui ont conservé des maisons closes savent très bien qu'un bordel peut être bien gouverné mais que cela n'en change pas la nature en boulangerie ou en centre de loisir pour les écoles du coin...
Là se trouve le vrai paradoxe
Et c’est probablement la conclusion la plus intéressante.
Plus on utilise Spec Kit dans un environnement exigeant (entendez très gros), plus son infrastructure devient justifiée.
Mais plus cette infrastructure devient importante, plus elle doit elle-même être comprise, auditée, versionnée et gouvernée. Sinon elle contredit les principes de base de gouvernance de SDD !
Autrement dit :
Pour utiliser correctement un outil destiné à gouverner le travail des agents, il faut commencer par gouverner cet outil.
Ce paradoxe n’est pas une condamnation de Spec Kit.
Il permet plutôt de replacer l’outil à sa juste place.
Spec Kit est une réponse élaborée à un problème de coordination élaboré. Il exige donc une organisation pour lui-même, une bureaucratie qui s'occupe de faire tourner l'administration, s'auto-justifiant presque de façon absurde.
Le problème commence lorsque cette réponse devient une prescription indépendante du contexte.
Le bon niveau de SDD n’est donc pas universel
Une petite équipe pourrait parfaitement fonctionner avec :
quelques fichiers Markdown
+ des règles explicites
+ un agent
Une équipe intermédiaire pourrait ajouter :
templates
+ contrôles
+ quelques commandes déterministes
Une organisation importante pourrait préférer :
workflow complet
+ contrôles automatiques
+ intégrations multiples
+ conventions partagées
+ Spec Kit ou un système comparable
Ces trois approches peuvent relever du SDD.
Le critère ne devrait pas être la conformité à un outil particulier.
Il devrait être :
Quel niveau de gouvernance faut-il pour conserver l’intention, maîtriser les agents et coordonner correctement les acteurs de ce projet ?
C’est probablement le point essentiel.
SDD permet aux LLM de supprimer une partie de la plomberie autrefois nécessaire pour traduire une intention en comportement logiciel.
Il serait dommage de profiter de cette simplification pour reconstruire immédiatement une infrastructure complexe partout, y compris là où elle ne résout aucun problème réel.
C'est peut-être là un réflexe des incompétents, souvent nombreux dans les hiérarichies (lire le principe de Peter, toute personne est propulsée dans la hiérarchie jusqu'à atteindre son niveau d'incompétence...). Trop simplifié, trop supprimer de bureaucratie rend ceux qui s'en occupait inutiles. Et ils n'aiment pas se sentir sur un siège éjectable, alors ils inventent une nouvelle bureaucratie pour se maintenir en place. Peut-être. Je n'affirme rien, à chacun de constater autour de lui.
En tout cas la bonne gouvernance n’est pas celle qui ajoute le plus de contrôles.
C’est celle qui ajoute exactement les contrôles dont le contexte a besoin — et pas davantage.
Bon projets avec SDD (bien digéré et pas imposé par un outil),
Stay Tuned!