La question fondamentale : Qu'est-ce qui détermine l'accès d'un utilisateur ?
Lorsqu'on demande "comment un utilisateur a-t-il accédé à ce champ ?", la réponse correcte est presque toujours une combinaison : son profil détermine l'accès de base, les groupes d'ensembles d'autorisations (Permission Set Groups) qui lui sont attribués ajoutent des capacités basées sur le rôle, et parfois un ensemble d'autorisations (Permission Set) supplémentaire gère une exception ponctuelle. Le problème en pratique est que la plupart des organisations construisent cette combinaison dans le sens inverse : elles commencent avec un profil large qui contient presque tout, puis "corrigent" des problèmes spécifiques avec des autorisations individuelles que personne ne se souvient de supprimer.
Un modèle d'autorisations sain est construit dans l'autre sens : un profil aussi restreint que possible, qui définit principalement la licence, l'accès par défaut à l'application et les caractéristiques de connexion ; et toutes les capacités de travail réelles – quels objets, quels champs, quelles actions – sont transférées aux Ensembles d'Autorisations et aux Groupes d'Ensembles d'Autorisations (Permission Sets et Permission Set Groups). Il est important de clarifier : cet article traite uniquement de la granularité des objets, des champs et des autorisations système. Les questions de visibilité des enregistrements entre utilisateurs – OWD, Hiérarchie des rôles, Règles de partage – sont abordées dans le Guide de visibilité et de partage, car il s'agit d'une couche de décision distincte avec ses propres compromis.
Les trois unités et leur rôle respectif
| Unité | Ce qu'elle détermine | Combien un utilisateur peut-il en avoir | Quand la choisir |
|---|---|---|---|
| Profil | Licence, Visibilité d'application par défaut, Présentation de page (Page Layout), Heures/IP de connexion | Exactement un | Différences d'infrastructure entre types d'utilisateurs |
| Jeu d'autorisations (Permission Set) | Autorisations d'objet, de champ, de classe Apex, d'onglet - ajoute uniquement | Autant que nécessaire | Capacité unique pertinente pour certains rôles |
| Groupe de jeux d'autorisations (Permission Set Group) | Regroupement de plusieurs jeux d'autorisations sous un même nom, avec possibilité de Muting | Autant que nécessaire | Combinaison fixe d'autorisations représentant un rôle de travail complet |
La différence entre un Jeu d'autorisations et un Groupe de jeux d'autorisations n'est pas seulement technique, elle est organisationnelle. Un Jeu d'autorisations unique convient à une capacité unique et ciblée ("accès aux rapports financiers"). Un Groupe de jeux d'autorisations convient lorsque l'on souhaite attribuer un "ensemble de travail" complet à un département ou à un rôle, et le maintenir en un seul endroit lorsqu'il évolue.
Cadre de décision : À quelle unité appartient une nouvelle permission ?
Lorsqu'une demande d'ajout d'accès est soulevée, la première question n'est pas "à quel profil ajouter", mais plutôt à quelle unité l'autorisation appartient structurellement :
- S'agit-il d'une autorisation qui caractérise tous les détenteurs du même type de licence ? Si oui, c'est une place pour le profil, à condition qu'il s'agisse de tous les détenteurs de la licence et non d'un sous-ensemble.
- S'agit-il d'une capacité de travail qu'un groupe de rôles spécifique doit toujours avoir en même temps que d'autres autorisations ? Si oui, c'est une place pour un Groupe de jeux d'autorisations, même s'il faut d'abord le décomposer en plusieurs Jeux d'autorisations distincts pour permettre une combinaison flexible.
- S'agit-il d'une autorisation ponctuelle et temporaire pour un utilisateur unique ou une exception ? Si oui, un Jeu d'autorisations autonome, attribué manuellement et vérifié lors de l'audit périodique.
- L'autorisation est-elle destinée à priver quelque chose à un utilisateur spécifique au sein d'un groupe plus large ? C'est ici qu'intervient le Jeu d'autorisations de Muting (Muting Permission Set) au sein d'un Groupe de jeux d'autorisations – le seul outil dans Salesforce qui permet de réduire une autorisation sans toucher au profil ou décomposer le groupe.
La règle qui prévient la plupart des dérives : ne jamais modifier un profil pour résoudre un problème d'utilisateur unique. Si la correction est définie comme une exception, elle passe par un Jeu d'autorisations documenté et ayant une date de révision.
Liste de contrôle pour la construction d'un modèle d'autorisations à partir de zéro
- ☐ Les rôles de travail réels (et non les départements organisationnels) ont été mappés et chaque rôle a reçu un nom clair.
- ☐ Pour chaque rôle, une liste de capacités requises au niveau de l'objet, du champ et de la classe Apex a été définie.
- ☐ Des Jeux d'autorisations ciblés sur une capacité unique ont été construits, et non des "amas d'autorisations" génériques.
- ☐ Chaque rôle a reçu un seul Groupe de jeux d'autorisations regroupant les capacités pertinentes.
- ☐ Les profils ont été réduits aux seules différences de licence et d'infrastructure.
- ☐ Un processus a été défini pour les cas exceptionnels : qui approuve un Jeu d'autorisations ponctuel et pour quelle durée.
- ☐ Une fréquence d'audit a été établie (trimestrielle au minimum) qui compare les autorisations actives au rôle actuel.
- ☐ Un propriétaire unique a été désigné pour la maintenance du modèle d'autorisations en fonction des changements de structure organisationnelle.
Scénario d'entreprise : une compagnie d'assurances avec trois unités de vente
Imaginons une compagnie d'assurance de taille moyenne avec environ trois cents utilisateurs Salesforce, répartis en trois unités : ventes directes, ventes via des agents et sinistres. Avant le projet, l'entreprise comptait douze profils différents, dont certains étaient des copies presque identiques créées pour "corriger" une seule autorisation pour un petit groupe. Résultat typique : lorsqu'un nouvel agent rejoignait l'entreprise, personne ne savait avec certitude quel profil parmi les douze lui convenait, et la réponse pratique était "copiez celui de quelqu'un de similaire".
L'équipe architecturale a reconstruit le modèle : trois profils seulement, selon le type de licence (Sales Cloud complet, Community pour les agents externes, Service Cloud pour les sinistres). Au-dessus d'eux, sept groupes d'ensembles d'autorisations (Permission Set Groups) selon le rôle de travail réel – représentant commercial, chef d'équipe de vente, agent externe, gestionnaire d'agents, expert en sinistres, gestionnaire de sinistres, et un rôle transitoire qui traite à la fois des ventes et des sinistres. Chaque Groupe d'ensembles d'autorisations était composé d'ensembles d'autorisations (Permission Sets) ciblés tels que "accès aux polices actives" ou "approbation de remboursement jusqu'à un plafond défini", de sorte qu'il était possible de les combiner à nouveau lorsqu'un nouveau rôle était créé sans avoir à construire l'autorisation de zéro.
Le résultat mesurable : le temps de création d'un nouvel utilisateur a diminué de plusieurs jours (incluant une vérification manuelle du profil approprié) à quelques heures, et le nombre de demandes de support du type "je n'ai pas accès au champ X" a diminué de moitié au cours du trimestre suivant la transition, car la plupart de ces demandes provenaient d'un profil qui n'incluait pas la capacité et il n'était pas clair à qui s'adresser pour la correction.
Risques courants et actions préventives
| Risque | Comment il se manifeste en pratique | Action préventive |
|---|---|---|
| Le profil devient un outil de correction ponctuel | Multiplicité de profils presque identiques, chacun pour un petit groupe | Transférer toute autorisation ponctuelle vers un Jeu d'autorisations et restreindre les profils à la licence uniquement |
| Sécurité au niveau du champ (FLS) incohérente | Le même champ est exposé à un endroit et bloqué à un autre | Documenter une matrice FLS centrale pour chaque champ sensible et la vérifier à chaque Release |
| Autorisations "collantes" après un changement de rôle | Un utilisateur qui a changé de rôle conserve les autorisations du rôle précédent | Un processus de désactivation de rôle (Offboarding-from-role) qui supprime l'ancien Groupe de jeux d'autorisations avant d'en ajouter un nouveau |
| Autorisations système (System Permissions) trop larges (View All Data, Modify All) | Attribuées "pour gagner du temps" et non supprimées par la suite | Approbation dédiée et date d'expiration pour toute autorisation système large |
| Absence de propriétaire pour le modèle d'autorisations | Chaque équipe ajoute des autorisations sans vision globale | Un propriétaire unique qui approuve chaque nouveau Jeu d'autorisations ou Groupe avant le déploiement |
Mesures pour évaluer la santé du modèle
| Domaine | Ce qui est mesuré | Fréquence de vérification |
|---|---|---|
| Duplication inutile | Nombre de profils actifs par rapport au nombre réel de types de licences | Trimestriel |
| Précision des autorisations | Pourcentage d'utilisateurs dont les autorisations correspondent au rôle enregistré dans les RH | Trimestriel |
| Exceptions ouvertes | Nombre de Jeux d'autorisations ponctuels sans date de révision | Mensuel |
| Autorisations larges | Nombre d'utilisateurs avec View All Data / Modify All Data sans justification documentée | Mensuel |
| Temps de configuration | Temps moyen entre la demande d'accès et l'attribution complète | Continu |
Pour la première version du suivi, il est conseillé de se limiter à trois mesures parmi les cinq, et de n'élargir le scope qu'après avoir établi une base de référence fiable. Une mesure sans propriétaire et sans date de vérification a tendance à disparaître du rapport après le premier mois.
Comment cela s'intègre dans l'architecture plus large
Un bon modèle d'autorisations est une condition préalable, et non un substitut, à la planification de la visibilité des enregistrements (OWD, hiérarchie des rôles, règles de partage) – ces deux sujets se complètent mais sont résolus séparément. Une organisation qui tente de résoudre un problème de visibilité en élargissant un profil, ou inversement, découvre généralement que la solution est fragile dès que la structure organisationnelle change. Lorsque l'organisation passe de plusieurs Orgs à un seul Org, le modèle d'autorisations est l'un des éléments qui doit être remappé – une explication plus détaillée est disponible dans le guide Single Org vs Multi Org. Et lorsque l'autorisation elle-même dépend d'une logique conditionnelle complexe, il convient d'examiner si l'implémentation relève de Flow ou d'Apex, comme détaillé dans le guide Flow vs Apex.
Dans les organisations qui exécutent des processus basés sur des événements entre systèmes, il est essentiel de s'assurer que les autorisations des utilisateurs de service (Integration Users) sont construites selon le même principe – un Jeu d'autorisations ciblé et non un profil large avec "System Administrator" comme valeur par défaut commode. Ce sujet est lié à la planification plus large de la communication entre systèmes, décrite dans le guide d'architecture événementielle pour Salesforce.
Résumé
Un modèle d'autorisations qui résiste à l'épreuve du temps est construit de bas en haut : des capacités ciblées dans les Jeux d'autorisations (Permission Sets), leur assemblage selon le rôle de travail réel dans les Groupes de Jeux d'autorisations (Permission Set Groups), et un Profil qui conserve un rôle minimal de licence et d'infrastructure uniquement. Le signe distinctif d'un échec est la prolifération de profils créés pour résoudre des problèmes ponctuels – chaque profil supplémentaire de ce type est une dette qui s'accumule jusqu'à ce que personne ne se souvienne pourquoi il existe. Lorsque la capacité interne à construire ou à nettoyer un modèle existant fait défaut, le service d'architecture CRM offre une voie pratique pour un démarrage ciblé.