LLM agent : comment fonctionne un agent IA

Un agent LLM tient dans une boucle d'une vingtaine de lignes. Le modèle lit une demande, répond par un appel d'outil, votre code exécute cet appel, renvoie le résultat, et le modèle repart pour un tour. Les frameworks d'orchestration, les couches de mémoire et les schémas d'architecture que vous croisez ne sont que des variations autour de ces quatre étapes.

Écrire cette boucle prend une heure. La faire tenir quand elle tourne mille fois par jour sur des données clientes, avec des outils qui échouent et des factures d'API qui grimpent, prend beaucoup plus longtemps. Cet article détaille ce qui se passe réellement à chaque tour, ce que ça coûte, et les quatre endroits où les agents cassent le plus souvent sur les projets que nous reprenons. Il s'adresse aux développeurs et aux responsables techniques qui doivent construire, auditer ou reprendre un agent existant.

La boucle qui fait l'agent

Un agent LLM est une boucle de quatre étapes qui tourne jusqu'à une condition d'arrêt. Vous envoyez au modèle une demande, la liste des outils disponibles et l'historique de la conversation. Le modèle renvoie soit du texte, soit un ou plusieurs appels d'outils sous forme de JSON structuré. Votre code exécute ces appels, renvoie les résultats au modèle dans un message dédié, et le cycle recommence. Quand le modèle répond enfin par du texte sans appeler d'outil, la boucle sort.

Le point que les schémas marketing gomment systématiquement : le modèle n'exécute rien. Il produit un objet JSON qui dit « appelle rechercher_client avec ce numéro de dossier ». C'est votre code qui interroge la base, envoie l'email ou déclenche le virement. L'intelligence du modèle porte sur le choix et l'enchaînement des appels, jamais sur leur exécution. Cette séparation est la meilleure nouvelle de toute l'architecture, parce que tout ce qui touche vos données reste dans du code que vous testez normalement.

Déclarer des outils a un prix, même quand le modèle n'en appelle aucun. La documentation de l'API Claude chiffre ce surcoût : 286 tokens de prompt système s'ajoutent à chaque requête sur Claude Opus 5 dès qu'au moins un outil est déclaré, et 406 tokens si vous forcez l'appel d'outil. À cela s'ajoutent vos propres définitions, réémises à chaque tour. Si vous voulez d'abord la vue d'ensemble avant d'entrer dans la mécanique, notre article sur ce qu'est vraiment un agent IA pose le vocabulaire.

Ce que le modèle relit à chaque tour

À chaque tour, le modèle relit tout. L'API est sans état : elle ne garde rien entre deux appels, donc votre code réémet l'intégralité de la conversation, appels d'outils et résultats compris, à chaque itération. Un agent qui a fait huit tours envoie au huitième appel les sept précédents, en plus du prompt système et des définitions d'outils.

