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.
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.
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.
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.
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é.
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.
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.
Le cadrage est gratuit et sans engagement. 30 minutes pour définir le périmètre et valider la faisabilité.
Contact →