Skip links
Linkedin
Facebook Twitter Github

Ces erreurs fréquentes qui compliquent vos projets

Auteur
Publié le :
Catégorie : Bonnes pratiques
Vous est-il déjà arrivé d’ouvrir un flow, de sentir l’interface ralentir fortement au premier clic, de dézoomer pour finalement découvrir un process illisible, non documenté et (presque) impossible à maintenir ? Nous aussi, ça nous est arrivé.
Autre scénario : votre tout nouveau composant a été rigoureusement testé et validé en sandbox, mais provoque une erreur sur votre environnement de production quelques minutes après son déploiement… Vous réalisez ainsi que vos environnements sont bien moins alignés que prévus…
Depuis 10 ans que nous intervenons sur des projets Salesforce, nous pourrions citer beaucoup d’autres exemples. Mais tous ces cas, aussi différents et nombreux soient-ils, mènent souvent au même résultat :
  • Une plateforme difficile à maintenir
  • Des évolutions ralenties, coûteuses, parfois risquées
  • Une application moins fiable et remise en question par les utilisateurs, freinant ainsi son adoption
Il y a bien entendu toujours un contexte à prendre en compte pour expliquer ces mauvais choix : une implémentation faite dans l’urgence, un manque de recul et d’anticipation, un besoin métier imprécis, des bonnes pratiques Salesforce mal assimilées…
Pour toutes ces raisons, nous avons souhaité rédiger cet article. L’objectif est de partager notre expérience accumulée au travers des nombreux projets que nous avons pu mener, concevoir, reprendre et redresser. Cette expérience a été enrichie par toutes les parties prenantes de chaque projet : équipe partenaire, confrères, clients, développeurs…
Ce premier article lance une série et une thématique que nous souhaitons aborder dans la durée. D’autres suivront, et chacun se concentrera sur une thématique spécifique : un cloud particulier, une technologie Salesforce, des approches méthodologiques ou des tâches courantes lors d’un projet.
Pour ce premier article, nous allons nous concentrer sur certaines des erreurs les plus courantes observées (parfois plusieurs fois) en conception ou en implémentation Salesforce Core. Bref, une synthèse de ce qui a réellement fonctionné et de ce qui fonctionne beaucoup moins. Car c’est bien là que les vraies bonnes pratiques Salesforce prennent forme. En les identifiant en phase initiale d’un projet, on peut éviter de grosses complications et bâtir une solution plus évolutive, simple et maintenable.

1. Développer et tester en production

Cela peut sembler évident pour certains, et pourtant… Il nous arrive très fréquemment d’intervenir sur des projets dans lesquels les développements ou les tests sont effectués directement sur l’environnement de production.
Avant de vous démontrer en quoi cela peut être une très mauvaise approche, essayons de comprendre pourquoi cela arrive.
  • Pas de sandbox configurée : cela arrive plus souvent qu’on ne le pense, notamment sur des projets jeunes, par manque d’anticipation, de temps ou même de budget. On se dit que l’on va commencer au plus simple, et que l’on mettra les choses en place correctement plus tard.
    Mais ce « plus tard » n’arrive parfois jamais.
  • Environnement de test obsolète ou pauvre en données : même quand une sandbox existe, elle est parfois inutilisable et outrepassée. Trop de différences avec la prod, pas de jeux de données fiables ou pertinents. Du coup, le moyen le plus sûr reste de tester en prod.
  • Petite modification rapide qui « ne présente aucun risque » : un champ créé, un flow ajusté, une règle de validation désactivée temporairement pour une reprise de données… Autant de petites actions qui s’accumulent sans être testées, semblant sans conséquence.
    Pourtant, elles créent des décalages avec vos sandboxes et peuvent être à l’origine de régressions lors des futures mises en production.

Une sandbox, c’est l’endroit où l’on peut tester, casser, recommencer, ajuster…

C’est le vrai filet de protection de votre projet.
Si l’on développe directement en production, on supprime ce filet et l’on s’expose d’autant plus aux erreurs d’implémentation, aux étourderies, aux effets de bords, etc… Et bien souvent, un environnement de production n’offre aucune tolérance.
Ce type de pratique fragilise clairement la plateforme à plusieurs niveaux :
  • Fiabilité et qualité dégradée : les utilisateurs voient passer des erreurs ou des comportements inattendus, même brièvement. Ils perdent confiance en l’outil, et l’adoption en souffre.
  • Historisation des modifications : aucune traçabilité claire de ce qui a été modifié, quand, par qui et pourquoi.
  • Environnements désalignés : les sandboxes deviennent obsolètes pour vos futurs tests et ne représentent plus la réalité.
