Développement orienté par les spécifications
From Wikipedia, the free encyclopedia
Développement piloté par les spécifications (en anglais : spec-driven development, SDD) est une méthodologie de génie logiciel dans laquelle une spécification formelle et lisible par machine constitue la source de vérité faisant autorité[1], et l'artéfact principal à partir duquel l'implémentation, les tests et la documentation sont dérivés[2],[3]. Contrairement au développement traditionnel où la documentation est souvent rétrospective, le développement piloté par les spécifications impose que l'intention du système soit explicitement définie dans un format structuré — tel qu'OpenAPI ou Markdown — avant le début de l'implémentation[4]. Dans le contexte de l'ingénierie assistée par l'IA, le développement piloté par les spécifications constitue un cadre rigoureux qui transforme les spécifications en plans d'exécution pour les agents de codage, prévenant les incohérences associées au codage ad hoc dit « vibe coding »[5].
Les racines du développement piloté par les spécifications remontent aux flux de travail de la NASA dans les années 1960 et aux premières méthodes formelles qui privilégiaient la vérification logique avant le codage. La méthodologie a été formalisée académiquement en 2004 comme une synergie entre le développement piloté par les tests (TDD) et la programmation par contrat (DbC), avant de connaître un renouveau dans les années 2020 porté par les flux de travail agentiques alimentés par les grands modèles de langage (LLM)[6].
Concepts fondamentaux
Le développement piloté par les spécifications moderne suit généralement un cycle de vie en quatre phases :
- Spécifier (définition des exigences fonctionnelles) ;
- Planifier (traduction de l'intention en architecture technique) ;
- Décomposer (division du plan en unités atomiques) ;
- Implémenter (génération automatisée de code et validation humaine)[7].
Ses partisans soutiennent que cette approche représente un changement de paradigme vers l'architecture comme plan de contrôle exécutable, où le code d'implémentation est considéré comme un sous-produit transitoire de la spécification maintenue — un concept parfois désigné sous le terme de « spec-as-source » (la spécification comme source)[8].
