Low code et no code : ce que c’est et quand cela remplace la programmation

On présente souvent le low code comme une version moins chère et plus rapide de la programmation. Ce n’est pas tout à fait exact. Quand vous construisez une application sur une plateforme low code, vous n’écrivez pas un logiciel meilleur marché : vous louez la plateforme de quelqu’un d’autre, avec sa base de données, ses écrans, ses automatisations et sa grille tarifaire. En échange, vous obtenez quelque chose de très précieux : un outil qui fonctionne en quelques jours, sans engager d’équipe. Le prix à payer, c’est de jouer selon les règles d’un autre.

Et c’est très bien ainsi, tant que vous tenez dans ces règles. Pour beaucoup d’outils internes, on y tient pendant des années.

Nous écrivons ceci depuis une position un peu particulière : nous ne vendons pas de plateformes low code et nous ne les mettons pas en place chez nos clients. Nous développons des logiciels en code. C’est précisément pour cela que nous pouvons dire sereinement quand le low code suffit et quand il cesse de suffire — et montrer les limites qu’on ne découvre qu’en lisant la grille tarifaire ou la documentation d’export.

Qu’est-ce que le low code (et en quoi il diffère du no code)

Le low code est une manière de construire des applications à partir de blocs tout faits — formulaires, tableaux, vues et automatisations — sur la plateforme d’un éditeur, avec la possibilité d’ajouter du code là où les blocs s’arrêtent. Le no code, c’est la même chose sans le code : vous assemblez toute l’application dans le navigateur, en glissant des éléments et en définissant des règles.

L’écart entre les deux est plus mince que les noms ne le laissent penser. Dans les deux cas, la plateforme fait l’essentiel du travail et vous décrivez ce qui doit se passer. En no code, la description s’arrête là où s’arrête la prévoyance de l’éditeur : s’il n’existe pas de bloc « envoyer la facture au logiciel comptable », vous ne pouvez pas l’envoyer. En low code, vous insérez à cet endroit un morceau de code — une formule, un script, l’appel d’un service externe — et vous continuez. C’est pourquoi le no code est généralement plus proche d’un tableur, et le low code plus proche de la programmation. Quand on cherche « low code no code » d’un seul tenant, on s’intéresse en général à toute cette famille : des outils qui permettent à des personnes extérieures à l’informatique de construire des logiciels.

Ce que vous apporte une plateforme low code

Une plateforme low code, ce sont quatre éléments fournis par un seul éditeur, que le développement classique vous obligerait à assembler séparément :

• l’hébergement — l’application tourne sur les serveurs de l’éditeur ; vous n’installez ni ne mettez à jour quoi que ce soit ;
• une base de données — des tables d’enregistrements, en général avec une vue qui ressemble à un tableur ;
• des écrans — formulaires, listes, fiches détaillées, tableaux de bord simples ;
• des automatisations — des règles du type « quand un enregistrement change de statut, envoyer un e-mail et créer une tâche ».

Parmi les plateformes low code et no code que vous croiserez probablement figurent, par exemple, Airtable, Microsoft Power Apps, Google AppSheet, Glide et Retool. Elles diffèrent par leur public et leur mode de facturation, mais le modèle reste le même : vous payez un abonnement, et l’application existe aussi longtemps que l’abonnement.

Une application no code n’est pas une automatisation

À côté des plateformes sur lesquelles on bâtit des applications entières, il existe des outils no code qui se contentent de relier des services existants : Zapier, Make, n8n. Ils n’ont ni écrans ni base de données propres — ils font circuler des données entre des systèmes que vous possédez déjà. Quand ils suffisent et comment ils facturent, nous le traitons dans notre article sur l’automatisation des processus. Ici, il est question des plateformes sur lesquelles on construit une application avec ses propres données et ses propres écrans — ce qu’on entend généralement par un outil no code pour créer une application.

Qui est le citizen developer

Le citizen developer est une personne extérieure au service informatique qui construit un outil pour elle-même ou pour son équipe, sur une plateforme low code ou no code. C’est le plus souvent quelqu’un des opérations, de la vente, des ressources humaines ou des finances, qui en a assez de recopier des données d’un tableur à l’autre et qui, en quelques soirées, monte une application qui le fait à sa place.

Cela présente un avantage énorme : le citizen developer connaît le processus mieux que n’importe quel intervenant externe. Personne n’a besoin de lui expliquer pourquoi une commande doit passer par la validation d’un responsable, ni ce que signifie le statut « en attente ». L’application est construite dès le départ autour du travail réel, et non autour d’une idée de ce travail. C’est souvent le premier endroit où le processus est tout simplement mis par écrit.

