
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.
Résumé de la partie 1. Dans la première partie, nous avons présenté notre étude du marché des composants Salesforce, en prenant pour exemples trois grandes familles de composants. Cette étude conclut qu’essayer de concevoir un composant idéal pour tous les contextes est une illusion, mais que la compétition entre les acteurs du marché encourage une accumulation de fonctionnalités, ce qui nuit à la qualité, à la performance et à la durabilité des logiciels tout en tirant les prix vers le haut. Ainsi, le choix d’un composant dans ce contexte devient une tâche complexe pour les entreprises, qui se voient contraintes d’acheter des composants en payant des fonctionnalités dont elles n’auront très probablement aucun usage, et qui de surcroît nuisent à la facilité d’utilisation et à la prise en main de ces composants.
Notre approche : les composants lean
L’idée du logiciel lean n’est pas nouvelle. Dès 1995, dans son article “A plea for lean software” [1] Niklaus Wirth exhortait l’industrie du logiciel à adopter des approches plus légères. En 2001, Peter Middleton a exploré comment transposer les principes du lean issus de l’industrie automobile vers le développement logiciel. Depuis, le développement logiciel lean [3] s’est imposé comme une méthodologie agile [4] visant à minimiser le gaspillage en se concentrant sur les fonctionnalités essentielles, en retardant les décisions au maximum et en livrant rapidement.
Ce principe de report des décisions rejoint plusieurs autres concepts clés en ingénierie logicielle agile, comme le célèbre adage attribué à Donald Knuth [2] : “premature optimization is the root of all evil”, ou encore le principe KISS, qui prône la recherche de la solution la plus simple répondant au problème, plutôt que d’anticiper des problèmes inexistants.
Un composant logiciel lean est donc l’application des principes du développement lean à un composant logiciel. Dans notre contexte, cela concerne particulièrement les composants front-end intégrés dans des logiciels d’entreprise pour des usages métiers, comme les CRM.
Nous définissons un composant lean selon les critères suivants :
- Focalisé sur les fonctionnalités essentielles
Les fonctionnalités secondaires ne sont ajoutées que lorsque leur nécessité est prouvée et leur retour sur investissement (ROI) démontré. - Facilement configurable
Un composant lean doit pouvoir s’adapter à différents contextes métiers. Chaque fonctionnalité inclut une interface de configuration accessible aux utilisateurs métiers. - Rapidement extensible
Les besoins ou contraintes techniques imprévus doivent pouvoir être pris en compte facilement grâce à un cadre de développement agile permettant d’ajouter des fonctionnalités et de les déployer rapidement.
Ainsi, un composant lean s’oppose à un fatware, car il évite l’accumulation de fonctionnalités inutiles et privilégie les outils permettant de livrer rapidement des évolutions.
Viabilité économique et écologique des composants lean
Ce modèle tire parti de la loi de Pareto : 20 % des fonctionnalités couvrent 80 % des besoins. En pratique, d’après le collectif GreenIT, lorsqu’une entreprise déploie un logiciel, en moyenne 45% des fonctionnalités demandées ne sont jamais utilisées, et 70% ne sont pas essentielles.

