Idée principale

Chaque fiche d'un référentiel produit porte un journal où l'on ajoute des entrées sans jamais corriger les précédentes. Une entrée qui cite une version du code signale que le produit a changé. Une entrée qui n'en cite pas signale autre chose : c'est notre compréhension qui a changé, pas le logiciel.

La distinction paraît mineure au moment de l'écrire. C'est elle qui permet, six mois plus tard, de répondre à une question que personne ne sait traiter autrement : a-t-on corrigé une fiche, ou le produit a-t-il évolué ? Sans elle, les deux mouvements se confondent dans un même « mis à jour le ».

Le mécanisme d'entretien tient avec elle : la version de référence sert de curseur et donne, par une commande, la liste de ce qui a bougé dans le produit depuis la dernière mise à jour — donc la liste de ce qu'il reste à consigner.

Pourquoi c'est important

Cela sépare deux natures d'obsolescence qui appellent des gestes différents. Une fiche en retard sur le produit se rattrape mécaniquement, en relisant les sources de la nouvelle version. Une fiche corrigée parce qu'on avait mal compris appelle une question : qu'est-ce qui nous avait trompés, et cette cause a-t-elle disparu ?

Cela permet aussi de juger la fiabilité d'une description : une fiche dont le journal ne porte que des corrections de compréhension a été écrite trop vite.

Nuances et limites

Le mécanisme suppose qu'une version du produit soit citable — un dépôt, un numéro de release. Sur un système sans référence versionnée nette, la distinction devient déclarative et s'use.

Et le journal en ajout seul grossit sans limite : au-delà d'un certain volume, il faut savoir quoi en faire, ce qui est un problème que cette note ne résout pas.

Questions ouvertes

• À quel rythme remettre à jour la version de référence, sachant que chaque report allonge la liste de ce qu'il faudra consigner d'un coup ?