Dans une application B2B, décider qui peut consulter, modifier ou approuver une ressource a des conséquences sur le produit, les opérations et les risques. Un modèle trop simple peut accorder des accès excessifs ; un modèle trop détaillé peut être difficile à administrer et à expliquer. Choisir entre des rôles et des autorisations contextuelles ne revient pas à sélectionner une étiquette technique : il s’agit de représenter les règles réelles de l’entreprise de façon compréhensible, vérifiable et durable.
La bonne option dépend de la variation des accès selon les utilisateurs, les ressources et les situations, ainsi que des personnes qui devront gérer ces différences. Il est préférable de partir des cas réels, et non d’une liste de contrôles. On peut ensuite adopter le modèle le plus simple qui les couvre et définir des signaux concrets pour le faire évoluer.
L’authentification et l’autorisation répondent à des questions différentes
L’authentification vérifie l’identité de l’utilisateur, par exemple au moyen d’une session ou d’un fournisseur d’identité. L’autorisation détermine ce que cette identité peut faire sur une ressource donnée. Le fait d’être connecté n’implique pas que l’on puisse consulter toutes les factures, tous les projets ou toutes les données d’une entreprise.
Pour concevoir l’autorisation, décrivez chaque décision à l’aide de quatre éléments : l’acteur, l’action, la ressource et les conditions applicables. Par exemple : « une personne disposant d’une autorisation de facturation peut télécharger les factures de son organisation ». Cette phrase oblige à préciser si l’autorisation concerne toutes les organisations, une organisation sélectionnée ou uniquement certains documents.
Il est également utile de définir dès le départ le périmètre des données. Dans un produit utilisé par plusieurs entreprises clientes, vérifier correctement le rôle ne suffit pas si la requête renvoie des ressources appartenant à un autre client. L’autorisation doit porter à la fois sur l’action, l’accès à la ressource et son appartenance au périmètre concerné.
Autorisations fondées sur les rôles : la clarté quand les schémas se répètent
Dans le contrôle d’accès fondé sur les rôles, ou RBAC, les autorisations sont regroupées en rôles, puis attribuées aux utilisateurs. Un rôle tel qu’« administrateur de l’organisation » pourrait permettre de gérer les membres et les paramètres ; un autre, comme « analyste », pourrait donner un accès en lecture aux rapports. L’application vérifie si le rôle de l’utilisateur comprend l’autorisation nécessaire à l’action.
Cette approche convient lorsque les fonctions ou responsabilités proposées par le produit se répètent et que les différences entre utilisateurs restent relativement stables. Elle facilite l’explication des accès dans l’interface, la création de profils courants et la vérification des attributions. Elle fournit aussi un vocabulaire commun aux équipes produit, assistance et technique : il est plus facile de discuter du rôle d’« éditeur » que de maintenir une liste opaque d’autorisations individuelles.
Les rôles ne devraient toutefois pas être assimilés automatiquement à des intitulés de poste. Une même personne peut avoir des responsabilités différentes dans chaque organisation, et un rôle global peut accorder trop de droits. Il est courant de limiter le rôle à un périmètre : par exemple, « administrateur » au sein d’une organisation, et non sur toute la plateforme. Définissez précisément qui attribue les rôles, quelles ressources ils couvrent et si une personne peut en cumuler plusieurs.
Choisissez des rôles lorsque les autorisations forment des ensembles reconnaissables, évoluent peu et peuvent être gérées sans créer un nouveau rôle pour chaque exception. Si les combinaisons se multiplient — « éditeur avec accès à seulement deux projets, sauf lors d’une approbation » — le rôle essaie peut-être de représenter trop de dimensions.
Règles contextuelles : des accès déterminés par l’utilisateur, la ressource ou la situation
Une règle contextuelle tient compte d’attributs qui s’ajoutent à l’identité ou au rôle. L’accès peut dépendre de la personne qui demande l’action, de la ressource qu’elle souhaite utiliser et des conditions du moment. Par exemple, la modification d’un projet pourrait être autorisée uniquement si la personne appartient à l’équipe qui lui est affectée et si le projet est à l’état de brouillon. Cette approche est souvent associée au contrôle d’accès fondé sur les attributs, ou ABAC.
Les règles contextuelles sont utiles lorsque les mêmes utilisateurs disposent de droits différents selon les ressources, ou lorsque l’état de l’activité modifie ce qui est autorisé. Elles peuvent représenter l’appartenance à une équipe, la propriété d’un enregistrement, la classification des données ou une étape d’approbation. On évite ainsi de créer un rôle différent pour chaque combinaison d’utilisateur et de ressource.
Cette flexibilité a un coût : les décisions deviennent moins visibles si elles reposent sur des attributs dispersés ou des conditions difficiles à expliquer. Une règle peut échouer parce que l’état de la ressource n’est pas à jour, qu’une donnée manque ou que le comportement à adopter face à une valeur inconnue n’a pas été défini. Pour chaque condition, identifiez sa source, la personne qui en est responsable, sa fréquence de mise à jour et le traitement des erreurs. Si une donnée nécessaire à l’octroi de l’accès est absente, la politique doit refuser l’action par sécurité.
Les « autorisations contextuelles » n’impliquent pas forcément la mise en place d’un moteur complexe. Dans une petite application, il peut s’agir d’une vérification explicite de l’appartenance à une équipe et de l’état de la ressource. L’essentiel est que la règle soit cohérente, centralisable et vérifiable, et non qu’elle repose sur une architecture particulière.
Comparer les approches à partir de cas réels
Préparez une petite matrice réunissant des utilisateurs représentatifs, des actions et des ressources. Incluez des cas ordinaires et des exceptions : une personne membre de deux organisations, une ressource partagée, une personne qui change d’équipe et une action d’approbation. Pour chaque ligne, notez le résultat attendu et sa justification. Comparez ensuite le coût d’expression et de gestion des règles selon chaque approche.
- Variabilité : les autorisations dépendent-elles surtout de responsabilités stables, ou varient-elles selon la ressource et son état ?
- Administration : un administrateur côté client peut-il comprendre et gérer les attributions sans aide technique constante ?
- Exceptions : sont-elles rares et maîtrisables, ou reviennent-elles au point de former un second système informel de rôles ?
- Audit : pouvez-vous expliquer pourquoi une opération a été autorisée ou refusée et retrouver la règle appliquée ?
- Conséquences des erreurs : quelles données seraient exposées ou quelle opération serait bloquée si une condition était mal configurée ?
Ne comparez pas uniquement le nombre de rôles ou de règles. Un modèle comprenant peu d’éléments peut être difficile à comprendre si leurs effets se combinent de manière implicite. Évaluez aussi l’expérience des personnes qui configurent les accès et la facilité avec laquelle vous pouvez répondre à une question adressée à l’assistance : « pourquoi cette personne ne peut-elle pas ouvrir ce document ? »
Signes d’un excès de rôles ou d’une complexité prématurée
Les rôles sont probablement trop nombreux lorsque des intitulés presque identiques correspondent à de petites variations, que chaque client demande un rôle exclusif ou que les conditions liées aux ressources sont codées sous forme d’exceptions dans les rôles. Le fait que personne ne puisse expliquer la différence entre deux profils sans consulter le code est également un signal d’alerte.
À l’inverse, les règles contextuelles peuvent être prématurées si presque tous les utilisateurs partagent les mêmes autorisations, si aucun besoin d’accès par ressource n’existe et si l’équipe ne dispose pas de données fiables pour évaluer les attributs. Dans ce cas, construire un système général de politiques ajoute des points de défaillance et des coûts de maintenance sans résoudre de problème réel.
Considérez ces signaux comme des raisons de réexaminer le modèle, et non comme un ordre automatique de migration. Regrouper les rôles, clarifier les périmètres ou corriger les attributions peut suffire. Si les exceptions expriment des différences légitimes et récurrentes, il devient alors pertinent de concevoir des règles plus explicites.
Faire évoluer le modèle sans rompre les autorisations existantes
Une évolution progressive limite les mauvaises surprises. Commencez par recenser les autorisations actuelles et décrivez les cas attendus à l’aide d’exemples. Séparez les politiques d’autorisation de la présentation de l’interface : masquer un bouton améliore l’expérience, mais ne remplace pas la vérification côté serveur à chaque exécution de l’action.
- Centralisez la décision : définissez comment vérifier si un acteur peut effectuer une action sur une ressource, afin d’éviter les contrôles contradictoires répartis dans l’application.
- Rédigez des tests d’accès : couvrez les cas autorisés et refusés, les limites entre organisations, les changements d’état et les attributs manquants. Vérifiez aussi les opérations de lecture et d’écriture.
- Comparez avant de remplacer : pendant la transition, évaluez le nouveau modèle en parallèle de l’ancien et consignez les écarts sans accorder d’accès supplémentaire sur la base de cette comparaison.
- Migrez par cas bien délimités : transférez une action ou un type de ressource, vérifiez les résultats avec les responsables métier et prévoyez un moyen contrôlé de revenir en arrière.
- Consignez les décisions importantes : conservez les informations utiles pour examiner les refus ou les accès sensibles, sans inclure inutilement des données personnelles dans les journaux.
Avant le déploiement, posez-vous les questions suivantes : qui peut accorder un accès, et dans quel périmètre ? Que se passe-t-il lorsqu’une personne quitte une équipe ? Comment le système réagit-il si un attribut manque ? Une organisation peut-elle accéder aux ressources d’une autre ? Chaque exception peut-elle être expliquée et testée ? Si les réponses ne sont pas claires, l’étape suivante consiste à préciser les règles, et non à ajouter des rôles ou des conditions.
En pratique, commencez par des rôles lorsque les responsabilités sont stables et faciles à comprendre. Ajoutez des règles contextuelles lorsqu’un besoin récurrent dépend de ressources ou de circonstances que les rôles représentent mal. Dans les deux cas, privilégiez des périmètres explicites, un refus par défaut en cas d’incertitude, des tests et une administration compréhensible. Le meilleur modèle est le plus simple qui reflète les décisions réelles de l’entreprise et peut être réexaminé lorsqu’elles évoluent.