Démystifions le low code

Il est temps de faire table rase des fausse idées reçues sur le low-code, et de profiter pleinement de ses avantages pour accélérer la transformation numérique de nos entreprises !

Dans un monde où tout doit toujours aller plus vite, où les utilisateurs souhaitent être de plus en plus autonomes pour des raisons d’agilité et de flexibilité, les promesses des plateformes low-code résonnent favorablement. Cependant, les développeurs professionnels ont tendance à conspuer ces outils et plateformes pour des raisons qui ont pu être réelles à un moment passé, mais qui méritent actualisation et une pincée d’objectivité ! Donc tentons de démystifier l’usage de telles plateformes et de mettre fin à quelques préjugés qui ont la dent dure. Tâche sûrement un peu rude que je vais tenter de relever.

Enterprise Class Application

J’ai souvent entendu : "Le low-code, ce n’est pas fait pour mettre en place des applications critiques", "C’est très bien pour le maquettage, mais pas plus", "Nous on doit délivrer du web desktop et du mobile natif !".

Si on peut entendre ces remarques pour des plateformes no code, je m’inscris complètement en faux pour des plateformes low-code dont le terrain de jeu est vraiment les applications critiques, innovantes et pourquoi pas customer facing. Les cas clients doivent parler d’eux-mêmes et montrent l’étendue des possibles et la variété des applications envisageables peu importe les domaines fonctionnels (applications RH, finance, métier, industrie…), les types d’applications (innovantes, de modernisation du legacy, d’efficacité opérationnelle ou de digitalisation de l’UX) ou les usages (web desktop, mobile natif ou hybride – PWA).

Les outils low-code permettent également de personnaliser finement les applications afin de les intégrer dans un existant applicatif, et de répondre à des contraintes tangibles, sans pour autant économiser sur les bénéfices de rapidité de mise en place.

Techniquement, les plateformes low-code n’imposent rien et l’intégration avec des briques existantes est proposée, aussi bien d’un point de vue organisationnel, que de gouvernance ou de sécurité. En revanche, elles fournissent nativement des outils pour les clients qui ne sont pas équipés ou partiellement (gestionnaire de sources, de build, de suivi projet). Ce, afin de coller au plus près aux contraintes fortes qui peuvent être imposées par les clients, de s’inscrire dans des pratiques DevOps standard, et autoriser une chaîne d’intégration et de livraison continue.

Capacités techniques et rapidité de livraison

"Je ne peux pas faire exactement ce que je veux", "Je vais être limité et contraint" et "Je me suis construit un framework de dev qui me permet d’être très rapide".

On ne peut pas nier qu’une plateforme low-code va imposer un cadre mais elles font preuve d’ouverture avec la possibilité d’invoquer des services de tout type à tout moment, d’injecter du code serveur ou client, de créer des extensions pour des intégrations ou pour de la présentation… on ne sera donc jamais limité. Alors certes, si je dois injecter du code en permanence, je perds l’intérêt d’une telle plateforme… mais sincèrement, en de nombreuses années d’expérience, je n’ai jamais été confronté à un tel besoin par un client.

Supposons qu’il soit nécessaire d’injecter du code sur chacune des pages de mon application. Une plateforme low-code va (et doit) me permettre de créer aisément un modèle de page qui embarque ce besoin afin que je puisse l’industrialiser et le réutiliser dans mes projets suivants sans avoir à faire à nouveau cet effort… Les concepts de la programmation objet sont donc repris en force et étendus au sein d’une telle plateforme.

Quant à la rapidité d’implémentation, si vous avez commencé à développer un framework d’accélération, c’est que vous êtes dans une dynamique low-code. Les plateformes low-code vont avoir l’avantage de reposer sur un historique et une R&D plus conséquents, il y a donc des chances qu’elles aient quelques longueurs d’avance sur vous. Et de prime abord, un développeur professionnel aura également tendance à sous-estimer la charge liée à de nombreuses fonctionnalités annexes qui composent toute application (interfaces d’administration fonctionnelle, gestion des traces, des permissions, les relances…).

La gouvernance des données

"Je n’ai aucune maîtrise sur mes données". Sujet sensible et critique pour les outils low-code en mode SaaS et qui mérite des précisions. La question ne se pose pas lorsque la plateforme ou les applications sont déployées on-premise. Cependant peu importe le mode de déploiement, un outil low-code proposera toujours le choix dans le système qui persistera les données métier.

