Il y a un schéma que presque tous ceux qui construisent avec l'IA répètent : au début tu lui parles, du code apparaît, ça marche, c'est magique. Mais vers la cinquième ou sixième fonctionnalité, la magie se brise — tu demandes un petit changement et autre chose se casse, tu lui expliques pour la troisième fois comment marche le login \"parce qu'elle a oublié\", et tu ouvres le projet le lendemain sans te rappeler pourquoi la moitié des fichiers existe. Le vrai problème n'est pas que l'IA soit bête : c'est qu'elle n'a pas de mémoire de l'intention et devine différemment chaque fois qu'elle comble un trou. Le Spec-Driven Development inverse l'ordre du vibe coding : avant que l'IA écrive une ligne, tu écris la spec —ce que l'app doit faire, dans tes mots— et ce document devient l'unique source de vérité à partir de laquelle l'agent génère plan → tâches → code, avec tes checkpoints entre chaque étape. Dans ce guide tu verras l'outil qui l'installe comme des commandes à l'intérieur de ton propre agent (GitHub Spec Kit, gratuit et open source), le flux réel en 4 phases, les commandes exactes, et un seul prompt maître pour démarrer n'importe quel projet spec-first sans devenir programmeur.
Au début, le vibe coding est magique. Tu parles à l'IA, un écran apparaît, ça marche, tu applaudis. Mais arrive un point —presque toujours vers la cinquième ou sixième fonctionnalité— où la magie se brise. Tu demandes un petit changement et autre chose que tu n'as pas touché se casse. Tu expliques pour la troisième fois comment le login doit fonctionner "parce qu'elle a oublié". Tu ouvres le projet le lendemain et même toi tu ne sais pas pourquoi la moitié des fichiers existe. C'est le moment : quand la conversation cesse de suffire comme source de vérité, et qu'il te faut quelque chose de plus solide qu'un chat à la mémoire de poisson rouge.
Le Spec-Driven Development (développement piloté par spécification, ou SDD) naît exactement là. L'idée est si simple qu'elle en est presque vexante : avant que l'IA écrive une ligne de code, tu écris ce que l'app doit faire — clair, ordonné et sauvegardé dans un fichier. Ce document, la spec, devient l'unique source de vérité. Et l'agent génère, à partir d'elle, un plan → une liste de tâches → le code. Dans cet ordre. Avec tes points de contrôle entre chaque étape.
Le problème n'est pas que l'IA soit bête. C'est que l'IA n'a pas de mémoire de l'intention. À chaque message elle prend la meilleure décision pour ce message-là, sans une image complète de ce que tu construis ni pourquoi. Toi, tu as cette image dans la tête — mais la tête n'est pas un document que l'agent peut lire. Alors l'IA comble les trous en devinant, et devine différemment chaque fois. Une fois le panier enregistre les taxes, une autre fois non. Une fois l'utilisateur peut modifier son profil, une autre fois la fonctionnalité disparaît dans un refactor. Personne n'a menti : simplement il n'a jamais existé de contrat disant ce qui est correct.
Que se passe-t-il si tu ne répares pas ça ? Ce n'est pas l'apocalypse — c'est un accident lent. Tu finis avec une app qui presque fonctionne, impossible à expliquer à quelqu'un d'autre (ou à l'IA de la semaine prochaine), où chaque correctif a sa propre probabilité de casser autre chose. Et ces probabilités ne pardonnent pas : dans un blog de cette même série on a raconté les maths des 27 % — un agent qui réussit à 85 % à chaque étape ne complète un flux de huit étapes que 27 % du temps (0,85⁸), parce que les réussites se multiplient, elles ne s'additionnent pas. Construire à l'aveugle enchaîne des étapes fragiles exactement de la même façon. La spec est ce qui brise cette chaîne de fragilité : elle donne à l'IA un point fixe contre lequel vérifier chaque étape, au lieu de laisser chacune dépendre de la bonne fortune de la précédente.
Dans le vibe coding le flux est : tu parles → code → (parfois) tu documentes. Dans le SDD il s'inverse complètement : tu spécifies → tu planifies → tu génères des tâches → code. La documentation cesse d'être le reste oublié de la fin et devient le point de départ. Et ce n'est pas de la bureaucratie : chaque phase est un artefact que l'agent génère presque seul à partir du précédent, avec un checkpoint à toi pour approuver avant de continuer. Toi tu diriges ; l'IA exécute.
Tu n'as pas à inventer ce flux à la main. GitHub Spec Kit est un kit d'outils open source —de GitHub, gratuit, licence MIT— qui installe le SDD comme une série de commandes à l'intérieur de ton agent d'IA. Toi tu écris la spec en langage naturel ; lui te donne la structure, les checkpoints et les commandes pour que l'IA la transforme en app. C'est l'un des outils d'IA qui a le plus vite grandi : 122 000 étoiles sur GitHub, et sa dernière version stable, la v0.13.0, est sortie le 17 juillet 2026. Il intègre 30+ agents — Claude Code, GitHub Copilot, Cursor, Gemini CLI et celui que tu utilises.
Le kit officiel de GitHub pour le Spec-Driven Development. Installe un flux de commandes (constitution → specify → plan → tasks → implement) à l'intérieur de ton agent d'IA, pour que tu construises à partir d'une spécification exécutable au lieu d'improviser. Model-agnostic : fonctionne avec 30+ agents.
Spec Kit s'installe avec uv, le gestionnaire de paquets Python moderne (rapide, sans drame). Si tu n'as pas uv, tu l'installes d'abord — une ligne. Ensuite tu installes le CLI de Spec Kit de façon persistante, et tu initialises ton projet en choisissant ton agent. Ne t'effraie pas du terminal : ce sont littéralement ces commandes, dans l'ordre, et tu n'y retouches pas pour le vrai travail (celui-ci se passe dans le chat de ton IA).
# 1) Si tu n'as pas uv (le gestionnaire de paquets Python), installe-le : curl -LsSf https://astral.sh/uv/install.sh | sh # 2) Installe le CLI de Spec Kit de façon persistante (en figeant la version stable) : uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.13.0 # 3) Regarde quels agents tu peux choisir (la valeur exacte pour le flag --integration) : specify integration list # 4) Initialise ton projet en choisissant ton agent (ici, Copilot en exemple) : specify init mi-proyecto --integration copilot # 5) Vérifie s'il y a une version plus récente (ne modifie rien, lit seulement) : specify self check
specify init mi-proyecto --integration copilot, la valeur après --integration est ton outil. Spec Kit apporte 30+ intégrations et les change entre les versions, donc au lieu de mémoriser le nom exact, lance d'abord specify integration list et choisis dans cette liste celui que tu utilises (Copilot, Cursor, Gemini, Claude Code, etc.) — c'est comme demander le menu avant de commander, comme ça tu ne commandes jamais un plat qui n'existe pas. Cette commande init crée le dossier avec les commandes /speckit.* déjà câblées dans ton agent ; à partir de là, tout le travail se passe en parlant à l'IA, pas dans le terminal.Une fois initialisé, Spec Kit te donne une série de slash commands que tu écris à l'intérieur de ton agent. Elles ne sont pas magiques : chacune demande à l'IA de générer l'artefact suivant du flux. L'ordre importe — c'est une cascade où chaque étape s'appuie sur la précédente. Voici les vraies, telles qu'elles arrivent dans la v0.13.0 :
/speckit.implement, c'est revenir au vibe coding avec des étapes en plus. La cascade fonctionne parce que chaque artefact restreint le suivant : la constitution borne le plan, le plan borne les tâches, les tâches bornent le code. Si tu brises la chaîne, l'IA se remet à deviner. La discipline est dans le respect des checkpoints, pas dans le fait d'avoir les commandes.Mis bout à bout, voici à quoi ressemble un projet du début à la fin. Remarque qu'à chaque frontière toi tu revois et tu approuves avant que l'IA avance. C'est ça l'astuce : ce n'est pas que l'IA travaille seule sans frein, c'est qu'elle travaille seule entre des checkpoints que tu contrôles.
/speckit.constitution et tu définis les règles d'or du projet. Checkpoint : tu lis et tu confirmes que ces principes sont les bons. Ça s'écrit une fois, ça gouverne toujours./speckit.specify et tu décris quoi construire. Puis /speckit.clarify pour que l'IA referme les ambiguïtés en te questionnant. Checkpoint : la spec dit EXACTEMENT ce que tu veux, sans trous./speckit.plan donne le plan technique ; /speckit.tasks le transforme en tâches ; /speckit.analyze vérifie que tout soit cohérent. Checkpoint : tu approuves la stack et les tâches avant qu'une ligne de code soit écrite./speckit.implement construit. L'IA exécute les tâches une à une contre la spec. Checkpoint : tu utilises /speckit.checklist pour valider que ce qui a été construit remplit les exigences.Le SDD n'est pas pour tout. Un changement d'une ligne, un bouton de couleur, un texte — pour ça tu parles normalement à l'IA et c'est réglé. Écrire une spec pour ça, ce serait comme demander un plan d'architecte pour accrocher un cadre. La bonne habitude, c'est de reconnaître le seuil : au moment où une tâche touche plus d'un fichier, comporte des règles métier, ou que tu vas y revenir la semaine prochaine — là oui, spec d'abord. Et à partir de là, chaque grande nouvelle fonctionnalité naît d'une spec, pas d'une impulsion.
Voici l'unique prompt que tu dois mémoriser. C'est celui que tu donnes à ton IA (avec Spec Kit déjà initialisé) pour bien démarrer dès la première minute : il lui demande de d'abord fixer la constitution, puis de construire la spec avec toi en posant les questions manquantes, et de ne pas écrire de code tant que tu n'as pas approuvé. Copie-le, remplis les [crochets], et colle-le à ton agent en démarrant n'importe quel projet sérieux.
On va construire ce projet avec le Spec-Driven Development en utilisant GitHub Spec Kit, qui est déjà initialisé. N'écris PAS de code pour l'instant. Suis ce flux avec moi, en t'arrêtant à chaque checkpoint pour que j'approuve avant d'avancer. Mon projet est : [décris ce que tu veux construire et pour qui, en 3-5 phrases]. Ce qu'il ne doit PAS faire / mes limites : [ex. ne pas enregistrer de cartes bancaires, fonctionner sur mobile, pas de données sensibles dans les logs]. ÉTAPE 1 — CONSTITUTION. Avant tout, lance /speckit.constitution et propose les principes inviolables de ce projet (sécurité, validation des entrées, cohérence, ce qui s'applique). Montre-les-moi et attends mon feu vert. ÉTAPE 2 — SPEC. Ensuite lance /speckit.specify et rédige la spécification à partir de ma description : exigences claires et récits utilisateurs. Puis lance /speckit.clarify et pose-moi TOUTES les questions nécessaires pour éliminer les ambiguïtés — ne devine pas, questionne-moi. Ne continue pas tant que je n'ai pas dit que la spec est correcte. ÉTAPE 3 — PLAN ET TÂCHES. Une fois la spec approuvée, lance /speckit.plan et propose la stack et l'architecture (explique-moi en clair pourquoi tu as choisi chaque chose). Puis /speckit.tasks pour le découpage, et /speckit.analyze pour vérifier que spec, plan et tâches ne se contredisent pas. Montre-moi tout et attends mon approbation. ÉTAPE 4 — IMPLÉMENTER. Seulement quand je l'autorise, lance /speckit.implement et construis. À la fin, génère une /speckit.checklist pour valider que ce qui a été construit remplit la spec. Règle d'or tout au long du processus : la spec est l'unique source de vérité. Si quelque chose dans le code s'écarte de la spec, la spec gagne — ou tu me préviens pour qu'on la mette à jour ensemble. Ne change jamais le comportement en silence.
/speckit.clarify existe justement pour ça : mettre ces suppositions en lumière avant qu'elles deviennent du code.Pour que tu ne te perdes pas : presque tout se passe en parlant à ton IA. Le terminal, tu le touches une seule fois (installer et initialiser). Les /speckit.* tu les écris dans le chat de ton agent, comme n'importe quel autre message. Et la spec tu l'écris dans tes mots — pas en code. Voici la répartition :
uv, installer specify-cli, voir les agents avec specify integration list, lancer specify init mi-proyecto --integration <ton-agent>, et specify self check pour vérifier que tu es à jour. C'est fini — tu ne retournes plus au terminal./speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement. Tu les écris comme des messages normaux./speckit.clarify, et les approbations à chaque checkpoint. Zéro code de ta part.Si tu as suivi la bibliothèque, ça ne te semble pas nouveau — c'est la marche suivante. Le protocole C-A-R t'a appris à séparer construire d'auditer pour ne pas envoyer de bugs. La ressource sur le système de design t'a appris à fixer les règles visuelles avant le premier écran. Les deux partagent une même idée : décide le contrat avant d'exécuter. Le SDD porte cette idée à sa forme la plus pure : la spec est le contrat, et c'est l'unique source de vérité pour toute l'app — design, logique, comportement. Tu passes de "organise ton contexte" à "écris le contrat et laisse l'IA le remplir".
Join 4,200+ builders. No credit card. Build your first app with AI in minutes.