Refactoriser les Triggers Monolithiques

On l’a tous déjà vu. Vous ouvrez une Org qui existe depuis cinq ou dix ans, vous allez dans la section "Triggers", et là, vous le trouvez : un seul AccountTrigger de 2 500 lignes de code. Il est rempli d’instructions if imbriquées, de requêtes à l'intérieur de boucles et d'IDs codés en dur qui ne sont plus valides depuis 2018.

En tant que Salesforce Developer/Architect, regarder um monolithe comme celui-ci ressemble moins à la lecture d'un code qu'à l'observation d'une bombe à retardement. Vous savez qu’il doit être réparé. Vous savez que c'est la raison pour laquelle les déploiements durent une éternité et pourquoi l'erreur "CPU Time Limit Exceeded" est devenue une invitée hebdomadaire dans votre boîte de réception.

Mais comment refactoriser quelque chose qui est si profondément lié aux opérations quotidiennes de l'entreprise ? Comment changer le moteur d'une voiture alors qu'elle roule à 100 km/h sur l'autoroute ?

Parlons stratégie.

1. Le coût de l'inaction

Avant de plonger dans le "comment", nous devons aborder le "pourquoi". Souvent, les parties prenantes voient la refactorisation comme un « luxe technique ». Ce n'est pas le cas. Les triggers monolithiques hérités entraînent un Coût Total de Possession (TCO) élevé.

• Rigidité : Ajouter une seule nouvelle fonctionnalité nécessite de naviguer dans un champ de mines de logique existante.

• Dégradations de performance : Les monolithes manquent souvent de contrôle sur l'ordre d'exécution, ce qui conduit à des requêtes redondantes et à de multiples instructions DML sur le même enregistrement.

• Cauchemars de test : Lorsque la logique est piégée à l'intérieur d'un trigger, vous ne pouvez pas tester les règles métier spécifiques de manière isolée. Vous vous retrouvez avec des « tests d'intégration » lents et fragiles.

2. Étape Zéro : Le filet de sécurité (Tests de régression)

Vous ne pouvez pas refactoriser ce que vous ne pouvez pas vérifier. Avant de déplacer une seule ligne de code, vous devez vous assurer de disposer d'une suite robuste de tests de régression.

Si les tests existants ne fournissent qu'une « couverture » sans réellement valider le comportement, votre première tâche est d'écrire des tests qui décrivent le comportement actuel (même s'il est imparfait) du monolithe. C'est votre police d'assurance. Si vous déplacez la logique vers un nouveau framework et que os testes passam, vous avez le feu vert. S'ils échouent, vous vous êtes épargné un incident de production.

3. Choisir votre architecture

Ne vous contentez pas de déplacer le code d'un trigger vers une classe "Helper". C'est comme déplacer le désordre dans une autre pièce. Vous avez besoin d'un Trigger Framework.

Que vous choisissiez un modèle de gestionnaire léger (handler pattern) ou une implémentation complète de fflib (Apex Enterprise Patterns) — que j'ai analysée en profondeur dans un article précédent concernant sa scalabilité et son overhead — l'objectif est le même : la Séparation des préoccupations (SoC).

• Le Trigger : Doit être sans logique (logicless). Son seul rôle est de déléguer à un gestionnaire.

• Le Handler : Gère le contexte (Before Insert, After Update, etc.).

• La couche Service/Domain : Là où vit la véritable logique métier.

4. La stratégie de migration : Le « Strangler Fig Pattern »

En ingénierie logicielle, le Strangler Fig Pattern (Modèle de l'étrangleur) consiste à créer progressivement un nouveau système autour de l'ancien, jusqu'à ce que ce dernier soit finalement remplacé. C'est le moyen le plus sûr de refactoriser un monolithe Salesforce.

Phase A : La Passerelle (The Bridge) Créez votre nouveau Trigger Handler et liez-le au trigger existant. À ce stade, le trigger contiendra l'« ancien » désordre et un appel vers le nouveau framework.

Phase B : Extraction de la logique Choisissez une règle métier spécifique — par exemple, « Validation de l'adresse sur le compte ». Extrayez cette logique spécifique du monolithe, déplacez-la dans une Classe Domain, et invoquez-la via le nouveau gestionnaire.

Phase C : Feature Flags (Le secret de l'architecte) Si la logique est particulièrement sensible, utilisez les Custom Metadata ou les Custom Permissions comme un « Feature Flag ». Cela vous permet d'activer ou de désactiver la nouvelle logique en production sans nouveau déploiement. En cas de problème, vous pouvez revenir au chemin hérité en quelques secondes.

5. Gérer le problème du « Contexte »

L'un des plus grands pièges des triggers monolithiques est l'absence d'un gestionnaire d'état (State Manager). La logique est souvent répétée parce que le développeur ne savait pas se un calcul avait déjà été effectué lors d'une étape précédente.

Pendant votre refactorisation, implémentez un moyen de transmettre l'état. Si vous utilisez un framework moderne, assurez-vous que votre couche Service est idempotente — ce qui signifie qu'elle peut être appelée plusieurs fois sans causer d'effets secondaires ou de requêtes SOQL redondantes.

6. L'élément humain : Communiquer la valeur

La refactorisation est difficile à "vendre" car elle ne se traduit pas toujours par um nouveau « bouton » sur lequel l'utilisateur peut cliquer. Pour obtenir l'adhésion (buy-in), vous devez parler le langage de l'entreprise :

• Vitesse de mise sur le marché (Speed to Market) : « En nettoyant ceci, nous pourrons livrer les trois prochaines fonctionnalités en deux fois moins de temps. »

• Stabilité : « Cela réduira nos erreurs de production de 40 %. »

• Scalabilité : « Le code actuel ne supportera pas les 500 000 nouveaux enregistrements que nous importerons au prochain trimestre. »

Verdict Final

Refactoriser un trigger monolithique ne consiste pas seulement à rendre le code « joli ». Il s'agit de construire une fondation qui permet à l'entreprise de croître. Cela demande de la patience, une approche disciplinée des tests et le courage d'admettre que la façon dont les choses étaient faites il y a cinq ans ne fonctionne plus aujourd'hui.

Le meilleur moment pour refactoriser était il y a deux ans. Le deuxième meilleur moment, c'est maintenant.