Cette tendance au “feature creep“, ou empilement fonctionnel, nous pouvons le visualiser simplement en regardant l’interface graphique de l’outil GeoPointe, l’un des composants de cartographie leader du marché pour Salesforce. On constate que l’interface GeoPointe dispose de 4 barres d’actions différentes (entourées en rouge). Ces 4 barres d’actions donnent accès à pas moins de 24 fonctionnalités sur le même écran, dont l’accès à la gestion des calques ou des itinéraires, l’accès à la planification, l’accès à des données météo et de trafic, l’accès à des fonctionnalités de dessin, etc.
En pratique, la plupart de ces fonctionnalités ne sont pas utilisées et rendent la prise en main du logiciel inutilement complexe d’un point de vue UX, mais rendent aussi le composant lourd (gourmand en ressources) et difficile à faire évoluer. Ainsi, avec ce genre d’approche fatware, les clients payent cher un composant proposant beaucoup de fonctionnalités qu’ils n’utilisent jamais ou rarement, mais en plus, en cas de besoins spécifiques sortant du scope du composant, l’éditeur du composant ne sera pas capable de les ajouter rapidement et efficacement.
Au contraire, les composants lean, grâce à leur périmètre fonctionnel restreint, peuvent évoluer de manière agile, en intégrant uniquement les fonctionnalités prouvées nécessaires au fur et à mesure des besoins. Ce principe applique directement l’idée de repousser les décisions au maximum, chère au développement lean.
D’un point de vue économique, un composant lean représente une alternative moins coûteuse à un fatware, qui nécessite souvent des années de R&D pour couvrir un maximum de besoins.
D’un point de vue écologique, un composant lean consomme également moins de ressources sur l’ensemble de son cycle de vie, que ce soit pour son développement ou sa maintenance. Cela réduit la taille des équipes nécessaires, simplifie les infrastructures (software factories, CI/CD), et diminue l’impact environnemental.
Adopter une approche lean permettrait de réduire significativement l’empreinte écologique du numérique. Cela ouvre la voie à une application de la loi EROOM (l’inverse de la loi de Moore), popularisée par Tristan Nitot. Cette démarche vise à réduire chaque année l’impact environnemental des logiciels en les optimisant pour les tâches essentielles, afin d’inverser la loi de Wirth.
Notre atout technologique
Mettre en œuvre une méthodologie lean exige des outils capables de livrer rapidement des ajouts fonctionnels de qualité, permettant aux clients d’adapter un composant lean à leurs propres besoins.
Traditionnellement, le développement logiciel lean repose sur une suite d’outils complexes, similaires à ceux du développement agile : pratiques de clean code, TDD (développement dirigé par les tests), intégration continue, analyse statique, etc. Bien que nécessaires dans des projets d’envergure, ces techniques requièrent un haut niveau d’expertise et une organisation pluridisciplinaire. Elles sont souvent trop lourdes pour des composants légers au périmètre fonctionnel restreint.
Daquota.io : une solution low-code adaptée
Dans notre contexte, nous avons développé un outillage spécifique pour la création de composants lean front-end, adaptés à l’environnement Salesforce et à nos objectifs de simplicité fonctionnelle.
Cet outil repose sur notre atelier de développement low-code Daquota.io. Il permet de créer des composants intégrés à Salesforce répondant à nos critères :

- Simplicité et ergonomie
- Configuration accessible aux utilisateurs métiers via une interface no-code (cases à cocher, sélecteurs d’options, etc.).
- Extensibilité rapide grâce à notre atelier low-code, permettant une personnalisation sans limite.
Exemple : le composant Lean Daquota Maps de LocalFlow
Chez LocalFlow, nous nous appuyons sur Daquota.io, notre framework low-code de développement de composants front-end pour mettre en pratique notre approche de composants leans.
Nous avons développé plusieurs composants sur ce principe, dont Daquota Maps, un composant lean de cartographie pour Salesforce. Les captures d’écrans ci-dessous montrent les 3 niveaux d’utilisation du component : normal (pour l’utilisateur final), configuration no-code (pour l’administrateur métier), extension low-code (pour l’administrateur technique).
Ainsi, la capture d’écran ci-dessous montre le composant, tel qu’il est accessible pour l’utilisateur final. On pourra noter une interface épurée ne proposant que les fonctionnalités essentielles aux utilisateurs pour travailler : (1) visualisation des marqueurs avec des calques, avec la possibilité de filtrer et d’effectuer des recherches simples, (2) un accès à la fonctionnalité de routing, (3) des outils de sélection multiple pour faciliter la gestion de quantités importantes d’objets.

L’écran ci-dessous montre l’interface de configuration no-code à destination des administrateurs métiers. C’est dans cette interface simple que les administrateurs vont définir les paramètres généraux tels que les calques d’objets utilisables par l’utilisateur final.

Enfin, le dernier écran montre l’interface de configuration low-code pour l’administrateur technique. L’atelier/framework de développement Daquota.io permet d’accéder à tous les éléments de l’application (composants graphiques, connecteurs) et de les modifier ou d’en ajouter pour répondre à des besoins qui n’avaient pas été initialement anticipés. Grâce à notre connecteur pour Salesforce, l’atelier donne accès à l’ensemble des objets Salesforce et permet de les modifier via l’API Salesforce. Finalement les modifications peuvent être déployées instantanément en quelques clics dans l’environnement Salesforce de votre choix, ce qui permet de faire évoluer vos composants de manière agile, avec un retour immédiat du terrain, comme le préconise la méthodologie lean.

