Contrôle d'accès pour cabinets : qui doit voir quoi, imposé où

Les petits cabinets fonctionnent d'ordinaire sur une visibilité interne totale, pour des raisons compréhensibles : l'équipe est petite, chacun est de confiance, et restreindre l'accès crée une friction qui ralentit le travail.

L'exposition croît en silence avec le cabinet. Un prestataire, un employé qui part, un junior embauché le mois dernier, un mot de passe compromis — chacun hérite de toute la salle des dossiers. La confiance n'est pas le problème ; le problème est que la confiance n'est pas un contrôle, et le cabinet n'a d'autre réponse à « qui aurait pu voir cela » que « tout le monde ».

L'implémentation la plus fréquente des rôles est que l'interface montre moins d'options. C'est une fonctionnalité d'ergonomie et rien de plus.

La question qui sépare les vrais contrôles des cosmétiques est où la règle est imposée. Si l'application vérifie un rôle avant de rendre une page, alors tout ce qui atteint les données autrement — un appel API direct, un état exporté, une intégration, un bug — la contourne. Si la base filtre chaque ligne par cabinet et par rôle, la règle tient quel que soit le chemin, car il n'y a qu'un endroit où l'évaluer.

Pour un cabinet détenant du secret professionnel, cette distinction est toute l'affaire.

Le contrôle d'accès en logiciel juridique a deux tâches distinctes, et les systèmes qui les confondent en ratent une.

La frontière de locataire sépare votre cabinet de tout autre cabinet sur la plateforme. Elle doit être absolue, imposée sous l'application, et jamais dépendante d'une requête correctement écrite. La frontière interne sépare rôles et dossiers au sein de votre cabinet. Elle est plus nuancée, plus souvent ajustée, et légitimement surmontable par la bonne personne pour la bonne raison — avec cette dérogation enregistrée.

Un système au modèle de permissions interne fort et à la frontière de locataire faible a résolu le problème le plus facile.

Le moindre privilège est juste en principe et souvent implémenté si strictement que les gens le contournent, ce qui laisse le cabinet plus mal loti qu'un système permissif réellement utilisé.

Une version viable : accès par défaut aux dossiers auxquels on est affecté ; large visibilité pour ceux qui en ont vraiment besoin, tel un associé gérant ; données financières au niveau de l'argent et du client restreintes par rôle ; et une voie documentée pour en accorder plus quand le travail l'exige. La mesure d'un bon schéma est que personne n'a besoin de partager un identifiant.

L'accès externe n'est pas une version affaiblie de l'accès interne ; c'est un autre modèle. Un client devrait voir précisément ce que le cabinet a choisi de partager et rien d'adjacent — ni le dossier autour du document, ni les autres affaires dont il est partie, ni des métadonnées que le cabinet n'entendait pas divulguer.

La construction sûre est des octrois explicites, par élément. Tout ce qui est hérité par proximité finira par divulguer quelque chose que personne n'a décidé de divulguer.

L'accès est d'ordinaire accordé avec soin et retiré sans soin. Les départs sont là où les cabinets sont le plus exposés, car la révocation dépend de la mémoire de quelqu'un, et les comptes du personnel parti sont la voie la plus fréquente vers les données d'un petit cabinet.

Deux disciplines couvrent l'essentiel : révoquer le dernier jour plutôt que quand on y pense, et garder une trace de ce à quoi cette personne pouvait accéder, ce qui est aussi ce que toute enquête ultérieure demandera en premier.

Les deux frontières sont imposées dans la base. Chaque table cadrée au cabinet et chaque objet de stockage est filtré par la sécurité au niveau des lignes, indexée sur le cabinet et le rôle de l'appelant — si bien qu'une requête sur le dossier, le document ou la facture d'un autre cabinet ne renvoie rien quelle que soit sa construction. Il n'y a pas de chemin de code qui l'élargit, parce que la vérification n'est pas dans le code.

En interne, le tableau de bord et les données d'un collaborateur sont cadrés à ses propres dossiers, tâches et clients ; les données financières au niveau du client et l'argent du cabinet sont gouvernés par rôle ; et les dossiers ouverts par des collaborateurs peuvent devoir passer la revue d'un associé avant de devenir actifs. Les invitations portent le rôle, et les limites de postes sont imposées au point d'invitation.

L'accès client est explicite et par élément — un utilisateur client nommé se voit accorder un dossier, une affaire ou un document précis, jamais un partage qui fuit par proximité — et les clients ne comptent jamais comme postes facturés. Octrois, révocations et événements d'accès sont écrits au registre d'audit en ajout seul, qu'aucun rôle ne peut amender, si bien que « qui pouvait voir cela, et quand » se répond depuis le registre et non de mémoire.