La spécification devient une source. Qui en répond ?

Une spécification périmée n'est plus de la mauvaise documentation

Une spécification qui n'est plus à jour a longtemps été un problème sans gravité. Elle égarait un nouvel arrivant, elle faisait perdre une heure en réunion, elle jetait un doute sur le document suivant. C'était de la mauvaise documentation, et la mauvaise documentation ne fait pas grand-chose : elle ment à des humains, qui vérifient.

Ce texte décrit un régime particulier et ne vaut que là : celui des équipes qui utilisent déjà des agents de façon régulière, au point de reconstruire une partie de leur produit à partir de son intention plutôt que de la modifier à la main. Là où la régénération reste exceptionnelle, rien de ce qui suit ne mord vraiment.

Dans ce régime, une spécification périmée cesse d'être un document dormant : elle devient une entrée. Elle est ce depuis quoi on reconstruit, et l'agent reconstruit vite, proprement, sans hésiter, quelque chose qui correspond exactement à ce qu'on voulait il y a huit mois. L'erreur ne reste plus dans le document : elle est exécutée.

Ce basculement oblige à revenir sur le statut que la spécification avait jusque-là. Le schéma qui suit n'est pas une mesure, c'est un motif — chacun jugera s'il le reconnaît dans son organisation : une spécification qui vit quelques semaines, sert à se mettre d'accord, alimente un découpage, puis se trouve abandonnée une fois le code écrit. Les écarts détectés en recette se corrigent alors dans l'implémentation, presque jamais dans le document, et personne ne s'en émeut.

Si ce motif est juste, il reposait sur une condition qu'on n'avait pas besoin d'énoncer parce qu'elle ne variait pas : écrire du code coûtait plus cher que décider ce qu'il devait faire. L'artefact qu'on protégeait était donc l'implémentation. On la versionnait, on organisait des rôles et des rituels autour d'elle ; la spécification n'était qu'un moyen d'y arriver, un échafaudage qu'on démonte une fois le bâtiment debout. C'est ce rapport de coût que les agents déplacent.

Ce qui change n'est pas l'usage de la spécification, mais son statut

Les agents ne suppriment pas cette économie : ils en inversent le terme coûteux. Quand la génération devient abondante, reconstruire une partie du produit à partir de son intention cesse d'être un projet pour devenir une opération courante.

Encore faut-il préciser depuis quoi. Ce texte ne parle que d'une régénération : celle qui part de l'intention, et non du code existant. Elle n'est pas la seule pratique possible, et rien n'oblige une équipe à l'adopter. Mais dès qu'elle l'adopte, le document qui porte l'intention change de rôle.

Il passe de document d'accord à source. Or une source ne se jette pas : elle se versionne, elle se relit, elle porte une dette, et quelqu'un répond de son état. C'est le déplacement qu'on observe ailleurs dans le SDLC agentique — la contrainte ne disparaît pas avec l'accélération de l'exécution, elle remonte vers la qualité des décisions et la circulation de l'intention. À ceci près qu'ici elle se loge dans un artefact précis, que les organisations n'ont pas l'habitude de traiter comme un actif.

Ce n'est pas un retour au cycle en V

Il pourrait être tentant d'y lire le retour du cycle en V : davantage d'écrit en amont, un gros document avant de coder, la boucle est bouclée. Une telle lecture serait toutefois réductrice, pour une raison de statut plus que de volume.

Le document du cycle en V décrivait ce qu'on allait construire. C'était un engagement, pris avant, vérifié après, et dont l'écart avec la réalité se réglait en comité de changement. Sa fonction était de figer. La spécification agentique est ce depuis quoi on construit : elle n'anticipe pas le travail, elle l'alimente, et elle est rejouée. Sa fonction n'est pas de figer, mais de rester exacte.

La conséquence est pratique avant d'être conceptuelle. Le cycle en V demandait une spécification stable et traitait chaque mise à jour comme une anomalie de processus ; le régime décrit ici demande l'inverse, et traite l'absence de mise à jour comme une dette. On ne gèle pas une source : on la maintient.

La dérive ne fait aucun bruit

Le problème pratique n'est pas d'écrire ces spécifications. C'est qu'elles se désalignent sans prévenir.

Le mécanisme est banal. Un correctif urgent appliqué directement au code un vendredi soir. Une règle de gestion arbitrée en séance et consignée dans un ticket. Un cas limite traité par un développeur qui avait compris l'intention mieux que le document ne l'exprimait. Chacune de ces décisions est raisonnable, aucune n'est une faute, et aucune ne remonte dans la spécification. Le produit continue de fonctionner, les tests passent, rien ne signale quoi que ce soit — parce qu'il n'y a effectivement rien à signaler tant que personne ne se sert de la spécification comme source.

