Le déploiement est la phase la plus redoutée d’un projet Salesforce. Pas parce qu’elle est techniquement complexe — mais parce qu’elle concentre tous les risques accumulés pendant le développement, et qu’une erreur ici touche la production réelle.
J’ai vu des déploiements bloquer pendant des heures parce qu’une validation rule avait été oubliée dans le Change Set. J’ai vu des migrations de données échouer silencieusement parce que le champ cible n’existait pas encore en production. Voici ce que j’ai appris à faire systématiquement.
Change Sets vs SFDX : bien comprendre ce qu’on choisit
Change Sets
- Interface graphique dans Setup
- Pas de prérequis technique
- Idéal pour des petites modifications ciblées
- Gestion manuelle des dépendances
- Pas de contrôle de version natif
- Lent sur les gros volumes de métadonnées
SFDX / CLI
- En ligne de commande + Git
- Contrôle de version natif
- Idéal pour les équipes et projets complexes
- Gestion automatisée des dépendances possible
- Courbe d’apprentissage plus haute
- Reproductible et auditabl
La règle que j’applique : Change Sets pour les corrections rapides et les projets sans équipe de développement dédiée. SFDX dès qu’il y a plusieurs développeurs, un besoin de reproductibilité, ou des déploiements réguliers.
Les erreurs classiques — et comment les éviter
Déployer directement depuis Dev vers Production
C’est l’erreur numéro un. Le sandbox de développement ne ressemble jamais exactement à la production — les données sont différentes, les configurations de profils peuvent diverger, les personnalisations réalisées directement en production (oui, ça existe) ne sont pas dans le sandbox.
La chaîne correcte : Dev → Full Sandbox (ou Partial) → UAT/Staging → Production. Chaque étape filtre les problèmes qui ne seraient pas apparus dans l’étape précédente.
Oublier les dépendances dans le Change Set
Un champ custom sur un objet standard dépend d’un autre champ, d’un record type, d’une validation rule. Oublier un composant dans le Change Set, c’est garantir une erreur de déploiement.
Salesforce vérifie certaines dépendances automatiquement, mais pas toutes. L’habitude à prendre : toujours déployer dans le Full Sandbox avant la production, et vérifier que tout fonctionne avant d’aller plus loin.
Ne jamais déployer un vendredi après-midi. Si quelque chose se passe mal, vous avez soit un weekend d’urgence, soit un lundi matin de crise. Les déploiements risqués se font en début de semaine, avec les équipes disponibles.
Ignorer la couverture de code
Salesforce exige 75% de couverture de code Apex pour déployer en production. Ce seuil est souvent atteint à la limite, avec des tests qui ne testent pas vraiment le comportement du code — juste sa couverture.
Des tests qui couvrent les scénarios réels (bulk, erreurs, cas limites) préviennent les régressions post-déploiement. Des tests qui courent pour la couverture donnent une fausse sécurité.
Ne pas avoir de plan de rollback
Salesforce ne permet pas de "dédéployer" un Change Set. Si un déploiement pose problème, le retour arrière demande soit un nouveau déploiement correctif, soit la suppression manuelle des composants ajoutés.
Avant chaque déploiement significatif : documenter l’état pré-déploiement, lister les composants modifiés, et définir la procédure de rollback si quelque chose se passe mal.
La checklist avant chaque déploiement en production
01
Déployer et valider dans le Full Sandbox
Le Full Sandbox est la réplique la plus proche de la production. Si ça passe ici, les risques en production sont significativement réduits.
02
Vérifier la couverture de code — vraiment
75% minimum, mais viser 85%+ avec des tests qui couvrent les scénarios bulk et les cas d’erreur.
03
Documenter les composants déployés
Liste des objets, champs, classes, workflows, flows inclus dans le déploiement. Indispensable pour le rollback.
04
Prévoir une fenêtre de maintenance
Communiquer aux utilisateurs, bloquer les accès si nécessaire, avoir les équipes techniques disponibles.
05
Valider en production immédiatement après le déploiement
Ne pas partir avant d’avoir vérifié les fonctionnalités critiques sur le système réel.
Pour les équipes qui déploient régulièrement : investir dans SFDX et un pipeline CI/CD (GitHub Actions, Azure DevOps) dès que le volume de déploiements dépasse 2 par mois. Le gain de temps et la réduction des risques le justifient largement.
Salesforce deployment is the most dreaded phase of a project. Not because it's technically complex — but because it concentrates all the risk accumulated during development, and an error here affects real production.
I've seen deployments stall for hours because a validation rule was forgotten in a Change Set. I've seen data migrations fail silently because the target field didn't yet exist in production. Here's what I've learned to do systematically.
Change Sets vs SFDX: understanding what you're choosing
Change Sets
- Graphical interface in Setup
- No technical prerequisites
- Ideal for small targeted changes
- Manual dependency management
- No native version control
- Slow on large metadata volumes
SFDX / CLI
- Command line + Git
- Native version control
- Ideal for teams and complex projects
- Automated dependency management possible
- Higher learning curve
- Reproducible and auditable
The rule I apply: Change Sets for quick fixes and projects without a dedicated development team. SFDX once there are multiple developers, a reproducibility requirement, or regular deployments.
Classic mistakes — and how to avoid them
Deploying directly from Dev to Production
This is mistake number one. The development sandbox never exactly resembles production — data differs, profile configurations can diverge, customisations made directly in production (yes, it happens) aren't in the sandbox. The correct chain: Dev → Full Sandbox (or Partial) → UAT/Staging → Production. Each step filters problems that wouldn't have appeared in the previous one.
Forgetting dependencies in the Change Set
A custom field on a standard object depends on another field, a record type, a validation rule. Forgetting a component in the Change Set guarantees a deployment error. Salesforce checks some dependencies automatically, but not all. The habit to build: always deploy to the Full Sandbox before production, and verify everything works before going further.
Never deploy on a Friday afternoon. If something goes wrong, you either have an emergency weekend or a crisis Monday. Risky deployments happen early in the week, with teams available.
Ignoring code coverage
Salesforce requires 75% Apex code coverage to deploy to production. This threshold is often barely reached, with tests that don't really test code behaviour — just coverage. Tests that cover real scenarios (bulk, errors, edge cases) prevent post-deployment regressions. Tests that run for coverage give false security.
Having no rollback plan
Salesforce doesn't allow "undeploying" a Change Set. If a deployment causes problems, rolling back requires either a new corrective deployment or manually deleting added components. Before every significant deployment: document the pre-deployment state, list modified components, and define the rollback procedure if something goes wrong.
The checklist before every production deployment
01
Deploy and validate in the Full Sandbox
The Full Sandbox is the closest replica to production. If it passes here, risks in production are significantly reduced.
02
Check code coverage — really
75% minimum, but aim for 85%+ with tests covering bulk scenarios and error cases.
03
Document deployed components
List of objects, fields, classes, workflows, flows included in the deployment. Essential for rollback.
04
Plan a maintenance window
Communicate to users, restrict access if necessary, have technical teams available.
05
Validate in production immediately after deployment
Don't leave before verifying critical features on the real system.
For teams deploying regularly: invest in SFDX and a CI/CD pipeline (GitHub Actions, Azure DevOps) once deployment volume exceeds 2 per month. The time saving and risk reduction justify it easily.