Low-code, c'est quoi ? Quand l'utiliser en PME

Assembler un outil ou le faire développer : le vrai arbitrage

Le scénario est classique dans les PME.

Quelqu'un dans l'entreprise, souvent quelqu'un de très bien, monte rapidement un outil qui règle un vrai problème. Suivi des interventions, gestion des devis, planning d'équipe. Ça marche. L'outil s'étend. Quelques années plus tard, il porte un processus critique. Il est devenu impossible à faire évoluer. Et la personne qui l'a construit est partie.

Ce n'est pas un argument contre le low-code.

C'est un argument pour poser, dès le départ, la seule question qui compte : cet outil sera-t-il encore là dans trois ans, et qui s'en occupera ?

TL;DR : le low-code permet de construire une application avec peu ou pas de programmation, grâce à des interfaces visuelles. Pour une PME, c'est un très bon choix pour un outil interne au périmètre stable et à faible enjeu. Il devient risqué quand l'outil porte un processus critique, doit s'intégrer finement à d'autres systèmes, ou fait partie de ce que l'entreprise vend.

Le low-code, c'est quoi ?

Le low-code regroupe les plateformes qui permettent de construire une application en assemblant des composants visuels, avec peu ou pas de programmation. On y définit des formulaires, des règles et des enchaînements par configuration plutôt qu'en écrivant du code.

Le no-code, son voisin, supprime complètement l'écriture de code. La frontière est floue, et surtout commerciale. La plupart des outils dits no-code proposent, dès qu'on sort du cas simple, un endroit où écrire une formule ou un script. Savoir lire un peu de code reste donc un atout, même quand l'IA en écrit une bonne partie : c'est la question que pose notre article faut-il encore apprendre à coder à l'ère de l'IA ?.

Est-ce réservé aux informaticiens ? Non, et c'est l'argument de vente. La documentation Microsoft sur Power Apps présente ces plateformes comme destinées aux développeurs autant qu'aux utilisateurs métier. Dans une PME, c'est presque toujours un profil métier qui construit le premier outil.

Le marché va du tableur amélioré aux plateformes spécialisées dans les applications métier, comme Flexio, dont nous avons intégré le site.

Cette accessibilité est un vrai bénéfice. C'est aussi la source des difficultés suivantes. Un outil construit par une seule personne, sans documentation ni règles, devient vite une dépendance invisible.

Les cas où c'est clairement le bon choix

Quand l'outil est interne, stable, peu stratégique, ou qu'il sert à valider une idée avant d'investir.

L'outil interne au périmètre stable. Un suivi de demandes, un annuaire, un formulaire de saisie terrain. Le besoin est clair, il bougera peu, et l'enjeu n'est pas stratégique.

Le prototype avant investissement. Avant d'engager un développement sur mesure, une version fonctionnelle montée rapidement permet de vérifier que le processus imaginé tient dans la vraie vie. C'est souvent le meilleur usage : le low-code sert de maquette qui fonctionne, pas de destination.

L'automatisation entre outils existants. Faire circuler une information entre un formulaire, une messagerie et un tableur ne justifie pas un développement. C'est exactement ce que ces plateformes font bien.

Le besoin urgent avec un budget serré. Quand l'enjeu est de tenir le temps de valider un besoin, et pas de construire pour dix ans, le calcul penche nettement de ce côté.

France Num, le dispositif public d'accompagnement des entreprises au numérique, propose des guides pour les TPE et PME. Ils aident à cadrer ce type de besoin avant de choisir un outil.

Les trois limites qu'on découvre tard

Le plafond fonctionnel, la facture qui grossit avec l'usage, et l'impossibilité de partir.

Le plafond fonctionnel. Tant que le besoin reste dans ce que la plateforme a prévu, tout va vite. Le jour où il faut une règle métier particulière, un calcul spécifique ou une interface hors gabarit, on entre dans les contournements. Ils fonctionnent, puis cassent à la mise à jour suivante de la plateforme.

La tarification à l'usage. Le coût est faible pour cinq utilisateurs et quelques centaines d'enregistrements. Il grimpe avec le nombre d'utilisateurs, le volume de données et les automatisations. Un outil bon marché au démarrage peut coûter beaucoup plus cher une fois adopté par toute l'équipe, sans que personne ne l'ait décidé.

La réversibilité. C'est la limite la plus sérieuse, et la moins anticipée. Vos données s'exportent en général. Votre logique métier, non : règles, enchaînements et automatisations vivent dans un format propriétaire. Changer de plateforme, c'est tout reconstruire.

