Agent IA : comprendre sa boucle et maîtriser son arrêt

Le modèle propose l’action suivante. Votre logiciel décide si elle peut être exécutée, consigne son résultat et détermine si un nouvel appel au modèle est autorisé. Cette répartition des rôles est le point de départ, aussi bien pour créer un premier agent que pour comprendre pourquoi un agent a continué à tourner.

Les comportements des frameworks présentés ici ont été vérifiés dans la documentation en ligne de leurs éditeurs le 24 octobre 2026. La comparaison précise ce que chacun compte et à quel moment ses contrôles interviennent. Les exemples de tickets de support et les règles proposées servent d’illustration ; ce ne sont pas des résultats mesurés en production.

Comment fonctionne la boucle d’un agent IA ?

La boucle suit le schéma appel au modèle → appel d’outil → observation → nouvel appel, avec une sortie dès que poursuivre devient inutile ou interdit.

Imaginez un responsable d’intervention qui coordonne un technicien. Le responsable choisit la prochaine mission, le technicien l’exécute, puis son compte rendu éclaire la décision suivante. Demander l’inspection d’une machine ne revient pas à l’inspecter ; un message rassurant ne prouve pas que la réparation a réussi.

Dans le logiciel, le responsable est un grand modèle de langage, ou LLM. Le technicien est un outil : une fonction qui lit une base de données, cherche dans des documents, exécute une commande ou modifie un enregistrement. Le moteur d’exécution est le code qui fait le lien entre les deux.

Pour une tâche fictive de rédaction d’une réponse à un ticket, la trace pourrait être la suivante : le premier appel au modèle demande le ticket ; le deuxième demande la procédure applicable ; le troisième renvoie un brouillon fondé sur ces deux sources. Cela représente 3 appels au modèle et 2 exécutions d’outils, au sein d’une seule requête à l’application. Si l’envoi de la réponse exige une approbation, la rédaction peut être terminée alors que l’envoi reste en attente.

Séparez l’état de la tâche de l’historique de conversation. L’état doit indiquer quel ticket est traité, quelle procédure a été retenue, si un brouillon existe et si son envoi est autorisé. L’historique explique comment vous en êtes arrivé là. Demander au modèle de reconstituer sans cesse ces informations à partir d’une conversation qui s’allonge complique la supervision.

Ce qu’apporte un agent qui fonctionne en boucle

Un agent fonctionnant en boucle peut choisir son action suivante à partir du dernier résultat. Dans un workflow fixe, l’enchaînement est déjà connu : récupérer le ticket, récupérer la procédure, produire le brouillon. Utilisez une boucle adaptative lorsque la prochaine action utile dépend de ce que la précédente a révélé. Si cette incertitude n’existe pas, préférez une séquence fixe.

Quelle place pour la boucle ReAct ?

La boucle d’agent ReAct relie raisonnement et action : le modèle s’appuie sur ses observations pour orienter les actions suivantes. Le projet ReAct d’origine décrit cette alternance entre raisonnement et actions dans un environnement. Pour superviser l’application, consignez les actions demandées, les observations et les résultats obtenus. Un texte décrivant l’avancement ne remplace pas une confirmation d’exécution.

Les trois conditions d’arrêt indispensables en production

Prévoyez trois sorties explicites : tâche terminée, limites épuisées et intervention humaine nécessaire. Ce sont des catégories de conception, pas l’affirmation que tous les SDK proposent les trois mêmes réglages. Les plantages, les annulations et les erreurs irrécupérables nécessitent eux aussi une gestion explicite des échecs.

Arrêter quand la tâche est terminée

Définissez ce que signifie « terminé » avant le premier appel au modèle. Pour un assistant de rédaction, cela peut être un brouillon valide accompagné des références pertinentes. Pour un assistant qui effectue des actions, une confirmation d’écriture peut également être nécessaire.

Distinguez « le modèle ne demande plus d’outils » de « le travail demandé a réussi ». Le premier est un signal d’exécution. Le second exige des preuves propres à la tâche. Un modèle peut s’arrêter parce qu’il ne peut plus avancer ; votre application doit alors enregistrer un état bloqué ou incomplet, au lieu de présenter le travail comme réussi.

Ne relancez pas automatiquement la boucle dès qu’une réponse échoue à la validation. Une tentative de correction doit être décomptée des mêmes limites que le reste de la tâche, faute de quoi le validateur peut devenir une nouvelle source de tentatives sans fin.

