Rôles, hiérarchie et règles de partage : bien concevoir votre modèle de sécurité

Une fois les profils et permission sets en place, une deuxième couche entre en jeu dès que l'organisation par défaut (OWD) n'est pas « Public en lecture/écriture » : le partage d'enregistrements. C'est là que rôles, hiérarchie et règles de partage prennent tout leur sens. Mal conçus, ils génèrent des recalculs de partage interminables et des accès incohérents ; bien pensés, ils reflètent fidèlement votre organisation métier.

Organization-Wide Defaults : le point de départ

Tout commence par la définition des OWD (Configuration > Paramètres de partage) pour chaque objet : Privé, Public en lecture seule, ou Public en lecture/écriture. C'est le réglage le plus restrictif possible par défaut ; tous les mécanismes suivants ne font qu'ouvrir des accès, jamais en fermer. Si vos OWD sont déjà ouverts, la hiérarchie de rôles et les règles de partage deviennent inutiles pour cet objet — inutile de les complexifier pour rien.

La hiérarchie de rôles : un accès vertical automatique

La hiérarchie de rôles (Configuration > Utilisateurs > Rôles) organise les utilisateurs selon un arbre qui reflète généralement les lignes hiérarchiques ou territoriales. Par défaut, un utilisateur voit automatiquement les enregistrements appartenant aux utilisateurs situés en dessous de lui dans la hiérarchie (sauf si l'option « Grant Access Using Hierarchies » est décochée pour un objet personnalisé donné, ce qui est rare).

• Le rôle n'est pas le poste de l'utilisateur : c'est un objet purement dédié au partage, distinct du titre affiché sur sa fiche.
• Gardez la hiérarchie peu profonde (3 à 5 niveaux idéalement) : chaque niveau supplémentaire alourdit les calculs de partage, surtout sur les gros volumes.
• Une hiérarchie de rôles trop calquée sur l'organigramme RH (qui change souvent) devient vite une source de maintenance lourde. Préférez une structure basée sur des fonctions ou territoires stables.

Règles de partage : ouvrir des accès horizontaux

Les règles de partage (Configuration > Paramètres de partage > Règles de partage) permettent d'ouvrir l'accès horizontalement, entre groupes qui n'ont pas de lien hiérarchique. Deux types principaux :

1. Basées sur le propriétaire : « tous les enregistrements possédés par le groupe public X sont visibles par le rôle Y », par exemple pour partager les comptes d'une équipe régionale avec le support client.
2. Basées sur des critères : partage automatique selon la valeur d'un champ (ex. tous les dossiers avec Statut = « Escaladé » partagés avec le groupe Direction), indépendamment du propriétaire.

Chaque règle attribue un niveau d'accès (Lecture seule ou Lecture/Écriture) qui ne peut qu'ajouter des droits par rapport à l'OWD, jamais les restreindre.

Groupes publics : la brique de composition

Les groupes publics (Configuration > Utilisateurs > Groupes publics) permettent de combiner utilisateurs, rôles et sous-groupes en une entité unique réutilisable dans les règles de partage. C'est l'outil à privilégier pour cibler des populations qui ne correspondent pas exactement à un rôle (ex. « tous les managers commerciaux + l'équipe support niveau 2 »).

Piège classique : ajouter une règle de partage par critère sur un objet à fort volume sans mesurer l'impact sur les temps de recalcul du partage. Testez toujours en sandbox avec un volume représentatif avant de déployer en production.

Cas particulier : équipes de compte et d'opportunité

Pour des besoins de partage ponctuels et non systémiques, les équipes de compte et équipes d'opportunité offrent une alternative légère : un utilisateur peut ajouter manuellement un collègue à un enregistrement précis sans passer par une règle globale. C'est idéal pour de la collaboration ad hoc, mais ne remplace pas un vrai modèle de partage pour des besoins récurrents.

Méthodologie de conception

• Partez toujours des besoins métier réels de visibilité, pas de la structure organisationnelle théorique.
• Documentez chaque règle de partage avec sa raison d'être : elles s'accumulent vite et deviennent illisibles sans contexte.
• Limitez le nombre de règles de partage par objet (Salesforce impose des limites strictes selon l'édition) et privilégiez les critères larges plutôt que de multiplier les règles fines.
• Revoyez le modèle à chaque réorganisation majeure : une hiérarchie obsolète casse silencieusement la visibilité des données.

Un modèle de sécurité bien conçu reste invisible pour les utilisateurs : ils voient exactement ce dont ils ont besoin, ni plus ni moins, sans jamais avoir à demander un accès manuel.