L'écart ne coûte donc rien, jusqu'au moment où il coûte d'un coup. À la régénération suivante, l'agent produit vite un résultat cohérent avec une intention périmée. Le défaut qui en sort est plus difficile à repérer qu'un bug ordinaire : il est plausible. Il ne plante pas, il ne casse pas la CI, il applique correctement une règle qui n'a plus cours.

Ce mécanisme est un raisonnement, pas une mesure. Il tient si ces décisions échappent réellement au document, et rien ici ne dit à quelle vitesse l'écart se creuse ni à partir de quel seuil il devient coûteux : aucun périmètre instrumenté ne vient l'étayer. C'est aussi ce qui le rend inconfortable. La dette technique, elle, se manifeste par un frottement continu : chaque évolution coûte un peu plus cher, et ce surcoût fonctionne comme un signal, même mal interprété. La dérive de spécification ne produit pas ce frottement intermédiaire — elle est silencieuse, puis brutale.

Il faudrait donc un indicateur qui alerte avant la régénération, et ce texte n'en propose aucun. C'est une limite réelle, pas une précaution de style. Le taux de couverture s'est imposé parce qu'il était calculable en continu et lisible par tout le monde ; rien d'équivalent ne s'est imposé pour l'écart entre une intention et son implémentation. Si un tel dispositif existe déjà quelque part, il n'a pas cette diffusion — et le constater ne suffit pas à le construire.

Un artefact composite, et aucun propriétaire désigné

Reste la question qui commande les autres : à qui appartient cet artefact ?

Une spécification exploitable par un agent mêle trois matières que les organisations tiennent le plus souvent séparées. L'intention métier et ses arbitrages : ce qu'on veut, pour qui, avec quelles priorités et quels renoncements. Les contraintes techniques et d'architecture : ce qui est permis, ce qui est imposé, ce qui a été tranché ailleurs et ne se rediscute pas. Les critères d'acceptation enfin, qui déterminent ce qui compte comme un résultat correct.

Dans un découpage courant — pas le seul, et la nuance compte pour la suite — la première matière relève du Product Owner, la deuxième de l'architecture ou du tech lead, la troisième circule entre les deux sans propriétaire net. Une organisation qui ne se découpe pas ainsi ne rencontre pas ce problème sous cette forme ; elle en rencontre probablement un autre, qu'il faudrait décrire séparément.

Là où ce découpage existe, l'indivision restait sans conséquence tant que la spécification était jetable : chacun apportait sa part, le code arbitrait ensuite, le document mourait. Dès qu'elle devient source, l'indivision cesse d'être un détail d'organisation. Un actif alimenté par trois rôles et maintenu par aucun est exposé à la dérive. Et celle décrite plus haut n'a alors personne à qui se signaler.

Ce qu'il manque n'est pas un rédacteur. C'est un propriétaire, au sens où l'on possède un composant : quelqu'un qui décide de ce qui entre dans la spécification, qui tranche les conflits entre intention et contrainte plutôt que de les laisser se résoudre dans l'implémentation, et qui assume explicitement la dette lorsque l'organisation choisit de ne pas mettre à jour. Car ce choix reste légitime : tout ne mérite pas d'être maintenu. Encore faut-il qu'il soit pris, et non subi.

Quel rôle doit l'assumer ne se tranche pas ici. Élargir le Product Owner suppose qu'il arbitre des contraintes techniques ; confier la spécification à la tech suppose qu'elle porte l'intention métier. Les deux options ont un coût, et aucune n'a réuni assez de retour d'expérience pour être recommandée.

Ce qu'il reste à savoir

Deux des questions ouvertes ont déjà été posées en chemin : quel signal alerterait sur la dérive avant la régénération, et quel rôle porte la propriété de l'artefact. Elles ne sont pas rhétoriques — tant qu'elles restent ouvertes, ce qui précède décrit un problème sans en donner la conduite.

Une troisième n'a pas encore été nommée : à quelle granularité une spécification mérite-t-elle d'être tenue à jour ? Tout maintenir revient à recréer une documentation exhaustive dont on connaît le sort. Ne rien maintenir revient à perdre la capacité de régénérer. La ligne se trace probablement par périmètre — les zones qu'on rejoue souvent, celles où l'erreur coûte cher — mais c'est une hypothèse de travail, pas une règle : elle demande à être éprouvée sur des cas réels avant d'être érigée en méthode.

Ces trois questions ont un point commun, et c'est peut-être le vrai sujet : aucune ne se règle par l'outillage.

La question n'est peut-être pas de savoir qui écrit la spécification. Elle est de savoir qui répond de son écart avec le produit réel.