Les composants Lean : mise en pratique dans Salesforce – Partie 1

User

Résumé

Dans cet article en deux parties, je présente le concept de composant « lean » : des composants conçus en suivant les principes du développement logiciel « Lean », c’est-à-dire en éliminant les fonctionnalités superflues et en retardant les décisions au maximum. En combinant une approche lean avec l’agilité de notre framework low-code, nous proposons des composants légers, parfaitement adaptés aux besoins des utilisateurs. Je détaille comment nous appliquons ce concept à des composants métiers pour le CRM Salesforce et explique en quoi ces composants sont à la fois moins gourmands en ressources, plus pertinents en termes d’expérience utilisateur (UX) et plus avantageux financièrement.

Le constat

Dans la vie réelle, les utilisateurs ont besoin d’outils performants et ergonomiques, capables de s’adapter à leurs métiers. C’est d’autant plus vrai pour les outils informatiques et les logiciels qui évoluent rapidement afin de maximiser la compétitivité des entreprises. La plupart des outils actuels proposent une interface de configuration no-code ou low-code, comme c’est le cas pour le CRM Salesforce. En effet, Salesforce permet d’adapter finement son module CRM à ses besoins via un large éventail d’outils standards ou d’extensions disponibles sur l’AppExchange, sa marketplace de composants et applications.

Cependant, une analyse plus poussée révèle les écueils suivants :

  1. Les outils standards sont efficaces pour configurer la logique métier (par exemple via les flows), mais ils montrent rapidement leurs limites en termes d’ergonomie pour le front-end et l’UX. L’amélioration de l’ergonomie nécessite souvent des ajustements précis qui ne peuvent être réalisés par simple configuration (« le diable se cache dans les détails », comme dit le proverbe).
  2. Pour atteindre une ergonomie optimale, il faut fréquemment recourir à des composants spécialisés, qui sont certes puissants, mais qui sont aussi coûteux, lourds et limités aux fonctionnalités prévues (ex. : Salesforce Maps, OmniStudio, etc.).
  3. Lorsque les limites de ces outils sont atteintes, les entreprises doivent choisir entre deux options : accepter les restrictions, ce qui réduit l’agilité et l’ergonomie pour les métiers, ou passer à un développement logiciel spécifique en utilisant le framework Lightning et le langage APEX. Cette seconde option nécessite des développeurs chevronnés et une organisation spécialisée, ce qui engendre des coûts élevés et des délais importants. De plus, les métiers perdent le contrôle sur le développement, notamment lorsque les projets sont externalisés (voire en offshore).

Ces écueils conduisent à une augmentation dramatique de la complexité et des coûts des licences et des développements informatiques. Dans le cadre d’un projet Salesforce (mais cette situation peut être transposée à d’autres contextes), le processus d’augmentation de la complexité et des coûts peut être décrit comme suit :

  • Étape 1 : Les outils standards étant insuffisants pour une ergonomie optimale, on décide de créer un outil parfaitement adapté aux besoins métiers.
  • Étape 2 : Pour limiter les coûts de développement spécifique, on identifie des composants prêts à l’emploi pouvant être intégrés via une configuration simple.
  • Étape 3 : Lors d’un appel d’offres, on met en concurrence plusieurs composants répondant au besoin (par exemple, un composant de cartographie ou de formulaire).
  • Étape 4 : Pour éviter un développement spécifique (et ses coûts élevés), on préfère des composants disposant du maximum de fonctionnalités, même si toutes ne sont pas indispensables (en moyenne, environ 45% des fonctionnalités demandées ne sont jamais utilisées, et 70% ne sont pas essentielles). Ce choix favorise des composants avec une couverture fonctionnelle large, mais potentiellement de moindre qualité.
  • Étape 5 : Une fois le composant intégré, ses limites apparaissent rapidement. Si les besoins évoluent, trois scénarios sont possibles :
    • Cas 1 : Faire des compromis avec le composant existant. Cela alourdit l’outil, augmente les coûts annexes (intégrations, développements palliatifs, gestion du changement, support, etc.) et complique la prise en main.
    • Cas 2 : Redévelopper un composant spécifique, ce qui entraîne des coûts et des délais importants.
    • Cas 3 : Mettre en concurrence de nouveaux éditeurs pour trouver un composant mieux adapté. Pour gagner le marché, les éditeurs ajoutent des fonctionnalités, augmentant ainsi la complexité et les prix de leurs solutions.

