Sécurité au niveau des champs (Field-Level Security) expliquée simplement

Le partage d'enregistrements (OWD, rôles, règles) contrôle l'accès à la ligne, mais rien n'empêche un utilisateur ayant accès à un compte de voir son champ "Chiffre d'affaires confidentiel" s'il n'y a pas de restriction sur la colonne. C'est le rôle de la Field-Level Security (FLS), aussi appelée sécurité au niveau des champs. Elle permet de masquer ou de rendre en lecture seule des champs précis, indépendamment de l'objet.

1. Où et comment se configure la FLS

La FLS se définit à deux endroits, qui se cumulent avec la logique la plus restrictive qui l'emporte :

• Profils : Configuration > Utilisateurs > Profils > sélectionner un profil > Sécurité au niveau du champ, pour chaque objet.
• Ensembles de permissions (Permission Sets) : Configuration > Ensembles de permissions > sélectionner un set > Sécurité au niveau du champ.

Chaque champ a trois états possibles : Visible (lecture/écriture), Lecture seule, ou invisible (aucune case cochée). Contrairement aux règles de partage, la FLS ne s'ouvre jamais par des règles automatiques : elle est purement additive via les profils et permission sets attribués à l'utilisateur.

2. La logique du "least privilege" appliquée aux champs

La bonne pratique consiste à définir un profil de base très restrictif (peu de champs visibles), puis à accorder l'accès complémentaire via des Permission Sets ou des Permission Set Groups ciblés par rôle métier. Cela évite l'anti-pattern classique : un profil unique "Commercial" avec 200 champs tous cochés en écriture, y compris des champs de marge ou de coût que seul un category manager devrait voir.

Un champ marqué "obligatoire" (Required) au niveau du champ lui-même, mais masqué par la FLS pour un profil, provoquera une erreur de sauvegarde bloquante pour cet utilisateur. Toujours tester le formulaire complet après une modification de FLS.

3. FLS et Apex : ce que le code ne fait PAS automatiquement

Point critique trop souvent ignoré : le code Apex exécuté sans mode utilisateur (contexte système par défaut) ignore la FLS. Un déclencheur ou une classe Apex standard peut lire ou écrire un champ même si l'utilisateur courant n'y a pas accès via son profil. Pour respecter la FLS en Apex :

• Utiliser WITH USER_MODE dans les requêtes SOQL et opérations DML (disponible depuis API 56+), qui applique automatiquement CRUD et FLS.
• Ou exécuter la classe avec with sharing et le mot-clé stripInaccessible() de la classe Security pour nettoyer les champs non autorisés d'une liste de SObjects avant de les exposer (typiquement en LWC/API).
• Pour les Visualforce et Lightning standards, la FLS est respectée nativement — le problème concerne surtout le code custom.

4. Cas d'usage concrets

1. Données RH sur l'objet User ou un objet custom Employé : salaire, numéro de sécurité sociale masqués à tous sauf au profil RH.
2. Champs de négociation commerciale : marge, coût de revient visibles uniquement par le management via un Permission Set "Vue Marge".
3. Champs système d'intégration : identifiants externes ou clés techniques passés en lecture seule pour tous les profils utilisateurs afin d'éviter une modification accidentelle qui casserait une synchronisation.

5. Outils pour auditer la FLS à grande échelle

Gérer la FLS champ par champ, profil par profil, via l'interface devient vite ingérable au-delà d'une dizaine de profils. Quelques leviers :

• La page Configuration > Utilisateurs > Profils > [Objet] propose une vue "Modifier l'accès aux champs" en tableau croisé, plus rapide pour les revues en masse.
• Le Security Health Check (Configuration > Contrôle d'intégrité) signale certains écarts, mais ne couvre pas la FLS en détail.
• Des outils tiers (Gearset, Elements.cloud) ou un script Metadata API/Apex peuvent exporter la matrice complète FLS pour audit avant une revue de sécurité ou une certification.

Points de vigilance

Migrer vers un modèle de Permission Set Groups plutôt que de multiplier les profils est aujourd'hui la recommandation Salesforce standard : les profils devraient ne porter que le strict socle (type de licence, apps visibles), et toute la granularité FLS/objet doit vivre dans des permission sets composables. Cela facilite grandement l'audit et la maintenance dans le temps, notamment lors des revues de conformité RGPD ou SOC 2.