La génération automatique de code a souvent une mauvaise réputation. Open Lowcode l’utilise massivement. Cet article explique son intérêt, et comment les effets pervers sont contenus.

Open Lowcode propose à l’utilisateur de définir son modèle de données étendu, le modèle métier: les objets et les propriétés attachées. L’outillage génère ensuite les objets d’accès aux données, les actions et pages standards pour le modèle métier. Tout le contenu spécifique, les pages et les actions définies par les utilisateurs, doivent étendre une classe abstraite qui est aussi générée. Tout le comme est généré en java, le langage de Open Lowcode.

Après plusieurs années d’utilisation, cette technologie de génération de source automatique est clairement un bénéfice, même s’il y a quelques pièges.

Le code généré est probablement légèrement plus rapide qu’une solution utilisant des approches différentes, telles que la réflexion¹. Le code est en tout cas beaucoup plus rapide que l’interprétation d’un langage de script, et une application générée avec Open Lowcode est au moins aussi simple à développer : Elle supprime les portions ennuyeuses du développement dans les langages fortement typés ²tels que java. Une meilleure performance vous permet d’utiliser du matériel moins coûteux, ce qui est d’autant plus visible dans un environnement cloud, et cela réduit l’impact environnemental, pas du tout négligeable, de l’informatique.

L’approche de génération de code apporte une plus-value incontestable dans la maintenance des applications. Quand on réalise un nouveau développement, si le code généré ne compile pas, c’est tout de suite visible, et particulièrement si l’application est la plus typée possible. C’est encore plus vrai quand on change le modèle métier : le code « manuel » à modifier est immédiatement visible par des erreurs de compilation. Dans un nombre très important de situations, on se retrouve dans la situation idéale où « si cela compile, cela marche ».

Quand on rencontre des erreurs sur un serveur en production, le code généré produit un log très précis sur le contexte de l’erreur. Cela rend l’analyse plus facile par un facteur 10 ou 100 comparé à une technologie qui renvoie des informations plus vagues. Comme la complexité du modèle métier est limitée, le code généré est lisible, contrairement, par exemple, au html généré parfois par des outils automatiques.

La génération automatique de code permet aussi d’avoir des interfaces très agréables, pour rendre l’écriture de logique métier spécifique aussi intuitive que possible. Cela permet à des développeurs débutants, ou des experts métiers pratiquant la programmation comme un hobby, de développer sur la technologie.

Cela a un avantage particulier en java, où le code généré permet de contourner les limitations des génériques, une fonction avancée de java permettant de définir des types complexes. Cette fonction est très utile, mais supporte mal certains cas. Leur gestion est supportée par le code généré automatiquement. On pourrait rétorquer que c’est juste contourner les limites de java, et qu’il serait préférable de changer de langage. Open Lowcode utilise java car c’est une technologie robuste et mature sur laquelle il est adapté de construire des applications qui auront de 5 à 20 ans de durée de vie, et il n’y a pas vraiment d’alternative.

Il y a des inconvénients à la génération de source. Le développement est un processus en plusieurs phases où l’on définit le modèle, génère et compile les classes automatiques ,et, ensuite, on peut créer ou mettre à jour les développements spécifiques, compiler le tout, et, enfin, le déployer. Ce n’est pas aussi simple qu’un éditeur visuel de type « WISIWIG ». Mais les bénéfices de cette approche compensent largement cette lourdeur. La séparation en différentes phases peut aider aussi à mieux structurer le travail en différentes phases (architecture, développement, déploiement).

Un autre inconvénient est le nombre de classes générées, typiquement quelques centaines pour une application de taille moyenne. Ce n’est pas vraiment beau, mais pas un problème majeur.

Le défaut majeur rencontré est la tendance à devenir paresseux avec la qualité du code généré. Il est facile de générer du code long et sale qui fonctionne, alors qu’il aurait été possible de mieux modulariser le développement, et de développer des fonctions d’aide plus génériques. Ce défaut n’est pas mortel, puisqu’il est très facile de refactoriser le code généré, et de l’améliorer même après l’entrée en service.

La solution Open Lowcode est le résultat de centaines de jours d’effort. J’ai décidé de le publier en open-source total (pas de freemium ou de doubles licences) et voici pourquoi.

Je ne suis pas un partisan naturel de l’économie collaborative. J’ai eu l’occasion de vérifier dans de nombreuses situations que l’argent est un meilleur arbitre que les alternatives telles que la politiques, les réseaux personnels, ou même la morale. Si je fais quelque chose qui a de la valeur pour quelqu’un, cette personne me paie, et je fais ce que je veux avec l’argent: c’est équilibré, honnête et pratique. Plus généralement, je pense que l’on ne réfléchis pas assez aux problèmes en termes économiques. Nous ferions mieux d’étudier l’histoire d’un point de vue économique que de gloser sur les maitresses des rois.

