La Réponse Courte
Des performances médiocres sur Salesforce sont le résultat d'un cumul de facteurs : une Record Page affichant 14 composants, trois automatisations déclenchées par le même événement de sauvegarde, une requête scannant un million d'enregistrements et une intégration de données aux heures de pointe. La seule approche efficace pour améliorer la situation sans dépasser le budget est de mesurer par couches, d'identifier la couche dominante et de la traiter – puis de mesurer à nouveau.
Les Cinq Couches et Ce Qui Est Mesuré dans Chacune
| Couche | Symptôme Typique | Outil de Mesure | Traitement Courant |
|---|---|---|---|
| Navigateur et Réseau | Lent uniquement pour certains utilisateurs | Lightning Usage App par utilisateur | Latence organisationnelle, version du navigateur, VPN |
| Écran et Composants | EPT élevé sur une page d'enregistrement clé | EPT par Page, Mode Débogage | Réduction des composants, chargement paresseux, onglets |
| Automatisation | Sauvegarde lente, Timeout lors de mises à jour massives | Debug Logs, Flow Interviews | Consolidation des Flows, passage à l'asynchrone |
| Données et Requêtes | Rapports en échec, List View figée | Query Plan, Apex Jobs | Filtrage sélectif, Index, archivage |
| Intégration | Pics de charge à des heures fixes | Event Monitoring, API Usage | Bulk API, fenêtres d'exécution, Throttling |
Travailler avec de Grands Volumes de Données
Au-delà d'environ un million d'enregistrements par Object, les règles du jeu changent. Le Data Skew – par exemple 200 000 Accounts associés au même Owner ou Parent – génère des verrous de ligne et ralentit toute mise à jour massive. La solution est de répartir la propriété des données, plutôt que d'ajouter du matériel, ce qui est de toute façon hors de votre contrôle. Parallèlement, il est conseillé d'examiner l'archivage : des enregistrements clos depuis cinq ans et non consultés coûtent cher à chaque requête de balayage.
Écrans : Moins, C'est Plus Rapide
Une Record Page moyenne au sein d'une organisation établie accumule des composants à un rythme de deux à trois par an, chaque partie prenante demandant "un widget de plus". Chaque composant Lightning effectue ses propres appels. Deux actions génèrent le plus de bénéfices : le déplacement des composants secondaires vers des onglets distincts qui ne se chargent qu'au clic, et l'application de la Visibilité des Composants par Type d'Enregistrement ou par rôle, afin qu'un utilisateur ne voie que ce qui est pertinent pour lui. La combinaison des deux réduit l'EPT de dizaines de pourcents sans modification de code.
La Séquence d'Actions Efficace
Commencez par une semaine de mesure sans modifications, afin d'établir une baseline fiable pour cinq écrans et trois processus clés. Ensuite, adressez les écrans – c'est la solution la moins chère et la plus rapide. Dans la troisième phase, consolidez les automatisations par Object, et seulement dans la quatrième phase, touchez aux requêtes et au modèle de données. Les intégrations sont traitées en parallèle, si la mesure a démontré qu'elles en sont la cause.
La logique derrière cet ordre est économique : les premières couches sont peu coûteuses et réversibles, les dernières sont onéreuses et exigent des tests de régression. Des informations complémentaires sont disponibles dans le Salesforce Health Check et les Signes d'une Mise à Niveau du Système.
Risques Courants et Actions Préventives
Le risque majeur est l'optimisation sans baseline : dix modifications sont effectuées, les utilisateurs se plaignent toujours, et il n'y a aucun moyen de savoir ce qui a aidé. Une mesure avant et après chaque changement significatif est une condition, pas un luxe.
Un second risque est de traiter le symptôme le plus bruyant. L'écran le plus souvent mentionné n'est pas nécessairement le plus lent — parfois, c'est simplement celui qui est ouvert le plus de fois par jour. Un troisième risque est de modifier les automatisations sans couverture de test : la consolidation des Flows est l'action ayant le potentiel le plus élevé de briser silencieusement la logique métier.
Comment Mesurer le Succès
Quatre métriques suffisent : EPT moyen sur les cinq écrans clés, temps de Save sur le processus métier principal, nombre d'échecs de Timeout et de Governor Limit par mois, et pourcentage de requêtes dépassant cinq secondes. Une cinquième métrique – complémentaire et non technique – est le nombre de plaintes relatives aux performances au Service Desk, qui devrait diminuer avec les améliorations concrètes.