Design patterns d'agents : tool loop, ReAct, planning, reflection, routing

Demandez à cinq ingénieurs de construire « un agent qui répond aux questions de remboursement des clients », vous obtiendrez cinq designs différents. L'un branche le modèle sur une base de données et le laisse boucler. Un autre le fait réfléchir à voix haute avant chaque action. Un autre lui fait d'abord écrire un plan. Un autre lui fait critiquer son propre brouillon. Un autre envoie les questions faciles à un modèle pas cher et les difficiles à un expert. Même tâche, cinq architectures, et seules certaines fonctionnent vraiment de façon fiable.

Un agent n'est qu'un modèle de langage capable d'agir sur le monde (appeler des tools, chercher, exécuter du code) et de décider quoi faire ensuite en fonction des résultats. Le design pattern que vous choisissez fait la différence entre un agent qui fait son travail sans bruit et un agent qui boucle à l'infini, hallucine ou brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûle de l'argent.

Passons en revue les cinq patterns de base, chacun avec une tâche concrète.

Pattern 1 : la tool-use loop

C'est la fondation sur laquelle tout le reste se construit. Un tool est n'importe quelle fonction que le modèle peut appeler : chercher sur le web, retrouver une commande, envoyer un e-mail, interroger une base de données.

La boucle est simple :

1. Donnez au modèle un objectif et une liste de tools.
2. Le modèle répond directement ou demande à appeler un tool.
3. Vous exécutez le tool et renvoyez le résultat.
4. Répétez jusqu'à ce que le modèle donne une réponse finale.

Tâche concrète : « Quel est le statut de la commande #4471 ? » Le modèle appelle get_order(4471), voit shipped, et répond. Un appel de tool, terminé.

Voici la boucle en pseudocode indépendant du fournisseur. Le SDK de chaque fournisseur emballe exactement cette même forme.

messages = [{"role": "user", "content": "Status of order #4471?"}]

while True:
    response = model.generate(messages, tools=[get_order, cancel_order])

    if response.tool_calls:
        for call in response.tool_calls:
            result = run_tool(call.name, call.args)   # c'est vous qui l'exécutez
            messages.append({"role": "tool", "content": result})
    else:
        print(response.text)   # réponse finale, on sort de la boucle
        break

La tool-use loop suffit pour un très grand nombre de tâches réelles. Ne passez aux patterns plus sophistiqués que quand celui-ci commence à échouer.

Pattern 2 : ReAct (raisonner, puis agir)

ReAct signifie « Reasoning and Acting ». Le modèle écrit une courte pensée avant chaque action, puis agit, puis lit le résultat, puis réfléchit à nouveau. Il entrelace la réflexion et l'action.

Tâche concrète : « Lequel de nos trois entrepôts peut livrer un bureau assis-debout à Denver le plus vite ? »

Une simple tool loop pourrait prendre un entrepôt et s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter là. ReAct raisonne :

Pensée : j'ai besoin du stock et du délai de livraison des trois entrepôts. Action : check_stock("desk", "Salt Lake") → en stock, 2 jours Pensée : bien, mais Phoenix est peut-être plus proche. Vérifions. Action : check_stock("desk", "Phoenix") → en stock, 1 jour Pensée : Phoenix est plus rapide. Vérifions Dallas pour en être sûr. Action : check_stock("desk", "Dallas") → hors stock Pensée : Phoenix gagne. Répondre à l'utilisateur.

Le raisonnement visible garde le modèle honnête et facilite le débogage : quand ça dérape, vous voyez exactement quelle pensée l'a fait dévier. ReAct est le pattern de base pour les tâches qui nécessitent plusieurs recherches dépendantes.

L'article d'origine est un classique clair et lisible : ReAct: Synergizing Reasoning and Acting in Language Models.

