Trois mécanismes distincts, souvent confondus
La sécurité Salesforce repose sur des couches indépendantes, et la confusion entre elles explique la plupart des orgs où plus personne ne sait qui accède à quoi. Les permission sets, les profils et les rôles ne répondent pas à la même question.
Le profil répond à « qu'ai-je le droit de faire ». Créer une opportunité, modifier un compte, exporter des données, accéder à tel objet. C'est le socle de départ d'un utilisateur.
Les permission sets répondent à « qu'ai-je le droit de faire en plus ». Ils s'ajoutent au profil, se cumulent, et se retirent sans toucher au socle. C'est le mécanisme que Salesforce met en avant, et celui qu'il faut privilégier aujourd'hui.
Le rôle répond à une tout autre question : « quels enregistrements ai-je le droit de voir ». Il positionne l'utilisateur dans une hiérarchie, et cette hiérarchie fait remonter la visibilité vers le haut. Un directeur commercial voit les affaires de son équipe parce que son rôle est au dessus, pas parce que son profil est plus permissif.
Retenez cette distinction, elle suffit à démêler quatre-vingts pour cent des situations : le profil et les permission sets disent ce que vous pouvez faire, le rôle et le partage disent sur quoi vous pouvez le faire.
Pourquoi les profils sont en train de reculer
Historiquement, tout passait par le profil. Un utilisateur avait besoin d'un droit supplémentaire, on dupliquait son profil et on l'ajustait. L'opération s'est répétée pendant des années dans la plupart des orgs.
Le résultat est toujours le même : autant de profils que d'utilisateurs, avec des noms comme « Commercial v2 » ou « Copie de Standard User modifié », et plus personne pour dire ce qui différencie l'un de l'autre. Le jour où il faut prouver qui accède à quoi, l'exercice devient une enquête de plusieurs jours.
Salesforce a tranché en orientant sa plateforme vers les permission sets. La bonne pratique aujourd'hui consiste à garder un profil minimal par grande famille d'utilisateurs, puis à accorder les droits supplémentaires par permission sets nommés par usage : « Export de données », « Gestion du catalogue », « Validation des remises ».
L'avantage est immédiat le jour d'un changement de poste. Vous retirez un permission set au lieu de reconstruire un profil, et vous savez exactement ce que vous venez de retirer.
Le partage des enregistrements, l'autre moitié du sujet
Un utilisateur peut avoir le droit de modifier des opportunités sans voir la moindre opportunité. Ce sont deux réglages différents, et c'est ici que se joue la confidentialité réelle de vos données.
Tout part du paramètre de partage par défaut de chaque objet. Public en lecture et écriture, public en lecture seule, ou privé. Ce réglage définit ce que voit quelqu'un qui n'a aucun lien particulier avec l'enregistrement.
À partir de là, la visibilité s'élargit par plusieurs mécanismes. La hiérarchie des rôles fait remonter l'accès vers les responsables. Les règles de partage ouvrent l'accès à des groupes entiers, par exemple une zone géographique ou une équipe transverse. Le partage manuel traite les cas particuliers. L'appartenance à une équipe sur l'enregistrement ajoute encore une couche.
Ma recommandation tient en une phrase : commencez restrictif et ouvrez ensuite. Une org qui démarre en privé et s'ouvre par règles reste compréhensible. Une org partie en public que l'on tente de refermer plus tard casse des usages tous les jours, et la reprise devient un chantier douloureux.
Les quatre droits qui ouvrent tout
Certaines autorisations annulent toutes les règles de partage. Ce sont les premières que je regarde pendant un audit d'org, parce qu'elles rendent le reste théorique.
- Afficher toutes les données. L'utilisateur voit chaque enregistrement de l'org, quelles que soient les règles. Réservez-la à une ou deux personnes.
- Modifier toutes les données. La précédente, avec le droit de tout modifier et supprimer. Elle ne devrait exister que sur le compte d'administration.
- Exporter des données. Le droit de sortir votre base commerciale de l'outil. On la trouve souvent accordée à des profils entiers sans que personne ne l'ait décidé.
- Gérer les utilisateurs. Le droit de créer des comptes et d'attribuer des droits, donc de s'accorder tout le reste.
Faites l'exercice une fois : listez les utilisateurs qui disposent de chacune de ces quatre autorisations. Dans la plupart des orgs que je reprends, la liste comporte deux ou trois noms de trop, souvent des personnes parties ou des comptes techniques créés pour un besoin ponctuel.
La sécurité au niveau des champs, celle qu'on oublie
Un utilisateur peut voir un enregistrement sans voir tous ses champs. Cette granularité est précieuse et sous-utilisée.
C'est elle qui permet de masquer une marge, un coût d'achat, une note interne ou une donnée sensible, tout en laissant l'enregistrement accessible. Sans elle, vous vous retrouvez à créer des objets séparés pour cacher trois champs, avec toute la complexité que cela entraîne.
Attention à un point contre-intuitif : masquer un champ dans la mise en page n'est pas une protection. Le champ reste accessible par les rapports, par l'export et par l'interface mobile. Seule la sécurité au niveau du champ le masque réellement.
Dans quel ordre régler tout cela
L'ordre compte, parce que chaque couche s'appuie sur la précédente. Voici celui que je suis systématiquement lors d'une remise au propre de la sécurité.
- 1. Les paramètres de partage par défaut, objet par objet, en partant du plus restrictif.
- 2. La hiérarchie des rôles, qui doit refléter la réalité de qui supervise qui, et non l'organigramme officiel.
- 3. Les règles de partage, pour les besoins transverses qui ne suivent pas la hiérarchie.
- 4. Les profils, réduits au minimum, un par grande famille d'utilisateurs.
- 5. Les permission sets, nommés par usage, pour tout le reste.
- 6. La sécurité des champs, sur les données réellement sensibles.
Tout se teste dans une sandbox avec des comptes de test représentatifs. Se connecter en tant qu'un utilisateur et regarder son écran vaut mieux que toutes les matrices de droits sur papier.
Ce que ce chantier vous apporte
Le bénéfice évident est la confidentialité : vos marges, vos conditions et votre base commerciale cessent d'être accessibles à qui n'en a pas besoin.
Le bénéfice moins évident est la clarté. Une org où les droits sont lisibles est une org où l'on peut accueillir un nouvel arrivant en dix minutes, traiter un départ sans stress, et répondre en quelques clics le jour où quelqu'un demande qui a accès à quoi. C'est aussi ce qui rend un offboarding propre possible, et ce qui permet de repérer les licences attribuées sans usage réel.
Si vous ne faites qu'une chose après cette lecture, ouvrez la liste de vos profils. S'ils sont plus nombreux que vos familles de métiers, vous savez déjà par où commencer, et les permission sets sont la sortie de ce labyrinthe.
Questions fréquentes
Faut-il encore créer des profils dans Salesforce ?
Le moins possible. Salesforce oriente clairement sa plateforme vers les permission sets, et la bonne pratique consiste à garder un profil minimal par grande famille d'utilisateurs, puis à ajouter les droits par permission sets. Une org avec autant de profils que d'utilisateurs est une org que personne ne peut plus auditer.
Quelle différence entre un rôle et un profil ?
Le profil détermine ce que vous avez le droit de faire, par exemple créer une opportunité ou exporter des données. Le rôle détermine quels enregistrements vous voyez, selon votre position dans la hiérarchie. Les deux sont indépendants : on peut avoir tous les droits fonctionnels et ne voir que ses propres affaires.