Voici maintenant un exemple très concret, qui illustre parfaitement ces risques.
Sur l’un de nos projets, une règle de validation a été désactivée entièrement, le temps d’une reprise de données.
Le problème ? La reprise donnée s’est avérée plus complexe que prévu, a duré plusieurs jours et la règle de validation n’a jamais été réactivée.
Le dysfonctionnement n’a pas été perçu immédiatement : la sandbox de recette était à jour et aucun test ne permettait de reproduire l’anomalie.
Quelques semaines plus tard, l’administrateur de la plateforme se rend compte d’une donnée incohérente. Il a pourtant bien connaissance de la règle de validation, qui avait été testée et validée il y a quelques mois. Il décide donc de se connecter sur sa sandbox de recette et de saisir une donnée erronée pour tester de nouveau cette règle de validation. Bien entendu, la règle de validation est active en recette et se déclenche.
En vérifiant maintenant sur l’environnement de production, il s’aperçoit assez vite du statut inactif de sa règle de validation. Et là, c’est le drame. Un rapport est implémenté pour vérifier la donnée du champ en question, et plusieurs centaines d’enregistrements sont impactés. Pas de chance, ce champ était très stratégique et permettait de déclencher des batch Apex, qui n’ont donc pas pu s’exécuter en temps et en heure.
Résultat : plusieurs jours de reprise, une dette technique évitable et une perte de confiance des utilisateurs.
Quelles bonnes pratiques Salesforce adopter dès maintenant ?

Et maintenant, qu’est ce que l’on peut préconiser ?

Sans forcément viser un cycle de DevOps complet dès le départ, ou s’équiper de toute urgence d’une sandbox Full, voici quelques pratiques à mettre en place :
  • S’interdire de modifier ou de créer des composants directement sur un environnement de production (à l’exception par exemple des rapports ou des emails templates)
  • Avoir une sandbox dédiée à vos développements
  • Disposer d’un environnement de recette identique à votre production et contenant des jeux de données réels
  • Documenter une procédure de refresh de vos environnements : il est rare qu’un simple refresh permette de rendre votre sandbox exploitable. Il faut très souvent réinjecter de la donnée, effectuer des configurations manuelles (notamment en ce qui concerne les valeurs sensibles comme les tokens, endpoints, etc…)
  • Idéalement, comparer dès que possible vos composants avant chaque déploiement, afin de s’assurer de l’uniformité des métadonnées et que seules les modifications souhaitées et testées seront déployées.

Votre environnement de production ne doit donc en aucun cas devenir un endroit d’expérimentation. En prenant de bonnes habitudes rapidement, il est possible de limiter ces situations et de sécuriser davantage vos évolutions.

2. Interdire l’Apex et le code dans un projet

 
Et oui ! Aussi étonnant que cela puisse paraître, nous avons déjà du composer avec cette contrainte. L’intention derrière peut parfois se comprendre : garder un système simple, accessible aux profils non développeurs, faciliter la prise en main et la maintenabilité, limiter les dépendances techniques, etc…
Au risque de se mettre les adeptes du no-code à dos, ce genre de règle finit trop souvent par produire l’effet inverse : des solutions plus complexes à maintenir, moins performantes et détournées pour contourner des limites Salesforce.
Un projet bien pensé doit pouvoir composer avec toutes les solutions que Salesforce nous met à disposition : des flows, du code Apex, des Lightning Web Components, des règles de validation, etc…

Refuser le code, c’est potentiellement se priver d’entrée de la bonne solution pour un besoin spécifique.

Et la promesse du no-code peut rapidement voir apparaître d’autres types de complexité :

  • Des flows ultra complexes, peu performants et tout aussi difficiles à maintenir
  • Des limitations détournées par des solutions moins performantes et moins robustes
  • Imposer des compromis et se détourner du besoin initial : votre solution doit s’adapter à vos process métier, et non l’inverse.
