# Configurer Spec Kit dans Claude Code en 2026 : des spécifications plutôt que des prompts
> Comment configurer GitHub Spec Kit dans Claude Code : 4 phases — Specify, Plan, Tasks, Implement. AWS rapporte plus de 80 heures économisées sur une fonctionnalité grâce à Kiro.
Source: https://ailoot.ai/blog/fr/spec-kit-claude-code-spec-driven-development/
Canonical: https://ailoot.ai/blog/fr/spec-kit-claude-code-spec-driven-development/
Language: fr
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-219
Revision: sha256-749da3d2ef32d4342ba2defd8c499e1a517387c85a1412d30fa00bd74385b90e
À retenir
Spec Kit est un outil de GitHub qui permet de rédiger une spécification de tâche en langage naturel. Claude Code élabore ensuite un plan, le décompose en tâches et écrit le code. Ce n’est pas de la théorie : 107 000 étoiles GitHub en 8 mois et AWS a utilisé cette méthode pour construire un projet de découverte de médicaments en 3 semaines au lieu de plusieurs mois. Ce guide couvre l’installation, les modèles, les 4 phases du workflow et une vérification finale, ainsi que la façon de le relier à votre CLAUDE.md.
[Documentation Ailoot](https://ailoot.ai/docs/) — ressources de référence sur l’utilisation du service.
## Que s’est-il passé avec le vibe coding en mai 2026 ?
À retenir
GitHub Spec Kit a recueilli 107 000 étoiles en 8 mois. En février 2026, AWS a publié une étude de cas faisant état de plus de 80 heures économisées sur une fonctionnalité. La tendance du moment en mai : la spécification comme remplacement de l’improvisation.
Un an plus tard, le 4 février 2026, il a publié un fil rétrospectif :
Lors de son intervention à Sequoia Ascent 2026, il l’a formulé encore plus précisément : « Le vibe coding élève le plancher — ce que chacun peut faire en logiciel. L’ingénierie agentique préserve le plafond — le niveau de qualité du développement professionnel. » Sur la même scène, il a lancé une phrase entrée dans le lexique du secteur : « On ne peut pas introduire de vulnérabilités à cause du vibe coding. Vous restez responsable de votre logiciel, comme avant. »
Deux choses se sont produites en parallèle. En septembre 2025, GitHub a publié l’outil [Spec Kit](https://github.com/github/spec-kit), qui a recueilli 107 000 étoiles en 8 mois. En février 2026, AWS a publié [une étude de cas détaillée sur la découverte de médicaments](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) faisant état de « 95 % de logique métier générée à partir de la spécification, soit plus de 80 heures économisées ».
Fin mai 2026, un consensus s’était formé dans l’espace anglophone : le vibe coding comme méthode de travail est le niveau débutant. Le Spec-Driven Development vient ensuite. Ce guide explique comment installer et appliquer cette approche.
## À quoi sert GitHub Spec Kit dans Claude Code ?
À retenir
Le Spec-Driven Development (SDD) inverse l’approche habituelle d’un agent IA. Auparavant, le code était la source de vérité et la spécification un document d’accompagnement. Désormais, la spécification est la source de vérité et le code devient l’étape finale : sa mise en œuvre. Spec Kit est un outil CLI de GitHub qui transforme les 4 phases (Specify, Plan, Tasks, Implement) et une vérification finale Converge en commandes prêtes à l’emploi dans Claude Code, Cursor, Copilot et plus de 30 autres agents.
L’idée centrale de la méthode tient en une phrase tirée de la documentation officielle de GitHub :
Le Spec-Driven Development change la hiérarchie : les spécifications ne sont pas au service du code, c’est le code qui est au service des spécifications. La spécification devient l’artefact principal et le code en est l’expression dans un langage et un framework particuliers.
— Documentation GitHub Spec Kit, https://github.com/github/spec-kit/blob/main/spec-driven.md
Dans la pratique, cela se déroule en 4 phases (Spec Kit en ajoute une autre, la phase zéro — la constitution, décrite ci-dessous) :
1. **Specify** - rédigez en langage naturel une spécification de ce que vous voulez. QUOI faire et POURQUOI. Pas COMMENT.
2. **Plan** - l’agent prend la spécification et élabore un plan technique : quelles technologies, quelle architecture et quels composants.
3. **Tasks** - l’agent décompose le plan en tâches précises et vérifiables, avec leurs dépendances.
4. **Implement** - l’agent (ou ses sous-agents) exécute les tâches et écrit le code.
Après Implement, la version actuelle de Spec Kit comporte une étape de vérification appelée **Converge** : l’agent compare le code terminé à la spécification, au plan et aux tâches, puis ajoute dans `tasks.md` tout élément manquant. Exécutez Implement et Converge en boucle jusqu’à ce que Converge réponde « Converged ».
Chaque phase est un fichier Markdown distinct dans le dépôt. Chaque phase est une commande slash distincte dans Claude Code : `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement`, tandis que la vérification est `/speckit-converge`. La documentation de Spec Kit écrit les mêmes commandes avec un point (`/speckit.specify`), mais dans Claude Code Spec Kit les installe sous forme de skills, appelées avec un trait d’union. Si quelque chose ne va pas à une étape, modifiez le fichier Markdown et relancez la phase suivante.
Spec Kit est une mise en œuvre particulière du SDD. En mai 2026, il comptait déjà plus de 30 intégrations avec différents agents IA. Dans un même dépôt, Spec Kit fonctionne de la même façon avec Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose et une douzaine d’autres.
| Phase Spec Kit | Commande slash | Artefact dans le dépôt |
|----|----|----|
| Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` |
| Specify | `/speckit-specify` | `specs/###-feature/spec.md` |
| Clarify (facultatif) | `/speckit-clarify` | modifications dans `spec.md` |
| Plan | `/speckit-plan` | `specs/###-feature/plan.md` |
| Checklist (facultatif) | `/speckit-checklist` | liste de contrôle de la qualité des exigences |
| Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` |
| Analyze (facultatif) | `/speckit-analyze` | rapport sur la spécification, le plan et les tâches |
| Implement | `/speckit-implement` | code dans le projet |
| Converge | `/speckit-converge` | verdict « Converged » ou nouvelles tâches dans `tasks.md` |
Ainsi, après une exécution, votre dépôt contient non seulement du code, mais aussi sa spécification, son plan et ses tâches. Un mois plus tard, vous pouvez revenir au projet, lire `spec.md` et comprendre ce qui a été fait et pourquoi. Ce n’est plus du « vibe coding où l’on oublie que le code existe » : c’est la mémoire de travail du projet.
## Pourquoi un vibe coder qui n’écrit pas de code en a-t-il besoin ?
À retenir
Le principal problème du vibe coder est l’imprévisibilité. Aujourd’hui, l’agent crée une fonctionnalité qui marche en 20 minutes ; demain, pour une tâche similaire, il produit du code spaghetti. Spec Kit élimine la source de cette imprévisibilité : une tâche formulée de manière vague. Quand vous rédigez une spécification à partir d’un modèle, l’agent travaille de façon cohérente, car il dispose d’une source de vérité sans ambiguïté. De plus, vous obtenez un artefact durable dans le dépôt, auquel vous pourrez revenir un mois plus tard.
Spec Kit formalise la planification en étapes distinctes avec 4 commandes slash. La logique consiste à séparer la réflexion de la mise en œuvre pour qu’elles se déroulent dans des fenêtres de contexte différentes. Chaque étape bénéficie d’un contexte vierge, qui n’a pas été encombré par la phase précédente.
Trois avantages concrets pour un vibe coder :
- **Prévisibilité.** Quand vous dites à l’agent « crée un formulaire d’inscription avec confirmation par e-mail », il devine 10 détails de son côté — et se trompe sur trois d’entre eux par rapport à ce que vous aviez en tête. Avec un `spec.md` contenant des User Stories, des Acceptance Scenarios et des marqueurs `[NEEDS CLARIFICATION]` à chaque point incertain, il n’y a rien à deviner.
- **Mémoire du projet.** Un mois plus tard, vous ne vous souviendrez pas de ce que vous avez discuté avec l’agent dans le chat. Mais `spec.md`, `plan.md` et `tasks.md` se trouvent dans le dépôt, dans le dossier `specs/###-feature/` à côté du code. Ils montrent non seulement ce qui a été fait, mais aussi pourquoi.
- **Passage à l’échelle.** Pour une fonctionnalité impliquant 1-2 fichiers, la différence est à peine perceptible. Pour une fonctionnalité qui implique 20 fichiers et 5 entités de données, la différence se situe entre « tout réécrire au bout de 4 heures » et « tout est arrivé dans la branche principale au bout de 4 heures ». AWS Kiro a démontré une automatisation à 95 % de la logique métier à partir d’une spécification dans le projet TargetID.
La principale illusion du vibe coding est qu’il semble plus rapide au départ. Une demi-heure, et voilà un prototype. Mais au bout d’une semaine, le prototype se casse et il est plus simple de le jeter. Le Spec-Driven Development prend un peu plus de temps au départ (une heure au lieu d’une demi-heure), mais une semaine plus tard, vous travaillez toujours dans le même dépôt.
## Installer Spec Kit dans Claude Code (4 étapes)
À retenir
Spec Kit s’installe avec uv, un gestionnaire de paquets Python d’Astral. La commande ne comporte qu’une ligne. Après l’installation, allez dans votre dépôt, exécutez `specify init` avec le flag `--integration claude` (ou choisissez Claude Code dans la liste des agents) et vous obtenez une structure prête à l’emploi avec des modèles pour la constitution, la spécification, le plan et les tâches, ainsi qu’un ensemble de commandes `/speckit-*` directement dans Claude Code. L’installation prend 5 minutes si uv est déjà installé, et 10 minutes si vous devez l’installer de zéro.
**Étape 1. Installer uv.** Vous n’avez à le faire qu’une seule fois ; il restera sur votre système.
```bash
# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
```
Vérifiez qu’uv est installé :
```bash
uv --version
```
**Étape 2. Installer Spec Kit.** Une commande :
```bash
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
```
Vérifiez :
```bash
specify --version
```
**Étape 3. Initialiser le dépôt.** Allez dans le dossier de votre projet (ou créez-en un nouveau) et exécutez :
```bash
specify init --here --integration claude
```
Le flag `--integration claude` sélectionne directement Claude Code. Sans ce flag, Spec Kit vous demande de choisir un agent dans une liste interactive et peut également vous demander un type de script (pour macOS et Linux, laissez `sh`). Si le dossier n’est pas vide, Spec Kit vous avertit qu’il fusionnera ses fichiers avec les vôtres : commitez d’abord votre travail, puis relancez la commande avec le flag `--force`.
Les éléments suivants apparaîtront alors dans le dépôt :
```
.specify/
memory/
constitution.md # project rules, filled in by /speckit-constitution
scripts/
templates/
spec-template.md
plan-template.md
tasks-template.md
.claude/
skills/
speckit-constitution/SKILL.md
speckit-specify/SKILL.md
speckit-clarify/SKILL.md
speckit-plan/SKILL.md
speckit-checklist/SKILL.md
speckit-tasks/SKILL.md
speckit-analyze/SKILL.md
speckit-implement/SKILL.md
speckit-converge/SKILL.md
speckit-taskstoissues/SKILL.md
```
**Étape 4. Ouvrir Claude Code et vérifier les commandes slash.** Exécutez ceci dans le même dossier :
```bash
claude
```
Dans la session, saisissez `/speckit` : les commandes `speckit-*` devraient apparaître dans les suggestions. Si ce n’est pas le cas, redémarrez Claude Code pour qu’il relise `.claude/skills/`. Si vous avez déjà un fichier `CLAUDE.md` à la racine du projet, Spec Kit le laisse intact : il fonctionne à ses côtés, dans `.specify/memory/constitution.md`.
Spec Kit fonctionne aussi sans Claude Code (il prend en charge plus de 30 agents), mais ce guide porte spécifiquement sur la configuration avec Claude. Si vous voulez installer deux outils tout de suite, consultez les guides distincts sur [la configuration de CLAUDE.md](https://ailoot.ai/blog/fr/claude-md-template/) et [le mode Plan dans Claude Code](https://ailoot.ai/blog/fr/claude-code-plan-mode/).
Spec Kit est la première brique d’un « contrat de travail pour agent ». La configuration complète comprend ces trois éléments : un clone IA (votre méthode sous forme de Skills et de sous-agents), un Second Brain (la structure `business/` à laquelle l’agent revient chaque fois) et l’ingénierie du contexte (Spec Kit, mode Plan, /compact). Ce sont les trois piliers sans lesquels l’IA hallucine.
## Rédiger votre première spécification (Specify)
À retenir
Spec Kit vous demande de décrire une fonctionnalité librement, puis développe cette description en un fichier `spec.md` à l’aide d’un modèle : User Stories avec les priorités P1/P2/P3, Acceptance Scenarios au format Given/When/Then, Functional Requirements (FR-001, FR-002, etc.) et Success Criteria avec des résultats mesurables. Partout où l’agent a un doute, il insère un marqueur `[NEEDS CLARIFICATION: ...]` — vous devez y répondre avant de passer à Plan.
Dans Claude Code, saisissez :
```
/speckit-specify
```
L’agent vous demandera alors de décrire la fonctionnalité. À cette étape, utilisez un langage simple, sans jargon technique :
```
Je veux un formulaire d’inscription dans mon application. L’utilisateur saisit
son e-mail et son mot de passe, reçoit un e-mail de confirmation et arrive
au tableau de bord après confirmation. La confirmation expire après 48 heures.
Si l’adresse reste non confirmée, supprime le compte dans les 5 minutes suivant
cette échéance ; ne supprime jamais un compte confirmé.
```
Dans cet exemple, la tolérance de suppression est clarifiée à 5 minutes après l’échéance de 48 heures. Pour un vrai produit, confirmez-la avant Plan ; une échéance exacte exige une conception et des tests plus stricts. L’agent créera `specs/001-registration/spec.md`. Ouvrez-le pour voir cette structure :
```markdown
# Feature Specification: User Registration
**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."
## User Scenarios & Testing *(mandatory)*
### Primary User Story
As a new user, I want to register an account with email confirmation,
so that I can access the dashboard with a verified identity.
### Acceptance Scenarios
1. **Given** I am on the registration page,
**When** I submit valid email and password,
**Then** I receive a confirmation email within 1 minute.
2. **Given** I clicked the confirmation link within 48 hours,
**When** I land on the dashboard,
**Then** I see my email confirmed in profile.
3. **Given** mon compte n’est pas confirmé à l’échéance de 48 heures,
**When** le nettoyage tourne dans les 5 minutes suivantes,
**Then** mon compte est supprimé et l’e-mail redevient disponible.
4. **Given** mon compte a moins de 48 heures ou est déjà confirmé,
**When** le nettoyage tourne,
**Then** le compte n’est pas supprimé.
## Requirements *(mandatory)*
### Functional Requirements
- **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION:
email/password only, or also SSO/OAuth?]
- **FR-002**: System MUST send confirmation email within 60 seconds
- **FR-003**: La confirmation MUST expirer à 48 heures ; le système MUST
supprimer les comptes encore non confirmés au plus tard 5 minutes après
cette échéance et MUST NOT supprimer les comptes confirmés
- **FR-004**: System MUST log all registration attempts for [NEEDS
CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?]
### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at
## Success Criteria *(mandatory)*
- **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95)
- **SC-002**: 0 suppression accidentelle de compte confirmé
- **SC-004**: Aucune suppression avant 48 heures ; tout compte non confirmé
admissible est supprimé avant 48 heures 5 minutes sous la charge testée
- **SC-003**: Registration completion rate > 60% (from form open to dashboard)
```
Prêtez attention aux marqueurs `[NEEDS CLARIFICATION: ...]`. Spec Kit les insère délibérément partout où l’agent n’a pas obtenu de réponse sans ambiguïté dans votre texte. Avant de passer à la phase Plan, vous devez soit y répondre manuellement dans `spec.md`, soit exécuter `/speckit-clarify`. L’agent passera alors en revue les points obscurs et vous posera des questions dans le dialogue.
Dans Spec Kit, la commande intégrée `/speckit-clarify` remplace le « pose-moi des questions » formulé à l’oral. Le résultat est le même : vous ne passez pas à Plan tant qu’il reste des marqueurs `[NEEDS CLARIFICATION]` dans `spec.md`.
Il ne devrait pas y avoir de technologies dans `spec.md`. Pas de mentions de React, Postgres, Prisma ou Redis. La spécification décrit ce que fait le système du point de vue de l’utilisateur et de l’entreprise. La pile technologique arrive à la phase suivante.
## Que fait Claude pendant la phase Plan ?
À retenir
La commande `/speckit-plan` prend la spécification terminée et élabore un plan technique : les technologies à utiliser, l’architecture, les modules, les entités de données et les contrats d’API. Le plan est écrit dans `specs/###-feature/plan.md`, les contrats sont exportés dans un dossier `contracts/` distinct et le modèle de données est placé dans `data-model.md`. À cette étape, Claude connaît déjà votre pile grâce à CLAUDE.md et à la constitution ; le plan s’adapte donc au projet existant au lieu de suggérer « réécrivons tout en Rust ».
Quand `spec.md` est prêt, exécutez :
```
/speckit-plan
```
Vous pouvez éventuellement indiquer directement des technologies dans la commande :
```
/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email
```
Claude lit trois sources : votre `spec.md`, votre `CLAUDE.md` (ou `memory/constitution.md`) et le code existant dans le dépôt. Le résultat est un fichier `plan.md` dont la structure ressemble à ceci :
```markdown
# Implementation Plan: User Registration
## Technical Context
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider
## Architecture Decisions
### 1. Token storage
Tokens stored in DB (table ConfirmationToken), not in JWT.
Reason: need server-side revoke on email re-register.
### 2. Email delivery
Async via cron `/api/cron/send-confirmation` triggered immediately
after registration. Retries handled by Resend.
### 3. Auto-delete cron
Exécuter `/api/cron/cleanup-unconfirmed` chaque minute. Supprimer seulement si
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
Cet exemple clarifié autorise au plus 5 minutes de retard. Vérifier retard
du planificateur et durée de traitement ; un dépassement est un échec,
pas un nettoyage quotidien réussi.
## Data Model
See data-model.md
## API Contracts
See contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation
## Implementation Phases
1. Database migration (Prisma schema + migration file)
2. API routes (3 endpoints)
3. UI: registration form + confirmation success page
4. Cron jobs (send + cleanup)
5. Email template
6. Integration tests
```
`data-model.md` décrit les entités et leurs relations. `contracts/` contient des ébauches de contrats d’API (en YAML OpenAPI ou sous forme de types de requête/réponse TypeScript). Ce n’est pas du code : c’est une intention que Claude transformera ensuite en véritables routes.
Le principal avantage de la phase Plan est le contexte vierge. Claude n’essaie pas de garder en tête la spécification et la mise en œuvre en même temps. Il réfléchit d’abord, consigne sa décision dans un fichier, puis passe à la suite.
Vient ensuite la commande facultative `/speckit-analyze`. Elle s’exécute après la phase Tasks et avant Implement : elle examine l’ensemble `spec.md + plan.md + tasks.md` pour y détecter des contradictions et vérifie que le plan et les tâches couvrent toutes les exigences de la spécification. Elle ne modifie pas les fichiers ; elle produit seulement un rapport. C’est en somme une vérification de cohérence formelle avant la mise en œuvre.
## Décomposer le travail en tâches (Tasks)
À retenir
La commande `/speckit-tasks` décompose le plan en tâches concrètes. Chaque tâche comprend des dépendances, une estimation et une indication précisant si elle peut être menée « en parallèle » ou « strictement en séquence ». Le résultat est `tasks.md`, où les tâches suivent le format de liste de contrôle `[ ] T-001: ...`. Vous pouvez ensuite les confier à `/speckit-implement` ou les convertir en GitHub Issues avec `/speckit-taskstoissues`, puis les répartir entre une équipe ou plusieurs sessions Claude Code parallèles.
Quand vous avez `spec.md` et `plan.md`, exécutez :
```
/speckit-tasks
```
Claude développe le plan en un fichier `tasks.md` :
```markdown
# Tasks: User Registration
## Phase 1: Database (no dependencies)
- [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe)
- [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001)
- [ ] T-003: Generate migration `add-user-registration` (after T-002)
## Phase 2: API contracts (no dependencies)
- [ ] T-004: Create Zod schemas in shared/validation/auth.ts
- [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004)
## Phase 3: Routes (depends on Phase 1+2)
- [ ] T-006: Implement POST /api/auth/register
- [ ] T-007: Implement POST /api/auth/confirm
- [ ] T-008: Implement GET /api/auth/resend-confirmation
## Phase 4: UI (parallel with Phase 3)
- [ ] T-009: Build /register page with form
- [ ] T-010: Build /register/confirm/[token] page
- [ ] T-011: Build /register/success page
## Phase 5: Cron + integration (depends on Phase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Email template registration-confirmation.tsx
- [ ] T-015: Tests d’intégration (Playwright) : juste avant 48h, exactement
à 48h, suppression avant 48h 5m, échec de tâche retardée et protection
des comptes confirmés
## Notes
- T-001, T-004, T-009-T-011 are parallel-safe (different files)
- T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially
- T-006 needs T-003 (migration applied) and T-005 (types)
```
Remarquez les marqueurs `parallel-safe` et `after T-NNN`. Ils constituent le graphe de dépendances qui permet ensuite d’exécuter plusieurs phases en parallèle. Toute l’accélération promise par Spec Kit repose sur ce mécanisme : certaines tâches peuvent être confiées simultanément à cinq sessions Claude Code différentes, tandis que d’autres doivent impérativement être exécutées en séquence.
Spec Kit le fait automatiquement avec une seule commande, dès l’installation.
La commande facultative `/speckit-taskstoissues` prend `tasks.md` et crée des GitHub Issues à partir de la liste, chacune avec un lien vers `spec.md`. C’est utile si vous travaillez en équipe ou souhaitez suivre l’avancement dans GitHub Projects.
## Mettre en œuvre avec des sous-agents (Implement)
À retenir
La phase finale `/speckit-implement` lance la mise en œuvre. Claude parcourt `tasks.md` de haut en bas et coche `[x]` à mesure que les tâches sont terminées. Vous pouvez lancer plusieurs sessions Claude Code en parallèle, une par phase. Dans chaque session, Claude lance des sous-agents pour différents types de travail : un réviseur de code, un testeur chargé des vérifications et un rédacteur de documentation pour le README. C’est le mode des « 1000 sous-agents parallèles » dont Anthropic a parlé à la sortie d’Opus 4.8 — dans Spec Kit, il s’agit simplement d’un mode de travail, pas d’un produit distinct.
```
/speckit-implement
```
Claude commence par la première tâche de `tasks.md`. Chaque tâche suit un petit cycle : lire les fichiers pertinents, écrire un diff, exécuter les tests, puis cocher `[x]`. Les sous-agents sont appelés automatiquement si nécessaire : un pour la revue du code, un pour lancer le linter et un pour rechercher les régressions.
Et séparément, à propos des règles :
Dans Spec Kit, ce cycle est formalisé. `spec.md` est la source de vérité, `plan.md` contient les décisions techniques et `tasks.md` sert de liste de contrôle. Si Claude s’écarte du sujet à une étape quelconque, revenez à la spécification et dites : « Cela ne correspond pas à FR-003 ; recommence. » Pas de longs prompts du type « souviens-toi de ce dont nous avons parlé... » : tout l’historique se trouve dans les fichiers.
Si vous avez connecté [Dynamic Workflows dans Opus 4.8](https://ailoot.ai/blog/fr/claude-code-dynamic-workflows/), vous pouvez faire fonctionner Spec Kit en mode entièrement automatisé : une commande `/speckit-implement`, et Claude parallélise le travail, regroupe les résultats et les vérifie. La limite est de 1000 sous-agents à la fois. Pour la plupart des fonctionnalités, 10-30 suffisent.
Quand toutes les cases `[x]` sont cochées et que la vérification de la section suivante répond « Converged », examinez la PR (ou une série de PR s’il y a beaucoup de tâches) et fusionnez-la. Les artefacts — `spec.md`, `plan.md`, `tasks.md` — restent dans le dépôt pour documenter la fonctionnalité. Un an plus tard, vous n’aurez pas à reconstituer la logique à partir du code.
## Vérifier que l’agent n’a rien oublié (Converge)
À retenir
Après Implement, la version actuelle de Spec Kit comporte une étape de vérification appelée `/speckit-converge`. L’agent compare le code terminé à `spec.md`, `plan.md` et `tasks.md`. Si tout concorde, il répond « Converged » et ne modifie pas les fichiers. S’il trouve des éléments manquants, il les ajoute à la fin de `tasks.md` comme nouvelles tâches. Exécutez ensuite `/speckit-implement` de nouveau, puis `/speckit-converge`, jusqu’à obtenir « Converged ».
```
/speckit-converge
```
L’agent commence par résumer ses constatations en précisant leur niveau de gravité, puis annonce l’un de deux résultats. « Converged » signifie qu’il n’y a aucun oubli, que `tasks.md` est resté strictement identique octet par octet et que vous pouvez passer à la revue. « Tasks appended » signifie que des éléments manquants ont été trouvés et ajoutés à la section Convergence de `tasks.md` ; l’agent vous indique leur nombre.
Converge ne modifie ni ne supprime le code ; sa seule écriture consiste à ajouter de nouvelles tâches dans `tasks.md`. Vous pouvez donc le lancer sans crainte, mais seulement après que `/speckit-implement` a traité le `tasks.md` actuel. Chaque passage suivant trouve moins d’omissions.
## Quelle est la différence entre Spec Kit, CLAUDE.md et le mode Plan ?
À retenir
C’est une question fréquente quand on compare ces outils. En bref : CLAUDE.md est le « contrat de travail » de l’agent, la source de vérité unique pour tout le projet. Le mode Plan sert à planifier une fois avant une demande précise. Spec Kit couvre tout le cycle de vie d’une fonctionnalité, de sa description à sa mise en œuvre, avec des artefacts dans le dépôt. Ils ne se remplacent pas ; ils forment ensemble un système à trois niveaux : contexte global (CLAUDE.md) → contexte du projet (constitution Spec Kit) → contexte de la fonctionnalité (spec.md + plan.md + tasks.md).
Comparez-les selon 5 caractéristiques :
| Caractéristique | CLAUDE.md | Mode Plan | Spec Kit |
|----|----|----|----|
| Quand il s’exécute | À chaque session | Sur demande (Shift+Tab ou /plan) | Avec la commande slash /speckit-* |
| Durée de vie | Tout le projet | Une session | Une fonctionnalité |
| Où il se trouve | À la racine du dépôt | Dans le contexte de Claude | `specs/###-feature/*` |
| Ce qu’il contient | Stack, règles, glossaire | Plan actuel + observations | spec + plan + tasks + contrats |
| Modèle | Libre (règles du dépôt) | Aucun | Markdown structuré |
| Rôle idéal | Règles et stack du projet | Vérification avant une modification majeure | Cycle complet d’une fonctionnalité : du QUOI au CODE |
Dans la terminologie de Spec Kit, c’est `.specify/memory/constitution.md`. Lors de l’initialisation, Spec Kit peut soit utiliser votre CLAUDE.md existant comme base pour la constitution, soit créer un fichier distinct à côté. En général, je conserve CLAUDE.md comme « contrat » global (stack, glossaire, protocole de déploiement) et j’utilise la constitution Spec Kit pour les règles propres au workflow, par exemple : « tous les formulaires sont validés avec Zod ; pas de vérifications manuelles ».
Le lien avec le mode Plan est plus simple. Le mode Plan est un mode rapide « planifier avant d’écrire du code », au sein d’une seule session. Il convient bien aux petites modifications (corriger un bug, refactoriser une fonction). Pour une fonctionnalité importante, le mode Plan est moins adapté, car la fenêtre de contexte d’une session est trop petite pour un plan de 3000 lignes — comme je l’explique directement lors de la session en direct :
Spec Kit est un outil concret d’ingénierie du contexte. Il déplace la « nappe d’architecture » du chat vers des fichiers. Spec.md reste dans le dépôt et chaque nouvelle session Claude le relit : vous n’avez pas besoin de vous répéter.
Une configuration pour un grand projet :
1. **CLAUDE.md** - stack, glossaire et choses à éviter. Il se trouve à la racine.
2. **.specify/memory/constitution.md** pour Spec Kit — les règles propres à ce workflow.
3. **specs/001-feature-A/spec.md, plan.md, tasks.md** - première fonctionnalité.
4. **specs/002-feature-B/spec.md, plan.md, tasks.md** - deuxième fonctionnalité.
5. Pour le travail quotidien, utilisez `/speckit-implement` (pour les tâches prêtes) ou `/plan` (une vérification rapide avant une modification).
## Quels cas concrets fonctionnent ?
À retenir
L’approche Spec Kit et SDD a déjà produit des résultats mesurables dans de grandes entreprises. AWS, dans un projet de découverte de médicaments : 95 % de la logique métier générée à partir d’une spécification, plus de 80 heures économisées sur une fonctionnalité. Rackspace Technology : 52 semaines de travail ramenées à 3 semaines, +90 % d’efficacité. Spec Kit lui-même a recueilli 107 000 étoiles GitHub en 8 mois.
Cas précis :
- **AWS Kiro - agent de découverte de médicaments.** Dans un [article du blog AWS Industries](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) daté du 18 février 2026, l’équipe décrit le projet TargetID. Trois développeurs, trois semaines, un agent de découverte de médicaments. Les chiffres de l’article : Kiro a généré plus de 95 % du code de logique métier, économisant plus de 80 heures de développement. Également : « La documentation README rédigée par Kiro nous a fait économiser environ 8 heures » et « 40 % de cycles itératifs prompt-correction en moins ».
- **Rackspace Technology.** Dans le même article AWS, Rackspace indique avoir « effectué 52 semaines de travail estimé en seulement 3 semaines » et enregistré une « hausse de 90 % de l’efficacité ». Il ne s’agit plus d’une petite fonctionnalité, mais d’un projet d’entreprise complet.
- **Croissance de GitHub Spec Kit.** Au 7 mai 2026, le dépôt comptait 93 000 étoiles ; au 31 mai, il en comptait 107 000. Cela représente +14 000 étoiles en trois semaines. Ce rythme de croissance indique clairement que l’approche gagne des parts de marché.
Pour le lecteur, cela signifie que l’approche n’est pas théorique : des équipes sérieuses l’utilisent déjà en production.
## Dans quels cas Spec Kit ne convient-il PAS ?
À retenir
Spec Kit ne convient pas à toutes les situations. Il a trois zones d’exclusion évidentes : les petites modifications (corriger un bug, renommer une variable), les expériences et les prototypes (où ne pas savoir ce que l’on veut constitue précisément le cœur du vibe coding) et le code hérité avec un état complexe (où la spécification devient obsolète plus vite que vous ne pouvez finir de la rédiger). Ces cas ont de sérieux détracteurs. Leurs arguments méritent d’être connus afin de ne pas perdre de temps avec des spécifications inutiles.
**Cas inadapté n° 1 - petites modifications.** Si la tâche consiste à « renommer une variable », « corriger une faute dans le texte » ou « ajouter un log », parcourir Specify → Plan → Tasks prendra plus de temps que la modification elle-même. Pour les petites modifications, le mode Plan ou un simple prompt direct dans Claude Code est plus rapide.
**Cas inadapté n° 2 - expériences en direct.** Quand vous ne savez pas encore ce que vous voulez et devez « tâtonner » dans l’interface ou assembler rapidement un prototype pour voir « si ça prend », une spécification n’a aucun sens. La valeur réside précisément dans le fait d’improviser. Quand il s’agit de « jouer avec une idée », c’est précisément le vibe coding qui fonctionne, pas une spécification.
**Cas inadapté n° 3 - code hérité avec un état complexe.** Un contre-argument sérieux : « La réalité évolue plus vite que les spécifications. » Prenons l’exemple de la facturation par abonnement : l’équipe a décrit les cycles de facturation et les règles fiscales, puis, une semaine plus tard, la direction financière a demandé la TVA européenne — la spécification était obsolète avant la mise en production. Quand la logique métier évolue rapidement, maintenir les spécifications devient une charge.
Un autre risque est le faux sentiment de contrôle : les structures sont élégantes, mais les agents ignorent souvent les consignes ou, à l’inverse, suivent les modèles trop littéralement. Le résultat est un code structurellement correct, mais qui ne convient pas à votre dépôt particulier : la spécification ne garantit pas que l’agent l’a comprise comme vous le vouliez.
En avril 2026, des analystes du secteur ont mis en garde contre le cycle en cascade : rédiger une grande spécification avant le code est une voie qui a déjà fait sombrer le secteur, à l’époque des exigences de 200 pages. Depuis, les ingénieurs abordent cette méthode avec prudence, à juste titre.
**Que faire ?** Je suggère une règle simple : comparer la taille de la fonctionnalité au temps nécessaire pour rédiger une spécification. Si une fonctionnalité demande moins de 2 heures de mise en œuvre, n’écrivez pas de spécification : le mode Plan est plus rapide. Si elle demande une semaine, utilisez absolument Spec Kit ; le gain de temps compensera cinq fois l’heure consacrée à la spécification. Entre 2 heures et une semaine, faites selon votre jugement, même si, personnellement, je rédige une spécification même pour les fonctionnalités d’une demi-journée, car l’artefact dans le dépôt vaut davantage que les 30 minutes économisées.
## Et maintenant : comment intégrer Spec Kit à votre projet ?
À retenir
Le plus simple pour commencer est d’essayer Spec Kit sur une nouvelle petite fonctionnalité, et non sur tout un projet existant. Installez-le, initialisez-le dans un dépôt, exécutez `/speckit-specify` pour une fonctionnalité et examinez les artefacts. Dans une semaine ou deux, vous saurez intuitivement quand l’utiliser et quand vous en tenir aux prompts rapides. La méthode complète combine CLAUDE.md + Spec Kit + Skills + sous-agents.
Un plan concret pour les 7 prochains jours :
- **Jour 1.** Installez uv et Spec Kit (5-10 minutes). Vérifiez que les commandes `/speckit-*` apparaissent dans Claude Code. N’essayez pas de les appliquer à un projet existant : commencez-en un nouveau.
- **Jour 2.** Choisissez une vraie fonctionnalité que vous prévoyez de développer. Exécutez `/speckit-specify` avec une description libre. Ouvrez `spec.md`, lisez-le et répondez à chaque marqueur `[NEEDS CLARIFICATION]`. Ne vous précipitez pas vers Plan.
- **Jour 3.** Exécutez `/speckit-plan` en précisant des indications sur votre pile. Lisez `plan.md`, en particulier la section Architecture Decisions. Si quelque chose ne vous convient pas, modifiez-le manuellement.
- **Jour 4-5.** Exécutez `/speckit-tasks`, puis `/speckit-analyze` pour vérifier l’ensemble spécification, plan et tâches, puis `/speckit-implement`. Observez Claude cocher `[x]` dans `tasks.md`. Il peut rester bloqué quelque part — c’est normal. Revenez à `spec.md`, clarifiez l’exigence et relancez `/speckit-implement` avec une tâche précise. Une fois les tâches terminées, exécutez `/speckit-converge` et répétez la séquence Implement et Converge jusqu’à ce qu’il réponde « Converged ».
- **Jour 6-7.** Examinez la PR (ou la série de PR). Fusionnez-la. Lisez `spec.md` et `plan.md` : ils documenteront votre fonctionnalité pour l’année à venir.
Voici ce que je vous suggère de lire en parallèle :
- [Configurer CLAUDE.md en 2026](https://ailoot.ai/blog/fr/claude-md-template/) - la base de la constitution de Spec Kit.
- [Le mode Plan dans Claude Code](https://ailoot.ai/blog/fr/claude-code-plan-mode/) - une solution rapide pour les petites tâches.
- [L’ingénierie du contexte en 2026](https://ailoot.ai/blog/fr/context-engineering/) - pourquoi Spec Kit fonctionne.
- [Skills, sous-agents, MCP ou plugins](https://ailoot.ai/blog/fr/skills-subagents-mcp-plugins-claude-code/) - quoi ajouter à Spec Kit pour votre workflow.
- [Dynamic Workflows dans Claude Code](https://ailoot.ai/blog/fr/claude-code-dynamic-workflows/) - comment lancer de nombreux sous-agents en parallèle pour la phase Implement.
### Sources
- [GitHub Spec Kit - dépôt](https://github.com/github/spec-kit)
- [GitHub Spec Kit - documentation officielle](https://github.github.com/spec-kit/)
- [Spec-Driven Development - texte officiel sur la méthode](https://github.com/github/spec-kit/blob/main/spec-driven.md)
- [Modèle de spécification - GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md)
- [Blog AWS Industries - De la spécification à la production : agent Kiro de découverte de médicaments (18 février 2026)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/)
- [Documentation Claude Code - Sous-agents](https://code.claude.com/docs/en/sub-agents)
- [Documentation Claude Code - Skills](https://code.claude.com/docs/en/skills)
- [Documentation Claude Code - Commandes](https://code.claude.com/docs/en/commands)
Le workflow complet de contexte : clone IA + Second Brain + ingénierie du contexte.
Retrouvez davantage de ressources sur [Ailoot](https://ailoot.ai/).
## Questions fréquentes : Configurer Spec Kit dans Claude Code en 2026 : des spécifications plutôt que des prompts
### Pourquoi une tâche quotidienne ne suffit-elle pas à une suppression sous 48 heures ?
Un compte atteignant l’échéance juste après le passage pourrait attendre presque une journée. Précisez la tolérance dans la spécification, adaptez la fréquence et testez le seuil de 48 heures ainsi que le retard maximal.
### Que faire si plan.md contredit spec.md ?
Revenez à l’exigence et résolvez l’écart avant d’implémenter. Actualisez ensemble spécification, plan, tâches et contrôles, puis utilisez Analyze et les tests d’implémentation pour vérifier le même comportement convenu.
## Ailoot · L’entreprise et son portefeuille de projets
Ailoot s’appuie sur une expérience opérationnelle éprouvée, une large clientèle, un service stable et un suivi continu des KPI.
L’entreprise et son portefeuille de projets : des millions de clients ; des ventes qui se chiffrent en milliards chaque mois.
Ailoot met cette expérience opérationnelle au service de l’accès API aux fonctions d’IA dans les produits des clients, leurs agents, applications et automatisations.