Concevoir un modèle de permissions Salesforce évolutif

Un modèle de permissions Salesforce commence simplement. Un profil pour les représentants commerciaux, un pour les gestionnaires, un pour les administrateurs. Puis l’entreprise grandit, les rôles se multiplient, des acquisitions surviennent, des produits s’ajoutent — et soudainement vous avez 47 profils, personne ne sait ce que chacun fait, et modifier une permission de champ prend trois heures de tests parce que vous n’êtes pas sûr de qui sera affecté.

Ce n’est pas une fatalité. Voici comment construire un modèle de permissions qui reste gérable à mesure que l’org grandit.

Comprendre les outils avant de les choisir

Salesforce vous donne plusieurs couches :

Outil	Contrôle	Utilisation optimale
Profil	CRUD objet/champ, visibilité des apps, heures/IP de connexion	Accès de base uniquement — le minimum dont chaque utilisateur de ce type a besoin
Ensemble de permissions	Identique au profil, additif seulement	Ajouts spécifiques de fonctionnalités ou de rôles par-dessus le profil
Groupe d’ensembles de permissions	Regroupe plusieurs ensembles de permissions	Attribution d’un « paquet de rôle » complet à un type d’utilisateur
Ensemble de permissions de désactivation	Retire des permissions dans un GEP	Gestion des exceptions au sein d’un groupe

L’insight clé : les profils doivent être minimaux, les ensembles de permissions font le vrai travail.

L’approche « profil minimal viable »

Les orgs les plus maintenables que nous avons vues utilisent 3 à 5 profils :

Utilisateur standard — lecture/création de base sur les objets principaux, pas de champs sensibles, pas d’opérations destructives
Utilisateur avancé — modification et suppression sur la plupart des objets, visibilité modérée des champs
Lecture seule — pour les sous-traitants, les auditeurs, les intégrations qui n’ont besoin que de lire
Administrateur système — accès complet, seulement pour les vrais administrateurs
(Optionnel) Utilisateur communauté / portail — pour Experience Cloud

C’est tout. Chaque variation d’accès — un directeur commercial qui peut voir les champs de revenus, un agent de support qui peut fermer des requêtes, un utilisateur marketing qui n’accède qu’aux campagnes — est gérée par des ensembles de permissions empilés sur le profil de base.

Cela signifie que vous pouvez modifier un profil et savoir exactement qui est affecté. Cela signifie que l’intégration d’un nouvel utilisateur consiste à attribuer un profil et quelques ensembles de permissions, pas à cloner un profil sur mesure et à ajuster manuellement 200 paramètres.

Nommer les ensembles de permissions de façon à les retrouver

Trois mois après leur création, les ensembles de permissions deviennent impossibles à trouver s’ils s’appellent EP_RepVentes_V2_NOUVEAU ou Accès complet marketing. Utilisez une convention de nommage cohérente :

[Objet/Fonctionnalité] — [Action/Niveau]

Exemples :

Opportunité — Modifier les champs de revenus
Requête — Fermer et supprimer
Rapports — Créer et modifier
CPQ — Accès complet

Quand vous recherchez dans votre liste d’ensembles de permissions tout ce qui est lié aux Requêtes, chaque ensemble pertinent apparaît ensemble. Quand vous regardez les ensembles attribués à un utilisateur, vous pouvez lire ce que chacun fait sans l’ouvrir.

Les groupes d’ensembles de permissions : l’approche « paquet de rôle »

Si un type d’utilisateur a systématiquement besoin de 6 à 8 ensembles de permissions, regroupez-les dans un Groupe d’ensembles de permissions. Au lieu d’attribuer chaque ensemble individuellement, vous attribuez un seul groupe.

Un gestionnaire de services terrain pourrait avoir besoin de :

Bon de travail — Modifier et fermer
Actif — Consulter et créer
Rendez-vous de service — Accès complet
Rapports — Créer et modifier
Application mobile — Accès complet

Regroupez-les dans un groupe appelé Gestionnaire de services terrain et attribuez cette seule chose. Si les besoins du gestionnaire changent, vous mettez à jour le groupe — et chaque gestionnaire reçoit le changement automatiquement.

Les permissions dangereuses à surveiller

Certaines permissions sont faciles à accorder en excès et difficiles à auditer. Révisez-les régulièrement :

Afficher toutes les données / Modifier toutes les données — ces permissions contournent entièrement les règles de partage. Seuls les utilisateurs d’intégration et les administrateurs système devraient les avoir. Exécutez ce SOQL trimestriellement :

SELECT Name, PermissionsViewAllData, PermissionsModifyAllData
FROM PermissionSet
WHERE PermissionsViewAllData = true OR PermissionsModifyAllData = true

Gérer les utilisateurs — permet à quelqu’un de créer des utilisateurs, d’attribuer des ensembles de permissions, de réinitialiser des mots de passe. Entre de mauvaises mains, c’est un vecteur d’escalade de privilèges.

API activé — nécessaire pour les intégrations et les développeurs, mais ne devrait pas être sur chaque profil d’utilisateur final. C’est un vecteur courant dans les incidents d’exfiltration de données.

Créer de l’Apex / Personnaliser l’application — ces permissions permettent aux utilisateurs de modifier les métadonnées de l’org. À moins que quelqu’un ne soit réellement administrateur ou développeur, il n’en a pas besoin.

La sécurité au niveau des champs : la couche oubliée

L’accès aux objets est la partie à laquelle tout le monde pense. L’accès aux champs est la partie qui vous rattrape.

Un utilisateur avec accès en consultation aux Opportunités peut quand même voir chaque champ sauf si la SNC (Sécurité au niveau des champs) les restreint. Pour les champs sensibles — revenus, marges, données personnelles, numéros d’assurance sociale — définissez la SNC explicitement sur chaque profil et ensemble de permissions, ne supposez pas qu’ils seront cachés par défaut.

Quand vous ajoutez un nouveau champ à n’importe quel objet, demandez-vous : qui a vraiment besoin de voir ça ? Ajustez la SNC avant que le champ soit mis en service, pas après que quelqu’un l’ait remarqué dans un rapport.

Documenter le modèle

Maintenez au minimum une feuille de calcul simple ou une page Confluence avec :

Chaque profil : le type d’utilisateur pour lequel il est destiné, ce qui le différencie des autres
Chaque groupe d’ensembles de permissions : quels rôles d’utilisateurs l’utilisent
Chaque ensemble de permissions autonome : ce qu’il accorde et avec quels profils il est généralement associé

Ce document est votre guide d’intégration, votre preuve d’audit et votre point de départ pour le débogage quand un utilisateur se plaint de ne pas pouvoir voir un champ qu’il devrait voir.

Migrer à partir de profils complexes

Si votre org a proliféré à plus de 30 profils, vous n’avez pas à tout corriger d’un coup. Une approche pratique :

Geler la création de profils — pas de nouveaux profils sans approbation
Pour les nouveaux types d’utilisateurs, utiliser des ensembles de permissions dès le premier jour
Identifier les 3 à 4 profils les plus utilisés et les laisser tranquilles pour l’instant
Quand vous avez une raison de toucher un profil (un nouveau champ, un nouvel objet), prenez 20 minutes pour évaluer si ce profil peut être consolidé dans un profil standard

Sur 12 à 18 mois, le nombre diminue naturellement sans une migration risquée en une seule fois.

Votre modèle de permissions est-il dû pour une révision ? Nous offrons des audits de sécurité Salesforce structurés. Contactez-nous pour savoir où vous en êtes.