Le no-code permet de créer une application sans écrire manuellement de code ; le low-code réduit la programmation, mais conserve la possibilité d’ajouter des développements personnalisés. Les deux approches utilisent des interfaces visuelles pour assembler des écrans, organiser des données et automatiser des actions. Leur intérêt dépend surtout du projet : un formulaire interne et une application critique n’exigent ni la même souplesse ni les mêmes garanties.
Deux approches visuelles, mais pas le même degré de liberté
Avec une plateforme no-code, l’utilisateur configure des composants prêts à l’emploi : champs de formulaire, tableaux, boutons, conditions et notifications. Il peut ainsi construire un outil métier sans maîtriser un langage de programmation. Cela ne supprime pas le travail de conception : il faut comprendre les données, les règles et les exceptions du processus.
Le low-code repose sur une logique similaire, avec davantage de possibilités d’extension. Un développeur peut ajouter un script, créer un composant ou réaliser une intégration spécifique. Il s’adresse donc souvent aux équipes techniques, parfois en collaboration avec les utilisateurs métier.
Le pro-code désigne le développement traditionnel par programmation. Il offre davantage de contrôle sur l’architecture et les fonctionnalités, au prix d’un effort de réalisation et de maintenance généralement plus important. Ces approches peuvent cohabiter : une interface no-code peut exploiter un service développé sur mesure.
| Critère | No-code | Low-code | Pro-code |
|---|---|---|---|
| Compétences | Logique métier et configuration | Configuration et programmation pour les extensions | Développement et architecture |
| Personnalisation | Limitée aux possibilités de l’outil | Étendue par du code personnalisé | Très large, selon les ressources |
| Rapidité | Élevée pour un besoin standard | Élevée grâce aux composants réutilisables | Variable selon le projet |
| Intégration | Connecteurs et API accessibles dans l’outil | Connecteurs et extensions spécifiques | Intégrations développées sur mesure |
| Évolutivité | Dépendante des limites de la plateforme | Dépendante de l’architecture et des extensions | Dépendante des choix techniques |
Du formulaire au workflow : ce que l’on construit réellement
Les plateformes combinent généralement un éditeur visuel, des modèles et un moteur qui exécute la configuration, parfois par génération automatique de code. Les données proviennent d’une base intégrée ou de sources externes. Les connecteurs facilitent les échanges ; les API, interfaces de communication entre logiciels, permettent des intégrations plus spécifiques.
Un exemple concret : la demande d’achat
Une équipe crée un formulaire contenant le fournisseur, le montant et le justificatif. Elle définit ensuite un workflow, c’est-à-dire un enchaînement d’étapes : réception, validation du responsable, transmission à la comptabilité et notification au demandeur. Des règles précisent qui peut consulter ou modifier chaque demande.
Le glisser-déposer ne règle toutefois pas les exceptions. Que se passe-t-il si le responsable est absent, si un justificatif manque ou si la connexion au logiciel comptable échoue ? La qualité de l’application dépend autant de ces réponses que de son interface.
Des usages adaptés aux équipes métier
- Ressources humaines : accueil des nouveaux salariés, collecte de documents et suivi des formations.
- Opérations : suivi d’interventions, inventaires et signalement d’incidents.
- Commercial et marketing : gestion de prospects, formulaires et automatisation de notifications.
- Finance : circuits de validation, reporting et tableaux de bord.
Ces usages dépassent le simple prototype. ZDNET mentionne une quinzaine d’applications low-code créées par la SNCF, plus de 70 applications utilisées par Telstra et plus de 400 développées par Toyota. Ces exemples illustrent la diversité des déploiements, sans garantir qu’une même plateforme conviendra à toutes les organisations.
Choisir selon les contraintes, pas selon la promesse « sans code »
Le no-code convient particulièrement à un processus bien délimité, proche des fonctions natives de l’outil. Le low-code devient pertinent lorsque les règles se complexifient ou que des intégrations spécifiques sont nécessaires. Le pro-code mérite d’être envisagé lorsque le produit exige une architecture particulière, des performances très contraintes ou une forte indépendance technique.
Pensez à l’application comme à un tissu : les écrans en sont la surface visible, mais les connexions constituent les coutures. Une modification du format d’un identifiant ou d’un droit d’accès peut tirer sur plusieurs assemblages. Avant de choisir, dessinez les échanges entre systèmes et désignez le responsable de chaque liaison. Cette cartographie révèle souvent davantage de risques qu’une démonstration d’interface réussie.
Le low-code n’est pas automatiquement plus évolutif que le no-code. Il offre généralement plus de possibilités d’extension, mais les limites de volumétrie, d’exécution et de stockage restent propres à chaque plateforme. Un essai représentatif vaut mieux qu’une comparaison d’étiquettes.
- Définissez le périmètre : utilisateurs, données sensibles, règles et fonctionnalités indispensables.
- Testez le scénario difficile : droits complexes, erreur de synchronisation ou traitement volumineux.
- Vérifiez l’exploitation : journaux, sauvegardes, restauration et séparation entre test et production.
- Préparez la sortie : exportez les données et examinez ce qui serait à reconstruire ailleurs.
Comparez aussi les conditions d’hébergement : cloud public, cloud privé ou installation sur site lorsque ces options existent. Leur disponibilité, la localisation des données et les engagements contractuels doivent correspondre aux exigences de l’entreprise.
Calculer le coût réel et organiser la maintenance
Le gain principal vient de la réutilisation : moins d’écrans, de connexions et de fonctions courantes à développer. Cela peut accélérer la mise en production et libérer les développeurs pour les besoins spécifiques. Mais moins de code ne signifie ni absence de coût ni absence de maintenance.
Le budget doit intégrer les licences, les utilisateurs externes, les volumes d’automatisation, le stockage et les connecteurs payants. Ajoutez le temps de formation, de test, de supervision et de correction. Une solution économique au démarrage peut devenir coûteuse lorsque son usage s’étend.
La dépendance au fournisseur mérite une vérification distincte. Exporter des données ne suffit pas à emporter l’application : les écrans, les règles et les automatisations peuvent rester liés à un moteur propriétaire. Demandez quels éléments sont portables et estimez l’effort de reconstruction.
Enfin, attribuez un propriétaire à chaque application. Il doit tenir à jour les règles métier, documenter les connexions et vérifier les changements introduits par la plateforme. Sans ce suivi, les composants visuels peuvent accumuler une dette technique aussi réelle que celle d’un logiciel traditionnel.
Donner de l’autonomie aux métiers sans perdre le contrôle
Un développeur citoyen est un utilisateur métier qui crée des applications ou des automatisations sans être développeur professionnel. Sa connaissance du terrain est précieuse. Sans cadre, toutefois, ces initiatives peuvent produire du shadow IT : des outils utilisés hors de la supervision informatique.
La DSI doit proposer des plateformes approuvées, des modèles réutilisables et un accompagnement proportionné au risque. Un suivi interne peu sensible ne nécessite pas les mêmes contrôles qu’une application manipulant des données personnelles ou déclenchant des paiements.
- Recenser les applications, leurs propriétaires et leurs dépendances.
- Limiter les accès selon les rôles et protéger les identifiants de connexion.
- Valider les traitements sensibles avant la mise en production.
- Prévoir les sauvegardes, les incidents et le départ du créateur de l’outil.
L’IA peut aider à générer des écrans, proposer des règles ou préparer des workflows. Elle ne remplace pas la vérification des droits, des calculs et des actions déclenchées. Les développeurs restent essentiels pour l’architecture, les intégrations et les tests. Le bon équilibre consiste à confier aux métiers la conception de leurs usages, tout en gardant une responsabilité technique clairement identifiée.