Les modèles ont fait des progrès considérables ces derniers mois. Si vous cadrez bien votre demande et vos instructions, un agent est capable de faire un code propre suivi de ses tests. Mais il est quand même possible qu'il réponde à côté de ce que vous vouliez vraiment.
Ce que je pense vraiment, c'est que même si le modèle est compétent, le problème peut venir de l'intention. L'IA a compris autre chose de ce que vous vouliez faire, et vous finissez par noyer vos informations dans le contexte de la discussion. Ce problème touche d'ailleurs la plus grande partie des personnes adeptes du vibe coding.
GitHub s'attaque au problème avec Spec Kit, un outil open source qui connaît une croissance impressionnante : plus de 126 000 étoiles sur GitHub au moment où j'écris ces lignes.
C'est quoi le Spec-Driven Development ?
Spec Kit repose sur une méthode : le Spec-Driven Development (SDD, ou en français, développement piloté par les spécifications). Le problème avec les agents, ce n'est pas leur capacité à coder, c'est la façon dont on leur envoie les informations.
Il y a plusieurs façons de diriger un agent, vous pouvez même le prendre pour un moteur de recherche avec une phrase vague et c'est parti, il commence à coder. Le SDD propose l'inverse : définir ce que l'on veut construire avant de laisser l'IA écrire le code. Le code n'est qu'une conséquence de la source de vérité : la spécification.
À noter
Le SDD dépasse Spec Kit. Kiro, Tessl sont construits autour de la même idée. Le SDD a même sa page Wikipédia 😎.
Pourquoi Spec Kit ?
C'est vrai que sur les réseaux l'outil fait pas mal parler de lui en cet été 2026. Lancé le 2 septembre 2025, actuellement presque 127 000 étoiles, 11 400 forks, 1 800 commits, et les releases s'enchaînent.
Trois points qui selon moi participent au succès :
-
L'outil est agnostique, il fonctionne avec plus de 30 agents : Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex CLI, Mistral Vibe, Hermes Agent, etc
-
Il répond à un vrai besoin, la frustration du code ou de la fonctionnalité « presque bonne ». Spec Kit propose un cadre
-
Petit bonus, ici on aime Python, et le projet est écrit en Python
Le fonctionnement de Spec Kit
Spec Kit repose sur la CLI specify qui prépare votre projet et un ensemble de templates et de commandes que l'agent va utiliser pour le workflow.
La méthode : des commandes qui produisent chacune un markdown, chaque fichier alimente l'étape suivante. Vous trouverez dans la documentation officielle deux chemins.
Le chemin court pour les petites fonctionnalités :
-
/speckit-specify: transforme une description en spécifications structurées -
/speckit-plan: pour le plan technique (avec notamment votre stack) -
/speckit-tasks: découpe le plan en liste de tâches -
/speckit-implement: exécute les tâches (production du code) -
/speckit-converge: compare le code produit à la spec
Le chemin complet pour la production ajoute des gardes-fous :
-
/speckit-clarifyaprès la spec : pose des questions structurées pour avoir un plan au plus juste -
/speckit-checklistaprès le plan : génère des checklists pour valider les exigences -
/speckit-analyzeaprès les tâches : vérifie la cohérence entre spec, plan et tâches avant l'implémentation
Dans la documentation, vous retrouverez /speckit-constitution, qui définit les principes du projet : standards de code, exigences en tests, contraintes. On la lance au début du projet. La constitution décrit comment on construit, jamais ce qu'on construit. Si votre projet est un e-commerce de poneys, les poneys n'apparaissent pas dans la constitution, ils arrivent dans la spec.
À noter
Vous verrez plusieurs notations, tout dépend du mode d'installation. En mode commands, la commande hérite du nom du fichier avec un .. En mode skills, elle hérite du nom de la skill qui n'accepte que les tirets. Fiez-vous à ce que votre terminal affiche à la fin de specify init, que nous verrons par la suite.
Comment installer Spec Kit ?
Il faut Python 3.11 minimum, Git et un agent 🫡. Pour l'installation, uv est l'idéal. À savoir que Spec Kit fonctionne sous Linux, macOS et Windows.
uv tool install specify-cli
À noter
J'utilise uv tool et non uv add pour installer la commande specify globalement sur mon PC, pas dans l'environnement virtuel du projet.
Vous pouvez vérifier que tout est en place :
specify version
Ma version de specify
Les commandes d'auto-gestion sont pratiques : specify self check et specify self upgrade permettent de vérifier la version et de mettre à jour l'outil.
Initialiser son premier projet
Créons un projet avec l'intégration Claude Code. On en profite pour embarquer l'extension git officielle qui automatise la partie Git du workflow :
specify init demo-speckit --integration claude --extension git
Spec Kit vous demande de choisir le type de scripts qu'il va installer. Ce qui permet de choisir le langage qui sera utilisé pour que Spec Kit fonctionne. C'est transparent pour vous.
Choix du langage pour les scripts
Je vais laisser le choix par défaut : sh (bash shell). Pour Windows, vous avez l'option ps (PowerShell).
Regardons ce que la commande a généré comme dossiers et fichiers :
gabrieltrouve@gabriels-macbook-pro demo-speckit % tree -a . ├── .claude │ └── skills │ ├── speckit-analyze │ │ └── SKILL.md │ ├── speckit-checklist │ │ └── SKILL.md │ ├── speckit-clarify │ │ └── SKILL.md │ ├── speckit-constitution │ │ └── SKILL.md │ ├── speckit-converge │ │ └── SKILL.md │ ├── speckit-git-commit │ │ └── SKILL.md │ ├── speckit-git-feature │ │ └── SKILL.md │ ├── speckit-git-initialize │ │ └── SKILL.md │ ├── speckit-git-remote │ │ └── SKILL.md │ ├── speckit-git-validate │ │ └── SKILL.md │ ├── speckit-implement │ │ └── SKILL.md │ ├── speckit-plan │ │ └── SKILL.md │ ├── speckit-specify │ │ └── SKILL.md │ ├── speckit-tasks │ │ └── SKILL.md │ └── speckit-taskstoissues │ └── SKILL.md └── .specify ├── .gitignore ├── extensions │ ├── .registry │ └── git │ ├── README.md │ ├── commands │ │ ├── speckit.git.commit.md │ │ ├── speckit.git.feature.md │ │ ├── speckit.git.initialize.md │ │ ├── speckit.git.remote.md │ │ └── speckit.git.validate.md │ ├── config-template.yml │ ├── extension.yml │ ├── git-config.yml │ └── scripts │ ├── bash │ │ ├── auto-commit.sh │ │ ├── create-new-feature-branch.sh │ │ ├── git-common.sh │ │ └── initialize-repo.sh │ ├── powershell │ │ ├── auto-commit.ps1 │ │ ├── create-new-feature-branch.ps1 │ │ ├── git-common.ps1 │ │ └── initialize-repo.ps1 │ └── python │ ├── auto_commit.py │ ├── create_new_feature_branch.py │ ├── git_common.py │ └── initialize_repo.py ├── extensions.yml ├── init-options.json ├── integration.json ├── integrations │ ├── claude.manifest.json │ └── speckit.manifest.json ├── memory │ ├── .constitution-template.json │ └── constitution.md ├── scripts │ └── bash │ ├── check-prerequisites.sh │ ├── common.sh │ ├── create-new-feature.sh │ ├── resolve-template.sh │ ├── setup-plan.sh │ └── setup-tasks.sh ├── templates │ ├── checklist-template.md │ ├── constitution-template.md │ ├── plan-template.md │ ├── spec-template.md │ └── tasks-template.md └── workflows ├── speckit │ └── workflow.yml └── workflow-registry.json 33 directories, 58 files
Là où on peut sentir la puissance de l'outil, c'est que Spec Kit installe ses commandes sous forme d'Agent Skills !
Vous remarquerez quinze dossiers dans .claude/skills/, un par commande, chacun son fichier SKILL.md. N'hésitez pas à aller voir mon article sur les skills.
Le dossier .specify/ contient toute la mécanique avec les templates qui seront remplis, les scripts et le fichier constitution.md qui contient les principes de votre projet et extensions.yml qui déclare les hooks de notre extension git.
Comment créer sa première spécification avec Spec Kit ?
Passons à la pratique. Patrick en a assez de relancer ses collègues pour les notes de frais. On va lui construire une petite application Django. Commençons par la constitution (pensez à lancer Claude Code avant) :
/speckit-constitution Principes : gestion des dépendances et de l'environnement virtuel avec uv exclusivement, jamais pip. Qualité de code vérifiée par Ruff, qui corrige aussi l'ordre des imports. Tests systématiques avec pytest, écrits sous forme de fonctions et non de classes. Docstrings rédigées en Gherkin (Given / When / Then). Pas de dépendance sans justification.
Voici le résultat :
Résultat de /speckit-constitution
Vous remarquerez que le dépôt Git est créé via le hook speckit-git-initialize 😎.
Passons maintenant à la spécification, notre besoin :
/speckit-specify Une application qui permet à Patrick de suivre les notes de frais de son équipe. Chaque note a un montant, une date et un statut. Sébastien, de la Direction, valide ou refuse les notes en attente. Limite-toi à trois user stories : soumettre une note, consulter ses notes, valider ou refuser une note en attente.
Résultat de /speckit-specify
L'agent commence par créer une branche dédiée via le hook before_specify, chez moi 001-expense-report-tracking.
L'agent a relevé une contradiction et me demande de clarifier directement la question sur le périmètre de visibilité de Patrick. Je choisis l'option B.
Rapport final de /speckit-specify
La spécification est écrite avec une checklist de qualité :
specs └── 001-expense-report-tracking ├── checklists │ └── requirements.md └── spec.md
N'hésitez pas à aller regarder le fichier spec.md : il contient les trois user stories, les exigences, les critères, etc.
/speckit-clarify n'est pas indispensable dans notre cas, l'agent le dit lui-même : la prochaine étape attendue est celle du plan.
/speckit-plan Django en monolithique, SQLite pour le stockage, montants en DecimalField. Interface via l'admin Django, pas de templates custom.
Résultat avec /speckit-plan
Cette étape génère six fichiers dans le dossier de la fonctionnalité : le plan, mais aussi les décisions techniques, les modèles, les contrats d'interface et les scénarios de validation.
La constitution montre bien son utilité, Claude va faire un check, c'est-à-dire la confronter aux principes. Vous verrez aussi les justifications de l'agent par rapport aux décisions techniques. Et c'est intéressant, l'agent a décidé d'utiliser la dernière version LTS de Django (5.2).
Prenons une seconde pour commiter. Depuis le début, l'agent nous propose de commiter mais nous ne l'avons pas encore fait. Allons-y avec /speckit-git-commit.
/speckit-git-commit
À noter
Le fichier .specify/extensions/git/git-config.yml pilote finement le comportement des hooks pour committer. Par défaut, les entrées auto-commit sont désactivées. Comme dit précédemment, vous lancez manuellement /speckit-git-commit ou activez les entrées qui vous intéressent dans ce fichier de configuration.
Nous pouvons passer à /speckit-tasks qui va produire la liste des tâches, et /speckit-implement qui va les exécuter. Pas besoin d'y ajouter autre chose, le contexte est déjà dans la spec et le plan, mais les deux acceptent un argument optionnel.
Commençons par /speckit-tasks :
Résultat de /speckit-tasks
Le résultat : un tasks.md avec 53 tâches, numérotées et réparties en six phases. L'agent suggère aussi un MVP, ce qui signifie Minimum Viable Product (produit minimum viable). On remarque aussi qu'il signale que le AUTH_USER_MODEL doit être défini avant la première migration. Notre agent est consciencieux 🤓.
Le découpage en tâches ne se contente pas de traduire le plan en liste : il anticipe quoi livrer quand !
Voici une capture d'une partie du tasks.md :
tasks.md
Passons à l'implémentation du MVP :
/speckit-implement Implémente uniquement le MVP : phases 1 à 3, tâches T001 à T026.
Résultat de /speckit-implement
Les tâches MVP sont codées, les tests passent, écrits sous forme de fonction avec des docstrings en Gherkin et ruff a bien été exécuté. L'IA a été rigoureuse sur les tests.
ruff a reformaté les blocs de code Python qui sont dans les markdowns de conception. L'agent l'a détecté, annulé les modifications, et ajouté extend-exclude = [".specify", "specs"] pour que ruff ne touche pas aux fichiers de conception.
Le rapport a signalé bien d'autres choses, mais vous avez compris le principe, pensez à bien relire les rapports pour voir ce qui a été fait et améliorer vos prochains workflows avec Spec Kit.
Je n'ai pas envie de m'en tenir à un MVP, c'était l'occasion de vous montrer qu'on peut guider l'implémentation plutôt que de tout lancer d'un bloc. Terminons le projet :
/speckit-implement Implémente les tâches restantes : T027 à T053.
Implémentation finale
Les tests, ruff, tout est ok sauf la revue humaine. L'agent a déroulé les scénarios de validation avec des données de démonstration. Les bugs trouvés ont été corrigés. Je ne vais pas vous détailler le rapport que j'ai mis ci-dessus, mais l'agent ne vous laisse pas dans l'ignorance 💡.
Sebastien peut valider ou refuser une note de frais
Attention
Les quatre premières étapes de constitution, spécification, plan, tâches produisent du markdown qu'il faut relire et corriger. Corrigez l'intention avant de coder, l'IA produit un code très propre si vous prenez les derniers modèles, mais c'est à vous de faire en sorte qu'elle code ce que vous voulez.
Avant de nous quitter, je voulais évoquer la skill speckit-taskstoissues : elle permet de transformer les tâches en issues GitHub.
