Ajout d’agents IA aux microservices Spring Boot avec Spring AI

Imaginez trois microservices Spring Boot qui gèrent déjà du trafic en production : six semaines de travail pour y intégrer des fonctionnalités d’agent, deux d’entre eux fonctionnant correctement tandis que le troisième se révèle être une leçon longue et coûteuse. Ce scénario, qui reflète l’expérience décrite par de nombreuses équipes Java, cadre ce qui suit. Il s’agit d’une analyse pratique de l’intégration de pipelines d’agents dans des services existants ayant des contraintes de latence, des équipes interdépendantes et des utilisateurs réels, destinée aux ingénieurs backend Java connaissant Spring Boot et souhaitant des capacités d’IA sans abandonner l’architecture qu’ils maintiennent.

Les pages suivantes abordent ce qu’est réellement un agent d’IA dans un environnement Spring Boot (et ce qu’il n’est pas), les raisons pour lesquelles les équipes les adoptent, la manière d’implémenter l’appel à des outils avec Spring AI, trois modes de défaillance qui apparaissent généralement seulement après le déploiement, ainsi que la façon de considérer la consommation de tokens comme une métrique opérationnelle de premier plan.

Qu’est-ce qu’un agent, et qu’est-ce qu’il n’est pas

Avant même d’écrire du code, le modèle mental doit être correct. La plupart des ingénieurs qui ont du mal avec l’intégration des agents en Java ne sont pas bloqués par le framework : ils appliquent simplement le mauvais modèle à ce dernier.

Un agent n’est pas une simple appel API astucieux. C’est un boucle de raisonnement : un modèle de langage reçoit une tâche, choisit les outils à utiliser, reçoit les résultats, réfléchit à tout ce qu’il sait maintenant, puis soit retourne une réponse finale, soit entame une nouvelle itération.

Quatre éléments composent cette boucle :

• Le modèle est le moteur de raisonnement, que ce soit GPT-4o, Claude, Gemini ou une alternative open source accessible via Ollama.
• Les outils sont les fonctions, API ou appels de service que le modèle est autorisé à utiliser.
• La boucle est le cycle à plusieurs étapes qui sépare un agent d’une seule appel à un LLM.
• Le contexte est l’accumulation progressive de l’historique des conversations, des résultats des outils et des instructions, qui alimente chaque étape de raisonnement.

Dans un microservice Spring Boot, cela signifie que vous n’ajoutez pas de wrapper de type RestTemplate autour d’une extrémité API d’IA. Vous intégrez plutôt un flux de travail à plusieurs étapes, à état et non déterministe, dans un service conçu pour une exécution limitée, synchrone et prévisible. C’est ce déséquilibre qui provoque les problèmes dans la plupart des intégrations IA en Java. Une façon simple de s’en souvenir : ce n’est pas l’outil qui est l’agent, c’est la boucle ; tant que vous ne le comprenez pas, vous finirez par créer des extrémités API plutôt que des agents.

Les raisons d’adopter des agents dans les services Spring Boot

Les tutoriels ont tendance à omettre cette partie. Ils montrent comment intégrer un agent mais disent peu sur les raisons pour lesquelles une organisation devrait le faire, le problème qu’il résout ou le coût d’une adoption prématurée.

Au-delà des règles fixes

Les microservices classiques automatisent des procédures connues, où une entrée A passe par un ensemble de règles B pour produire une sortie C, ce qui convient parfaitement aux flux déterministes. Les agents étendent cette idée aux tâches ambiguës et multi-étapes, dans lesquelles l’action suivante correcte dépend des résultats intermédiaires. Voici quelques exemples compatibles avec les architectures Spring Boot existantes :

• Traitement des commandes. Un agent vérifie les stocks, évalue les règles de tarification, applique des remises spécifiques au client et produit une recommandation de livraison dans une seule requête, de sorte que l’interface utilisateur n’a pas besoin d’orchestrer quatre appels successifs.
• Compréhension des documents. Un agent lit un PDF téléchargé, extrait des champs structurés, les valide selon des règles métier et confirme la réponse ou transmet l’affaire à un réviseur humain, sans règles d’extraction prédéfinies.
• Soutien client. Au sein d’un service de support existant, un agent récupère l’état du compte, l’historique des commandes et les documents relatifs aux politiques, puis rédige une réponse précise en fonction du contexte, ce qui réduit le temps de traitement sans écarter l’intervention humaine.
• Revue de code et assistance CI. Dans un pipeline d’ingénierie de plateforme, un agent analyse les tests qui échouent, consulte la documentation interne et propose des corrections ciblées.

