Dette technique Salesforce : les 8 indicateurs qu’on mesure en audit
La dette technique Salesforce n’est pas une impression, c’est un inventaire. Quand un org devient lent à faire évoluer, coûteux à maintenir ou risqué à toucher, la vraie question n’est pas “est-ce mal fait ?”, mais “où la complexité s’est-elle accumulée, et avec quelles conséquences ?”. En audit, nous ne cherchons pas un ressenti global. Nous mesurons huit indicateurs concrets qui disent si l’org peut être remis en ordre par lots, ou s’il faut envisager une reprise plus structurée.
Le mot “dette technique” sert souvent à tout dire et donc à ne rien dire. Côté métier, il résume une frustration diffuse : un rapport peu fiable, une règle qui casse, une évolution qui prend deux semaines au lieu de deux jours. Côté intégration, il devient parfois une explication fourre-tout. Or un org Salesforce se reprend mieux quand la dette est nommée précisément.
Pourquoi la dette technique est rarement là où on la cherche
Beaucoup d’équipes pensent d’abord au code Apex. C’est normal, et souvent incomplet. Dans Salesforce, la complexité se cache tout autant dans les Flows, les droits, les objets détournés de leur usage, les champs jamais nettoyés et les décisions métier qui n’ont jamais été documentées.
Un org peut avoir très peu de code et être pourtant difficile à maintenir. À l’inverse, un org avec du spécifique bien rangé et bien gouverné peut évoluer proprement. L’objectif d’un audit n’est donc pas de stigmatiser le standard ou le spécifique. Il est de voir où l’empilement a commencé à produire du risque.
1. Le nombre d’automatisations qui se superposent sur un même objet
Premier signal : plusieurs automatismes traitent le même événement sur le même objet, sans hiérarchie claire.
Concrètement, cela ressemble à :
- plusieurs Flows “after save” qui modifient la même donnée ;
- d’anciens Process Builders ou Workflow Rules encore actifs ;
- des règles qui se contredisent entre elles selon le chemin suivi par l’utilisateur.
Ce n’est pas qu’un sujet de lisibilité. Dès qu’on ajoute une nouvelle règle, on augmente le risque d’effet de bord. Si ce signal est localisé à un périmètre, une reprise ciblée suffit souvent. S’il touche tous les objets coeur, la maintenance devient structurellement fragile.
2. Les exceptions codées comme si elles étaient devenues la règle
Deuxième signal : l’org a accumulé des contournements pour gérer des cas particuliers, puis ces contournements sont restés.
On le voit dans :
- des formules illisibles ;
- des valeurs par défaut détournées ;
- des règles de validation pleines d’exceptions ;
- des IDs codés en dur ou des dépendances à un utilisateur précis.
Ce type de dette rend chaque évolution plus chère, car personne n’ose supprimer ce qu’il ne comprend plus. Le sujet n’est pas esthétique. C’est un risque direct de régression.
3. La gestion des droits repose sur l’historique, pas sur une logique
Quand les profils et les permissions se sont empilés au fil des urgences, l’org devient lent à gouverner et dangereux à auditer.
Les signaux les plus fréquents :
- un grand nombre de profils quasi identiques ;
- des permissions attribuées à la main sans logique de rôle ;
- des comptes techniques trop puissants ;
- une difficulté à expliquer qui peut voir, modifier ou supprimer quoi.
Ce point compte double. D’un côté, il pèse sur la sécurité. De l’autre, il rend toute reprise plus lente, car la moindre évolution doit être validée contre un paysage de droits peu lisible.
4. Les champs, layouts et objets morts sont plus nombreux que les actifs utiles
Un org qui a vécu garde toujours des traces. Ce n’est pas grave. Cela le devient quand le bruit dépasse la valeur.
Indices classiques :
- champs jamais alimentés ;
- layouts surchargés ;
- objets créés pour un ancien besoin et abandonnés ;
- listes de valeurs qui se contredisent entre services.
Cette dette brouille l’adoption. Les utilisateurs ont l’impression que Salesforce est “lourd”, alors qu’ils subissent souvent un problème de design hérité. Le nettoyage n’est pas cosmétique : il réduit le temps de saisie, clarifie le support et améliore la qualité des données.
5. La qualité des données ne tient plus sans bricolage manuel
La dette technique n’est pas seulement technique. Elle devient visible quand les équipes compensent hors de l’outil.
Nous la voyons quand :
- les doublons reviennent malgré les règles existantes ;
- les champs clés sont remplis de manière inégale ;
- les exports Excel servent de source de vérité parallèle ;
- personne ne fait confiance aux segments ou aux listes.
Ce signal pèse lourd dans une décision de reprise. Une automatisation propre sur des données peu fiables reste une automatisation peu fiable. C’est pour cela que les chantiers de dette et de données se traitent souvent ensemble.
6. Le reporting demande plus d’explications que de lecture
Un bon tableau de bord se lit. Un mauvais tableau de bord se justifie.
Quand les utilisateurs demandent systématiquement :
- “d’où vient ce chiffre ?”
- “pourquoi ce total ne colle pas ?”
- “qu’est-ce qui est inclus dans ce statut ?”
le problème est rarement le dashboard seul. Il révèle une dette plus profonde : définitions instables, objets mal utilisés, données incohérentes ou règles qui ont changé sans remise à plat. Un reporting qui n’inspire pas confiance ralentit tout le reste du pilotage.
7. Le déploiement dépend encore de personnes précises
Autre indicateur très révélateur : l’org avance seulement quand une ou deux personnes savent où toucher.
Les symptômes :
- absence de documentation exploitable ;
- nomenclature incohérente ;
- environnements mal séparés ;
- déploiements artisanaux ;
- difficulté à reconstituer rapidement le fonctionnement d’un flux.
Cette dette ne bloque pas toujours le quotidien, mais elle fragilise toute transition. Le jour où le prestataire change, où un consultant part, ou où l’équipe interne reprend la main, la dépendance devient visible d’un coup.
8. Le coût de la moindre évolution n’est plus proportionné au sujet
Dernier indicateur, souvent le plus parlant pour une direction : un petit besoin simple nécessite un effort disproportionné.
Exemples :
- ajouter une règle métier locale demande plusieurs jours d’analyse ;
- modifier un écran oblige à tester une cascade d’effets secondaires ;
- chaque lot commence par de la rétro-ingénierie.
À ce stade, la dette n’est plus seulement un sujet d’architecture. Elle devient un sujet économique. L’org freine la décision parce que chaque ajustement mobilise trop d’énergie pour trop peu de valeur.
Ce que ces huit signaux changent dans un devis de reprise
Un audit utile ne s’arrête pas au constat. Il doit dire ce que ces signaux impliquent pour la suite.
En pratique :
- une dette localisée plaide pour une reprise par lots ;
- une dette diffuse sur les objets coeur rapproche d’une refonte partielle ou d’une remise à plat plus profonde ;
- une dette surtout documentaire et de gouvernance peut souvent se résorber sans tout refaire ;
- une dette mêlée à des données peu fiables impose d’abord un chantier de clarification avant toute promesse de vitesse.
C’est précisément là que l’arbitrage rejoint l’article sur sauver ou refondre. La dette technique n’est pas un verdict moral sur l’org. C’est un critère de décision.
Comment l’IA accélère l’inventaire sans remplacer le jugement
L’inventaire d’un org a longtemps été le moment le plus lent d’une reprise. Lire les Flows, reconstituer les dépendances, cartographier les objets, repérer les droits et produire une documentation d’existant demandait beaucoup de temps avant même de parler métier.
Aujourd’hui, l’IA change surtout cette phase-là :
- lecture accélérée des métadonnées ;
- première cartographie des dépendances ;
- repérage des automatismes redondants ;
- documentation initiale des objets, champs et règles à vérifier.
Le point clé est le suivant : elle accélère le relevé, pas la décision. Les huit indicateurs ci-dessus ne valent que s’ils sont confrontés au vécu des utilisateurs, aux priorités métier et à la gouvernance réelle de l’entreprise.
Quand demander un état des lieux
Les bons moments sont très concrets :
- avant de signer une TMA, quand personne n’est sûr de l’état réel de l’org ;
- quand une évolution simple devient systématiquement lente ;
- quand le reporting n’inspire plus confiance ;
- quand un changement d’intégrateur se profile ;
- quand la direction hésite entre reprise et refonte.
Dans ces cas-là, l’enjeu n’est pas d’obtenir “un avis technique de plus”. C’est d’avoir un plan priorisé, des risques classés et une estimation crédible des scénarios.
Questions fréquentes
Un org sans Apex peut-il avoir une forte dette technique ? Oui. Dans Salesforce, la dette se loge tout autant dans les Flows, les droits, les champs, les objets et les conventions d’usage.
Combien d’indicateurs suffisent pour conclure qu’il faut refondre ? Il n’existe pas de seuil magique. Ce qui compte est la diffusion de la dette : localisée, elle se traite ; diffuse sur les objets coeur, elle change le scénario.
Le Health Check suffit-il pour mesurer la dette ? Non. C’est un bon angle de lecture sur la sécurité et certains réglages, mais il ne couvre ni la gouvernance, ni l’empilement des automatismes, ni la qualité des données. Il reste utile en maillage : déchiffrer un Health Check Salesforce.
Peut-on reprendre un org sans documentation ? Oui. La configuration et les métadonnées restent la source de vérité. L’enjeu est alors d’accélérer l’inventaire sans inventer d’explication qui n’existe pas.
—
Vous voulez savoir si votre org Salesforce a surtout besoin d’un nettoyage, d’une reprise structurée ou d’une refonte partielle ? Le Second avis Salesforce objectivise la situation en 5 jours : état des lieux indépendant, dette mesurée, risques classés, plan priorisé et scénarios chiffrés. 100 % crédités* si une reprise ou une TMA se signe avec nous sous 60 jours.
—
Pour passer d’un diagnostic à un plan de livraison clair, découvrez notre accompagnement intégrateur Salesforce.
