Le métier, celui qui construit et celui qui teste écrivent ensemble quelques exemples chiffrés d'une règle, avec le résultat attendu. Ils deviennent la spécification, puis la recette, puis une documentation qui reste juste.
Une règle comprise de deux façons se découvre en recette, ou chez l'usager. Elle se paie en développement refait et en dossiers recalculés. Posée avant, la question coûtait une heure.
Comptez-le sur vos chiffres. Un ordre de grandeur suffit pour décider d'essayer.
Pour une règle sans seuil ni exception : une phrase suffit. Et tant que personne ne peut trancher le cas débattu, nommez d'abord qui décide (fiche P-09). Un délai à tenir se déduit, lui, de l'engagement de service (fiche O-48).
Une règle en phrases se lit de plusieurs façons. En dossiers chiffrés avec leur résultat, elle ne se lit que d'une, et le désaccord se voit avant le développement.
Vingt dossiers réels rendus anonymes, un tableau vide. Ce tableau est aussi la consigne la plus claire pour un assistant d'IA qui écrit le code, et le contrôle de ce qu'il produit (fiche P-16).
Le chef de service lit la recette sans aide, et y retrouve ses dossiers.
Au lancementÉcrire les exemples seul
Le métier ou le prestataire les rédige seul. Personne ne pose la question qui gêne.
Trois regards ensemble : le testeur cherche le cas qui casse, le métier répond.
Au lancementPersonne pour trancher
Le cas débattu reste ouvert. Le développeur choisit, sans le dire.
Nommer qui décide avant la séance, et lui soumettre chaque dossier débattu.
PendantDécrire les écrans au lieu de la règle
Les exemples racontent des clics. Ils cassent à chaque nouvel écran.
Écrire ce que la règle décide, pas comment on saisit.
PendantÉcrire toutes les combinaisons
Deux cents lignes, où se perdent les trois cas qui comptent.
Un exemple par cas qui change la décision. Le reste va aux tests du prestataire.
Dans la duréeDes exemples qui dorment
Le règlement change, le document non. Un an après, nul ne sait lequel est juste.
Les faire vérifier automatiquement à chaque version. On corrige l'exemple avant le code.
La prime au loyer d'une ville, dont le conseil vient de revoir le règlement d'octroi.
Après la révision précédente, une décision sur neuf a été recalculée dans l'année.
Le règlement signé par tous, puis la recette du prestataire : 240 cas que le service n'avait jamais lus.
Les cas que le règlement ne tranchait pas, trouvés avant le développement : quatre réglés en séance, trois par le collège en dix jours.
Les décisions recalculées la première année : 84 sur 4 200, contre 4 200 × 11 % = 462 après la révision précédente.
Le temps rendu : (462 − 84) = 378 recalculs × 2,5 h = 945 h, soit 45 360 € à 48 € l'heure.
Ce que ça a coûté : 30 h d'agents × 48 € = 1 440 €, et 5 jours du prestataire × 650 € = 3 250 €. Payé en 1,2 mois de temps rendu.
Refaites-le avec votre prochaine règle : vingt dossiers réels, trois regards, chacun écrit seul le résultat attendu. Là où les réponses diffèrent, posez la question à qui tranche avant le développement.
À gauche une exigence lue de trois façons, puis le tableau d'exemples qui la remplace. À droite cinq des seize exemples du cas, et le dossier qui faisait débat.