Définir les responsabilités avant les rôles
Commencez par les activités d’une organisation cliente : consulter des rapports, inviter des collègues, modifier des intégrations, préparer des demandes et approuver des changements sensibles. Pour chacune, précisez sa raison métier et les données concernées. Regroupez ensuite les responsabilités compatibles en rôles qu’un administrateur peut expliquer sans schéma. Évitez un rôle de gestionnaire tout-puissant simplement pratique pendant le développement. Un spécialiste du reporting peut avoir besoin de tout l’historique sans pouvoir modifier les paramètres. Écrivez, pour chaque rôle, un exemple d’action autorisée et un autre d’action refusée. Ils serviront de critères de réception.
Rendre les limites de l’organisation explicites
Une personne peut appartenir à plusieurs organisations ; son identifiant de compte ne suffit donc pas à décider d’un accès. Chaque requête concernée doit établir l’organisation active et vérifier l’appartenance par rapport à la ressource demandée. Appliquez cette limite aux exports, recherches, tâches de fond et liens de pièces jointes. Un changement d’espace ne doit pas laisser les données de la société précédente affichées. Testez deux organisations avec des projets aux noms proches et des membres communs. Incluez une personne dont l’accès est retiré pendant la préparation d’un rapport. Décidez si celui-ci doit finir, être abandonné ou nécessiter une nouvelle autorisation de téléchargement.
Organiser les invitations et les départs
Une invitation doit préciser destinataire, rôle proposé, expiration et statut. Expliquez ce qui se passe si la personne possède déjà un compte ou accepte avec le mauvais compte. Un ancien lien ne doit pas suffire à obtenir des privilèges. Un départ exige davantage que masquer un utilisateur : examinez sessions actives, clés API personnelles, exports planifiés et propriété des ressources partagées. Distinguez retrait d’accès et suppression des travaux antérieurs. Avant de retirer le dernier propriétaire, exigez un transfert volontaire de propriété ou une autre procédure de récupération définie. Enregistrez l’auteur de chaque changement et le droit qui l’autorise.
Permettre la revue des changements
Montrez les conséquences d’un changement de rôle avant son enregistrement, notamment lorsqu’il ouvre l’accès à des données financières ou aux intégrations. Conservez un historique lisible indiquant auteur, organisation, ancien rôle, nouveau rôle et date. Les traces doivent rester utiles après un changement de nom d’affichage. Testez les droits côté serveur autant que dans l’interface : masquer un bouton ne constitue pas une limite d’autorisation. Enfin, faites avec le support un exercice pour comprendre pourquoi un utilisateur ne peut accomplir une tâche, sans lui donner davantage de privilèges par facilité. Le modèle obtenu doit être compréhensible, vérifiable et exploitable.