Gérer profils et permission sets dans le contrôle de source

Réponse courte : placez les permission sets sous contrôle de source comme véritable source de vérité, décomposez-les pour que deux personnes puissent les modifier sans conflit de fusion, gardez les profils minces et traitez chaque déploiement de profil comme une superposition et non un remplacement complet. Ensuite, cessez volontairement de suivre ce qui dépend de l'environnement, car l'essentiel du bruit des profils dans un dépôt n'est lu par personne.

Pourquoi les profils sont-ils si difficiles à garder dans Git ?

Deux comportements documentés rendent les profils différents de tout autre fichier du dépôt.

• Une récupération dépend du contexte. Le fichier .profile renvoyé ne contient que les paramètres de sécurité des autres types de métadonnées cités dans la même requête. Demandez le profil seul et vous n'obtenez presque rien ; demandez-le avec 40 objets et vous obtenez un autre fichier (documentation de l'API Metadata).
• Un déploiement est une superposition. Les permissions absentes du fichier ne sont pas retirées dans l'org cible, et désactiver une permission exige d'écrire explicitement la valeur false dans le XML. Une ligne manquante signifie "pas d'avis", pas "désactivé".

Combinez les deux et le même profil produit un diff différent selon qui l'a récupéré et ce qu'il y avait d'autre dans son paquet. Voilà pourquoi les diffs de profils sont les fichiers les plus discutés et les moins fiables de la plupart des dépôts Salesforce.

Qu'est-ce qui a changé en 2026, et cela change-t-il la stratégie ?

Salesforce avait annoncé le retrait des permissions dans les profils à partir de Spring '26. Le 6 juin 2026, cette application a été annulée, au motif des retours clients et de fonctionnalités encore manquantes, Salesforce continuant de recommander un modèle de sécurité mené par les permission sets (aide Salesforce).

Lecture pratique : l'échéance a disparu, la direction non. Les profils restent pris en charge, donc aucune migration précipitée, mais si vous devez choisir où investir votre discipline de gestion de sources, investissez-la dans les permission sets. Ils sont additifs, ils se décomposent et ils fusionnent.

Comment décomposer les permission sets pour qu'ils cessent d'entrer en conflit ?

Un permission set récupéré est un gros fichier XML listant chaque permission d'objet, de champ et d'utilisateur. Deux administrateurs travaillant sur deux champs sans rapport entrent en collision dans le même fichier. Salesforce livre un remède dans la CLI : des options de comportement de source qui découpent le fichier en un fichier par groupe de permissions (guide développeur Salesforce DX).

1. Commitez tout d'abord. L'opération réécrit des fichiers sur disque, partez donc d'un arbre propre.
2. Lancez un essai à blanc : sf project convert source-behavior --behavior decomposePermissionSetBeta2 --dry-run.
3. Lancez pour de vrai. Votre sfdx-project.json est mis à jour pour que le comportement s'applique à tous, et la source existante est convertie sur place.
4. Commitez la conversion sur sa propre branche, sans aucune modification fonctionnelle. Personne ne peut relire un diff qui mélange conversion de format et vraies modifications.

Le même mécanisme couvre les étiquettes personnalisées, les workflows, les règles de partage et les enregistrements de services externes. Notez la lacune : les profils ne figurent pas dans la liste des types décomposables. Objets et traductions d'objets se décomposent par défaut, le reste est en bêta optionnelle, et les profils restent un seul fichier.

Que faut-il cesser de suivre ?

La moitié de la douleur est auto-infligée. Ceci a sa place hors du dépôt, ou derrière une exclusion assumée.

• Les permissions des packages gérés. Les permissions d'objets et de champs avec espace de noms apparaissent et disparaissent selon les versions de package dans chaque org. Les suivre garantit des diffs fantômes permanents.
• Plages d'IP et heures de connexion. C'est en général une politique d'environnement, pas du contenu de release, et cela diffère légitimement entre sandbox et production.
• Les affectations de permission sets. Ce sont des enregistrements, pas des métadonnées. Qui possède quel ensemble relève des données, donc d'une étape d'amorçage, pas de Git.
• Les permissions d'objets standard que vous ne comptez jamais modifier. Si votre processus ne les gère pas, les récupérer n'ajoute que du volume de diff.
• Les profils que vous ne déployez pas. La plupart des orgs traînent des profils hérités que personne n'a touchés depuis des années. Suivez ceux que votre pipeline promeut réellement.

Écrivez ces exclusions comme une règle dans le dépôt, pas comme un savoir tribal dans l'historique CLI d'une seule personne. Une règle logée dans l'alias shell de quelqu'un casse dès la première récupération d'un nouvel arrivant.

Comment déplacer les permissions des profils vers les permission sets sans casse ?

1. Choisissez un profil et inventoriez ce qu'il accorde réellement en production, pas dans la sandbox où il a dérivé.
2. Créez des permission sets par tâche, pas par intitulé de poste. Les ensembles orientés tâche sont réutilisés ; ceux orientés intitulé sont dupliqués à chaque nouveau titre.
3. Affectez les nouveaux ensembles à côté du profil, sans rien changer d'autre. L'accès est additif, personne ne perd quoi que ce soit à ce stade.
4. Retirez les permissions déplacées du profil dans une release distincte, avec des valeurs false explicites pour que le déploiement les désactive vraiment.
5. Vérifiez avec un utilisateur de ce profil dans une sandbox, et conservez l'instantané des permissions d'avant tant que ce n'est pas fait.

Ne faites jamais les étapes trois et quatre dans la même release. Les changements additifs et soustractifs de permissions n'ont pas du tout le même scénario de retour arrière, et les mélanger, c'est ainsi qu'on se retrouve bloqué un lundi matin. D'autres guides d'ingénierie de release sont dans notre bibliothèque SF Guides.

FAQ

Profils ou permission sets comme source de vérité ?

Les permission sets. Ils sont additifs, se décomposent en fichiers fusionnables, et Salesforce recommande un modèle mené par les permission sets. Gardez les profils pour les valeurs de base : licence, types d'enregistrement par défaut, mises en page.

Les permissions dans les profils sont-elles retirées ?

Non. Le retrait prévu pour Spring '26 a été annulé le 6 juin 2026. La migration suit désormais votre calendrier, pas une échéance.

Pourquoi mon diff de profil change-t-il alors que je n'y ai pas touché ?

Parce qu'une récupération de profil ne renvoie que les paramètres des métadonnées présentes dans la même requête. Changez le contenu du paquet et le fichier change. Corrigez le manifeste de récupération, pas le fichier.

Les profils peuvent-ils être décomposés comme les permission sets ?

Pas aujourd'hui. Les options de comportement de source couvrent permission sets, étiquettes personnalisées, workflows, règles de partage et services externes. Les profils restent un fichier, argument de plus pour les garder minces.