Passer au contenu
Anti spaghettiManage AI Code
Anti spaghetti

Spec-Driven Development

En développement assisté par agents IA, le Spec-Driven Development (SDD) fait d'une spécification structurée et versionnée avec le code, la référence à partir de laquelle les agents planifient, produisent et vérifient le code. Le prompt libre est remplacé par un contrat écrit, relu et validé par un humain avant toute génération.

Le problème que le SDD cherche à résoudre

Les modèles génératifs sont non déterministes : le même prompt ne donne pas deux fois le même code, et ils peuvent produire avec assurance des éléments faux, comme par exemple des API qui n'existent pas. Tant que l'usage se limite à des compléments de code ou à de petites tâches, ces défauts se corrigent à la main. Ils deviennent structurels dès que l'on confie à un agent des travaux longs. Les principales difficultés viennent du fait que l'agent ne se souvient pas des décisions prises dans une session précédente (d'où l'expression « session amnesia »), ses performances se dégradent à mesure que son contexte de travail s'allonge (on parle de « context rot »), et le code s'éloigne progressivement de l'architecture voulue (« architectural drift »).

Le terme « vibe coding » (popularisée par Andrej Karpathy en février 2025) désigne cette pratique du prompt conversationnel sans cadre : efficace pour un prototype, fragile sur un système qui doit durer. L'expression « spec-driven development » est plus ancienne, mais elle s'est imposée dans le contexte des agents IA au second semestre 2025, avec la sortie de frameworks par des grands industriels du digital (Kiro de AWS en juillet et Spec Kit de GitHub en septembre), comme réponse outillée à cette fragilité.

La spécification comme contrat

Le développeur, ou le PO avec lui, rédige un fichier de spécification (le plus souvent en Markdown) qui contient les récits utilisateurs, les critères d'acceptation, les contraintes du système et, selon les outils, des règles invariantes du projet, que certains outils appellent « constitution ». Cette spécification est relue, validée, puis versionnée avec le code. Elle fait autorité : quand code et spécification divergent, c'est la spécification que l'on corrige d'abord, puis le code.

Ce n'est pas un cahier des charges au sens classique. Elle est écrite pour être lue par un humain et consommée par un agent, et elle reste vivante tant que la fonctionnalité existe.

Le cycle en quatre phases

Les outils de SDD convergent vers un même enchaînement, en trois ou quatre phases selon le découpage retenu. Le nom des phases varie, pas leur logique. Le cycle est structuré et rejouable, mais pas déterministe : ce sont les points de validation humaine qui compensent la variabilité des modèles.

  1. Specify (Spécifier) : un humain définit le « quoi », comportements attendus et critères d'acceptation, sans choix technique.
  2. Plan (Planifier) : l'agent dérive de la spécification un plan technique (architecture, modèles de données, interfaces, dépendances). Ce plan est relu et approuvé avant d'aller plus loin : c'est le point de contrôle le plus important du cycle.
  3. Tasks (Découper) : le plan est découpé en tâches courtes, ordonnées par dépendance, chacune rattachée à un ou plusieurs critères d'acceptation. Ce découpage permet de confier à un agent un périmètre qui tient dans sa fenêtre de contexte.
  4. Implement (Implémenter) : les agents produisent code et tests, tâche par tâche. Les tests automatisés vérifient ce que les critères d'acceptation ont permis d'encoder. La conformité à l'intention reste vérifiée par une relecture humaine (normalement) avant fusion (merge).

Principe général

graph TD
    A[Besoins] --> B[Specify : le quoi]
    B --> C[Plan : le comment]
    C --> D[Tasks : découpage]
    D --> E[Implement : code et tests par l'agent]
    E --> F[Tests automatisés]
    F -- Échec --> E
    F -- Succès --> G[Relecture humaine]
    G -- Écart avec l'intention --> B
    G -- Conforme --> H[Fusion]

Trois niveaux de SDD

Birgitta Böckeler distingue trois niveaux, selon le sort réservé à la spécification une fois la tâche terminée :

Limites et critiques

Le SDD ne fait pas consensus. En janvier 2026, Kent Beck a relevé que les descriptions du SDD supposent que l'on n'apprendra rien qui pourrait modifier la spécification pendant l'implémentation, hypothèse qu'il juge étrange. Martin Fowler a repris et enrichi cette critique, en rappelant que la boucle de feedback courte est au cœur de l'agilité. La critique vise la spécification figée avant de coder, pas la spécification en tant que telle. Le niveau spec-anchored, où la spécification évolue avec le code, y répond mieux que le spec-first.

Böckeler note pour sa part que les outils produisent parfois des quantitées de spécification disproportionnés pour de petits changements, donc difficiles à relire.

Trois écueils reviennent dans les retours de praticiens :

Ce que le SDD n'est pas

Sources

Provenancemanual éditorial
Établie le2026-09-10

Cet en-tête est saisi à la main, comme toute cette page : elle est rédigée de bout en bout, et ne porte aucun bloc calculé.