Qu'est-ce que le développement piloté par les spécifications ? La spécification comme source de vérité

La spécification comme source de vérité, et non comme document annexe.

Sommaire

Le développement piloté par les spécifications est l’une de ces idées que les ingénieurs logiciels ont tenté d’adopter par le passé, puis mises de côté lorsque l’effort investi n’était plus rentable.

Ce qui a changé en 2025, c’est l’arrivée des agents de codage IA, qui ont rendu l’absence d’intention explicite coûteuse. Les invites (prompts) sont éphémères. Les sessions des agents sont réinitialisées. Le code change, mais le raisonnement qui le sous-tend disparaît. La spécification est l’artefact qui empêche cela de se produire.

Qu’est-ce que le développement piloté par les spécifications – la spécification comme source de vérité pour l’IA

La spécification devient la source de vérité

Pendant la majeure partie de l’histoire du développement logiciel, la spécification était soit un artefact de planification temporaire, soit une réflexion après coup. Les exigences vivaient dans les tickets, les décisions de conception dans les fils de discussion, et le code était la vérité terrain. La documentation décrivait ce qui existait a posteriori.

Le développement piloté par les spécifications inverse cette relation. La spécification devient l’artefact principal. Le code est ce qui est généré ou vérifié par rapport à la spécification, et non l’inverse.

Ce n’est pas une nouvelle idée. Les méthodes formelles, la conception par contrat et le BDD (Behavior-Driven Development) en contiennent toutes des versions. Ce qui est nouveau, c’est la motivation pratique : les agents de codage IA ont besoin d’un contexte explicite et durable pour produire un résultat correct et cohérent. Les invites sont trop éphémères. La spécification est le seul artefact capable de transporter l’intention à travers les sessions des agents, les membres de l’équipe et le temps.

Ce que signifie réellement le développement piloté par les spécifications

Le développement piloté par les spécifications, généralement abrégé en SDD (Spec-Driven Development), est un flux de travail dans lequel une spécification versionnée guide ou génère l’implémentation. La spécification est rédigée et revue avant que l’agent ne code. Elle capture :

  • Ce qui doit être construit – problème utilisateur, objectifs et non-objectifs
  • À quoi ressemble un comportement correct – critères d’acceptation, cas limites, états d’erreur
  • Comment le construire – décisions architecturales, modèle de données, contrats API, contraintes de sécurité
  • Comment le vérifier – stratégie de test, règles de validation, traçabilité jusqu’aux exigences

La spécification n’est pas un document ponctuel. Elle est mise à jour lorsque la réalité diffère de la conception. Lorsque l’agent découvre quelque chose lors de l’implémentation que la spécification a mal interprété, la spécification est corrigée avant de continuer. La spécification reste fidèle car elle est traitée comme du code.

Des travaux académiques récents formalisent ce cadre : les chercheurs décrivent le SDD comme le traitement des spécifications comme source de vérité et du code comme généré ou vérifié par rapport à elles. L’interprétation pratique est que la spécification est le record durable et revu de l’intention que tout humain ou outil IA peut lire et auquel faire confiance.

Trois termes capturent différents points sur le spectre d’utilisation des spécifications :

Spécification en premier (Spec-first) signifie écrire la spécification complète avant le début de toute implémentation. C’est l’interprétation la plus stricte et celle qui se rapproche le plus du modèle en cascade si elle n’est pas faite avec soin.

Spécification ancrée (Spec-anchored) signifie maintenir une spécification synchronisée avec l’implémentation tout au long du cycle de vie de la fonctionnalité. La spécification est mise à jour au fur et à mesure que les décisions changent. C’est la version la plus pratique pour la plupart des équipes.

Spécification comme source (Spec-as-source) signifie générer ou valider l’implémentation à partir de la spécification, soit par des agents IA, soit par des outils qui vérifient le code par rapport aux contraintes de la spécification. C’est la direction vers laquelle des outils comme GitHub Spec Kit et Kiro se dirigent.

Pourquoi le SDD est important maintenant

La réponse honnête est que le SDD n’est pas séduisant pour un développeur solo construisant un script d’une journée. Le surcoût n’en vaut pas la peine.

