En quelques jours seulement après sa publication, le dépôt GitHub Spec Kit a dépassé les 100 000 étoiles et récolté plus de 8 000 forks. Des chiffres qui ne s’expliquent pas par un effet de mode, mais par la reconnaissance collective d’un problème bien réel que tout développeur travaillant avec l’IA a déjà rencontré. Si tu as déjà lu notre article sur les risques d’une application vibe codée par un néophyte, tu sais que le problème dépasse largement le simple manque de compétences : c’est l’approche elle-même qui est en cause.
Le vrai problème avec les agents de code IA
Alors que les agents de code sont devenus de plus en plus puissants, un schéma est apparu : tu décris ton objectif, tu reçois un bloc de code en retour, et souvent… il semble correct, mais ne fonctionne pas tout à fait. Cette approche de vibe coding peut convenir pour des prototypes rapides, mais se révèle peu fiable dès qu’il s’agit de construire une application sérieuse ou de travailler sur une base de code existante.
GitHub le résume parfaitement dans son annonce : « Nous traitons les agents de code comme des moteurs de recherche alors que nous devrions les traiter davantage comme des développeurs en binôme au pied de la lettre. » Le problème n’est pas la capacité du modèle. C’est la façon dont on lui soumet le travail.
GitHub Spec Kit : qu’est-ce que c’est exactement ?
GitHub Spec Kit est un toolkit open source (licence MIT) qui introduit le Spec-Driven Development (SDD) (le développement piloté par la spécification) dans vos workflows d’agents IA. Au lieu de coder en premier et d’écrire la documentation après, tu commences par une spécification précise qui devient la source de vérité que les outils IA utilisent pour générer, tester et valider le code.
Il est compatible avec GitHub Copilot, Claude Code, Gemini CLI, Cursor, Codex et plus de 25 agents. L’installation se fait via une simple commande CLI :
uvx --from git+https://github.com/github/spec-kit.git specify init <NOM_PROJET>Les 4 phases du workflow Spec Kit
Le processus s’articule autour de quatre phases ordonnées et validées. On ne passe pas à l’étape suivante sans avoir validé la précédente : c’est précisément ce qui élimine les dérives habituelles des agents IA.
/specify — Décrire le « quoi », pas le « comment »
Tu fournis un prompt de haut niveau sur tes objectifs et tes parcours utilisateurs. L’agent rédige une spécification détaillée qui évolue avec tes retours. Tu parles du besoin, pas de la stack.
/plan — Choisir l’architecture et les contraintes
Tu déclares ici la direction technique : stack, architecture, contraintes organisationnelles. L’agent génère un plan détaillé qui respecte tes standards. Tes exigences de sécurité ou ton design system ne sont plus des réflexions après coup : ils sont intégrés dès cette étape.
/tasks — Découper en tâches atomiques
L’agent décompose le travail en unités petites, révisables et testables de façon isolée, ordonnées par dépendances. Fini le bloc de code monolithique incompréhensible.
/implement — L’agent construit
L’agent implémente en suivant la spécification à chaque étape. Il sait exactement quoi construire, dans quel ordre et pourquoi.
Un élément particulièrement utile est le fichier constitution.md, qui permet de définir des règles non négociables avant que l’implémentation commence — toujours exiger des tests, adhérer à un framework précis, interdire certaines dépendances. Plus question que l’agent ignore tes conventions internes.
Une spécification vivante, pas un document mort
Ce qui distingue Spec Kit d’une simple liste de requirements, c’est le caractère exécutable de la spécification. Le SDD inverse le paradigme traditionnel : pendant des décennies, les spécifications étaient des échafaudages que l’on construisait et jetait une fois le « vrai travail » de codage commencé. Avec Spec Kit, elles deviennent le cœur du processus : elles génèrent directement des implémentations fonctionnelles plutôt que de simplement les guider.
La nature itérative de cette approche est ce qui lui donne sa vraie puissance. Là où le développement traditionnel vous enferme dans des décisions précoces, le spec-driven simplifie le changement de cap : il suffit de mettre à jour la spécification, de regénérer le plan, et de laisser l’agent gérer le reste. C’est d’ailleurs en parfaite cohérence avec ce que nous évoquions dans notre article sur les agents IA et le second cerveau : un agent n’est efficace que si tu lui fournis un contexte structuré et des instructions claires. Spec Kit industrialise exactement cela.
Pour qui est fait Spec Kit ?
GitHub identifie trois cas d’usage principaux. Pour les projets greenfield, démarrer avec une spécification garantit que l’IA construit ce que tu veux vraiment, et non une solution générique basée sur des patterns communs. Sur les bases de code existantes, l’agent comprend le contexte avant de toucher au code, ce qui réduit drastiquement les régressions. En travail d’équipe, la spécification devient le référentiel partagé entre développeurs utilisant des outils IA différents.
Un projet expérimental, mais déjà incontournable
L’équipe de GitHub est claire : Spec Kit reste un projet expérimental et cherche activement des retours de la communauté. Mais avec +100 000 étoiles en quelques jours et des forks provenant d’IBM ou d’autres grandes organisations, le signal est fort.
La vraie question n’est plus « faut-il adopter le spec-driven development ? » mais « pourquoi ne pas l’avoir fait avant ? »