Dette technique Salesforce : comment la trouver et la rembourser

Reponse courte : la dette technique Salesforce est le cout accumule de tous les raccourcis passes encore presents dans votre org, autant en clics qu'en code. On la trouve avec un inventaire complet des metadonnees croise avec les donnees 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 indefiniment.

Qu'est-ce que la dette technique Salesforce ?

La dette technique, c'est le travail supplementaire qu'un changement futur coutera a cause d'une decision prise avant. Sur Salesforce elle s'accumule plus vite qu'ailleurs, pour deux raisons structurelles : un changement se trouve a 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 declenchement que personne ne sait dessiner au tableau.
• Dette de configuration. Des champs que personne ne remplit depuis deux ans, des layouts pour des roles disparus, des profils portant des droits qui devraient vivre dans des permission sets.
• Dette de code. Plus d'un trigger par objet, des tests ecrits pour atteindre un taux de couverture plutot que pour verifier un comportement, des identifiants en dur.
• Dette d'integration. Des appelants figes sur des versions d'API que la plateforme ne sert plus, et du middleware dont le proprietaire a quitte l'entreprise.

Seule la quatrieme casse bruyamment. Les trois autres taxent silencieusement chaque projet que vous lancez.

Ou se cache-t-elle en ce moment ?

Deux points dates meritent une verification cette semaine, parce que la plateforme a bouge et que la plupart des orgs non.

• Workflow Rules et Process Builder ont passe la fin de support. Salesforce a fixe cette date au 31 decembre 2025. Ce qui tourne encore dessus continue de s'executer, mais les bugs n'y seront plus corriges et vous ne pouvez plus en creer. L'outil Migrate to Flow existe exactement pour cela.
• Les anciennes versions d'API ont disparu. Les versions 21.0 a 30.0 de la Platform API en SOAP, REST et Bulk ont ete depreciees en Summer '22 puis retirees avec Summer '25. Les appelants recoivent desormais 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 la.

Comment inventorier la dette sans arreter la livraison ?

1. Lancez Salesforce Optimizer et exportez le rapport. C'est gratuit, c'est dans Setup, et cela vous donne une liste de depart plutot qu'une opinion.
2. Recuperez les metadonnees de l'org dans le controle de source. Meme si vous ne deployez jamais depuis la, 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 ecriture depuis douze mois est un candidat. Le meme champ sur un objet qui en porte 400 autres est une priorite.
4. Cartographiez les dependances avant toute suppression. La question ou est-ce utilise fait toute la difference entre un nettoyage et une panne.
5. Nommez un proprietaire par domaine. Une dette sans proprietaire n'est jamais remboursee.

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

Comment classer ce que vous avez trouve ?

C'est la que la plupart des programmes de dette derapent. Classer par gravite donne une liste ordonnee selon l'apparence du probleme. Classer par effort donne une liste ordonnee selon la facilite. Ni l'une ni l'autre n'est une liste que votre entreprise financera deux fois.

Classez plutot contre la roadmap. Pour chaque element du registre, posez une seule question : quel element engage de la roadmap devient plus lent, plus risque ou impossible a cause de lui ? Cette question repartit le registre en trois niveaux.

• Bloquant. L'element de roadmap ne peut pas sortir tant que la dette n'est pas remboursee. Faites le travail dans ce projet, finance par lui et par son business case.
• Taxant. L'element sort quand meme, mais coute plus cher ou porte un risque injustifie. Traitez-le dans le sprint precedent, avec un perimetre serre.
• Dormant. Rien sur la roadmap ne le touche. Consignez-le, surveillez-le, ne le financez pas.

Deux categories priment sur ce classement : tout ce qui a une consequence de securite ou de conformite, et tout ce qui echoue silencieusement en production. On les corrige quelle que soit la roadmap, parce que leur cout ne se paie pas en temps de livraison.

Pourquoi un grand nettoyage echoue-t-il ?

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

1. Aucun resultat visible. Un nettoyage a l'echelle de l'org ne produit ni fonctionnalite ni chiffre qu'un sponsor puisse montrer : il perd son budget des la premiere revision des priorites.
2. Un effet d'attribution. On supprime des metadonnees que personne ne surveillait, un incident survient, l'incident est impute au nettoyage, et le suivant n'est jamais approuve.
3. Cela ne converge jamais. Une org qui a livre toute l'annee a deja de la dette fraiche quand le balayage se termine. Un remboursement rattache aux elements de roadmap converge par construction, puisqu'il s'arrete quand l'element sort.

L'objectif n'est pas une org propre. C'est une org ou les douze prochains mois de roadmap peuvent etre livres a un cout previsible.

Quelle cadence fonctionne vraiment ?

• Chaque sprint. Une part fixe de la capacite, souvent 10 a 20%, consacree a 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 reverifiez les versions d'API demandees par vos integrations.
• Chaque annee. Rafraichissez l'inventaire et reclassez-le contre la nouvelle roadmap. Les elements changent de niveau quand les plans changent, et une dette dormante devient parfois bloquante du jour au lendemain.

Un controle preventif surpasse les trois : deployez depuis le controle de source, pour que l'etat 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 decouverte dans un incident.

Nous menons cet inventaire au debut des missions plutot qu'apres la premiere surprise, et c'est en partie ainsi que nous avons mis 16+ organisations en production sur Salesforce. Si vous voulez un second avis sur votre org avant d'engager la roadmap de l'annee 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 regression sur des zones sans rapport, ou si personne ne sait predire ce qu'un changement va casser, la dette coute deja cher.

Faut-il supprimer les champs inutilises ?

Seulement apres un controle des dependances et seulement si un element de roadmap y gagne. Les champs inutilises sont le plus souvent une dette dormante, et la dette dormante est ce qu'il y a de moins cher a laisser tranquille.

Salesforce Optimizer suffit-il ?

C'est le bon premier geste, pas le dernier. Optimizer signale des problemes 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 etait le 31 decembre 2025 : leurs defauts resteront non corriges. Migrez d'abord les automatisations que votre roadmap touche, pas toutes d'un coup.