Dès que plusieurs personnes se connectent à un logiciel métier, la question des droits devient concrète. Un outil trop ouvert expose des données qui n'ont pas à être vues par tout le monde. Un outil trop fermé pousse les équipes à partager un mot de passe ou à contourner l'application avec un tableur. Le point de départ utile est le travail réel : qui fait quoi, sur quelles données, pour quelle partie de l'organisation.
Contrôler les droits, pas seulement l'affichage
Dans une évolution récente d'un outil interne, les règles ont été appliquées côté serveur selon les profils autorisés. Masquer un bouton ne suffit pas : c'est le serveur qui doit refuser ce qui n'est pas permis, même si l'écran ne le propose plus.
Les vues et les données accessibles ont ensuite été contrôlées avec différents comptes et dans différents contextes. Certaines fonctions ont volontairement été différées plutôt qu'ouvertes sans validation. La conséquence pratique est simple : testez chaque profil réellement, et acceptez de reporter une fonction tant que sa règle d'accès n'est pas claire.
Partir des tâches plutôt que des intitulés de poste
Deux personnes qui portent le même titre n'effectuent pas toujours les mêmes tâches, et un intitulé ne dit rien des données manipulées. Mieux vaut lister les actions quotidiennes, puis noter pour chacune quatre éléments :
- l'action réalisée : lecture, création, modification, export, suppression ou validation ;
- les données concernées : fiches clients, devis, prix d'achat, documents ;
- le périmètre : un atelier, une boutique, un service ou toute l'organisation ;
- le moment : avant ou après validation, dossier ouvert ou clôturé.
Les tâches voisines se regroupent ensuite en profils. Quelques rôles nommés d'après ce qu'ils permettent de faire restent plus faciles à expliquer, à tester et à maintenir qu'une multitude de cas particuliers. Cette cartographie est aussi le point de départ d'une application web sur mesure : elle évite de découvrir les règles au fil des demandes, en fin de projet.
La CNIL décrit des principes pour les habilitations : des profils qui correspondent aux tâches, des accès limités au besoin, le retrait des droits lors d'un départ ou d'un changement de poste, et une revue régulière. Les appliquer ne rend pas pour autant un outil conforme au RGPD, mais cela donne une base de travail claire.
Un exemple fictif : un atelier, une boutique et un responsable
Prenons un atelier imaginaire de réparation de vélos, rattaché à une boutique. Ce cas est inventé et ne décrit aucun projet réel : il sert seulement à illustrer la méthode. Trois profils ressortent : technicien, vendeur et responsable.
| Action | Technicien | Vendeur | Responsable |
|---|---|---|---|
| Voir les interventions | Celles de l'atelier | Lecture seule | Toutes |
| Changer l'état d'une intervention | Oui | Non | Oui |
| Voir les prix d'achat | Non | Non | Oui |
| Exporter la liste des clients | Non | Non | Oui |
| Supprimer une fiche | Non | Non | Oui, avec trace |
| Voir les ventes de la boutique | Non | Oui | Oui |
Ce tableau fait surgir des questions à trancher : un vendeur peut-il corriger l'adresse d'un client ? Le technicien voit-il le téléphone ou seulement le prénom ? Chaque réponse devient une règle écrite, relue par la personne qui connaît le métier, avant d'être programmée.
Faire respecter les règles côté serveur
L'OWASP distingue l'authentification et l'autorisation : l'une établit qui se connecte, l'autre décide de ce que cette personne peut faire. Le contrôle s'effectue côté serveur, pour chaque opération, avec un refus par défaut quand aucune règle n'autorise l'action. Masquer un bouton ne protège pas une donnée.
Concrètement, un menu absent ne suffit pas. Une personne qui connaît l'adresse d'une page, d'un export ou d'un appel d'API doit recevoir un refus, même sans passer par l'interface. Chaque requête vérifie donc deux choses : le droit d'effectuer l'action et le droit d'accéder à cette donnée précise, par exemple la fiche d'une autre boutique.
Un compte par personne permet de savoir qui a modifié quoi et de retirer un accès sans gêner les autres. Les messages de refus restent sobres : ils indiquent que l'action n'est pas permise, sans détailler ce qui existe derrière.
Valider, révoquer et revoir les droits dans la durée
Les équipes changent plus vite que le logiciel. Trois situations demandent une procédure écrite :
- une arrivée : qui demande le profil, qui l'accorde, sur quel périmètre ;
- un changement de poste : les anciens droits sont retirés, pas seulement complétés ;
- un départ : le compte est désactivé, avec un traitement de l'historique conforme aux règles de conservation prévues.
Une revue régulière consiste à parcourir la liste des comptes et à faire confirmer les profils par le responsable de chaque équipe. Un journal des changements de droits aide à retrouver qui a accordé quoi, et quand.
Vérifier chaque parcours par des essais de réussite et de refus
Un profil n'est pas terminé tant qu'il n'a pas été essayé avec un compte de test. Pour chaque rôle, la recette comprend des cas qui doivent réussir et des cas qui doivent être refusés :
- réaliser les actions normales du rôle, de la connexion à la déconnexion ;
- tenter une action réservée à un autre rôle, par l'interface puis par l'adresse directe ;
- ouvrir la fiche d'une autre boutique ou d'un autre atelier ;
- lancer un export et vérifier les colonnes réellement fournies ;
- changer un utilisateur de rôle, puis désactiver son compte, et reprendre les essais.
Chaque écart est noté avec le rôle, l'action et le résultat attendu. La grille se rejoue après chaque évolution du logiciel, car une nouvelle fonction ajoute souvent un accès à contrôler.
Questions fréquentes
Combien de rôles prévoir au départ ?
Commencez par des profils correspondant à des tâches distinctes. Le nombre dépend de la séparation réelle des responsabilités, des données et des périmètres, sans seuil standard à appliquer à toutes les structures.
Un compte commun pour l'atelier est-il acceptable ?
Mieux vaut l'éviter. Un compte partagé rend l'attribution des modifications moins fiable et complique le retrait d'un accès lors d'un départ. Des comptes individuels facilitent ces opérations.
Si vous souhaitez cadrer les rôles et les accès d'un outil existant ou à créer, vous pouvez décrire votre besoin sur la page développement d'applications web. Je regarderai les tâches, les données et les profils concernés avant d'envisager la suite.
Parlons de votre projet
À Annecy, en Haute-Savoie ou à distance, je vous accompagne pour cadrer un besoin concret et choisir une solution adaptée à votre activité.
Découvrir l’accompagnement · Me contacterSources et documentation
Documentation consultée le 20 octobre 2026.
Dernière mise à jour : 20 octobre 2026.
← Tous les articles