Note technique (pour les développeurs) : il convient de préciser ici que notre approche low-code pour le front-end est très différente d'une approche de développement classique. En effet, dans une approche classique, l'environnement de codage est décorrélée de l'environnement d'exécution et le code se retrouve éparpillé dans des dizaines, voire des centaines de fichiers. Cela implique d'une part une difficulté à visualiser et valider/tester rapidement les impacts de ses modifications, et d'autre part une difficulté à retrouver rapidement les éléments de code liés aux éléments graphiques.
Dans notre outil Daquota.io, le composant est modifié à chaud en se connectant aux données des environnements de test ou d'exécution final (la prod si nécessaire), ce qui permet un retour visuel immédiat et une navigation plus intuitive dans les éléments de code. De plus la gestion des dépendances, des connecteurs de données, et de déploiement étant entièrement intégrée, le besoin en terme d'équipes pluri-disciplinaire est largement réduit. Avec Daquota.io, un seul développeur pourra gérer un périmètre beaucoup plus large qu'avec des outils classiques de développement logiciel. La courbe d'apprentissage et de "handover" sera aussi beaucoup plus efficace et le développement collaboratif (plusieurs développeurs sur le même projet), se passe aussi de manière naturelle en utilisant un gestionnaire de code et de versions classique (git).
Conclusion
Dans cet article, nous avons présenté notre approche pour développer des composants lean pour Salesforce. Ces composants sont légers, extensibles et financièrement avantageux.
Il est difficile de comparer les composants leans avec les composants standard du marché, car l’approche lean est radicalement différente.
Dans une approche classique, connaissant la difficulté à faire évoluer les composants, on aura tendance à considérer qu’il faut choisir un composant qui présente le maximum de possibilités pour le moins cher possible. Mais cette manière de voir les choses est mise à mal par l’approche lean.
Ainsi, même si l’offre lean de nos composants est moins chère que la compétition, cela ne veut pas dire qu’elle est de moins bonne qualité, bien au contraire.
Imaginez par exemple un couteau suisse qui fournit en un seul élément de nombreux outils : couteux, ciseaux, décapsuleur, … Ce couteau suisse est un bon dépannage quand on n’a pas l’outil idéal sous la main, mais il n’est ni optimal ni efficace : on préfèrera par exemple utiliser une vraie paire de ciseaux pour un travail de précision.
Aussi, même si l’offre lean de nos composants propose une couverture fonctionnelle plus restreinte que les composants classiques du marché, gardez en tête que les composants lean sont extensibles – contrairement aux composants classiques qui ne peuvent pas évoluer rapidement du fait de leur complexité intrinsèque, comme nous l’avons largement expliqué.
Enfin, notez que concevoir et mettre en oeuvre des composants lean n’est pas aussi simple qu’il y paraît, car cela nécessite un socle technologique adapté. Chez LocalFlow, nous avons investi dans la création de Daquota.io, un framework de développement adapté au développement de composants lean pour le front-end. Sans Daquota.io, l’approche lean telle que nous l’envisageons serait impossible à mettre en oeuvre, car elle nécessiterait des équipes pluri-disciplinaires et une expertise poussée dans une gamme de technologies et d’outils complexes. L’efficacité financière et l’agilité seraient donc largement compromises, et cela explique pourquoi les composants classiques ont tant de mal à appliquer une approche lean, comme avait averti Wirth dès 1995.
À ce jour, nous somme fiers de proposer trois composants lean pour Salesforce :
- Daquota Maps : un composant de cartographie,
- Daquota Quiz : un composant de questionnaires,
- Daquota Search : un composant de recherche structurée ergonomique et responsive.
Nous serions heureux de vous faire découvrir ce nouveau type de composant hors du commun. Contactez-nous sur https://localflow.fr pour une démo ou demandez à votre intégrateur Salesforce de tester nos composants dans votre environnement.
Références
[1] Wirth, Niklaus. “A plea for lean software.” Computer 28.2 (1995): 64-68.
[2] Knuth, Donald E. The Art of Computer Programming, volume 1 Fundamental Algorithms. Addison Wesley Longman Publishing Co., Inc., 1997.
[3] Middleton, Peter, and James Sutton. Lean software strategies: proven techniques for managers and developers. CRC Press, 2020.
[4] Al-Saqqa, Samar, Samer Sawalha, and Hiba AbdelNabi. “Agile software development: Methodologies and trends.” International Journal of Interactive Mobile Technologies 14.11 (2020).