Ce que l’on observe souvent, ce n’est pas un projet complexifié par la présence de code, mais un projet complexifié par un code sans gouvernance et qui ne respecte pas les bonnes pratiques Salesforce : triggers Apex multiples et désordonnés, logique métier dupliquée, tests unitaires baclés, pas de convention de nommage, pas de documentation et de commentaires, etc… Et c’est justement cela qui crée la fameuse « boîte noire » tant redoutée.
Notre conviction est la suivante : il ne faut pas banir le code (Apex, LWC,…). Mais il doit être encadré.
Si l’on se focalise sur l’Apex, le vrai problème n’est pas l’Apex en soi. Le vrai problème vient plutôt d’un code non cadré et non documenté. Un bon developpeur doit être en mesure de rendre son code compréhensible par un profil non technique.
Car oui, quelqu’un qui sait lire un flow complexe, suivre une logique algorithmique et comprendre ce qu’implique une automatisation dans Salesforce dispose déjà de beaucoup de compétences pour réussir à comprendre du code. Avec un peu de contexte, un code structuré et quelques commentaires bien placés, il peut tout à faire monter en compétence et comprendre la logique et les règles de gestion implémentées.
De plus, avec la montée en puissance de l’IA générative, nous disposons de beaucoup d’outils qui peuvent nous aider à comprendre du code, voire même d’y apporter quelques modifications ! Il peut s’agir d’un très bon support pour monter en compétences. Attention tout de même à ne pas s’improviser développeur avec ChatGPT du jour au lendemain. Nous aurions un tas de mauvais exemples à vous citer pour démontrer que cette approche n’a pas toujours été couronnée de succès…
Quelles bonnes pratiques Salesforce adopter dès maintenant ?
Alors, concrètement, qu’est ce que l’on recommande ici ? Le plus important est de poser un cadre clair et précis en début de projet, en fonction des ressources disponibles. Voici quelques principes simples que nous appliquons systématiquement :
  • Définir quand l’utilisation de code est justifiée et quand elle ne l’est pas : tout ne peut pas être fait en Apex, mais tout ne peut pas toujours être fait avec des flows. Simplement, il faut savoir quand est-ce que le code apporte une vraie valeur.
    Si vous souhaitez en apprendre davantage, vous pouvez consulter notre article dédié
  • Encadrer et normer l’utilisation du code : définir des conventions de nommage, de factorisation (handler, helper, service…)
  • Assurer la lisibilité du code
  • Ecrire des tests unitaires pertinents et complets
  • Documenter son code et organiser des sessions avec la personne en charge de la maintenance pour l’aider à comprendre les grandes logiques des process implémentés
Vous l’aurez donc bien compris : ce qui pose problème à notre sens, ce sont plutôt les décisions rigides. Plutôt que de l’interdire, mieux vaut apprendre à utiliser le code à bon escient.
Dans bien des cas, un peu de code bien pensé permet d’éviter beaucoup de complexités futures.

3. Se lancer dans un développement sans conception ni vision finale du process

Il arrive parfois que l’on se lance tête baissée dans un développement, et de nombreuses raisons peuvent expliquer cette situation : un besoin métier exprimé dans l’urgence,  on veut avancer vite, on veut montrer que le projet progresse, que l’on est efficace… Alors on se lance directement dans la création d’un nouvel objet, d’un nouveau flow, un nouveau Lightning Web Component, sans prendre le temps de concevoir le process dans sa globalité.
Dans certains cas, et heureusement, cela fonctionne. Les tests sont validés, les premiers cas sont traités et la nouvelle fonctionnalité répond parfaitement aux besoins exprimés.
Mais assez vite, la suite peut s’avérer compliquée. On s’aperçoit que la logique doit être étendue, qu’un autre service métier est concerné mais que le process n’est pas tout à fait le même, qu’un cas « rare » n’est pas couvert par la solution… On commence à empiler les correctifs, les exceptions, les contournements… On se laisse tenter par de la duplication de process pour gagner du temps, et tant pis pour la maintenance, on verra plus tard pour homogéiniser tout ça… Spoiler : plus tard devient jamais.

La solution devient alors fragile, instable et difficile à maintenir. Chaque nouvelle évolution ressemble à un casse-tête. L’impossibilité d’établir une documentation efficace et claire nous rend rapidement dépendant d’une ressource qui est la seule à pouvoir maintenir la solution. On passe plus de temps à analyser et comprendre l’implémentation qu’à la faire évoluer.

Bref, on se crédite d’une nouvelle dette fonctionnelle et technique.
La phase de conception est une étape clé. Il ne s’agit pas d’alourdir le projet avec une documentation trop détaillée et des ateliers sans fin. Mais prendre un peu de temps pour formaliser le process cible permet d’en gagner beaucoup par la suite.
Quelles bonnes pratiques Salesforce adopter dès maintenant ?
Commencer tout d’abord par un schéma simple. Un croquis sur un bloc note, un diagramme sur Lucid Chart ou Figma… Peu importe, mais cela vaut toujours mieux qu’une logique dans la tête. Il s’agit de la première étape pour clarifier son process et votre propre pensée. Vous pouvez ensuite vous en servir de support, le présenter aux autres parties prenantes, valider votre approche, reccueillir les remarques et idées et rendre ainsi la communication autour du sujet plus efficace…
Essayez ensuite de lister les cas passants et non passants. On pense souvent au scénario idéal, mais ce sont bien souvent les exceptions qui amènent toute la complexité. Anticipez d’ores et déjà vos tests et votre recette, pour gérer au mieux les cas particuliers et les restrictions de votre solution.

Projetez vous sur du long terme :

  • Est ce que mon process restera fonctionnel dans 2 ans, quand le volume de données sera beaucoup plus important ?
  • Quel est le temps de calcul ou d’exécution dans le pire des cas ? En prenant en compte les limites de la plateforme et de la solution que j’implémente, y a t il des risques de les atteindre ?
  • Y a t il une règle de gestion que je peux d’ores et déjà factoriser ?
  • Est-il judicieux de créer un sous-flow, une classe apex dédiée, un custom metadata ?
