Comment définir le Low Code ? Et sur quelles technologies / approches reposent le Low Code ?

Le Low Code mélange la programmation visuelle à la simplification des tâches de programmation répétitives. Le but est d’augmenter le niveau d’abstraction pour gérer l’ensemble des tâches de programmation. Le constat est simple : pour une application métiers, 80 à 90% du code écrit est pratiquement identique d’une application à l’autre (NDLR : on différencie le code purement technique et le code métier)!

Pourquoi ne pas faire en sorte que tout ce code redondant soit déjà géré par une plateforme et que le développeur n’ait plus qu’à se soucier du fonctionnel de son application sans se préoccuper de la plomberie, de la base de données, du fonctionnement hors connexion etc.

C’est une idée vieille comme le monde informatique et on croit avoir déjà tout vu dans ce genre de concept, du générateur d’application au L4G en passant par les frameworks et autres bibliothèques de code réutilisable.  Le Low Code reprend ces idées mais en décuplant leurs capacités :

• Niveau d’abstraction encore plus élevé sur les données
• Une approche Full Stack : Front end et Back end
• Construction visuelle des processus et des interfaces utilisateurs
• Réutilisation de blocs composants fonctionnels
• Réduction des contraintes de syntaxe

Ce qui change c’est que maintenant on ne se préoccupe plus seulement de la programmation de l’application, mais aussi de sa mise en production et de son cycle de vie !   C’est là que le Low Code diffère énormément, et tout cela grâce à la montée en puissance des technologies cloud, des processus DevOps CI/CD et des nouvelles technologies conteneurs par exemple.

Une plateforme d’entreprise Low Code gère l’ensemble des tâches : de la construction de l’application à son déploiement, en passant par son exploitation. Le tout avec des ressources humaines inférieures comparées au développement classique.

Plusieurs technologies permettent l’avènement du Low Code je citerais ici les plus importantes à mon avis : les conteneurs (Docker + la partie orchestration avec Kubernetes), la puissance des framework Javascript, la standardisation des terminaux au niveau des technologies WEB (Chromium, WebKit) et pour finir la puissance de calcul et de mémoire des serveurs et terminaux qui n’oblige plus à compter le moindre octet ni le moindre cycle de CPU pour faire fonctionner correctement une appli.

On pourrait m’objecter que c’était justement un problème. Mais, je dirais qu’une barrette de RAM sur une instance cloud ou sur une machine physique revient toujours moins chère qu’un développeur à plein temps.

Les plus importants éditeurs de Low Code sont souvent américains. Et pourtant, nous trouvons des acteurs français / européens et notamment Convertigo. Quelles sont les difficultés pour un éditeur comme vous d’émerger dans ce marché très concurrentiel ?

Certaines plateformes Low Code américaines sont issues de développements européens, néanmoins elles ne présentent pas forcément les garanties que les grands comptes Français et Européens exigent pour leurs besoins :

• La souveraineté des données
• La réduction de la dépendance industrielle et technique
• L’ouverture en cas de changement de politique de tarification du vendeur
• La réduction de la dépendance au vendeur de la plateforme (le fameux « Vendor Lock-in »)

Présenter une plateforme ouverte et standard, construite sur les standards actuels du marché, avec des capacités d’hébergement multi-cloud et souverain, et qui est en plus open source, est notre proposition. D’autre part, nous ne sommes pas inférieurs à la couverture fonctionnelle des concurrents.

Les sujets low code, no code ne sont pas récents mais nous avons l’impression que la crise Covid, avec la transformation numérique, favorise une autre approche du développement et des apps ?

C’est assez logique en fait, l’industrie numérique fait face à un défi majeur : comment gérer un nombre croissant d’application à développer et à déployer avec une pénurie de ressources pour des raisons de coûts ou de disponibilité des développeurs ? Il suffit de voir comme le marché des développeurs IT est tendu et comment la majeure partie des développements d’application a été outsourcée avec tous les soucis que cela pose d’ailleurs … et bien sûr le COVID n’a rien arrangé. On est obligé de faire plus avec moins. C’est une des raisons majeures de l’adoption du Low Code en entreprise.

On parle de Low-Code / no code, de la fin des développeurs. N’y a-t-il pas une confusion ?