Cette accumulation a une conséquence financière directe. Prenons un agent avec un préfixe stable de 5 000 tokens (prompt système plus définitions d'outils) et huit tours qui ajoutent chacun 1 500 tokens d'appel et de résultat. Le préfixe est facturé huit fois, soit 40 000 tokens, et l'historique cumulé pèse 54 000 tokens de plus. Au tarif de Claude Opus 5, 5 $ par million de tokens en entrée et 25 $ en sortie, une seule tâche revient autour de 0,61 $ en comptant la génération. À 200 tâches par jour, la facture approche 120 $ quotidiens pour un agent qui ne fait qu'une chose.

Deux leviers réduisent cette note, et le premier est gratuit. Sur Claude Opus 5, la relecture d'un préfixe déjà mis en cache est facturée 0,50 $ par million de tokens, soit 10 % du tarif d'entrée, ce qui divise par dix le coût du préfixe stable. Encore faut-il que ce préfixe soit vraiment stable : sur un audit récent, un simple horodatage inséré en tête du prompt système invalidait le cache à chaque appel, et personne ne s'en apercevait puisque l'agent fonctionnait. Le second levier consiste à ne pas tout garder, ce qui nous amène à la mémoire. Pour la partie budgétaire, notre guide pour maîtriser les coûts d'un LLM en entreprise détaille le tableau de bord à mettre en place avant la mise en production.

La taille du contexte n'est plus la contrainte qu'elle était. Claude Opus 5 accepte 1 million de tokens en entrée, soit environ 555 000 mots, et produit jusqu'à 128 000 tokens par réponse sur l'API synchrone. La limite qui mord aujourd'hui est économique, et accessoirement cognitive : un modèle noyé sous 400 000 tokens d'historique choisit moins bien ses outils qu'un modèle à qui on a donné les 5 000 tokens utiles.

Les outils : la description est votre vrai code

La description d'un outil est la seule spécification que le modèle lit, et elle décide de la qualité des appels bien plus que le modèle choisi. Un outil se réduit en effet à trois choses : un nom, une description en langage naturel et un schéma JSON des paramètres. Cette description occupe dans un agent exactement la place qu'une signature de fonction et sa documentation occupent dans une bibliothèque : mal écrite, elle produit des appels absurdes que ni les types ni les tests unitaires n'attraperont.

Trois règles nous servent sur tous les projets. Découper par intention métier plutôt que par point d'entrée technique : un outil reprogrammer_rendez_vous vaut mieux que trois outils qui exposent votre API REST telle quelle, parce que le modèle raisonne en intentions. Valider les arguments côté serveur systématiquement, en traitant le modèle comme un client non authentifié : il produira tôt ou tard un identifiant qui n'existe pas ou une date au mauvais format. Et renvoyer les erreurs au modèle dans le résultat d'outil, plutôt que de faire planter la boucle, parce qu'un message clair du type « ce dossier est clôturé, aucune modification possible » le fait corriger son tir tout seul au tour suivant.

Le nombre d'outils compte aussi. Chaque définition est réémise à chaque tour et pèse dans la fenêtre, et le choix se dégrade quand deux outils se ressemblent trop. Sur nos agents en production, nous restons rarement au-delà d'une dizaine d'outils par agent ; au-delà, il vaut mieux découper en plusieurs agents spécialisés qu'un seul agent omniscient. Notre méthode complète pour construire un agent qui tient en production reprend ce découpage étape par étape.

MCP, pour brancher les outils une seule fois

Le Model Context Protocol standardise la connexion entre une application qui héberge un modèle et les services qui lui fournissent des outils et des données. Il règle un problème d'intégration bête mais coûteux : sans standard, connecter cinq applications à huit sources de données demande quarante intégrations sur mesure, chacune à maintenir.

La spécification, dans sa révision du 28 juillet 2026, s'appuie sur JSON-RPC 2.0 et distingue trois rôles : les hôtes, qui sont les applications LLM qui ouvrent les connexions, les clients qui vivent dans ces hôtes, et les serveurs qui exposent les capacités. Un serveur peut offrir trois primitives : des ressources (des données à lire), des prompts (des modèles de messages) et des outils (des fonctions à exécuter). Nous avons détaillé le fonctionnement du Model Context Protocol et la façon de créer votre propre serveur MCP dans deux articles dédiés.

Un avertissement de la spécification mérite d'être lu deux fois par toute équipe qui branche un serveur tiers : les descriptions du comportement d'un outil doivent être considérées comme non fiables, sauf si elles proviennent d'un serveur de confiance. Une description d'outil est du texte que le modèle lit et suit. Un serveur malveillant peut donc y glisser des instructions. Notre position sur les projets clients est simple : les serveurs MCP externes passent par une revue au même titre qu'une dépendance logicielle, et les outils qui touchent à de l'argent ou à des données personnelles restent des outils maison. Pour un agent unique avec trois outils internes, l'appel direct reste plus simple ; MCP prend son intérêt dès que plusieurs agents partagent les mêmes sources.

Trois mémoires que l'on confond en permanence

Quand une équipe dit « mémoire », elle parle de trois mécanismes différents qui ne se remplacent pas. Le premier est le contexte du tour, l'historique brut que le modèle relit. Le deuxième est l'état de la tâche : le dossier en cours, les étapes déjà validées, les identifiants créés. Le troisième est la connaissance externe, ces documents que l'agent va chercher au moment où il en a besoin.

Notre position est tranchée sur le deuxième. L'état de la tâche doit vivre dans une base de données, écrit et relu par vos outils, jamais dans l'historique de conversation. Un historique se tronque, se résume, se perd quand la session redémarre, et rien ne vous permet de le requêter. Un agent qui a créé une commande doit écrire cette commande quelque part, et pouvoir la relire au tour suivant par un appel d'outil explicite. Les agents que nous reprenons échouent souvent sur ce point précis : ils fonctionnent tant que la conversation est courte, et perdent le fil dès qu'elle dépasse la douzaine de tours.

Pour le premier, la compaction automatique proposée par les fournisseurs résume l'historique ancien quand il approche du plafond. Le mécanisme est utile, avec une réserve : il résume une trace de conversation, pas des faits métier. Un numéro de dossier peut disparaître dans le résumé. Le troisième mécanisme, la recherche documentaire, relève d'une architecture à part entière, avec sa base vectorielle et sa stratégie de découpage. Un agent bien conçu appelle cette recherche comme un outil parmi d'autres, plutôt que de tout précharger dans son contexte.

Arrêter l'agent, la partie qu'on oublie d'écrire

La condition d'arrêt est la première chose à écrire, et celle qui manque le plus souvent dans le code que nous auditons. Un agent sans compteur de tours qui se retrouve devant un outil en échec permanent réessaie, reformule, réessaie encore, et vous découvrez la boucle infinie sur la facture du mois. Trois bornes suffisent à couvrir l'essentiel des cas.

À ces bornes s'ajoute une règle sur les actions irréversibles. Envoyer un email, encaisser un paiement, supprimer un enregistrement : ces appels passent par une validation humaine ou par un mécanisme d'idempotence, avec une clé unique par action, pour qu'un rejeu de la boucle ne produise pas deux virements. Sur un agent qui écrit dans un outil métier client, nous plaçons systématiquement un journal des appels d'outils, avec les arguments et le résultat de chacun. Ce journal sert au débogage, mais il est surtout la seule façon de répondre honnêtement à la question « qu'est-ce que l'agent a fait le 14 à 9 h 12 ». Une réponse crédible sur ce point conditionne la mise en production chez la plupart de nos clients.

Quand la boucle est le mauvais choix

Si vous connaissez le chemin à l'avance, un enchaînement déterministe fera mieux qu'un agent, pour moins cher. Extraire trois champs d'une facture, les vérifier et les écrire dans un tableur ne demande aucune décision : un workflow classique qui appelle le modèle une fois par étape est plus rapide, plus facile à tester et bien plus prévisible en coût. Le critère de choix tient en une question : l'incertitude porte-t-elle sur le chemin, ou seulement sur le contenu ? Un chemin connu ne mérite pas de boucle.

Le coût d'une erreur pèse tout autant. Un agent qui se trompe dans une recherche documentaire fait perdre trente secondes ; un agent qui se trompe dans une remise commerciale fait perdre de l'argent et de la crédibilité. Plus l'erreur coûte cher, plus la part déterministe de votre architecture doit être grande, et plus les garde-fous décrits plus haut doivent être serrés.

Le choix du modèle vient en dernier, et c'est le paramètre le plus facile à changer. Les étapes simples d'une boucle, classer une demande ou reformuler une requête, tournent très bien sur un modèle rapide comme Claude Haiku 4.5, facturé 1 $ par million de tokens en entrée et 5 $ en sortie. Pour les organisations qui veulent rester chez un fournisseur européen, Mistral affiche un tarif de 0,5 $ par million de tokens en entrée et 1,5 $ en sortie pour Mistral Large. Faites tourner la même boucle sur deux modèles avant de trancher : nous découvrons régulièrement que le modèle le plus cher n'apporte rien sur les étapes mécaniques, et tout sur celle qui décide. Si vous préférez faire cadrer l'architecture avant d'écrire la boucle, notre agence spécialisée dans les agents IA intervient sur ce type de projet, du prototype à la mise en production.

Questions fréquentes

Faut-il un framework pour construire un agent LLM ?

Pas au départ. La boucle brute tient en une vingtaine de lignes avec le SDK officiel du fournisseur, et vous comprenez exactement ce qui part dans chaque requête. Les frameworks apportent de la valeur quand vous multipliez les agents, les outils partagés et les traces à collecter. Commencer par le framework revient souvent à déboguer une abstraction avant d'avoir compris le mécanisme qu'elle cache.

Combien de tours faut-il autoriser dans la boucle ?

Mesurez avant de fixer la borne. Faites tourner une trentaine de cas réels, regardez la distribution du nombre de tours, puis placez la limite nettement au-dessus du pire cas légitime, souvent entre 10 et 25. Une limite trop basse coupe des tâches valides, une limite absente laisse passer les boucles infinies. Dans les deux cas, le dépassement doit produire une alerte, jamais un échec silencieux.

Comment teste-t-on un agent dont les réponses varient ?

En testant séparément ce qui est déterministe et ce qui ne l'est pas. Vos outils se testent comme du code normal, avec une couverture classique. Le comportement du modèle se teste sur un jeu de cas réels rejoué à chaque changement de prompt ou de modèle, en vérifiant les outils appelés et l'état final plutôt que le texte produit. Une même tâche doit être rejouée plusieurs fois : un agent qui réussit une fois sur deux n'est pas prêt.

Un agent LLM peut-il tourner sans envoyer de données hors d'Europe ?

Oui, à condition de choisir le fournisseur en conséquence. Des modèles européens comme ceux de Mistral, ou des modèles ouverts hébergés sur une infrastructure européenne, se pilotent avec exactement la même boucle : seul le client d'API change. La logique de l'agent, ses outils et ses garde-fous restent identiques, ce qui rend le changement de fournisseur beaucoup moins douloureux qu'on ne le craint au moment de la conception.

Quelle différence avec un chatbot connecté à des plugins ?

Le droit de rappeler le modèle. Un chatbot avec plugins fait un aller-retour : une question, éventuellement un appel de fonction, une réponse. Un agent boucle sur les résultats et enchaîne les appels sans intervention, ce qui lui permet d'accomplir une tâche en plusieurs étapes. Cette autonomie est précisément ce qui rend les compteurs, les validations et le journal des appels indispensables.