Salesforce : profils, rôles, permission sets et sharing rules, guide complet

La gestion des habilitations est l'un des sujets les plus récurrents, et les plus mal maîtrisés, sur les projets Salesforce Sales Cloud. La confusion entre profils, rôles, permission sets et sharing rules génère des problèmes de sécurité, des accès incorrects et des architectures difficiles à maintenir. Voici une vue claire et opérationnelle de chaque concept.

La logique globale : deux dimensions distinctes

Avant tout, il faut comprendre que Salesforce sépare deux types d'accès fondamentalement différents :

• Accès fonctionnel, ce qu'un utilisateur peut faire : créer un compte, modifier une opportunité, exporter des données, accéder à une application. C'est géré par les profils et les permission sets.
• Accès aux données, quels enregistrements un utilisateur peut voir. C'est géré par les rôles, les sharing rules et les paramètres de partage d'objet (OWD).

Mélanger ces deux dimensions est la principale source de confusion. Un profil ne contrôle pas quels enregistrements on voit, il contrôle ce qu'on peut faire avec les enregistrements qu'on voit.

Les 4 couches du modèle de sécurité

Les profils : la base obligatoire

Chaque utilisateur Salesforce doit avoir un profil. C'est la couche de permissions minimale et non négociable. Le profil définit :

• Permissions sur les objets, Read, Create, Edit, Delete, View All, Modify All sur chaque objet standard et custom
• Permissions sur les champs, visibilité et édition de chaque champ (field-level security)
• Permissions système, export de données, gestion des utilisateurs, accès à l'API…
• Accès aux applications, quelles apps Lightning sont visibles
• Page layouts assignés, quelle mise en page s'affiche selon l'objet

Les permission sets : l'extension additive

Les permission sets permettent d'accorder des droits supplémentaires à des utilisateurs spécifiques sans changer leur profil. C'est le mécanisme recommandé par Salesforce pour gérer les cas particuliers.

Exemple concret : tous les commerciaux ont le profil "Commercial". Trois d'entre eux ont besoin d'accéder au module de prévision avancée. Plutôt que de créer un nouveau profil "Commercial + Prévisions", on crée un permission set "Accès Prévisions" qu'on assigne aux trois utilisateurs concernés.

Permission Set Groups

Les Permission Set Groups (disponibles depuis quelques versions) permettent de regrouper plusieurs permission sets en un seul objet assignable. Sur des organisations complexes, c'est le pattern recommandé, on assigne un groupe plutôt que plusieurs permission sets individuels, ce qui simplifie la gestion et les audits.

Les rôles : la hiérarchie de visibilité

Les rôles définissent la position de chaque utilisateur dans l'organigramme Salesforce. La règle fondamentale : un utilisateur voit toujours les enregistrements des utilisateurs qui lui sont subordonnés dans la hiérarchie, selon les paramètres OWD (Organization-Wide Defaults) de chaque objet.

Exemple : un Directeur Commercial voit les opportunités de tous ses commerciaux. Un commercial ne voit que les siennes (si l'OWD est "Private") ou celles de son équipe (si l'OWD est "Public Read Only").

Ce que les rôles ne font pas

• Ils ne contrôlent pas les permissions fonctionnelles, c'est le rôle des profils et permission sets
• Ils ne permettent pas un partage latéral, un commercial du Bureau de Paris ne voit pas les enregistrements d'un commercial du Bureau de Lyon s'ils sont au même niveau dans la hiérarchie
• Ils ne remplacent pas les sharing rules pour les accès transversaux

Les OWD et les sharing rules : la visibilité des données

Les Organization-Wide Defaults (OWD) définissent le niveau de visibilité par défaut pour chaque objet :

• Private, un utilisateur ne voit que ses propres enregistrements (+ ceux de ses subordonnés)
• Public Read Only, tout le monde voit tous les enregistrements, seul le propriétaire peut les modifier
• Public Read/Write, tout le monde voit et peut modifier tous les enregistrements

Les sharing rules permettent ensuite d'ouvrir la visibilité au-delà des OWD dans des cas spécifiques, sans passer par la hiérarchie des rôles. Deux types :

• Sharing rules basées sur le propriétaire, "partager les enregistrements du rôle X avec le groupe Y"
• Sharing rules basées sur des critères, "partager les opportunités dont le montant > 100K€ avec tous les managers"

Tableau de décision

Les erreurs classiques

• Créer un profil par utilisateur, ingérable dès 20 utilisateurs, impossible à auditer
• Confondre rôle et profil, le rôle ne donne pas de droits fonctionnels, seulement de la visibilité sur les données
• Utiliser "Public Read/Write" sur tous les objets, aucun contrôle sur la visibilité, impossible à restreindre ensuite sans remettre à plat l'architecture
• Oublier les field-level security, un utilisateur peut avoir accès à l'objet mais certains champs sensibles (salaire, données confidentielles) doivent être masqués via le profil
• Empiler les permission sets sans gouvernance, sans inventaire et revue régulière, les droits s'accumulent et personne ne sait plus qui a accès à quoi

Conclusion

Le modèle de sécurité Salesforce est puissant mais nécessite une architecture réfléchie dès le départ. Profils pour les droits de base, permission sets pour les exceptions, rôles pour la hiérarchie de visibilité, sharing rules pour les partages transversaux, chaque mécanisme a son rôle précis. Les confondre génère des architectures fragiles qu'on ne peut plus faire évoluer proprement. C'est l'un des premiers points d'audit que j'effectue quand j'arrive sur une instance existante.