Gérer les droits d’accès par rôle dans une application

Dans un outil métier, tout le monde ne doit pas tout voir. Un commercial n’a pas à consulter les salaires, un client ne doit voir que ses propres commandes, un stagiaire ne doit pas pouvoir supprimer une facture. Les droits d’accès par rôle organisent cela. Bien conçus, ils protègent vos données et simplifient l’administration. Mal conçus, ils sont la faille de sécurité la plus répandue dans les applications web. Voici comment je les conçois.

Pourquoi c’est le premier sujet de sécurité

Le Top 10 de l’OWASP, le référentiel de référence des risques de sécurité des applications web, place le « contrôle d’accès défaillant » (A01:2025 Broken Access Control) en première position dans sa version 2025 (consultée le 27 octobre 2026). Concrètement, cela recouvre des situations comme :

• un utilisateur qui change un numéro dans l’adresse de la page et accède à la fiche d’un autre client ;
• un bouton masqué à l’écran, mais dont l’action reste accessible en appelant directement le serveur ;
• une page d’administration protégée seulement par le fait qu’aucun lien n’y mène.

Le RGPD impose par ailleurs de limiter l’accès aux données personnelles aux personnes qui en ont besoin (article 32 du règlement (UE) 2016/679). La CNIL détaille la gestion des habilitations dans son guide de la sécurité des données personnelles.

Concevoir la matrice des rôles

Tout commence par un tableau, rédigé pendant le cadrage avec les responsables métier. En lignes, les rôles ; en colonnes, les actions sur chaque type de donnée. Exemple d’illustration pour un outil commercial :

Trois principes guident ce tableau :

1. Le moindre privilège. Chaque rôle reçoit le minimum nécessaire à son travail. On ajoute un droit quand le besoin est démontré, pas « au cas où ».
2. Rôle et périmètre. « Responsable d’équipe » est un rôle ; « équipe Ouest » est un périmètre. Combiner les deux évite de créer un rôle par agence.
3. La séparation des tâches. Celui qui crée une remise exceptionnelle n’est pas celui qui la valide.

Vérifier les droits au bon endroit

Masquer un bouton ne protège rien. Les droits doivent être contrôlés à trois niveaux :

• l’interface : n’afficher que ce que l’utilisateur peut faire, pour le confort ;
• le serveur : chaque requête vérifie l’identité et le rôle de l’utilisateur avant d’agir, c’est là que se joue la sécurité ;
• la base de données : avec PostgreSQL, les politiques de sécurité au niveau des lignes (Row Level Security) filtrent les données directement dans la base. Une fois activées sur une table sans politique définie, aucune ligne n’est accessible par défaut.

Ce troisième niveau est celui que j’utilise avec Supabase. Il sert de filet de sécurité : même si une erreur se glisse dans le code de l’application, la base refuse de renvoyer les données d’un autre client ou d’une autre équipe.

Les erreurs classiques à contrôler

Ce sont les points que je contrôle en priorité lors de la reprise ou de l’audit d’une application :

• des droits vérifiés uniquement dans le navigateur, fréquents dans les prototypes générés rapidement ;
• des identifiants séquentiels dans les adresses, qui permettent de deviner les fiches voisines ;
• un compte administrateur partagé par plusieurs personnes, sans traçabilité ;
• des comptes jamais désactivés après un départ ;
• des droits accumulés au fil des changements de poste.

D’autres failles fréquentes sont détaillées dans les failles les plus fréquentes dans les applications de PME.

Ce que cela coûte

Dans mon barème, les droits d’accès s’ajoutent au prix de base de l’application sous forme de briques (montants HT) :

Un outil avec plusieurs espaces cloisonnés en est l’illustration : O’GYM réunit une app adhérent, des espaces coach et partenaire et une administration, chacun avec ses propres droits. La connexion avec l’annuaire de l’entreprise est détaillée dans connexion unique (SSO) avec Microsoft 365 ou Google.

Quand une gestion fine des droits n’est pas nécessaire

Je le dis franchement : pour un outil utilisé par cinq personnes qui ont toutes besoin de tout voir, deux rôles suffisent (utilisateur et administrateur). Une matrice détaillée ajoute du coût de conception et d’administration sans bénéfice. La finesse des droits doit suivre la sensibilité des données et le nombre d’équipes, pas l’inverse.

Comment je le mets en place

1. Au cadrage : la matrice des rôles, validée par les responsables métier et la liste des administrateurs.
2. Aux maquettes : chaque rôle teste ses propres écrans.
3. Au développement : contrôle côté serveur et politiques au niveau de la base, tests automatiques qui vérifient qu’un rôle ne peut pas accéder aux données d’un autre.
4. À la mise en ligne : journal des modifications de droits et procédure de revue périodique.

Les droits d’accès font partie de toute application métier que je développe. Pour estimer votre projet, cochez les briques utiles dans l’estimateur.