01Le film que tout le monde connaît
Tu ouvres Claude ou Cursor, tu tapes « fais-moi une app de réservation ». L'agent part en courant, écrit 400 lignes, et tu passes les deux heures suivantes à réparer ce qu'il a mal deviné.
Le problème n'est pas l'agent. Il n'avait aucune spec, alors il a rempli les trous à ta place. Chaque trou rempli au hasard devient un bug qui ressemble à une fonctionnalité.
02SpecKit en six étapes
SpecKit découpe le travail en étapes, chacune lancée par une commande dans ton agent :
| Étape | Ce que tu écris |
|---|---|
| Constitution | Les règles non négociables du projet : stack, conventions, ce qu'on ne fait jamais. |
| Specify | Ce que tu veux et pourquoi, en langage clair. Pas le comment. |
| Clarify | L'agent te renvoie les ambiguïtés au lieu de les deviner. L'étape que tout le monde saute. |
| Plan | L'architecture technique : fichiers, dépendances, ordre. |
| Tasks | Le plan découpé en tâches vérifiables une par une. |
| Implement | L'agent exécute, tâche par tâche, sur une base validée. |
Quand l'agent écrit le code, il ne devine plus rien : les décisions ont été prises avant, par écrit, par toi.
03Le vrai déclic : l'inversion
Ce qu'on dit peu dans les guides SpecKit : le gain n'est pas dans l'outil, il est dans l'inversion.
Sans spec, tu délègues la décision à l'agent et tu reprends l'exécution à la main, sous forme de débogage. Avec une spec, tu gardes la décision et tu délègues l'exécution. Tu passes de tâcheron à architecte.
Un agent est aussi bon que la spec qu'on lui donne. Vague en entrée, chaos en sortie.
04Ce que ça donne sans coder
Je ne construis pas d'applications grand public. Je fais tourner un parc de sites, et le principe qui le rend possible est le même. Je ne demande jamais « écris-moi un article ». Je donne une spec : la question cible, le lecteur, la structure (la réponse dans les deux premières phrases), les données structurées attendues, et la liste des faits vérifiés que l'article a le droit d'utiliser.
La dernière ligne est la plus importante. Un agent sans liste de faits en invente. Avec la liste, il écrit avec ce qu'il a, et il te dit ce qui manque.
Voilà à quoi ressemble une spec de page chez moi, en version courte :
OBJECTIF Répondre à « combien de Go fait le jeu » mieux que la page n°1.
LECTEUR Joueur qui hésite à racheter un SSD.
STRUCTURE Réponse chiffrée dans les 2 premières phrases, puis tableau
par plateforme, puis FAQ (3 questions réellement posées).
FAITS Seulement les chiffres de la fiche éditeur (lien), datés.
CRITÈRES - title de 51 à 60 caractères avec le chiffre
- FAQPage valide, questions présentes sur la page
- aucune affirmation sans source
HORS Pas de comparatif de SSD, pas de lien affilié dans l'intro.05Où ça vaut le coup, et où non
- Ça vaut le coup dès qu'un travail a plus d'une inconnue : une vraie fonctionnalité, une page qui doit vendre, une refonte. Le temps « perdu » en spec se récupère au débogage.
- C'est du zèle pour une tâche triviale (« renomme cette variable »). Là, prompter directement est plus rapide. Ne ritualise pas pour ritualiser.
- Le piège : sauter Clarify. Un agent qui ne pose aucune question n'est pas obéissant, il devine.
06Questions fréquentes
C'est quoi le spec-driven development ?
Écrire la spécification d'abord (quoi, pourquoi, critères d'acceptation), puis laisser l'agent exécuter. Le code devient la conséquence d'une décision écrite.
SpecKit est-il gratuit ?
Oui, c'est un projet open source publié par GitHub. Il fonctionne avec plusieurs agents de code, dont Claude Code.
Et si je ne veux pas installer SpecKit ?
Garde le principe. Le skill cahier-des-charges du Starter fait l'essentiel : il transforme une demande floue en spec avec objectif, périmètre, critères d'acceptation et hors-périmètre.