Chapitre 8.10Le no-code et le low-code

Et si tu pouvais créer un site web, une application ou automatiser des tâches répétitives sans écrire une seule ligne de code ?

C'est la promesse du no-code et du low-code, un mouvement qui a beaucoup grandi ces dernières années en démocratisant l'accès à la création d'outils numériques. Ce chapitre te donne de quoi juger quand c'est une excellente idée, et quand c'est une dette qui s'accumule.

Une idée plus vieille qu'elle n'en a l'air

Le terme est récent, la démarche ne l'est pas du tout. Depuis quarante ans, l'informatique cherche à mettre la création d'outils entre les mains de ceux qui en ont besoin.

Les tableurs ont été le premier grand succès du genre. Une formule dans une cellule, c'est déjà de la programmation, simplement débarrassée de tout l'appareillage technique. Sont venues ensuite les bases de données bureautiques des années 1990, les éditeurs de sites en glisser-déposer, puis les systèmes de gestion de contenu comme WordPress, qui ont permis à des millions de gens de publier un site sans savoir ce qu'est une balise HTML.

Ce qui a changé récemment, c'est la puissance des outils et surtout leur capacité à se parler entre eux. Un outil no-code moderne ne vit pas isolé, il se branche sur ton CRM, ta messagerie et ton système de paiement via leurs API. C'est cette connectivité qui a fait passer le no-code du bricolage au véritable outil de travail.

No-code vs low-code

La distinction tient en deux lignes.

• No-code : aucune connaissance en programmation requise. L'interface est entièrement visuelle, tu glisses-déposes des éléments, tu configures des règles, tu connectes des services. Notion, Airtable, Webflow, Bubble ou Glide appartiennent à cette famille.
• Low-code : l'essentiel se fait visuellement, mais les cas particuliers demandent d'écrire un peu de code. C'est un intermédiaire entre le no-code et le développement traditionnel, souvent destiné aux équipes techniques qui veulent aller plus vite. Retool, OutSystems, Mendix ou la Power Platform de Microsoft se rangent ici.

En pratique, la frontière est floue et essentiellement commerciale. La plupart des outils vendus comme "no-code" finissent par proposer un champ où l'on peut glisser une formule, une condition ou un bout de JavaScript. Et c'est souvent à ce moment précis que le projet quitte le confort de l'interface visuelle.

Les cas d'usage

Le no-code brille sur quatre terrains bien identifiés.

• Les automatisations : Zapier, Make (anciennement Integromat) ou n8n connectent des services entre eux sans code. "Quand un formulaire est soumis, crée une ligne dans le tableur, envoie un email au client et ajoute une tâche dans l'outil de suivi." C'est probablement l'usage au meilleur rapport temps investi sur temps gagné.
• Les sites vitrines et les pages de campagne : Webflow ou Squarespace permettent de produire un site professionnel sans mobiliser un développeur, et surtout de le modifier sans passer par un cycle de mise en production. Pour une équipe marketing qui lance dix pages par trimestre, l'autonomie change tout.
• Les outils internes : Airtable, Notion ou Retool remplacent avantageusement le tableur partagé qui a dérivé en base de données officieuse. Suivi de candidatures, gestion de stock, planning éditorial, ce sont exactement les besoins qu'une équipe technique n'aura jamais le temps de traiter.
• Les prototypes : valider une idée auprès de vrais utilisateurs avant d'investir dans un développement complet. Monter une place de marché fonctionnelle en deux semaines pour vérifier que quelqu'un veut bien s'en servir, c'est une économie considérable, y compris quand la réponse est non.

Les limites

Le no-code a des frontières nettes, et mieux vaut les connaître avant de les percuter.