Par défaut, les données métier vont être hébergées au sein de la base de données sous-jacente au fonctionnement de la plateforme (et donc en ligne), mais le concepteur, grâce aux différents connecteurs pourra décider d’externaliser cet enregistrement vers des systèmes de gestion de données dont vous êtes complètement administrateur. Cela peut se faire grâce à des web services si votre système en expose ou au travers de connecteurs SGBD via des intégrations SQL directes. Dans un souci de gouvernance, l’outil de conception va proposer des visualisations graphiques des connexions et usages des différentes sources.

Si d’un point de vue architecture applicative, on ne souhaite pas multiplier les systèmes de gestion de données et profiter de cet espace de stockage inclus avec la plateforme, les données persistées dans cette base sous-jacente sont nativement cryptées au repos et en transit ; et pour des données hyper sensibles, le concepteur peut même appliquer ses propres clés d’encryptage avant leur sauvegarde.

N’oublions pas également qu’une plateforme low-code se doit de laisser la propriété intellectuelle des applications et des données à ses clients et devra donc leur fournir des outils qui permettent de les extraire quand ils le souhaitent.

Réversibilité et verrouillage fournisseur

"Une fois que j’ai mis le pieds dans la plateforme low-code, je suis bloqué et ne peux plus en changer". Soyons réalistes, on ne peut pas nier qu’il y a du vrai dans cette affirmation, mais elle est à nuancer. Une bonne plateforme de low-code doit proposer des options de sortie à son client, et cela peut se situer à plusieurs niveaux.

Tout d’abord, le besoin de réversibilité n’est pas toujours lié à l’outil en tant que tel mais peut-être lié à l’hébergement des applications. Une organisation peut éprouver le besoin de basculer tout ce qui est hébergé dans un cloud public vers un autre. Une plateforme low-code cloud native est intrinsèquement prête à cela et permettra la bascule de manière très simple grâce à son architecture conteneurisée.

Ensuite, il peut bien évidemment s’agir de changer d’outil, dans ce cas-là, une telle plateforme doit proposer des outils qui vont permettre d’extraire les modélisations, des classes et les données afin de pouvoir les ré-importer dans un autre outil. Ce n’est pas magique non plus, les développements récupérés nécessiteront sûrement une phase de compréhension et vraisemblablement d’adaptation, mais cela a le mérite d’être mis à disposition.

Cependant, n’oublions pas que le challenge attaché à la réversibilité n’est pas lié aux plateformes low-code, c’est le cas pour tout, et je ne parle pas que d’outils. Une application développée avec un framework datant de quelques années, lorsqu’elle aura droit à son refactoring…. Il y a de grandes chances que l’équipe de développement préfère repartir de 0, d’un point de vue technique j’entends (car les connaissances fonctionnelles resteront acquises, ce qui est également vrai pour les plateformes low-code).

Plus besoin des services IT

"Avec le low-code, les services IT ne serviront plus à rien, que vais-je faire ?"

L’objection est ici différente car on est conscient de la valeur et de l’intérêt d’une plateforme low-code, mais si nous n’avons plus besoins d’être développeur professionnel pour mettre en place des applications d’entreprise, que vont faire ces derniers ?

Dans un premier temps, il est important de noter que les services IT conservent toute leur importance. Il y aura besoin de leur compétence sur les parties les plus techniques d’une application (l’intégration avec un nouvel outil, la création d’une extension…). Cela leur permet donc de se concentrer sur des tâches à fort intérêt technique.

Ensuite, la tendance est à la croissance exponentielle des besoins métier et à leur évolution permanente. En permettant à des concepteurs moins expérimentés de participer à la création d’applications d’entreprise et en accélérant la livraison, cela permet aussi de mettre fin aux goulets d’étranglement des ressources IT.

Enfin, n’oublions pas que ces plateformes permettent à des équipes aux profils différents de communiquer autour d’un même univers. Cela permet donc de fluidifier les échanges, de se rapprocher d’un langage commun… et la réconciliation métier/IT n’a pas de prix.

Conclusion

Et si le low-code n’était pas, tout simplement, un nouveau standard de développement. La jeune histoire des langages de programmation a été le réceptacle de nombreuses (r)évolutions, de la carte perforée, au langage objet, en passant par le binaire, l’assembleur et les langages procéduraux… le low-code ou la programmation graphique n’en serait-il pas la prochaine étape ? Les arguments en faveur des passages de l’une à l’autre de ces évolutions ont toujours été : abstraction plus forte, compréhension plus aisée, environnements plus accessibles, démocratisation du processus de développement et amélioration de la rapidité de mise en place… Vous remarquez ? Nous sommes en plein dedans avec le low-code.