Cela comporte aussi un risque sérieux : l’application d’une seule personne. Un outil construit par un collaborateur n’est en général compris que par lui. Il sait quelle automatisation en déclenche une autre, pourquoi tel champ est calculé avec une formule étrange et quelle table il ne faut surtout pas toucher. Quand cette personne part en vacances, change de service ou quitte l’entreprise, il reste un outil qui fonctionne, mais que personne ne sait réparer ni modifier. Le problème grandit sans bruit, parce que pendant longtemps tout marche.

Il ne s’agit pas de freiner les citizen developers. Il s’agit de trois règles simples. L’application a un second responsable qui comprend son fonctionnement. Elle dispose d’une courte description : quelles tables, quelles automatisations, qui l’utilise. Et elle est créée sur un compte de l’entreprise, pas sur un compte privé — parce que les données et l’application appartiennent à l’entreprise, pas à la personne qui les a construites.

À quoi le low code se prête le mieux

Le low code donne le meilleur de lui-même quand trois conditions sont réunies : l’application sert à votre équipe et non à vos clients, les utilisateurs sont peu nombreux, et le processus évolue encore. Concrètement, cela donne quatre usages typiques.

Les outils internes. Un inventaire du matériel, une liste d’interventions à traiter, un planning de permanences, un fichier de fournisseurs. Tout ce qui vit aujourd’hui dans un tableur, là où le tableur commence à coincer, parce que plusieurs personnes modifient les mêmes lignes et que personne ne sait qui a changé quoi.

Le prototype d’un processus. Avant de commander un système, vérifiez que le processus que vous avez en tête fonctionne vraiment. Sur une plateforme low code, vous pouvez monter une version utilisable en une semaine et observer, pendant un mois, quels champs personne ne remplit, quelle étape est superflue et laquelle manque. C’est la façon la moins chère de se tromper.

Un formulaire, un tableau et une validation. Une demande de congé, une commande de matériel, un signalement de panne, une demande de rabais. Quelqu’un remplit un formulaire, l’enregistrement arrive dans un tableau, une autre personne l’accepte ou le refuse, et le système envoie une notification. Ce schéma est au cœur de la plupart des plateformes no code, et il y fonctionne très bien.

Un petit nombre d’utilisateurs. La plupart des plateformes facturent par personne. À cinq utilisateurs, c’est un coût modeste ; à cinquante, beaucoup moins. Le low code est le plus avantageux dans une petite équipe.

AppSheet Core : vous l’avez peut-être déjà dans votre abonnement

Si votre entreprise utilise Google Workspace, jetez un œil à AppSheet avant de payer quoi que ce soit d’autre. D’après l’aide destinée aux administrateurs de Google Workspace, AppSheet Core est disponible sans supplément dans la plupart des éditions : Business Starter, Standard et Plus, les éditions Enterprise, ainsi que les éditions Education, Frontline et Nonprofit. Il permet de construire des applications simples à partir des données de Workspace — par exemple d’une feuille Google Sheets — et de les utiliser avec n’importe qui au sein de votre organisation.

Il y a une condition, mais elle compte : les applications créées avec AppSheet Core ne peuvent être partagées qu’avec des personnes de l’organisation. Le partage à l’extérieur, par exemple avec des clients ou des sous-traitants, ainsi que les intégrations avancées exigent la formule AppSheet Enterprise Plus. Pour un outil interne, Core suffit pourtant souvent — et c’est le départ le moins cher possible, puisque vous le payez déjà avec votre abonnement Workspace.

Les limites qu’on ne voit pas au départ

La première semaine avec une plateforme low code est en général un enchantement. Les limites apparaissent plus tard, quand l’application grandit et accumule enregistrements, utilisateurs et exigences. Voici celles qu’il vaut la peine de vérifier avant de commencer. Tous les prix sont en dollars américains, tels que les éditeurs les publient, à la date du 22 septembre 2026.

Le nombre d’enregistrements par base. Chez Airtable, la formule Free contient 1 000 enregistrements par base, la formule Team 50 000 et Business 125 000 (documentation des formules Airtable). Mille enregistrements, c’est moins qu’il n’y paraît : à vingt demandes par jour, cela tient moins de deux mois. Cinquante mille dureront longtemps pour un inventaire de matériel, mais dans la base de commandes d’une entreprise qui en reçoit quelques centaines par jour, la place viendra vite à manquer. S’y ajoute l’espace pour les pièces jointes : 1 Go, 20 Go et 100 Go par base selon la formule.