L’anticipation doit faire partie de la conception afin de rendre votre solution évolutive. Elle permettra d’analyser efficacement la complexité de votre solution.

4. Ne pas nettoyer ce que l’on utilise plus

Si vous avez déjà travaillé sur des org Salesforce vieilles de quelques années, vous avez probablement croisé des composants obsolètes, des champs personnalisés dédoublonnés, des process builder inactifs, etc…
Et bien souvent, on ne les supprime pas. On ne sait jamais, ça pourrait resservir un jour ! Laissons ce composant dans son coin. Après tout, il ne dérange personne.
Qu’est-ce qui nous amène dans ce genre de situation ? Comment est ce que l’on se retrouve avec des composants orphelins, dédoublonnés ou  inactifs ?
Les raisons peuvent être mutliples et sont normales dans le cycle de vie d’un projet :
  • Une fonctionnalité couverte par un développement spécifique devient native grâce à la nouvelle release Salesforce
  • Un évolution des besoins : votre champ formule ne fait plus l’affaire car l’information calculée doit être utilisée dans un roll-up summary
  • Un turnover important des équipes et une passation légère voire inexistante
  • La peur de casser un process en supprimant un composant sur lequel on manque de visibilité : comprenez ici un manque de documentation
  • Un manque de communication entre les différents acteurs du projet
Cela n’empêche bien évidemment pas vos process de fonctionner et ne gène en rien votre activité. La plupart du temps, c’est même entièrement transparent pour les utilisateurs finaux.
En revanche, on risque de perdre en visibilité : on ne sait plus identifier les process actifs et les process obsolètes. Par exemple, si l’on souhaite savoir où est-ce qu’un champ est utilisé, on tombe sur une liste de tous les process qui le réfèrencent : autant de ligne que de version de flow, de classe apex, de process builder, de rapports… Il nous faut donc entrer dans chacun des process, les analyser. Et on se rend compte que la moitié d’entre eux sont inactifs depuis plusieurs années. Quel temps perdu !

Les performances peuvent se dégrader et les évolutions se compliquent : on peut atteindre des limites, par exemple le nombre de champs personnalisés, le nombre de règle de partage, le nombre de version de flow, etc….

Quelles bonnes pratiques Salesforce adopter dès maintenant ?
Alors voici quelques bonnes habitudes à adopter pour garder une org suffisamment structurée et saine :
  • Définissez une vraie stratégie d’archivage : la peur de supprimer un composant est normale. Mais laissez vos composants inutilisés hors de votre prod. Lorsque vous identifiez un composant inactif ou obsolète, mais potentiellement utile à l’avenir, archivez le : une sandbox dédiée, un repository Git, voire même un fichier exporté. Mais le « juste au cas où » ne doit pas polluer votre production.
  • Documentez ce que vous mettez en pause : si vous désactivez complètement un flow, créez une nouvelle version et ajustez la description : un commentaire, un responsable du process…
  • Tracer vos suppressions : dépéndant de votre stratégie de DevOps, vous pouvez commencer par mettre en place un fichier de suivi des modifications. Ce fichier doit vous permettre de savoir quand et pourquoi un composant a été supprimé, et où a t il été archivé.
Pour résumer, ne pas nettoyer sa plateforme, c’est comme laisser s’accumuler des fichiers sur un bureau. On retombe quelques mois plus tard sur un document, on ne sait plus si il a été traité, si il est toujours d’actualité… Nettoyer son org, c’est préserver sa lisibilité et son évolutivité.

 Conclusion

Ces premiers éléments traités ici peuvent vous sembler anecdotiques, basiques ou familiers. Pourtant, mis bout à bout, ils sont très souvent responsables des plus grosses tensions dans les projets Salesforce : évolutivité complexe, dette technique, adoption freinée, plateforme instable… Il nous arrive aujourd’hui encore de constater ce genre de pratique sur des projets.
Toutes ces mauvaises pratiques ne sont pas de vraies fautes techniques : on n’obtient pas un message d’erreur si l’on ne suit pas ces préconisations, et notre plateforme peut tourner convenablement quand même. Ce sont des choix faits dans l’urgence, sans mauvaises intentions… mais qui peuvent à terme fragiliser tout votre ensemble.
L’objectif ici était simplement de vous montrer qu’en adoptant une discipline dès la phase initiale de votre projet, on peut s’éviter bien des problèmes à venir. Pas besoin non plus d’une refonte complète ni d’un changement radical de méthode : quelques réflexes et un aligement collectif peuvent permettre de faire toute la différence.
 

Posts similaires