Comprendre le modèle de partage Salesforce : OWD, rôles, partage

Le modèle de partage Salesforce détermine qui peut voir et modifier quels enregistrements. C'est la couche la plus mal comprise de la plateforme, et pourtant celle qui provoque le plus d'incidents de sécurité en production : des commerciaux qui voient les comptes d'un autre secteur, un manager qui ne voit pas les opportunités de son équipe, ou pire, des données sensibles exposées à toute l'org. Ce modèle repose sur quatre couches empilées : les permissions objet (profil/ensemble de permissions), l'Organization-Wide Default (OWD), la hiérarchie de rôles, et les règles de partage. Chaque couche ne fait qu'élargir l'accès, jamais le restreindre.

1. Le point de départ : les permissions objet

Avant même de parler de partage, un utilisateur doit avoir le droit CRUD (Create, Read, Update, Delete) sur l'objet via son profil ou un Permission Set. Sans ce droit de base, aucun mécanisme de partage ne peut donner accès à un enregistrement. C'est souvent la première case à cocher qu'on oublie en debug : un utilisateur qui "ne voit rien" a parfois simplement perdu l'accès Read sur l'objet lui-même.

2. Organization-Wide Default (OWD) : le réglage par défaut

L'OWD définit le niveau d'accès le plus restrictif possible par défaut pour un objet, avant toute ouverture. Il se configure dans Configuration > Sécurité > Paramètres de partage. Trois valeurs principales :

• Privé : seul le propriétaire de l'enregistrement (et sa hiérarchie de rôle au-dessus) y a accès.
• Lecture seule publique : tout le monde peut voir, seul le propriétaire modifie.
• Lecture/Écriture publique : tout le monde voit et modifie.

Pour les objets sensibles (dossiers RH, contrats, données financières), Privé doit être le défaut. Ouvrir ensuite l'accès de façon ciblée avec les rôles et les règles de partage est toujours plus sûr que de partir d'un OWD trop permissif qu'on essaie de restreindre après coup avec des règles de partage restrictives — ce que Salesforce ne permet pas nativement.

Changer l'OWD d'un objet déjà en production recalcule tous les partages : sur un gros volume de données, prévoyez une fenêtre de maintenance, l'opération peut prendre plusieurs heures.

3. La hiérarchie de rôles : l'accès vertical

La hiérarchie de rôles (Configuration > Utilisateurs > Rôles) donne automatiquement aux utilisateurs situés au-dessus dans la hiérarchie l'accès aux enregistrements possédés par ceux du dessous — à condition que l'OWD ne soit pas déjà Lecture/Écriture publique (dans ce cas la hiérarchie n'apporte rien de plus). C'est le mécanisme naturel pour reproduire l'organigramme : un Directeur Commercial voit les opportunités de tous les commerciaux sous lui. Attention : la hiérarchie de rôles n'est pas l'organigramme RH. Elle doit être construite pour refléter les besoins de visibilité métier, pas les lignes de reporting managérial. On peut décocher l'option "Accès en lecture/écriture" par défaut et choisir "Lecture seule" pour la hiérarchie sur un objet précis, via les paramètres de partage.

4. Les règles de partage : l'accès horizontal et ciblé

Quand l'OWD est privé et que la hiérarchie ne suffit pas (par exemple partager entre pairs d'une même équipe, ou avec une queue), on utilise les règles de partage (Configuration > Paramètres de partage > [Objet] Règles de partage). Deux types principaux :

1. Basées sur le propriétaire : tous les enregistrements possédés par un rôle/groupe public/groupe de rôle et subordonnés sont partagés avec un autre rôle/groupe.
2. Basées sur des critères : partage automatique selon la valeur de champs (ex. tous les comptes avec "Secteur = Grand Compte" partagés avec l'équipe Grands Comptes).

Ces règles peuvent accorder un accès en Lecture seule ou en Lecture/Écriture. Il existe aussi le partage manuel (bouton "Partager" sur un enregistrement) et le partage programmatique via Apex Managed Sharing (objets __Share) pour des cas complexes non couverts par l'UI.

5. Diagnostiquer un problème de visibilité

Face à "l'utilisateur X ne voit pas l'enregistrement Y", la méthode la plus fiable reste l'outil Vérification d'accès aux enregistrements (Configuration, dans l'aide contextuelle d'un enregistrement, ou via Configuration > Utilisateurs > sélectionner l'utilisateur > "Vérifier l'accès aux enregistrements"). Il liste précisément quelle règle, quel rôle ou quelle permission accorde ou refuse l'accès, plutôt que de deviner en croisant les quatre couches manuellement.

Bonnes pratiques à retenir

• Partez toujours d'un OWD restrictif sur les objets sensibles, puis ouvrez avec parcimonie.
• Documentez votre hiérarchie de rôles avant de la construire : elle est coûteuse à refactorer une fois peuplée de millions d'enregistrements.
• Préférez les règles de partage basées sur des critères aux partages manuels, qui ne passent pas à l'échelle et sont invisibles en audit.
• Testez toujours avec "Se connecter en tant que" pour valider le ressenti utilisateur final, pas seulement la théorie.