La spec anémique : Spec-Driven Development, agents IA et règles métier

Une spécification peut être détaillée et laisser les règles métier implicites.

---

Le bouton « Annuler » fait 120 pixels de large.

Prenons un service de réservation de salles. La spec précise la couleur du bouton, le message de confirmation, l’API à appeler et le format de la réponse. L’agent dispose même d’un plan d’implémentation.

Un organisateur veut annuler dix minutes avant le début de sa réservation. La spec ne dit pas s’il en a le droit. Le délai d’annulation n’apparaît ni dans les critères d’acceptation ni dans les tâches générées.

Il manque une décision métier. Quelques lignes suffiraient à la décrire, mais quelqu’un doit d’abord la prendre.

Avec le Spec-Driven Development (SDD), les agents s’appuient davantage sur les spécifications pour produire le code. Nous devons donc pouvoir y retrouver les règles à appliquer, les exemples qui permettent de les vérifier et les points qui restent à clarifier.

La spec comme référence

Le SDD recouvre plusieurs pratiques. Birgitta Böckeler distingue trois approches : spec-first, où la spec précède l’implémentation ; spec-anchored, où elle est conservée pour les évolutions suivantes ; et spec-as-source, où l’humain modifie la spec et le code est généré à partir d’elle.

Lorsqu’elle sert de référence, une règle manquante peut avoir des conséquences sur le logiciel. Un développeur peut la retrouver grâce à sa connaissance du produit, un test existant ou une conversation. Un agent peut explorer le dépôt et poser des questions. Tous deux peuvent aussi avancer sur une hypothèse sans la faire valider.

Si les tests reprennent la même hypothèse, ils confirmeront que le code la respecte. L’ensemble pourra ensuite servir de référence à d’autres modifications. Une décision prise faute d’information devient alors difficile à distinguer d’une règle voulue par l’équipe produit.

Des règles qui restent implicites

J’appelle spec anémique une spécification qui rassemble de l’information, mais laisse implicites les décisions nécessaires au comportement attendu et les moyens de les vérifier.

Le terme fait écho à l’Anemic Domain Model décrit par Martin Fowler : les objets portent les données, tandis que les comportements sont organisés ailleurs. Je reprends cette idée de responsabilités placées ailleurs. L’analogie a ses limites : avec un Anemic Domain Model, les règles peuvent être connues et correctement appliquées. Dans une spec anémique, certaines n’ont parfois jamais été définies.

Voici ce que j’attends d’une spécification :

Responsabilité	Ce que nous devons pouvoir retrouver
Décrire l’intention	Le problème à résoudre, le résultat recherché et le périmètre.
Préciser les décisions	Les règles, leurs conditions d’application, les exceptions et les arbitrages.
Permettre la vérification	Des exemples et des résultats attendus capables de révéler une mauvaise interprétation.
Signaler les incertitudes	Les décisions validées, les hypothèses, les questions ouvertes et le hors-périmètre.
Expliquer l’origine des règles	Leur source et les personnes capables d’en préciser le sens ou de les faire évoluer.
Suivre les évolutions	Les changements, leurs raisons et les situations auxquelles ils s’appliquent.

Tout ne doit pas tenir dans un fichier unique. Une règle peut être référencée dans une documentation du domaine, un contrat ou un scénario d’acceptation. Il faut pouvoir la retrouver et savoir quelle version s’applique.

La difficulté apparaît quand ces informations restent dans la tête d’un expert ou dans une conversation que personne ne retrouve. Ajouter des pages à la spec ne résout pas forcément ce problème.

Deux implémentations possibles

Reprenons la réservation. La partie fonctionnelle tient en quelques lignes :

Fonction : traiter une demande d'annulation.
Entrée : identifiant de la réservation.
Sortie : statut de la demande.
Interface : bouton Annuler et dialogue de confirmation.

