Dette technique Salesforce : comment la trouver et la rembourser

Réponse courte : la dette technique Salesforce est le coût accumulé de tous les raccourcis passés encore présents dans votre org, autant en clics qu'en code. On la trouve avec un inventaire complet des métadonnées croisé avec les données d'usage. On la rembourse dans l'ordre qu'impose la roadmap, pas de haut en bas, car une dette qui ne bloque rien sur la roadmap peut attendre, parfois indéfiniment.

Qu'est-ce que la dette technique Salesforce ?

La dette technique, c'est le travail supplémentaire qu'un changement futur coûtera à cause d'une décision prise avant. Sur Salesforce elle s'accumule plus vite qu'ailleurs, pour deux raisons structurelles : un changement se trouve à un admin et cinq clics de distance, et rien sur la plateforme n'expire quand plus personne ne s'en sert.

Elle prend quatre formes :

• Dette d'automatisation. Workflow Rules, processus Process Builder et Flows qui se recouvrent, dans un ordre de déclenchement que personne ne sait dessiner au tableau.
• Dette de configuration. Des champs que personne ne remplit depuis deux ans, des layouts pour des rôles disparus, des profils portant des droits qui devraient vivre dans des permission sets.
• Dette de code. Plus d'un trigger par objet, des tests écrits pour atteindre un taux de couverture plutôt que pour vérifier un comportement, des identifiants en dur.
• Dette d'intégration. Des appelants figés sur des versions d'API que la plateforme ne sert plus, et du middleware dont le propriétaire a quitté l'entreprise.

Seule la quatrième casse bruyamment. Les trois autres taxent silencieusement chaque projet que vous lancez.

Où se cache-t-elle en ce moment ?

Deux points dates méritent une vérification cette semaine, parce que la plateforme a bougé et que la plupart des orgs non.

• Workflow Rules et Process Builder ont passé la fin de support. Salesforce a fixe cette date au 31 décembre 2025. Ce qui tourne encore dessus continue de s'exécuter, mais les bugs n'y seront plus corrigés et vous ne pouvez plus en créer. L'outil Migrate to Flow existe exactement pour cela.
• Les anciennes versions d'API ont disparu. Les versions 21.0 à 30.0 de la Platform API en SOAP, REST et Bulk ont été dépréciées en Summer '22 puis retirées avec Summer '25. Les appelants reçoivent désormais 410 GONE en REST, 500 UNSUPPORTED_API_VERSION en SOAP et 400 InvalidVersion en Bulk. Si un vieux job nocturne s'est tu, commencez par là.

Comment inventorier la dette sans arrêter la livraison ?

1. Lancez Salesforce Optimizer et exportez le rapport. C'est gratuit, c'est dans Setup, et cela vous donne une liste de départ plutôt qu'une opinion.
2. Récupérez les métadonnées de l'org dans le contrôle de source. Même si vous ne déployez jamais depuis là, vous disposez enfin de quelque chose que l'on peut chercher, comparer et compter.
3. Croisez l'inventaire avec l'usage. Historique des champs, abonnements aux rapports et tableaux de bord, pages vues, logs Apex. Un champ sans lecture ni écriture depuis douze mois est un candidat. Le même champ sur un objet qui en porte 400 autres est une priorité.
4. Cartographiez les dépendances avant toute suppression. La question où est-ce utilisé fait toute la différence entre un nettoyage et une panne.
5. Nommez un propriétaire par domaine. Une dette sans propriétaire n'est jamais remboursée.

Pour une org de taille moyenne, c'est un exercice de deux semaines qui tourne en parallèle d'un sprint normal. Ce qu'il produit est un registre, pas un plan de projet.

Comment classer ce que vous avez trouvé ?

C'est là que la plupart des programmes de dette dérapent. Classer par gravité donne une liste ordonnée selon l'apparence du problème. Classer par effort donne une liste ordonnée selon la facilité. Ni l'une ni l'autre n'est une liste que votre entreprise financera deux fois.

