Salesforce lent ou instable : comment remettre une organisation d'aplomb

Les symptômes qui ne trompent pas

Une organisation Salesforce ne devient pas instable du jour au lendemain. Elle se dégrade au fil des années, des demandes urgentes et des intervenants successifs. Les signes sont presque toujours les mêmes :

des pages et des enregistrements qui mettent plusieurs secondes à s'ouvrir ou à s'enregistrer ;
des erreurs aléatoires, du type « Apex CPU time limit exceeded » ou « Too many SOQL queries: 101 », surtout lors des imports ou des mises à jour en masse ;
des évolutions simples qui prennent des semaines, parce que chaque modification casse autre chose ;
des mises en production bloquées par les tests ;
des utilisateurs qui contournent le CRM avec des fichiers Excel.

À ce stade, la tentation est de tout reconstruire. C'est rarement nécessaire, et c'est presque toujours plus long et plus risqué que prévu.

D'où viennent ces problèmes

Dans la grande majorité des cas, on retrouve les mêmes causes :

des automatisations empilées sur un même objet : un trigger, plusieurs flows, d'anciennes règles de workflow ou des Process Builder, qui se déclenchent en cascade et se relancent parfois les uns les autres ;
du code qui ne tient pas le volume : des requêtes ou des mises à jour à l'intérieur de boucles, qui fonctionnent sur dix enregistrements et cassent sur dix mille ;
des requêtes non sélectives sur des objets qui ont beaucoup grossi ;
des appels à des systèmes externes faits en direct, pendant que l'utilisateur attend ;
des composants d'interface qui chargent trop de données à l'ouverture d'une page ;
un modèle de partage devenu complexe, coûteux à recalculer.

Salesforce impose des limites par transaction (temps de calcul, nombre de requêtes, nombre d'enregistrements traités). Quand ces limites sont atteintes, la transaction échoue : c'est l'origine de la plupart des erreurs « aléatoires ».

La méthode en cinq étapes

1. Mesurer avant de corriger

On commence par identifier les trois à cinq parcours qui comptent vraiment pour le métier (créer une opportunité, traiter une demande, importer un fichier…) et on mesure : temps de réponse, erreurs, transactions qui approchent des limites. Les journaux de débogage et l'historique des erreurs donnent une image précise de ce qui se passe. Sans mesure, on corrige au hasard.

2. Cartographier les automatisations objet par objet

Pour chaque objet sensible, on liste tout ce qui se déclenche à l'enregistrement : triggers, flows, anciennes automatisations, règles de validation, et l'ordre dans lequel ils s'exécutent. C'est souvent à cette étape qu'apparaissent les doublons et les boucles.

3. Corriger les causes, pas les symptômes

Les corrections qui ont le plus d'effet sont généralement :

un seul point d'entrée par objet pour le code, avec une logique claire et testée ;
un code « bulkifié », qui traite les enregistrements par lots au lieu de les traiter un par un ;
des requêtes sélectives, qui s'appuient sur des champs indexés ;
des traitements asynchrones pour tout ce qui n'a pas besoin d'être immédiat (appels externes, recalculs, envois) ;
des composants d'interface plus sobres, qui ne chargent que ce qui est affiché.

4. Sécuriser chaque correction

Chaque correction s'accompagne de tests sur des cas métier réels, et part en production par une chaîne de déploiement maîtrisée, avec un retour arrière possible. C'est ce qui permet de corriger sans arrêter l'activité.

5. Prioriser la dette restante

Tout ne se corrige pas en une fois. On termine par une liste priorisée des chantiers restants, classés selon leur impact métier et leur risque, pour que l'équipe sache quoi traiter ensuite.

Ce que l'on peut en attendre

Quelques exemples tirés de nos missions :

un traitement métier critique ramené de 60 secondes à 5 secondes, avec un effet direct sur la productivité des équipes ;
la fiabilisation d'un écosystème Salesforce utilisé par plus de 800 personnes en interne et par un portail de plus de 200 000 utilisateurs, en traitant les incidents à la racine plutôt qu'au cas par cas.

Chaque organisation est différente, mais le principe reste le même : mesurer, trouver la cause, corriger de façon ciblée et sécuriser.

Questions fréquentes

Faut-il tout reconstruire ?

Rarement. Une organisation instable contient presque toujours un socle sain : données, processus, habitudes des équipes. Remettre d'aplomb ce qui existe est généralement plus rapide, moins risqué et moins coûteux qu'une reconstruction complète.

Combien de temps faut-il ?

Le diagnostic prend en général une à deux semaines. Les premières corrections, sur les parcours les plus critiques, peuvent suivre aussitôt. La suite dépend de l'ampleur de la dette technique.

Peut-on le faire sans perturber les utilisateurs ?

Oui. Les corrections sont livrées par petits lots, testées en amont et déployées de façon contrôlée.

Notre approche

C'est notre cœur de métier : intervenir quand une organisation Salesforce devient lente, instable ou difficile à faire évoluer. Nos consultants sont certifiés Salesforce et ont fiabilisé des plateformes à fort volume. Pour faire le point sur la vôtre : diagnostic gratuit de 30 minutes. Voir aussi notre offre d'audit et sécurité Salesforce.