Arrêter dès qu’une limite est atteinte

Fixez des limites indépendantes pour le nombre d’étapes, les ressources consommées et le temps écoulé. Un plafond d’étapes borne les répétitions. Un budget de tokens ou de dépenses borne la consommation. Une échéance empêche un modèle ou un outil lent de maintenir la tâche ouverte indéfiniment. Aucune de ces limites ne remplace les autres.

Vérifiez les limites avant d’autoriser une nouvelle opération, puis actualisez la consommation une fois celle-ci terminée. Un compteur d’appels terminés ne peut pas empêcher une requête déjà en cours de consommer des ressources. Si l’application promet un plafond strict, réservez la capacité nécessaire à l’opération suivante et tenez compte des travaux simultanés avant de la lancer.

Appliquez les limites à l’ensemble de la tâche métier, et pas seulement à une invocation du SDK. Une nouvelle tentative, une reprise après approbation ou un agent enfant ne doit pas réinitialiser le budget en silence. Si du travail supplémentaire est justifié, augmentez le budget par une décision explicite de l’application.

Human in the loop : mettre l’agent en pause avant l’action

Un agent IA soumis à une validation humaine doit se mettre en pause avant l’opération qui nécessite une approbation. Présentez l’action proposée, sa cible et les arguments pertinents. Sauvegardez l’appel en attente et l’état actuel de la tâche, puis attendez une décision explicite.

Pour l’assistant de support, faites approuver la réponse précise à envoyer au destinataire précis. L’approbation d’un brouillon ne doit pas devenir une autorisation générale pour les messages ultérieurs. Si le modèle modifie le destinataire ou le contenu après l’approbation, réévaluez cette action.

Enregistrez une pause sous l’état awaiting_approval, et non completed. Un refus doit conduire à une solution de remplacement définie ou à un arrêt. Il ne doit pas déclencher des tentatives répétées pour faire passer la même opération par un autre outil. Le guide de la validation humaine détaille les files d’approbation et les procédures d’escalade.

Une boucle d’agent minimale en pseudocode

La boucle reste courte lorsque les contrôles encadrent chaque opération. Il s’agit de pseudocode, pas de code SDK exécutable. Le plafond de 8 appels au modèle est un choix d’application donné à titre d’exemple ; fixez vos propres limites à partir de la tâche et des traces observées.

state = new_job(task, max_model_calls=8, budget, deadline)

while true:
    if limit_reached(state):
        return stop("limit", partial_result=state)

    reserve_capacity_or_stop(state, next_model_call)
    response = call_model_with_deadline(state)
    record_model_call_usage_and_response(state, response)

    if response.is_final and not response.tool_calls:
        return validate_and_finish_or_stop_incomplete(response, state)

    if not response.tool_calls:
        return stop("no_action", partial_result=state)

    for index, call in enumerate(response.tool_calls):
        decision = validate_and_authorize(call, state)
        if decision == "denied":
            return stop("denied", partial_result=state)
        if decision == "needs_human":
            return pause_and_save(state, response.tool_calls[index:])

        reserve_capacity_or_stop(state, call)
        observation = execute_with_timeout_and_retry_cap(call)
        record_tool_usage(state, observation)
        append_matching_tool_result(state, call, bounded(observation))

    if no_progress(state):
        return stop("stalled", partial_result=state)

Ces fonctions auxiliaires doivent respecter des exigences importantes, que leurs noms ne font qu’évoquer. Les réservations doivent tenir compte des opérations déjà en cours. Les nouvelles tentatives d’appel d’outils doivent être limitées. Après l’expiration d’un délai, si le résultat d’une écriture est inconnu, il faut s’arrêter ou vérifier ce qui s’est réellement passé avant de réessayer. Une erreur fatale du modèle ou d’un outil doit terminer l’exécution avec un échec consigné, sans laisser démarrer une nouvelle itération.

La sauvegarde d’une pause doit inclure les appels d’outils restants, les résultats déjà obtenus et la part du budget consommée. À la reprise, poursuivez ce travail sauvegardé en revérifiant ses autorisations et ses limites. Recommencer toute la tâche peut reproduire des effets déjà survenus.

Observez l’emplacement des contrôles : l’approbation précède l’exécution de l’outil, la consommation est comptabilisée après le travail terminé et une nouvelle itération ne peut pas commencer au seul motif que le modèle l’a demandée.

Comment les frameworks pilotent-ils la boucle ?

