Pourquoi un modèle de partage correctement défini a posteriori est plus difficile à construire qu'un modèle bien pensé dès le départ
Le problème typique n'est pas révélé au cours du premier mois. Il apparaît lorsqu'un directeur commercial régional remarque qu'il peut voir une opportunité d'un territoire concurrent, ou lorsqu'un agent de service ouvre le dossier d'un client VIP qui ne devrait être accessible qu'à une équipe dédiée. Ces deux cas résultent directement d'un ordre de travail inversé : les objets et les champs sont définis, et ce n'est qu'à la fin que l'on se demande qui devrait réellement voir quoi.
Le modèle de visibilité dans Salesforce est construit à partir de couches qui fonctionnent ensemble et non isolément : les paramètres par défaut à l'échelle de l'organisation (OWD) définissent le niveau de base le plus privé, la hiérarchie des rôles ajoute un accès vertical en fonction de la structure de gestion, les règles de partage ouvrent un accès horizontal selon des critères métier, les équipes et le partage manuel gèrent les cas individuels, et le partage géré par Apex intervient lorsque la logique est trop complexe pour être exprimée de manière statique. Cet ordre est crucial : toute couche choisie prématurément crée une dette difficile à annuler, car les autorisations déjà accordées sont perçues comme un droit établi.
La carte des couches et quand choisir chacune
| Couche | Ce qu'elle résout | Quand la choisir | Le risque d'un mauvais choix |
|---|---|---|---|
| OWD | La base : qui ne peut rien voir par défaut | Toujours configuré, généralement Privé pour les objets sensibles | Un OWD trop ouvert rend toute autre couche superflue |
| Hiérarchie des rôles | Accès vertical d'un manager aux informations de ses subordonnés | Lorsque la structure de management reflète également le besoin de supervision des données | Une hiérarchie "politique" qui ne correspond pas à la propriété réelle des données |
| Règles de partage | Ouverture de l'accès horizontal selon un critère fixe (rôle, groupe, valeur de champ) | Une équipe transversale ayant besoin d'accéder au même type d'enregistrement | Une multitude de règles qui se chevauchent, rendant difficile de savoir qui a ouvert quoi |
| Groupes publics | Regroupement d'utilisateurs pour le partage, indépendamment de la hiérarchie | Lorsque le groupe de travail ne correspond pas à un rôle organisationnel unique | Des groupes non mis à jour lorsqu'un employé change de poste |
| Équipes de compte/dossier | Accès variable à un enregistrement unique selon la composition de son équipe | Lorsque chaque client ou dossier a une équipe unique et variable | Maintenance manuelle oubliée lorsque l'équipe change |
| Gestion de territoire | Attribution d'accès basée sur des règles dynamiques et multidimensionnelles | Attribution variable selon plusieurs attributs simultanément, accès parallèle pour plusieurs représentants | Complexité de maintenance injustifiée en dessous d'un certain seuil organisationnel |
| Partage géré par Apex | Partage dérivé d'une logique dynamique qui ne peut être exprimée par une règle statique | Un critère dépendant d'un calcul, d'un événement externe ou d'une combinaison de champs | Code non surveillé qui continue de s'exécuter après la modification de l'exigence métier |
OWD : La décision qui détermine toutes les autres
L'OWD n'est pas seulement un paramètre de sécurité technique – c'est une déclaration organisationnelle sur qui est le propriétaire initial de l'information. La règle pratique : définir l'OWD selon la situation la plus restrictive réellement requise, et ouvrir à partir de là en utilisant les Règles de Partage, plutôt que l'inverse. La raison : étendre l'accès de manière ponctuelle est plus facile et documenté, tandis que restreindre un accès déjà existant nécessite une communication organisationnelle, car les utilisateurs perçoivent la perte d'accès comme un préjudice, même s'il s'agit d'une correction d'une erreur historique.
Un point qui ne reçoit pas toujours une attention suffisante : l'OWD est défini séparément pour chaque objet, et les objets dépendants (Maître-Détail) héritent la visibilité de l'objet principal. Lors de la construction d'un nouveau modèle de données, il est impératif de vérifier la chaîne complète de dépendances avant de définir l'OWD – sinon, un objet "secondaire" défini par erreur comme Public peut exposer des informations de l'objet principal par son biais.
Hiérarchie des rôles versus structure de gestion réelle
L'erreur la plus courante est de dupliquer l'organigramme dans la Hiérarchie des rôles tel quel, sans vérifier s'il reflète également le flux de propriété des données. Un directeur régional doit voir les opportunités de son équipe – c'est un rôle de gestion. Mais un directeur financier n'a pas besoin de voir automatiquement chaque dossier de service simplement parce qu'il est haut dans la hiérarchie générale ; si un tel besoin existe, il est résolu par une Règle de partage ciblée et non par une hiérarchie trop large.
Une hiérarchie de partage distincte de la hiérarchie de reporting organisationnelle est une solution légitime et parfois préférable, en particulier dans les organisations dotées d'une structure matricielle où le reporting managérial ne correspond pas à la propriété des données clients.
Matrice de décision : ce qui déclenche chaque mécanisme de partage
- Le besoin varie selon un rôle fixe et prévisible → Hiérarchie des rôles.
- Le besoin est partagé par un groupe de travail inter-rôles → Groupe public + Règle de partage.
- Le besoin varie selon la composition de l'équipe sur un enregistrement unique → Équipe de compte ou Équipe de dossier.
- Le besoin dépend d'une combinaison de conditions dynamiques (géographie, produit, taille du client) → Gestion de territoire.
- Le besoin découle d'un calcul, d'un événement externe ou d'une condition qui ne peut être exprimée par une règle statique → Partage géré par Apex.
- Le besoin est une exception ponctuelle et temporaire pour un enregistrement unique → Partage manuel, sous supervision et documentation.
Cette matrice doit être rédigée avant de travailler avec les outils, et non en parallèle – sinon, nous choisirons un mécanisme basé sur ce que l'équipe de développement connaît, plutôt que sur ce qui est adapté au besoin.
Cas d'étude : Fabricant d'équipement industriel avec trois canaux de vente
Imaginons un fabricant d'équipement industriel hypothétique avec environ 180 utilisateurs Salesforce, opérant sur trois canaux : vente directe par zone géographique, vente via des distributeurs, et vente à des comptes stratégiques mondiaux gérés simultanément par plusieurs représentants dans différents pays.
Une première tentative d'utiliser uniquement la Hiérarchie des rôles a échoué : un compte stratégique mondial n'appartient pas à une seule hiérarchie régionale, et un représentant en Allemagne ne voyait pas les mises à jour de son collègue au Brésil sur le même compte. La solution retenue a combiné trois couches : l'OWD sur Compte et Opportunité a été défini comme Privé ; la Hiérarchie des rôles a été utilisée pour l'accès managérial standard au sein de chaque région ; et pour les comptes stratégiques, une Équipe de compte dynamique a été mise en place, se mettant à jour automatiquement via Flow lorsque le champ "Région du propriétaire du compte stratégique" était modifié. Les distributeurs ont obtenu un accès séparé via une Règle de partage basée sur un Groupe public dédié, afin de ne pas être exposés aux comptes de vente directe.
Le résultat : le temps de recalcul du partage est resté stable, car la majeure partie de l'accès découle d'une structure fixe (Rôle, Groupe public) et seulement une minorité des comptes – les stratégiques – dépend d'une mise à jour dynamique. La leçon clé : il n'y a pas un seul mécanisme "juste" pour toute l'organisation ; il faut adapter le mécanisme au type de dépendance de chaque sous-ensemble d'enregistrements. Une explication plus détaillée sur le choix des modèles d'intégration et du modèle de données pris en charge se trouve dans le Guide d'architecture CRM.
Risques spécifiques liés à la planification de la visibilité et actions préventives
| Risque | Comment il se manifeste concrètement | Action préventive |
|---|---|---|
| OWD "temporairement" ouvert lors de la phase pilote | L'ouverture persiste même après le passage du système en production | Définir une date de fermeture à l'avance et la documenter comme élément Go-Live, non comme une recommandation |
| Multiplicité de règles de partage qui se chevauchent | Il est impossible de savoir avec certitude pourquoi un utilisateur voit un enregistrement donné | Nommage standard pour chaque règle incluant la raison métier, et examen périodique des règles inutilisées |
| Partage Apex sans tests de charge | Le calcul du partage est ralenti avec l'augmentation du volume de données | Exécuter un test de charge sur le recalcul du partage avant de multiplier le volume d'enregistrements en production |
| Hiérarchie de partage copiée à partir d'une hiérarchie organisationnelle "politique" | Les managers voient des données dont ils n'ont pas un besoin métier | Séparer la hiérarchie des rôles à des fins de partage de la hiérarchie de reporting officielle lorsqu'elles ne sont pas identiques |
| Partage manuel accumulé sans propriétaire | Les autorisations exceptionnelles perdurent après que la raison du partage n'est plus pertinente | Processus d'expiration (Expiration) ou examen trimestriel des partages manuels |
| Modification du rôle d'un utilisateur sans mise à jour des groupes publics | L'ancien accès reste ouvert et le nouvel accès est manquant | Intégrer la mise à jour des groupes et des rôles comme une seule étape du processus de changement de statut d'un employé |
Liste de contrôle avant de finaliser le modèle de partage
- ☐ L'OWD a été configuré selon l'état le plus restrictif requis, et non selon la commodité de la phase de développement.
- ☐ La chaîne de dépendance entre les objets Maître-Détail a été vérifiée par rapport à l'OWD de l'objet principal.
- ☐ La hiérarchie des rôles a été examinée par rapport à la propriété réelle des données, et pas seulement par rapport à un organigramme.
- ☐ Chaque règle de partage a une raison métier documentée et un propriétaire responsable de sa validité.
- ☐ Il a été vérifié si la gestion des territoires est réellement nécessaire ou s'il s'agit d'une complexité superflue.
- ☐ Le code de partage Apex a été testé avec un volume de données réaliste, et pas seulement dans un petit environnement Sandbox.
- ☐ Un processus est en place pour la mise à jour des groupes publics et des autorisations en cas de changement de rôle ou de fin d'emploi.
- ☐ Une fréquence d'examen périodique a été définie pour le partage manuel et les règles de partage inactives.
- ☐ L'impact du modèle de partage sur les performances des rapports et des exécutions de lots importants a été évalué.
- ☐ Il existe un plan de réponse en cas de surexposition découverte en production.
Comment savoir si le modèle supporte la charge
Une première mesure est le temps de recalcul du partage après un changement structurel – une augmentation constante dans le temps indique que le modèle approche d'une complexité insoupçonnée. Une deuxième mesure est le nombre de demandes de support du type "il me manque un accès" par rapport à "j'ai un accès inutile" – un ratio qui penche fortement d'un côté indique que l'OWD ou les règles de partage ne sont pas correctement calibrés. Une troisième mesure, particulièrement importante dans les organisations avec de multiples systèmes, est la concordance entre les autorisations Salesforce et les autorisations dans les systèmes synchronisés avec lui – surtout lorsqu'il s'agit d'une architecture d'intégration basée sur les événements, comme décrit dans le Guide d'architecture événementielle dans Salesforce.
Dans les organisations qui exploitent plusieurs Org, la question du modèle de partage se mêle souvent à celle de savoir s'il faut réellement plus d'un environnement de production – la discussion complète à ce sujet est abordée dans Salesforce Single Org vs Multi Org, et dans le choix d'un modèle d'intégration compatible dans le Guide des modèles d'intégration Salesforce.
Résumé
Un modèle de partage et de visibilité efficace ne se mesure pas le jour du lancement – il se mesure lorsque l'organisation se développe, lorsqu'un utilisateur change de rôle et lorsque quelqu'un demande « pourquoi ne vois-je pas cela ? ». La voie à suivre n'est pas de choisir un outil unique et de l'appliquer à tout, mais de mapper chaque groupe d'enregistrements en fonction de son type de dépendance – fixe, transversale, dynamique ou exceptionnelle – et de choisir le mécanisme approprié pour chacun. Un OWD fermé par défaut, une hiérarchie des rôles qui reflète la propriété réelle, des règles de partage avec une raison documentée, et un partage Apex uniquement lorsque la logique le justifie – voilà la combinaison qui tient bon même lorsque l'organisation double en volume et en complexité.