Comment fonctionnent les agents IA : du LLM à la boucle de rétroaction

Taper une question dans ChatGPT et recevoir une réponse est une chose. Demander à un système "recherchez les concurrents de mon entreprise, créez un tableau comparatif et envoyez-le moi par e-mail" et voir cela se faire tout seul, en plusieurs étapes, en est une autre complètement différente. La seconde est ce qu'on appelle aujourd'hui un agent IA, et comprendre comment il fonctionne de l'intérieur nécessite de séparer six pièces qui, ensemble, transforment un modèle qui ne fait que prédire du texte en quelque chose qui décide, agit et corrige son propre parcours.

Qu'est-ce qu'un agent IA

Un agent IA est un système construit autour d'un LLM (modèle de langage) qui peut exécuter des tâches en plusieurs étapes de manière autonome, en décidant lui-même quelle action prendre à chaque étape, en fonction de l'état actuel de la tâche. La différence centrale avec un chatbot ordinaire n'est pas le modèle sous-jacent, généralement le même, c'est l'architecture qui l'entoure : une mémoire entre les étapes, un cycle de planification, un accès à des outils et un mécanisme de répétition jusqu'à ce que la tâche soit terminée.

Cela change complètement le type de travail que le système peut effectuer. Un chatbot répond à une question et s'arrête. Un agent peut rechercher, lire le résultat, se rendre compte qu'il manque des informations, rechercher à nouveau avec un terme différent, organiser le tout et ensuite seulement fournir la réponse finale, sans que l'utilisateur ait besoin d'intervenir à chaque étape.

Le terme est devenu un parapluie utilisé pour des produits très différents : des agents de code qui modifient des dépôts entiers, des agents de navigateur qui remplissent des formulaires et cliquent sur des boutons, des agents de service client qui consultent des systèmes internes avant de répondre à un client. Ce qu'ils ont tous en commun, malgré leur apparence si distincte, est précisément cette structure en six pièces que cet article détaille. Comprendre chaque pièce séparément permet de comparer différents produits de manière équitable, au lieu de tout juger par le résultat final qui apparaît à l'écran.

Il convient également de délimiter ce qu'un agent n'est pas. Il n'est pas un système avec "libre arbitre" et ne prend pas de décisions en dehors du cadre défini par le développeur : l'ensemble des outils disponibles, les limites d'itération et les critères de succès sont tous configurés à l'avance. L'autonomie d'un agent est réelle dans ces limites, mais les limites elles-mêmes restent définies par des humains.

LLM : le moteur de raisonnement

Le LLM est le composant qui décide quoi faire ensuite, mais il convient de dissiper un malentendu courant : le modèle ne "se souvient" de rien entre deux appels. Chaque fois que l'agent a besoin d'une décision, il construit une nouvelle invite complète (avec l'historique, les résultats des outils, les instructions) et l'envoie au modèle, qui répond de manière stateless, sans mémoire propre intégrée.

Ce qui donne l'impression que le LLM "raisonne" sur plusieurs étapes est une technique appelée chain-of-thought : au lieu de sauter directement à une réponse, le modèle est incité à exposer des étapes intermédiaires de raisonnement avant de décider l'action finale. Cela améliore considérablement la qualité des décisions complexes, car le processus même "d'écrire en pensant" aide le modèle à ne pas sauter d'étapes logiques importantes.

En pratique, le LLM dans un agent remplit un rôle très spécifique : regarder l'état actuel (ce qui a été fait, ce que l'outil a renvoyé, quel est l'objectif original) et décider la prochaine action, qu'il s'agisse d'appeler un outil, de demander plus d'informations à l'utilisateur ou de conclure que la tâche est terminée.

Un point qui surprend souvent les débutants : le même modèle, avec la même invite, peut générer des décisions légèrement différentes lors d'exécutions distinctes. Cela se produit parce que la génération de texte dans un LLM est probabiliste, pas déterministe, contrôlée par un paramètre appelé température. Dans les agents qui prennent des décisions sensibles (comme déplacer de l'argent ou supprimer des données), il est courant de configurer une température basse pour réduire cette variation et rendre le comportement plus prévisible, bien que jamais parfaitement déterministe.