Le prix par personne grandit avec l’équipe. Airtable Team coûte 20 USD par personne et par mois en facturation annuelle, 24 USD en facturation mensuelle. Business coûte 45 USD à l’année et 54 USD au mois. Power Apps Premium coûte 20 USD par utilisateur et par mois, payé à l’année. Le prix de l’abonnement pour une personne ne dit pas grand-chose. Ce qui compte, c’est combien de personnes utiliseront l’application dans un an ou deux.

À cinq personnes, l’écart entre les formules représente quelques centaines de dollars par an. À vingt personnes sur la formule Business, vous payez 900 USD par mois en facturation annuelle, et 1 080 USD en facturation mensuelle. C’est le moment de calculer ce que coûterait un outil à vous — non pas parce que le low code est cher, mais parce que son coût augmente avec chaque personne que vous engagez, alors que celui de votre propre application, non.

Qui compte comme utilisateur payant. C’est un détail qu’on rate facilement. Sur Airtable gratuit, cinq personnes au plus peuvent travailler avec des droits de modification. Dans la formule Team, vous payez pour toute personne qui peut commenter ou modifier ; dans Business, pour toute personne qui peut modifier ; les accès en lecture seule sont gratuits dans les deux formules. Avant de fixer un budget, établissez qui a réellement besoin de changer quelque chose dans l’application.

Le partage à l’extérieur, dans une formule plus chère. Une application pour l’équipe et une application pour les clients sont, sur beaucoup de plateformes, deux formules différentes. Chez AppSheet, la frontière est nette : Core ne fonctionne qu’au sein de l’organisation, et le partage externe exige Enterprise Plus. Si vous prévoyez qu’un jour des clients ou des partenaires utiliseront l’outil, vérifiez-le avant de commencer, pas le jour où vous les invitez.

Les intégrations. La connexion avec votre logiciel comptable, votre boutique en ligne ou votre base de données ne figure généralement pas dans la formule de base. Dans Power Apps, les connecteurs prédéfinis, personnalisés et locaux font partie de la formule Premium. Avant de choisir une plateforme, dressez la liste des systèmes avec lesquels l’application doit dialoguer et vérifiez dans quelle formule chacune de ces connexions est disponible.

Ce que vous pouvez emporter en partant

On parle en général de la dépendance à un fournisseur (le vendor lock-in) en termes de données : le prestataire vous laissera-t-il les récupérer ? Avec le low code, la question a deux volets, et les réponses diffèrent. Les données, vous les emportez. L’application, non.

Les données : oui, mais morceau par morceau — et aux conditions du contrat

Vous avez peut-être lu que le droit européen protège désormais les clients du cloud contre la dépendance. C’est vrai, mais pas pour vous. Depuis le 12 septembre 2025, le Data Act de l’Union européenne (règlement 2023/2854) oblige les fournisseurs de services cloud, y compris les plateformes SaaS et PaaS, à permettre à leurs clients de changer de fournisseur : un préavis qui ne dépasse pas deux mois, une période transitoire de trente jours calendaires au plus avec l’aide du fournisseur, une spécification exhaustive des données qui peuvent être exportées (art. 25, par. 2) et, à compter du 12 janvier 2027, aucun frais de changement de fournisseur (art. 29). Ces obligations visent toutefois les fournisseurs « fournissant de tels services à des clients dans l’Union » (art. 1, par. 3, let. f). Une entreprise établie en Suisse n’est pas un client dans l’Union.

Et la loi suisse ne comble pas ce vide : elle ne prévoit aucune règle de changement de fournisseur équivalente pour les clients professionnels. La loi fédérale sur la protection des données connaît bien un droit à la remise ou à la transmission des données personnelles (art. 28 LPD), gratuit, mais il appartient à la « personne concernée », c’est-à-dire à la personne physique dont les données sont traitées (art. 5, let. b LPD), et il ne porte que sur les données personnelles « qu’elle lui a communiquées », traitées de manière automatisée avec son consentement ou en relation directe avec un contrat. Il ne donne à votre entreprise aucun droit sur ses données commerciales, et certainement pas celui de sortir sa base de commandes d’une plateforme.

En Suisse, ce que vous pouvez emporter, c’est donc ce que permettent le contrat et les fonctions d’export de la plateforme — rien de plus. Le Data Act reste utile comme liste de contrôle : ces quatre points sont exactement ce qu’il faut chercher dans les conditions, ou demander, avant de construire quoi que ce soit d’important. Un éditeur qui vend dans toute l’Europe vous accordera peut-être les mêmes conditions de toute façon ; faites-les mettre par écrit. Et si l’application contient des données personnelles de vos clients, la plateforme les traite pour votre compte : la LPD exige alors un contrat ou une base légale, et c’est à vous de vous assurer que ce sous-traitant garantit la sécurité des données (art. 9, al. 1 et 2 LPD).

