Code, No-Code et Low-code

Cet affrontement entre adeptes du “No-Code”, du “Low-code”, et du code tout court me laisse un peu perplexe. On voit bien le potentiel de ces nouveaux outils mais certains semblent vouloir jeter tout ce qui s’est fait auparavant. D’autres rejettent en bloc ces concepts et ne jurent que par le dev custom en toutes circonstances.

Entre les deux, il y a sûrement un juste milieu à trouver mais force est de constater que le débat est polarisé.

No-Code et low-code

Les plateformes No-Code et Low-Code permettent de créer et déployer des projets avec des interfaces graphiques au lieu du code à la main. Peu voire aucune compétence technique n’est nécessaire pour créer une appli, juste du glisser-déposer et l’assistance visuelle (ex: WYSIWYG).

Au lieu de coder ligne par ligne, les utilisateurs vont manipuler des blocs et des structures pré-formatées ce qui facilite le travail et fait gagner un temps fou. L’idée est de consacrer le temps à ce qui apporte de la valeur en s’épargnant les étapes habituelles et répétitives de codage.

Les deux concepts sont donc des alternatives au dev traditionnel mais il y a des différences notables. Contrairement au No-code où tout est intégré directement dans le framework, les solutions Low-Code peuvent exiger des savoirs techniques.

Comment choisir entre les deux

L’approche No-Code est particulièrement efficace pour les petits projets et permet aux devs de se concentrer sur des tâches plus essentielles. N’importe qui ou presque va pouvoir “pondre” la mini-appli rapidement, ce qui apporte certains avantages:

  • le TTM (time to market) est fortement réduit
  • on réduit les communications inutiles entre les devs et certains pôles ou services de la boîte
  • on s’épargne de longs circuits de validation interne

L’approche Low-Code sera plus taillée pour des projets spéciaux, par exemple, des applications ponctuelles qui nécessitent plus de flexibilité que ne peut en fournir le No-Code.

Dans ce cas-là, on ne pourra pas confier le projet à ces “non-techniques” mais ce sera beaucoup plus rapide qu’un dev personnalisé classique la plupart du temps.

Alerte au Bullshit 🚨

Le No-Code et le Low-Code ne semblent pas être des mots-valise mais une tendance de fond, directement observable en entreprise. D’ailleurs, bon nombre de projets devraient se baser sur ces approches dans les années à venir selon les projections.

En revanche, les termes comme “no-code” ou “serverless” m’emmerdent assez car on fait comme s’il n’y avait rien derrière, ce qui caractérise bien un terme creux.

Il faut des serveurs dans une architecture serverless, c’est juste la plateforme qui se charge de l’installation et de la maintenance pour l’utilisateur.

De la même façon, “no-code” ne veut pas dire “0 code”. Il faut bien des devs pour coder et maintenir les interfaces graphiques et le glisser-déposer.

C’est exactement pareil avec le “low-code.” Il n’y pas moins de code, c’est juste le framework qui va prémâcher le travail.

Je comprends bien le côté marketing de l’affaire pour vendre les concepts mais certains adeptes semblent s’être mis en mode évangélistes.

Low-Code et No-Code sont-ils surcôtés?

Beaucoup de critiques dénoncent un effet pervers connu sous le nom anglais de shadow IT. Dans cette configuration, les devs n’étant pas impliqués dans le processus, des problèmes de conformité et de sécurité apparaissent.

En gros, Régis* a pondu un site tout cassé et vérolé, et c’est au dev de venir réparer les dégâts, alors que l’idée de base était de le laisser se concentrer sur d’autres sujets plus importants.

Pour les mêmes raisons, ces approches entraînent parfois des coûts additionnels d’infrastructure car la base code n’est pas bien optimisée pour un usage intensif.

Le Low-Code peut aussi avoir des incompatibilités majeures avec la stack de projets existants dans une organisation, ce qui fait perdre un temps fou, alors que l’idée de base était justement d’en gagner.

*Je n’ai rien contre le prénom Régis, c’est une référence à la pop culture des années 90.

Il faut choisir maintenant

Rejeter en bloc le “Low-code” et le “No-code” est un non-sens pour moi, tout comme dire “le dev c’est fini”.

Certains projets n’auront pas besoin de dev personnalisé et pourtant ils pourront dégager des revenus importants. C’est ça l’efficacité !

De manière réciproque, on essaiera de ne pas gâcher du temps de dev sur des tâches basiques sans aucune valeur ajoutée.

Pour autant, on ne peut pas avoir le beurre et l’argent du beurre, et espérer la même modularité qu’avec du code à la main conçu par un expert. Ce n’est pas réalisable pour le moment.

Pour ma part, j’aime bien l’approche Low-Code pour certains projets très simples qui s’y prêtent bien. Je suis un peu plus dubitatif sur le No-Code dans sa forme actuelle.