Classez plutôt contre la roadmap. Pour chaque élément du registre, posez une seule question : quel élément engagé de la roadmap devient plus lent, plus risqué ou impossible à cause de lui ? Cette question répartit le registre en trois niveaux.

• Bloquant. L'élément de roadmap ne peut pas sortir tant que la dette n'est pas remboursée. Faites le travail dans ce projet, financé par lui et par son business case.
• Taxant. L'élément sort quand même, mais coûte plus cher ou porte un risque injustifié. Traitez-le dans le sprint précédent, avec un périmètre serré.
• Dormant. Rien sur la roadmap ne le touche. Consignez-le, surveillez-le, ne le financez pas.

Deux catégories priment sur ce classement : tout ce qui a une conséquence de sécurité ou de conformité, et tout ce qui échoue silencieusement en production. On les corrige quelle que soit la roadmap, parce que leur coût ne se paie pas en temps de livraison.

Pourquoi un grand nettoyage échoue-t-il ?

Trois raisons, et nous les avons vues toutes les trois.

1. Aucun résultat visible. Un nettoyage à l'échelle de l'org ne produit ni fonctionnalité ni chiffre qu'un sponsor puisse montrer : il perd son budget dès la première révision des priorités.
2. Un effet d'attribution. On supprime des métadonnées que personne ne surveillait, un incident survient, l'incident est imputé au nettoyage, et le suivant n'est jamais approuvé.
3. Cela ne converge jamais. Une org qui a livré toute l'année a déjà de la dette fraîche quand le balayage se termine. Un remboursement rattaché aux éléments de roadmap converge par construction, puisqu'il s'arrête quand l'élément sort.

L'objectif n'est pas une org propre. C'est une org où les douze prochains mois de roadmap peuvent être livrés à un coût prévisible.

Quelle cadence fonctionne vraiment ?

• Chaque sprint. Une part fixe de la capacité, souvent 10 à 20%, consacrée à la dette taxante dans les zones que touchent les prochaines stories.
• Chaque release Salesforce. Trois fois par an, relancez Optimizer, relisez les avis de retrait et revérifiez les versions d'API demandées par vos intégrations.
• Chaque année. Rafraîchissez l'inventaire et reclassez-le contre la nouvelle roadmap. Les éléments changent de niveau quand les plans changent, et une dette dormante devient parfois bloquante du jour au lendemain.

Un contrôle préventif surpasse les trois : déployez depuis le contrôle de source, pour que l'état de l'org soit reproductible et que chaque changement arrive avec un auteur, une raison et un test. Une dette visible dans un diff devient rarement une dette découverte dans un incident.

Nous menons cet inventaire au début des missions plutôt qu'après la première surprise, et c'est en partie ainsi que nous avons mis 20+ organisations en production sur Salesforce. Si vous voulez un second avis sur votre org avant d'engager la roadmap de l'année prochaine, commencez ici.

FAQ

Comment savoir si mon org a trop de dette technique ?

Mesurez-la en livraison, pas en volumes. Si des changements de routine imposent des tests de régression sur des zones sans rapport, ou si personne ne sait prédire ce qu'un changement va casser, la dette coûte déjà cher.

Faut-il supprimer les champs inutilisés ?

Seulement après un contrôle des dépendances et seulement si un élément de roadmap y gagne. Les champs inutilisés sont le plus souvent une dette dormante, et la dette dormante est ce qu'il y a de moins cher à laisser tranquille.

Salesforce Optimizer suffit-il ?

C'est le bon premier geste, pas le dernier. Optimizer signale des problèmes au niveau de la plateforme, mais ne peut pas dire lesquels se dressent entre vous et la roadmap du trimestre prochain.

Devons-nous quitter Workflow Rules et Process Builder maintenant ?

Ils tournent encore, mais la fin de support était le 31 décembre 2025 : leurs défauts resteront non corrigés. Migrez d'abord les automatisations que votre roadmap touche, pas toutes d'un coup.