Idée principale

Un même objet est décrit à quatre endroits d'un produit, et chacun dit ce que les autres taisent. Le cœur du code porte les règles — ce qui est interdit, ce qui est obligatoire, ce qui déclenche quoi. La base de données porte les champs, l'unicité, ce qui ne peut pas rester vide. Les écrans portent les contrôles de saisie, les champs conditionnels, les boutons grisés, les listes de choix. Les traductions portent les mots réellement affichés à l'utilisateur, dans toutes les langues.

Une règle peut très bien n'exister que dans un seul de ces quatre endroits. Lire le cœur du code et s'arrêter là — le réflexe le plus naturel, celui d'un développeur comme celui d'un agent — laisse donc sortir une description qui a l'air complète et qui ne l'est pas.

Un ordre de lecture s'impose : les écrans après le code, et avant de clore le sujet. Le rapprochement se fait objet par objet, jamais dossier par dossier, parce que le découpage de l'interface ne recouvre pas celui du serveur.

Pourquoi c'est important

C'est une condition d'achèvement opposable : « ce pan est fini » devient vérifiable ligne à ligne, un pan et un endroit par ligne, plutôt que déclaré. Un suivi à cette maille survit à l'interruption du travail et évite de refaire deux fois la même lecture.

Et c'est ce qui met les quatre sources en présence, donc ce qui rend visibles leurs contradictions.

Nuances et limites

Le critère mesure la profondeur, jamais la largeur. On peut avoir lu les quatre endroits sur une minorité des pans du produit et ignorer tout le reste — auquel cas la règle est parfaitement respectée et le travail très incomplet.

Le nombre quatre n'est pas une loi : il correspond aux endroits où ce produit-là dépose de l'information. Une architecture différente — messages échangés entre services, moteur de règles externalisé — en ajouterait d'autres.

Questions ouvertes

• Comment reconnaître, sur une architecture inconnue, la liste des endroits où l'information se dépose, avant d'avoir commencé à les lire ?