Le Spec-Driven Development

Spec Kit repose sur le Spec-Driven Development (SDD). Le constat de départ tient en une phrase : les agents savent coder, et la qualité du résultat dépend surtout de la façon dont on leur communique l'intention. Le SDD propose de définir ce que l'on veut construire avant de laisser l'IA écrire le code. Le code devient une conséquence de la source de vérité, qui est la spécification.

La philosophie dépasse Spec Kit lui-même : Kiro (AWS) ou Tessl appliquent la même idée avec leurs propres outils.

Pourquoi celui-là

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 « presque bon » qu'on passe son temps à réorienter ;
  • il est écrit en Python.

Le fonctionnement

Spec Kit s'installe via la CLI specify, qui dépose dans le projet des templates et des commandes en markdown. Ces commandes s'enchaînent ensuite dans l'agent.

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 le tout 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 de l'ensemble avant d'implémenter.

Une commande à part, /speckit-constitution, définit les principes du projet : standards de code, exigences de tests, contraintes techniques. Elle ne porte jamais le contenu métier, qui appartient aux specs.

Installation

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

uv tool install specify-cli
specify version

La CLI se gère elle-même avec specify self check et specify self upgrade.

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

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

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

Le flux complet sur un exemple

Une application de suivi des notes de frais illustre l'enchaînement.

La constitution pose les principes techniques du projet, une fois pour toutes :

/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 décrit le besoin métier, sans un mot de 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 dédiée via le hook before_specify (du type 001-expense-report-tracking), détecte les contradictions dans la demande 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 en sortent : 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, 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, speckit-taskstoissues, peut aussi transformer les tâches en issues GitHub.

Relire avant de coder

Les quatre premières étapes (constitution, spécification, plan, tâches) produisent du markdown, et ce markdown doit être relu et corrigé avant de lancer l'implémentation. C'est le cœur 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, et il se joue dans ces fichiers.

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, découper en tranches vérifiables. L'apport de l'outil, c'est la discipline. Les commandes forcent à passer par chaque étape, et les artefacts markdown laissent une trace relisable qui survit à la session de l'agent.

Le coût est réel : pour une petite correction, dérouler constitution, spec, plan et tâches est disproportionné, et le chemin court reste plus lourd qu'un simple prompt. Là où la méthode paie, c'est sur les fonctionnalités qui demanderaient plusieurs allers-retours de recadrage avec l'agent. Chaque minute passée à corriger le markdown en amont économise des cycles de code à jeter en aval.