Les Organization-Wide Defaults (OWD) de Salesforce expliqués

Les valeurs par défaut à l’échelle de l’organisation sont le point de départ de chaque décision de partage dans Salesforce. Réussissez-les et le reste du modèle — hiérarchie des rôles, règles de partage, partages — disposera d’une fondation saine sur laquelle s’appuyer. Ratez-les (généralement parce qu’elles sont trop ouvertes) et aucune règle de partage astucieuse ne pourra corriger le problème. Ce guide explique ce qu’elles sont et comment bien les configurer.

Ce que sont les valeurs par défaut à l’échelle de l’org

Les Organization-Wide Defaults (OWD) définissent le niveau d’accès de référence dont disposent les utilisateurs sur les enregistrements qu’ils ne possèdent pas, objet par objet. C’est le réglage le plus restrictif ; tout le reste existe pour ouvrir l’accès au-dessus de ce socle.

Les valeurs par défaut de l’org sont le socle. La hiérarchie des rôles et les règles de partage sont les moyens d’élever des personnes précises au-dessus de ce socle. Aucun outil standard ne permet de passer en dessous.

C’est pourquoi l’OWD constitue la première couche du modèle d’accès aux enregistrements.

Les niveaux d’accès

L’OWD de chaque objet est réglée sur l’une des valeurs suivantes :

Niveau	Qui peut voir / faire quoi
Privé	Seul le propriétaire (et les utilisateurs au-dessus de lui dans la hiérarchie des rôles) peut consulter
Public en lecture seule	Toute personne ayant accès à l’objet peut consulter ; seul le propriétaire peut modifier
Public en lecture/écriture	Toute personne ayant accès à l’objet peut consulter et modifier
Contrôlé par le parent	L’accès suit l’enregistrement maître/parent associé

Certains objets offrent des variantes supplémentaires (par exemple Lecture/Écriture/Transfert pour les leads et les requêtes).

Valeurs par défaut internes et externes

De nombreux objets permettent de définir des valeurs par défaut à l’échelle de l’org distinctes pour l’interne et pour l’externe. La valeur par défaut externe régit les utilisateurs d’Experience Cloud (communauté) et de portail, et peut — et devrait généralement — être plus restrictive que la valeur interne, afin que les audiences externes n’héritent pas de l’accès plus large dont dispose votre personnel.

Bonne pratique : commencer restrictif, ouvrir délibérément

La règle d’or :

Réglez l’OWD sur le niveau le plus restrictif que l’activité peut tolérer — généralement Privé — puis ouvrez l’accès avec la hiérarchie des rôles et les règles de partage.

La raison tient au sens de fonctionnement du modèle de partage. L’accès est additif : vous pouvez toujours ajouter de l’accès par-dessus un socle Privé, mais vous ne pouvez pas utiliser les règles de partage pour retirer un accès qu’une OWD trop ouverte a déjà distribué à tout le monde. Démarrer en Privé maintient un modèle intentionnel, auditable et facile à comprendre.

Une façon rapide de choisir

Pour chaque objet, demandez-vous : un employé lambda qui ne possède pas cet enregistrement devrait-il le voir par défaut ?

Non, jamais → Privé.
Il peut le lire mais pas le modifier → Public en lecture seule.
N’importe qui peut le modifier librement → Public en lecture/écriture (rare pour des données sensibles).

Modifier une OWD après la mise en production

Ouvrir une OWD (par exemple Privé → Public en lecture seule) est peu risqué — cela ne fait qu’accorder davantage d’accès.
Resserrer une OWD (Public → Privé) est le changement à planifier. Il déclenche un recalcul du partage et peut retirer un accès dont les utilisateurs dépendent actuellement. Testez dans une sandbox, et communiquez avant de déployer.

Pourquoi l’OWD est la première chose à auditer

Parce que tous les autres mécanismes s’appuient sur elle, une OWD trop ouverte gonfle silencieusement ce que tout le monde peut voir — et cela reste invisible jusqu’à ce que quelqu’un demande « attendez, qui peut voir tout ça ? ». Lorsque vous examinez les accès, l’OWD est le socle qui explique les plus grandes surprises.

AgentForceAccess rend ce socle lisible : demandez pourquoi un utilisateur peut voir un enregistrement et l’outil vous indique quand la réponse est simplement « la valeur par défaut de l’org est Public » — par opposition à une règle ou un partage spécifique — pour que vous corrigiez la cause à la bonne couche.

Questions fréquentes

Que signifie chaque niveau d'accès OWD ?

Privé — seuls le propriétaire et les utilisateurs situés au-dessus de lui dans la hiérarchie des rôles voient l'enregistrement. Public en lecture seule — toute personne ayant accès à l'objet peut consulter, seul le propriétaire peut modifier. Public en lecture/écriture — tout le monde peut consulter et modifier. Contrôlé par le parent — l'accès suit l'enregistrement maître associé.

Pourquoi devrais-je commencer en Privé ?

Parce que le partage est additif : vous pouvez toujours élargir l'accès avec la hiérarchie des rôles et les règles de partage, mais vous ne pouvez pas les utiliser pour reprendre un accès qu'une OWD trop ouverte a déjà accordé. Démarrer en Privé et élargir délibérément maintient un modèle intentionnel et auditable.

Quelle est la différence entre les valeurs par défaut internes et externes ?

De nombreux objets permettent de définir une valeur par défaut distincte pour les utilisateurs externes — utilisateurs d'Experience Cloud / de communauté et de portail — qui peut être plus restrictive que la valeur par défaut interne. Cela évite que les audiences externes héritent de l'accès dont disposent vos utilisateurs internes.

Puis-je réduire l'accès d'un objet après la mise en production ?

Oui, mais resserrer une OWD déclenche un recalcul du partage et peut retirer un accès dont les utilisateurs dépendent actuellement ; testez donc dans une sandbox et communiquez le changement. Ouvrir une OWD est peu risqué ; en restreindre une est le changement à planifier avec soin.