Microsoft aborde ce point dans ses recommandations de gouvernance pour Power Platform. Elles insistent sur la nécessité d'organiser la propriété et la supervision des applications créées. La lecture vaut même si vous utilisez une autre plateforme : elle donne la liste des questions à se poser.

La question des données, souvent oubliée

Une plateforme low-code héberge vos données chez elle, ce qui en fait un sous-traitant au sens du RGPD, avec les obligations qui vont avec.

La CNIL rappelle, dans sa définition du sous-traitant, que le responsable de traitement doit s'assurer des garanties de ce prestataire et encadrer la relation par contrat. Si votre outil stocke des données de clients ou de salariés, vous devez savoir où elles sont et ce que l'éditeur en fait.

Beaucoup de ces plateformes sont américaines. Cela ne les disqualifie pas, mais ajoute une étape. Les transferts hors Union européenne ne sont possibles que dans les conditions décrites par la CNIL dans son cadre général sur les transferts de données, et vous devez pouvoir le documenter.

C'est une raison de plus pour réserver le low-code aux données peu sensibles, quand c'est possible.

Vous hésitez entre assembler un outil et le faire développer ? Nous cadrons ce choix au démarrage de chaque projet d'application métier sur mesure. Devis gratuit et sans engagement.

Low-code ou sur mesure : comment décider ?

En répondant à quatre questions, dans cet ordre.

Cet outil porte-t-il un processus critique ? Si son arrêt bloque la facturation, la production ou la relation client, dépendre d'un éditeur devient un risque d'exploitation, pas un sujet informatique.

Fait-il partie de ce que vous vendez ? Si oui, il fait partie de la valeur de l'entreprise. Une valeur qui vit dans une plateforme tierce, et qu'on ne peut pas transférer, pose un vrai problème le jour d'une cession ou d'une levée. C'est le cas de Funela, une plateforme B2B pour le secteur funéraire, développée sur mesure avec un matching géolocalisé et une gestion des abonnements.

Le périmètre va-t-il bouger ? Un besoin stable s'accommode très bien du low-code. Un besoin qui se précisera avec l'usage finira par toucher le plafond.

Qui s'en occupe dans deux ans ? Si la réponse est une seule personne, non remplaçable, le problème n'est ni le low-code ni le sur mesure. C'est l'organisation.

Ce que ça coûte réellement dans la durée

La comparaison honnête ne se fait pas au démarrage, mais sur toute la durée de vie de l'outil.

Pour un outil interne modeste, le low-code reste en général moins cher. L'écart se resserre quand le nombre d'utilisateurs augmente. Il s'inverse quand une évolution majeure oblige à tout reconstruire ailleurs.

Le raisonnement est le même que pour un site web. Ce qui compte n'est pas le montant initial, mais le coût rapporté à la durée pendant laquelle vous garderez l'outil.

Questions fréquentes

Quelle différence entre low-code et no-code ? Le no-code supprime toute écriture de code. Le low-code en autorise une part pour les cas particuliers. En pratique, la plupart des projets d'entreprise finissent par avoir besoin de cette part.

Le low-code remplace-t-il un développeur ? Pour un outil interne simple, souvent oui. Pour une application qui porte de la valeur métier, non. Le travail se déplace vers la conception, l'intégration et la gouvernance, il ne disparaît pas.

Peut-on récupérer ce qui a été construit en low-code ? Les données, presque toujours. La logique métier, très rarement. C'est le point à vérifier avant de s'engager.

Un site web peut-il être fait en low-code ? Oui, et pour un site vitrine simple c'est parfois pertinent. Les limites apparaissent sur la performance, la finesse du référencement et la personnalisation. Les critères sont détaillés dans notre guide de création de site internet pour PME.

Comment éviter que l'outil devienne ingérable ? Documenter dès le départ. Désigner deux personnes plutôt qu'une. Revoir chaque année le coût et le périmètre. La plupart des situations bloquées viennent de l'absence de ces trois réflexes.

Gagner du temps ou gagner de l'argent

Le low-code n'est ni un raccourci miracle ni un piège. C'est un arbitrage entre vitesse de mise en œuvre et maîtrise dans la durée.

La règle tient en une phrase : utilisez le low-code pour ce qui vous fait gagner du temps, faites développer ce qui vous fait gagner de l'argent.

Vous avez un outil interne qui commence à montrer ses limites ? Parlons de votre projet. Devis gratuit et sans engagement.