Une frontière qui a beaucoup bougé
Il y a quelques années, la moindre interface un peu spécifique demandait du développement. Ce n'est plus le cas : le déclaratif couvre aujourd'hui une part considérable des besoins, et beaucoup d'orgs contiennent du code écrit à une époque où il était indispensable, qui ne le serait plus.
La question n'est donc pas « sait-on le faire sans code », mais « le résultat sera-t-il utilisable et maintenable ». Un Lightning Web Component se justifie quand le déclaratif produirait quelque chose que personne ne voudra utiliser ou que personne ne pourra reprendre.
C'est un arbitrage, et j'essaie toujours le déclaratif d'abord. Non par principe, mais parce que le coût de possession n'est pas le même.
Les quatre situations qui le justifient
1. L'ergonomie conditionne l'adoption
C'est le cas le plus fréquent et le plus légitime. Une saisie répétée des dizaines de fois par jour ne supporte pas les allers-retours entre écrans.
Un Flow d'écran est excellent pour guider, mais il impose une séquence. Quand l'utilisateur doit voir beaucoup d'informations en même temps, comparer des lignes, saisir vite au clavier, les composants standard atteignent leur limite.
C'est exactement le raisonnement qui m'a conduit à développer un composant de saisie de commande pour un négociant : le parcours standard en trois étapes ralentissait des équipes qui saisissaient toute la journée. Le composant a remplacé ce parcours par une saisie en une seule passe, sans changer le bouton d'entrée, donc sans nouvelle habitude à prendre.
2. L'affichage croise des données que le standard ne rapproche pas
Certaines vues demandent de rassembler sur un écran des informations issues de plusieurs objets sans lien direct, ou provenant d'un système externe.
Les composants standard affichent des listes liées, pas des synthèses composées. Quand l'utilisateur doit ouvrir quatre onglets pour reconstituer une situation, un composant dédié fait gagner un temps réel et évite les erreurs de recopie.
3. Le calcul dépasse ce que le déclaratif sait exprimer
Boucles imbriquées, tri élaboré, règles conditionnelles qui se croisent : ce sont des logiques que l'on peut construire en déclaratif, au prix d'un assemblage illisible.
Mon critère est concret : si le Flow devient une usine à gaz que je ne saurais pas expliquer à un autre administrateur en cinq minutes, il est temps de passer au code. Vingt lignes d'Apex lisibles valent mieux que quarante éléments graphiques enchevêtrés.
4. Le volume atteint les limites de la plateforme
Les traitements déclaratifs sont soumis à des limites par transaction. Une opération qui parcourt des milliers d'enregistrements les atteint, et l'automatisation s'interrompt.
À ce niveau, un traitement écrit pour le volume est plus adapté, plus rapide et plus prévisible.
Les trois fausses bonnes raisons
Je refuse régulièrement des demandes de développement, et pour de bonnes raisons.
« Ce serait plus joli. » Une interface différente du reste de Salesforce déroute plus qu'elle ne séduit. La cohérence visuelle avec le reste de l'org a plus de valeur qu'une esthétique particulière.
« On l'a toujours fait comme ça dans l'ancien outil. » Reproduire à l'identique une interface héritée revient à payer pour transporter des habitudes que personne n'a réexaminées. La bonne question est ce que le processus exige aujourd'hui.
« Le déclaratif, c'est du bricolage. » C'est l'inverse. Un Flow documenté est repris par n'importe quel administrateur ; un composant sur mesure non documenté vous rend dépendant de son auteur.
Ce que le sur mesure coûte réellement
Le prix visible est le développement. Le prix réel comprend trois autres postes que l'on découvre plus tard.
Les tests. Un composant s'appuie presque toujours sur de l'Apex, et la plateforme exige une couverture de test suffisante pour déployer. Cette écriture représente une part significative de la charge, et elle n'est pas négociable.
Le déploiement. Un composant ne se paramètre pas dans l'interface de production. Il se développe dans une sandbox et se déploie, ce qui ajoute une étape à chaque évolution, même mineure.
La maintenance. Salesforce livre des mises à jour plusieurs fois par an. Le déclaratif suit tout seul, le code doit être vérifié. Un composant vit plusieurs années, et cette vérification revient périodiquement.
C'est pour cela qu'un devis découpé en lots doit distinguer clairement la part déclarative de la part développée : ce ne sont pas les mêmes coûts, ni les mêmes engagements dans le temps.
La bonne approche, mélanger les deux
Opposer déclaratif et code est une facilité de discours. Dans la pratique, les meilleures solutions combinent les deux.
Un Lightning Web Component peut être intégré dans un Flow d'écran : le parcours, les conditions et les enregistrements créés restent déclaratifs, et seul l'écran qui l'exigeait vraiment est développé. Vous limitez la surface de code, donc la surface de maintenance.
De même, un composant qui expose une vue riche peut s'appuyer sur des données produites par des automatisations déclaratives. Chacun fait ce qu'il sait faire le mieux.
Ce qu'il faut prévoir après la livraison
Un composant sur mesure n'est pas un livrable qu'on installe et qu'on oublie. Trois points se préparent au moment du devis, pas au moment où le problème survient.
Les mises à jour de la plateforme. Salesforce livre plusieurs versions par an. Le paramétrage suit automatiquement, le code doit être vérifié. Prévoyez une revue annuelle du composant : c'est une demi-journée qui évite la panne au pire moment.
Le successeur. Posez la question franchement avant de signer : si vous n'êtes plus disponible, qui reprend ? La réponse doit être « n'importe quel développeur Salesforce, grâce à la documentation », pas « il faudra me rappeler ».
La réversibilité. Que se passe-t-il si le composant doit être retiré ? Un Lightning Web Component bien conçu s'appuie sur des champs et des objets standards, donc son retrait laisse les données intactes. Un composant qui stocke des informations dans une structure qui lui est propre vous rend captif de son existence.
Ces trois points ne coûtent presque rien à traiter en amont. Ils coûtent très cher à traiter après coup.
Trois questions avant de valider un développement
- Que se passe-t-il si on ne le fait pas ? Si la réponse est « les utilisateurs perdent quelques secondes », le sur mesure ne se justifie pas. Si c'est « ils continuent de saisir dans un tableur », il se justifie.
- Qui pourra le reprendre ? Exigez la documentation dans le livrable, au même titre que le code. Sans elle, la moindre évolution devient une reprise complète.
- A-t-on épuisé le déclaratif ? Demandez explicitement ce qui a été essayé et pourquoi cela ne convient pas. Un intervenant qui propose du code d'emblée, sans avoir exploré le paramétrage, prend une décision qui vous engage pour des années.
Un Lightning Web Component bien choisi est un investissement rentable, parfois spectaculaire du point de vue des utilisateurs. Mal choisi, c'est une dette que vous paierez à chaque évolution.
Questions fréquentes
Un Lightning Web Component coûte-t-il plus cher qu'un Flow ?
Oui, et pas seulement en temps de développement. Il faut écrire les tests de la partie Apex associée, déployer proprement, et documenter pour que le composant reste reprenable. Comptez un facteur significatif par rapport à une solution déclarative équivalente.
Peut-on mélanger déclaratif et composant sur mesure ?
C'est même la meilleure approche. Un composant peut être intégré dans un Flow d'écran : on garde le déclaratif partout où il suffit, et on ne développe que le morceau qui l'exige vraiment. C'est ce qui limite le coût et préserve la maintenabilité.