Les limites du low-code dans le développement d’applications métier

Low-code, no-code, citizen-developer… à en croire la presse spécialisée, la tendance aujourd’hui serait de développer des applications sans avoir à saisir une seule ligne de code. L’exemple de Google avec le rachat d’AppSheet pour intégrer le no-code à la plateforme Google Cloud  confirme que tous les grands acteurs semblent s’engager dans cette voie. Mais est-ce bien réaliste ? Et quels en sont les usages concrets ? Car cette tendance à ne plus vouloir développer n’est pas vraiment compatible avec les exigences croissantes de sécurité, de valorisation des données et d’une meilleure expérience utilisateur dans les projets de développement d’applications métier. Nous avons voulu faire le point et démêler le vrai du faux.

Le low-code est assurément une tendance de fond importante dans le développement

Il est évident qu’une plateforme de développement low-code ou no-code est un accélérateur incontournable dans les projets de transformation numérique puisqu’elle permet de créer des applications métier sans devoir réinventer bon nombre d’automatismes et de règles. En revanche, les deux approches sont bien différentes. Le no-code permet de créer des applications métier sans coder en les compilant automatiquement à partir de paramétrages graphiques, tandis qu’une plateforme low-code permet de générer automatiquement l’application ainsi que du code personnalisable pour certains processus particuliers par exemple.

Mais puisque tout, autour de nous, repose sur le numérique et donc des codes de programmation, pourquoi est-ce si important de ne pas coder ? Certes, les gains de temps sont évidents, mais répondre à cette question exige d’abord de se replonger dans la généralisation des outils informatiques au sein des organisations au cours des 25 dernières années…

Quel utilisateur métier n’a jamais eu l’idée géniale d’un outil qui lui simplifierait la tâche mais s’est heurté ensuite au mur de la DSI ? « Impossible »,« C’est trop compliqué », « Nos plannings sont complets et il y a plus urgent ». Ces situations ne sont pas inédites et les utilisateurs métier désiraient depuis longtemps prendre leur indépendance par rapport à la DSI afin de ne plus être freinés dans leurs idées concernant leurs outils. Avec le sentiment de liberté que les applications sur smartphone et le phénomène du BYOD (Bring Your Own Device) ont apporté aux utilisateurs, on assiste aujourd’hui à l’avènement du BYOS (Bring Your Own Software) : ils n’hésitent plus à aller chercher eux-mêmes dans le Cloud des applications prêtes à l’emploi pour parvenir à leurs fins. Malheureusement, cela se fait au détriment de toute cohérence avec les autres applications du système d’information, sans parler des risques majeurs en termes de sécurité et de fuite de données. Une catastrophe !

Les équipes IT n’étant pas extensibles et les stratégies d’externalisation off-shore du développement ayant largement montré leurs limites, c’est tout naturellement que les DSI se tournent vers ces plateformes pour mettre en œuvre plus rapidement des applications répondant aux attentes des utilisateurs métier. Elles contribuent ainsi à réduire le temps nécessaire entre l’expression des besoins métier et leur concrétisation en termes d’outils, ce qui explique leur forte croissance. Mais si leur promesse de simplicité et de rapidité peut être séduisante, rappelons-nous quand même que les applications métier sont bien souvent censées prendre en charge des processus et des données garantissant le bon fonctionnement de l’organisation…

Les usages concrets des plateformes low-code et no-code aujourd’hui

Quand on y pense, l’approche low-code a toujours existé dans les organisations. Qui n’a jamais rencontré l’un de ces fameux collègues dégourdis en informatique qui avait quasiment développé un ERP à partir d’un tableur comme Excel ? D’abord via des formules, puis en l’enrichissant de macros et au final en écrivant du code Visual Basic pour répondre à la complexité croissante des demandes fonctionnelles…

Lorsqu’on creuse les discours de façade des éditeurs positionnés sur le no-code qui prônent le recours à ces utilisateurs métier habiles que l’on appelle désormais « citizen developers », on s’aperçoit rapidement que promettre de ne pas développer une seule ligne de code n’est pas vraiment réaliste. Le discours ne survit pas à la prise en compte des règles de gestion spécifiques à chaque organisation comme dans notre exemple Excel, ni aux questions de confidentialité des données et de sécurité d’accès, ou tout simplement à l’indispensable échange de données avec les autres applicatifs du système d’information.

Arrêtons de nous bercer d’illusions, il y a toujours du code à écrire quelque part pour garantir le bon fonctionnement d’une application métier. En revanche, il y a aussi beaucoup de codes qui peuvent être mutualisés et réutilisés voire même générés automatiquement par des paramétrages issus d’une plateforme low-code. On parvient ainsi à un meilleur compromis entre la conception simplifiée des grandes lignes de l’application métier dans la plateforme et l’écriture de code personnalisé sur les 20 % restants afin de tenir compte des spécificités de l’organisation. Mais là encore, ne nous voilons pas la face : si les citizen developers jouent un rôle clé dans les projets de transformation numérique, grâce notamment à leur capacité de contribuer au lien entre utilisateurs finaux et équipes IT, ils ne sont pas toujours à même de développer du code et il faut à un moment ou un autre redonner la main à la DSI ou au partenaire expert.

Les limites d’une approche low-code pour la création d’applications métier

Soyons clairs, si l’on veut répondre rapidement à un besoin ponctuel et faire face, par exemple, à un pic d’activité, un salon ou un événement particulier, la DSI peut laisser les utilisateurs métier créer eux-mêmes une application no-code voire même recourir à un outil dans le Cloud. Mais sans intégration avec le reste du SI, ni partage sécurisé des données avec d’autres processus, l’application métier en question aura nécessairement une durée de vie limitée.

Les limites de l’approche low-code ou no-code sont donc perceptibles dès l’expression du besoin. Si l’on s’écarte de besoins basiques et individuels pour arriver sur des sujets nécessitant d’interagir entre collègues via des workflows collaboratifs manipulant de près ou de loin des processus documentaires de GED, des arbitrages sont vite nécessaires et les dimensions indispensables de Sécurité/Conformité et Pérennité/Évolutivité exigent alors que la DSI garde le contrôle.

Le recours à une plateforme low-code dans le cadre de projets de transformation numérique doit donc nécessairement rester encadré par la DSI pour assurer la gouvernance nécessaire et garantir la pérennité des applications métier développées au sein du SI. Loin de nous l’idée de minimiser l’importance des besoins métier et la compétence des utilisateurs finaux qui sont déterminants pour la réussite du projet, mais la réponse applicative à ces besoins nécessite de se poser les bonnes questions sans se précipiter sur des réponses toutes faites.

C’est précisément pour pouvoir proposer le meilleur compromis entre la capacité à répondre rapidement aux besoins métier et celle de préserver la cohérence du SI, que notre plateforme de développement permet de générer automatiquement le tronc commun de l’application métier tout en laissant la possibilité aux développeurs de le personnaliser. Cela permet à la DSI d’utiliser une plateforme dans laquelle les paramétrages autour des processus documentaires vont déterminer automatiquement les droits d’accès et actions possibles de chacun puis d’ajouter le code nécessaire pour gérer les spécificités métier en fonction du cycle de vie de l’information.

parler expert