Low-code ou code : jusqu'où aller sans développeur

Une responsable des opérations construit en un après-midi le formulaire d’inspection que son équipe attendait depuis des mois. Un commercial relie son tableur au CRM sans ouvrir de ticket. Les outils low-code (on assemble des blocs, on écrit un peu de logique) et sans code (on n’écrit rien) ont rendu cela possible, et c’est une bonne nouvelle. La question n’est pas de savoir s’ils remplacent les développeurs, mais jusqu’où les pousser, et à quel moment le code prend le relais.

Ce que les outils sans développeur font très bien

Leur force tient à une chose : la personne qui connaît le métier construit elle-même, sans traduire son besoin à quelqu’un d’autre. Les cas où ils sont à leur meilleur :

• Les outils internes : un formulaire d’inspection, un suivi de demandes, un tableau de bord sur des données existantes.
• Les automatisations : relier des logiciels entre eux, déclencher une relance, recopier une commande dans le CRM.
• Les prototypes : vérifier qu’un parcours a du sens avant d’investir, au même titre qu’une maquette cliquable.
• Les besoins qui changent vite : l’équipe ajuste elle-même un champ ou une étape, sans attendre une version.

Où ils atteignent leurs limites

Un prix qui grandit avec l’équipe

Les grandes plateformes se paient souvent par utilisateur et par mois, ce qui est raisonnable pour une équipe de dix et devient une ligne importante pour une entreprise de trois cents personnes.

Ces prix, relevés en octobre 2026, ne disent pas qu’un outil est cher : un abonnement qui évite un développement peut être une excellente affaire. Ils disent qu’il faut faire le calcul sur trois ans, avec le nombre réel d’utilisateurs, comme pour sur mesure ou outil du marché.

La logique reste sur la plateforme

On sort facilement ses données d’une plateforme sans code ; la logique de l’application, beaucoup moins. Bubble, par exemple, l’écrit sans détour dans sa foire aux questions : les applications y sont construites visuellement, il n’y a donc pas de code traditionnel à exporter. Bubble précise que l’application et ses données vous appartiennent, propose un export brut de la logique en JSON pour aider à migrer, l’export des données en CSV, et s’engage à publier son code source sous licence libre s’il fermait. C’est honnête et rassurant, mais quitter la plateforme reste une reconstruction.

Les règles complexes et la sécurité

Des règles métier imbriquées, des calculs qui doivent être exacts, des droits d’accès fins entre plusieurs types d’utilisateurs : c’est là que la logique visuelle devient difficile à relire et à tester. Et la sécurité ne se délègue pas entièrement à l’outil : les règles d’accès aux données restent à écrire et à vérifier, comme l’explique la sécurité d’une application. Les outils qui génèrent une application entière à partir d’une description, autre visage du « sans développeur », ont connu des failles de ce type, racontées dans le vibe coding.

Les applications publiques et les stores

Une application pour vos clients, publiée sur l’App Store et Google Play, avec ses notifications, son mode hors connexion, ses abonnements et sa fiche sous votre propre compte développeur, demande un contrôle que les plateformes sans code offrent inégalement. Plus l’application est exposée, plus le code devient raisonnable.

Le low-code ne remplace pas les développeurs

Les outils sans code ont élargi le cercle de ceux qui construisent, et c’est un progrès. Ils n’ont pas rendu le développement inutile : ils ont déplacé une partie du travail des développeurs. Quand une équipe métier construit ses outils, il faut encore quelqu’un pour brancher la plateforme sur les logiciels de l’entreprise, vérifier qui accède à quelles données, surveiller ce qui tourne, et reprendre en code ce qui a dépassé l’outil. Le bon fonctionnement, c’est une équipe métier qui construit vite, et des développeurs qui rendent ces constructions solides.

La voie hybride

Les deux se combinent bien, et c’est souvent le choix le plus économique.

1. 01Valider en low-code.

   Un premier outil construit vite par l’équipe montre ce qui sert vraiment.

2. 02Coder le cœur.

   Ce qui doit être exact, sûr ou exposé au public passe dans une application codée, avec une vraie base de données.

3. 03Garder le low-code autour.

   Les automatisations, les tableaux de bord et les petits outils internes restent entre les mains de l’équipe, branchés sur le cœur par son interface de programmation.

Ce découpage s’écrit dans le cahier des charges de l’application, et pèse sur le prix d’une application comme sur son budget de maintenance. Le cœur codé repose souvent sur un back-end comme ceux que compare Supabase, Firebase ou serveur à soi. Les autres décisions du parcours ont chacune leur article : PWA ou application native, l’application des équipes terrain, les notifications, le portail client, l’IA dans une application et la reprise d’une application abandonnée.

Notre développement d’applications commence par un cadrage écrit, qui dit aussi ce qui peut rester en low-code.

Questions fréquentes

Sources

1. Microsoft, tarifs de Power Apps (nouvel onglet)microsoft.com
2. Google, tarifs d’AppSheet (nouvel onglet)about.appsheet.com
3. Bubble, foire aux questions (nouvel onglet)bubble.io