• La personnalisation : tu es limité à ce que l'outil a prévu. Tant que ton besoin reste dans le cadre, tout va très vite. Dès qu'il en sort, tu te heurtes à un mur, et il n'y a pas de solution de contournement propre.
• La performance : les applications no-code sont généralement plus lentes qu'un développement sur mesure, car l'outil doit rester générique. Pour un produit minimum viable ou un outil interne utilisé par vingt personnes, aucun problème. Pour une application grand public à forte charge, c'est rarement tenable.
• Le coût qui s'inverse : ces plateformes facturent souvent à l'utilisateur, à l'enregistrement ou à l'automatisation exécutée. Très bon marché au démarrage, la facture peut devenir déraisonnable quand le volume grimpe, exactement au moment où le projet réussit.
• La dépendance : ton application repose entièrement sur un outil tiers. Si son éditeur augmente ses prix, change ses conditions ou ferme, tu as peu de recours. Contrairement à du code que tu possèdes, la logique métier construite dans une interface visuelle ne s'exporte généralement pas. Avant de t'engager sur un outil structurant, pose la question de ce que tu peux récupérer si tu pars, et sous quelle forme.
• La complexité qui se retourne : dès que la logique métier s'élabore, le no-code devient plus pénible que le code. Un arbre de règles visuelles avec cinquante conditions imbriquées est un cauchemar à relire, impossible à tester automatiquement et très difficile à reprendre quand son auteur a quitté l'entreprise.

Ce dernier point est le plus sous-estimé. Un flux no-code n'a ni historique de versions, ni revue de code, ni tests automatisés dans la plupart des outils. Ce sont pourtant les mécanismes qui permettent à un logiciel de durer. On y retrouve donc, en accéléré, tous les symptômes de la dette technique.

La question de la gouvernance

Quand n'importe qui peut créer un outil qui manipule des données clients, une question se pose vite. Qui sait ce qui existe, et qui en est responsable ?

Le phénomène porte un nom, l'informatique de l'ombre. Une automatisation créée par une personne sur son compte personnel, qui tourne depuis deux ans, dont plus personne ne connaît le fonctionnement, et qui s'arrête le jour où cette personne part. C'est extrêmement courant.

Trois précautions suffisent à limiter les dégâts. Créer les automatisations sur des comptes d'équipe et non personnels. Tenir un inventaire, même sommaire, de ce qui existe et de qui en a la charge. Et vérifier, dès que des données personnelles circulent, que l'outil est compatible avec tes obligations RGPD, notamment sur la localisation de l'hébergement et la sous-traitance.

Le no-code remplace-t-il les développeurs ?

Non. Il déplace la frontière de ce qui vaut la peine d'être développé.

Le no-code excelle sur les besoins simples, spécifiques à une équipe, qui ne justifient pas un développement sur mesure et n'auraient donc jamais été traités. Un chef de produit qui automatise son reporting, un marketeur qui publie une page de campagne sans attendre le prochain déploiement, ce sont des heures de développement économisées et surtout des semaines d'attente évitées.

Les développeurs, eux, se concentrent sur ce que le no-code ne sait pas faire, les systèmes complexes, les intégrations poussées, la performance à grande échelle, la sécurité. Et souvent, ils reprennent en développement classique les outils no-code qui ont trop bien marché.

L'arrivée de l'IA générative rebat une partie des cartes, puisqu'elle permet désormais de décrire un besoin en français et d'obtenir du code fonctionnel. Paradoxalement, cela ne rend pas le no-code obsolète, mais cela déplace encore la ligne. Le problème reste le même dans les deux cas, produire quelque chose qui marche est devenu facile, le faire durer, le sécuriser et le maintenir ne l'est toujours pas.

Comment décider

De mon expérience, trois questions suffisent à trancher avant de démarrer.

Ce que je construis est-il temporaire ou destiné à durer plusieurs années ? Manipule-t-il des données sensibles ou de l'argent ? Combien de personnes l'utiliseront dans deux ans ?

Un besoin temporaire, sans données sensibles, pour une poignée d'utilisateurs, c'est un cas d'école pour le no-code, et hésiter serait du gâchis. Un système durable, critique, destiné à monter en charge, mérite un vrai développement dès le départ. Entre les deux, l'approche hybride est devenue la norme, no-code pour valider l'idée, développement sur mesure quand le produit a trouvé son marché.