Dans chacun de ces cas, la valeur n’est pas « AI » en tant que telle. Il s’agit de remplacer une logique d’orchestration fragile et manuelle par une couche de raisonnement capable de s’adapter à ce qu’elle trouve, plutôt que de tomber en panne lorsque l’entrée s’écarte du parcours prévu.

Pourquoi Spring Boot convient à cette tâche

Python domine les tutoriels sur l’IA, tandis que Java domine les systèmes de production d’entreprise, et l’écart entre les deux représente une véritable opportunité. Spring Boot offre des avantages structurels que les frameworks Python légers ne fournissent pas par défaut :

• L’injection de dépendances permet de gérer les beans d’outil de manière efficace, de les tester et de les combiner sans configuration supplémentaire.
• Actuator et Micrometer transforment l’utilisation des tokens, la latence entre les tours d’agent et les taux d’erreur des outils en métriques opérationnelles ordinaires.
• Les primitives asynchrones telles que @Async et CompletableFuture gèrent efficacement les boucles d’agent dont le temps d’exécution varie.
• Resilience4j enveloppe les appels aux outils dans des mécanismes de coupure de circuit et de tentatives répétées, empêchant ainsi des pannes en cascade.
• Spring Security permet d’intégrer l’authentification et l’autorisation pour les points de terminaison des outils destinés aux agents au système de contrôle d’accès existant.
• Des outils d’opérations matures signifient que des solutions existantes comme Prometheus, Grafana ou Datadog peuvent être étendues pour gérer les métriques des agents sans nécessiter de nouvelle infrastructure.

De plus, Spring AI fournit des clients pour les LLM, une intégration avec des bases de données vectorielles ainsi que des appels de fonctions basés sur l’annotation @Tool au sein du même écosystème, de sorte que la création d’un agent de niveau production ne nécessite pas de quitter la méthode de travail propre à Spring.

Quand un agent est utile

Les agents se révèlent utiles lorsque :

• Le flux de travail nécessite des décisions basées sur des informations découvertes pendant son exécution, et non sur des informations connues au moment de la réception de la demande.
• L’implémentation actuelle oblige l’interface utilisateur ou un service d’orchestration à coordonner plusieurs appels vers le backend, et l’agent pourrait assumer cette coordination sur le serveur.
• Les données d’entrée sont en langue naturelle à structure variable, avec une classification, une extraction, une synthèse ou un routage déterminés par le contenu plutôt que par un schéma prédéfini.
• Le système actuel échoue de manière « erronée mais sans planter », et un agent pourrait être conçu pour mettre en évidence l’incertitude plutôt que de retourner silencieusement la réponse erronée la plus probable.

Ils ne conviennent pas lorsque le flux de travail est entièrement déterministe, que les entrées sont structurées et que la logique basée sur des règles est facile à maintenir. Les agents ajoutent de la complexité, et cela ne justifie des coûts supplémentaires que lorsque l’alternative est pire.

Le raisonnement commercial en termes simples

Pour les responsables techniques et les parties prenantes du produit, ce raisonnement repose sur trois éléments clés :

1. Un déploiement plus rapide de nouvelles fonctionnalités. Les fonctionnalités qui nécessitaient autrefois des semaines de codage pour l’orchestration backend peuvent souvent être prototypées en quelques jours lorsque c’est un agent qui gère la coordination en plusieurs étapes. Les équipes rapportent fréquemment cette accélération après une première intégration réussie, bien que les chiffres varient.
2. Maintenance des règles moins fragile. Chaque règle codée en dur dans un service représente une dette qui augmente lorsque la logique métier évolue, et les instructions écrites en langue naturelle sont généralement plus faciles à mettre à jour que du code exprimant la même logique de manière impérative.
3. Base pour des systèmes d’IA composés. Un agent bien intégré constitue la fondation des workflows multi-agents, des pipelines de génération améliorés par la récupération d’informations et des fonctionnalités de produits natives de l’IA.

Pourquoi cette urgence, et ce changement de modèle d’exécution

Jusqu’en 2023 et au début de 2024, l’IA en Java ne signifiait guère plus que d’envoyer une requête vers une interface LLM et de récupérer le texte généré : un simple HTTP via un WebClient, un délai d’attente, sans autre réflexion.

Celui-ci n’est plus valable. L’ensemble des fonctionnalités de Spring AI (appel d’outils et de fonctions, intégration avec un stockage vectoriel ainsi qu’une API ChatClient conçue en tenant compte des workflows agents) indique que le modèle d’exécution lui-même a changé.

• Auparavant, une seule requête entraînait un appel à un LLM et une seule réponse.
• Aujourd’hui, une requête se divise en N appels à des outils et M étapes de raisonnement avant qu’une seule réponse ne soit générée.

De nombreux ingénieurs Spring Boot continuent d’appliquer l’ancien modèle et de traiter ChatClient comme un RestTemplate. Cette erreur de catégorisation provoque des incidents en production des semaines après le déploiement, et ces derniers sont rarement évidents au moment où ils surviennent.

Le cycle est l’agent

Les ingénieurs novices en intégration d’agents imaginent généralement un service qui remplace un contrôleur : une bean @Service, un ChatClient injecté, et c’est tout. Il s’agit d’un point de terminaison d’autocomplétion, pas d’un agent. Un véritable agent exécute une boucle qui consiste à recevoir une tâche, choisir un outil, l’exécuter, recevoir le résultat, raisonner sur le nouvel état, puis décider s’il doit continuer ou répondre. Le modèle est le moteur de raisonnement à l’intérieur de cette boucle ; la boucle, c’est l’agent.

Pourquoi la conception habituelle surestime les coûts

L’hypothèse courante est que l’appel à l’LLM est la partie coûteuse et complexe, et qu’un wrapper Spring @Service gère le reste. En réalité, « le reste » est désormais distribué : la lenteur des outils, l’état que le contexte conserve d’une étape à l’autre, la manière dont les erreurs se propagent le long de chaînes multiples d’étapes, ainsi que les tentatives de réessai nécessaires pour gérer des tâches inachevées.

Considérons un service hypothétique de classification des commandes. Il commence par un point d’entrée POST /orders/classify qui effectue une seule appel à un LLM. Il est ensuite refactorisé en un agent qui classe la commande, appelle un outil de gestion des stocks, appelle un outil de tarification en fonction des stocks disponibles, et retourne une recommandation pour l’exécution de la commande. Chaque appel à un outil représente en réalité un appel à un service avec une latence réelle.

Supposons que l’agent termine son travail en moins de deux secondes pour 80 % des requêtes, tandis que pour les 20 % restants, un service de gestion des stocks lent allonge les temps de réponse à 8 à 14 secondes. Ce n’est pas un problème lié à l’IA, mais plutôt un problème de systèmes distribués que le cycle d’action de l’agent a mis en évidence.

Le compromis qui est négligé

Un boucle d’agent n’est pas sans état. Chaque résultat d’outil est ajouté à la conversation et renvoyé au modèle lors du tour suivant. À un débit élevé, la mémoire consommée par chaque requête augmente avec le nombre de tours effectués par l’agent, tandis que le nombre total de requêtes devient moins important. Un service traitant 1 000 requêtes par minute avec en moyenne quatre tours effectue en réalité 4 000 appels à un LLM, les tailles de contexte s’accumulant au fil du temps.

Ainsi, avant d’écrire le moindre code d’agent, listez toutes les appels aux outils, estimez la latence p95 de chacun et calculez la taille maximale du contexte au nombre maximal de tours. Prévoyez l’espace de stockage du contexte avant de concevoir la boucle. La plupart des pannes d’agents dans les backends Java s’avèrent en fait être des pannes de délai masquées en tant que pannes du modèle.

Spring AI vous fournit les infrastructures, pas un plan

Spring AI est une couche d’abstraction sérieuse, conçue pour un environnement de production. Elle propose ChatClient, ToolCallback, VectorStore ainsi qu’une API d’exécution d’agents fonctionnant avec l’injection de dépendances, le changement de modèle via application.properties et un soutien réactif grâce à Flux. En tant que point de départ pour l’intégration des LLM dans Spring Boot, c’est le choix idéal.

Ce qu’elle ne fournit pas, c’est une stratégie pour les pipelines d’agents, et c’est cette lacune qui distingue les prototypes des services de production. Le framework gère les appels aux outils individuels et les interactions avec les modèles. Il ne gère pas :

• Les contrats à la frontière de service entre l’agent et les services en aval.
• La persistance de l’état de l’agent entre les requêtes, c’est-à-dire la mémoire de session.
• Une logique de circuit-breaker pour les pannes qui affectent plusieurs étapes.

Observabilité au niveau du flux de travail, comme la capacité à comprendre pourquoi l’agent a choisi une séquence particulière d’outils.

Rédiger une matrice de défaillance des outils

Avant le lancement, définissez pour chaque méthode @Tool ce qui se passe dans trois situations :

• L’outil renvoie la sortie attendue. L’agent passe à l’étape de raisonnement suivante.
• L’outil renvoie une erreur. L’agent reçoit le signal d’erreur et décide s’il faut réessayer, utiliser une solution de secours ou informer l’utilisateur.
• L’outil expiré. Un interrupteur de circuit est déclenché, une valeur de secours est renvoyée et l’agent est informé que les données ne sont pas disponibles.

Si les deuxième et troisième cas sont laissés vides pour un outil quelconque, l’intégration n’est pas achevée. Le scénario idéal n’est pas le service lui-même. Spring AI gère la méthode ; les raisons, le moment et les conséquences en cas d’échec restent à votre charge.

Les fenêtres de contexte se comportent comme des contrats non écrits

Dans un service Spring Boot ordinaire, enfreindre un contrat provoque une exception. Dans un agent, dépasser la taille de la fenêtre de contexte ne génère ni exception, ni alerte, ni entrée dans le journal des erreurs. Le modèle supprime silencieusement le contenu le plus ancien de la conversation, qui est souvent le prompt système contenant vos règles métier. Une API REST renvoie un code 400 lorsque vous enfreignez ses contrats ; une fenêtre de contexte, quant à elle, commence simplement à oublier, ce qui rend la détection de la panne beaucoup plus difficile.

Un incident illustratif

Imaginez un service de traitement de documents dont l’instruction système compte environ 800 tokens. Lors des tests, les réponses des outils atteignent en moyenne environ 1 600 tokens par requête, ce qui reste bien dans les limites du modèle. En environnement de production, un flux de travail particulier déclenche les trois appels aux outils avec de gros volumes de données, parmi lesquels une réponse concernant l’historique des commandes imbriquée comptant à elle seule environ 1 800 tokens. Le contexte total dépasse 6 000 tokens, l’instruction système est tronquée silencieusement et l’agent renvoie une réponse plausible qui omet une règle commerciale cruciale.

Rien ne génère d’erreur ni d’alerte. Le bug n’apparaît que lors d’un audit hebdomadaire, trois jours plus tard.

La solution : suivre les métriques de tokens dès le premier jour

Consommation de contexte de l’outil avant le déploiement. Avec Micrometer, cela signifie lire les comptes des tokens d’entrée et de sortie depuis l’objet usage des métadonnées de réponse et les publier chacun en tant qu’indicateur, par exemple sous des noms tels que agent.context.input_tokens et agent.context.output_tokens. Les noms exacts des accesseurs varient selon les versions de Spring AI, il faut donc vérifier l’API d’utilisation de la version que vous utilisez. Ensuite, déclenchez une alerte lorsque la consommation atteint environ 80 % de la limite de contexte du modèle. Cela correspond à peu près à deux beans et une propriété de configuration, et cela doit être mis en place avant le lancement. Déployer un agent sans métriques de tokens, c’est comme exécuter une base de données sans surveillance du temps d’exécution des requêtes, ce qui conduit généralement à des problèmes vers 2 heures du matin.

Le construire étape par étape

Prérequis : Spring Boot 3.2 ou une version ultérieure, Spring AI 1.0 ou une version ultérieure accompagnée du starter adapté à votre fournisseur de modèles (un starter OpenAI dans cet exemple), une maîtrise solide de @Async et CompletableFuture, un service interne à exposer en tant qu’outil, ainsi que Micrometer intégré à votre stack d’observabilité. Les noms des artefacts starters ont changé au fil des versions de Spring AI, il convient donc de vérifier le nom actuel dans la documentation de référence.

Étape 1 : ajouter les dépendances

Dans le pom.xml, ajoutez le starter Spring AI adapté à votre fournisseur, ainsi que l’artefact resilience4j-spring-boot3 si vous souhaitez disposer de la fonctionnalité de circuit-breaker pour les appels aux outils. Les identifiants du modèle sont indiqués dans application.properties. Lisez la clé API à partir d’une variable d’environnement telle que OPENAI_API_KEY via la propriété spring.ai.openai.api-key, sélectionnez le modèle de chat (l’exemple utilise gpt-4o) et maintenez une température basse, d’environ 0,2, afin que l’utilisation des outils reste prévisible.

Étape 2 : définir les outils avant de configurer l’agent

L’ordre est important car la conception des outils influence le comportement de l’agent. Un prompt système doit faire référence à des capacités concrètes des outils ; le rédiger avant leur existence génère des instructions vagues qui confondent le modèle.

Dans l’exemple, un composant OrderTools reçoit un InventoryService et un PricingService via son constructeur et expose deux méthodes annotées. checkInventory(String sku) renvoie la quantité disponible, ou -1 lorsque le SKU est inconnu. getPrice(String sku, String customerTier) renvoie un prix en centimes de dollars américains. Chaque méthode porte une annotation @Tool accompagnée d’une description.

La erreur courante consiste à rendre ces descriptions vagues. Le modèle les lit pour déterminer quand appeler chaque outil ; donc, des descriptions précises et complètes permettent moins d’appels inutiles et des réponses plus exactes. Précisez les unités, les valeurs de retour ainsi que le cas de non-recherche, comme le montrent les exemples ci-dessus.

Étape 3 : fournir au ChatClient un prompt système court

Une classe AgentConfig définit un bean ChatClient à partir du constructeur injecté ainsi que de OrderTools. L’instruction système par défaut est courte et impérative : agir en tant qu’assistant à la gestion des commandes, vérifier toujours les stocks avant de confirmer la disponibilité, obtenir toujours les prix avant de proposer une estimation, retourner un objet JSON contenant un booléen available, un entier price exprimé en centimes de dollar américain et une chaîne recommendation, et ne jamais inventer de niveaux de stock ou de prix. Les outils sont enregistrés sous defaultTools.

Ici, la discipline en matière de tokens est essentielle. Chaque token dans l’instruction système réduit l’espace réservé aux résultats des outils, il convient donc de viser moins de 300 tokens et d’éditer sans pitié.

Étape 4 : exécuter l’agent de manière asynchrone et enregistrer les tokens

Un OrderAgentService contient un ChatClient ainsi qu’un MeterRegistry. Sa méthode processOrder renvoie une CompletableFuture<String> et exécute l’appel de l’agent à l’intérieur de supplyAsync : elle envoie les entrées de l’utilisateur, appelle le modèle, reçoit la réponse du chat, lit les comptes des tokens d’entrée et de sortie et les enregistre comme indicateurs, avant de retourner le texte du résultat.

Pourquoi asynchrone ? Le temps d’exécution d’un agent est proportionnel au nombre d’appels aux outils, et non à la complexité apparente de la demande. Un thread de contrôleur synchrone bloqué pendant 8 à 14 secondes sur un service chargé épuisera le pool de threads. Traitez l’exécution des agents comme une tâche en arrière-plan dès le début.

Étape 5 : mettre un circuit breaker sur chaque outil

Commentez chaque méthode d’outil avec @CircuitBreaker de Resilience4j, en indiquant le nom du circuit de protection (par exemple inventoryTool) ainsi qu’une méthode de fallback. La méthode de fallback pour l’outil d’inventaire enregistre un avertissement accompagné du SKU et renvoie -1, ce qui indique à l’agent que les données d’inventaire ne sont pas disponibles. Les seuils doivent être définis dans application.properties : une fenêtre glissante de 10 appels, un seuil de taux d’échec de 50 % et un délai d’attente de 10 secondes dans l’état ouvert.

Si les circuits de protection ne semblent jamais être activés, n’oubliez pas que Spring AOP ne fonctionne que lorsque les appels passent par le proxy Spring. Injectez correctement les composants d’outil et ne les instanciez pas directement.

Étape 6 : exposer une extrémité avec un modèle de réponse asynchrone

