---

Voir la vidéo : https://youtu.be/rmSRsDSjyR0

---

Etendre Salesforce : les difficultés

Salesforce propose une gamme assez large d’outils pour l’étendre, allant de la configuration no-code au développement de composants spécifiques en utilisant le langage de programmation Apex, dans le cadre du framework Lightning. Salesforce permet aussi l’intégration via OAuth2 d’applications tierces, tout en permettant un accès complet à son API.

Malgré cela, étendre Salesforce peut être un vrai casse-tête pour le métier, mais aussi pour les équipes techniques. Tout d’abord, les options de configuration sont très nombreuses, ce qui est à la fois une force et une faiblesse. Datant de 1999 et assurant une rétro-compatibilité, le framework fait cohabiter plusieurs strates d’outils et de versions qui induisent une difficulté de prise en main, ne serait-ce que pour comprendre quel outil correspond le mieux à ses besoins. De plus, les outils no-code étant limités par essence, l’utilisateur Salesforce se retrouve assez rapidement bloqué dans les évolutions métier possibles. Il doit alors passer en mode développement, et là aussi faire des choix compliqués parmi la multitude d’options qui s’offre à lui.

Pour des extensions spécifiques, le métier devra fatalement s’appuyer sur un intégrateur Salesforce qui aura les compétences techniques, y compris des compétences en programmation avancée. Potentiellement, on retrouvera donc des problèmes similaires à ceux du développement d’applications classiques. Ces problèmes que l’on connaît bien peuvent se résumer comme suit.

• Délais importants de mise en œuvre et perte d’agilité. Les contraintes et évolutions du métier ne peuvent plus facilement et rapidement être mises en œuvre. Il faut passer par des développeurs, voire par des spécifications détaillées avant de se lancer dans une évolution.
• Difficulté à trouver des ressources compétentes. Avec des intégrateurs qui auront du mal à recruter des profils techniques, il est fort probable qu’ils doivent eux-mêmes se reposer sur des ressources offshore pour les développements les plus spécifiques, ce qui augmente encore les délais et la perte d’agilité.
• Difficulté à gérer les contraintes techniques finement. Comme la mise en œuvre devient une boîte noire pour le métier, des contraintes comme par exemple la performance, le FinOps, le GreenOps, la sécurité et l’éco-conception deviennent difficiles à intégrer au projet. En effet, ces contraintes nécessitent une implication forte des métiers, car de nombreuses décisions concernant la QoS ou la sécurité sont liées à des arbitrages du métier.
• Perte d’intérêt des métiers et utilisation d’outils externes. En général, comme pour un développement informatique classique, les métiers peuvent finir par perdre confiance dans la capacité à livrer des logiciels rapidement et commencer à utiliser des outils externes au CRM d’entreprise pour aller plus vite et répondre à leurs besoins. Dans les pires cas, cela peut mener à la création d’un Système d’Information parallèle non maîtrisé, avec les problématiques que cela implique en termes de sécurité, de scalabilité, d’archivage, etc.

Étendre Salesforce avec Daquota.io : le continuum No-Code/Low-Code

Daquota.io est un outil low-code qui propose un connecteur Salesforce complet permettant d’accéder à son API en étant authentifié dans Salesforce avec OAuth2. Grâce à ce connecteur, un “low-codeur” Daquota pourra facilement et rapidement créer des extensions en tirant parti du continuum no-code/low-code de Daquota.

En effet, Daquota propose des outils no-code à la main du métier, mais contrairement à d’autres frameworks no-code, ces outils sont intégrés naturellement dans un écosystème WEB/mobile standard, et l’accès au code se fait de manière intégrée et naturelle. De plus, Daquota permet de tirer parti de l’Intelligence Artificielle Générative pour manipuler le code sans pour autant posséder des compétences avancées dans le domaine de la programmation. Grâce à cette approche basée sur un continuum no-code/low-code, Daquota permet de maximiser les possibilités d’extension et permet aux métiers et aux équipes techniques de cohabiter dans des projets communs.

Pour résumer : avec l’aide de l’Intelligence Artificielle Générative, le continuum No-Code/Low-Code de Daquota limite les effets “tunnel” et “boîte noire” et permet au métier de garder la main sur ses extensions Salesforce.