Le SDD devient précieux lorsque trois conditions sont réunies : la fonctionnalité est suffisamment grande pour s’étendre sur plusieurs sessions, l’agent doit prendre des décisions qui affectent l’architecture, et le travail sera revu ou continué par quelqu’un d’autre.

Les trois conditions sont de plus en plus courantes avec le développement assisté par IA.

Les LLMs ont besoin de contexte, pas seulement d’invites. Un modèle qui reçoit une invite vague prend des décisions vagues. Un modèle qui reçoit une spécification revue avec des contraintes explicites, des non-objectifs et des critères d’acceptation prend de meilleures décisions et est plus facile à recentrer lorsqu’il dérive. Cela se connecte à la façon dont la récupération et la représentation fonctionnent : donner à un agent une spécification versionnée est une forme de récupération structurée de l’intention du projet.

La génération de code est bon marché ; décider quoi construire reste difficile. Le goulot d’étranglement dans le développement assisté par IA n’est plus la frappe – c’est savoir quoi construire et comment contraindre l’agent. Le SDD déplace l’effort là où il compte : spécifier l’intention clairement avant que la génération ne commence.

Les invites sont éphémères. L’agent ne se souvient pas de ce que vous lui avez dit lors de la session précédente. Une spécification versionnée stockée dans le dépôt, oui. Chaque nouvelle session peut lire la même spécification et implémenter selon la même intention sans rétablir le contexte à partir de zéro.

Le « Vibe Coding » fonctionne jusqu’à ce qu’il ne fonctionne plus. Pour les prototypes et le travail jetable, l’invocation ad-hoc est plus rapide et appropriée. Dès qu’une fonctionnalité nécessite des contraintes de sécurité, des décisions architecturales multi-fichiers ou un transfert d’équipe, l’absence de spécification devient la principale source de dérive et de défauts. Consultez la comparaison dans SDD vs Vibe Coding pour savoir quand chaque approche s’applique.

Artefacts principaux

Un flux de travail SDD pratique produit quatre artefacts principaux. Chacun réduit une ambiguïté spécifique avant qu’elle n’atteigne l’agent.

Spécification des exigences. L’énoncé du problème, les utilisateurs concernés, les objectifs, les non-objectifs explicites et les critères d’acceptation. Les non-objectifs sont aussi importants que les objectifs – ils disent à l’agent quoi ne pas construire et empêchent la dérive de périmètre. Les critères d’acceptation sont assez précis pour que chacun corresponde à au moins un test.

Spécification de conception. Les décisions architecturales pertinentes pour cette fonctionnalité : modules affectés, modifications du modèle de données, contrats API, migrations, contraintes de sécurité, exigences d’observabilité et modes de défaillance connus. Ce n’est pas un document de conception système complet – c’est le sous-ensemble des décisions architecturales nécessaires pour implémenter correctement cette fonctionnalité.

Plan de tâches. Une séquence de petites tâches d’implémentation, chacune avec des dépendances explicites, des modifications de fichiers attendues et des critères de validation. Les tâches sont suffisamment petites pour être implémentées en une seule session d’agent et vérifiées avec un diff ciblé. Chaque tâche a un point de contrôle de révision humaine.

Enregistrement de traçabilité. Une cartographie des critères d’acceptation vers les tests, des décisions de conception vers les fichiers affectés, et des tâches vers les commits. C’est ce qui sépare le SDD de la documentation qui devient périmée : la traçabilité rend possible la vérification que la spécification a été effectivement implémentée, et non seulement écrite.

Ces artefacts n’ont pas à être lourds. Une fonctionnalité simple pourrait produire un seul document markdown de deux pages couvrant les quatre domaines. Le format importe moins que l’habitude d’écrire l’intention avant le début de l’implémentation.

Comment le SDD diffère de la documentation

La confusion la plus courante est de traiter les artefacts SDD comme de la documentation. Ils ne sont pas de la documentation au sens conventionnel.

La documentation décrit. Elle vous dit ce que le système fait, comment l’utiliser et ce qu’il contient. Elle est écrite a posteriori et mise à jour lorsque le système change.

Les spécifications contraignent. Une spécification dit à l’agent ce qu’il est autorisé à construire et ce qu’il n’est pas autorisé à faire. Elle est authoritative avant le début de l’implémentation. Elle est validée après la fin de l’implémentation. Une spécification qui décrit ce qui a été effectivement construit – plutôt que de contraindre ce qui devrait être construit – a déjà échoué dans son but.