Il convient également de noter que "le LLM" d'un agent est rarement un seul appel de modèle. Les systèmes plus sophistiqués utilisent différents modèles pour différentes étapes : un modèle moins cher et plus rapide pour les décisions simples de routage, et un modèle plus grand et plus cher uniquement pour les étapes qui nécessitent un raisonnement approfondi. Cette division du travail permet de contrôler les coûts sans sacrifier la qualité là où elle compte.

Mémoire

Comme le modèle ne garde rien tout seul, toute la "mémoire" d'un agent est en réalité de l'ingénierie de contexte : décider quoi remettre dans l'invite à chaque appel. Il existe en pratique deux types :

• Mémoire à court terme : l'historique de la conversation ou de l'exécution en cours, qui tient dans la fenêtre de contexte du modèle. Elle croît à chaque étape de l'agent, et dans les tâches longues, elle peut devoir être résumée pour ne pas dépasser la limite de tokens.
• Mémoire à long terme : les informations qui doivent survivre au-delà d'une seule exécution, stockées en dehors du modèle, dans une base de données, un fichier ou un index vectoriel, et récupérées à la demande lorsqu'elles sont pertinentes. La technique la plus courante pour cela est le RAG (retrieval-augmented generation) : avant de répondre, le système recherche les passages les plus pertinents de cette mémoire externe et les injecte dans l'invite.

Un exemple pratique aide à fixer la différence : un agent de programmation qui lit le code d'un projet garde le fichier ouvert au moment présent comme mémoire à court terme, mais les conventions de l'équipe (comme "utilisez toujours TypeScript strict" ou "n'utilisez jamais la bibliothèque X") sont généralement sauvegardées comme mémoire à long terme, dans un fichier de configuration qui est rechargé à chaque nouvelle session.

La fenêtre de contexte d'un modèle, aussi grande soit-elle, a une limite physique de tokens, et chaque token coûte de l'argent et du temps de traitement. Cela oblige le constructeur de l'agent à prendre des décisions constantes sur ce qui vaut la peine d'être conservé dans la mémoire à court terme et ce qui peut être résumé ou jeté. Une technique courante est la compression progressive : après un certain nombre d'étapes, l'agent lui-même génère un résumé de ce qui s'est passé jusqu'à présent, remplace l'historique brut par ce résumé et poursuit l'exécution avec un contexte beaucoup plus léger.

Pour la mémoire à long terme basée sur le RAG, le mécanisme sous-jacent implique généralement une base de données vectorielle : chaque morceau d'information est converti en un vecteur numérique (embedding) qui représente sa signification, et la recherche ne cherche pas des mots exacts, mais les vecteurs les plus similaires sémantiquement à la question actuelle. C'est pourquoi un agent avec un RAG bien configuré peut trouver un document pertinent même s'il utilise des mots complètement différents de ceux tapés par l'utilisateur.

Planification

Face à une tâche complexe, un agent résout rarement tout en un seul appel au modèle. Le modèle le plus utilisé aujourd'hui est le ReAct (Reasoning and Acting), publié en 2022 : le modèle alterne entre "penser" (raisonner sur ce qu'il faut faire) et "agir" (appeler un outil), en observant le résultat de chaque action avant de décider la suivante, plutôt que d'essayer de prédire le plan entier d'un coup.

Il existe également le modèle "plan-and-execute", dans lequel le modèle écrit d'abord un plan complet avec plusieurs étapes, puis commence à les exécuter une par une. Il a tendance à être plus prévisible, mais moins flexible : si une étape en cours de route échoue ou révèle de nouvelles informations, l'agent doit replanifier, ce qui n'est pas toujours traité automatiquement dans cette conception.

En pratique, la plupart des agents de production mélangent les deux : un plan initial approximatif, révisé tous les quelques pas en fonction de ce qui s'est réellement passé, plutôt que suivi aveuglément du début à la fin.

Un exemple concret du modèle ReAct en action : demandez à un agent "quels sont les horaires d'ouverture du magasin le plus proche de moi qui a le produit X en stock". Un plan rigide, fait d'un coup, échouerait probablement, car l'agent ne sait pas encore quels magasins existent ni lesquels ont le produit. Avec ReAct, le modèle raisonne d'abord ("il faut trouver les magasins proches"), agit (appelle un outil de recherche par localisation), observe le résultat, raisonne à nouveau ("maintenant je dois vérifier le stock de chacun"), agit à nouveau, et seulement alors, avec suffisamment d'informations, formule la réponse finale. Chaque décision dépend du résultat de la précédente, ce qui serait impossible à prévoir dans un plan unique et fixe.

