Modifier les applications métier par conversation : champs, workflows, vues et automatisation
La vraie valeur d'un builder IA est l'itération conversationnelle continue : champs, workflows, vues, permissions et automatisations évoluent en sécurité dans les métadonnées.
En bref : la vraie valeur de modifier les systèmes par conversation n’est pas « on discute et ça change » — c’est que chaque champ ajouté, chaque workflow modifié ou chaque permission ajustée se traduit dans une couche de métadonnées vérifiable et réversible. Rapide à changer, et sûr à changer.
Après la mise en production d’une application métier, le vrai travail commence.
Le responsable support veut ajouter un champ. La directrice commerciale veut changer une étape. La finance veut ajouter une approbation. Le juridique veut ajuster les règles de risque. Les opérations veulent un tableau de bord supplémentaire. L’IT veut resserrer les permissions. Dans un cycle logiciel classique, tout cela devient des demandes : estimer, planifier, développer, tester, déployer.
La promesse la plus importante d’un builder IA est de faire passer une grande partie de ces changements de « déposer une demande » à « modifier par conversation ».
Mais il faut être précis. La modification conversationnelle ne veut pas dire que l’IA peut changer le système librement. Elle veut dire que le langage naturel doit produire un plan de changement de métadonnées explicable, confirmable et réversible.
Ce qui inquiète les lecteurs
Du point de vue des utilisateurs d’une plateforme low-code, « modifier une application par conversation » semble pratique, mais aussi risqué.
Ils se demanderont naturellement :
- L’IA va-t-elle modifier le mauvais objet ?
- Un nouveau champ peut-il perturber des formulaires existants ?
- Un changement de workflow affectera-t-il des demandes déjà en approbation ?
- Un changement de permissions peut-il exposer des données sensibles ?
- Une automatisation peut-elle envoyer la mauvaise notification ?
- Un agent peut-il exécuter une action hors de ses droits ?
- Peut-on revenir en arrière après modification ?
Un article sur un builder IA ne doit donc pas seulement dire : « modifier une application avec une phrase ». Le vrai sujet est la manière dont la plateforme transforme une phrase en changement contrôlé.
Type de changement 1 : ajouter un champ
L’utilisateur dit :
Ajoute aux clients un champ « risque de renouvellement », avec les options faible, moyen et élevé. Les clients à risque élevé doivent apparaître dans le tableau du responsable customer success.
Un builder IA professionnel ne devrait pas exécuter immédiatement. Il devrait d’abord générer un plan de changement :
| Élément | Plan |
|---|---|
| Objet | Modifier customer |
| Champ | Ajouter le champ enum renewal_risk |
| Formulaires | L’afficher dans les pages détail et édition client |
| Vue | Créer le tableau « High-risk renewal customers » |
| Permissions | Customer success peut modifier; ventes en lecture seule |
| Automatisation | Notifier le responsable quand le risque devient élevé |
| Agent | Autoriser les résumés client à citer ce champ |
La plateforme ne modifie les métadonnées qu’après confirmation de l’utilisateur.
La différence avec « ajouter une colonne » est importante : le champ entre dans tout le runtime applicatif, pas seulement dans la base de données.
Type de changement 2 : modifier un workflow
L’utilisateur dit :
Quand une note de frais dépasse 3 000, elle doit être approuvée d’abord par le manager direct, puis par le responsable financier. Si le budget du projet associé est insuffisant, le responsable du budget doit aussi confirmer.
Cette phrase implique des conditions, des nœuds d’approbation, des états, des notifications, des exceptions et de l’audit.
Le builder devrait générer :
- Une condition de montant;
- Un nœud d’approbation du manager direct;
- Un nœud d’approbation du responsable financier;
- Une vérification du budget;
- Un nœud pour le responsable du budget;
- Des chemins de rejet et de demande de compléments;
- Les commentaires d’approbation et les horodatages d’audit.
Il devrait aussi indiquer le périmètre d’impact : ce workflow concerne-t-il seulement les nouvelles notes de frais, ou aussi celles déjà en cours d’approbation ? Si des instances en cours sont concernées, faut-il les migrer ?
C’est un détail professionnel essentiel dans une plateforme low-code. Un workflow n’est pas terminé parce qu’il est dessiné. Il doit aussi cohabiter avec des instances déjà en exécution.
Type de changement 3 : générer une vue
Les vues sont l’un des meilleurs cas pour la génération conversationnelle, car les utilisateurs savent souvent ce qu’ils veulent voir sans savoir configurer les filtres et le tri.
L’utilisateur dit :
Crée pour les chefs de projet une vue « projets à haut risque cette semaine », triée par jours de retard prévus, et affiche seulement les projets dont je suis responsable.
La plateforme devrait générer :
- Objet : projet;
- Filtre : niveau de risque élevé et impact attendu sur un jalon de cette semaine;
- Permission : afficher seulement les projets possédés par l’utilisateur courant ou auxquels il participe;
- Tri : jours de retard prévus en ordre décroissant;
- Champs : nom du projet, responsable, jalon, raison du risque, prochaine action;
- Présentation : liste ou tableau.
Un bon builder devrait aussi accepter une demande de suivi :
Ajoute une colonne « dernière décision de réunion ».
À ce moment, il ne doit pas reconstruire la page. Il doit modifier les métadonnées de la vue.
Type de changement 4 : ajuster les permissions
Les permissions sont la partie la plus sensible de la modification conversationnelle.
L’utilisateur dit :
Les commerciaux ne voient que leurs propres clients, les responsables régionaux voient les clients de leur région, et la direction voit tous les clients.
La phrase semble claire, mais la plateforme doit générer et afficher une matrice de permissions :
| Rôle | Périmètre des enregistrements | Périmètre des champs | Actions autorisées |
|---|---|---|---|
| Commercial | Ses propres clients | Masquer les coûts et clauses sensibles du contrat | Créer des suivis, mettre à jour les activités |
| Responsable régional | Clients de sa région | Peut voir les montants agrégés | Assigner des responsables, voir les risques |
| Direction | Tous les clients | Peut voir les résumés, pas forcément modifier | Voir les rapports; export avec approbation |
Les requêtes d’agent doivent hériter des mêmes permissions. Si un commercial demande « quels clients sont à haut risque ? », le système ne doit retourner que les clients qu’il a le droit de voir.
L’IA peut aider à configurer les permissions, mais elle ne doit pas rendre le contrôle d’accès léger ou approximatif.
Type de changement 5 : créer une automatisation et des actions d’agent
L’utilisateur dit :
Chaque lundi matin, résume les clients à haut risque pour les responsables customer success et crée des tâches de suivi pour les propriétaires.
La plateforme devrait décomposer cela en :
- Un déclencheur planifié;
- Une requête sur les clients à haut risque;
- Un regroupement par propriétaire;
- Un résumé interne;
- La création de tâches de suivi;
- Les journaux d’exécution de l’automatisation;
- Une notification administrateur en cas d’échec.
Elle doit aussi classer le risque des actions :
- Résumé interne : risque faible;
- Création de tâche : risque faible à moyen;
- Modification du niveau de risque client : risque moyen, confirmation requise;
- Envoi d’un email au client : risque élevé, approbation ou envoi manuel requis.
La clé de l’automatisation conversationnelle n’est pas « faire plus automatiquement ». C’est distinguer clairement ce qui peut être automatisé de ce qui doit être confirmé.
Quatre détails produit indispensables
Premièrement, afficher le plan de changement. L’utilisateur doit savoir quels objets, champs, vues, workflows, permissions et automatisations la plateforme veut modifier.
Deuxièmement, afficher le périmètre d’impact. Pour les permissions, workflows et automatisations surtout, il faut expliquer quels rôles, données et instances en cours sont concernés.
Troisièmement, prendre en charge la prévisualisation et le rollback. Avant modification, on doit pouvoir prévisualiser. Après modification, on doit pouvoir revenir à une version précédente.
Quatrièmement, conserver un audit. Qui a demandé le changement, comment l’IA l’a expliqué, si un humain l’a confirmé, et ce que le système a finalement changé doivent être enregistrés.
Sans ces quatre détails, « modifier les applications par conversation » devient une boîte noire dangereuse.
La valeur d’ObjectStack
ObjectStack convient bien à l’itération conversationnelle des applications parce qu’il place la structure applicative dans la couche de métadonnées.
Champs, vues, workflows, permissions, automatisations et outils d’agent ne sont pas dispersés dans le code. Ce sont des structures métier qui peuvent être générées, expliquées, modifiées, versionnées et auditées.
Les utilisateurs métier décrivent le changement en langage naturel. La plateforme génère un plan. Un administrateur ou un business owner le confirme. Le runtime fonctionne ensuite avec les nouvelles métadonnées, et les agents héritent des mêmes limites d’objet, de permission et d’action.
C’est la clé pour modifier les systèmes métier par conversation : l’IA ne corrige pas temporairement une fonctionnalité. Le système devient continuellement modelable par le langage métier, tout en conservant la gouvernance attendue d’une plateforme low-code.