OpenAI Agents SDK, Claude Agent SDK, Vercel AI SDK et LangGraph organisent la boucle différemment. Comparez leurs unités de comptage et les points où l’arrêt intervient avant de comparer les noms des options.

Ces noms proviennent des documentations respectives de la boucle OpenAI, de la boucle Claude, de la boucle Vercel et de la Graph API de LangGraph. Les liens sur le fonctionnement des approbations figurent dans les sections ci-dessous.

OpenAI Agents SDK : le Runner décide de poursuivre

OpenAI Agents SDK est un framework dont le Runner appelle le modèle, exécute les outils demandés, ajoute leurs résultats et poursuit l’exécution. Un transfert change l’agent actif et continue l’exécution. La fin normale documentée correspond à une sortie du type attendu, sans appel d’outil ; dépasser max_turns lève l’exception MaxTurnsExceeded, sauf prise en charge de ce cas. Documentation OpenAI sur l’exécution des agents.

Pour un assistant de support, c’est un point de contrôle simple pour limiter les appels au modèle. Sa limite tient à la différence entre une exécution terminée et une action métier accomplie : configurez le contrat de sortie et vérifiez les preuves exigées par votre tâche.

Pour les approbations, les outils Python peuvent déclarer needs_approval ; les appels en attente apparaissent dans interruptions. Sauvegardez le RunState, appliquez l’approbation ou le refus, puis reprenez. Une exécution en pause ne constitue pas une nouvelle demande de l’utilisateur. Documentation OpenAI sur la validation humaine.

Boucle Claude : limiter à la fois les tours et les dépenses

Claude Agent SDK intègre la boucle qui fait fonctionner Claude Code, avec ses outils de fichiers et de commandes. L’option maxTurns compte les tours avec utilisation d’outils ; maxBudgetUsd fixe un seuil de dépenses estimées. Si elles ne sont pas définies, aucun de ces deux plafonds ne s’applique. En Python, les options s’appellent max_turns et max_budget_usd. Documentation de la boucle d’agent Claude.

Examinez le sous-type du résultat : success, error_max_turns et error_max_budget_usd correspondent à des issues différentes. En mode à requête unique, un résultat d’erreur est suivi d’une exception ; prenez donc en charge le résultat comme le traitement de l’exception. Gestion des résultats avec Claude.

Les autorisations demandent autant d’attention. allowedTools approuve automatiquement les outils de la liste ; l’absence d’un outil dans cette liste ne le supprime pas. Dans le mode d’autorisation par défaut, les appels qui exigent une approbation et ne correspondent à aucune règle d’autorisation sont transmis à canUseTool. Vérifiez l’ensemble de la politique d’autorisation avant d’utiliser ce SDK pour des écritures sans supervision. Autorisations de Claude.

Pour comptabiliser aussi les agents enfants, Claude distingue usage, qui couvre la boucle principale, de modelUsage, ou model_usage en Python, qui couvre tout l’arbre d’agents. Utilisez le total approprié pour analyser la consommation d’une tâche. Documentation Claude sur les coûts et la consommation.

Pour passer à l’implémentation, commencez par le guide Claude Agent SDK du site.

Vercel AI SDK : stopWhen contrôle l’étape suivante

Vercel AI SDK pilote la poursuite de l’exécution avec stopWhen. Sa documentation actuelle utilise isStepCount pour limiter le nombre d’étapes et autorise plusieurs conditions : il suffit que l’une d’elles soit remplie pour arrêter. Par défaut, ToolLoopAgent est limité à 20 étapes, tandis que generateText et streamText se limitent à une génération. Le point d’entrée choisi compte donc. Contrôle de la boucle Vercel, documentation des appels d’outils.

Une étape comprend une génération et les exécutions locales d’outils associées. Point essentiel : stopWhen est évalué lorsque la dernière étape contient des résultats d’outils. Il ne peut pas annuler le travail des outils qui a produit ces résultats. C’est donc un contrôle de poursuite de l’exécution, pas une approbation préalable à l’action. Appels en plusieurs étapes avec Vercel.

Pour demander l’approbation explicite de l’utilisateur, utilisez le mécanisme documenté toolApproval. La documentation actuelle indique que l’ancienne propriété d’outil needsApproval est obsolète. Approbation des outils avec Vercel.

