Aller au contenu principal
Intermédiaire

Développement piloté par spécification avec Spec Kit

Le vibe coding — « construis-moi un tableau de bord », accepter ce qui revient — fonctionne très bien jusqu'à ce que la fonctionnalité devienne grosse. Là, l'agent dérive : il oublie une décision antérieure, réinvente une fonction, ou livre quelque chose qui techniquement tourne mais qui n'est pas ce que vous vouliez. Le Développement piloté par spécification (SDD) est la solution qui s'est imposée dans la communauté du codage agentique en 2026 : au lieu de traiter le prompt comme jetable, vous faites d'une spécification écrite et révisable la source de vérité, et vous demandez à l'agent de générer du code à partir d'elle.

Le Spec Kit open source de GitHub transforme cette idée en un workflow concret que vous pouvez exécuter dans Claude Code dès aujourd'hui.

What you'll learn
  • Comprendre ce qu'est le développement piloté par spécification et le problème qu'il résout
  • Parcourir les phases du Spec Kit : constitution → specify → plan → tasks → implement
  • Installer le CLI Specify et le brancher dans Claude Code
  • Connaître les garde-fous qualité optionnels (clarify, analyze, checklist)
  • Décider quand le SDD vaut la surcharge et quand l'éviter

Pourquoi des specs, pas seulement des prompts​

Un prompt disparaît dès que le tour se termine. Une spec est un artefact : elle peut être lue, révisée dans une PR, corrigée, et ré-exécutée. Ce seul changement corrige les trois façons dont les gros chantiers agentiques tournent mal :

  • Dérive — l'agent contredit une décision antérieure parce que rien ne l'avait écrite. La spec est la mémoire.
  • Ambiguïté — « rends ça joli » veut dire dix choses différentes. Forcer les exigences dans de la prose fait ressortir les manques avant que le code existe, là où ils sont peu coûteux à corriger.
  • Diffs non révisables — une PR générée de 2 000 lignes est difficile à juger. Une spec + un plan révisés rendent le diff attendu au lieu de surprenant.

Le modèle mental : l'intention est la chose de grande valeur et durable ; le code est un artefact en aval, régénérable. Le SDD est le cousin discipliné du Mode Plan de Claude Code — planifier d'abord, construire ensuite — étendu à toute une fonctionnalité et persisté dans des fichiers de votre dépôt.

Le workflow Spec Kit​

Spec Kit structure une fonctionnalité comme un court pipeline de slash commands. Chacune écrit des artefacts Markdown dans votre dépôt (sous .specify/), de sorte que chaque phase est inspectable et versionnée.

Guided walkthrough1 of 5
  1. Exécutez /speckit.constitution une fois par projet. Cela écrit les principes directeurs — style de code, niveau d'exigence des tests, non-négociables architecturaux — dans .specify/memory/constitution.md. Chaque phase ultérieure est vérifiée par rapport à elle, c'est donc votre garde-fou durable (voyez-le comme un CLAUDE.md centré sur les principes).

Garde-fous qualité optionnels​

Trois commandes supplémentaires resserrent la boucle quand une fonctionnalité est à fort enjeu :

  • /speckit.clarify — interroge la spec sur les zones sous-spécifiées et vous pose des questions ciblées avant la planification. À exécuter de préférence juste après specify.
  • /speckit.analyze — recoupe la spec, le plan et les tâches pour vérifier leur cohérence et les lacunes de couverture.
  • /speckit.checklist — génère une checklist de validation pour que « terminé » soit défini et testable.
Pro tip
  • Exécutez /speckit.clarify avant /speckit.plan — corriger l'ambiguïté coûte le moins cher avant que l'architecture soit figée.
  • Traitez chaque artefact généré comme une PR : lisez-le, corrigez-le, et seulement ensuite passez à la phase suivante.
  • Committez les artefacts .specify/ — ils constituent la trace révisable de l'intention derrière le code.

Le mettre en route avec Claude Code​

Spec Kit fournit un CLI, Specify, qui échafaude les slash commands dans votre projet. Il prend en charge plus de 30 agents de codage, dont Claude Code.

Guided walkthrough1 of 3
  1. Utilisez uv pour l'installer depuis le dépôt. (Python + uv requis.)

Install the Specify CLI (uv)

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Scaffold spec-driven workflow into a project

# new project
specify init my-feature

# or in the current repo
specify init --here

Then, inside Claude Code, run the pipeline

/speckit.constitution Establish principles: TypeScript strict, tests for every public function, no secrets in code.
/speckit.specify Build a CSV export for the reports page: users pick a date range and download a CSV of matching rows.
/speckit.clarify
/speckit.plan Next.js App Router, server action for the query, stream the CSV; no new dependencies.
/speckit.tasks
/speckit.implement
Watch out
  • Le flag exact de sélection d'agent pour specify init change d'une version à l'autre — consultez le quickstart du README plutôt que de copier un flag à l'aveugle.
  • Le SDD ne supprime pas le besoin de vérifier : lisez le code généré et exécutez-le. La spec rend le diff révisable, pas automatiquement correct.
  • Ne mettez jamais de secrets ou d'identifiants dans la spec, le plan ou la constitution — ils sont committés comme n'importe quel autre fichier.

Quand l'utiliser (et quand non)​

Le SDD échange de la cérémonie en amont contre du contrôle. Cet échange en vaut la peine quand le travail est gros, ambigu, ou doit être révisé par d'autres — et n'est que de la surcharge quand ce n'est pas le cas.

What you'll learn
  • Optez pour le SDD : fonctionnalités greenfield, chantiers multi-fichiers, tout ce qu'un collègue doit réviser, ou un travail que vous confierez à une flotte de subagents.
  • Évitez le SDD : scripts ponctuels, petites corrections, code exploratoire jetable — un simple prompt ou le Mode Plan est plus rapide.
  • Le brownfield marche aussi : pointez /speckit.specify vers une amélioration d'une base de code existante, pas seulement de nouveaux projets.
SDD at a glance
Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 5

Vérifiez vos connaissances​

Check yourself

0/3
  1. Quelle est l'idée centrale du développement piloté par spécification ?
  2. Quelle phase du Spec Kit doit capturer la stack technique et l'architecture ?
  3. Quand le développement piloté par spécification ne vaut-il PAS la surcharge ?
Key takeaways
  • Le développement piloté par spécification fait d'une spec révisable — pas du prompt — la source de vérité, tuant la dérive, l'ambiguïté et les diffs non révisables.
  • Le Spec Kit de GitHub (le CLI Specify) amène le SDD dans Claude Code sous forme de slash commands /speckit.*.
  • Le pipeline est constitution → specify → (clarify) → plan → (analyze) → tasks → (checklist) → implement, chacun écrivant des artefacts inspectables.
  • Gardez le QUOI/POURQUOI dans la spec et le COMMENT dans le plan ; révisez chaque artefact comme une PR avant d'avancer.
  • Utilisez-le pour les fonctionnalités grosses, ambiguës ou révisées ; évitez-le pour le travail jetable — et vérifiez toujours le code généré.

Suite​

Sources & lectures complémentaires​