Idée principale

Quand le code dit une chose et que la base de données ou l'écran en dit une autre, le premier réflexe est d'accuser les dates : l'un des deux est en retard sur l'autre, il n'y a rien à conclure. Ce réflexe a un effet pervers — il classe en artefact de méthode ce qui est le résultat recherché.

Si les deux affirmations proviennent du même instant du produit — la même version, en production —, aucun décalage n'est en cause. Le produit se contredit lui-même : une contrainte d'unicité que le métier dément, un contrôle de saisie qu'aucune vérification serveur ne double, un champ obligatoire à l'écran et facultatif dans la base. C'est exactement le genre de divergence qu'une description croisée sert à faire remonter.

D'où la précaution d'ordre : on datera les sources d'abord, pour que toute contradiction restante soit du produit et non du dispositif d'observation.

Pourquoi c'est important

Cela transforme une gêne méthodologique en rendement. L'essentiel de la valeur d'un référentiel ne vient pas des règles qu'il recopie proprement, mais des endroits où deux parties du produit ne disent pas la même chose — chacun devenant une dette à arbitrer ou un défaut avec un enjeu de sécurité.

Cela évite aussi de « lisser » la description : devant deux affirmations contradictoires, la tentation est d'en retenir une et de passer, ce qui efface la trouvaille.

Nuances et limites

La règle exige une discipline de datation exemplaire, faute de quoi elle produit l'erreur inverse : prendre un décalage de sources pour une incohérence du produit, et ouvrir des écarts qui n'existent pas.

Et toute contradiction n'a pas le même statut : une différence entre deux applications peut être un choix assumé de portée plutôt qu'un défaut, à condition que ce choix soit écrit quelque part.

Questions ouvertes

• Quelle part de ces contradictions est acceptée sciemment par les équipes, et comment distinguer l'arbitrage tacite du défaut jamais vu ?