Les spécifications exécutables guident la génération et la validation. Les meilleures spécifications SDD sont suffisamment proches du lisible par machine pour qu’un agent puisse implémenter par rapport à elles et qu’une suite de tests puisse les vérifier. Des critères d’acceptation écrits comme « le point de terminaison doit rejeter les demandes non authentifiées avec une réponse 401 » constituent une spécification exécutable ; « le point de terminaison est sécurisé » est de la documentation.

Les registres de décision – ADRs, PDRs et DDRs – sont complémentaires aux artefacts SDD mais servent un but différent. Les registres de décision capturent pourquoi un choix a été fait et ce qui a été rejeté. Les spécifications SDD capturent quoi construire et comment le vérifier. Les deux appartiennent au dépôt. Ensemble, ils donnent aux agents IA le tableau complet : l’intention actuelle et le raisonnement qui la sous-tend.

Comment le SDD diffère du TDD

Le développement piloté par les tests et le développement piloté par les spécifications sont souvent confondus car tous deux produisent des artefacts explicites avant l’existence du code. La différence réside dans le point de départ.

Le TDD commence par les tests. Vous écrivez un test qui échoue décrivant le comportement souhaité, puis vous écrivez le code minimum pour le faire passer. Le TDD est une boucle de rétroaction au niveau de l’unité. Il produit de bons tests mais ne répond pas à la question de savoir si vous construisez la bonne chose.

Le SDD commence par l’intention. Avant l’existence des tests, avant que l’architecture ne soit décidée, la spécification répond : qui a ce problème, à quoi ressemble un comportement correct, qu’est-ce qui est explicitement hors de portée. La spécification informe ensuite quels tests écrire, c’est pourquoi un bon SDD et un bon TDD sont complémentaires plutôt que concurrents.

Une façon pratique d’y penser : le SDD pilote le TDD. Les critères d’acceptation dans la spécification deviennent les scénarios de test. La spécification de conception identifie les limites d’intégration qui nécessitent des tests de contrat. Le plan de tâches identifie quels comportements unitaires nécessitent une couverture de test avant que l’agent ne les implémente.

Comment le SDD diffère du BDD

Le développement piloté par le comportement utilise des scénarios en langage naturel – généralement au format Gherkin – pour décrire le comportement attendu du point de vue de l’utilisateur. Ces scénarios comblent le fossé entre l’intention métier et l’implémentation technique.

Le SDD est plus large. Il inclut des descriptions de comportement (qui peuvent utiliser un langage de style BDD ou du texte brut) mais couvre également les décisions architecturales, les modèles de données, les contraintes de sécurité, la planification des tâches et la traçabilité. Le BDD peut être un format utile pour écrire les critères d’acceptation à l’intérieur d’une spécification d’exigences SDD. La spécification est le conteneur ; les scénarios BDD sont une manière d’écrire ce qui y va à l’intérieur.

La distinction a de l’importance en pratique : les outils BDD se concentrent sur le rendu des scénarios exécutables. La pratique SDD se concentre sur le rendu de l’intention durable – à travers les outils, les sessions et les membres de l’équipe.

Comment le SDD diffère des méthodes formelles

Les méthodes formelles utilisent la notation mathématique et la vérification automatisée pour prouver des propriétés des systèmes logiciels. Elles sont extrêmement rigoureuses et extrêmement coûteuses pour la plupart des contextes de développement en production.

Le SDD ne nécessite pas de notation formelle. Un fichier markdown avec des critères d’acceptation et des décisions architecturales est une spécification. Il contraint sans être mathématiquement formel. Le niveau de rigueur évolue avec les enjeux : une spécification pour un service de facturation devrait être plus précise et plus soigneusement revue qu’une spécification pour une page de documentation.

La relation est un spectre :

  • Spécification en prose informelle (SDD minimum viable)
  • Markdown structuré avec critères d’acceptation et non-objectifs
  • Spécification lisible par machine avec validation de schéma
  • Tests de contrat dérivés directement de la spécification
  • Spécification formelle avec preuve automatisée

