Jmix donne à son agent IA d'entrepôt un accès en écriture : sécurité et audit

Les développeurs de la plateforme Jmix ont publié le deuxième volet de leur article consacré à un agent IA d'entrepôt basé sur Spring AI. Cette fois, l'agent a le droit non seulement de lire, mais aussi de modifier les données. L'équipe se penche sur la sécurité, l'audit et l'intégration au modèle métier, rapporte Habr.

Ce que contenait la première partie

Dans la première partie, l'équipe avait construit un agent en lecture seule au sein d'une application Jmix. L'utilisateur pose une question en langage naturel, et le ChatClient de Spring AI fait tourner l'agent loop : il appelle les méthodes @Tool jusqu'à réunir assez de données pour répondre.

• L'agent read-only de la première partie répond aux questions de l'utilisateur en langage naturel
• Chaque tool lit les données via DataManager avec un fetch plan explicite
• Cette approche reste presque entièrement dans le périmètre du système de sécurité de Jmix et ne renvoie au modèle que les champs nécessaires
• L'interface de l'agent est une vue Jmix classique, sans couche REST intermédiaire
• Les auteurs soulignent qu'un modèle dépourvu d'un native tool calling fiable fait s'effondrer tout le fonctionnement de l'agent

Quelles questions a soulevées le passage à l'écriture ?

Dès que l'agent a pu modifier les données, et plus seulement les lire, des questions sont apparues que ni la documentation de Spring AI ni la plupart des tutoriels sur les agents n'abordent habituellement. Sous quel utilisateur s'exécute réellement le tool appelé par le modèle ? Comment gérer les transactions lorsque le modèle enchaîne plusieurs tools ? Comment auditer des actions initiées par l'IA, et non directement par un humain ? Et comment faire travailler l'agent avec le modèle de domaine de l'application sans lister manuellement toutes les entités dans le prompt système ?

Selon les auteurs, il ne s'agit pas de retouches cosmétiques : ce sont précisément ces choix qui séparent un prototype de démonstration d'une application présentable à un client, c'est-à-dire d'un système prêt à être exploité en conditions réelles dans un entrepôt.

Ce que cela signifie

Le passage d'un agent read-only à un agent en écriture montre que la partie la plus difficile dans la construction d'agents IA pour applications métier n'est pas l'appel d'outils par le modèle. Ce sont les questions d'identité, d'intégrité transactionnelle et d'audit : sans elles, autoriser un modèle à modifier des données n'est tout simplement pas sûr.

Questions fréquentes

Que savait faire l'agent IA de la première partie de l'article ?

Il fonctionnait en lecture seule : il répondait en langage naturel aux questions de l'utilisateur sur l'entrepôt en appelant des méthodes @Tool via le ChatClient de Spring AI, tout en restant dans le cadre du système de sécurité de Jmix.

Quelles questions aborde la deuxième partie de l'article ?

Sous quel utilisateur s'exécute un tool, comment gérer les transactions lors d'une chaîne d'appels, comment auditer les actions initiées par le modèle et comment travailler avec le modèle de domaine sans énumérer manuellement les entités dans le prompt.