---
title: 'GitHub Spec Kit : cadrer ton agent de code avec des spécifications'
description: "Spec Kit, l'outil open source de GitHub, fait passer ton agent de code par une constitution, une spécification, un plan et des tâches avant d'écrire la première ligne ; voici l'installation et le cycle complet."
pubDate: 2026-11-04
family: 'intelligence-artificielle'
tags: [GitHub]
heroImage: /images/github-spec-kit-cadrer-ton-agent-de-code-avec-des-specifications.webp
heroImageAlt: "Miniature de la vidéo GitHub Spec Kit : L'IA code mieux quand on arrête d'improviser"
videoUrl: 'https://www.youtube.com/watch?v=zXwt0-XZ6-8'
faq:
  - question: 'Spec Kit fonctionne-t-il avec Claude Code, Codex ou Gemini ?'
    answer: "Oui. `specify init` accepte une intégration via `--integration` : les exemples de la documentation officielle couvrent `copilot`, `claude`, `codex`, `gemini`, `codebuddy`, `vibe` et `generic` pour un agent maison. Chaque intégration installe ses propres commandes ou skills, avec sa syntaxe d'appel."
  - question: 'Faut-il uv pour installer Spec Kit ?'
    answer: 'uv est la méthode recommandée par la documentation depuis v1.3.0, mais pas la seule : `pipx install specify-cli` et `pip install specify-cli` sont documentés comme alternatives. Il faut Python 3.11 ou plus. Pour une exécution ponctuelle sans installation, uv propose un mode `uvx`.'
  - question: "Spec Kit écrit-il le code à la place de l'agent ?"
    answer: "Non. Spec Kit installe un processus, des templates, des scripts et des commandes dans ton projet ; c'est toujours ton agent de code (Copilot, Claude Code, Codex, Gemini…) qui exécute chaque étape. Les skills s'appellent dans le chat de l'agent, une par une, et tu valides le résultat avant de continuer."
---

