Qui peut voir quoi
Une permission que l'on peut contourner d'un clic n'est pas une permission
La plupart des contrôles d'accès dans les logiciels juridiques ne sont que décoration. L'écran dissimule un bouton. Le menu omet une option. Le collaborateur ne voit pas le dossier restreint, parce que l'interface a choisi de ne pas l'afficher. Il s'agit là de courtoisie, non de sécurité. L'enregistrement demeure dans la base de données, à une seule requête habilement construite de quiconque dont la session atteint le serveur.
La distinction importe, car les interfaces constituent la couche la plus vulnérable de tout système. On les réécrit, on les contourne, on les inspecte. Une règle appliquée au seul niveau de l'écran est une règle qui dépend de chaque ingénieur futur, de chaque voie d'exportation et de chaque requête directe, tous supposés respecter un accord qu'ils n'ont peut-être jamais lu. Ce n'est pas un contrôle. C'est un espoir.
La question n'est pas ce qu'un rôle se voit présenter. La question est ce qu'un rôle peut atteindre.
Quatre rôles, une limite que le moteur maintient
Un cabinet repose sur des mains distinctes. L'associé porte la relation client et la responsabilité. Le collaborateur rédige et fait avancer le dossier. L'assistant juridique assemble et dépose. La facturation prépare les sommes et rend des comptes à l'auditeur. Chacun requiert une portée différente, et la portée de l'un constitue l'exposition de l'autre.
Dans Mersal, la Row-Level Security, au niveau du moteur de base de données, filtre chaque requête par cabinet et par rôle, de sorte qu'un dossier restreint demeure invisible à quiconque se trouve hors de son cercle, sans aucune voie de contournement du côté de l'application. La limite ne réside pas dans la page. Elle réside une couche au-dessous de chaque page, de chaque exportation et de chaque rapport, à l'endroit où les données reposent véritablement.
Que l'on en mesure la conséquence. Un assistant juridique qui constitue un index de dépôt ne peut énumérer le mandat scellé d'un associé. Un employé à la facturation qui exporte le mois ne peut faire apparaître un dossier cloisonné pour des raisons de conflit. Le mur n'est pas tracé par le menu. Il est tracé par le moteur qui répond au menu.
La gouvernance devient physique
Le même principe s'étend, au-delà de qui peut lire, à qui peut agir. Les collaborateurs ne peuvent activer seuls des dossiers ; la barrière d'approbation est appliquée par la base de données, non par un bouton désactivé qu'une main empressée pourrait réactiver. Le registre d'audit rejette toute modification au moyen de déclencheurs qui s'exécutent avant chaque mise à jour et chaque suppression, pour tout rôle, y compris les administrateurs. Nul ne modifie l'enregistrement de ce qui s'est produit, car l'enregistrement refuse la modification au niveau même où les modifications s'opèrent.
Une règle inscrite dans un manuel est une préférence. Une règle inscrite dans le moteur est une contrainte. La différence tient à ce que la règle survive ou non à la personne qui veut l'enfreindre.
Les promesses de confidentialité d'un cabinet ne valent que par l'endroit le plus faible où elles peuvent être défaites. Déplacez la limite de l'interface vers le moteur, et la promesse cesse de dépendre de la discipline, de la mémoire ou de l'honnêteté de la prochaine requête. Le dossier scellé de l'associé n'est pas caché au collaborateur ; il est inaccessible. La piste d'audit n'est pas dissuadée de l'altération ; elle la refuse. Une gouvernance que l'on peut contourner d'un clic est un conseil. Une gouvernance que la base de données maintient est une loi.
Dossiers, conflits, facturation TVA, reçus scellés et calendrier, dans un seul système défendable.