Droits et rôles : trois modèles, et quand chacun casse
La gestion des droits commence par deux rôles et finit par une liste ingérable. Le modèle se choisit au début, quand le changer coûte encore peu.
Au démarrage, deux rôles suffisent : administrateur et utilisateur. Dix-huit mois plus tard, la liste compte vingt-trois rôles dont sept sont nommés d’après une personne partie depuis.
Le modèle initial n’était pas mauvais. Il n’a simplement jamais été revu.
Modèle 1 — par rôle
Chaque personne reçoit un rôle, chaque rôle porte une liste de permissions. C’est simple, lisible, et suffisant pour beaucoup de cas.
Où il casse : dès qu’une exception apparaît. « Comme gestionnaire, mais sans accès aux tarifs » crée un rôle supplémentaire. Chaque exception en crée un, et le nombre de rôles suit le nombre de situations particulières, pas le nombre de métiers.
Signal d’alerte : plus de rôles que de types de postes réels.
Modèle 2 — par attribut
L’autorisation se calcule à partir de propriétés : l’agence de rattachement, le montant, le statut du dossier. « Un gestionnaire peut modifier un dossier de son agence tant qu’il n’est pas clôturé. »
Où il casse : la règle devient difficile à expliquer et à déboguer. Quand quelqu’un demande pourquoi il ne voit pas un dossier, il faut dérouler le calcul. Sans écran de diagnostic montrant la règle appliquée, le support devient une enquête.
Modèle 3 — par appartenance
Les droits découlent du rattachement à une structure : une équipe, un service, un projet. Rejoindre l’équipe donne l’accès, la quitter le retire.
Où il casse : sur les transversalités. Un auditeur doit voir toutes les équipes sans appartenir à aucune. Une direction doit voir en lecture seule. Ces cas obligent à greffer un autre modèle par-dessus.
Le choix pratique
La combinaison la plus tenable est l’appartenance pour le périmètre — quelles données —, et le rôle pour l’action — quoi en faire. Les deux axes restent lisibles séparément, et leur croisement couvre la plupart des besoins sans explosion combinatoire.
Deux règles qui évitent le pire
Le refus par défaut. Ce qui n’est pas explicitement autorisé est refusé. L’inverse produit des fuites à chaque nouvelle fonctionnalité, faute d’avoir pensé à la protéger.
La vérification côté serveur. Masquer un bouton dans l’interface n’est pas une protection : la requête reste appelable directement. Le contrôle vit là où la donnée vit.
Une revue annuelle
La liste des personnes et de leurs droits, relue une fois par an par les responsables concernés. L’exercice prend une demi-journée et supprime systématiquement des accès de gens partis, ou promus sans que les anciens droits soient retirés.