Bloquer ou signaler, trois questions à poser à chaque règle

Toute règle métier arrive avec la même question implicite. Est-ce que j’empêche, ou est-ce que je préviens ? Le réflexe est d’empêcher. C’est plus court à écrire, ça se teste en une ligne, et ça donne l’impression de protéger l’utilisateur.

Voici trois tests à passer sur chaque règle avant de trancher. Le troisième décide de quelque chose qu’on ne voit venir que plus tard.

Est-ce impossible, ou seulement déconseillé ?

Autrement dit, le résultat existe-t-il dans le monde réel ?

Un meuble qui traverse un mur n’existe pas, donc la règle bloque. Une armoire avec 60 cm devant elle au lieu des 75 qu’il faudrait pour ouvrir ses portes existe très bien. C’est une armoire pénible à utiliser, dans un logement où la personne a peut-être d’autres priorités. La règle prévient.

Le test est plus tranchant qu’il n’y paraît, parce qu’il déplace la charge de la preuve. Une règle bloquante doit démontrer que le résultat est impossible, pas seulement qu’elle a de bonnes raisons d’exister.

Est-ce un booléen, ou une quantité ?

Deuxième test. Sauriez-vous dire de combien la règle est enfreinte ?

Si oui, elle est signalable. Si vous ne savez répondre que par oui ou non, soit c’est un vrai blocage, soit la règle est mal formulée.

Beaucoup de règles qui ressemblent à des booléens cachent une quantité. « Le canapé doit faire face à la télévision » a l’air binaire. En pratique il y a une distance de recul confortable, une plage acceptable autour, et un décentrage qu’on tolère jusqu’à un certain point. Chercher la quantité cachée est souvent le vrai travail de modélisation, et c’est par là qu’il faut commencer si vous voulez reprendre vos propres validations.

Voulez-vous que le logiciel sache proposer ?

C’est le test que personne n’applique, et c’est celui qui coûte le plus cher quand on l’oublie.

Des règles bloquantes vous donnent un validateur. Il sait dire valide ou invalide. Des règles pondérées vous donnent un solveur, qui sait classer. Et un logiciel qui sait classer sait proposer.

Le solveur d’aménagement que j’ai mis dans mes labs essaie 72 dispositions et garde la moins fautive. Il ne peut le faire que parce que chaque infraction porte un poids. Un meuble qu’on n’atteint plus depuis la porte vaut 20, un voisinage rompu 4, un dossier qui ne touche pas le mur 2. Si toutes ces règles étaient bloquantes, il n’aurait devant lui que des dispositions valides et des invalides, et parmi les valides il prendrait la première venue.

Donc si un jour vous voulez d’un « range ça pour moi », d’un « propose-moi une correction », d’une mise en page automatique, il vous faut des coûts. La décision se prend bien avant que la fonctionnalité soit au programme, et elle se prend règle par règle sans qu’on s’en aperçoive.

Les deux façons de se tromper

Trop bloquer se paie deux fois. L’utilisateur contourne, en décalant l’objet ou en trichant sur une dimension, et vous obtenez un résultat qui satisfait le logiciel sans satisfaire personne. Et vous vous fermez la porte des propositions automatiques.

Trop signaler se paie une fois, mais franchement. Au-delà de quelques avertissements visibles en même temps, plus personne ne les lit. Deux garde-fous simples aident, ne montrer que les infractions de l’objet sélectionné, et les ordonner par poids plutôt que par ordre d’apparition dans le code.

Ce que ça coûte

Signaler demande, pour chaque règle, une phrase lisible qui nomme l’infraction, un chiffre qui la mesure, et un endroit à l’écran où la montrer. Un blocage demande un booléen et un message d’erreur.

C’est donc plus de travail, et c’est le travail qu’on coupe en premier quand le planning serre. Dans mon lab, à peu près la moitié du code sert à formuler les infractions plutôt qu’à les détecter. C’est aussi cette moitié qui décide si l’outil saura un jour répondre à la place de l’utilisateur.