Un OrderAgentController mappé sur /agent accepte une requête POST vers /orders, génère un ID de requête, lance l’agent et stocke l’état futur dans un tableau concurrentiel, puis répond avec un code 202 Accepted accompagné de cet ID. Une requête GET vers /orders/{requestId}/result permet de récupérer cet état futur. Elle renvoie un code 404 si l’ID est inconnu, un code 202 avec un message « Processing » tant que l’opération n’est pas terminée, un code 200 avec le résultat une fois l’opération achevée, et un code 500 avec un message d’erreur en cas d’échec de l’exécution. Pour tout usage au-delà d’une démonstration, remplacez le tableau en mémoire par un stockage capable de survivre aux redémarrages et de faire expirer les entrées anciennes.

Un point de décision s’applique aux outils eux-mêmes. Pour les appels de services internes à faible latence, conservez des outils synchrones et gérez les opérations asynchrones au niveau du service. Pour les API externes présentant une latence imprévisible, faites en sorte que les outils soient asynchrones en utilisant un pool de threads dédié ainsi qu’un délai d’expiration strict, afin qu’une dépendance lente ne provoque jamais une latence illimitée affectant le budget de temps alloué à l’agent.

Outils à connaître

• Spring AI est le framework principal pour les agents dans Spring Boot.
• LangChain4j est une alternative native de Java, souvent considérée comme plus performante pour la coordination entre plusieurs agents.
• Resilience4j fournit des mécanismes de protection et des tentatives de réessai pour les appels aux outils.
• Micrometer publie des informations sur l’utilisation des tokens et des métriques relatives aux agents.
• Ollama exécute des modèles open source localement pour le développement et les tests.

Trois erreurs qui gaspillent du temps et de la crédibilité

Le piège des débutants : ne tester qu’avec des données de parcours idéal. Les tutoriels utilisent des données de test propres et coopératives, mais les utilisateurs réels soumettent des données qui entraînent des exécutions longues, restent ambiguës ou déclenchent des comportements inhabituels des outils, seuls observables dans les données de production. Créez un outil capable de reproduire des échantillons de requêtes anonymisées issues de la production, et non des données synthétiques, contre l’agent en environnement de préparation avant chaque mise en production, et testez au minimum avec des données adverses dépassant le budget de contexte attendu.

Le point aveugle des experts : une sur-ingénierie avant le déploiement. Les ingénieurs familiers avec la littérature sur les systèmes multi-agents arrivent parfois avec des orchestrateurs, des sous-agents, des couches de mémoire et des pipelines RAG avant même qu’un seul agent n’ait interagi avec un utilisateur réel. C’est la version « AI composite » de la construction d’un service mesh avant de valider un monolithe. Déployez un agent avec un ensemble d’outils dans un seul service, mesurez-le, et n’ajoutez de complexité que là où les données l’exigent. Les équipes qui parviennent le plus rapidement en production ont évité de concevoir une plateforme avant d’avoir un produit concret.

L’échec systémique : personne ne est responsable du comportement de l’agent. Un échec conventionnel laisse une ligne de journal, une métrique et une alerte. Une réponse de l’agent, fausse mais plausible, ne laisse rien de tout cela : aucune exception, aucune alerte, simplement une réponse qui passe la validation du schéma mais échoue à la logique métier. Il faut désigner un responsable pour ce que dit l’agent, et non seulement pour le fait qu’il ait répondu, et examiner chaque semaine un échantillon de réponses plutôt que de se concentrer uniquement sur les taux d’erreur. Il s’agit davantage d’une décision organisationnelle que technique.

Ce que les guides de démarrage omettent

D’après la plupart des avis, la partie la plus difficile de l’intégration des agents Spring Boot n’est pas l’intelligence artificielle. Le comportement des modèles, l’ingénierie des prompts et l’interface de appel des outils peuvent être maîtrisés en environ une semaine. La difficulté réside dans le fait que l’héritage synchrone de Java entre en conflit avec la nature asynchrone et à plusieurs tours de l’exécution des agents.

Le modèle demande-réponse de Spring Boot suppose un temps d’exécution limité. Un agent, lui, ne l’est pas : il effectue autant d’appels d’outils que le travail le nécessite et effectue autant de tours de raisonnement que requis, sans tenir compte du délai de timeout de 30 secondes de votre passerelle. Les pipelines agents ne correspondent pas au modèle demande-réponse ; ils s’adaptent plutôt à un modèle basé sur les événements, et plus vous résisterez tardivement à cette approche, plus l’intégration mettra de temps à être mise en œuvre.

