Idée principale

Décrire un logiciel suppose de fixer un instant : une version du code, et tout ce qui tourne avec elle — la base telle qu'elle est à cette version, les écrans de cette version, les traductions de cette version. C'est la photo, et elle définit ce qui a le droit d'entrer.

Un export de base de données produit quelques mois plus tôt paraît pourtant utilisable : il décrit le même produit, à peu de chose près. Il décrit en réalité un produit plus ancien, et le « à peu de chose près » est précisément ce qu'on cherchait. Sur un pan entier, des objets présents dans le code n'avaient aucune table correspondante dans l'export — et la conclusion tirée fut qu'ils n'existaient pas.

La règle n'est pas « vérifier la date avant de conclure », parce que cette vigilance ne tient pas sur la durée. Elle est plus radicale : une source d'une autre date est remplacée par une version à jour, ou bien on s'en passe.

Pourquoi c'est important

C'est ce qui empêche une erreur muette. Une source périmée ne produit pas un message d'erreur : elle produit une absence, et une absence se lit comme une information — « cet objet n'existe pas » — alors qu'elle ne dit rien.

Et la règle se contrôle sans jugement : chaque source porte sa version, ou elle sort du périmètre. C'est une condition d'admission, pas une précaution de lecture.

Nuances et limites

L'exigence ne vaut que pour les sources censées décrire l'état du produit. Les matières qui portent ce que les gens disent — comptes rendus d'entretiens, tickets — sont datées par nature et gardent leur valeur : elles ne décrivent pas le produit, elles décrivent un usage.

La contrainte a un coût réel : reconstituer une source à la bonne version prend du temps, et la tentation de se servir de celle qu'on a sous la main revient à chaque pan.

Questions ouvertes

• À quel rythme reprendre la photo, sachant que chaque décalage transforme progressivement les sources disponibles en sources inadmissibles ?