Le développement piloté par la source dans Salesforce, expliqué

La définition d'abord : le développement piloté par la source est le modèle où votre dépôt Git, et aucune org, fait autorité sur la configuration et le code Salesforce. Les orgs deviennent des environnements jetables vers lesquels vous déployez depuis le dépôt, plutôt que des endroits entre lesquels vous copiez des changements. Tout le reste de ce guide découle de cette phrase.

Qu'est-ce que le développement piloté par la source dans Salesforce ?

Dans ce modèle, chaque changement arrive d'abord dans le contrôle de version et seulement ensuite dans une org. Le dépôt contient l'état voulu de l'org. Un déploiement est l'acte de rendre une org conforme à cette intention.

Trois propriétés pratiques l'accompagnent :

• Historique. Chaque changement porte un auteur, une date et une raison.
• Réversibilité. Revenir en arrière consiste à déployer un état connu comme bon, pas à le reconstruire de mémoire.
• Parallélisme. Deux personnes peuvent travailler sur le même objet sans que l'une écrase silencieusement l'autre, parce que la fusion est explicite.

En quoi cela diffère-t-il du déploiement d'org à org ?

Le déploiement d'org à org, par change sets ou par comparaison directe de deux orgs, prend une org vivante comme référence. C'est la vraie distinction, et elle a des conséquences.

• Où vit la vérité. Org à org : l'org source. Piloté par la source : la branche.
• Ce qu'est une release. Org à org : une liste de composants assemblée par une personne. Piloté par la source : un diff entre deux commits.
• L'historique obtenu. Org à org : ce que le journal de déploiement a bien voulu garder. Piloté par la source : tout l'historique, pour toujours.
• Le retour arrière. Org à org : reconstruire l'état précédent à la main. Piloté par la source : déployer le commit précédent.
• Qui peut auditer. Org à org : qui possède un accès admin. Piloté par la source : quiconque peut lire le dépôt, y compris des auditeurs qui ne devraient jamais toucher la production.

Notez ce qui n'est pas dans cette liste : la vitesse. Ce modèle n'est pas automatiquement plus rapide. Il est reproductible, ce qui est une propriété différente et plus durable.

Qu'est-ce que le source tracking et où fonctionne-t-il ?

Le source tracking est la fonction de la plateforme qui enregistre quels composants ont changé dans une org ou dans votre projet local depuis la dernière synchronisation, afin de ne récupérer que ce qui a réellement bougé au lieu de tout retirer et de lire un diff.

La limite que l'on rencontre est la couverture. Le source tracking est disponible dans les scratch orgs et dans les sandboxes Developer et Developer Pro. Il ne l'est pas partout, donc un modèle piloté par la source doit répondre pour les environnements incapables de suivre les changements : sandboxes full, copies partielles et production. Ce sont exactement les orgs où naissent les changements non documentés.

Source format ou metadata format : que commite-t-on ?

On commite le source format. Les deux formats décrivent les mêmes métadonnées différemment :

• Le metadata format est la forme de la Metadata API : de gros fichiers par objet plus un manifeste package.xml. Modifier un champ réécrit un gros fichier, donc le diff embarque tout l'objet et la revue devient bruyante.
• Le source format décompose cette structure : chaque champ, règle de validation et vue de liste obtient son propre fichier dans une arborescence, avec les répertoires de package déclarés dans sfdx-project.json.

L'effet porte sur la revue et la fusion, pas sur la fonction. De petits fichiers donnent des diffs lisibles et bien moins de conflits quand deux personnes touchent le même objet, et c'est précisément la situation que ce modèle existe pour survivre.

Le source format ne décompose pas tout pour autant. Les profiles, permission sets et sharing rules atterrissent toujours dans de gros fichiers partagés, donc deux personnes qui modifient le même profile peuvent encore entrer en conflit. Décidez qui possède ces fichiers avant de migrer. Le source tracking ne couvre pas non plus tous les types de métadonnées : consultez le Metadata Coverage Report avant de supposer qu'un type est suivi.

