En bref
Une boucle d'agent IA est le cycle répétitif qui transforme un modèle de langage en agent : il perçoit une entrée, raisonne sur ce qu'il faut faire, agit en appelant un outil, observe le résultat, puis reboucle, encore et encore, jusqu'à ce que la tâche soit terminée ou qu'une règle d'arrêt s'enclenche. Cette unique idée architecturale constitue toute la différence entre un agent et un chatbot. Un chatbot répond en une seule passe ; un agent poursuit, enchaîne les étapes et peut se rétablir quand quelque chose échoue.
C'est pourquoi les gens appellent, à moitié pour plaisanter, un agent « un LLM dans une boucle while avec des outils ». La boucle est aussi exactement la raison pour laquelle les agents fonctionnent pour le support client : un ticket est une tâche en plusieurs étapes (cerner le problème, chercher des informations, accomplir une action, vérifier que ça a marché, résoudre ou escalader), et c'est une boucle, pas une ligne droite. Si vous voulez faire tourner cette boucle au sein de votre helpdesk sans construire ni surveiller la plomberie vous-même, c'est ce que fait eesel.
La définition en une phrase
Une boucle d'agent IA (vous la verrez aussi appelée boucle agentique) est le cycle d'exécution itératif au cœur de tout système agentique. Un modèle perçoit de façon répétée une entrée, raisonne sur ce qu'il faut faire ensuite, agit en appelant un outil, puis observe le résultat et l'injecte dans le tour suivant, en répétant jusqu'à ce que la tâche soit terminée ou qu'une condition d'arrêt soit atteinte.
L'équipe de développeurs d'Oracle formule la distinction sans détour : « La différence architecturale entre un chatbot et un agent IA tient à un seul motif : la boucle d'agent ». La version du praticien Simon Willison est encore plus courte. Un agent, écrit-il, est quelque chose qui « exécute des outils en boucle pour atteindre un objectif ».
C'est sincèrement l'essentiel du concept. La partie intéressante, c'est ce que chaque étape de la boucle fait réellement, pourquoi la boucle débloque des choses qu'un seul appel au modèle ne peut pas, et où elle fait ses preuves.
Les quatre étapes : percevoir, raisonner, agir, observer
La plupart des descriptions ramènent la boucle à quatre étapes qui se répètent. Oracle utilise une version à cinq étapes (elle sépare la planification du raisonnement), mais la mécanique est la même dans les deux cas.
- Percevoir. L'agent reçoit une entrée : un message d'utilisateur, une réponse d'API, une erreur, ou le résultat de sa propre dernière action.
- Raisonner. Le modèle examine tout ce qui se trouve dans son contexte et décide quoi faire ensuite. Pour les tâches plus difficiles, c'est aussi là qu'il planifie, en décomposant l'objectif en étapes plus petites avant d'agir.
- Agir. L'agent fait quelque chose dans le monde : un appel d'outil, une requête d'API, une requête de base de données, une exécution de code.
- Observer. L'agent examine le résultat. A-t-il fonctionné ? La tâche est-elle terminée ? Le plan doit-il changer ?
Puis il reboucle. Le tout se ramène à une poignée de lignes de pseudo-code, ce qui explique pourquoi la formule « ce n'est qu'une boucle while » est restée :
while not done:
response = call_llm(messages)
if response has tool_calls:
results = execute_tools(response.tool_calls)
messages.append(results)
else:
done = True
return response
Les grands laboratoires y sont tous arrivés indépendamment. Anthropic décrit les agents comme « généralement de simples LLM utilisant des outils en boucle sur la base du retour de l'environnement ». L'Agents SDK d'OpenAI documente son runner comme une boucle littérale : appeler le modèle et, s'il renvoie une réponse finale sans appel d'outil, s'arrêter ; sinon, exécuter les outils, ajouter les résultats et le relancer. Un résumé pratique en une ligne, à l'origine de Lilian Weng, est Agent = LLM + Mémoire + Planification + Utilisation d'outils. La boucle est le runtime qui relie ces quatre éléments.
Un exemple concret
Pour rendre cela tangible, voici une véritable exécution sur trois itérations pour la tâche « identifier l'article le plus cité sur la mémoire des agents publié en 2026 et en résumer les principales conclusions », tirée de l'article d'Oracle :
- Itération 1. Raisonner : il faut chercher. Agir : appeler une API de recherche. Observer : 15 articles avec leur nombre de citations reviennent.
- Itération 2. Raisonner : choisir le meilleur résultat avec 340 citations. Agir : appeler un outil de récupération de documents. Observer : le résumé et les sections clés sont renvoyés.
- Itération 3. Raisonner : assez d'éléments rassemblés. Agir : rédiger le résumé. Observer : tâche terminée, sortir de la boucle.
Comme le dit Oracle : « Trois itérations. Trois appels d'outils. Une réponse complète qu'aucun chatbot en une seule passe n'aurait pu produire. » Cette dernière proposition résume tout l'enjeu.
D'où vient l'idée : ReAct
La boucle n'est pas une invention de 2026. Sa colonne vertébrale académique est l'article ReAct (Yao et al., 2022), abréviation de « reasoning and acting » (raisonner et agir). Son intuition était d'entrelacer les traces de raisonnement avec les actions : une Thought (pensée) sur ce qu'il faut faire, puis une Action, puis une Observation, puis une autre pensée, et ainsi de suite. Le raisonnement, soutient l'article, « aide le modèle à induire, suivre et mettre à jour des plans d'action ainsi qu'à gérer les exceptions, tandis que les actions lui permettent de s'interfacer avec des sources externes ».
Le bénéfice mesuré était réel, et non vague : une amélioration absolue du taux de réussite de 34 % sur le benchmark ALFWorld et de 10 % sur WebShop par rapport aux meilleures lignes de base (arXiv:2210.03629). Un modèle qui ne fait que raisonner « souffre de désinformation car il n'est pas ancré dans des environnements externes », et un modèle qui ne fait qu'agir « souffre du manque de raisonnement ». Les combiner dans la boucle corrige les deux. Si la récupération fait partie de votre tableau, il vaut la peine de comprendre comment cela se rattache à la simple génération augmentée par récupération, que nous aborderons dans un instant.
Boucle d'agent face au chatbot : l'unique boucle while
Voici la comparaison qui compte, car c'est la question avec laquelle la plupart des gens arrivent réellement.
| Dimension | Chatbot traditionnel / RAG à tour unique | Boucle d'agent |
|---|---|---|
| Passes du modèle par requête | Une | Plusieurs (une par itération) |
| État entre les étapes | Sans état et isolé | Contexte persistant transporté en avant |
| Utilisation d'outils | Aucune, ou un seul appel | Appels d'outils répétés et enchaînés |
| Récupération après échec | Aucune | Observe les erreurs et replanifie |
| Tâches en plusieurs étapes | Ne peut pas décomposer | Décompose et enchaîne |
| Accomplit de vraies actions | Lit et répond uniquement | Agit (remboursements, réservations, écritures) |
| Flux de contrôle décidé par | Chemins codés en dur | Le modèle, au moment de l'exécution |
| Se termine quand | Une réponse est produite | La tâche est terminée ou condition d'arrêt |
Le détail crucial, et celui que les gens manquent, c'est que il ne s'agit pas d'un écart de capacité du modèle. Les mêmes modèles sous-jacents (Claude, GPT, Gemini) alimentent les deux. Oracle est clair : ChatGPT, Claude et Gemini « sont tous capables de raisonner sur des problèmes à plusieurs étapes. La limite est architecturale. » Une interaction de chatbot simple est sans état : chaque invite est traitée isolément, sans mémoire des résultats intermédiaires et sans moyen d'enchaîner les décisions. La boucle est ce qui retire ce plafond.
Il vaut la peine de nommer spécifiquement le RAG à tour unique, car il se situe au milieu et embrouille les gens. Un chatbot RAG récupère bel et bien des connaissances externes avant de répondre, ce qui donne une impression d'agent. Mais il ne s'exécute toujours qu'une seule fois : récupérer, puis répondre. Il ne peut pas décider qu'il a besoin d'une deuxième recherche en fonction de ce que la première a donné, ne peut pas accomplir une action avec effets de bord, et ne peut pas se rétablir si la première récupération est passée à côté. Une boucle d'agent transforme cette unique récupération en une seule action qu'elle peut répéter et enchaîner avec d'autres. Si vous vous êtes déjà demandé pourquoi un chatbot IA continue de répondre de manière incorrecte, l'absence de cette boucle en est souvent la raison : il n'a qu'une seule tentative et aucune chance de se vérifier.
Un dernier cadrage à garder à l'esprit : « agentique » est un spectre, pas un oui ou un non. Harrison Chase, de LangChain, soutient qu'un système est « d'autant plus agentique qu'un LLM décide davantage de la façon dont le système peut se comporter », allant d'un simple routeur, à une machine à états qui boucle jusqu'à l'achèvement, jusqu'à un agent pleinement autonome qui construit et réutilise ses propres outils. L'automatisation de support la plus utile vit au milieu de cet éventail, pas à l'extrémité sauvage.
La boucle a des variantes
La boucle ReAct de base gère la plupart des cas, mais quelques extensions reviennent assez souvent pour qu'on les connaisse par leur nom. Andrew Ng a regroupé les idées centrales en quatre patrons de conception agentiques : réflexion, utilisation d'outils, planification et collaboration multi-agents. En termes de boucle :
- Plan-and-execute (planifier puis exécuter). Séparer la planification de l'exécution. Un planificateur écrit la décomposition complète de la tâche à l'avance, un exécuteur la déroule, et un re-planificateur ajuste lorsque la réalité diverge. Cela réduit les appels au modèle par rapport au fait de raisonner à chaque étape ; le LLMCompiler de LangChain a rapporté une accélération de 3,6x par rapport à une exécution séquentielle de style ReAct.
- Réflexion. Un appel au modèle génère un résultat tandis qu'un autre le critique et fournit un retour, en bouclant jusqu'à ce que la sortie atteigne le niveau requis. Ng décrit cela comme le LLM qui « critique et révise son propre travail ».
- Multi-agents. Un agent principal engendre des sous-agents qui traitent des fils en parallèle. Anthropic a rapporté que son système de recherche multi-agents « a surpassé une configuration à agent unique de 90,2 % sur des évaluations de recherche internes ».
Le conseil constant de toutes les sources, et la partie la plus souvent ignorée : commencez par la boucle la plus simple qui fonctionne, et n'ajoutez de la complexité que lorsque vous pouvez mesurer qu'elle a réellement aidé.
Garde-fous : pourquoi la boucle a besoin d'un frein
Une boucle capable de s'exécuter elle-même est aussi une boucle capable de s'emballer. Les conditions d'arrêt ne sont pas optionnelles. Sans elles, un agent peut tourner indéfiniment, en « brûlant des jetons et produisant des résultats de plus en plus incohérents ».
Les freins standards :
- Itérations maximales. Un plafond strict sur les tours de boucle. OpenAI lève une exception
MaxTurnsExceededdès que vous dépassez la limite configurée, et Anthropic recommande un nombre maximal d'itérations « pour garder le contrôle ». - Budgets de jetons et de coûts. Les boucles ne sont pas bon marché. Les agents consomment environ 4 fois plus de jetons qu'un appel de chat standard, et les configurations multi-agents jusqu'à 15 fois, selon Oracle. Ce coût est la principale raison pour laquelle les équipes de production instrumentent chaque étape.
- Détection d'absence de progrès. Sortir quand des itérations répétées cessent de produire quoi que ce soit de nouveau.
- Points de contrôle avec intervention humaine. Les agents peuvent se mettre en pause pour un humain face à un blocage, ce qui compte beaucoup dans le support.
Oracle raconte ici une excellente histoire édifiante : un agent de scraping dont le site cible a discrètement changé de structure s'est mis à renvoyer des résultats vides et, avec une invite « réessaie jusqu'à obtenir des données » et sans arrêt strict, il « a appelé l'outil cassé 400 fois en cinq minutes » avant qu'une limite de débit ne le sauve. Le correctif était presque insultant de simplicité : « Une limite d'itérations maximale de trois cycles aurait empêché l'échec en totalité. » Si vous ne deviez retenir qu'une seule leçon opérationnelle de tout cet article, que ce soit celle-là.
Comment la boucle s'applique à un ticket de support
C'est là que le motif abstrait devient un produit. Anthropic désigne le support client comme « un terrain naturel pour des agents plus ouverts », car le travail nécessite à la fois de la conversation et de l'action. Un ticket de support est une boucle de manuel :
- Trier. La boucle perçoit le ticket entrant et le modèle raisonne sur l'intention : facturation, remboursement, réinitialisation de mot de passe, un bug technique. C'est l'étape classique de tri des tickets.
- Récupérer. Appeler des outils de données : recherche dans la base de connaissances, historique des commandes, consultation de comptes.
- Agir. Appeler des outils d'action avec de vrais effets de bord : émettre un remboursement, changer un abonnement, mettre à jour une adresse de livraison, réinitialiser un mot de passe, mettre à jour le ticket.
- Observer et vérifier. Vérifier si l'action a réellement fonctionné. Si une consultation est revenue vide ou qu'une API a renvoyé une erreur, la boucle replanifie, ce qui est la reprise qu'un bot en une seule passe ne peut tout simplement pas faire.
- Résoudre ou escalader. Si c'est terminé, clôturer. Si l'agent atteint une limite de confiance, le transmettre proprement à un humain.
C'est aussi pourquoi les boucles d'agent résolvent bien plus que les anciens bots. Selon le rapport de benchmark 2026 de Notch, les chatbots hérités ne résolvent que 10 à 25 % des problèmes (ils ont été conçus pour router, pas pour résoudre), tandis que les plateformes agentiques qui « se connectent directement aux systèmes CRM, de facturation et de réclamations et exécutent » atteignent 70 à 85 % de résolution de bout en bout.
Un avertissement issu du même rapport, à emporter dans toute conversation avec un fournisseur : la résolution n'est pas la même chose que le déflectage ou le confinement. Le déflectage signifie seulement que l'IA a produit une réponse et que le client est parti ; le problème de fond peut rester non résolu. Le confinement (pas d'escalade) est, selon les mots de Notch, « sans doute le plus trompeur ». La question honnête à poser à un fournisseur est « non pas quel est son taux de résolution, mais ce qu'il compte comme résolu ». C'est le genre de nuance qu'une vraie boucle avec de vraies actions peut réellement étayer, et qu'un bot de simple déflectage ne peut pas. Si vous choisissez un outil, nos panoramas des meilleures IA pour l'automatisation des tickets et de la meilleure IA de service client approfondissent quelles plateformes résolvent réellement plutôt que de déflecter.
Voici à quoi ressemble une boucle d'agent en action en direct au sein d'un vrai helpdesk, accomplissant des actions sur les tickets plutôt que de simplement les suggérer :
Le transfert fondé sur la confiance est la sortie propre de la boucle
Le contrôle le plus demandé que nous entendons de la part des équipes de support n'est pas « faites en sorte que l'IA réponde à tout ». C'est l'inverse : laissez l'IA traiter uniquement ce sur quoi elle est confiante, et laissez le reste tranquille. Une responsable CX d'une marque de compléments alimentaires en vente directe traitant environ 7 000 tickets par mois l'a parfaitement résumé :
« L'IA ne pourra jamais répondre à 100 % des questions… J'ai besoin d'une IA qui ne traite que les tickets qu'elle est confiante de traiter et qui laisse tous les autres tranquilles. »
C'est la condition d'arrêt appliquée au support. Un seuil de confiance décide si la boucle résout ou transfère, et un transfert propre à un humain prend en charge le reste. C'est aussi pourquoi le taux d'escalade et le taux de recontact à 48-72 heures sont les indicateurs qui méritent d'être surveillés, plus qu'un chiffre de résolution à effet d'annonce : ils vous disent si la boucle résout réellement des problèmes ou se contente de clôturer des tickets.
Ce que les praticiens disent vraiment de la boucle
La communauté des développeurs a des opinions fortes, drôles et légèrement contradictoires sur les boucles d'agent, ce qui est le meilleur signe que l'idée est réelle.
Sur la simplicité, cet avis largement partagé est représentatif :
« C'est vraiment stupéfiant de voir à quel point une boucle avec un LLM capable d'appeler des outils fonctionne bien désormais pour toutes sortes de tâches. »
libraryofbabel, sur Hacker News
Sur le danger de laisser la boucle tourner sans contrainte, le fondateur de Docker, Solomon Hykes, a la phrase que tout le monde cite :
« Un agent IA, c'est un LLM qui saccage son environnement en boucle. »
Les deux sont vraies à la fois, et cette tension est le véritable problème d'ingénierie. La boucle est d'une capacité saisissante et véritablement risquée, ce qui est précisément pourquoi la section sur les garde-fous ci-dessus n'est pas du remplissage optionnel. Simon Willison va jusqu'à soutenir que « concevoir des boucles agentiques » devient une discipline à part entière : l'art, dit-il, « consiste à concevoir soigneusement les outils et la boucle pour qu'ils les utilisent ».
Construire la sienne, ou en acheter une ?
Parce que la boucle est si simple à décrire, beaucoup d'équipes techniques arrivent à la conclusion évidente : nous allons simplement construire la nôtre sur l'API de Claude ou d'OpenAI. Et honnêtement, vous pouvez monter un prototype fonctionnel en un après-midi. La boucle while, ce sont les 20 % faciles.
Les 80 % difficiles, c'est tout ce qui l'entoure : la mémoire persistante, l'observabilité sur chaque appel d'outil, les garde-fous qui arrêtent une boucle emballée, les intégrations au helpdesk et à la base de connaissances, et la maintenance continue à mesure que les modèles et les API évoluent sous vos pieds. C'est la partie que les équipes sous-estiment. Nous avons vu de nombreux clients techniquement solides construire une démo, puis choisir d'acheter pour ne pas avoir à porter cela sur le long terme. Comme nous l'a dit un responsable ingénierie d'une entreprise de matériel de distributeurs de Bitcoin, qui a choisi d'acheter plutôt que de construire :
« Nous aurions pu essayer d'écrire notre propre application LLM, mais nous ne voulions pas y investir notre temps. Nous voulions quelque chose que nous n'aurions pas à maintenir. »
Si l'avantage de votre équipe réside dans votre produit, et non dans la maintenance d'un runtime d'agent, ce calcul penche généralement en faveur de l'achat. Nous avons creusé ce compromis plus en détail dans notre étude sur la création d'un GPT personnalisé pour le service client, et vous pouvez voir à quoi ressemblent des boucles matures sur le terrain à travers les entreprises qui utilisent déjà l'IA pour le service client.
Essayez eesel
eesel est la boucle d'agent, transformée en produit pour les équipes de support, d'IT et d'ops, sans la construction. Son agent de helpdesk IA exécute le cycle complet percevoir, raisonner, agir, observer directement au sein du helpdesk que vous utilisez déjà (Zendesk, Freshdesk, HubSpot, Gorgias, Front, Slack et plus de 100 intégrations), de sorte qu'il ne se contente pas de rédiger des réponses, il accomplit des actions sur les tickets et les résout.
L'élément différenciant qui correspond directement à tout ce qui précède, c'est son mode simulation : vous pouvez faire tourner l'agent sur des milliers de vos tickets passés pour voir exactement ce qu'il aurait résolu, thème par thème, avant qu'une seule réponse en direct ne soit envoyée. C'est la version de la boucle d'abord fondée sur les garde-fous et la confiance, celle que les équipes de support réclament réellement. Il apprend de vos tickets résolus et de vos documents d'aide dès le premier jour, fonctionne dans plus de 80 langues et facture à la résolution plutôt qu'au siège. Vous pouvez essayer eesel avec 50 $ d'utilisation gratuite, sans carte de crédit, et voir votre propre chiffre de résolution avant de vous engager.
Foire aux questions
Qu'est-ce qu'une boucle d'agent IA en termes simples ?
Quelle est la différence entre un agent IA et un chatbot ?
Une boucle d'agent IA peut-elle tourner indéfiniment, et comment l'empêche-t-on ?
Devrais-je construire ma propre boucle d'agent IA ou en acheter une ?
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
Comment la boucle d'agent IA s'applique-t-elle au support client ?