Pour gérer le contexte, prepareStep s’exécute avant chaque étape et peut modifier les messages ou les réglages. Profitez de ce point de contrôle pour fournir l’état pertinent, au lieu de retransmettre tous les résultats bruts à chaque appel. Vercel prepareStep.

LangGraph et la boucle d’agent LangChain

LangGraph est un moteur d’exécution de graphes : vous reliez des nœuds, qui effectuent le travail, par des arêtes, qui déterminent la suite. Pour une boucle d’agent LangChain construite sur un graphe, définissez explicitement le chemin de retour au modèle et celui qui mène à END. En Python, recursion_limit limite les super-étapes du graphe ; les nœuds exécutés en parallèle partagent une même super-étape. Ce n’est pas un compteur d’appels d’outils. Graph API de LangGraph.

Placez recursion_limit au premier niveau de la configuration d’invocation, et non dans configurable. Atteindre cette limite lève GraphRecursionError ; un chemin de fin prévu dans le graphe devrait normalement terminer le travail avant cette sortie de secours. Limite de récursion de LangGraph.

Pour une validation humaine, interrupt() met le graphe en pause. Utilisez un mécanisme de sauvegarde des points de contrôle et un thread_id stable, puis reprenez avec Command(resume=...). Attention à une limite importante : la reprise redémarre le nœud interrompu depuis le début. Le code qui précède l’interruption peut donc s’exécuter à nouveau. Placez les opérations produisant des effets après l’approbation, ou rendez-les idempotentes : les répéter ne doit produire aucun effet supplémentaire. Interruptions de LangGraph.

Choisissez cette structure de graphe explicite lorsque les embranchements et la reprise à partir d’un état sauvegardé sont au cœur de la tâche. Pour un premier assistant en lecture seule doté d’un cycle d’outils simple, commencez par le moteur d’exécution le plus léger qui répond à vos besoins.

Pourquoi une exécution atteint-elle 40 étapes ?

Avant de relever le plafond, cherchez ce qui a changé d’une étape à l’autre. Une exécution longue peut correspondre à du travail utile, à des échecs répétés ou à un redémarrage qui a perdu la trace de ce qui était déjà fait. Le nombre d’étapes ne permet pas, à lui seul, de les distinguer.

Boucles sans fin : répéter sans rien apprendre

Un agent de support peut rechercher une procédure, obtenir un résultat vide et relancer la même recherche. L’observation suivante n’apporte rien ; la décision suivante peut donc reproduire exactement la même action.

Consignez le nom de l’outil et ses arguments sous une forme normalisée, une empreinte du résultat et un indicateur d’avancement de la tâche. Une répétition sans changement d’état doit déclencher un contrôle de blocage. Une interrogation périodique légitime peut elle aussi se répéter : définissez-lui des règles et des limites propres, au lieu de traiter chaque doublon comme une erreur.

Changez quelque chose avant de réessayer : un terme de recherche, un identifiant manquant, une source de données disponible ou le périmètre de la tâche. Si rien ne peut être modifié utilement, indiquez ce qui reste à résoudre ou demandez de l’aide. « Réessayer » ne constitue pas, à lui seul, une stratégie de reprise.

Erreurs d’outils : distinguer l’échec récupérable du résultat inconnu

Un argument mal formé, une autorisation refusée et une panne temporaire du service appellent des réponses différentes. Renvoyez une erreur concise que le modèle peut exploiter. Limitez les nouvelles tentatives pour les erreurs récupérables et arrêtez immédiatement face aux erreurs impossibles à corriger avec les autorisations de la tâche.

L’expiration d’un délai pendant une écriture est plus délicate : l’écriture peut avoir réussi même si la réponse n’est jamais arrivée. Avant de renvoyer un message au client ou de créer un autre enregistrement, vérifiez le statut de l’opération ou utilisez une clé d’idempotence, un identifiant stable qui permet au service de reconnaître qu’il s’agit de la même opération.

Conservez le travail déjà réussi pendant la reprise. Si la lecture du ticket a abouti mais que la récupération de la procédure a échoué, relancer toute la tâche ajoute du travail et risque de reproduire des effets déjà survenus.

Contexte qui grossit : conserver les décisions, pas tous les résultats bruts

À l’appel suivant, chaque observation se dispute l’attention du modèle avec les instructions de la tâche et les éléments déjà recueillis. Une réponse d’outil volumineuse peut être techniquement valide tout en rendant la prochaine décision moins ciblée.

Bornez la taille des sorties d’outils, stockez les fichiers volumineux hors du prompt et renvoyez un résultat compact avec une référence permettant de les récupérer. Conservez les contraintes retenues, les approbations et les actions confirmées dans un état applicatif persistant. Un résumé peut décrire ces enregistrements ; il ne doit pas en devenir l’unique copie.

Le SDK de Claude documente une compression automatique à l’approche de la limite de contexte et avertit que les premières instructions peuvent disparaître du résumé. C’est une raison de sauvegarder explicitement les éléments d’état critiques. Compression du contexte avec Claude. Le décryptage du context rot explique pourquoi tenir dans une fenêtre de contexte ne garantit pas que les informations seront rappelées utilement.

Des traces qui répondent aux questions de l’équipe d’exploitation

Pour chaque tâche, consignez son identifiant, le nombre d’appels au modèle, les tentatives d’appel d’outils, la consommation, le temps écoulé, les approbations en attente et le motif d’arrêt. Pour chaque opération, indiquez ce qui a été demandé, ce qui a été réalisé et si l’état de la tâche a changé.

Gardez des compteurs distincts pour les requêtes au modèle, les exécutions d’outils et les étapes du moteur d’exécution. Un tableau de bord qui affiche « 40 étapes » sans préciser l’unité n’explique pas l’exécution. Incluez le travail des agents enfants et les nouvelles tentatives dans la comptabilité de la tâche parente. Le guide de l’orchestration des agents IA explique la répartition des responsabilités lorsque le travail passe d’un agent à l’autre.

Quelles promesses autour des boucles d’agents sont exagérées ?

Davantage d’itérations ne prouve pas que le travail avance davantage. Une boucle multiplie les occasions d’exploiter un retour d’information ; ce sont la qualité de ce retour et la définition de la réussite qui déterminent si la répétition est utile.

Un modèle qui dit « terminé » a achevé sa part de l’échange. Un plafond d’étapes prouve que l’exécution était bornée. Ni l’un ni l’autre ne prouve qu’une réponse de support est correcte ou qu’une modification demandée a bien eu lieu.

L’utilisation d’un framework ne dispense pas non plus de définir les autorisations, la persistance et la reprise après erreur. Le framework fournit les mécanismes d’exécution. Votre application définit ce que signifie réussir et qui a le droit d’agir.

La boucle de test de l’agent remplit une autre fonction

Une boucle de test évalue le comportement de l’agent à partir de cas et de critères d’acceptation. Elle peut entourer la boucle d’exécution d’un vérificateur qui accepte le résultat ou renvoie des remarques pour une nouvelle tentative. L’explication de LangChain sur la conception des boucles distingue l’exécution, la vérification et le travail déclenché par des événements.

Bornez aussi le vérificateur. Demander sans cesse à un autre modèle si une réponse est bonne peut épuiser le budget sans fournir de preuve décisive. Privilégiez des contrôles concrets lorsque c’est possible : les champs requis sont présents, les enregistrements cités correspondent, une confirmation d’écriture existe ou un test attendu réussit.

Par quoi commencer pour construire ou exploiter un agent ?

Vous développez votre premier agent : commencez par une tâche ciblée en lecture seule, un contrat de fin explicite et des opérations bornées. Ajoutez les écritures lorsque vous pouvez présenter l’action proposée, faire respecter les autorisations et gérer la reprise après un résultat ambigu. Si la séquence est déjà connue, un workflow fixe peut suffire.

Vous analysez une exécution coûteuse : examinez les appels répétés, les chaînes de nouvelles tentatives et les observations qui grossissent avant de changer de modèle ou de relever les limites. Déterminez quelle étape a apporté une information utile et quel compteur a réellement arrêté la tâche.

Votre équipe dispose d’un workflow fixe fiable : conservez-le jusqu’à ce que la sélection adaptative des outils résolve un problème concret. Une boucle apporte de la valeur lorsque les résultats intermédiaires déterminent l’action suivante ; la répétition seule ne justifie pas de tout reconstruire.

Dès lundi, prenez une tâche représentative et testez sa fin normale, son arrêt sur limite, sa pause pour approbation, son traitement d’une action refusée et sa gestion d’un échec d’outil. Vérifiez que chaque cas laisse un statut clair et que la reprise préserve à la fois le travail accompli et le budget restant.

Questions fréquentes sur les boucles d’agents IA

Pour recevoir des guides pratiques sur la création et l’exploitation de systèmes d’IA, abonnez-vous à la newsletter.