No-code et low-code : ce qu'une PME peut construire elle-même
Un responsable administratif qui relie un formulaire en ligne à une base de données, puis déclenche l’envoi automatique d’un e-mail de confirmation, sans écrire une ligne de code : c’est désormais à la portée de beaucoup de petites entreprises. Les outils dits « no-code » et « low-code » ont ouvert un espace entre le tableur bricolé et le logiciel développé sur mesure. Encore faut-il savoir ce qu’on peut raisonnablement y construire.
Deux termes, une même idée
- Le no-code désigne des outils qui permettent de créer des applications, des bases de données ou des automatisations par des interfaces visuelles : glisser-déposer, menus, règles du type « quand ceci arrive, faire cela ». Aucune programmation n’est nécessaire.
- Le low-code repose sur le même principe visuel, mais autorise l’ajout de code pour aller plus loin. Il s’adresse plutôt à des profils techniques ou à des équipes qui disposent d’un minimum de compétences en développement.
La frontière est floue et la plupart des outils se situent quelque part entre les deux.
Ce qu’une PME peut construire
Les usages qui fonctionnent bien sont ceux d’une complexité modérée, utilisés en interne :
- des bases de données partagées qui remplacent un tableur devenu ingérable : suivi de prospects, parc de matériel, registre des interventions ;
- des formulaires de demande, d’inscription ou de réclamation, reliés à une base ;
- des automatisations entre logiciels existants : créer une fiche client quand un formulaire est rempli, envoyer une notification, copier une information d’un outil à l’autre ;
- de petites applications internes : demande de congés, validation de notes de frais, suivi de commandes ;
- des tableaux de bord qui rassemblent des chiffres issus de plusieurs sources ;
- des prototypes, pour tester une idée avant d’investir dans un développement plus solide.
Si votre réflexion porte sur la sortie du tableur pour la relation client, comparez avec un outil standard : voir tableur ou CRM.
Les limites à connaître
| Limite | Ce que cela signifie |
|---|---|
| Dépendance à la plateforme | L’application n’existe que sur l’outil qui l’héberge ; on ne peut généralement pas l’emporter ailleurs |
| Volume et performance | Au-delà d’un certain nombre d’enregistrements ou d’utilisateurs, l’outil ralentit ou impose une offre supérieure |
| Logique complexe | Les règles métier très ramifiées deviennent illisibles dans une interface visuelle |
| Coût qui croît avec l’usage | Tarification par utilisateur, par enregistrement ou par automatisation exécutée |
| Sécurité et droits | Gestion des accès parfois sommaire pour des données sensibles |
| Localisation des données | Hébergement souvent hors de l’Union européenne, à vérifier |
Ces limites ne disqualifient pas le no-code, mais elles indiquent où il s’arrête. Un outil qui devient critique pour l’activité, manipule des données sensibles ou dépasse quelques dizaines d’utilisateurs mérite une réflexion plus approfondie, présentée dans logiciel sur mesure ou SaaS.
Le risque principal : l’application que personne ne comprend
Le danger le plus fréquent n’est pas technique, il est organisationnel. Une personne motivée construit un outil utile, le fait évoluer au fil des besoins, puis quitte l’entreprise ou change de poste. Personne ne sait plus comment fonctionnent les automatisations, ni pourquoi telle règle existe. On parle parfois d’« informatique fantôme » pour désigner ces outils créés hors de tout cadre.
Quelques règles simples limitent ce risque :
- Documenter : une page qui décrit ce que fait l’outil, ses automatisations et qui l’administre.
- Avoir au moins deux administrateurs, pour ne pas dépendre d’une seule personne.
- Utiliser des comptes d’entreprise, pas des comptes personnels créés avec une adresse privée.
- Recenser les outils utilisés, avec les données qu’ils contiennent.
- Exporter régulièrement les données, en complément d’une stratégie de sauvegarde.
Les précautions juridiques
Dès qu’un outil no-code contient des données personnelles (clients, candidats, salariés), le RGPD s’applique comme pour n’importe quel logiciel. L’éditeur de la plateforme agit en principe comme sous-traitant de votre entreprise : vérifiez qu’un accord de traitement des données conforme à l’article 28 du RGPD est proposé, où sont hébergées les données, et comment elles peuvent être exportées ou supprimées. L’article contrat SaaS et réversibilité détaille les clauses à lire. Pensez aussi à inscrire ces traitements dans votre registre.
Comment démarrer
- Partir d’un problème précis et limité : un formulaire, une automatisation, un registre.
- Dessiner le circuit sur papier avant de toucher à l’outil : qui saisit quoi, qui reçoit quoi, à quel moment.
- Tester avec de fausses données, puis avec un petit groupe d’utilisateurs.
- Fixer un seuil de vigilance : nombre d’utilisateurs, volume de données ou niveau de criticité au-delà duquel on réévaluera le choix de l’outil.
Le no-code est souvent une excellente étape intermédiaire. Il permet de comprendre précisément son besoin à moindre risque, et, si un développement sur mesure devient nécessaire plus tard, de disposer d’un prototype qui vaut tous les cahiers des charges.
Cet article peut contenir des liens partenaires. Ils n'influencent jamais ce que nous écrivons.