Introduction
On a toujours dit qu’il fallait “écrire des specs”. Personne ne le faisait vraiment. On préférait foncer dans le code. Mais avec des IAs capables de générer 500 lignes de code en 30 secondes, foncer dans le code sans plan est devenu la recette du désastre (et de la dette technique instantanée).
Bienvenue dans le Spec-Driven Development (SDD).
Le principe
Au lieu d’écrire le code d’implémentation, vous écrivez un fichier Markdown ultra-détaillé décrivant ce que vous voulez.
- Les types de données.
- Les comportements attendus.
- Les cas d’erreurs.
- Les contraintes de sécurité.
Ensuite ? Vous donnez ce fichier à votre LLM/agent (Claude, Gemini, Copilot, Cursor, etc.), et il implémente tout.
Pourquoi ça marche maintenant ?
Avant, écrire une spec prenait autant de temps que coder. Aujourd’hui, écrire la spec est plus rapide que de coder + débugger + refactorer le code spaghetti généré par une IA sans direction claires.
Une bonne spec est le “prompt ultime”. Elle sert de contrat entre vous et l’agent IA.
Exemple de workflow SDD
- Création de
specs/auth-feature.md. - Description des écrans, des flux, et du schéma de base de données.
- Prompt : “Agis en tant que Senior Dev. Implémente la feature décrite dans @auth-feature.md en utilisant notre stack actuelle.”
- L’IA génère le code.
- Vous reviewez le code par rapport à la spec.
Si ça ne marche pas, vous ne corrigez pas le code… vous corrigez la spec et vous régénérez. C’est un changement mental radical.
Ce que ça change pour les devs
On réapprend à écrire. On réapprend à être précis. L’ambiguïté est l’ennemi. Le SDD remet la conception au centre du village, et c’est une excellente nouvelle pour la qualité logicielle.
Conclusion
Pour 2026, on parie que des outils dédiés au SDD vont émerger, intégrant specs et code de manière bidirectionnelle. En attendant, ouvrez un fichier .md avant votre .ts, et voyez la différence.
Sources:
