Sur une org Salesforce, le modèle d'habilitations est l'une des premières décisions structurantes — et l'une des plus rarement documentées. Mal cadré, il devient en deux ou trois ans un enchevêtrement de profils dupliqués et de règles contradictoires que personne n'ose modifier. Bien conçu, il absorbe l'arrivée de nouvelles équipes, de nouveaux clouds et de nouvelles obligations réglementaires sans réécriture. Cet article détaille comment poser un modèle qui tient à cinq ans, et comment reconnaître un intégrateur qui sait le faire.
Profils, rôles, permission sets : trois briques distinctes
La confusion entre ces trois objets est la source la plus fréquente de dette technique sur les habilitations. Chacun répond à une question différente.
- Le profil définit ce qu'un utilisateur peut faire : accès aux objets, aux champs, aux applications, aux onglets. Il est obligatoire (un utilisateur a exactement un profil).
- Le rôle définit ce qu'un utilisateur peut voir dans la hiérarchie de partage : il conditionne la visibilité verticale des enregistrements (un manager voit les données de son équipe).
- Le permission set (et les permission set groups) ajoute des droits par-dessus le profil, sans le modifier. Il est cumulable et attribuable à la demande.
La règle directrice moderne, recommandée par Salesforce depuis plusieurs années : garder des profils minimalistes et confier l'essentiel de la granularité aux permission sets. Cette approche prépare d'ailleurs la fin annoncée de la gestion des permissions au niveau des profils, que Salesforce a communiquée dans sa feuille de route.
Pourquoi le « profil par métier » ne tient pas dans le temps
Le réflexe historique consiste à créer un profil par population : « Profil Commercial Nord », « Profil Commercial Sud », « Profil ADV avec accès facturation ». Le résultat est prévisible : au bout de trois ans, l'org compte 40 profils dont la moitié ne diffèrent que par deux cases à cocher. Chaque évolution oblige alors à répéter la modification sur tous les profils concernés, avec un risque d'oubli à chaque itération.
Le modèle qui tient repose sur une logique additive :
- Un petit nombre de profils socle (souvent 3 à 6) qui portent le strict nécessaire commun à une grande population.
- Des permission sets fonctionnels nommés par capacité (« Accès module facturation », « Export de données », « Gestion des campagnes »), attribués à la carte.
- Des permission set groups qui regroupent ces capacités par métier réel, avec la possibilité de désactiver temporairement une permission (muting) sans démonter le groupe.
Quand un nouveau besoin arrive, on crée ou attribue un permission set — on ne touche pas au socle. C'est cette propriété qui rend le modèle durable.
Cadrer le partage : hiérarchie de rôles et règles
Le modèle de partage se conçoit en même temps que les habilitations fonctionnelles, jamais après. Il s'appuie sur trois niveaux à décider dans l'ordre :
- Les paramètres de partage par défaut (Org-Wide Defaults) : par principe, on part du plus restrictif (Private) et on ouvre ensuite, plutôt que l'inverse.
- La hiérarchie de rôles, qui fait remonter la visibilité vers le haut de l'organigramme.
- Les règles de partage pour les cas transverses (partage entre équipes de même niveau, partage basé sur des critères).
Une erreur récurrente consiste à calquer la hiérarchie de rôles sur l'organigramme RH complet. Le rôle sert la visibilité des données, pas la représentation de l'entreprise. Une hiérarchie de rôles trop profonde ralentit les recalculs de partage et complique le débogage. Mieux vaut une hiérarchie plate, alignée sur les besoins réels de visibilité.
Attention à l'accumulation silencieuse de droits. Un utilisateur qui change de poste conserve souvent ses anciens permission sets si aucun processus de revue n'existe. Au bout de quelques années, cela crée des accès non justifiés — un point systématiquement relevé lors d'audits de sécurité et incompatible avec le principe de minimisation des données du RGPD.
Documenter et gouverner : la condition du long terme
Un modèle d'habilitations n'est durable que s'il est gouverné. Trois pratiques font la différence entre une org saine à cinq ans et une org qu'on n'ose plus modifier.
Une convention de nommage stricte
Les permission sets et groupes doivent porter des noms explicites et cohérents : préfixe fonctionnel, verbe d'action, périmètre. « PS_Facturation_Consultation » se lit sans documentation ; « Perm3_new » ne se lit jamais. Cette discipline paraît triviale mais conditionne la capacité de tout nouvel administrateur à reprendre l'existant.
Une matrice d'habilitations tenue à jour
Un tableau qui croise populations, profils socle, permission sets et justification métier constitue le référentiel de contrôle. Il permet de répondre à la question qu'un auditeur posera tôt ou tard : « pourquoi cet utilisateur a-t-il accès à cet objet ? »
Une revue périodique des accès
Prévoir une revue au moins annuelle des attributions, avec retrait des droits obsolètes. Salesforce fournit les outils de reporting nécessaires (User Access Policies, rapports sur les permission set assignments) pour industrialiser cette revue.
Ce que cela implique dans le choix d'un intégrateur
Le modèle d'habilitations est rarement le premier sujet abordé en avant-vente, alors qu'il détermine le coût de maintenance des années suivantes. Quelques questions permettent de distinguer un prestataire qui pense long terme :
- Propose-t-il d'emblée une logique profils socle + permission sets, ou reproduit-il un profil par métier ?
- Livre-t-il une matrice d'habilitations documentée et une convention de nommage ?
- A-t-il prévu la gouvernance (revue des accès, gestion des mouvements internes) et pas seulement la mise en place initiale ?
- Anticipe-t-il la trajectoire Salesforce vers les permission sets plutôt que de figer des choix bientôt dépréciés ?
Ces critères sont vérifiables indépendamment du volume de projets affiché par un prestataire. C'est précisément l'approche d'INTEGREER : qualifier le besoin à partir d'éléments factuels et objectifs, pour aider une ETI à cadrer sa demande avant de rencontrer des intégrateurs, plutôt que de se fier à un discours commercial.
Aller plus loin
En résumé
Un modèle d'habilitations qui tient à cinq ans repose sur trois principes : des profils socle minimalistes, une granularité portée par les permission sets, et une gouvernance documentée avec revue régulière. Les décisions prises au démarrage — nommage, profondeur de la hiérarchie de rôles, matrice de contrôle — pèsent bien plus lourd que le paramétrage lui-même. Les valider avant de lancer le projet évite une refonte coûteuse quelques années plus tard.