Les équipes qui rencontrent le plus de difficultés tentent de maintenir un traitement synchronique jusqu’à la réponse de l’agent. Ceux qui livrent le plus rapidement exécutent l’agent en tant que tâche en arrière-plan, le lancent sur demande, transmettent les résultats via des requêtes poll ou des WebSocket et conçoivent le contrat de service en fonction de cela. Cette réinterprétation fait défaut dans les documents de démarrage de Spring AI, et il n’est peut-être pas nécessaire qu’elle y figure.

Le modèle mental à retenir

Tout ce qui a été dit ci-dessus se résume en une phrase : un agent IA est un système distribué doté d’un moteur d’exécution non déterministe à l’intérieur de lui.

Les principes des systèmes distribués que tout ingénieur Java connaît déjà (isoler les pannes, observer le comportement, limiter le temps d’exécution, définir clairement les contrats de défaillance) s’appliquent ici avec encore plus d’importance, car les pannes sont plus discrètes et mettent plus de temps à se manifester. Ce qui est encourageant, c’est que Spring Boot convient très bien à ce type de travail. L’injection de dépendances, l’observabilité basée sur Actuator, les primitives asynchrones ainsi qu’un écosystème opérationnel mature constituent de réels avantages, et Spring AI est un framework sérieux. Le problème réside dans le modèle mental, et non dans les outils.

Règles pratiques :

• Considérez l’agent comme un cycle de raisonnement et conçez le contrat de service en fonction de ce cycle, et non de l’appel au modèle.
• Adoptez des agents lorsque le flux de travail dépend d’informations obtenues en cours d’exécution, ou lorsque l’orchestration existante est fragile et difficile à maintenir. Évitez-les lorsque le flux de travail est déterministe et que la version basée sur des règles fonctionne.
• Spring AI fournit le framework ; vous définissez la stratégie pour gérer les pannes des outils, les budgets de contexte et l’observabilité.
• Considérez les fenêtres de contexte comme des contrats et surveillez la consommation de tokens avant le lancement, et non après le premier incident.
• Exécutez l’exécution des agents de manière asynchrone dès le début, car une conception basée sur les événements est plus efficace lorsque les approches demande-réponse posent des problèmes.

Questions fréquentes

Quel framework est le mieux adapté aux agents dans Spring Boot ? Spring AI est l’option la plus appropriée pour les applications Spring Boot. LangChain4j constitue une alternative solide offrant un soutien plus étendu pour la coordination entre plusieurs agents, et les deux sont activement maintenus.

Les microservices existants doivent-ils être réécrits ? Non. Cette approche permet d’étendre un service à l’aide de l’annotation @Tool de Spring AI, d’un bean ChatClient ainsi que d’une exécution @Async, sans toucher à la logique du service existant.

Comment gérer les pannes des agents en production ? Il faut envelopper chaque méthode @Tool dans un circuit breaker Resilience4j, publier la consommation de tokens via Micrometer, définir une matrice de défaillance des outils avant le lancement, et désigner quelqu’un chargé d’évaluer la qualité des réponses, et non seulement les taux d’erreur.

En quoi un agent diffère-t-il d’une simple appel à un LLM ? Un appel simple correspond à une seule requête et une seule réponse. Un agent, quant à lui, représente une boucle dans laquelle le modèle peut appeler des outils, lire leurs résultats, les analyser et décider de continuer ou de répondre au cours de plusieurs échanges.

Spring Boot est-il prêt pour les charges de travail d’agents en production ? Oui, à condition de faire les bons choix architecturaux. L’exécution asynchrone, les disjoncteurs de circuit, les métriques de tokens et une gestion explicite de la fenêtre de contexte peuvent tous être mis en œuvre à l’aide de bibliothèques existantes et stables.

Quel est le rôle de RAG ? RAG n’est qu’un des modèles d’outils possibles : l’agent récupère des documents pertinents depuis un stockage vectoriel afin d’enrichir son contexte avant de raisonner. Il est utile lorsque l’agent a besoin d’une grande base de connaissances, mais il n’est pas indispensable pour chaque intégration ; de plus, son introduction complique les choses, ce qui ne devrait se faire que lorsque la limite de la fenêtre de contexte pose réellement des problèmes.