Vous héritez d’une instance Salesforce qui a 8, 10, parfois 15 ans. Vous y trouvez des objets custom oubliés, des Workflow Rules empilées sur des Process Builder eux-mêmes empilés sur des Flows, des permissions sets clones de profils clones de rôles, des champs « Old__c », « TempField__c », « DoNotUse__c », des règles de validation qui se contredisent, du code Apex que personne n’a écrit récemment et que personne ne comprend.
Bienvenue dans la vraie vie d’une instance Salesforce mature. La question n’est pas « est-ce qu’il faut refactorer », c’est « comment faire sans tout casser ».
Pourquoi refactorer
- Performance dégradée : trop de Flows déclenchés simultanément, requêtes lentes, gouverneurs Salesforce atteints.
- Adoption en chute : interface devenue illisible avec trop de champs, layouts surchargés, navigation confuse.
- Risque sécurité : permissions accumulées, accès oubliés, sharing model dérivé. Voir notre article Responsabilité partagée Salesforce.
- Coût d’évolution prohibitif : ajouter une fonctionnalité demande 3x plus de temps qu’avant à cause de la dette technique.
- Risque RGPD : objets oubliés contenant des données personnelles, durées de conservation pas appliquées. Voir notre checklist RGPD.
La méthode en 5 étapes
Étape 1 — Diagnostic complet
Avant de refactorer, comprendre. Sortir un état des lieux objectif :
- Inventaire des objets custom : utilisés ? volume ? dernier accès ?
- Inventaire des champs custom par objet : remplis à plus de 5 % ? utilisés dans des rapports ? dans des Flows ?
- Inventaire des automations (Workflow Rules, Process Builder, Flows, Apex Triggers) : qui fait quoi, qui se déclenche, qui rentre en conflit ?
- Inventaire des profiles, permission sets, permission set groups : permission sprawl, doublons, droits oubliés.
- Inventaire des connected apps. Voir notre méthode.
- Apex code : couverture de test, complexité, dépendances.
Le diagnostic prend 1 à 3 semaines selon la taille de l’org. Il produit un rapport priorisé.
Étape 2 — Quick wins (semaines 4-6)
- Désactiver les Workflow Rules redondants ou obsolètes (en commençant par ceux jamais déclenchés depuis 6 mois).
- Supprimer les champs custom non utilisés (volume = 0 ou non référencés dans des Flows / rapports).
- Désactiver les Profiles non utilisés.
- Révoquer les permission sets non assignés depuis 12 mois.
- Supprimer les rapports / dashboards obsolètes.
Ces quick wins ne cassent rien et libèrent immédiatement de la complexité.
Étape 3 — Migration des automations
Workflow Rules → Flow. Process Builder → Flow. Apex Triggers anciens → Flow ou Apex modernisé. Salesforce a annoncé la fin de vie de Workflow Rules et Process Builder — c’est inévitable.
Approche : un objet à la fois, un Flow consolidé qui remplace les multiples automations. Tests rigoureux sur sandbox avant production.
Étape 4 — Modernisation UI et UX
- Refonte des layouts Lightning par persona.
- Migration Aura → LWC pour les composants custom.
- Simplification des record types et page layouts qui se sont accumulés.
- Réécriture des champs Help Text pour les champs critiques.
Étape 5 — Gouvernance pour ne plus dériver
- Mettre en place un outil DevOps (Gearset, Copado, Salto). Voir notre comparatif.
- Définir une convention de nommage et l’imposer (Code Review).
- Mettre en place une revue trimestrielle des permissions et des automations.
- Désactiver, ne pas supprimer (par sécurité) jusqu’à validation de 90 jours sans incident.
Les pièges du refactoring
- Vouloir tout refaire d’un coup. La méthode big bang échoue 9 fois sur 10. Y aller par incréments.
- Supprimer sans backup. Toujours backup les métadonnées et données avant suppression. Voir notre article sur la sauvegarde.
- Casser les intégrations sans prévenir. Avant de supprimer un champ, vérifier qui le lit (REST API logs, External IDs, Flows tiers).
- Ne pas embarquer les utilisateurs. Une refonte UI sans communication = baisse d’adoption. Co-construire avec les power users.
- Sous-estimer le temps. Un refactoring sérieux d’une org de 10 ans prend 4 à 8 mois.
Combien ça coûte
- Diagnostic complet : 15 à 40 k€.
- Refactoring complet d’une org mid-market : 80 à 250 k€ sur 6 à 12 mois.
- Outils DevOps : 25 à 80 k€/an selon licence.
- Maintenance préventive trimestrielle ensuite : 10 à 30 k€/an.
Ces investissements sont rentabilisés par la productivité retrouvée : une org propre permet 30 à 50 % de gain sur les évolutions futures.
Conclusion : refactorer, c’est continuer
Refactorer une instance Salesforce n’est pas un projet ponctuel. C’est une discipline continue. Les organisations qui réussissent leur Salesforce sur 10 ans sont celles qui ont normalisé la maintenance préventive, la revue trimestrielle, le nettoyage régulier.
Chez Cloud Girafe, nous menons régulièrement des missions de refactoring Salesforce. Si vous suspectez que votre org est devenue ingérable, ou si vous reprenez une instance d’un précédent intégrateur, contactez-nous sur cloudgirafe.fr.