Exemples d’extension Daquota avec le CRM Salesforce d’ELOI

ELOI.fr est une société à impact spécialisée dans la reprise d’exploitations agricoles. ELOI utilise Salesforce pour son CRM et a été pionnière dans l’utilisation du low-code Daquota, en développant une extension pour simuler le potentiel financier de reprise d’une exploitation (outil initialement développé en Excel, avec les problèmes de sécurité et de collaboration que cela implique), et une extension pour naviguer simplement dans les solutions partenaires d’accompagnement à la reprise de fermes.

Quand les extensions sont développées avec Daquota, il est alors possible de les déployer et de les connecter à Salesforce via une app connectée de type “Canvas App”. Il est ensuite facile de les intégrer (via une page VisualForce) dans n’importe quel emplacement du CRM, par exemple dans un objet Salesforce, dans un onglet global, ou dans une page de communauté Salesforce. Il est même possible d’accéder à l’application en lecture seule en dehors de Salesforce sans connexion/authentification requise, par exemple pour mettre à disposition certains éléments du CRM en consultation et les intégrer dans un site non-Salesforce (par exemple WordPress pour le site vitrine de l’entreprise).

Voici un exemple d’intégration de l’application de simulation de reprise de fermes. Cette application est accessible dans 2 contextes différents dans l’objet métier Transaction du CRM ELOI :

• en mode “preview”, elle montre un résumé des 3 configurations les plus “rentables” en termes de potentiel de reprise,
• en mode “normal”, elle permet de saisir les données et de visualiser le détail des calculs pour différents types d’exploitations. À noter que dans ce mode, l’utilisateur ayant les permissions nécessaires peut aussi modifier les paramètres de calcul et passer en mode édition low-code pour éventuellement changer les formules de calcul.

Voici un deuxième exemple d’application intégrée à Salesforce. Il s’agit d’une application permettant simplement de visualiser et de rechercher des “solutions”, c’est-à-dire un objet métier ELOI contenant les solutions partenaires d’accompagnement à la reprise.

L’intérêt de l’application “solutions” est pour l’utilisateur de pouvoir simplement visualiser et rechercher des solutions correspondant à ses critères de choix. L’écran suivant montre un exemple de recherche sur les critères du modèles des objets solutions.

Il faut noter que ce genre d’extension est bien sûr possible avec les outils Salesforce standard. Cependant, comme nous l’avons expliqué précédemment, le “fine-tuning” de la présentation et du comportement pour l’adapter aux besoins métier est rapidement limité dans la partie no-code. En particulier, il est difficile d’avoir une présentation simple de l’information et proche du métier à destination d’utilisateurs béotiens en informatique (comme c’est le cas ici pour ELOI). Ces difficultés obligent à passer dans un mode développement avec une famille d’outils de code très différents des outils no-code, ce qui casse le continuum no-code/low-code, ayant pour le métier des impacts de perte de contrôle et d’agilité décrits plus haut.

Présentation du mode développement

L’IDE low-code Daquota.io permet de développer simplement des applications en utilisant un certain nombre de composants et d’outils no-code/low-code. Voici comment se présente l’application “solutions” d’ELOI dans cet IDE.

L’IDE se présente comme suit:

• Au centre en haut, l’application en cours de développement est affichée en mode “édition”. Ce mode permet de sélectionner les composants de la page en cours et d’interagir avec eux.
• À gauche, un arbre de composants reflétant la structure de l’application permet de naviguer dans l’ensemble des pages et des composants. À noter qu’une page d’application Daquota peut être comprise comme une page HTML avec des composants interactifs et réactifs.
• À droite, la configuration du composant sélectionné, avec un ensemble de propriétés classées par catégories. À noter que la plupart des propriétés peuvent être calculées dynamiquement grâce à une formule écrite en JavaScript standard.
• En bas au centre, se trouvent les fonctionnalités permettant de configurer les données dans les composants, ainsi que le code JavaScript fonctionnel commun pour étendre le comportement de l’application et des composants si nécessaire (code global, code par composant), ainsi que l’internationalisation de l’application.

L’application “solutions” est composée des éléments suivants.