La plupart des équipes opèrent au milieu de ce spectre. Le but n’est pas la rigueur mathématique – c’est rendre l’intention suffisamment explicite pour qu’un agent IA puisse implémenter par rapport à elle et qu’un réviseur humain puisse vérifier le résultat.

Avantages du développement piloté par les spécifications

Moins de dérive d’intention. La spécification est la référence. Lorsque l’agent dérive – et il le fera – le réviseur a quelque chose contre quoi comparer l’implémentation. Sans spécification, la dérive est invisible jusqu’à ce que quelque chose casse.

Meilleures sorties IA. Les agents donnés des contraintes explicites, des non-objectifs et des critères d’acceptation produisent des implémentations plus proches de ce qui était intentionné et plus faciles à corriger lorsqu’ils manquent. La qualité du contexte détermine directement la qualité de la sortie.

Révision plus facile. Une demande de tirage (pull request) attachée à une spécification est plus facile à réviser qu’une demande de tirage qui nécessite au réviseur de reconstruire l’intention à partir du code. La spécification est la liste de contrôle de révision.

Alignement d’équipe. Lorsque plusieurs personnes ou agents travaillent sur la même fonctionnalité, la spécification est le contrat partagé. Sans elle, chaque contributeur optimise localement et les pièces peuvent ne pas s’adapter.

Meilleure planification des tests. Les critères d’acceptation dans la spécification se mapent directement aux cas de test. La couverture de test devient une question de couverture de spécification : chaque critère d’acceptation est-il couvert par au moins un test ?

Transfert durable. Lorsqu’une fonctionnalité change de main – entre ingénieurs, entre sessions d’agent, entre sprints – la spécification est l’artefact de transfert. Elle capture ce qui a été décidé, ce qui était hors de portée et ce qui reste à valider.

Coûts du développement piloté par les spécifications

Effort initial. Écrire une bonne spécification avant d’écrire le moindre code prend du temps. Pour les petites fonctionnalités, ce surcoût est réel et parfois non rentable.

Confiance fausse. Une spécification qui existe mais n’est pas validée par rapport à l’implémentation donne un faux sentiment de correction. Les spécifications périmées sont parfois pires que l’absence de spécification : elles induisent en erreur les réviseurs et les agents qui les lisent.

Spécifications périmées. Les spécifications dérivent lorsque l’équipe les traite comme des artefacts de planification plutôt que des documents vivants. Mettre à jour la spécification lorsque l’implémentation diffère de la conception n’est pas optionnel – c’est ce qui sépare le SDD de la documentation qui s’accumule et se dégrade.

Bureaucratie générée. Les agents IA peuvent générer des listes de tâches exhaustives et des spécifications verbeuses rapidement. Une spécification de 200 tâches générée en trente secondes n’est pas une spécification utile – c’est un générateur de bureaucratie. Un bon SDD nécessite du jugement sur quoi spécifier et quoi laisser implicite.

Enfermement aux outils. Certains outils SDD sont dogmatiques quant au format, à la structure des fichiers et au flux de travail. Une spécification écrite dans un format propriétaire est plus difficile à transporter à travers les outils qu’un fichier markdown avec des en-têtes clairs et des critères d’acceptation.

Conclusion

Le développement piloté par les spécifications n’est pas une nouvelle méthodologie. C’est une vieille discipline qui redevient pratique car le coût de l’intention implicite est maintenant visible dans le code généré par IA.

La discipline est simple : écrire ce que vous avez l’intention de construire, revu et versionné, avant que l’agent ne le construise. Garder ce record honnête en le mettant à jour lorsque la réalité diffère. L’utiliser comme référence pour la révision, les tests et le transfert.

La spécification n’est pas magique. Une spécification qui n’est pas validée devient le type de documentation le plus coûteux : celle qui induit en erreur avec confiance. Un bon SDD est la pratique de garder les spécifications honnêtes – suffisamment petites pour être maintenues, suffisamment précises pour contraindre, et suffisamment durables pour survivre à n’importe quelle session d’agent unique.

Le SDD se situe à l’intersection des pratiques de documentation, de l’architecture de test et de la conception de code – tous couverts dans le cluster Architecture d’application en production aux côtés des registres de décision, de la conception API et des modèles d’accès aux données.

Liens utiles

S'abonner

Recevez de nouveaux articles sur les systèmes, l'infrastructure et l'ingénierie IA.