Il existe également la question de la profondeur de planification : les tâches simples peuvent sauter l'étape de planification explicite et aller directement au choix de l'outil, tandis que les tâches complexes, avec de nombreuses dépendances entre sous-tâches, bénéficient d'un plan écrit explicitement, parfois même montré à l'utilisateur avant de commencer l'exécution, afin qu'il puisse approuver ou ajuster le cap avant qu'une action réelle ne soit entreprise.

Outils

Les outils sont ce qui donne à l'agent la capacité d'agir dans le monde réel, au-delà de la simple génération de texte : rechercher sur le web, exécuter du code, interroger une base de données, envoyer un e-mail. Le mécanisme technique derrière cela est le function calling (ou tool calling) : le développeur décrit chaque outil disponible, avec un nom, une description et un schéma des paramètres qu'il accepte, et le modèle renvoie une réponse structurée indiquant quel outil appeler et avec quels arguments.

Le modèle lui-même n'exécute jamais l'outil. Il ne fait que décider et formater l'appel ; celui qui exécute effectivement le code, fait la requête HTTP ou interroge la base de données est le logiciel autour du modèle. Cette séparation est importante : elle signifie que le même "cerveau" peut être connecté à des outils complètement différents sans avoir besoin d'être réentraîné, simplement en reconfigurant quelles fonctions sont disponibles dans l'invite.

