Idée principale

Mettre à jour un artefact produit a toujours consisté à corriger sa version précédente : on rouvre la spécification écrite il y a dix-huit mois, on cherche les paragraphes touchés par la dernière livraison, et on les réécrit. Le document hérite alors de tout ce qui n'a pas été relu — des comportements retirés depuis, des écrans qui n'existent plus, des hypothèses démenties par le développement.

L'autre voie consiste à jeter la version précédente et à régénérer l'artefact depuis le dépôt : la documentation de support après une livraison, le changelog, la spécification fonctionnelle de l'état courant. Le document ne porte plus l'accumulation de ses versions, il porte une date de lecture du code.

Le gain n'est pas la vitesse d'écriture. C'est que l'artefact cesse d'être un stock qu'il faut entretenir pour devenir une projection qu'on relance. Une projection ne diverge pas : elle est périmée ou elle est refaite.

La règle s'applique à l'intérieur d'un même document dès qu'il mélange deux matières. Dans une fiche d'objet produit, le corps décrit la réalité telle qu'elle est dans le code : il se jette et se refait sans rien perdre. Les écarts entre cette réalité et ce qu'on voudrait, eux, viennent d'une décision humaine, ne se retrouvent nulle part si on les perd, et se rangent donc dans un bloc séparé qu'aucune régénération ne touche. Ce que l'on régénère et ce que l'on maintient ne cohabitent qu'à condition d'être visiblement séparés.

Couche apportée par « J'ai écrit l'ontologie d'un produit. Trois fois, j'ai cru avoir fini. » (2026-08-11).

Couche apportée par « Quatre jours de vibe coding… » (2026-07-28). Le renversement ne concerne pas que la mise à jour d'un document existant : il touche aussi le moment où le premier document est écrit. Sur un outil interne construit directement par un profil produit, il n'y a pas eu de spécification préalable — la personne s'est lancée, a construit, a montré, a reçu des demandes d'évolution et a itéré. Le comportement a émergé dans le produit, et la documentation fonctionnelle a été générée ensuite depuis le code. La séquence habituelle s'inverse alors complètement : on ne régénère pas un document faute d'avoir pu le maintenir, on le génère parce qu'il n'a jamais été écrit avant.

Pourquoi c'est important

C'est ce qui rend l'écart entre le produit et sa documentation traitable sans discipline. Tant qu'on met à jour, la divergence s'accumule à chaque itération sautée ; dès qu'on régénère, une itération sautée ne laisse aucune dette — la régénération suivante repart du même endroit.

Cela change aussi ce qu'on archive : il devient plus utile de conserver la capacité à régénérer que la dernière version produite.

Nuances et limites

Le code ne porte pas l'intention. Une spécification régénérée dit ce que le produit fait, pas pourquoi ce comportement a été retenu ni ce qui a été écarté — et cette perte est invisible, puisque le document paraît complet.

La régénération n'est pas gratuite non plus : elle demande une relecture, et une sortie fausse qui a l'air juste coûte plus cher qu'un document manifestement périmé.

Questions ouvertes

• Quelle part d'un artefact doit rester écrite à la main parce qu'aucune régénération ne peut la retrouver ?