Le Spec-Driven Development

Spec Kit repose sur le concept de Spec-Driven Development (SDD). Les agents savent coder, et la qualité du résultat dépend de notre façon de communiquer avec eux. Le SDD propose de définir ce que l'on veut développer avant de laisser l'IA coder. Le code devient une conséquence de la source de la spécification.

La philosophie dépasse Spec Kit : Kiro (AWS) ou Tessl appliquent la même idée.

Pourquoi Spec Kit

Trois raisons expliquent son adoption depuis son lancement le 2 septembre 2025 :

  • il est agnostique et fonctionne avec plus de 30 agents (Claude Code, GitHub Copilot, Cursor...)
  • il répond à un vrai besoin, celui du code qui fonctionne presque
  • il est écrit en Python

Le fonctionnement

Spec Kit s'installe via la CLI specify, qui pépare un ensemble de templates et de commande que l'agent pourra utiliser.

Le chemin court, pour les petites fonctionnalités :

  • /speckit-specify transforme une description en spécification structurée
  • /speckit-plan produit le plan technique avec la stack
  • /speckit-tasks découpe en liste de tâches
  • /speckit-implement exécute les tâches, c'est là que le code est produit
  • /speckit-converge compare le code produit à la spec

Le chemin complet ajoute des garde-fous pour la production :

  • /speckit-clarify pose des questions structurées après la spec
  • /speckit-checklist génère des checklists après le plan
  • /speckit-analyze vérifie la cohérence avant d'implémenter

Une commande à part, /speckit-constitution, définit les principes du projet : standards de code, exigences de tests, contraintes techniques. Le contenu métier appartient toujours aux specs.

Installation

Prérequis : Python 3.11+, Git et un agent.

uv tool install specify-cli
specify version

specify self check et specify self upgrade permettent de vérifier la version et de mettre à jour l'outil.

L'initialisation d'un projet précise l'agent utilisé et les extensions :

specify init demo-speckit --integration claude
cd demo-speckit
specify extension add git

Cette commande génère des fichiers, dont des Agent Skills dans .claude/skills/ et toute la mécanique dans .specify/.

Le flux complet sur un exemple

Utilisons une application de suivi de notes de frais, comme ça vous n'aurez plus d'excuses si les vôtres sont en retard 😛.

La constitution permet de poser les principes techniques du projet :

/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.

La spécification de décrire le besoin métier, nul besoin de mot technique :

/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.

L'agent crée une branche via le hook before_specify (du genre 001-expense-report-tracking), détecte les contradictions et pose ses questions de clarification. La sortie atterrit dans un dossier de specs :

specs
└── 001-expense-report-tracking
    ├── checklists
    │   └── requirements.md
    └── spec.md

Le plan injecte les choix techniques :

/speckit-plan Django en monolithique, SQLite pour le stockage,
montants en DecimalField. Interface via l'admin Django, pas de
templates custom.

Six fichiers sont crées : plan, décisions techniques, modèles, contrats d'interface et scénarios de validation.

Les tâches découpent le plan. /speckit-tasks produit ici un tasks.md de 53 tâches numérotées en six phases (pour ma part), avec un MVP identifié. L'implémentation peut alors se faire en tranches :

/speckit-implement Implémente uniquement le MVP : phases 1 à 3,
tâches T001 à T026.

Puis le reste (T027 à T053), avant un /speckit-git-commit qui gère les commits selon la configuration de .specify/extensions/git/git-config.yml. Un skill complémentaire permet transformer les tâches en issues GitHub : specify extension add github, puis /speckit-github-taskstoissues.

Relire avant de coder

Les quatre premières étapes (constitution, spécification, plan, tâches) produisent du markdown, et pas besoin de vous préciser que ce markdown doit être relu et corrigé avant de lancer l'implémentation. C'est tout l'intérêt de la méthode : corriger l'intention avant de coder. Les derniers modèles produisent un code très propre ; faire en sorte qu'ils codent ce que vous voulez, c'est votre travail, ça dépend de la qualité des markdowns.

Mon avis

Spec Kit formalise ce que les gens qui travaillent bien avec les agents font déjà à la main : écrire ce qu'on veut avant de demander du code, séparer le besoin métier des choix techniques, autrement dit, se créer un harnais solide. L'apport de l'outil, c'est la discipline que vous imposez à vous-même et à l'agent. Les commandes forcent à passer par chaque étape, et les markdown laissent une trace relisable qui survit à la session de l'agent.

Un outil très intéressant à surveiller de près. En tout cas, de mon côté, c'est déjà ce que je fais plus ou moins quand je développe un projet.