Toute org Salesforce porte de la dette technique, et viser zéro conduit à de plus mauvaises décisions que la dette elle-même. La vraie question : quelle dette corriger maintenant, laquelle planifier selon un déclencheur connu, laquelle laisser en place. C’est une décision de gouvernance. Le responsable de la plateforme la prend, l’écrit avec un nom en face de chaque élément, et la revoit chaque trimestre.
Dette stable et dette qui s’aggrave
La dette s’accumule pour des raisons structurelles plus que par négligence : les besoins arrivent plus vite que la conception ne peut les absorber, les outils déclaratifs permettent à plus de monde de construire avec moins de contrôle, et les fusions empilent la configuration sur la configuration.
Ce qui compte : un élément est-il stable, ou s’aggrave-t-il ? Une vieille règle de validation que personne ne touche, sur un champ et un record type toujours utilisés, est stable : elle ne coûte presque rien à porter. Un Flow qui se déclenche à chaque mise à jour d’Opportunity, appelle un endpoint qui renvoie désormais des erreurs et échoue sans alerter personne s’aggrave : chaque exécution dégrade les données et masque une panne d’intégration. Traitez les deux de la même façon et vous gaspillez l’effort sur le premier ou laissez grossir le second.
La complexité seule n’est pas de la dette. Un Flow complexe pour un processus métier complexe est la bonne conception. La dette, c’est la complexité qui existe à cause d’un raccourci. Une longue classe Apex qui fait ce qu’un Flow simple ferait est de la dette ; une longue classe Apex qui gère une opération de masse que Flow ne sait pas exécuter efficacement n’en est pas. Refactorer une logique qui fonctionne sans gain clair est un moyen sûr d’ajouter des bugs en prétendant réduire le risque.
Trois niveaux : corriger, planifier, tolérer
Classez selon le périmètre d’impact et la trajectoire, pas selon l’âge.
| Niveau | Ce que c’est | Exemples | Décision |
|---|---|---|---|
| Risque actif | Dégrade les données aujourd’hui, bloque une mise à niveau ou crée une exposition réglementaire | Un Flow aux chemins d’erreur non gérés qui avale les erreurs ; du code qui contourne les règles de partage | Corriger, avec une échéance en semaines |
| Risque latent | Stable aujourd’hui, actif sous un déclencheur prévisible | Des triggers non conçus pour le traitement de masse, qui ne tiennent qu’aux volumes actuels ; des ID de Record Type codés en dur qui cassent après un refresh de sandbox | Planifier, avec un plan lié au déclencheur |
| Inerte | Inutilisé, jamais touché, sans danger | Des champs référencés nulle part, des permission sets affectés à personne, des dossiers de rapports que personne n’ouvre | Tolérer, nettoyer pendant les fenêtres de release |
Une longue liste d’éléments inertes sans aucun risque actif vaut mieux qu’une courte liste qui compte trois risques actifs. Avant de supprimer quoi que ce soit d’« inutilisé », vérifiez ses dépendances : un champ peut encore être référencé par une règle de validation, un Flow et un rapport partagé.
Les niveaux bougent quand la plateforme change. Ajouter Data Cloud ou Agentforce reclasse la dette existante. Le rapprochement d’identités repose sur des champs cohérents : des formats de téléphone disparates, inertes dans un CRM isolé, deviennent un risque latent le jour où quelqu’un utilise ce champ pour le rapprochement. Un agent qui s’appuie sur des données CRM avec des Accounts en double, des Contacts orphelins et des Opportunities jamais clôturées répétera ces incohérences dans ses réponses, et aucune modification de prompt n’y changera rien. Reclassez avant l’extension : la dette latente se nettoie moins cher dans un cycle planifié qu’en plein projet.
Ce qu’un health check standard ne voit pas
Un health check standard revoit la sécurité, compte les champs inutilisés et trie ses constats par catégorie. Un scanner listera les Flows sans description à côté des Flows aux chemins d’erreur non gérés ; les premiers sont inertes, les seconds peuvent être un risque actif. Les outils font la découverte. Le classement demande du jugement, sur quatre couches que le contrôle habituel ignore.
- Automatisations. Chemins d’exécution, récursivité, conflits d’ordre d’exécution, exposition aux governor limits en charge normale. Beaucoup de Flows ne sont pas un risque en soi ; une poignée qui se déclenchent sur la même mise à jour et s’appellent entre eux, si.
- Topologie des intégrations. Chaque système qui lit ou écrit dans l’org, jobs planifiés et middleware compris. La question : quels systèmes externes cassent si un nom d’API de champ, une picklist ou une relation entre objets change ?
- Modèle de données. Un schéma qui ne correspond plus au métier : des objets avec de nombreux record types qui modélisent plusieurs entités, des lookups circulaires. Le coût apparaît à la prochaine migration ou fusion.
- Lacunes de gouvernance. Qui peut déployer, si le code est revu, s’il existe des conventions de nommage, si un changement de schéma exige une analyse d’impact. Ces lacunes ne cassent rien le premier jour. Elles laissent la dette s’aggraver d’une équipe à l’autre.
L’ordre de remédiation
- Stabiliser. Corriger ce qui échoue en production, les processus proches des governor limits, les automatisations sans gestion d’erreur.
- Dépréciations. Sortir des fonctionnalités dont Salesforce a annoncé le retrait, comme les Workflow Rules et Process Builder, remplacés par Flow. L’échéance est celle de Salesforce, pas la vôtre. Commencez par les conversions les plus complexes : elles prennent plus de temps que prévu.
- Refactorer. Découpler les intégrations trop couplées, simplifier le modèle de données, ajouter les contrôles qui empêchent la nouvelle dette. C’est une pratique permanente, avec une capacité réservée chaque trimestre et sans date de fin.
Mener les trois de front crée plus de changement qu’une équipe ne peut en absorber. La remédiation modifie aussi des comportements que les utilisateurs prennent pour des fonctionnalités, bugs compris : chaque vague demande sa propre conduite du changement.
Une décision avec un responsable et une revue trimestrielle
Trois contrôles empêchent la dette à risque actif de se reconstituer.
- Une responsabilité nommée. Chaque Flow, classe Apex et configuration d’intégration a un responsable de sa santé. Rattachez cette responsabilité à un rôle (« responsable des automatisations Service Cloud ») plutôt qu’à une personne, pour qu’elle survive au turnover.
- Un contrôle avant déploiement. Des vérifications automatisées avant la production : chemins d’erreur sur les Flows, un seuil de couverture de tests que l’équipe fixe et fait respecter, aucun ID codé en dur.
- Une revue trimestrielle de la dette. Une courte séance où le responsable de la plateforme reclasse la liste selon ce qui a changé : nouvelles intégrations, nouvelles sources de données, nouvelles actions d’agents. Le résultat est une liste révisée avec un responsable et une date par élément.
Le responsable de la plateforme signe cette liste : corriger, planifier ou tolérer. La dette tolérée apparaît alors comme une décision, avec un nom et une date en face. Dans une org plus large, la note sur le Centre d’excellence précise qui mène cette revue.
À vérifier
- Chaque risque actif a-t-il un responsable et une échéance en semaines ?
- Chaque risque latent est-il rattaché à un déclencheur nommé (volume, extension, refresh de sandbox, date de retrait) ?
- La liste a-t-elle été reclassée depuis l’ajout de la dernière intégration, source de données ou agent ?
- Des Workflow Rules ou des processus Process Builder tournent-ils encore, et existe-t-il un plan daté pour les passer sur Flow ?
- Qui signe la liste trimestrielle, et où est-elle conservée ?