Comparatif
Low-code vs metadriven : quelle approche pour vos applications métier ?
Les deux promettent de livrer plus vite sans armée de développeurs. Elles ne partent pas du même endroit : le low-code assemble des écrans, le metadriven déclare un modèle. Voici ce que ça change concrètement, et dans quels cas choisir l'un ou l'autre.
Low-code
On assemble des écrans
Une plateforme low-code fournit un éditeur visuel : on glisse des composants, on branche des sources de données, on décrit des flux. Le résultat est une application générée ou interprétée, écran par écran.
- + Prise en main rapide par des profils non développeurs
- + Grande liberté de mise en page et d'interactions
- + Écosystèmes de connecteurs très fournis
- − Chaque écran porte sa propre logique : un champ ajouté se reporte à la main partout
- − L'API et les droits sont souvent déduits après coup, ou à configurer séparément
- − Enfermement fréquent : l'application vit dans la plateforme
Metadriven
On déclare un modèle
Une plateforme metadriven part du métamodèle : classes, propriétés typées, relations, règles, workflows, droits. Le moteur en dérive la base de données, les écrans, l'API et les outils IA à l'exécution.
- + Une modification du modèle se propage partout, immédiatement
- + API, droits et outils MCP toujours alignés sur le même modèle
- + Données dans une base standard, modèle versionné et exportable
- − Demande de savoir modéliser : penser objets et relations avant écrans
- − Les écrans générés sont standardisés ; les interfaces très spécifiques se personnalisent à part
- − Moins adapté aux applications qui sont surtout de la mise en page (sites événementiels, landing pages)
Point par point
Ce qui diffère vraiment
Ajouter un champ
Low-code : modifier la table, puis chaque formulaire, chaque liste, chaque export qui doit l'afficher.
Metadriven : déclarer la propriété ; formulaires, listes, API et outils IA la connaissent aussitôt.
Changer un workflow
Low-code : rouvrir le flux, ajouter l'étape, vérifier chaque écran qui teste le statut.
Metadriven : ajouter le statut au workflow déclaré ; les transitions et les droits associés suivent.
Exposer une API
Low-code : souvent un module à part, à configurer endpoint par endpoint.
Metadriven : l'API REST est une projection du modèle, documentée automatiquement.
Brancher un agent IA
Low-code : écrire les outils, leurs schémas et leurs règles de sécurité à la main.
Metadriven : le serveur MCP expose le métamodèle avec les droits de l'utilisateur, sans code.
Quitter la plateforme
Low-code : l'application est rarement récupérable hors de l'outil ; on exporte des données, pas une application.
Metadriven : données dans PostgreSQL et modèle versionné lisible ; la dépendance porte sur le moteur, pas sur le format.
Interface sur mesure
Low-code : c'est son point fort, chaque pixel est à portée de souris.
Metadriven : écrans standard générés, personnalisation possible mais elle s'ajoute au modèle plutôt qu'elle ne le remplace.
Notre position
Le modèle d'abord, l'écran ensuite
Pour une application de gestion — objets, relations, règles, historique — nous pensons que le metadriven vieillit mieux : c'est le modèle qui change avec le métier, pas des dizaines d'écrans. C'est le principe de la plateforme agis, et la raison pour laquelle nos propres produits (GMAO, CMS) sont construits dessus. Pour un prototype visuel ou une interface très graphique, le low-code reste un bon choix.