Même quand les conditions sont bonnes, l’export peut être plus laborieux que ne le suggère n’importe quel contrat. La documentation d’export d’Airtable en est un bon exemple. On y lit que :

• on ne peut pas exporter une base entière dans un seul fichier — chaque table se télécharge séparément au format CSV ;
• l’export ne contient ni les commentaires des enregistrements, ni les descriptions des champs, ni le guide de la base, ni les données stockées uniquement dans des extensions ;
• les pièces jointes arrivent dans le fichier sous forme de nom de fichier et de lien, et ces liens expirent au bout de quelques heures — il faut donc télécharger les fichiers tout de suite, pas « un de ces jours ».

Avec une base de dix tables et des milliers de pièces jointes, un déménagement est un projet, pas un clic. Mieux vaut le savoir avant que la base ne grossisse.

L’application : elle reste sur la plateforme

Le second volet pèse plus lourd. Sur une plateforme low code, vous n’avez pas seulement construit des tables de données, mais aussi une logique : automatisations, règles de validation, formules, droits d’accès, écrans et interfaces. Cette logique fait la valeur de l’application — c’est là que votre processus est écrit. Et elle ne tourne que sur la plateforme de l’éditeur.

La documentation d’export d’Airtable citée plus haut ne dit rien des automatisations ni des interfaces. Nous ne prétendons pas qu’on ne peut rien en reconstituer — mais il n’existe aucun fichier que vous pourriez télécharger et faire tourner ailleurs. Une automatisation construite avec les blocs d’une plateforme ne fonctionnera pas sur une autre, pas plus qu’une macro d’un programme ne fonctionne dans un autre. Au moment du départ, la logique se reconstruit de zéro.

C’est pourquoi en low code, la dépendance porte sur la logique, pas sur les données. Les données, vous les récupérerez, peut-être morceau par morceau. Le processus que vous avez inscrit dans l’application, il faudra l’écrire à nouveau. La protection la plus simple ne coûte presque rien : tenez, à côté de l’application, une courte description de ce que fait chaque automatisation et chaque règle. Elle vous servira au moment du départ — et, avant cela, chaque fois que l’application changera de mains.

Où s’arrête notre panneau d’administration et où commence le code

Nous ne mettons pas en place de low code chez nos clients. Nous développons des logiciels en code, et c’est notre point de vue, pas un verdict. Mais la question « que peut-on modifier sans développeur ? » est une question que nous posons dans chaque projet, y compris pour ce site. Et nous y répondons à peu près comme les plateformes low code ; nous plaçons simplement la frontière ailleurs.

Les formulaires se construisent dans le panneau d’administration. Le formulaire de contact, l’inscription à une consultation, chaque formulaire de ce site est assemblé dans le panneau à partir de champs tout faits — texte, e-mail, liste déroulante, date, case de consentement — sans développeur. La personne qui gère le site ajoute un champ, change un libellé ou crée un nouveau formulaire elle-même.

Le brief aussi. Notre brief de projet en plusieurs étapes, que le client remplit avant que nous fassions une offre, a sa structure dans le panneau : les étapes, les sections qu’elles contiennent, les champs de chaque section, avec les règles qui déterminent quand un champ ou une section s’affiche. Modifier une question, ajouter une étape ou une nouvelle option de réponse, c’est une modification dans le panneau, pas une tâche de développeur.

Les calculateurs, eux, sont délibérément dans le code. Les huit calculateurs de coûts de ce site — du site internet au coût d’une panne, en passant par la boutique en ligne — sont des configurations écrites en code et vérifiées par des tests. Nous pourrions les déplacer dans le panneau. Nous ne le faisons pas, parce qu’un calculateur donne un prix, et qu’une erreur de prix coûte de l’argent : le client reçoit une estimation trop basse et bâtit son budget dessus. Un changement de tarif passe donc par un test qui vérifie que le résultat tombe toujours juste.

Il en découle une règle que nous appliquons et recommandons, quelle que soit la plateforme. Ce qui change souvent, et où une erreur se voit et se corrige facilement, va dans le panneau — un libellé de champ, une nouvelle question, la formulation d’un consentement. Ce qui doit être testé avant d’atteindre les gens va dans le code — les prix, les règles de calcul, la logique dont dépendent de l’argent ou des décisions. Une plateforme low code repousse cette frontière très loin du côté du panneau. C’est sa force — et l’endroit où il faut être prudent.

Low code, SaaS du marché ou logiciel sur mesure ?

