Revue juridique

Pourquoi

Une règle de droit ne devient opposable dans le produit qu'après avoir été relue par un juriste habilité — jamais parce qu'un développeur l'a codée avec bonne foi. Ce processus organise cette relecture pour que chaque cellule du référentiel de sûretés utilisée en production ait été effectivement validée par quelqu'un qui en porte la responsabilité.

Comment dans l'application

Une règle traverse une machine à états à quatre positions : PROPOSEE_A_VALIDER, puis, après validation, VALIDEE_CONSEIL, et enfin, après un second geste distinct, ACTIVEE — seul cet état rend la règle utilisable en production. La distinction entre les deux derniers états est volontaire : le conseil peut dire ce que le droit permet sans que quiconque ait encore décidé de s'en servir, par exemple parce qu'un moteur n'est pas prêt ou qu'une question opérationnelle reste ouverte. Une position de correction (A_CORRIGER) permet de renvoyer une proposition en amont sans la perdre.

Trois habilitations distinctes gouvernent ces gestes : relire, commenter et demander une correction sont ouverts à un réviseur ; verser une proposition dans l'espace de revue est ouvert à un éditeur de règles, qui n'emporte aucun pouvoir de validation ; valider et activer sont tous deux réservés à un approbateur, enregistré nommément avec le cabinet et la source de son habilitation. Chaque correction d'une règle déjà proposée crée une nouvelle version plutôt que d'écraser la précédente — une règle relue six mois plus tard doit pouvoir montrer ce qui avait été soumis et ce que le conseil avait répondu à ce moment-là.

Le référentiel de base couvre vingt-deux régimes de sûretés OHADA, complétés par des surcouches nationales propres à chaque pays ; une cellule non validée ou explicitement marquée indisponible ne peut jamais être utilisée par défaut — toute opération qui la rencontrerait est bloquée et remontée explicitement à un humain, plutôt que de recevoir une valeur par défaut qui produirait une sûreté silencieusement nulle.

Garde-fous

• Verser une proposition et la valider sont deux actes de nature différente, volontairement tenus par des habilitations distinctes : lier les deux avait pour effet pervers de laisser l'espace de revue vide, faute d'approbateur disponible pour l'alimenter.
• Un jeu de règles fictif, utilisé pour les démonstrations, est verrouillé pour ne jamais pouvoir se charger en production — la règle est posée à la fois dans le code et dans une colonne dédiée en base, pour qu'une base restaurée depuis un environnement de démonstration ne puisse pas déverrouiller ce jeu fictif en production par la seule vertu de ses données.
• Une valeur par défaut erronée serait pire qu'un blocage : un blocage coûte un appel téléphonique, une sûreté nulle coûte le principal du financement.