Ce processus, répété à chaque itération, pousse inéluctablement le marché du logiciel vers davantage de complexité et de lourdeur, avec une couverture fonctionnelle toujours plus étendue. L’accumulation de fonctionnalités et de configurations nuisant à l’ergonomie, à la prise en main et à la consommation de ressources, nous conduit dans une logique d’« obésiciel » (« fatware » en anglais), c’est-à-dire un logiciel inutilement gourmand en ressources.

Illustration dans le contexte de Salesforce

Chez LocalFlow, nous avons étudié trois types de composants populaires, vendus sur l’AppExchange de Salesforce :

  1. Les composants de cartographie : Ils permettent de visualiser les objets Salesforce sur une carte, puis de réaliser des analyses prospectives ou d’organiser des tournées.
  2. Les composants de formulaires : Ils permettent de créer des formulaires de saisie d’information et de les rendre disponibles aux utilisateurs afin de récupérer ces données dans Salesforce.
  3. Les composants de recherche et/ou de filtrage : Ils offrent des moyens ergonomiques et intuitifs pour rechercher des informations dans les données Salesforce.

Pour illustrer le problème, nous avons recherché sur Internet les fonctionnalités mises en avant par les différents composants proposés par les différents vendeurs présents sur l’AppExchange de Salesforce. Nous les avons ensuite comparés dans une matrice de fonctionnalités, afin de visualiser les différentes offres.

Etude des composants de cartographie

Nous avons étudié les 8 composants les plus visibles sur Internet, dont voici la liste :

  • C1: Salesforce Maps
  • C2: Geopointe
  • C3: Vision-e
  • C4: Badger Maps
  • C5: RealZips
  • C6: GeoConcept by Nomadia
  • C7: Galigeo
  • C8 Maps Plotter by Extensia

De même nous avons étudiés les fonctionnalités principales mises en avant sur Internet. Nos recherches, nous ont permis d’identifier 17 fonctionnalités pour les composants de cartographie, dont voici la liste :

  • F1 : Geocoding des adresses des objets Salesforce
  • F2 : Dessin manuel sur la carte : marqueurs, cercles, polygones, et lignes
  • F3 : Zones géographiques et segmentation des données
  • F4 : Visualisation des objets Salesforce sur la carte
  • F5 : Gestion des calques d’objets
  • F6 : Surlignage de marqueurs spécifiques
  • F7 : Ajustement conditionnel du format des markers
  • F8 : Filtrer sur les catégories et les calques
  • F9 : Recherche par valeur utilisateur sur des champs spécifiques (ex: date, prix, mot dans un texte, …)
  • F10 : Enregistrement des configurations utilisateurs
  • F11 : Mode clusters de markers
  • F12 : Sélection multiple de markers autour d’un point (avec rayon personalisable)
  • F13 : Méta-données cartographiques additionnelles
  • F14 : Routing (calcul d’itinéraire optimal)
  • F15 : Export des itinéraires vers des services standard (Google Maps, Apple Maps) pour instructions de conduite
  • F16 : Gestion de grands volumes de données
  • F17 : Analytics géospaciale

La matrice suivante résume le support des fonctionnalités par les différents composants étudiés. La couleur verte indique que la fonctionnalité est supportée, alors que le rouge indique qu’elle n’est pas supportée. Attention, l’information de support est issue de notre recherche sur Internet, donc des informations publiquement visibles. Il est possible que l’information publique ne corresponde pas à la réalité exacte du produit.

C1 C2 C3 C4 C5 C6 C7 C8
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
Prix (*) $75 à $125/u/m $74/u/m $39/u/m $69 à $95/u/m $25/u/m 28€ à 46€/u/m $25/u/m Sur demande
Matrice de support des fonctionnalités pour les composants de cartographie dans Salesforce
(*) /u/m: prix mensuel par utilisateur

Etude des composants de recherche

Comme pour la cartographie, nous avons étudié les 8 composants les plus visibles sur Internet, dont voici la liste :

  • C1 : Ascendix Technologies
  • C2 : Prefixbox
  • C3 : Everyone’s Platform
  • C4 : KonaSearch
  • C5 : Coveo Solutions
  • C6 : Satrang Technologies
  • C7 : Softsquare
  • C8 : Cloud Maven

