Pourquoi la dette technique des automatisations diffère de la dette technique conventionnelle
Il est plus aisé d'accumuler de la dette technique sur Salesforce que dans un environnement de développement classique, car l'outil permet à toute personne d'ajouter des automatisations sans passer par un processus de code structuré. Chaque administrateur qui ajoute un Flow Before Save pour résoudre un problème ponctuel, chaque Trigger ajouté il y a deux ans dont personne ne se souvient de l'utilité, et chaque champ de formule dépendant d'un champ inexistant – tous ces éléments s'accumulent pour former une couche que personne ne perçoit dans sa globalité.
La différence fondamentale entre la dette technique classique et la dette technique des automatisations Salesforce réside dans le fait que cette dernière est presque toujours dépourvue de documentation centralisée. Le code réside dans un dépôt avec un historique des commits ; le Flow se trouve dans la section Setup sans explication quant à sa création. Cela rend la phase d'identification particulièrement difficile – non pas parce que le problème est techniquement complexe, mais parce qu'il n'y a personne à interroger.
Cet article traite de l'identification, de la mesure et de la réduction de cette dette. Il n'aborde pas la question de savoir quand choisir un Flow et quand Apex dès le départ – ce sujet est traité dans Flow vs Apex : comment choisir.
Trois types de dettes qui se comportent différemment
Toute dette technique n'est pas identique, et un traitement généralisé de toutes ces dettes comme un problème unique conduit à un gaspillage d'efforts. Il convient de les classer en trois catégories :
| Type de dette | Exemple typique | Que se passe-t-il si ignoré | Priorité de traitement |
|---|---|---|---|
| Dette structurelle | Plusieurs Triggers sur le même objet sans cadre unificateur | Ordre d'exécution imprévisible, échec silencieux | Élevée |
| Dette logique | Flow avec des dizaines de branches de décision représentant une règle métier qui a déjà changé | Décisions erronées exécutées silencieusement | Élevée |
| Dette de maintenance | Champs, Flows et variables personnalisées sans documentation ni utilisation | Temps de développement allongé, peur d'intervenir | Moyenne |
La dette structurelle et la dette logique génèrent un risque opérationnel réel – elles peuvent entraîner des données erronées transmises au client ou dans un rapport financier. La dette de maintenance ralentit l'équipe mais ne rompt pas nécessairement un processus. Cette classification détermine l'ordre de traitement : d'abord, éliminer les risques opérationnels, ensuite, améliorer la vitesse de développement.
Comment identifier la dette avant qu'elle n'explose en production
L'identification ne doit pas commencer par une revue de code manuelle exhaustive – c'est trop coûteux et non durable. Elle commence par quelques indicateurs quantitatifs que l'on peut obtenir en une heure :
- Nombre de Flows actifs sur chaque objet clé (Lead, Opportunity, Case, etc.). Au-delà de cinq ou six Flows actifs sur le même objet, l'ordre d'exécution devient difficile à prévoir.
- Nombre de Triggers non unifiés sous un même cadre pour chaque objet. Plus d'un Trigger par objet est déjà un signe d'alerte, sauf s'il existe une couche de routage explicite.
- Densité des requêtes SOQL dans les boucles apparaissant dans les journaux comme une limite Governor Limit proche du seuil, même si elle n'est pas réellement dépassée.
- Temps d'exécution anormal d'un Flow ou d'un Apex Batch qui augmente avec le temps sans que le volume d'activité n'augmente proportionnellement.
- Champs et variables sans utilisation identifiée dans le rapport d'utilisation des champs, conservés "au cas où quelqu'un en aurait besoin".
Ces indicateurs ne prouvent pas un problème univoque, mais ils fournissent une liste de suspects ciblée. Leur combinaison avec une compréhension approfondie des intégrations dont dépend l'automatisation est détaillée dans Modèles d'intégration Salesforce.
Cadre de décision : Que traiter en premier
Toutes les découvertes de la liste des suspects ne méritent pas le même investissement. Un cadre simple de priorisation, basé sur deux axes – impact commercial et probabilité d'échec – est proposé :
| Situation | Impact commercial en cas d'échec | Probabilité d'échec à court terme | Action |
|---|---|---|---|
| Automatisation d'un processus de commande/facturation avec plusieurs Triggers non documentés | Élevé | Élevée | Refactoring immédiat, hors file d'attente normale |
| Flow complexe sur une mise à jour de statut interne sans impact externe | Faible | Élevée | Documentation et simplification à un rythme normal |
| Ancien Trigger stable mais dont la raison d'être n'est pas claire | Potentiellement élevé | Faible | Documentation d'abord, pas d'intervention immédiate |
| Champs inutilisés et variables personnalisées orphelines | Faible | Faible | Nettoyage cyclique au niveau de la version |
La règle d'or : ne pas traiter en fonction de ce qui irrite le plus les développeurs, mais en fonction de ce qui est le plus risqué pour l'entreprise. Un Trigger ancien et stable que personne ne comprend est parfois le cas le plus tentant à aborder en premier – et c'est précisément le cas où une intervention imprudente cause le plus de dégâts.
Scénario organisationnel : Une compagnie d'assurance avec 14 Flows sur Opportunity
Imaginons une compagnie d'assurance de taille moyenne qui gère ses ventes B2B via Salesforce depuis six ans. Au fil du temps, 14 Flows actifs se sont accumulés sur l'objet Opportunity : sept gèrent les mises à jour de statut, trois envoient des notifications internes, deux synchronisent les données avec un outil de BI externe, et deux autres sont des vestiges d'un ancien processus remplacé il y a deux ans mais jamais désactivés.
Le déclencheur de l'identification du problème fut une défaillance concrète : une transaction est passée au statut " Gagné " mais la notification à l'équipe de souscription n'a pas été envoyée, car un autre Flow a mis à jour le même champ simultanément, créant un ordre d'exécution imprévu. L'équipe a passé deux jours à essayer de comprendre pourquoi – non pas parce que le bug était complexe, mais parce que personne ne connaissait l'ordre d'exécution complet des 14 composants.
Le traitement n'a pas consisté à " tout réécrire en Apex ". L'équipe a d'abord cartographié les 14 Flows et les a classés selon le tableau ci-dessus : les deux anciens Flows ont été désactivés après vérification de l'absence de dépendance active, les trois notifications ont été unifiées en un seul Flow avec une logique de routage claire, et les sept mises à jour de statut ont été unifiées sous un seul Flow déclenché par enregistrement avec un ordre d'exécution explicite. Résultat : de 14 composants à 6, avec une documentation de l'ordre d'exécution que tout nouveau développeur peut lire en quinze minutes.
Risques inhérents au processus de réduction lui-même
La réduction de la dette technique, en soi, comporte ses propres risques, et ne constitue pas uniquement une correction de risques existants :
| Risque | Comment il se manifeste concrètement | Mesure préventive |
|---|---|---|
| Changement d'ordre d'exécution qui rompt une dépendance cachée | Un processus qui fonctionnait cesse de fonctionner après l'unification des Flows | Cartographie complète des dépendances et tests de régression avant toute unification |
| Suppression d'un composant "mort" qui, en réalité, s'exécute encore dans un scénario rare | Défaillance qui n'apparaît qu'à la fin du trimestre ou dans un scénario de pointe saisonnier | Examen des journaux d'exécution sur une année complète, pas seulement le mois dernier |
| Conversion vers Apex sans propriétaire de processus comprenant la règle métier | Le nouveau code est "techniquement correct" mais implémente une règle obsolète | Validation de la règle métier avec le propriétaire de processus avant le codage, et non seulement par rapport au code existant |
| Refactoring effectué dans un seul Sandbox et non synchronisé | Le problème réapparaît en production après le prochain déploiement | Gérer le changement via un processus de publication standard et non comme une correction "hors file d'attente" |
Le risque commun à tous est le même phénomène : l'équipe est persuadée de "juste nettoyer" et, par conséquent, ignore les tests qu'elle effectuerait pour une nouvelle fonctionnalité. Au niveau de la gouvernance, le Refactoring doit suivre le même processus d'acceptation qu'un développement régulier – ni plus ni moins.
Indicateurs pour un suivi continu de la réduction
Pour s'assurer que l'effort réduit réellement la dette plutôt que de simplement la déplacer, il est conseillé de suivre les éléments suivants :
- Nombre de composants d'automatisation actifs par objet, comme mesure trimestrielle de tendance et non ponctuelle.
- Temps moyen de diagnostic d'une défaillance d'automatisation, du signalement à l'identification du composant responsable.
- Pourcentage de composants documentés parmi l'ensemble des automatisations actives dans le cluster central.
- Nombre de défaillances récurrentes sur le même composant sur une période de trois mois.
Les organisations qui peinent à prioriser entre le refactoring et le développement courant peuvent recourir à des services d'architecture CRM pour élaborer un plan de travail contraignant et mesurable.
Liste de vérification opérationnelle avant d'entreprendre un Refactoring
- ☐ Une cartographie complète de toutes les automatisations actives sur l'objet pertinent est disponible.
- ☐ L'ordre d'exécution réel est connu, et non pas seulement l'ordre de création.
- ☐ Chaque composant destiné à être supprimé a été examiné par rapport aux journaux d'exécution sur une année complète.
- ☐ Le responsable du processus métier a approuvé la règle qui est réimplémentée.
- ☐ Un environnement de test simulant un volume de données réel est disponible.
- ☐ Une métrique "avant et après" a été définie pour le nombre de composants et le temps de diagnostic.
- ☐ Le processus de Refactoring suit une publication normale, et non un déploiement exceptionnel.
- ☐ Une capacité constante a été allouée à chaque Sprint pour une gestion continue, et non pour un événement ponctuel.
Résumé
La dette technique dans les automatisations Salesforce s'accumule silencieusement, un composant à la fois, et doit donc être démantelée de la même manière – non pas par un grand projet de nettoyage qui interrompt le développement pendant un mois. Les outils nécessaires sont relativement simples : le décompte des composants par objet, la cartographie de l'ordre d'exécution, et la classification selon l'impact commercial versus la probabilité d'échec. Ce qui détermine le succès est la continuité – allouer une capacité constante à la réduction de la dette parallèlement au développement courant, et non une poursuite ponctuelle du composant qui a causé la dernière défaillance. Une organisation qui adopte cette habitude de mesure atteint un état où tout nouveau développeur peut comprendre en une heure ce qui se passe lors de la sauvegarde d'un enregistrement – et c'est, en fin de compte, la définition la plus pratique de l'absence de dette technique.