• Un connecteur salesforce pour la connexion de développement à Salesforce (à noter qu’on utilise une sandbox pour le développement, mais qu’une fois intégré à Salesforce, le connecteur utilise automatiquement la connexion à l’environnement Salesforce courant).
• Un connecteur permettant de lire/créer/modifier/supprimer des objets solutions (il s’agit d’un connecteur CRUD, ici salesforce-crud-solutions.
• Un conteneur de filtrage contenant des sélecteurs select-* pour la recherche.
• Un composant itérateur iterateur-0 qui s’occupe de parcourir les objets solutions. Il contient les composants cartes pour afficher les solutions avec leurs images et les informations utiles.

Afin de pouvoir développer l’application, il faut tout d’abord s’assurer qu’on a à disposition les objets “solutions”. Pour cela il suffit d’aller dans l’onglet Objects du connecteur, et de sélectionner le type correspondant aux solutions.

Le coeur fonctionnel de l’application se trouve dans la formule de la data source de l’itérateur. Il s’agit d’un filtre sur la donnée du connecteur de solution (qui est créé automatiquement à partir de l’instant où on sélectionne l’objet solution dans le connecteur Salesforce).

Pour récupérer toutes les solutions, on utilise la formule $d('salesforce-crud-solutions') qui renvoie toutes les solutions accessibles dans Salesforce. On vient ensuite filtrer cette liste en fonction des critères entrés par l’utilisateur dans les sélecteurs (par exemple $d('select-activite') retourne la valeur potentielle saisie par l’utilisateur pour le filtre d’activité).

Pour démontrer les possibilités d’extension de Daquota, je peux simplement ajouter un champ libre dans le filtre permettant de rechercher une solution par rapport à un mot clé dans sa description.

Je peux ensuite ajouter une condition de filtrage à ma formule de filtre pour prendre en compte la valeur de la saisie libre de l’utilisateur.

Il faut noter que pour rechercher sur le bon champ de l’objet Salesforce, je peux utiliser l’assistant de code qui me permet entre autres de sélectionner un champ. Ici je sélectionne le champ Description_courte_c. Quand le code correspond à mes attentes, j’insère le code dans ma formule de data source et je l’applique.

Si je joue mon application (bouton “play” en haut à droite), je peux par exemple recherche la solution qui contient le terme RSE dans sa description.

Par contre, je peux constater que mon code ne fonctionne pas pour tous les cas, car la formule est sensible aux majuscules/minuscules. Si l’utilisateur tape “rse” (en minuscules), aucune solution ne sort. Il faut donc modifier la formule pour la rendre insensible à la casse (“case insensitive”).

Utilisation de l’Intelligence Artificielle Générative (ChatGPT)

Afin d’assurer un continuum no-code/low-code, il est important qu’un utilisateur n’ayant qu’une connaissance très superficielle en code puisse prendre la main, y compris sur les formules Javascript. Daquota est conçu pour que le code à écrire soit simple, minimal, et bien localisé dans des formules. On pourrait le cacher complètement dans une approche no-code, mais cela aurait des impacts négatifs sur l’extensibilité.

En effet, rien n’est plus puissant que le code pour modifier un comportement sans aucune limite. Précisons que le logicien Alan Turing, inventeur de la machine Enigma qui a décrypté les codes nazis pendant la Seconde Guerre mondiale, a démontré formellement dans ses travaux qu’il est possible de tout calculer avec du code. Ce n’est pas le cas pour le no-code, qui est limité par essence. Il est donc important de garder une base de code, et Daquota a été conçu dans cette optique.

Mais garder le code visible a un autre avantage que l’extensibilité sans limite. Il permet aussi de tirer parti de l’Intelligence Artificielle Générative. L’IA Générative a été entraînée sur du code et comprend étonnamment bien sa structure et sa signification, surtout lorsqu’il s’agit de langages standard et populaires comme Javascript. Daquota a donc été pensé dès le départ pour qu’un non-codeur puisse, grâce à l’IA, générer de nouvelles formules et modifier les formules existantes sans avoir à apprendre la programmation ou à déléguer le travail à des experts.

Pour l’exemple, reprenons le cas de notre recherche de solution qui doit être insensible à la casse. Dans l’assistant de code, on va simplement pouvoir demander à ChatGPT de modifier la formule pour répondre à notre besoin, via une question à la portée de n’importe qui.

Pour utiliser la fonctionnalité et appeler l’API ChatGPT, il faut entrer votre clé d’API fournie par OpenAI. Vous pouvez ensuite taper votre question dans la langue et avec le style qui vous conviennent le mieux.

A noter que l’intégration ChatGPT contextualise automatiquement la question par rapport au code de la formule qui nous intéresse. A terme la contextualisation sera tellement complète que ChatGPT sera capable de comprendre plus d’élément et de générer des formules de plus en plus compliquées. Mais déjà à ce stade, la pertinence de ses réponses est impressionnante.

Ainsi, la réponse donnée par ChatGPT pour rendre la recherche insensible à la casse est parfaitement correcte. Il est même capable d’expliquer ce qu’il a fait.

Il ne reste donc plus qu’à cliquer sur “Use this code”, à l’insérer et à appliquer les changements pour tester la suggestion de ChatGPT. On se rend compte rapidement que cela fonctionne parfaitement.

Il s’agit bien sûr d’un exemple assez simple, mais le principe reste valable pour des formules beaucoup plus complexes. Nous sommes tous impressionnés par le degré de pertinence de l’IA générative, y compris quand il s’agit de travailler sur du code, et il serait inconcevable de devoir s’en passer.

Modification des objets dans Salesforce

Comme nous l’avons dit plus haut, le connecteur vers les solutions est un connecteur “CRUD” (création, lecture, modification, suppression). Il est donc possible avec ce connecteur, non seulement d’accéder aux objets, mais bien sûr de les modifier.

Par exemple, si nous souhaitons modifier notre application pour qu’il soit possible de changer le nom d’une solution et que ce changement soit répercuté dans Salesforce, rien de plus simple. Il suffit de créer un champ de saisie, par exemple dans la carte d’une solution, et de le lier au champ Solution__c.Name (défini dans Salesforce). Il faut créer un nouveau composant (input-6) et modifier la section data source.

Je peux ensuite venir modifier le nom de la première solution. Ici, je renomme Aba’Lab vers Aba’Lab2 pour le test.

Et je peux ensuite constater dans Salesforce que la solution a bien été modifiée.

Sans aucune formule à écrire de la part du concepteur de l’application, le connecteur Daquota est notifié d’un changement de manière réactive (immédiate), et la différence constatée est automatiquement envoyée à Salesforce via l’API. Bien sûr, les droits applicables sur l’utilisateur connecté sont vérifiés par Salesforce, pour chacune des actions possibles.

Déploiement dans Salesforce

Une fois l’application modifiée, déployer une nouvelle version dans Salesforce et la rendre disponible aux utilisateurs est d’une simplicité déroutante. Via le menu File > Share application..., on configure ou on choisit l’environnement sur lequel on souhaite déployer. Par exemple, on peut créer autant de configurations qu’il y a de sandbox Salesforce et une configuration pour la prod. Pour chaque déploiement, on peut créer une nouvelle version. Les versions sont automatiquement historisées.

Il existe un certain nombre de paramètres de déploiement pour une application Daquota. On peut par exemple activer une configuration LDAP ou un serveur OAuth2 externe. Pour l’intégration à Salesforce, il faut bien cocher “Bundle as Salesforce Canvas app”. Dans ce cas, il faudra entrer les secrets pour l’API récupérable dans Salesforce, mais si on coche “Preserve previous version configuration”, la nouvelle version reprend tous les paramètres de la version précédemment déployée, ce qui rend la mise à jour sur l’ensemble des environnements cibles une opération simple et rapide.

A noter qu’il est possible de déployer sur n’importe quelle infrastructure standard, par exemple un cloud PaaS tel que Heroku. Le déploiement “On Premise” est aussi possible en générant un bundle à intégrer dans une CI/CD maison.

Pour démarrer / conclusion

Convaincu? Pour démarrer, vous pouvez partir du template Salesforce disponible en Open Source ici et l’ajuster à vos besoins et à votre environnement Salesforce.

Voici quelques lien utiles pour en savoir plus.

• Le site web Daquota.io
• L’IDE Low-Code (en local first, sans enregistrement requis)
• Le Github pour les projets et composants low-code en Open Source
• Le LinkedIn de Daquota pour rester informé

Le projet étant en phase d’amorçage, n’hésitez pas à contacter Renaud Pawlak pour toute question, y compris si un partenariat vous intéresse.