Spec-Driven Development.
Rédigez d'abord une spécification explicite et faisant autorité, puis pilotez l'implémentation, les tests et le code généré à partir d'elle — en conservant la spec comme unique source de vérité.
##Intent
Faire de la spécification précise l'artefact principal du développement. L'implémentation, les tests et même le code généré par IA sont dérivés de la spec et vérifiés par rapport à elle, au lieu que la spec soit un document jetable rédigé avant le « vrai » travail.
##Problem
Les exigences résident généralement dans la tête des gens, dans des fils de discussion ou dans des documents périmés. L'implémentation dérive de l'intention, et lorsque cela arrive il n'existe aucune référence faisant autorité pour trancher ce que le système devrait faire.
Cela fait le plus de dégâts avec le codage assisté par IA : une consigne vague produit du code d'apparence plausible qui peut ne pas correspondre à ce qui était réellement voulu, et il n'y a rien de concret pour le vérifier.
##Solution
Capturez le comportement visé dans une spécification claire et versionnée — scénarios, critères d'acceptation et contrats — et traitez-la comme la source de vérité. Générez ou guidez l'implémentation (souvent avec l'assistance de l'IA) à partir de la spec, dérivez les tests de conformité de cette même spec, et vérifiez l'implémentation par rapport à eux.
Lorsqu'un comportement doit changer, vous modifiez d'abord la spec et laissez l'implémentation et les tests suivre. C'est la spec, et non le code, que l'équipe relit et débat.
##Structure
- Spécification — intention, scénarios, critères d'acceptation et contrats/schémas, conservés sous contrôle de version.
- Génération / implémentation — code produit ou guidé pour satisfaire la spec.
- Tests de conformité — vérifications dérivées de la spec que l'implémentation doit réussir.
- Boucle de rétroaction — les divergences mettent à jour la spec, qui re-pilote le code et les tests.
##Applicability
- Utilisez-la pour le développement assisté par IA, où une spec précise transforme une consigne vague en intention vérifiable.
- Utilisez-la pour les API « contract-first », la coordination entre plusieurs équipes et les systèmes réglementés ou auditables.
- Évitez les specs lourdes pour les minuscules scripts ou les explorations rapides, où elles coûtent plus qu'elles ne rapportent.
##How to Implement
- Rédigez la spec : intention, scénarios concrets, critères d'acceptation et tout contrat ou schéma.
- Passez-la en revue avec les parties prenantes — c'est là que les désaccords se résolvent.
- Dérivez les tests d'acceptation / de conformité à partir des scénarios.
- Implémentez pour satisfaire la spec, souvent avec l'assistance de l'IA guidée par la spec.
- Exécutez les tests de conformité ; traitez les échecs soit comme des bogues, soit comme des signaux pour affiner la spec.
- Gardez la spec comme référence faisant autorité — mettez-la à jour en premier dès que le comportement change.
##Pros & Cons
- Une source de vérité unique et révisable garde l'intention explicite.
- Se marie naturellement avec la génération de code par IA, transformant les consignes en contrats vérifiables.
- La conformité peut être vérifiée automatiquement, réduisant la dérive.
- Les décisions se débattent sur la spec, avant l'écriture du code.
- Un véritable effort initial pour rédiger et maintenir la spécification.
- Les specs pourrissent et induisent en erreur si elles ne restent pas en phase avec la réalité.
- L'outillage et les conventions sont encore en cours de maturation.
- Trop spécifier peut être aussi nuisible que pas assez.