De même, voici les 17 fonctionnalités étudiées pour les composants de recherche, en suivant le même principe que pour les composants de cartographie :

  • F1 : Recherche en texte intégral (Full-text search) avec synonymes et variantes orthographiques
  • F2 : Recherche sémantique et NLP (Natural Language Processing) pour comprendre l’intention
  • F3 : Recherche multi-langues et localisée
  • F4 : Requête par facettes (faceted search) pour filtrer les résultats par catégorie
  • F5 : Personnalisation de l’interface de recherche (disposition, filtres, etc.)
  • F6 : Capacité de personnalisation des algorithmes de recherche (priorités, pondérations, etc.)
  • F7 : Intégration d’IA pour des recommandations et des résultats personnalisés
  • F8 : Temps de réponse rapide, même pour des bases de données importantes
  • F9 : Création et mise à jour automatique d’objets Salesforce en fonction des requêtes et résultats
  • F10 : Fonction de recherche géolocalisée et filtre par zone
  • F11 : Suivi des recherches et suggestions automatiques basées sur les actions de l’utilisateur
  • F12 : Partage de résultats avec les équipes ou intégration de flux de travail collaboratif
  • F13 : Rapports d’analyse des requêtes, des résultats les plus fréquents, et des recherches sans résultat
  • F14 : Analyse de performance du moteur de recherche (temps de réponse, taux d’erreur)
  • F15 : Chiffrement des données sensibles et accès sécurisé aux résultats de recherche
  • F16 : Contrôles d’accès utilisateur, avec gestion des permissions sur les résultats
  • F17 : Conformité avec les normes de protection des données (GDPR, HIPAA, etc.)

La matrice suivante résume le support des fonctionnalités par les différents composants de recherche étudiés. La couleur verte indique que la fonctionnalité est supportée, alors que le rouge indique qu’elle n’est pas supportée (avec les mêmes réserves que celles expliquées pour la cartographie).

C1 C2 C3 C4 C5 C6 C7 C8
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
Prix (*) $15/u/m $21000/y £5400/y $20/u/m $20/u/m Sur demande $50/m $20/u/m
Matrice de support des fonctionnalités pour les composants de recherche dans Salesforce
(*) /u/m: prix mensuel par utilisateur
     /y: prix par an pour une entreprise
     /m: prix par mois pour une entreprise

Etude des composants de formulaires

Comme pour la cartographie et la recherche, nous avons étudié les 8 composants de formulaires les plus visibles sur Internet, dont voici la liste :

  • Survey Vista
  • Titan Forms
  • Formstack
  • YesLocal Digitial
  • Jotform Inc.
  • FormAssembly
  • 123FormBuilder
  • BreezyBit LLC

De même, nous avons identifié 20 fonctionnalités étudiées pour les composants de formulaires, en suivant la même démarche que précédemment :

  • F1 : Thèmes prédéfinis pour un design cohérent
  • F2 : Personnalisation des couleurs
  • F3 : Personnalisation des polices
  • F4 : Personnalisation des icônes
  • F5 : Disposition adaptable (sections, colonnes, espacements)
  • F6 : Modèles de formulaires prêts à l’emploi pour divers cas
  • F7 : Formulaires multi-étapes avec progression visible
  • F8 : Indicateurs de progression et animations
  • F9 : Auto-sauvegarde des réponses en cas de déconnexion
  • F10 : Alertes utilisateur et suggestions automatiques pour erreurs
  • F11 : Envoi d’emails déclenchés automatiquement sans quitter Salesforce
  • F12 : Création automatique d’objets Salesforce (Leads, Opportunités)
  • F13 : Mise à jour de champs Salesforce existants en fonction des réponses
  • F14 : Statistiques de conversion et d’abandon
  • F15 : Rapports en temps réel sur les réponses
  • F16 : Contrôles d’accès administrateur et chiffrement des données sensibles
  • F17 : Mode hors ligne pour utilisation sur le terrain avec synchro
  • F18 : Support pour les formulaires multi-langues
  • F19 : Optimisation mobile et adaptabilité responsive
  • F20 : Gestion de grands volumes de données avec mise en cache

La matrice suivante résume le support des fonctionnalités par les différents composants de formulaires étudiés. La couleur verte indique que la fonctionnalité est supportée, alors que le rouge indique qu’elle n’est pas supportée (avec les mêmes réserves que celles expliquées précédemment).

C1 C2 C3 C4 C5 C6 C7 C8
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
F18
F19
F20
Prix (*) $3000/y Sur demande $400/m Free $39 à $59/u/m $83/m $99/u/m $100/us/m
Matrice de support des fonctionnalités pour les composants de formulaires dans Salesforce
(*) /u/m: prix mensuel par utilisateur
     /y: prix par an pour une entreprise
     /m: prix par mois pour une entreprise

Analyse et interprétation

Notre étude permet ainsi, grâce aux matrices de fonctionnalitées, de visualiser et comparer rapidement les couvertures fonctionnelles des différents produits pour nos trois familles de composants : cartographie, recherche, et formulaires.