L’organisateur demande l’annulation d’une réservation confirmée, dix minutes avant son début. Deux implémentations peuvent compléter cette spec avec des règles différentes :

	Interprétation A	Interprétation B
Règle ajoutée	Annulation autorisée jusqu’au début.	Annulation autorisée jusqu’à 24 heures avant le début.
Résultat	Acceptée.	Refusée.
Tests écrits selon cette interprétation	Au vert.	Au vert.

La spec ne permet pas de trancher. Chaque version a ajouté une règle qui n’avait pas été décidée.

Un autre LLM pourrait proposer un troisième délai ou demander une précision. C’est à l’équipe produit de choisir la règle adaptée au besoin.

Lors de la revue d’une spec, chercher deux comportements métier incompatibles mais tous deux permis par le texte aide à repérer ce type de manque. Plusieurs architectures peuvent satisfaire une même exigence. Dans cet exemple, le désaccord concerne directement le droit de l’utilisateur à annuler.

Garder les incertitudes visibles

Exiger toutes les règles avant de commencer suppose de connaître le besoin jusque dans ses détails. Nous avons surtout besoin des décisions nécessaires au périmètre traité et de savoir ce qui reste à clarifier.

L’Example Mapping distingue les règles, les exemples et les questions sans réponse. Cette séparation aide à ne pas confondre une hypothèse bien rédigée avec une exigence validée.

Supposons que l’équipe produit retienne le délai de 24 heures. La spec pourrait contenir ceci :

R-12 - Annulation par l'organisateur

Statut : décision validée par l'équipe produit.
Origine : arbitrage sur le délai minimal d'annulation.

Règle : l'organisateur peut annuler une réservation confirmée si son début est à au moins 24 heures de l'instant de la demande. Le délai est une durée écoulée, indépendante des heures locales.

Exemples :
- Exactement 24 heures avant : annulation acceptée.
- 23 heures et 59 minutes avant : annulation refusée.
- En cas de refus, la réservation reste confirmée.

Hors périmètre : les dérogations accordées par un administrateur.
Question ouverte : que faire si la notification ne peut être remise ?

Les exemples précisent la limite et permettent de la tester. Ils ne couvrent pas toute la stratégie de test de la fonctionnalité.

Le problème de notification reste ouvert. On peut expérimenter la règle d’annulation sans l’avoir résolu, à condition de savoir ce qu’on pourra évaluer et ce qui restera incomplet.

La distinction entre décision validée, hypothèse à tester, question ouverte et décision remplacée permet de travailler sans donner à toutes les lignes du document le même statut.

Le versionnement garde la trace des modifications. Il faut aussi préciser leur portée métier. Si le délai d’annulation change, la nouvelle règle peut s’appliquer aux futures réservations tout en laissant les anciennes soumises aux conditions précédentes. La date du commit ne suffit pas à définir cette politique.

Les boucles de feedback

Le feedback commence pendant l’implémentation. Écrire le code peut révéler une contradiction, un cas limite, une contrainte technique ou une distinction absente du modèle. La spec doit pouvoir évoluer à partir de ces découvertes.

Kent Beck critique les démarches qui supposent que l’implémentation n’apprendra rien susceptible de modifier la spec. Le travail sur le comportement continue pendant le développement, puis avec les retours d’usage.

Nous avons deux choses à vérifier :

• La conformité : le logiciel respecte les décisions formulées.
• La pertinence : ces décisions produisent le résultat recherché.

Les tests peuvent vérifier la règle des 24 heures. Les retours des utilisateurs peuvent nous apprendre que cette règle les empêche de libérer des salles qui resteraient autrement inoccupées. Le logiciel respecte alors la spec, mais ce retour peut conduire à revoir la règle.

Lorsqu’un écart apparaît, l’équipe doit décider s’il faut corriger le code, revoir la règle ou poursuivre l’exploration. Modifier automatiquement la spec pour l’aligner sur le code pourrait entériner une erreur.

Organiser la revue des specs

