SpecKit : le guide complet pour arrêter de prompter à l'aveugle

GitHub a publié un outil qui change la façon de travailler avec l'IA : Spec Kit. Plus de 128 000 étoiles sur le repo, et quasiment personne ne le montre en français. Ce qui fait la différence, ce n'est pas la puissance du modèle — c'est ce que tu poses avant de lancer la machine. Voici le guide d'installation et l'enchaînement complet des étapes. Le repo est ici : github.com/github/spec-kit.

1Le problème que ça règle (avant même la technique)

Aujourd'hui tu as deux galères. Soit tu lances l'IA au hasard : ça part vite, tu rattrapes derrière, et au bout de trois jours le projet part en vrille parce que personne — ni toi ni la machine — n'a jamais écrit ce qu'on construisait vraiment. Soit tu écris chaque ligne toi-même, et tu y passes tes soirées.

La troisième voie. Spec Kit force un ordre : d'abord les règles du projet, ensuite le besoin en langage normal, ensuite les questions sur tes zones floues, ensuite seulement la technique, le découpage et l'exécution. L'IA n'a plus le droit d'improviser : elle a un document à respecter.

Et ça dépasse largement le code. Poser le plan avant de bâtir, tous les bons opérateurs font ça depuis toujours. La nouveauté, c'est que GitHub vient de l'outiller. Quand raconter suffit à produire, la vitesse ne vaut plus rien : c'est la clarté qui paye.

2Installer Spec Kit (10 minutes)

Ce qu'il te faut avant. Python 3.11 ou plus, Git, le gestionnaire de paquets uv (d'Astral), et un assistant de code que tu utilises déjà — Spec Kit s'intègre à plus de 30 outils (Claude Code, GitHub Copilot, Codex CLI, et d'autres). Mac, Linux ou Windows.

Étape 1 — installer l'outil en ligne de commande. Une seule fois sur ta machine :

Étape 2 — créer ton projet en indiquant l'assistant que tu utilises. Remplace copilot par ton intégration (la liste exacte de ta version s'affiche avec specify integration list) :

Étape 3 — vérifier. specify self check te dit si une version plus récente existe, sans rien modifier. À partir de là, tout se joue dans ton assistant : Spec Kit y a installé une série de commandes, toutes préfixées /speckit.

3L'enchaînement complet des étapes

Six commandes dans l'ordre. Chacune produit un document que tu relis et valides avant de passer à la suivante. C'est là qu'est toute la valeur : tu es le point de contrôle entre chaque étape.

1. /speckit.constitution — la charte. Tu poses les principes que l'IA n'aura pas le droit de casser sur tout le projet : niveau de test exigé, contraintes de sécurité, simplicité imposée, conventions. Écrit une fois, ça s'applique à toutes les fonctionnalités qui suivent. C'est l'étape que tout le monde saute — et c'est celle qui tient le projet.

2. /speckit.specify — le besoin, en français. Tu racontes ton produit comme à un humain : « je veux un outil qui classe mes photos par date, en glisser-déposer ». Le quoi et le pourquoi, jamais la technique. Pas de langage de programmation, pas de base de données, pas d'architecture : ça vient plus tard.

3. /speckit.clarify — les questions. L'IA relit ton brief et te renvoie tous ses trous, marqués [NEEDS CLARIFICATION] : « que se passe-t-il si deux photos ont la même date ? », « combien d'utilisateurs en même temps ? ». Tu réponds. Tant qu'il reste un trou, on n'avance pas. C'est exactement le moment où un projet classique dérape en silence — ici il s'arrête et te demande.

4. /speckit.plan — la technique. Maintenant seulement tu donnes ta stack et tes choix d'architecture. L'IA rédige le plan d'implémentation en respectant la charte de l'étape 1 et la spec de l'étape 2.

5. /speckit.tasks — le découpage. Le plan est transformé en lots de travail concrets, numérotés, ordonnés. Tu vois le chantier avant qu'il commence, et tu peux couper ou réordonner.

6. /speckit.implement — l'exécution. L'IA attaque les tâches dans l'ordre, en s'appuyant sur les trois documents précédents. Elle ne réinvente rien : elle exécute ce que tu as signé.

4Ce que ça pose sur ton disque

Chaque étape laisse une trace écrite. C'est ça qui rend le projet relisable par un humain, transmissible à un prestataire, et défendable devant un client.

Les fonctionnalités sont numérotées automatiquement (001, 002, 003…). Une fonctionnalité = un dossier = une histoire complète, du besoin jusqu'aux tâches.

5Les 4 erreurs qui font rater le truc

Erreur 1 — sauter la charte. Sans constitution, l'IA prend ses propres décisions à chaque fonctionnalité, et ton projet devient un patchwork de conventions contradictoires. Dix minutes à l'étape 1 t'économisent des jours à l'étape 6.

Erreur 2 — mettre de la technique dans la spec. Si tu écris « avec une base Postgres et du React » dans le specify, tu as déjà tranché avant d'avoir décrit le besoin. Le quoi d'abord, le comment ensuite. C'est tout l'intérêt d'avoir deux documents séparés.

Erreur 3 — répondre vite aux clarifications. C'est l'étape la plus rentable et la plus ennuyeuse. Chaque question esquivée redevient un bug trois jours plus tard. Prends-les au sérieux.

Erreur 4 — valider sans lire. Le système ne vaut que par ton contrôle entre les étapes. Si tu enchaînes les six commandes sans relire les documents, tu as juste remplacé le prompt à l'aveugle par un pipeline à l'aveugle. Plus rapide, mais tout aussi aveugle.

Ce que tu pilotes, ce que tu délègues

Même si tu ne codes pas une ligne, ce découpage est directement utilisable pour cadrer un projet avec un prestataire ou une équipe interne.