Spec Kit de GitHub : la spécification comme contrat, en sept commandes

Spec Kit est le toolkit open source de GitHub pour le spec-driven development : la spécification fait office de contrat, le code en dérive, et des points de relecture recommandés jalonnent chaque artefact². Il s'adresse aux équipes qui veulent plus de structure que le vibe coding, sur du greenfield comme sur du code existant. Le 21 août 2026, un an jour pour jour après sa première release publique, le projet a livré sa version 1.0¹. L'article chapeau de la série le compare à huit autres méthodes sur une même grille, le SDLC augmenté par l'IA de SFEIR.

D'où vient Spec Kit

Spec Kit est un projet de GitHub (Microsoft), publié sous licence MIT¹. Den Delimarsky l'a présenté sur le blog de GitHub le 2 septembre 2025⁴. Le 21 août 2026, GitHub publie les versions 1.0.0 et 1.0.1 le même jour¹ ; la 1.0.8 suit le 17 septembre. Les étoiles GitHub, à lire avec leur date : 127 800 le 14 août 2026 selon Wavect⁵, 132 000 en août 2026 selon Vibecoding⁶. Le projet revendique plus de trente intégrations d'agents, dont GitHub Copilot, Claude Code, Gemini CLI, Cursor et Codex¹.

La surface de commandes a bougé en un an : le préfixe est désormais /speckit.*, la ligne 0.16 installe les skills par défaut, et la 0.10.0 avait retiré les flags --ai, cassant les tutoriels antérieurs¹. Spec Kit propose trois processus indépendants : le spec-driven development (SDD) dans le cœur, le bug fixing et l'idea assessment en extensions optionnelles³. La grille SFEIR ne capture que le chemin SDD.

Le cycle SDD en sept temps

L'installation passe par uv tool install specify-cli puis specify init³. Le cycle enchaîne sept commandes, chacune avec son porteur³ :

• 1 Constitution (l'équipe) : les règles non négociables du projet.
• 2 Specify (agent et humain) : la spécification fonctionnelle, centrée sur le quoi et le pourquoi.
• 3 Clarify (l'humain répond) : un point de contrôle recommandé avant la planification.
• 4 Plan (agent et humain) : le plan technique.
• 5 Tasks (agent) : le découpage en tâches.
• 6 Analyze (agent et humain) : une vérification de cohérence.
• 7 Implement (agent et développeur) : l'exécution.

L'exécution reste séquentielle : les tâches tournent une à une, sans parallélisation native³.

Lecture dans la grille SFEIR

Sur le cycle SFEIR à onze phases, Spec Kit couvre l'amont et le cœur de construction.

Étape Spec Kit	Étape(s) de la grille SFEIR
Constitution	0 Setup
Specify	1 Define
Clarify	1 Define (contrôle)
Plan	2 Plan
Tasks	2 Plan
Analyze	5 Review (contrôle)
Implement	3 Build, 4 Verify

Constitution joue le rôle de Setup ; Specify et Plan portent Define et Plan, Clarify et Analyze servent de points de contrôle avant qu'Implement exécute. Spec Kit ne prévoit aucune capitalisation entre deux cycles, là où SFEIR en nomme deux, Compound-1 et Compound-2. Ship, Ops et Deprecation restent hors champ.

Son parti pris : l'intention comme source de vérité

Le document de philosophie du projet passe de « code is the source of truth » à « intent is the source of truth »². Les points de relecture recommandés (clarify, checklist, analyze) donnent des endroits où rejeter ou affiner avant que le code ne se multiplie. Les specs sont des fichiers Markdown diffables, versionnés comme du code².

Forces, limites et angles morts

Côté forces : la distribution et la marque GitHub, une structure tangible face au vibe coding, et zéro surcoût de modèle (on apporte son propre agent)⁵. Côté limites : le processus est lourd, et les documents gouvernent le code par convention, sans mécanisme qui l'impose. La critique la plus nette est celle de Colin Eberhardt (Scott Logic), le 26 novembre 2025 : « Radical Idea or Reinvented Waterfall? »⁷. D'autres retours pointent la « mer de markdown », le temps passé à corriger des specs générées et l'inadéquation aux travaux exploratoires. Sur des systèmes brownfield multi-modules, la structure produit du volume plus que de la fidélité⁹.

Quand choisir Spec Kit

Spec Kit se justifie sur des fonctionnalités conséquentes, du travail à plusieurs ou un cadre réglementé ; un prototype jetable ou une petite correction ne rentabilise pas sept étapes⁸. Démarche prudente : piloter sur trois à cinq fonctionnalités représentatives, mesurer temps de clarification, défauts échappés et retouches, et garder tests, revue de sécurité et approbation humaine hors du modèle. Dans la même famille, Kiro porte le spec-driven dans l'IDE d'AWS, et OpenSpec vise le brownfield léger⁹.

Ce que le SDLC SFEIR en retient

SFEIR retient la spec comme contrat et les points de contrôle jalonnés. Le cycle SFEIR y ajoute des gates humains formels (Plan isolé, Ship), une capitalisation en deux temps et la couche aval (Ship, Ops, Deprecation) que Spec Kit laisse hors champ.

Sources

1. GitHub, dépôt spec-kit, consulté en septembre 2026. github.com
2. GitHub, « Spec-Driven Development », document de philosophie du projet. github.com
3. GitHub, documentation officielle Spec Kit. github.github.io
4. Den Delimarsky, « Spec-driven development with AI: Get started with a new open source toolkit », The GitHub Blog, 2 septembre 2025. github.blog
5. Wavect, « GitHub Spec Kit Review for Production Teams », 14 août 2026. wavect.io
6. Vibecoding, « GitHub Spec Kit Review (2026): Spec-Driven Dev for AI Coding », mise à jour d'août 2026. vibecoding.app
7. Colin Eberhardt (Scott Logic), « Putting Spec Kit Through Its Paces: Radical Idea or Reinvented Waterfall? », 26 novembre 2025. blog.scottlogic.com
8. CodeMySpec, « GitHub Spec Kit: How It Works and When to Use It (2026) », 3 juin 2026. codemyspec.com
9. GitHub, discussion « Pros and Cons of Spec Kit compared to OpenSpec, Greenfield/Brownfield development », janvier 2026. github.com