Le spec-driven development (SDD) est une façon de travailler avec un agent de code IA où une spécification structurée et validée, et non un prompt de chat, est la source de vérité : vous écrivez et validez la spec d'abord, vous la transformez en plan puis en liste de tâches, et seulement ensuite vous laissez le modèle générer le code à partir de ça. C'est une réponse directe à ce que le "vibe coding" casse dès qu'un projet dépasse le prototype de weekend : rapide sur les premiers prompts, puis en dérive à mesure que les exigences s'accumulent, non documentées, dans un historique de chat que le modèle ne peut pas retenir en entier.

Pourquoi utiliser le spec-driven development

Coder au prompt fonctionne bien pour des scripts petits et jetables. Au-delà, le mode d'échec est constant : l'intention ne vit que dans un fil de discussion, une décision prise vingt prompts plus tôt se fait silencieusement contredire par le prompt vingt-cinq, et un relecteur doit reconstruire ce que le code était censé faire avant de juger s'il le fait vraiment. Le SDD déplace l'intention dans un document qui survit à la session : la spec devient une mémoire partagée entre vous, votre équipe et le modèle, et la relecture passe de deviner l'intention à partir d'un diff à vérifier un diff contre une page qui énonce déjà cette intention.

• ✓Traçabilité : chaque bout de code généré remonte à une exigence écrite, donc la relecture devient "est-ce que ça correspond à la spec" plutôt que "c'était censé faire quoi déjà".
• ✓Cohérence sur une tâche longue : relire la spec réancre le modèle à chaque étape, plutôt que de compter sur un historique de chat toujours plus long dont il ne peut retenir qu'une partie.
• ✓Relectures moins coûteuses : le relecteur lit un document court avant que le code n'existe, plus rapide que reconstruire l'intention a posteriori depuis un gros diff.
• ✓Travail en parallèle : une fois la spec découpée en tâches cadrées, plusieurs tâches (ou plusieurs agents) peuvent avancer sur le même contrat partagé sans se marcher dessus.
• ✓Tests inclus : les critères d'acceptation écrits dans la spec se transforment presque directement en tests de non-régression, souvent avant même que la fonctionnalité soit codée.

Le SDD sur du code existant et pour corriger des bugs

Les plus gros gains du SDD viennent d'un travail cadré, en terrain neuf : un nouvel endpoint, un nouveau module, une fonctionnalité aux contours clairs. Sur du code existant, ça aide encore, mais la spec change de forme : au lieu de décrire une fonctionnalité entière, vous écrivez un court document qui énonce le comportement actuel à ne pas casser, le comportement cible à obtenir, et les contraintes (budget de performance, compatibilité ascendante, migrations de données). Ce contrat est exactement ce qui évite le plus gros risque quand on laisse un agent restructurer l'intérieur d'un module : une dérive de comportement silencieuse qui ne se voit qu'en production.

Pour un bug, le cérémonial complet du SDD est excessif sur un correctif d'une ligne, au périmètre évident ; écrire une spec coûterait plus cher que le bug lui-même. Il devient utile dès que la cause racine n'est pas claire ou que le correctif touche plusieurs points d'appel : une courte spec avec les étapes de reproduction, le comportement attendu, les contraintes, et le test de non-régression à ajouter donne à l'agent une cible concrète vers laquelle converger, et vous donne de quoi vérifier le diff plutôt que de faire confiance parce que "ça a l'air bon". La règle pratique : sortez le SDD quand un changement traverse une frontière de module ou touche une interface publique ; passez outre pour un correctif local et trivial.

Utiliser le SDD pour construire une nouvelle fonctionnalité

Le workflow popularisé par les outils SDD actuels tient en quatre étapes, chacune produisant un artefact que l'étape suivante consomme.

• ✓Specify (spécifier) : décrire ce que fait la fonctionnalité et pourquoi, en langage clair, centré sur le comportement visible par l'utilisateur et les contraintes, pas l'implémentation.
• ✓Clarify (clarifier) : une passe assistée où le modèle repère les ambiguïtés et questions ouvertes de la spec, à résoudre avant que le moindre code n'existe.
• ✓Plan : transformer la spec validée en plan technique : architecture, modèle de données, endpoints, librairies choisies.
• ✓Tasks et implement (tâches et implémentation) : découper le plan en petites tâches vérifiables indépendamment, puis laisser l'agent de code les implémenter une par une, en vérifiant chacune contre la spec et en lançant les tests avant de passer à la suivante.

## Fonctionnalite : reinitialisation de mot de passe

### User story
En tant qu'utilisateur ayant oublie son mot de passe, je peux
demander un lien de reinitialisation par email et definir un
nouveau mot de passe depuis ce lien.

### Criteres d'acceptation
- Le lien expire au bout de 30 minutes.
- L'ancien mot de passe cesse de fonctionner seulement apres
  confirmation du nouveau.
- Limite a 3 demandes par heure par compte.

### Hors perimetre
- Indicateur de force du mot de passe (regle existante reutilisee telle quelle).

Les outils du spec-driven development

Comment le SDD s'intègre avec le LLM

La spec n'est pas jetée dans un seul prompt géant puis oubliée. Chaque étape du workflow en compile une partie dans le contexte de travail du modèle : l'étape plan réinjecte la spec validée pour produire un plan technique, l'étape tasks compile ce plan en unités assez petites pour tenir dans un seul tour d'agent, et l'étape implement réinjecte à chaque tour la tâche précise plus la tranche pertinente de la spec, pas le document entier. Ça garde l'agent ancré sur les mêmes exigences de nombreux tours plus tard, ce qu'un long chat en freeform ne peut pas garantir une fois que les décisions précédentes sortent du contexte.

L'autre moitié, c'est la vérification : après génération, le résultat est vérifié contre les critères d'acceptation de la spec, soit par le modèle lui-même dans une passe d'auto-vérification, soit par la suite de tests réelle issue de ces critères. Un écart rouvre la tâche au lieu de livrer silencieusement une implémentation qui a dérivé. En pratique, un workflow SDD tourne le plus souvent comme des commandes slash à l'intérieur d'un outil de code agentique, qui est lui-même un modèle dans une boucle d'appel d'outils (voir notre guide sur la construction d'un agent IA) ; quand une tâche doit sortir du dépôt, c'est en général branché via des serveurs MCP plutôt que des intégrations sur mesure (voir ce qu'est le MCP). Le modèle qui fait le plan et la génération doit rester capable d'un raisonnement fiable sur plusieurs étapes, ce qui fait partie de ce qu'il faut peser en choisissant un LLM pour un produit.

Avantages et limites

Le spec-driven development n'est pas une façon de sauter le jugement technique, c'est une façon de l'écrire noir sur blanc avant que le modèle ne commence à générer du code, pour qu'il puisse être vérifié, réutilisé d'une tâche à l'autre, et relu par l'agent à chaque étape plutôt que de disparaître d'un historique de chat. Sortez-le pour tout ce qui traverse une frontière de module ou définit une nouvelle fonctionnalité ; passez outre le cérémonial pour un correctif trivial où une spec coûterait plus cher que le bug.