Le low code n’est pas la seule alternative à la programmation. Souvent, un système du marché conçu pour la tâche précise fait mieux : si vous avez besoin d’un fichier client, un CRM du marché battra presque toujours un CRM assemblé soi-même avec des blocs — nous en parlons dans notre article sur le CRM pour PME. Le low code prend l’avantage là où il n’existe tout simplement aucun système du marché pour votre processus.

Pour beaucoup d’entreprises, le chemin se ressemble : un tableur, puis du no code, puis du low code, et parfois un logiciel sur mesure. Il n’y a aucune raison de brûler les étapes. Il existe en revanche quelques signaux qui indiquent qu’il est temps de passer à la suivante — et, au bout du chemin, trois qui disent que le low code ne suffit plus.

Vous touchez une limite. Celle des enregistrements par base, de l’espace pour les pièces jointes ou des licences dont le coût augmente avec chaque nouvelle personne. Si, chaque trimestre, vous supprimez d’anciennes données pour rester dans la formule, ou si vous repoussez l’invitation de collègues parce que cela coûterait plus cher, la limite a commencé à décider à votre place.

Les clients utilisent l’application, pas seulement l’équipe. Un portail client, des commandes passées depuis l’extérieur, un tableau de bord pour des partenaires. Cela signifie une formule plus chère, des exigences plus élevées en matière d’apparence, de rapidité et de sécurité — et une situation où une panne de la plateforme devient une panne de votre service à la clientèle.

La logique devient le cœur de l’activité. Quand l’application contient votre manière de fixer les prix, de planifier ou de servir vos clients — et que c’est ce qui vous distingue de la concurrence —, la garder sur la plateforme d’un autre, sans possibilité de l’emporter, devient un risque plutôt qu’une économie.

Si vous reconnaissez deux de ces signaux, il vaut la peine de calculer si une application sur mesure serait rentable. Comment le faire, fonction par fonction, nous l’expliquons dans notre article sur le logiciel sur mesure face au logiciel du marché. Si vous n’en reconnaissez aucun, restez sur le low code et ne laissez personne vous vendre davantage.

Par où commencer

Si vous avez un processus qui ne tient plus dans un tableur, commencez par une plateforme low code ou no code — idéalement une que vous payez déjà dans un abonnement. Construisez une version simple, confiez-la à l’équipe pendant un mois et observez. Ne concevez pas tout d’avance : ajoutez un champ quand quelqu’un en a vraiment besoin.

Au passage, faites la seule chose que la plupart des entreprises ne font pas : mettez le processus par écrit. Quelles tables, quels statuts, qui valide quoi, ce qui doit se passer automatiquement. Une telle description prend une heure de travail et rapporte deux fois. D’abord, elle vous protège de l’application d’une seule personne. Ensuite, si l’application dépasse un jour la plateforme, un prototype qui fonctionne, accompagné de sa description, sera le cahier des charges le moins cher et le plus précis que vous puissiez remettre à l’équipe qui construira la version définitive. Au lieu d’hypothèses sur le processus, elle recevra un processus éprouvé par le travail quotidien.

Si vous voyez déjà que le low code ne portera pas votre cas — parce que l’application doit servir des clients, se connecter à vos systèmes ou contenir la logique sur laquelle repose votre activité —, parlons de la question de savoir s’il vous faut un développement de logiciel sur mesure. Pour une vue d’ensemble des applications d’entreprise et des problèmes que chacune résout, voyez notre guide des logiciels d’entreprise.

D’où viennent ces chiffres

• Limites et prix d’Airtable — la page airtable.com/pricing et la documentation des formules sur support.airtable.com/docs/airtable-plans, lues le 22 septembre 2026, prix en dollars américains par personne et par mois.
• Export depuis Airtable — la documentation « Download a view to CSV », support.airtable.com, lue le 22 septembre 2026.
• Prix de Power Apps Premium — la grille tarifaire de Power Apps sur microsoft.com, lue le 22 septembre 2026 ; nous laissons de côté le prix pour un minimum de 2 000 licences, qui ne concerne pas une petite entreprise.
• AppSheet dans Google Workspace — l’aide destinée aux administrateurs de Google Workspace, lue le 22 septembre 2026.
• Règles — règlement (UE) 2023/2854 (Data Act), art. 1, par. 3, let. f, art. 25 et art. 29, sur ce que le droit européen exige des fournisseurs et qui il protège ; loi fédérale sur la protection des données (LPD, RS 235.1), art. 5, let. b, art. 9 et art. 28, état au 7 juillet 2025, texte français de Fedlex.
• Notre panneau d’administration et nos calculateurs — l’état du système sur lequel tourne ce site.