Spec-driven development : ce que c’est, comment je l’utilise, pourquoi maintenant

Écrire du code n’a jamais été aussi rapide : l’IA en produit des écrans entiers en quelques secondes. Le goulot d’étranglement s’est déplacé — il n’est plus dans l’écriture du code, mais dans la décision. Le spec-driven development (SDD) est une réponse à cette (r)évolution.

Ce qu’est le spec-driven development

Le SDD tient en une inversion : la spécification d’abord, le code ensuite. Pas un cahier des charges figé de quatre-vingts pages — une spec courte, vivante, versionnée au même titre que le code. Elle décrit l’intention (le pourquoi), les contraintes (ce qui n’est pas négociable) et les tâches (le comment, découpé). Le code devient un dérivé de la spec, pas l’inverse.

Pas contre l’agile — une version allégée

Le SDD ne jette pas l’agilité, il en garde l’essence en retirant la cérémonie :

• Le backlog existe toujours, mais ultra-simplifié : ici, un simple document d’idées qui conserve les grands jalons et epics — pas un outil de gestion, une liste où l’on pioche.
• On travaille toujours en courtes itérations — souvent plus courtes qu’avant.
• On a toujours un ou plusieurs livrables à chaque incrément.

Ce qui change, c’est que la spec remplace les rituels lourds. Et parce que chaque incrément est petit et spécifié, on s’adapte en continu : à la réalité du terrain, à un changement de direction, à un mouvement du marché. La spec n’est pas une rigidité — c’est ce qui rend le changement de cap bon marché.

Comment je travaille, concrètement

Un cycle, pour moi, c’est cinq temps :

1. Je choisis un sujet — souvent tiré de ce backlog simplifié.
2. J’explore — avec des agents IA : creuser le sujet, consolider les pistes, le découper en incréments plus petits, débusquer les trade-offs et les impensés.
3. Je propose — je consolide l’exploration en artefacts (proposal, design, tasks) : le quoi, le comment, les étapes.
4. J’applique — les agents IA passent à l’implémentation, mais cadrés par les contraintes et le design des artefacts : c’est ce qui évite les dérives.
5. J’archive — une fois le change validé, la spec rejoint la source de vérité et le code fusionne dans le tronc commun.

Une tâche, ça ressemble à ça — extrait réel d’un de mes changes (le fil de conversation d’un outil de tickets), lisible par l’humain comme par l’IA :

## Fil de conversation du ticket

- [x] Le client lit le ticket, mais jamais les notes internes de l’équipe
- [x] Un interne hors du périmètre du client ne peut pas ajouter de note
- [x] Composer à deux onglets « Commentaire / Note interne » — onglet note masqué côté client
- [x] Le fil mêle commentaires et notes par ordre chronologique ; côté client, les commentaires seuls
- [~] « Mis à jour par … » : un commentaire fait remonter le ticket, une note interne non

Chaque case cochée est une décision tracée. Six mois plus tard, on sait pourquoi le produit se comporte ainsi — sans devoir faire de l’archéologie.

Pourquoi c’est pertinent — surtout maintenant

L’IA change l’équation, et le SDD en sort renforcé :

• L’IA accélère, la spec dirige. Un modèle génère vite mais ne tranche ni l’architecture ni la sécurité. La spec est le cadre dans lequel il génère — de la vitesse, sous contrôle.
• La spec survit aux modèles. Les meilleurs modèles changent tous les six mois ; la spec, elle, dure. On bascule de l’un à l’autre sans réécrire le produit — l’actif, c’est la spec.
• La traçabilité devient vitale. Quand une machine produit beaucoup de code, savoir pourquoi chaque décision a été prise — écrite, revue, versionnée — n’est plus un luxe : c’est ce qui garde le produit auditable.

La spec d’abord, ce n’est pas ralentir pour faire joli. C’est déplacer les décisions là où elles sont encore réversibles — et donner à l’IA un cadre où elle accélère sans rien casser.