C’est un vieux débat. Combien de développeurs codent toujours en assembleur ? Au fur et à mesure de l’évolution de l’industrie IT et de l’informatique, le niveau d’abstraction s’est élevé et c’est normal. Il faut voir le Low Code comme une évolution supplémentaire.

Mais je tiens à rassurer les mordu(e)s des lignes de code : « on écrit du code avec les plateformes Low Code ! ». On en écrit moins et on se concentre sur le code apportant de la valeur. C’est d’ailleurs une des caractéristiques essentielles de la plateforme Convertigo. Elle a été conçue avec l’idée qu’un développeur ne devait jamais être limité par la plateforme et qu’il ait toujours la possibilité de coder directement ce qui est nécessaire pour assurer une fonctionnalité de l’application.

Le Low Code ce n’est pas la fin des développeurs, au contraire ! Et pour celles et ceux qui s’intéressent aux perspectives de carrière, entre 2 développeurs, qui sera mieux payé ? Celui qui délivre et déploie son projet en 10 jours ou celui qui le fait en 100 jours ? J’ai une petite idée de la réponse…

Une plateforme Low Code, finalement c’est quoi ? Un éditeur de code, un éditeur graphique, des connecteurs ? Comment le développeur prend sa place dans ce contexte ? A-t-il accès aux codes générés pour le maintenir ou l’optimiser ?

Ça dépend des plateformes bien sûr, mais en général - et c’est le cas pour Convertigo – la plateforme est constituée par un Studio IDE avec un éditeur graphique. Dans notre solution, nous avons deux éditeurs : un pour les développeurs et un autre pour les développeurs citoyens orientés No-Code. A cela s'ajoutent les environnements d’exécution et de développements des applications. Ils incluent les accès aux bases de données et les connecteurs. La solution peut être utilisée sur le cloud ou en on premises.

Le développeur n’est d’ailleurs pas forcément responsable de la mise en production des applications, les rôles pouvant être distribués au sein de la plateforme.

Chez Convertigo, les processus backends ne sont pas assurés par de la génération de code. Il s’agit plus exactement d’exécution de modèles de données décrits par le Studio. La partie Frontend est basée sur un générateur de code qui fournit tout simplement une application standard Angular, gage de pérennité et de maintenabilité en cas de réversibilité imposée.

Comme dit plus haut, nous donnons accès aux développeurs à tout le code pour qu’ils puissent « customiser » ou adapter à leurs besoins.

Une des critiques que l’on fait souvent aux plateformes Low Code est le verrouillage de l’outil : on ne peut pas avoir de réversibilité (récupérer l’application générée), si on arrête de souscrire à la plateforme, impossible de continuer à utiliser l’application ?

Exact, c’est le fameux « Vendor Lock In » ! Nous répondons à cela par deux réponses :

• L’Open Source
• L’utilisation de frameworks standards tel que Angular

C’est justement tout ce qui nous différencie.  Comment imaginer qu’une entreprise puisse confier ses applications métiers stratégiques à une plateforme si la réversibilité n’est pas assurée ?  Tout comme Gartner, nous (Et les analystes tels que Gartner aussi) pensons que la bonne réponse à cette question est la stratégie Open Source.

Quels sont les usages les plus fréquents que vous voyez au Low code ?

C’est très horizontal au niveau usage métier. Ça peut aller de la maintenance matérielle à l’e-commerce en passant par des processus RH, banque assurance le tout en B2E, B2B et B2C.  Une tendance toutefois : certaines applications qui n’étaient gérées qu’au niveau départemental dans une entreprise pour quelques utilisateurs sont maintenant gérées au niveau global pour l’ensemble de l’entreprise.

Aujourd’hui, quels sont les langages / frameworks que vous utilisez pour générer les codes ? Et sont-ils facilement maintenable ?

La plateforme Convertigo est écrite en Java et fait largement usage des technologies Node,  CouchDB, Docker, Angular et Kubernetes. Pour la partie Frontend, le code généré est du TypeScript. Le développeur Low Convertigo manipule essentiellement des objets Low Code Convertigo mais peut à tout moment écrire du TypeScript ou JavaScript pour assurer ses « customisations ». Il faut bien noter qu’il pourra également intégrer tout composant Angular pour le Frontend et toute librairie JS ou Java pour la partie Backend

Le plus simple est d’aller voir le dépôt GIT de Convertigo : github.com/convertigo/convertigo