Le Model Context Protocol (détaillé dans l'article précédent sur MCP) résout précisément la partie de normalisation de la façon dont ces outils sont décrits et découverts, afin qu'un agent n'ait pas besoin d'une intégration spécifique pour chaque service externe qu'il utilise.

En pratique, les outils d'un agent se regroupent généralement en quelques catégories récurrentes : recherche et lecture d'informations (web, documents, bases de données), action sur des systèmes externes (envoyer un e-mail, créer un ticket, mettre à jour un tableur), exécution de code (exécuter un script, une requête SQL, une commande de terminal) et communication avec l'utilisateur lui-même (demander une confirmation, poser une question de clarification). Un agent bien conçu ne reçoit généralement pas l'accès à tous les outils disponibles dans le système à la fois, seulement le sous-ensemble nécessaire à la tâche en question, suivant le même principe de moindre privilège utilisé dans la sécurité des systèmes traditionnels.

La qualité de la description de chaque outil est plus importante qu'il n'y paraît. Un nom vague comme process_data avec une description d'une ligne tend à générer des appels erronés ou mal formatés, car le modèle n'a pas assez de contexte pour décider quand l'utiliser. Des descriptions spécifiques, avec des exemples d'utilisation et des limites claires (ce que l'outil ne fait pas), réduisent considérablement le taux d'erreur à cette étape.

Exécution

L'exécution est la couche logicielle, généralement appelée runtime ou orchestrateur de l'agent, qui reçoit la décision du LLM et la met effectivement en pratique : appelle la bonne API, exécute la commande, attend la réponse, gère les erreurs si l'appel échoue. C'est également ici qu'interviennent les couches de sécurité : sandboxing pour le code généré par le modèle, limites de temps (timeout) pour chaque appel, et validation des paramètres avant d'exécuter quoi que ce soit d'irréversible.

Un détail qui prête à confusion : toute exécution n'est pas séquentielle. Les agents plus sophistiqués peuvent déclencher plusieurs outils en parallèle lorsqu'ils sont indépendants les uns des autres, comme rechercher dans trois sources différentes en même temps, ce qui réduit considérablement le temps total de la tâche par rapport à l'appel d'un outil à la fois et à l'attente de chaque réponse avant de continuer.

La gestion des erreurs dans cette couche est ce qui sépare un agent fragile d'un agent fiable. Un appel d'outil peut échouer pour des dizaines de raisons : l'API externe est hors ligne, les paramètres sont mal formatés, l'autorisation a été refusée, le temps limite a expiré. Un orchestrateur bien construit capture chaque type d'échec séparément et décide quoi en faire : réessayer automatiquement (avec une limite de tentatives, pour ne pas répéter indéfiniment un échec permanent), renvoyer l'erreur au LLM dans le cadre de l'observation afin qu'il essaie une approche différente, ou escalader le problème vers une intervention humaine lorsqu'aucune des options automatiques ne résout le problème.

Le sandboxing mérite une mention à part lorsque l'outil implique l'exécution de code généré par le modèle lui-même. Exécuter ce code directement dans le même environnement que celui où vit l'agent est un risque réel, donc les implémentations sérieuses isolent cette exécution dans un conteneur ou une machine virtuelle jetable, sans accès au réseau ou aux fichiers sensibles par défaut, en libérant seulement ce dont la tâche spécifique a réellement besoin.

Boucle de rétroaction

Après qu'un outil a été exécuté, son résultat ne disparaît pas : il revient dans le contexte, comme une nouvelle information que le LLM doit prendre en compte dans la prochaine décision. Ce cycle (percevoir l'état, planifier, agir, observer le résultat, mettre à jour le contexte) se répète autant de fois que nécessaire jusqu'à ce que l'une des deux choses suivantes se produise : le modèle décide que la tâche est terminée, ou l'agent atteint une limite de sécurité, comme un nombre maximal d'itérations ou un temps d'exécution total.

Cette limite d'itérations n'est pas un détail mineur. Sans elle, un agent mal configuré peut entrer dans un cycle où il répète la même action sans jamais considérer la tâche terminée, dépensant des tokens (et de l'argent) indéfiniment. C'est pourquoi pratiquement tous les frameworks d'agents sérieux intègrent une sorte de verrou : un compteur maximal d'étapes, une vérification explicite des critères de succès, ou l'exigence d'une confirmation humaine après un certain nombre de tentatives sans progrès.

Il convient de distinguer deux types d'arrêt. L'arrêt "heureux" se produit lorsque le LLM évalue l'état actuel par rapport à l'objectif original et conclut, de manière explicite, que tous les critères ont été remplis. L'arrêt par limite se produit lorsque l'agent épuise le nombre d'itérations ou le budget de temps/coût autorisé sans y parvenir, et dans ce cas, le comportement attendu n'est pas simplement de planter, mais de signaler à l'utilisateur ce qui a été fait jusqu'à ce point et pourquoi la tâche n'a pas pu être terminée seule.

Un modèle de plus en plus courant dans les systèmes de production est le human-in-the-loop : pour les actions à haut risque (déplacer de l'argent, supprimer des données, envoyer une communication publique), la boucle de rétroaction inclut une pause obligatoire en attendant l'approbation humaine avant de passer à l'itération suivante, même si l'agent a déjà décidé, seul, que cette action est la bonne.

Le cycle complet, en diagramme

En réunissant les six pièces, le cycle d'un agent IA devient :

Le point central de cette conception est que la flèche de retour n'est pas un détail esthétique : c'est ce qui sépare un agent d'un simple flux automatisé d'étapes fixes. L'agent décide, à chaque tour du cycle, s'il doit continuer ou s'il a déjà atteint l'objectif.

Chatbot vs agent

Il vaut la peine de les mettre côte à côte, car la ligne entre les deux n'est pas toujours évidente pour l'utilisateur du produit final :

Aspect	Chatbot traditionnel	Agent IA
Structure de la réponse	Une question, une réponse	Plusieurs étapes enchaînées jusqu'à atteindre un objectif
Accès aux outils	Rare ou inexistant	Central, via function calling ou MCP
Mémoire entre les étapes	Seulement l'historique de la conversation en cours	Court et long terme, souvent avec recherche externe (RAG)
Autonomie de décision	Faible, l'utilisateur guide chaque échange	Élevée, le système lui-même décide des prochaines étapes
Critère d'arrêt	Fin du message généré	Critère de succès de la tâche ou limite d'itérations

En pratique, la frontière est un spectre, pas une ligne nette : de nombreux produits sont aujourd'hui des chatbots avec quelques outils simples branchés, sans avoir un cycle de planification complet. Le terme "agent" tend à être réservé aux systèmes qui décident vraiment de leurs propres prochaines étapes, pas seulement exécutent une fonction lorsque l'utilisateur le demande explicitement.

Un test pratique pour différencier les deux lors de l'évaluation d'un produit : demandez une tâche qui nécessite au moins trois étapes dépendantes les unes des autres, sans détailler le processus, seulement le résultat souhaité. Un chatbot aura tendance à demander plus d'instructions ou à essayer de tout résoudre en une seule réponse unique et superficielle. Un véritable agent décompose la demande en sous-tâches, utilise des outils pour résoudre chacune d'elles, et ne livre le résultat final qu'après avoir terminé le cycle entier tout seul.

Exemple complet

Pour rendre tout cela concret, suivons un agent hypothétique d'étude de marché recevant la demande : "recherchez les 3 principaux concurrents de mon entreprise au Brésil et envoyez-moi un résumé par e-mail".

Étape 1, planification : le LLM décompose la demande en sous-tâches : trouver des concurrents, collecter des données sur chacun, synthétiser en un résumé, envoyer par e-mail. Ce plan initial reste stocké dans la mémoire à court terme de l'exécution.

Étape 2, premier outil : l'agent appelle un outil de recherche web avec la requête "principaux concurrents [entreprise] Brésil". Le résultat (une liste de noms et de liens) revient en tant qu'observation.

Étape 3, rétroaction et replanification : le LLM observe que la recherche a renvoyé 5 noms, mais il n'en faut que 3. Il filtre les plus pertinents et décide, pour chacun, d'appeler un nouvel outil qui extrait les données publiques de base (taille, principaux produits, présence sur le marché).

Étape 4, exécution parallèle : comme les trois concurrents sont indépendants les uns des autres, l'orchestrateur déclenche les trois appels d'extraction en même temps, plutôt que l'un après l'autre, économisant du temps total.

Étape 5, synthèse : avec les trois ensembles de données dans la mémoire à court terme, le LLM génère le texte du résumé comparatif, déjà formaté.

Étape 6, dernier outil : l'agent appelle l'outil d'envoi d'e-mail, en passant le résumé généré comme corps du message.

Étape 7, conclusion : le LLM observe la confirmation d'envoi, vérifie que tous les éléments du plan initial ont été remplis, et termine le cycle, répondant à l'utilisateur que la tâche est terminée.

Remarquez qu'à aucun moment l'utilisateur n'a eu besoin d'intervenir entre les étapes. Cela n'est possible que parce que chacune des six pièces (LLM, mémoire, planification, outils, exécution, boucle de rétroaction) a joué exactement le rôle décrit dans les sections précédentes.

FAQ

Un agent IA a-t-il toujours besoin d'une mémoire à long terme ?

Non. Les tâches simples, résolues en une seule session, peuvent fonctionner uniquement avec une mémoire à court terme (l'historique de l'exécution en cours). La mémoire à long terme est importante lorsque l'agent doit se souvenir de quelque chose entre différentes exécutions.

Combien d'itérations un agent effectue-t-il généralement avant de s'arrêter ?

Cela varie beaucoup avec la complexité de la tâche et la configuration du framework utilisé, mais la plupart des systèmes de production définissent une limite explicite, généralement entre 5 et 25 itérations, pour éviter les boucles sans fin.

Un chatbot avec des plugins est-il déjà un agent ?

Cela dépend du degré d'autonomie. Si l'utilisateur doit demander explicitement chaque action, c'est plutôt un chatbot avec des outils. Si le système décide lui-même de la séquence d'actions nécessaires pour atteindre un objectif, c'est déjà un comportement d'agent.

Que se passe-t-il si un outil échoue en cours d'exécution ?

Cela dépend de l'orchestrateur. Les implémentations robustes renvoient l'erreur dans le cadre de l'observation, et le LLM décide s'il réessaie, essaie une approche différente ou signale l'échec à l'utilisateur, plutôt que de bloquer tout le cycle.

Est-il possible qu'un agent utilise plusieurs LLM en même temps ?

Oui, et c'est de plus en plus courant. Un modèle plus petit et moins cher peut gérer les décisions simples de routage, tandis qu'un modèle plus grand n'intervient que dans les étapes nécessitant un raisonnement plus profond, ce qui aide à contrôler le coût total de l'exécution sans perdre en qualité dans les parties les plus importantes.

Jargon mis à part, un agent IA n'est pas une technologie nouvelle isolée, c'est une manière spécifique d'organiser des pièces déjà connues (un modèle de langage, une certaine forme de mémoire, un accès à des outils) dans un cycle qui se répète jusqu'à ce qu'un objectif soit atteint. Comprendre ces six pièces séparément est ce qui permet de diagnostiquer pourquoi un agent spécifique échoue, boucle ou livre un résultat incomplet, au lieu de traiter l'ensemble du système comme une boîte noire.