Gerer profils et permission sets dans le controle de source

Reponse courte : placez les permission sets sous controle de source comme veritable source de verite, decomposez-les pour que deux personnes puissent les modifier sans conflit de fusion, gardez les profils minces et traitez chaque deploiement de profil comme une superposition et non un remplacement complet. Ensuite, cessez volontairement de suivre ce qui depend de l'environnement, car l'essentiel du bruit des profils dans un depot n'est lu par personne.

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

Deux comportements documentes rendent les profils differents de tout autre fichier du depot.

• Une recuperation depend du contexte. Le fichier .profile renvoye ne contient que les parametres de securite des autres types de metadonnees cites dans la meme requete. 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 deploiement est une superposition. Les permissions absentes du fichier ne sont pas retirees dans l'org cible, et desactiver une permission exige d'ecrire explicitement la valeur false dans le XML. Une ligne manquante signifie "pas d'avis", pas "desactive".

Combinez les deux et le meme profil produit un diff different selon qui l'a recupere et ce qu'il y avait d'autre dans son paquet. Voila pourquoi les diffs de profils sont les fichiers les plus discutes et les moins fiables de la plupart des depots Salesforce.

Qu'est-ce qui a change en 2026, et cela change-t-il la strategie ?

Salesforce avait annonce le retrait des permissions dans les profils a partir de Spring '26. Le 6 juin 2026, cette application a ete annulee, au motif des retours clients et de fonctionnalites encore manquantes, Salesforce continuant de recommander un modele de securite mene par les permission sets (aide Salesforce).

Lecture pratique : l'echeance a disparu, la direction non. Les profils restent pris en charge, donc aucune migration precipitee, mais si vous devez choisir ou investir votre discipline de gestion de sources, investissez-la dans les permission sets. Ils sont additifs, ils se decomposent et ils fusionnent.

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

Un permission set recupere 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 meme fichier. Salesforce livre un remede dans la CLI : des options de comportement de source qui decoupent le fichier en un fichier par groupe de permissions (guide developpeur Salesforce DX).

1. Commitez tout d'abord. L'operation reecrit des fichiers sur disque, partez donc d'un arbre propre.
2. Lancez un essai a blanc : sf project convert source-behavior --behavior decomposePermissionSetBeta2 --dry-run.
3. Lancez pour de vrai. Votre sfdx-project.json est mis a jour pour que le comportement s'applique a 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 melange conversion de format et vraies modifications.

Le meme mecanisme couvre les etiquettes personnalisees, les workflows, les regles de partage et les enregistrements de services externes. Notez la lacune : les profils ne figurent pas dans la liste des types decomposables. Objets et traductions d'objets se decomposent par defaut, le reste est en beta optionnelle, et les profils restent un seul fichier.

Que faut-il cesser de suivre ?

La moitie de la douleur est auto-infligee. Ceci a sa place hors du depot, ou derriere une exclusion assumee.

• Les permissions des packages geres. 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 fantomes permanents.
• Plages d'IP et heures de connexion. C'est en general une politique d'environnement, pas du contenu de release, et cela differe legitimement entre sandbox et production.
• Les affectations de permission sets. Ce sont des enregistrements, pas des metadonnees. Qui possede quel ensemble releve des donnees, donc d'une etape d'amorcage, pas de Git.
• Les permissions d'objets standard que vous ne comptez jamais modifier. Si votre processus ne les gere pas, les recuperer n'ajoute que du volume de diff.
• Les profils que vous ne deployez pas. La plupart des orgs trainent des profils herites que personne n'a touches depuis des annees. Suivez ceux que votre pipeline promeut reellement.

Ecrivez ces exclusions comme une regle dans le depot, pas comme un savoir tribal dans l'historique CLI d'une seule personne. Une regle logee dans l'alias shell de quelqu'un casse des la premiere recuperation d'un nouvel arrivant.

Comment deplacer les permissions des profils vers les permission sets sans casse ?

1. Choisissez un profil et inventoriez ce qu'il accorde reellement en production, pas dans la sandbox ou il a derive.
2. Creez des permission sets par tache, pas par intitule de poste. Les ensembles orientes tache sont reutilises ; ceux orientes intitule sont dupliques a chaque nouveau titre.
3. Affectez les nouveaux ensembles a cote du profil, sans rien changer d'autre. L'acces est additif, personne ne perd quoi que ce soit a ce stade.
4. Retirez les permissions deplacees du profil dans une release distincte, avec des valeurs false explicites pour que le deploiement les desactive vraiment.
5. Verifiez avec un utilisateur de ce profil dans une sandbox, et conservez l'instantane des permissions d'avant tant que ce n'est pas fait.

Ne faites jamais les etapes trois et quatre dans la meme release. Les changements additifs et soustractifs de permissions n'ont pas du tout le meme scenario de retour arriere, et les melanger, c'est ainsi qu'on se retrouve bloque un lundi matin. D'autres guides d'ingenierie de release sont dans notre bibliotheque SF Guides.

FAQ

Profils ou permission sets comme source de verite ?

Les permission sets. Ils sont additifs, se decomposent en fichiers fusionnables, et Salesforce recommande un modele mene par les permission sets. Gardez les profils pour les valeurs de base : licence, types d'enregistrement par defaut, mises en page.

Les permissions dans les profils sont-elles retirees ?

Non. Le retrait prevu pour Spring '26 a ete annule le 6 juin 2026. La migration suit desormais votre calendrier, pas une echeance.

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

Parce qu'une recuperation de profil ne renvoie que les parametres des metadonnees presentes dans la meme requete. Changez le contenu du paquet et le fichier change. Corrigez le manifeste de recuperation, pas le fichier.

Les profils peuvent-ils etre decomposes comme les permission sets ?

Pas aujourd'hui. Les options de comportement de source couvrent permission sets, etiquettes personnalisees, workflows, regles de partage et services externes. Les profils restent un fichier, argument de plus pour les garder minces.