Pattern 3 : planning (écrire les étapes d'abord)

Parfois vous voulez que l'agent réfléchisse à la tâche *entière* avant de toucher à quoi que ce soit. Un planner produit d'emblée une liste ordonnée d'étapes, puis les exécute une par une.

Tâche concrète : « Préparer un brief concurrentiel sur trois produits rivaux. »

ReAct pourrait partir dans tous les sens. Un planner s'engage d'abord :

Plan : 1. Identifier les trois principaux concurrents. 2. Récupérer les prix de chacun. 3. Récupérer les principales fonctionnalités de chacun. 4. Trouver les plaintes clients récentes pour chacun. 5. Rédiger une comparaison d'une page.

Ensuite il déroule la liste. L'avantage : sur des tâches longues et multi-étapes, l'agent ne perd pas le fil à mi-parcours. Vous pouvez aussi montrer le plan à un humain pour validation avant toute exécution, ce qui compte quand les étapes coûtent de l'argent ou envoient des e-mails.

Une amélioration courante est le plan-and-execute avec re-planning : exécuter quelques étapes, vérifier si la réalité correspond au plan, et réécrire les étapes restantes si ce n'est pas le cas. Le travail réel est désordonné, et les plans rigides cassent.

Règle empirique : les tâches courtes et exploratoires favorisent ReAct. Les tâches longues avec de nombreuses sous-étapes connues favorisent un planner.

Pattern 4 : reflection (critiquer son propre brouillon)

Les modèles produisent un meilleur travail quand ils le relisent. Une reflection loop fait générer un brouillon à l'agent, puis le fait changer de rôle pour critiquer ce brouillon, puis le réviser.

Tâche concrète : « Écrire une requête SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète → pour trouver les clients qui ont churné le trimestre dernier. »

1. Brouillon : l'agent écrit la requête.
2. Reflection : « Est-ce que ça gère les clients sans commande ? Est-ce que “le trimestre dernier” utilise les bonnes dates ? Des jointures qui pourraient dupliquer des lignes ? »
3. Révision : il corrige les problèmes qu'il vient de trouver.

Vous pouvez même exécuter le brouillon et réinjecter le message d'erreur *réel*, ce qui transforme la reflection en une boucle d'autocorrection serrée. Ce pattern brille pour le code, l'écriture structurée et tout ce qui a une notion claire de « correct ».

Une reflection loop minimale :

draft = model.generate("Write a SQL query for churned customers last quarter.")

for _ in range(2):   # plafonner les itérations
    critique = model.generate(f"Find bugs or gaps in this query:\n{draft}")
    if "no issues" in critique.lower():
        break
    draft = model.generate(f"Fix these issues:\n{critique}\n\nQuery:\n{draft}")

Une mise en garde : plafonnez toujours la boucle. Sans limite, la reflection peut tourner en rond en « améliorant » indéfiniment et faire grimper la facture.

Pattern 5 : routing (répartir vers des spécialistes)

Un router regarde une requête entrante et l'envoie au bon handler : un modèle précis, un jeu de tools précis, ou un sous-agent précis. Voyez-le comme un réceptionniste intelligent.

Tâche concrète : une boîte de support qui reçoit trois types de messages.

• Questions de facturation → vers l'agent facturation (dispose des tools de remboursement).
• Bugs techniques → vers l'agent de dépannage (peut lire les logs).
• Questions « Comment faire pour… ? » → vers un modèle rapide et pas cher, avec la documentation.

Le routing fait deux choses bien. Il garde chaque spécialiste simple, parce qu'un agent facturation qui ne traite que la facturation est plus facile à bien faire qu'un agent unique qui essaie de tout faire. Et il fait économiser : les questions faciles vont à un petit modèle pas cher, le modèle coûteux est réservé aux questions difficiles.

Un router n'est souvent qu'un seul appel de modèle qui renvoie une catégorie :

route = model.generate(
    f"Classify this message as one of: billing, technical, howto.\n\n{message}"
)

handler = {"billing": billing_agent,
           "technical": tech_agent,
           "howto": docs_agent}[route.strip()]

handler.run(message)

Le routing est la façon dont la plupart des agents sérieux en production sont construits en 2026 : pas un cerveau géant, mais un dispatcher devant plusieurs spécialistes ciblés.

Combiner les patterns

Ce ne sont pas des camps rivaux. Les vrais systèmes les empilent.

Un agent de support en production pourrait : router un message vers le spécialiste facturation, qui exécute une boucle ReAct sur ses tools de remboursement, et s'il rédige un e-mail client, lancer une passe de reflection avant l'envoi. Un agent de recherche pourrait planifier le rapport, puis utiliser une tool loop pour chaque section.

Commencez par le pattern le plus simple qui pourrait marcher (généralement la tool loop nue) et n'ajoutez de la complexité que lorsque vous constatez un échec précis. Sur-concevoir un agent est un risque aussi réel que le sous-concevoir.

Chaque grand fournisseur livre un SDK qui vous donne ces patterns comme briques de base : l'OpenAI Agents SDK, le Claude Agent SDK et l'Agent Development Kit (ADK) de Google. Les patterns présentés ici se transposent à tous ; les blocs d'approfondissement par fournisseur couvrent la syntaxe spécifique à chaque outil. Pour une cartographie large et indépendante du fournisseur, Building Effective Agents d'Anthropic est une excellente lecture gratuite.

Points clés

• Commencez par la tool-use loop. Donnez des tools au modèle, exécutez-les, renvoyez les résultats, répétez. La plupart des tâches n'ont besoin de rien de plus.
• Faites correspondre le pattern à la tâche. ReAct pour les recherches exploratoires et dépendantes ; un planner pour les tâches longues multi-étapes ; la reflection pour tout ce qui a une réponse « correcte » ; le routing quand les requêtes tombent dans des catégories claires.
• Plafonnez toujours vos boucles. La reflection et ReAct peuvent tourner à l'infini. Fixez un nombre maximal d'itérations et un budget.
• Routez pour économiser et rester simple. Envoyez les requêtes faciles à un modèle pas cher et les difficiles à un expert. De petits spécialistes ciblés battent un agent géant qui fait tout.
• Empilez les patterns, mais méritez la complexité. N'ajoutez un planner ou une étape de reflection qu'après avoir constaté un échec réel, pas avant.