Faire relire une spec par un autre LLM peut aider à trouver des contradictions et des contre-exemples. L’accord de plusieurs modèles ne permet pas de savoir si une règle convient au métier.

Je préfère demander des objections précises :

Règle concernée : ...
Deux interprétations possibles : ...
Situation qui permet de les départager : ...
Conséquence pour l'utilisateur : ...
Information ou arbitrage nécessaire : ...

L’équipe peut alors corriger, expérimenter ou différer le point soulevé. Une suite de reformulations et de cas hypothétiques peut aussi prolonger la revue sans aider à décider. La revue peut s’arrêter quand l’équipe dispose des décisions nécessaires au prochain incrément et sait comment en évaluer le résultat.

La quantité de texte compte également. Dans ses essais de SDD, Böckeler décrit une charge de lecture parfois disproportionnée pour de petites tâches. Si le volume généré dépasse ce que l’équipe peut examiner, certaines parties risquent d’être validées sans vraie revue.

Les experts métier et l’équipe produit examinent les règles et les résultats attendus décrits dans la spec. Les développeurs examinent le modèle, les contraintes et leurs conséquences techniques. Le travail de test apporte des contre-exemples et précise les résultats observables. Une même personne peut contribuer à plusieurs de ces activités.

Pour faciliter cette revue, une règle doit être facile à retrouver, avec sa justification et ses exemples. La recopier dans cinq fichiers multiplie les endroits à corriger lors du prochain changement.

L’apport du DDD

Le Domain-Driven Design (DDD) aide à préciser le vocabulaire partagé avec le métier (Ubiquitous Language), les frontières du modèle et les invariants à protéger. Une « annulation demandée », une « annulation acceptée » et une « réservation annulée » peuvent désigner des faits différents. Les regrouper dans un champ status sans préciser leurs relations laisse une partie du comportement indéfinie.

Les Bounded Contexts précisent où ce vocabulaire s’applique. Le travail sur les Aggregates aide à définir les frontières dans lesquelles les invariants doivent être préservés. Le Behavior-Driven Development (BDD) et les exemples fournissent des situations concrètes pour discuter ces règles et les vérifier.

Ce travail se fait avec les personnes qui connaissent le domaine. Des rubriques « DDD », « Aggregates » ou « invariants » dans un document ne garantissent pas que les décisions correspondantes ont été prises.

Avant de confier une spec à un agent, je veux pouvoir en vérifier les règles, comprendre les arbitrages et repérer les incertitudes. La revue des specs s’appuie sur des exemples pour vérifier que le comportement décrit répond au besoin. Elle reprend chaque fois qu’un feedback conduit à modifier une règle.

---

Références

Spec-Driven Development

• Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, martinfowler.com, octobre 2025 : les trois approches spec-first, spec-anchored et spec-as-source, et la charge de lecture observée sur de petites tâches. martinfowler.com
• Kent Beck, post LinkedIn sur les descriptions du Spec-Driven Development : la critique des démarches qui supposent que l’implémentation n’apprendra rien susceptible de modifier la spec. linkedin.com

Modélisation du domaine

• Martin Fowler, AnemicDomainModel, martinfowler.com : des objets qui portent les données, des comportements organisés ailleurs. martinfowler.com
• Martin Fowler, BoundedContext, martinfowler.com : où s’applique un vocabulaire. martinfowler.com
• Vaughn Vernon, Aggregates, extrait de Implementing Domain-Driven Design (Addison-Wesley, 2013), InformIT : les frontières dans lesquelles les invariants doivent être préservés. informit.com

Exemples

• Matt Wynne, Introducing Example Mapping, Cucumber, décembre 2015 : distinguer les règles, les exemples et les questions sans réponse. cucumber.io

---

Les situations de réservation sont fictives. Les graphiques sont conceptuels ; ils ne représentent pas des résultats de mesure. Illustration de couverture générée avec une IA.