Rôles et permissions : concevoir les accès dès le départ

Séparer connexion et autorisation

Savoir qui se connecte ne dit pas ce que cette personne peut faire. Un membre peut consulter son dossier sans pouvoir modifier celui d’un collègue. Un responsable peut valider certaines demandes sans accéder à la configuration de l’entreprise. Écrivez ces différences dans une matrice simple qui croise les rôles, les ressources et les actions.

Vérifier la portée des données

La permission « modifier un projet » doit préciser lesquels : les projets attribués à l’utilisateur, ceux de son équipe ou tous ceux de l’organisation. Un contrôle limité au rôle laisse des angles morts. Testez notamment le cas où une personne remplace l’identifiant d’une ressource dans une requête. Le serveur doit refuser l’opération même si l’interface ne propose jamais ce chemin.

Prévoir le cycle de vie des accès

Une invitation, un changement d’équipe et un départ sont des événements ordinaires. Définissez qui attribue les droits, comment on les retire et comment on conserve l’historique utile. Donnez les privilèges nécessaires à la mission, puis élargissez-les lorsqu’un besoin explicite le justifie. Évitez les comptes partagés qui rendent les actions difficiles à attribuer.

Rendre les refus compréhensibles

L’interface doit expliquer qu’une opération n’est pas disponible sans révéler une donnée privée. Un message peut proposer de contacter un administrateur. Côté tests, vérifiez les refus attendus avec autant de soin que les parcours autorisés : c’est là que se joue la réalité du contrôle d’accès.