Une matrice de permissions relie les rôles aux actions et aux données afin de rendre les accès testables et compréhensibles par l’équipe.
Un logiciel peut proposer des rôles comme commercial, responsable, comptable et administrateur. Le nom du rôle ne suffit pas à dire ce que chacun peut faire. Une matrice précise les actions autorisées, les ressources concernées et les exceptions nécessaires au travail.
Commencez par les opérations du parcours. Lire un devis, le modifier, le soumettre, le valider, l’exporter et le supprimer sont des permissions différentes. Les réunir dans « accès aux devis » rend les erreurs difficiles à voir et conduit souvent à donner plus de droits que prévu.
Décrire les ressources et les actions
Listez les ressources importantes : clients, devis, commandes, factures, fichiers et utilisateurs. Pour chacune, écrivez les actions de lecture, création, modification, validation, partage, export et suppression qui ont un effet réel.
Ajoutez la portée de la donnée. Un commercial peut voir ses propres dossiers, ceux de son équipe ou ceux de toute l’entreprise. Cette portée ne doit pas être déduite d’un écran ; elle doit être contrôlée sur le serveur avec le contexte de l’utilisateur et de l’entreprise.
Les relations peuvent modifier l’accès. Une personne peut lire un devis auquel elle est assignée, mais pas les notes internes d’un autre service. Une facture liée à une commande peut rester visible après la fermeture du dossier. Documentez ces règles au lieu de les laisser dans plusieurs conditions dispersées.
Construire la matrice avec le métier
Utilisez un tableau simple où chaque ligne décrit une action et chaque colonne un rôle. Indiquez autorisé, refusé ou soumis à une condition. La condition doit être écrite en termes observables, comme « responsable du dossier » ou « montant inférieur au seuil ».
Une matrice utile contient des exemples. Pour un devis, précisez ce que voit un commercial, ce que peut valider un responsable et ce qui arrive quand le montant dépasse le seuil. Les exemples servent ensuite aux critères d’acceptation.
Les utilisateurs peuvent avoir plusieurs rôles. Décidez si les droits se cumulent, si une interdiction prend le dessus ou si une règle spécifique s’applique. Un rôle temporaire doit avoir une date d’expiration et un propriétaire. Évitez les exceptions personnelles sans raison et sans révision.
Séparer l’affichage de l’autorisation
Masquer un bouton améliore l’interface, mais ne protège pas une route ou une API. Le serveur doit vérifier l’action à chaque requête. Une personne peut appeler une adresse directement ou utiliser un client différent de l’interface habituelle.
Les listes doivent appliquer la portée, puis les détails doivent la revérifier. Une recherche par identifiant ne doit pas contourner le filtre. Les règles d’isolation entre entreprises doivent s’appliquer aux ressources actives, archivées et supprimées.
Les exports et les fichiers demandent une permission distincte. Le droit de voir une colonne ne donne pas automatiquement le droit de télécharger une liste complète. Un lien vers un fichier doit contrôler le rôle et l’entreprise au moment de son ouverture.
Gérer les actions sensibles
Une suppression, une validation financière ou une modification de rôle peut exiger une confirmation et une trace. Le système peut demander une justification ou une double approbation selon le risque. La règle doit indiquer qui peut annuler ou corriger l’action.
Les droits d’administration sont rarement homogènes. Séparez la gestion des utilisateurs, la configuration, la consultation des audits et l’accès aux données. Une personne qui peut gérer un compte technique ne doit pas forcément lire tous les dossiers clients.
Un accès de support peut être limité dans le temps et associé à un ticket. Journalisez l’activation, les ressources consultées et la fin de l’accès selon la politique de l’entreprise. Le journal d’audit doit rester protégé contre les modifications ordinaires.
Tester les refus et les changements
Les tests doivent vérifier les accès autorisés et les refus. Utilisez des comptes avec des rôles proches et deux entreprises fictives. Essayez une URL directe, un export, une tâche en arrière-plan et une ressource dont l’identifiant appartient à une autre entreprise.
Testez un changement de rôle pendant une session et après une reconnexion. Les caches de permissions peuvent conserver un droit retiré. Une action déjà ouverte doit revérifier l’autorisation au moment de l’enregistrement.
Les erreurs doivent révéler peu d’informations. Un utilisateur sans accès peut recevoir une réponse uniforme pour une ressource inexistante ou située dans un autre espace, selon la politique retenue. Les logs techniques doivent permettre l’enquête sans exposer les données dans l’interface.
Réviser les permissions dans le temps
Les rôles changent avec l’organisation. Planifiez une revue des comptes, des rôles temporaires, des exceptions et des accès inutilisés. Un rapport doit montrer les droits effectifs, pas seulement les rôles attribués, car plusieurs rôles peuvent se cumuler.
Retirez les permissions qui ne servent plus et documentez les décisions qui restent. Une migration de fonction peut créer un nouveau rôle ou rendre une ancienne permission trop large. Les feature flags peuvent contrôler une disponibilité temporaire, mais ils ne remplacent pas la matrice d’accès.
Une matrice bien tenue permet au métier de relire les règles et à l’équipe technique de les tester. Elle réduit les exceptions cachées et donne une base claire pour les nouveaux parcours et les audits.
Sources : OWASP, modèle de contrôle d’accès, NIST, contrôle d’accès.