Pourquoi alors choisir l’open-source ? Certaines raisons sont liées à ma situation personnelle. J’ai développé l’outil “Open Lowcode” sur mon temps personnel en étant employé d’une grande enterprise, et j’ai utilisé ce logiciel à mon travail, ce qui m’a permis de le valider. Rendre “Open Lowcode” open-source était la solution la plus élégante de sortir de la zone grise légale dans laquelle je me trouvais sans que personne (ni mon employeur, ni moi) n’ait quoi que ce soit à payer. Cela me permet aussi de publier le logiciel sans quitter pour l’instant mon emploi.

Open Lowcode est une initiative modeste. Etre complètement libre est un différenciateur facile à mettre en place, et dans de nombreuses situations, cela peut faire la différence pour faciliter l’adoption. C’est d’autant plus le cas que l’on peut maintenant avoir une solution complètement open-source à l’exception de la couche applicative, qui représente souvent la majorité des coûts. OS et bases de données ont maintenant des solutions de référence.

Même si je n’étais pas un enthousiaste du logiciel libre, après plus de 20 ans en direction informatique, je suis maintenant convaincu que c’est la bonne solution dans la plupart des cas. D’abord, le logiciel ne coûtant rien à copier et distribuer, un utilisateur supplémentaire ne coûte rien. Si le logiciel est gratuit, un utilisateur supplémentaire qui se débrouille tout seul est complétement transparent. C’est différent d’une boulangerie qui offrirait des croissants gratuits aux étudiants, et qui pourrait se mettre en difficulté à cause de cela. Il y a de plus de nombreux inconvénients à rendre un logiciel commercial. Le coût des ventes est énorme, souvent beaucoup plus important que les investissements dans le produit. Au contraire, le logiciel libre se diffuse par le bouche à oreille. Et je ne suis pas sûr qu’il soit possible, pour un vendeur de logiciel, de gérer correctement la situation où ils bénéficient d’une rente de clients captifs. Presque toujours, cela veut dire, à des degrés divers, un produit limité et des coûts de license astronomiques.

Le logiciel libre est de meilleur qualité, et souvent de façon vraiment significative par rapport aux alternatives commerciales. C’est d’abord grâce à l’ouverture des sourrces: elle permet aux utilisateurs de trouver, et souvent de corriger eux-mêmes, les défauts. Une autre raison de cette qualité est le processus de décision. Un éditeur de logiciel n’est pas le meilleur endroit pour prendre des décisions de long-terme sur le produit: celles-ci seront affectées par des considérations politiques et marketing, parfois de court-terme. Le processus de décision sera presque toujours meilleur que l’instinct du développeur de l’application, surtout s’il a l’occasion de discuter directement avec ses utilisateurs.

L’open-source a aussi ses dangers: sans le modèle économique évident de la vente de licenses, il n’est pas facile de mettre en place une communauté durable pour maintenir l’outil dans le temps, c’est à dire une communauté où tous les contributeurs y trouvent leur compte. Le plaisir et l’égo peuvent parfois suffire, mais c’est improbable pour un logiciel d’entreprise qui a aussi ses composants nécessaires et ennuyeux. Il est évidemment possible de contribuer à l’outil sur son temps de travail, ce qui est fréquent. On peut en général développer une fonction manquante ou corriger une erreur en moins de temps qu’il n’en faudrait pour contacter le support d’un logiciel commercial.

Nous sommes au début d’une aventure de “low-code”, ou “atelier de génie logiciel” en bon français, une idée des années 90 qui mérite une seconde change. Après 20 ans d’informatique d’entreprise, j’ai développé et déployé des solutions logicielles ces 20 dernières années. La grande constante de ces années en DSI est un gâchis épique. Cela commence par des développeurs qui passent la majeure partie de leur temps à des tâches désagréables d’assemblages de composants mal finis, tâches n’apportant aucune valeur métier. A la fin de la chaîne, une egonomie rugueuse et des performances médiocres font perdre le sourire et beaucoup de temps à nos victimes. Et vous n’êtes pas à l’abris de lenteurs même si vous avez investi dans un serveur luxueux, qui, il y a 20 ans, aurait fait tourner sans problème la sécurité sociale d’un grand pays. Le coût arbitraire des licences logicielles, et les perturbations des mises à jour imposées sur un système qui pourtant tourne parfaitement, méritent aussi d’être mentionné. Et tout n’a pas été mentionné, c’est un puit sans fond.

La grande constante de ces années en DSI est un gâchis épique

Après quelques années à souffrir, l’idée que l’on pouvait faire mieux devint une évidence. j’ai commencé à expérimenter il y a 10 ans, et la solution s’est construite progressivement. Il y a 4 ans, j’ai présenté à mes collègues la solution, et j’ai pu la tester sur certains de nos cas métiers. Les premiers déploiement ne furent pas sans histoire, mais les problèmes ont été rapidement résolus, et ont confirmé le choix clé de la simplicité: les corrections en sont d’autant plus faciles.

La solution Open Lowcode sera déployée progressivement dans les semaines à venir. Elle sera complètement open-source. Tous les services professionnels que vous pourriez souhaiter seront également offerts. Cela devrait permettre d’offrir le meilleur des deux mondes: la qualité sans contraintes de l’open-source, et le confort des services offerts autour des solutions commerciales.