Pour moi cette objection puise sa source dans plusieurs incompréhensions ou malentendus. En voici les raisons.

Ne pas mélanger low-code et no-code

Tout d’abord, beaucoup trop de personnes confondent encore le low-code et le no-code. D'ailleurs, la prochaine fois que je reçois un RFP intitulé "no code / low-code", je jette ma souris par la fenêtre. C'est comme si l’intitulé de l’appel d’offres se lisait bateau / avion. Aucun rapport si ce c’est que ce sont tous les deux des moyens de transport.

Pour clarifier, le low-code et le no-code sont deux solutions distinctes qui ne s'adressent pas aux mêmes utilisateurs, n'ont pas la même philosophie, ne s'inscrivent pas du tout dans la même vision IT et surtout ne résolvent pas les mêmes problématiques métier. Après il faut reconnaître aussi que les analystes n'aident pas car eux même mélangent low-code, no-code, solutions de BPM et solutions de XRM.

La principale différence entre les deux est que les solutions no-code, faites pour les citizen developers, sont des solutions qui ont des environnements de configuration fortement contraints. Et c'est normal, à partir du moment où l’on adresse des gens n'ayant pas de compétence en développement il faut masquer la complexité sous-jacente avec un outil de configuration de très haut niveau qui a un but bien précis et qui ne permet pas, par exemple, de faire du pixel-perfect, de faire des intégration complexes, de modifier les index des tables, de modifier des feuilles de style et surtout, de prendre en compte des besoins métier qui sortent du cadre de ce pour quoi la solution no-code est faite. Est-ce acceptable pour un développeur ? Bien évidemment non.

Alors que les solutions low-code natives ont été conçues dès le départ pour fournir aux développeurs tout ce dont ils ont besoin pour créer des applications d'entreprise modernes, sans les contraindre, quel que soit le besoin métier. Alors bien évidemment la contrepartie est que ces solutions s'adressent avant tout à l'IT, mais au final c'est un moyen de combiner le meilleur des deux mondes : les développeurs ne sont pas limités dans la réponse aux besoins qu'ils peuvent apporter (en adéquation avec le monde du développement spécifique) et en même temps grâce au low-code ils vont aller deux à quatre fois plus rapidement dans la mise en oeuvre.

Les développeurs veulent faire du code

En tant qu'ancien développeur je m'inscris en faux. Effectivement, on ne convertira jamais des data scientists qui font du Python, des passionnés du codage ou autre aficionados du développement pour le développement. Et tant mieux. Mais dans 90 % des cas les développeurs adoptent des solutions low-code très naturellement et cela pour une raison très simple : Les développeurs ne font pas du COBOL, du C#, du Java, du JavaScript, du React, du Vue.JS, du Laravel ou du Python parce qu’ils aiment écrire du code. Non, ils utilisent ces langages pour fournir une réponse à une problématique métier.

Pour la grande majorité des développeurs, le code n’est qu’un moyen. Même si certains initialement peuvent être sceptiques, après avoir testé les solutions de low-code, la discussion n’est plus du tout la même. Comme on dit, l’essayer c’est l’adopter. Quand les développeurs réalisent qu'avec une vraie solution low-code ils vont pouvoir fournir la même valeur au métier mais 2 à 4 fois plus rapidement, ils deviennent souvent les premiers et les plus ardents défenseurs de la solution.

Par Alexandre Cozette, Lead Solutions Architect chez Outsystems