Refactorer une org Salesforce legacy sans casser la prod
Vous avez hérité d'une org Salesforce de 10 ans et tout est fragile. La tentation est de refondre. La bonne réponse est presque toujours de refactorer, dans un ordre précis qui garde le business en marche.
Vous avez hérité d'une org Salesforce en vie depuis dix ans. 400 champs custom par compte, trois automatisations qui se chevauchent à chaque save, et une classe Apex nommée ProcessStuff que personne n'ose toucher. La tentation est de déclarer faillite et de refondre. La bonne réponse est presque toujours de refactorer, mais dans un ordre précis qui garde le business en marche.
Refonte vs refactor : le check honnête
Refonte seulement si deux de ces critères sont vrais : le modèle d'objets est fondamentalement faux, plus de 60 % du code est mort ou mal utilisé, ou le sponsor a du capital politique frais. Sinon, refactor. Les refontes coûtent 3x plus et portent 3x le risque d'adoption.
L'ordre de refactor qui marche
- Geler la nouvelle customisation pendant 4 semaines. Rien de neuf tant que la baseline n'est pas comprise.
- Scorer la dette technique. Passer les 8 indicateurs. C'est votre carte.
- Supprimer avant de refactorer. Chaque champ, rapport, Flow, classe Apex inutilisée supprimée = une chose de moins à migrer.
- Consolider l'automatisation. Migrer Process Builder et Workflows vers Flow, un objet à la fois. Voir notre playbook Flow.
- Reconstruire le modèle d'objets chirurgicalement. Uniquement là où c'est vraiment faux. Introduire de nouveaux objets custom plutôt que remodeler les standards en place.
- Réécrire l'Apex en dernier. Classes simples d'abord, monolithes complexes en dernier, avec couverture à chaque étape.
Le pattern « à côté »
Refactorer une org en prod veut rarement dire « stop et refonte ». Ça veut dire : construire la nouvelle version à côté de l'ancienne, dual-write pendant que les deux tournent, migrer les utilisateurs quand le nouveau chemin est prouvé, retirer l'ancien artefact.
Le jeu de tests de régression obligatoire
Avant chaque étape : capturer le top 20 des rapports (screenshot + nombre de lignes), les 10 chemins Flow principaux (entrée → sortie attendue), et la réponse API des 5 intégrations principales. Re-jouer après chaque changement. Cette seule habitude évite 80 % des incidents de prod.
Quand appeler à l'aide
- Vous êtes le seul à connaître l'org.
- La doc d'origine n'existe pas.
- Chaque déploiement prend des heures et échoue une fois sur deux.
- Le sponsor perd patience face à « pas de progrès visible ».
Deux critères = alerte rouge. Trois = conversation rescue. Voir notre guide rescue.
Notes régionales
- UE : si le refactor change les flux de données, rafraîchir le registre des traitements. Voir guide RGPD.
- États-Unis & Canada : aligner les vagues sur les cycles SOC 2.
Questions fréquentes
Combien de temps ?
Petite org : 2-3 mois. Mid-market : 4-8 mois. Grand compte complexe : 9-18 mois par phases.
Refactor pendant qu'on livre du neuf ?
Oui, mais plafonnez le neuf à 20 % de la capa dev pendant le refactor.
Comment le vendre au board ?
Traduire la dette en risque : proba d'outage, heures perdues en workarounds, taxe sur la précision du forecast.
Faut-il tout geler ?
Pas tout, seulement le neuf pendant la baseline. Bug fixes et conformité sortent normalement.
Cadrer un refactor au forfait
Notre audit Salesforce se termine par une roadmap de refactor : quoi supprimer, quoi migrer, quoi laisser tranquille, par phases. Réservez un appel de 30 minutes.
Si ça ressemble à votre CRM, regardons-le ensemble.
Trente minutes, sans slides, sans pitch commercial. Vous repartez avec un diagnostic dans tous les cas.