Le no-code, la révolution qui dévore ses enfants ?

Il y a quelque chose de fascinant dans l’évolution du développement logiciel. Aujourd’hui, sans être développeur, il est possible de construire des systèmes complexes, d’automatiser des tâches et même de générer du code à une vitesse inimaginable. Quand je vois ce qu’on peut faire avec Zapier ou Make, sans écrire un seul script Python, je ne peux m’empêcher de vouloir tout expérimenter. Les possibilités sont folles, et je dois avouer que mon temps libre me sert à jouer avec des outils IA comme Bolt, v0 ou Replit. Cette capacité à « presque » manipuler du code et à assembler des briques sans être un ingénieur, c’est tout simplement grisant.

Récemment, Lovable s’est vu banni de GitHub pour avoir généré un nombre massif de nouveaux dépôts et commits. Un fait anecdotique ? Peut-être. Mais c’est surtout un révélateur : nous entrons dans une époque où le code est produit en quantités industrielles, parfois sans véritable maîtrise, et où la frontière entre « développeur » et « non-développeur » devient plus floue que jamais.

Ce phénomène, on le retrouve aussi dans le no-code. L’idée que n’importe qui peut créer une application sans écrire une seule ligne est puissante et séduit de plus en plus d’entreprises, et on en voit passer ! Accélérer la production, réduire la dépendance aux équipes techniques, raccourcir les cycles de développement… Les promesses sont belles. Mais derrière cette simplicité apparente se cachent des pièges que de nombreuses personnes découvrent à leurs dépens.

Nous assistons ici à une transformation plus profonde, qui va bien au-delà du no-code. L’essor des outils d’IA et du no-code ne remplace pas les développeurs, il reconfigure leur rôle. L’article Personal Software: The Unbundling of the Programmer? analyse cette mutation avec justesse : le software devient plus personnel, les utilisateurs peuvent générer des outils sur-mesure pour leurs besoins spécifiques, là où, auparavant, le développement devait nécessairement viser un marché plus large.

Mais si cette évolution promet pas mal de choses, elle soulève aussi une question : où se situe la frontière entre autonomie et illusion de maîtrise ?

Section intitulée quand-le-no-code-devient-un-frein-plutot-qu-un-accelerateurQuand le no-code devient un frein plutôt qu’un accélérateur

Dans une interview sur la chaîne YouTube Underscore_, Arthur Desutter, fondateur d’Horsaï, partageait son expérience sur les limites du no-code. Il raconte l’histoire de sa boîte qui a investi 45 000 euros dans une application avant de se rendre compte qu’elle était… inutilisable.

Le problème ne venait pas d’un manque d’idées ou de compétences de l’équipe, mais bien des limitations inhérentes aux outils no-code. Dès qu’un projet dépasse le stade du MVP, les contraintes deviennent évidentes : restriction sur le nombre d’utilisateurs, difficulté à structurer les bases de données, absence d’optimisation des performances. Ce qui semblait être une solution rapide et économique se transforme en un obstacle qu’on aimerait éviter 🧘.

Le coût, lui aussi, devient un problème majeur. Ce qui commence comme un abonnement abordable finit par devenir insoutenable. Arthur citait que 95 % de ses coûts opérationnels provenaient des abonnements à des outils no-code 🥴. Une dépendance totale qui finit souvent par imposer une refonte complète… en code. Mais l’un des plus grands risques reste la perte de contrôle sur son propre produit. Contrairement à une application développée sur-mesure, une solution no-code est liée à son fournisseur. Lorsque l’application atteint un certain niveau de complexité, les équipes se retrouvent bloquées, incapables de récupérer leurs données ou d’adapter leur architecture sans repartir de zéro : c’est l’effet boite noir.

Section intitulée l-impact-du-no-code-sur-les-developpeurs-et-le-marche-de-l-emploiL’impact du no-code sur les développeurs et le marché de l’emploi

Si l’essor du no-code et de l’IA transforme la façon dont on conçoit des applications, cela reconfigure aussi le marché du travail des développeurs. Comme l’explique Damien Cavaillès, les formations de développeurs se sont multipliées, mais les offres d’emploi n’ont pas suivi la même dynamique, créant un décalage entre le nombre de compétences sur le marché et les postes réellement disponibles 👔.

Dans ce contexte, le métier de développeur évolue. Il ne s’agit plus seulement de savoir coder, mais de comprendre l’architecture des systèmes, maîtriser le cloud et intégrer des outils existants : « Le cloud en 2025 est le permis de conduire du développeur » .

Cette transformation ne signifie pas la fin du développement, mais un glissement vers des rôles plus stratégiques et polyvalents, où l’optimisation et la capacité à travailler avec des outils automatisés deviennent essentielles.

Section intitulée la-souverainete-des-donneesLa souveraineté des données

Utiliser une plateforme propriétaire signifie remettre entre les mains d’un acteur tiers l’ensemble de son infrastructure et de ses données. Que se passe-t-il si la plateforme change ses conditions d’utilisation ou décide de fermer ? De nombreuses startups découvrent trop tard qu’elles n’ont aucun moyen simple d’exporter leurs données ou de migrer ailleurs 🔐.

Dans ce contexte, les solutions open source apparaissent comme une alternative crédible. Des outils comme n8n ou Directus offrent la flexibilité du no-code si je puis dire, tout en garantissant une maîtrise totale des données et de l’infrastructure.

Section intitulée une-culture-tech-pour-eviter-les-piegesUne culture tech pour éviter les pièges

Le no-code n’est pas une mauvaise idée en soi. Ce qui pose problème, c’est le manque de compréhension des implications techniques de son adoption. C’est précisément ce que j’aborde dans ma formation sur la culture engineering. Mon objectif est d’aider les porteurs de projets à mieux collaborer avec les développeurs, à comprendre les enjeux techniques et à faire des choix éclairés.

Section intitulée le-no-code-fausse-bonne-ideeLe no-code, fausse-bonne idée ?

Loin de remplacer les développeurs, les outils no-code et l’IA génèrent un besoin encore plus grand de compréhension technique. Comme le souligne l’article Personal Software, nous passons d’un modèle où l’on « achète un logiciel » à un modèle où l’on « génère ce dont on a besoin ».

Mais cette flexibilité a un prix : sans culture technique, elle peut vite devenir une impasse. L’avenir du développement appartient à ceux qui savent s’adapter aux nouveaux outils, tout en gardant une solide maîtrise des fondamentaux techniques.

Envie d’en discuter ? Écrivez-nous en commentaire ou rejoignez notre formation sur la culture engineering.