Applications natives IA : pourquoi générer des métadonnées plutôt que du code
La génération de code accélère les prototypes, mais les applications d’entreprise ont besoin d’un runtime de métadonnées où objets, permissions, workflows, actions et outils d’agent sont gouvernés ensemble.
En bref : une application AI-native n’est pas un amas de code généré, mais des métadonnées générées — objets, permissions, workflows et outils d’Agent réunis dans un runtime gouverné. Le code s’exécute ; les métadonnées sont ce qui reste modifiable et gouvernable.
Depuis plusieurs années, les plateformes low-code résolvent un problème concret : chaque système interne ne devrait pas exiger de recréer pages, formulaires, workflows et écrans d’administration depuis zéro.
L’AI déplace maintenant la question en amont. Si le low-code permet d’assembler une application, peut-on la générer à partir d’une phrase métier ?
Oui, mais il y a un piège. Si « générer une application avec l’AI » signifie seulement « générer du code », les anciens problèmes des applications d’entreprise reviennent vite. La première version semble rapide. La deuxième ralentit. Les pages fonctionnent, mais les permissions sont fragiles. Les formulaires enregistrent des données, mais les processus sont difficiles à expliquer. L’AI répond, mais les Agents ne savent pas quelles actions sont autorisées ni quand attendre une confirmation humaine.
Le cœur d’une plateforme d’applications AI-native n’est donc pas la génération de code. C’est la génération de métadonnées.
Le vrai sujet est la capacité à changer
Pour un responsable métier ou IT, la question importante n’est pas seulement de générer une première version. Les vraies questions sont :
- L’application peut-elle changer quand le métier change ?
- Si un champ change, les formulaires, listes, permissions et workflows suivent-ils ?
- Si une nouvelle règle d’approbation apparaît, les anciens dossiers restent-ils explicables ?
- L’Agent hérite-t-il des permissions de l’utilisateur ?
- Peut-on auditer qui a vu, modifié, confirmé et approuvé quoi ?
- Le système sera-t-il encore maintenable dans six mois ?
La génération de code accélère le départ. Les métadonnées structurent l’évolution continue.
C’est une leçon centrale du low-code : une application d’entreprise n’est pas un ensemble de pages. C’est un modèle métier configurable, gouvernable et évolutif.
Pourquoi le code généré perd le contrôle
La génération de code convient aux prototypes, petits outils et pages ponctuelles. Elle peut créer des composants, APIs, schémas de base et validations.
Mais la complexité d’entreprise se situe souvent dans la cohérence entre couches.
Un utilisateur dit :
Ajoutez un champ « risque de renouvellement » aux clients et rappelez chaque semaine le customer success manager pour les clients à haut risque.
AI peut modifier la base, le formulaire, la liste et une tâche planifiée. Cela paraît terminé.
Dans un vrai système, ce champ touche aussi :
- son affichage dans la fiche client ;
- qui peut modifier le niveau de risque ;
- la visibilité des managers sur leur équipe ;
- les exports ;
- l’usage par les Agents dans les résumés ;
- l’audit des règles de risque ;
- les notifications déclenchées par un changement ;
- les migrations futures.
Si cette logique est dispersée dans le code, chaque modification devient une petite refonte. Le système s’alourdit et revient vers le développement spécifique.
Les métadonnées sont le langage métier de la runtime
Ici, les métadonnées ne sont pas de simples options. Elles sont le langage par lequel la runtime comprend le métier.
| Couche de métadonnées | Question traitée |
|---|---|
| Objets | Quelles entités existent : clients, contrats, tickets, tâches |
| Champs | Quels attributs existent, avec type, obligatoire, formule, sensibilité |
| Relations | Comment les objets se relient |
| Vues | Comment chaque rôle voit les données |
| Permissions | Qui peut voir, modifier et agir sur quels enregistrements |
| Workflows | Comment les statuts changent et quelles conditions déclenchent des actions |
| Actions | Créer des tâches, lancer des approbations, produire des rapports |
| Outils d’Agent | Ce que l’AI peut consulter, proposer ou exécuter, et quand elle doit s’arrêter |
| Audit | Ce que l’AI a proposé, ce qu’un humain a confirmé et ce que le système a exécuté |
Ces couches pilotent ensemble UI, API, permissions, automatisation et Agents.
AI Builder doit générer une spécification d’application
Un AI Builder mature ne commence pas par écrire du code. Il agit comme un architecte métier qui comprend le low-code et produit d’abord une spécification.
Si l’utilisateur demande une application de tickets après-vente, le Builder doit identifier des objets comme client, ticket, message, base de connaissance, SLA et escalade ; des champs comme type de problème, priorité, sentiment, impact et échéance ; des vues comme file support et tableau manager ; des permissions ; un workflow ; des outils d’Agent pour résumer, classifier, chercher dans la base de connaissance et rédiger une réponse ; puis les points d’audit.
Après validation, la plateforme génère pages, structures de données, automatisations et appels d’outils.
C’est à peine plus lent que de générer directement du code, mais beaucoup plus stable ensuite.
Ce que l’AI change dans le low-code
Le low-code traditionnel demande de comprendre des designers d’objets, panneaux de champs, canevas de workflow, matrices de permission et éditeurs d’expression.
AI Builder ne doit pas remplacer ces capacités. Il doit réduire le coût d’expression.
L’utilisateur peut dire :
Mettez les contrats à haut risque dans un tableau juridique et ajoutez une revue finance au-delà de 500 000.
La plateforme transforme cette phrase en filtres, vues, conditions de workflow, nœuds d’approbation et changements de permission, puis montre un plan à confirmer.
La vraie amélioration n’est pas de transformer la plateforme en boîte noire, mais de faire entrer le langage métier dans la structure de la plateforme.
Six questions pour évaluer un AI Builder
Ne demandez pas seulement s’il génère une belle page. Demandez :
- Génère-t-il du code ou des objets, champs, vues, permissions et workflows explicables ?
- Les métiers peuvent-ils modifier la structure en langage naturel ?
- Les permissions sont-elles une capacité de runtime unifiée ?
- Les Agents accèdent-ils aux données uniquement via des outils gouvernés ?
- Les suggestions AI, confirmations humaines et actions système sont-elles auditées ?
- Quand les règles changent, modifie-t-on les métadonnées ou régénère-t-on du code ?
Ces réponses distinguent une démonstration d’une vraie plateforme d’entreprise.
La différence ObjectStack
ObjectStack vise à transformer le langage naturel en métadonnées, puis à laisser ces métadonnées piloter la runtime.
Une demande génère objets, champs, relations, vues, permissions, workflows, actions et outils d’Agent. Une fois l’application en production, les utilisateurs continuent de la modifier en langage naturel. Les Agents travaillent dans les mêmes limites d’objets, de permissions et d’actions.
Le code existe toujours, mais il n’est plus le seul support du changement métier. La structure métier doit entrer dans la couche de métadonnées pour être générée, comprise, modifiée, gouvernée et auditée.