On constate que, conformément à la logique de fatware décrite précédemment, les prix sont globalement élevés, tout comme la couverture fonctionnelle, avec des fonctionnalités communes à de nombreux composants du marché. En effet, modulo quelques rares exceptions, la plupart des solutions supportent l’ensemble des fonctionnalités. On constate aussi que la couverture fonctionnelle est un peu plus variable pour des composant tels que les formulaires, qui sont par définition plus ouverts.

On peut donc constater que globalement, il est difficile de faire son choix pour son propre besoin en se dispensant d’une analyse poussée des composants, rendant un choix objectif de l’ordre du casse tête pour les DSI. La difficulté du choix pourra ainsi mener à des comportements étranges, comme se creuser les méninges pour chercher d’autres fonctionnalités mineures afin de départager la compétition (ce qui poussera les éditeurs à augmenter leur couverture fonctionnelle), ou de choisir en considérant des critères comme le prix ou la capacité de support de la société qui édite le composant. Par exemple, on pourra choisir par défaut la solution la plus chère en estimant qu’à fonctionnalités équivalentes, on aura une meilleure qualité et un meilleur support si on paye plus cher.

Or, en logiciel, le prix n’est pas forcément corrélé à la qualité, car il s’avère que développer un logiciel avec une couverture fonctionnelle large coûte plus cher, mais peut aussi nuire à l’UX en ayant un effet d’empilement des fonctionnalités qui rend le produit moins facile à utiliser. On appelle cet effet le “feature creep“.

Pour se rendre compte de l’investissement nécessaire pour développer un logiciel avec une couverture fonctionnelle élevée, on peut prendre comme exemple la solution cartographique de référence : Salesforce Maps. En effet, il se trouve que Salesforce Maps provient du rachat de MapAnything, une startup ayant levé 84,1 millions de dollars, dont 42,5 millions en capital-risque (source : growjo.com). Ce contexte et ces chiffres publiquement disponibles nous permettent d’avoir une idée des coûts de R&D et de commercialisation nécessaires pour développer des composants. Ces coûts importants sont liés à la concurrence permanente entre éditeurs et le besoin d’augmenter la couverture fonctionnelle pour gagner les appels d’offres. Ces coûts de R&D sont un frein à la baisse des prix dans le domaine du logiciel (ce qui est contre-intuitif car en général, dans d’autres domaines, la compétition tend à faire baisser les prix).

Au final, cette dynamique de compétition et de difficulté à maîtriser les coûts de développement entraîne un cercle vicieux. Plus la couverture fonctionnelle s’élargit, plus la complexité et la lourdeur des composants augmentent. Cela fait exploser les coûts de configuration, de maintenance et d’hébergement. En effet, un composant consommant plus de ressources coûte davantage à installer, maintenir et héberger [1].

Conclusion

Il est légitime à ce stade de se demander pourquoi il est si difficile techniquement parlant, d’arriver à proposer à bas prix un composant universel qui réponde à tous les besoins des clients. La réponse à cette question se trouve dans les travaux des chercheurs en informatique, qui savent depuis longtemps que le composant idéal n’existe pas. Chaque composant doit faire des choix de conception qui l’optimisent pour un contexte donné, mais le rendent sous-optimal dans d’autres cas.

Ainsi, le constat empirique que nous faisons ici est soutenu par le théorème de Brewer [2], qui démontre que des propriétés clés comme la cohérence des données, la disponibilité et l’évolutivité ne peuvent être simultanément garanties dans tous les cas. Un choix de conception privilégie nécessairement certaines propriétés au détriment d’autres. Cette réalité est confirmée par des travaux comme ceux de Blinowski [3], qui montrent un effet de « vases communicants » entre performance et évolutivité dans les architectures monolithiques et micro-services.

En conclusion, chercher à concevoir un composant idéal pour tous les contextes est une illusion. Cela entraîne le marché dans une course sans fin, avec des effets souvent négatifs sur la qualité, la performance et la durabilité des logiciels. Cette dynamique explique parfaitement la loi de Wirth : le logiciel ralentit plus vite que le matériel n’accélère.

Dans la partie suivante, nous allons présenter notre approche de composants lean, dont le but est de remédier aux problèmes de complexité et de coûts associés (financiers et environnementaux).

Reférences

[1] Ogheneovo, Edward E. “On the relationship between software complexity and maintenance costs.” Journal of Computer and Communications 2.14 (2014): 1.
[2] Brewer, Eric. “CAP twelve years later: How the” rules” have changed.” Computer 45.2 (2012): 23-29.
[3] Blinowski, Grzegorz, Anna Ojdowska, and Adam Przybyłek. “Monolithic vs. microservice architecture: A performance and scalability evaluation.” IEEE Access 10 (2022): 20357-20374.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top