Le Développement Piloté par la Source dans Salesforce, Expliqué

Le développement piloté par la source dans Salesforce signifie que votre dépôt Git, et non l'org, est l'unique source de vérité. Chaque changement existe comme un fichier versionné, chaque déploiement remonte à un commit, et votre pipeline reconstruit les environnements depuis cette source au lieu de cliquer la metadata d'un org à l'autre à la main. C'est le modèle autour duquel Salesforce DX a été conçu, et en 2026 c'est l'hypothèse par défaut derrière presque tout processus de release sérieux.

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

Dans l'approche classique, l'org est traité comme la source de vérité. Vous faites des changements dans une sandbox, les regroupez dans un change set et les poussez, en espérant que rien ne dérive en chemin. Le développement piloté par la source inverse cela. Votre metadata vit sous forme de fichiers dans le gestionnaire de versions, et l'org devient un rendu de ce que le dépôt dit qu'il devrait être. Comme le précise la documentation DX de Salesforce, le suivi de source observe ce que vous créez, modifiez ou supprimez pour que le dépôt et l'org restent honnêtes l'un envers l'autre.

Le gain, c'est la traçabilité. Chaque changement en production est lié à un commit précis, la revue de code a lieu avant le merge, et vous obtenez une piste d'audit complète gratuitement. Cette gouvernance n'est pas un luxe dans un org Salesforce réglementé ; c'est la raison pour laquelle le développement piloté par la source a gagné.

En quoi diffère-t-il du modèle org development ?

Salesforce fournit deux modèles de développement, et la différence tient surtout au suivi de source :

• Modèle org development : vous travaillez sur des orgs qui ne suivent pas la source, comme la production, les orgs Developer Edition ou les sandboxes non suivies. Vous indiquez à la main ce que vous récupérez et déployez.
• Modèle piloté par la source (package) : vous travaillez sur des orgs à suivi de source, surtout des scratch orgs et des sandboxes à suivi de source. Salesforce DX suit les changements des deux côtés automatiquement, et sf project deploy start ou sf project retrieve start ne déplacent que ce qui a réellement changé.

La plupart des équipes se situent entre les deux. C'est très bien. Mais la direction va vers le suivi de source et loin des change sets manuels, le même virage que nous décortiquons dans pourquoi chaque outil DevOps Salesforce ignore le développement de packages.

Pourquoi le source format a-t-il tout changé ?

Le développement piloté par la source ne fonctionne que grâce au source format. L'ancien metadata format entasse un objet personnalisé entier, ses champs, ses règles de validation et ses vues de liste dans un seul long fichier XML. Le source format le décompose en petits fichiers modulaires, un par composant, sous une structure de dossiers hiérarchique. Le résultat, comme le documente Gearset, ce sont des diffs plus propres et beaucoup moins de conflits de merge : deux développeurs modifiant des champs différents du même objet ne se heurtent plus, car leurs changements vivent dans des fichiers séparés. Le source format est désormais le défaut recommandé par Salesforce pour les nouveaux projets.

Où le développement piloté par la source coince-t-il encore ?

Voici la partie que la plupart des explications sautent. Le source format ne décompose pas tout. Les profiles, permission sets, sharing rules, workflows et external services atterrissent toujours dans de gros fichiers partagés, donc deux personnes modifiant le même profile se battront encore dans le gestionnaire de versions. Le suivi de source ne couvre pas non plus tous les types de metadata ; vous devez consulter le Metadata Coverage Report pour savoir ce qui est réellement suivi, et ce sont ces lacunes qui brûlent les équipes.

Les scratch orgs rendent cela plus propre en théorie, mais les vrais orgs portent des années de configuration qui n'ont jamais vécu dans Git. Passer au piloté par la source est une migration, pas un interrupteur, et le coût de ne pas franchir ce pas ressurgit à chaque release, exactement le calcul que nous faisons dans le vrai coût des déploiements Salesforce manuels. Un outillage conçu pour réconcilier ces bords désordonnés, plutôt que de supposer un projet greenfield, sépare un pipeline qui marche d'une démo.

Comment adopter concrètement le développement piloté par la source ?

1. Mettez votre metadata dans Git en source format. Récupérez depuis votre org existant, convertissez en source format et committez. C'est votre nouvelle base de référence.
2. Choisissez un modèle de branching qui correspond à vos orgs, pour que chaque environnement soit constructible depuis une branche.
3. Activez le suivi de source où c'est possible, avec des sandboxes à suivi de source et des scratch orgs pour le travail de fonctionnalité.
4. Automatisez les déploiements depuis les commits, pour que rien n'atteigne la production sauf via un changement revu et versionné.
5. Anticipez les types non décomposés, en décidant qui possède les profiles et permission sets avant qu'ils ne causent des conflits.

Un pipeline qui traite Git comme la source de vérité, suit les changements avec précision et gère la metadata que Salesforce ne décompose pas entièrement, c'est précisément ce que Serpent a été conçu pour faire tourner. La stack open source peut aussi vous y mener, et nous lui donnons une lecture honnête dans notre regard sur sfdx-hardis.

FAQ

Le développement piloté par la source est-il la même chose que Salesforce DX ?

Non. Salesforce DX est l'outillage et le format ; le développement piloté par la source est la pratique consistant à faire de votre dépôt Git, et non de l'org, la source de vérité.

Ai-je besoin de scratch orgs pour le développement piloté par la source ?

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

Le source format élimine-t-il les conflits de merge ?

Il les réduit fortement en donnant à chaque composant son propre fichier, mais les profiles, permission sets et quelques autres types partagent encore de gros fichiers et peuvent entrer en conflit.

Puis-je mélanger développement piloté par la source et change sets ?

Vous le pouvez pendant une transition, mais l'objectif est de retirer les change sets manuels pour que chaque changement soit versionné, revu et traçable jusqu'à un commit.