Change Sets vs déploiements par outils DevOps

Déployer des changements de configuration d'une sandbox vers la production reste l'un des exercices les plus délicats de l'administration Salesforce. Deux approches coexistent : les Change Sets natifs, simples mais limités, et les pipelines DevOps basés sur Git et Salesforce CLI, plus robustes mais plus exigeants à mettre en place.

Change Sets : le déploiement natif

Les Change Sets (Configuration > Ensembles de modifications sortants) permettent de sélectionner des composants de métadonnées dans une organisation source et de les envoyer vers une organisation cible connectée par un lien de déploiement (typiquement sandbox vers production, ou entre sandbox liées à la même production).

• Avantages : aucun outil externe requis, interface graphique accessible à un administrateur sans compétences techniques, adapté aux petites équipes et aux déploiements ponctuels.
• Limites : pas de contrôle de version (pas d'historique ni de diff), sélection manuelle des composants sujette à l'oubli de dépendances, pas de possibilité de revenir en arrière automatiquement, uniquement entre organisations liées (impossible par exemple entre deux sandbox indépendantes), pas de tests automatisés intégrés au processus.

Le déploiement DevOps : Git + Salesforce CLI

Une approche DevOps repose sur un repository Git comme source de vérité, le Salesforce CLI (ou sf) pour récupérer et déployer les métadonnées, et généralement une plateforme d'intégration continue (GitHub Actions, GitLab CI, Azure DevOps, Bitbucket Pipelines, ou l'offre native Salesforce DevOps Center).

1. Chaque développement est fait dans une branche dédiée, reflétée par une sandbox ou une scratch org éphémère.
2. Une Pull Request déclenche une validation automatique : déploiement de contrôle (--dry-run), exécution des tests Apex, vérification de la couverture de code.
3. Après revue et fusion, le pipeline déploie automatiquement vers l'environnement suivant (recette, puis production), avec traçabilité complète de qui a déployé quoi et quand.
4. Un rollback est possible en revenant à un commit antérieur, ce qui est structurellement impossible avec les Change Sets.

Comparatif synthétique

Critère	Change Sets	Pipeline DevOps
Historique / traçabilité	Aucun	Complet (Git)
Tests automatisés	Non	Oui, intégrés au pipeline
Rollback	Manuel, difficile	Automatisable
Courbe d'apprentissage	Faible	Élevée au démarrage
Adapté à	Petites équipes, orgs simples	Équipes multiples, releases fréquentes

Le DevOps Center : un pont entre les deux mondes

Salesforce DevOps Center mérite une mention à part : c'est un outil natif (gratuit) qui apporte une interface visuelle proche des Change Sets, mais avec un vrai repository Git en arrière-plan et un suivi des « work items » façon ticket. C'est souvent le point d'entrée idéal pour une équipe qui souhaite migrer des Change Sets vers une démarche DevOps sans adopter immédiatement toute la complexité d'un pipeline CI/CD custom.

Ne migrez pas vers un pipeline DevOps complet sans avoir d'abord structuré votre stratégie de branches et votre stratégie de sandbox (voir article dédié). Un pipeline sophistiqué sur une organisation Git en désordre amplifie le chaos plutôt que de le résoudre.

Quand choisir quoi

• Une petite organisation avec un seul administrateur et des changements peu fréquents peut légitimement continuer avec les Change Sets, en étant rigoureuse sur la documentation manuelle des déploiements.
• Dès qu'il y a plusieurs développeurs, plusieurs sandbox en parallèle, ou du code Apex avec des tests à maintenir, un pipeline DevOps devient rapidement rentable malgré l'investissement initial.
• La bascule ne se fait pas du jour au lendemain : commencez par versionner vos métadonnées dans Git en parallèle des Change Sets existants, avant de basculer progressivement les déploiements réels vers le pipeline.

Le choix entre ces deux approches n'est pas binaire ni définitif : il doit refléter la maturité réelle de votre équipe et la fréquence de vos cycles de changement.