GitHub a publié [Spec Kit](https://github.com/github/spec-kit), un outil open source sous licence MIT qui applique une idée simple : si ton agent de code produit du code approximatif, le problème est souvent dans la demande, pas dans le modèle. Plutôt que d'empiler un prompt de plus, le projet impose un **Spec-Driven Development (SDD)** : on écrit d'abord ce qu'on veut construire, on en dérive un plan technique, on découpe le travail en tâches, et seulement ensuite on laisse l'agent coder.

La vidéo présente les concepts puis passe à une démonstration : transformer une idée en spécification, plan et tâches avant l'implémentation. Cette page reprend le cadre et l'installation, avec les commandes telles que la documentation officielle les décrit aujourd'hui.

## Ce que Spec Kit installe réellement

Spec Kit n'est pas un agent de code. C'est une boîte à outils de processus : des commandes, des templates Markdown, des scripts et une constitution de projet, posés dans ton dépôt. Ton agent habituel — Copilot, Claude Code, Codex, Gemini — reste celui qui exécute le travail.

L'intérêt pratique tient à trois choses :

- les étapes sont explicites et vérifiables une par une, au lieu d'un unique prompt qui doit tout contenir ;
- les artefacts (spécification, plan, tâches) restent des fichiers Markdown relus par un humain ;
- les commandes ne repartent pas de zéro à chaque session : elles lisent l'état du projet.

C'est cette dernière partie qui change le plus la donne. Spec Kit stocke la fonctionnalité active dans `.specify/feature.json` (surchargeable par la variable `SPECIFY_FEATURE_DIRECTORY`) et résout le contexte à partir de ce fichier, **pas** de la branche Git. Pas besoin de Git pour l'utiliser ; l'extension `git` optionnelle ajoute seulement des branches numérotées.

## Prérequis et installation

La documentation demande **Python 3.11 ou plus**, [uv](https://docs.astral.sh/uv/) pour la gestion des paquets, et un agent de code pris en charge sur Linux, macOS ou Windows. `uv` est la méthode recommandée, pas la seule : `pipx` et `pip` sont documentés comme alternatives pour une installation persistante, et uv propose un mode ponctuel sans installation.

```bash
uv tool install specify-cli
specify init mon-projet --integration copilot
cd mon-projet
```

`init` choisit l'intégration de façon interactive, ou la reçoit via `--integration`. Les exemples officiels couvrent `copilot`, `claude`, `codex`, `gemini`, `codebuddy`, `vibe` et `generic` (agent maison, avec `--commands-dir`). En environnement non interactif — CI, agent —, ajoute `--non-interactive` : sans cela, `init` attend une sélection qui ne viendra jamais.

**Vérification réellement exécutée pour cet article.** Sur un environnement Linux sans `uv`, j'ai installé `specify-cli` depuis PyPI dans un environnement virtuel Python (`pip install specify-cli`, version **1.3.0**, publiée le 3 novembre 2026), puis lancé :

```bash
specify --version
# specify 1.3.0

specify init skdemo --integration copilot --non-interactive --script sh
```

`init` a terminé sans erreur et généré l'arborescence attendue. Limite du test : seule l'initialisation du projet a été vérifiée ; les skills de Spec Kit n'ont pas été exécutés, puisqu'ils se lancent dans le chat d'un agent et non dans le terminal.

## Le cycle SDD, étape par étape

Chaque commande est une étape, invoquée dans le chat de l'agent, **une par une**, en relisant le résultat avant de continuer. Deux parcours cohabitent : un chemin court pour les petites fonctionnalités, et un chemin complet qui ajoute trois garde-fous de qualité.

**Chemin court** : `specify` → `plan` → `tasks` → `implement` → `converge`.

**Chemin complet**, avec les portes de qualité :

```text
/speckit-constitution  (une fois par projet)
/speckit-specify
/speckit-clarify
/speckit-plan
/speckit-checklist
/speckit-tasks
/speckit-analyze
/speckit-implement
/speckit-converge
```

Le rôle de chacune :

- **constitution** — fixe les principes du projet (qualité, tests, maintenabilité). Toutes les étapes suivantes sont évaluées par rapport à eux.
- **specify** — transforme une description en langage naturel en spécification : le _quoi_ et le _pourquoi_, sans empiler la pile technique. C'est l'étape strictement indispensable avant `plan`.
- **clarify** — pose jusqu'à cinq questions ciblées sur les zones floues et réinjecte tes réponses dans la spécification. À lancer avant de planifier.
- **plan** — génère les artefacts de conception à partir de la spécification ; c'est ici qu'on donne la pile technique et l'architecture.
- **checklist** — produit une checklist qualité, décrite comme des « tests unitaires pour tes exigences » : elle vérifie que la spécification est complète et non ambiguë, pas que le code est écrit.
- **tasks** — génère un `tasks.md` ordonné par dépendances, découpé en phases (Setup, Foundational, une phase par user story, Polish).
- **analyze** — analyse en lecture seule la cohérence entre `spec.md`, `plan.md` et `tasks.md`, et signale conflits, trous et ambiguïtés.
- **implement** — exécute les tâches dans l'ordre des dépendances. Pour une grosse fonctionnalité, on peut la limiter à une phase par invocation.
- **converge** — compare le code produit aux artefacts. S'il trouve des manques, il **ajoute** des tâches à `tasks.md` (jamais de suppression), et tu rejoues `implement` puis `converge` jusqu'au verdict `Converged`.

Un point de vocabulaire utile si tu retrouves d'autres tutoriels : le contenu de la vidéo nomme les étapes `specify`, `plan`, `tasks`, `implement` et cite `constitution.md`, `spec.md`, `plan.md`. Depuis les versions 1.x, la documentation écrit ces commandes sous la forme `/speckit.constitution`, `/speckit.specify` ou `/speckit.plan`, affichées `speckit-constitution` et `speckit-specify` sous Copilot ; Codex utilise un préfixe `$` et Kimi un préfixe `/skill:`. Il s'agit du même processus, avec une syntaxe d'appel variable d'un agent à l'autre.

## Où vivent les fichiers

Après `init`, le projet contient les briques suivantes (arborescence observée sur le test ci-dessus) :

- `.github/skills/` — une skill par étape du processus (`speckit-constitution`, `speckit-specify`, etc.), pour l'intégration choisie ;
- `.specify/memory/constitution.md` — la constitution, créée depuis un template à compléter ;
- `.specify/templates/` — les gabarits `spec`, `plan`, `tasks`, `checklist` et `constitution` ;
- `.specify/scripts/bash/` — les scripts d'automatisation (variantes PowerShell et Python également fournies) ;
- `.specify/integration.json` — l'intégration installée et sa version.

Au fil du travail, les étapes écrivent la spécification, le plan et les tâches dans un dossier par fonctionnalité : `/specs/[###-feature-name]/spec.md`, `plan.md` et `tasks.md`. Tu peux donc relire et corriger ces fichiers à la main, ou demander à l'agent de le faire, sans relancer l'étape entière.

## Vérifier le travail de l'agent

C'est l'apport le plus concret pour limiter les dérives :

- `analyze` est **en lecture seule** : il ne modifie rien et sert à corriger les artefacts au bon endroit avant de coder. S'il signale un problème d'exigence, retourne à `specify` ou `clarify` ; un problème de conception se règle dans `plan`.
- `converge` est **append-only** : il ne touche pas au code et ne peut qu'ajouter des tâches. Tant qu'il répond « Tasks appended », il reste du travail à faire.
- les checklists personnalisées appartiennent au relecteur : cocher un élément signifie que la qualité de l'exigence est validée, **pas** que l'implémentation est terminée. À ne pas confondre avec une CI verte.

## Limites et erreurs courantes

- **Ces étapes ne remplacent pas les tests.** Spec Kit organise la demande et la vérification documentaire ; il n'exécute pas ta suite de tests à ta place et ne garantit pas qu'un code généré est correct.
- **Une version ancienne de la CLI casse les commandes récentes.** La documentation note qu'avec une 0.1.6, `specify init --integration …` échoue (`No such option: --integration`) et `--ai` échoue aussi. Compare `specify version` à la dernière version sur PyPI, et remets à niveau avec l'outil qui a fait l'installation.
- **Ne lance pas les skills dans le terminal.** Seule l'installation et l'initialisation s'y font ; les skills de Spec Kit vivent dans le chat de l'agent.
- **Le contexte de l'agent reste une contrainte.** Sur une grosse fonctionnalité, mieux vaut implémenter phase par phase plutôt que tout d'un coup.
- **Les templates sont des documents, pas un garde-fou automatique.** Rien n'empêche techniquement de passer à l'implémentation avec une spécification incomplète : c'est à toi de relire.

## À qui ça sert

Spec Kit a du sens si tu attends de ton agent de code autre chose que du code plausible : une fonctionnalité tracée, relue, dont on sait d'où viennent les décisions. Il n'apporte rien de plus qu'un prompt correctement rédigé si ta demande tient en une phrase, ni sur un projet où personne ne relira les artefacts. Dans le doute, commence par la version courte du cycle (`specify` → `plan` → `tasks` → `implement`), puis ajoute `clarify`, `checklist` et `analyze` quand les allers-retours coûtent plus cher que ces relectures.

Le [parcours agents IA et outils de code](/blog/agents-ia-code/) rassemble les autres approches de ce site, dont les workflows Claude Code et Copilot.

Pour voir l'installation et la démonstration de bout en bout, regarde la vidéo complète sur la chaîne Pentiminax.

_Note de sources : la transcription française de la vidéo n'était pas disponible au moment de la rédaction ; cet article s'appuie sur la description officielle de la vidéo et sur la documentation officielle de Spec Kit (v1.3.0), complétés par le test d'initialisation décrit plus haut._

## Questions fréquentes

**Spec Kit fonctionne-t-il avec Claude Code, Codex ou Gemini ?**

Oui. `specify init` accepte une intégration via `--integration` : les exemples de la documentation officielle couvrent `copilot`, `claude`, `codex`, `gemini`, `codebuddy`, `vibe` et `generic` pour un agent maison. Chaque intégration installe ses propres commandes ou skills, avec sa syntaxe d'appel.

**Faut-il uv pour installer Spec Kit ?**

uv est la méthode recommandée par la documentation depuis v1.3.0, mais pas la seule : `pipx install specify-cli` et `pip install specify-cli` sont documentés comme alternatives. Il faut Python 3.11 ou plus. Pour une exécution ponctuelle sans installation, uv propose un mode `uvx`.

**Spec Kit écrit-il le code à la place de l'agent ?**

Non. Spec Kit installe un processus, des templates, des scripts et des commandes dans ton projet ; c'est toujours ton agent de code (Copilot, Claude Code, Codex, Gemini…) qui exécute chaque étape. Les skills s'appellent dans le chat de l'agent, une par une, et tu valides le résultat avant de continuer.