Dans cet article
L’essentiel
Spring AI permet à une application Java de relier un modèle à des outils et à un contexte documentaire. L’application doit garder la maîtrise de l’authentification, des règles métier et de l’exécution. Commencez par une tâche limitée en lecture seule.
Garder l’agent au plus près des services métier
Prenons une application Java qui gère déjà des tickets de support. Un premier agent utile pourrait lire un ticket autorisé, consulter une procédure et préparer une réponse. Spring AI permet l’appel d’outils via des méthodes Java, notamment avec @Tool. Le modèle demande une opération ; le code applicatif l’exécute. Cette distinction permet au service métier de garder le contrôle.
Nous recommandons de réutiliser la couche de services plutôt que d’exposer des requêtes libres en base ou un terminal d’administration. Définissez tâche, outils et conditions d’arrêt avant de choisir le modèle. Les fragments Java ci-dessous sont illustratifs et s’appuient sur la documentation Spring AI 2.0 consultée pour cet article ; ils ne constituent ni une application exécutable complète ni une réalisation client testée.
L’application garde le contrôle
L’exemple de l’agent de support, organisé par responsabilité.
ChatClient
Transmettre la question et les outils disponibles pour cette requête.
@Tool
Exposer une opération limitée, comme lire un ticket.
TicketService
Identifier l’utilisateur authentifié et contrôler l’accès au dossier.
Données métier
Retourner à l’application une vue minimale autorisée.
Exposer un outil limité et autorisé
L’exemple accepte volontairement un identifiant de ticket, pas une identité utilisateur ou locataire choisie par le modèle. TicketService est un service propre à l’application. Sa méthode readForCurrentUser doit obtenir l’identité depuis l’authentification serveur, contrôler l’accès à l’enregistrement et retourner une vue minimale. Validez l’identifiant et limitez la taille des données retournées.
Conservez cette opération en lecture seule. Une écriture nécessite un contrat distinct, des validations métier, une gestion des doublons et, selon le processus, une approbation appliquée par le système. Un message de validation humaine dans le prompt ne remplace pas le contrôle applicatif. Un identifiant client fourni par le modèle ne doit jamais déterminer les dossiers d’entreprise accessibles.
import org.springframework.ai.tool.annotation.Tool;
final class TicketTools {
private final TicketService tickets;
TicketTools(TicketService tickets) {
this.tickets = tickets;
}
@Tool(description = "Read a support ticket visible to the current user")
TicketView readTicket(String ticketId) {
return tickets.readForCurrentUser(ticketId);
}
}Connecter le client, puis ajouter les preuves
Avec un ChatClient configuré et une instance de TicketTools, un prompt peut enregistrer cet outil pour la requête. Commencez par tester des identifiants valides, absents et interdits. Limitez le nombre d’itérations et la durée totale dans la configuration applicative. Prévoyez aussi l’annulation et le comportement lorsque le service appelé est indisponible.
Pour les questions documentaires, Spring AI propose QuestionAnswerAdvisor et le composant modulaire RetrievalAugmentationAdvisor. Rattachez les contraintes de recherche au contexte applicatif authentifié. Dans notre scénario, le ticket fournit le contexte produit, la recherche retrouve la procédure et le modèle prépare une réponse citant ses sources. Sans procédure applicable, demandez une revue plutôt que d’inventer une règle.
String draft = chatClient.prompt()
.user("Read ticket INC-1042 and summarise the confirmed facts.")
.tools(ticketTools)
.call()
.content();Observer les décisions sans tout collecter
Spring AI documente l’observabilité des interactions avec modèles et outils. Nous relierions une requête aux résultats des outils, au temps écoulé et à l’usage des tokens, sans journaliser inutilement tickets ou secrets. Rendez visibles pour l’exploitation les différences entre erreur du modèle, refus d’autorisation et panne d’une API appelée.
Avant livraison, évaluez identifiants erronés, procédures contradictoires, appels répétés et texte hostile dans un ticket. Le critère est un brouillon utile, fondé sur des preuves autorisées, sans modification involontaire de l’état métier. MASLOV Solutions peut cadrer intégration Java, RAG et évaluation autour des services existants. Ajoutez ensuite des actions lorsque leurs contrôles et leur récupération sont conçus.
L’étape suivante : proposer une écriture sans l’exécuter
La consultation de ticket est un bon point de départ. Pour ajouter un changement de statut, créez une proposition avec identifiant du ticket, transition demandée, motif et version attendue. Validez la transition dans le service métier existant. Si une approbation est requise, enregistrez la proposition et retournez sa référence de revue au lieu de modifier immédiatement le ticket.
À l’exécution, revérifiez utilisateur, droits et version. Un ticket fermé par une autre personne ne doit pas être rouvert parce qu’une ancienne proposition vient d’être approuvée. Utilisez un identifiant d’opération stable contre les doublons. Ce flux proposé conserve les invariants dans le code applicatif ; les descriptions d’outils aident le modèle à demander une action, sans imposer ces invariants.
De la demande d’outil à la commande métier
Extension proposée de l’exemple en lecture seule. Le service contrôle droits, version et prévention des doublons.
Demande d’outil → valider la transition → stocker la proposition
Approbation valide et version du ticket inchangée ?
Oui
- Revérifier les droits → exécuter avec identifiant d’opération
- Retourner le résultat métier dans la conversation
Non
- Ne pas modifier le ticket
- Expliquer le refus ou demander une proposition révisée
Tester la frontière agent sans appeler un modèle à chaque test
Testez autorisation, validation et changements d’état comme des services ordinaires, avec des entrées déterministes. Simulez tickets inconnus, accès interorganisation, transitions interdites et identifiants d’opération répétés. Gardez une suite d’intégration plus ciblée pour le comportement du modèle : choix d’outil, demande de précision et explication d’un refus.
Distinguez durée des outils, types d’erreurs et latence du modèle. Masquez les arguments sensibles et conservez des identifiants de corrélation pour suivre un incident entre conversation et service métier. Fixez des versions compatibles et vérifiez l’exemple complet dans votre application ; les fragments précédents illustrent une frontière, pas un service déployable comprenant authentification, stockage et toutes les erreurs.
Sources et lectures complémentaires
Documentation consultée le .
FAQ / DÉCISIONS
Questions fréquentes
Le modèle exécute-t-il directement le code Java ?+
Non. Il demande un appel d’outil. Spring AI et votre application exécutent l’opération enregistrée, dont l’implémentation doit appliquer droits et règles métier.
Un agent métier nécessite-t-il toujours plusieurs agents ?+
Non. Commencez par un processus limité et quelques outils. Ajoutez une coordination lorsque la séparation des responsabilités apporte un bénéfice mesurable.