Dette technique Salesforce
La dette technique Salesforce est le coût accumulé des raccourcis et des choix dépassés dans la configuration et le code d’une org : automatisations superposées, outils historiques, valeurs codées en dur, champs inutilisés, intégrations vieillissantes. Ce n’est pas un indicateur unique mais une notion de terrain : chaque élément rend l’évolution suivante plus longue à analyser et plus risquée à déployer.
Automatisations qui se recouvrent et outils historiques
Des points d’entrée Flow et déclencheurs Apex indépendants peuvent morceler la responsabilité et les tests. Évaluez leurs interactions et la densité d’automatisation avant de proposer une refonte : une conception délibérée associant Flow et Apex invocable n’est pas, en soi, un signe de dette technique.
Les règles de workflow et Process Builder en sont une autre source. Salesforce a mis fin à leur support le 31 décembre 2025 : ceux qui existent continuent de s’exécuter, mais sans support client ni correction d’anomalies, et Salesforce recommande de les migrer vers Flow.
Valeurs codées en dur et versions d’API obsolètes
Les identifiants d’enregistrement codés en dur rendent la configuration dépendante d’enregistrements et d’environnements précis. Certains enregistrements copiés peuvent conserver leur identifiant dans une sandbox, mais les enregistrements créés séparément et les autres environnements n’ont aucune raison de partager les mêmes. Préférez une recherche ou une stratégie de configuration explicite plutôt que de supposer des identifiants identiques partout. Les intégrations qui appellent des versions d’API retirées échouent purement et simplement : Salesforce a retiré les versions 21.0 à 30.0 des API SOAP, REST et Bulk avec la version Summer ’25. Ce retrait ne concerne pas la version d’API enregistrée sur les classes Apex, les déclencheurs ou les flows.
Champs inutilisés et automatisations mortes
Les champs que personne ne lit, les automatisations inactives ou remplacées et les composants laissés par des projets abandonnés ajoutent du bruit sans apporter de fonction. Chacun doit pourtant être vérifié avant qu’une évolution puisse l’écarter : le coût se paie à chaque analyse d’impact, pas une seule fois.
La gérer
Les recommandations Well-Architected de Salesforce sur l’excellence opérationnelle préconisent d’inscrire la dette technique dans le même backlog que les évolutions fonctionnelles et de réserver délibérément de la capacité pour la réduire. Le préalable est un inventaire : on ne peut pas prioriser une dette que l’on ne voit pas.
Ce qu’apporte aprity
aprity produit cet inventaire à partir des métadonnées, en lecture seule : objets, champs, automatisations et règles métier documentés en termes métier, graphe de dépendances calculé de façon déterministe, graphes d’exécution par objet qui montrent où plusieurs automatisations réagissent à la même sauvegarde, et comparaison des règles d’une analyse à l’autre, en termes métier, pour suivre le nettoyage dans le temps.
Termes liés
- Ordre d’exécution Salesforce — La séquence fixe dans laquelle Salesforce exécute flows, déclencheurs, règles de validation et autres automatisations lors de la sauvegarde d’un enregistrement.
- Flow déclenché par un enregistrement — Un Flow que Salesforce lance automatiquement lorsqu’un enregistrement d’un objet donné est créé, mis à jour ou supprimé.
- Package géré et préfixe d’espace de noms — Un package géré est un ensemble de métadonnées distribuable et pouvant être mis à niveau ; son préfixe d’espace de noms s’ajoute au nom d’API de chacun de ses composants.
- Règle de validation — Une formule qui empêche la sauvegarde d’un enregistrement et affiche un message d’erreur dès qu’elle renvoie vrai.
Sources
La documentation officielle de Salesforce sur laquelle cette définition a été vérifiée (pages en anglais). Le comportement de la plateforme évolue d’une version à l’autre : la page citée fait foi.