Que faire quand l'org et le dépôt divergent ?

C'est la question que la plupart des explications évitent, et celle qui décide si le modèle survit au contact d'une vraie équipe Salesforce. Quelqu'un modifiera toujours quelque chose en production : un correctif à minuit, un admin qui ajoute une valeur de liste, une mise à jour de package qui réécrit des métadonnées que vous aviez commitées.

Tranchez ces trois points avant la migration, pas après :

1. Qui gagne. Le dépôt gagne, par politique. Un changement hors circuit n'est donc pas "perdu" mais réconcilié : récupéré, commité avec une explication, puis redéployé depuis la branche.
2. Comment vous l'apprenez. Faites tourner une détection de dérive contre la production selon un calendrier. Découvrir la divergence au moment de la release, c'est la découvrir trop tard.
3. Ce qui est volontairement hors périmètre. Certaines métadonnées sont réellement propres à l'environnement ou appartiennent à un package installé. Écrivez cette liste d'exclusions. Une liste honnête vaut mieux qu'un dépôt que tout le monde soupçonne en silence.

Comment adopter cela sans équipe à l'aise avec Git ?

La plupart des équipes Salesforce sont des admins et des consultants, pas des utilisateurs de CLI, et c'est là que les migrations calent. Ordonnez les étapes pour que personne n'ait à apprendre Git pour continuer à travailler :

1. Commencez par une frontière de package. Une équipe, un jeu de métadonnées. N'essayez pas de commiter toute l'org la première semaine.
2. Récupérez en source format et obtenez un déploiement propre de ce périmètre vers une sandbox avant que quiconque change ses habitudes.
3. Mettez une porte devant la production. Même une approbation manuelle sur une branche compte. Une vérité sans porte dérive en un mois.
4. Gardez l'interface quotidienne familière. Les admins continuent de travailler dans un ticket ou un work item ; commit, branche et fusion doivent se produire en dessous.
5. Ajoutez la détection de dérive en dernier. Une fois le pipeline crédible, elle vous dit où le modèle fuit.

Encore sur les change sets ? Commencez par passer des change sets au contrôle de source, puis automatisez la livraison avec une pipeline CI/CD Salesforce sur GitHub Actions. Ou laissez-nous mener la migration avec vous.

FAQ

Faut-il que chaque admin apprenne Git ?

Non. Il faut que le dépôt fasse autorité. Qui manipule Git directement est un choix d'outillage, pas une propriété du modèle.

Faut-il convertir toute l'org en source format d'un coup ?

Non. Convertissez par frontière de package ou par équipe. Un dépôt partiel réellement faisant autorité sur son périmètre vaut mieux qu'un dépôt complet auquel personne ne se fie.

Est-ce la même chose que le CI/CD ?

Non. Le modèle piloté par la source décide où vit la vérité. Le CI/CD automatise son transport vers les orgs. Le premier peut exister sans le second, l'inverse n'a guère de sens.

Et les métadonnées non versionnables ?

Certains paramètres et composants appartenant à un package ne font pas l'aller-retour proprement. Documentez-les comme exclus et pilotez-les par procédure au lieu de prétendre que le dépôt les couvre.

Est-ce la même chose que Salesforce DX ?

Non. Salesforce DX est l'outillage et le format de fichiers ; le développement piloté par la source est la pratique qui fait du dépôt, et non de l'org, la source de vérité.

Faut-il des scratch orgs pour adopter ce modèle ?

Non. Les scratch orgs aident, mais les sandboxes avec source tracking le prennent aussi en charge, donc vous pouvez adopter le modèle sans workflow scratch org complet.

Serpent est conçu pour exactement l'équipe décrite ici : le dépôt reste la source de vérité pendant que les admins et consultants travaillent dans des tickets, avec déploiements delta, détection de dérive et retour arrière en un clic par-dessus. D'autres guides de référence sont dans SF Guides.