D’une phrase aux objets, vues, permissions et Agents : la chaîne de génération d’AI Builder
L’important dans AI Builder n’est pas de transformer une phrase en pages, mais de décomposer une demande métier en objets, champs, vues, workflows, permissions, automatisations et outils d’Agent.
En bref : un bon AI Builder ne transforme pas une phrase en quelques pages ; il décompose une seule demande métier en objets, champs, vues, workflows, permissions et outils d’Agent — une spécification d’application exécutable, modifiable et gouvernable.
« Générer une application depuis une phrase » semble puissant, mais l’expression peut tromper.
Si le lecteur imagine qu’un prompt crée simplement quelques pages, ce n’est pas très différent d’une démonstration de génération de code. La question importante est de savoir comment AI Builder décompose une demande métier en métadonnées d’application exécutables, modifiables et gouvernables.
Exemple :
Construisez une application de risque fournisseur. Elle doit gérer fournisseurs, qualifications, devis, commandes, livraisons et problèmes qualité. L’AI doit détecter qualifications expirées, devis anormaux et risques de livraison. Les fournisseurs critiques à haut risque doivent être approuvés par le responsable achats.
La vraie question est : que devient cette phrase dans la plateforme ?
Première étape : générer un graphe d’objets métier
AI Builder doit d’abord identifier les noms du domaine.
Ce n’est pas une grande table fournisseur. C’est un ensemble d’objets liés : supplier, supplier_qualification, quotation, purchase_order, delivery_record, quality_issue, supplier_risk et approval_task.
Cette étape définit les frontières de l’application. Sans objets clairs, il devient difficile d’expliquer quelle livraison, quel devis ou quelle qualification a créé un risque. Avec un graphe propre, le risque pointe vers des preuves, l’approbation vers des raisons, et l’Agent peut expliquer sa base.
Deuxième étape : champs et relations avec sens métier
Un générateur faible traite les champs comme des entrées de formulaire. Un bon Builder les traite comme de la sémantique métier.
Une qualification n’est pas un simple fichier. Elle nécessite type, numéro, date d’effet, date d’expiration, état de revue, relecteur, fournisseur lié et caractère critique.
Un devis n’est pas seulement un montant. Il nécessite matière, quantité, prix unitaire, validité, écart historique, transport, service et demande d’achat liée.
Les relations comptent autant. Un fournisseur a plusieurs qualifications, devis, commandes, livraisons et problèmes qualité. Un risque doit revenir vers ces preuves.
C’est ce qui transforme l’analyse AI en explication fondée sur les relations, et non en intuition du modèle.
Troisième étape : vues par rôle
Une application d’entreprise ne montre pas la même table à tout le monde.
| Rôle | Vues |
|---|---|
| Acheteur | Mes fournisseurs, qualifications manquantes, comparaison de devis |
| Responsable achats | Fournisseurs à haut risque, approbations en attente, risque matériaux critiques |
| Qualité | Problèmes récents, défauts répétés, statut de correction |
| Juridique / conformité | Lacunes de qualification, risques contractuels, liste noire |
| Direction | Répartition des risques, concentration fournisseurs, tendances achats |
Cela ressemble à la configuration de vues en low-code. La valeur d’AI Builder est de créer un bon point de départ depuis la demande métier.
Quatrième étape : permissions et limites d’action
Les permissions sont souvent absentes des démos, mais elles distinguent une plateforme professionnelle.
Dans cette application :
- les achats maintiennent les profils fournisseurs sans modifier les conclusions qualité ;
- la qualité ferme les problèmes sans approuver les commandes ;
- le responsable achats approuve les achats à haut risque ;
- les utilisateurs ordinaires ne voient pas les données financières sensibles ;
- l’AI peut suggérer un risque sans bloquer automatiquement un fournisseur ;
- les actions à haut risque exigent approbation.
Ce sont des règles de runtime, pas des détails d’écran.
Si un Agent doit « trouver les fournisseurs à haut risque et suspendre les achats », il doit respecter ces limites.
Cinquième étape : workflows, automatisation et SLA
Des objets statiques ne suffisent pas. L’application doit faire avancer le travail.
Le processus peut couvrir création du fournisseur, upload de qualifications, contrôle AI, comparaison de devis, commande, retour livraison, détection du risque, approbation, suggestion de correction et clôture avec audit.
L’automatisation doit aussi venir de la demande :
- rappel 30 jours avant expiration ;
- blocage d’achats si une qualification critique a expiré ;
- création d’un risque si la ponctualité baisse ;
- tâche de revue si les défauts se répètent ;
- rappel d’approbation en retard.
C’est cela, générer une application, et non seulement des pages.
Sixième étape : outils d’Agent
La dernière couche est l’outillage Agent.
La plateforme doit générer des outils gouvernés : consulter le risque fournisseur, comparer des devis, expliquer les sources de risque, créer des tâches de revue, lancer une approbation et générer un rapport mensuel.
Chaque outil nécessite entrées, sorties, permissions et audit.
Quand un utilisateur demande si l’on peut encore commander auprès d’un fournisseur, l’Agent doit interroger les données, qualifications, livraisons, qualité et devis, puis répondre avec preuves. Les actions critiques restent des actions de plateforme.
Un bon Builder montre un plan
AI Builder doit construire la confiance. Il ne doit pas tout générer silencieusement. Il doit montrer :
- les objets créés ;
- les champs clés ;
- les relations ;
- les vues ;
- les règles de permission ;
- les automatisations ;
- les outils Agent ;
- les actions demandant confirmation humaine.
Après confirmation, l’application est générée. Le Builder devient un architecte collaboratif, pas une boîte noire.
La chaîne ObjectStack
ObjectStack doit transformer le langage naturel en spécification d’application, puis laisser cette spécification piloter la runtime.
Demande en langage naturel → objets métier → champs et relations → vues et formulaires → limites de permission → automatisation de workflow → outils d’Agent → runtime auditée
La valeur n’est pas magique. Elle vient du fait de savoir quelle couche de métadonnées chaque phrase doit modifier et comment ces couches produisent un système métier exécutable.