Idée principale

Quand un contrôle n'est appliqué que par l'interface — un plafond de remise vérifié dans le formulaire de saisie et nulle part ailleurs —, deux lectures seulement sont possibles, et les deux sont des écarts.

Soit c'est une vraie règle métier, mal placée : elle devrait vivre là où vivent les règles, et sa présence dans l'écran est un défaut de conception à arbitrer. Soit elle est contournable — par un import de fichier, par l'interface que le produit expose aux développeurs extérieurs — et c'est alors un défaut avec un enjeu de sécurité : ce que l'écran interdit, un autre chemin l'autorise.

Le cas inverse se traite de la même manière. Une règle appliquée par le cœur du code que l'écran ne reflète pas produit un refus incompréhensible : l'utilisateur voit son action rejetée sans voir ce qu'il a fait de mal.

Pourquoi c'est important

Cela transforme la lecture des écrans — d'habitude reléguée en fin de course, quand elle est faite — en machine à trouver des écarts. Le rendement est élevé parce que la question ne demande aucun jugement : il suffit de constater qu'une règle n'a pas de jumelle côté serveur.

Cela donne aussi un argument pour ne pas sauter cette lecture quand le temps manque : c'est la partie du produit qui rapporte le plus par heure passée.

Nuances et limites

« Presque toujours » : une aide à la saisie qui n'a aucune portée métier — un format de date proposé, un champ masqué pour alléger l'écran — n'est pas une règle et ne devient pas un écart.

Le contournement suppose un autre chemin réellement ouvert. Sur un produit sans import ni interface externe, le premier cas — la règle métier mal placée — reste seul en lice.

Questions ouvertes

• Une fois la règle remontée côté serveur, que devient le contrôle de saisie : duplication assumée pour le confort, ou source de divergence future ?