Matrice de permissions SaaS : partir des actions sensibles

Écrire les limites du compte

Pour un logiciel fictif de suivi de dépenses, « responsable » ne précise pas si la personne peut consulter tous les services, modifier une dépense validée ou exporter les justificatifs. Définissez l’organisation, l’équipe et la propriété des objets. Les contrôles doivent s’appliquer côté serveur, pas uniquement aux boutons visibles.

Une première matrice

Cette grille est un exemple à adapter, pas un modèle universel. La séparation entre demande et validation peut être indispensable selon le métier.

Tester les interdictions

Préparez deux organisations et plusieurs rôles. Tentez une lecture, une modification et un export avec l’identifiant d’un objet voisin. Vérifiez aussi les pièces jointes, tâches différées et recherches. Après le retrait d’un rôle, l’ancienne session ne doit pas conserver indéfiniment son pouvoir.

Peut-on commencer avec deux rôles ?

Oui si les limites sont explicites. Deux rôles correctement contrôlés valent mieux que six intitulés dont les droits se recouvrent sans règle. Ajoutez une permission lorsqu’une tâche réelle l’exige et documentez son propriétaire, son périmètre et son test de refus.

Les exemples sont pédagogiques et ne décrivent pas des résultats clients. Contenu préparé avec assistance IA ; voir notre politique éditoriale. Notre méthode ↗