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

# 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 », et 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 bon marché et les difficiles à un expert. Même tâche, cinq architectures, et seules certaines fonctionnent vraiment de façon fiable.

Un agent est simplement 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 principaux, chacun avec une tâche concrète.

Pattern 1 : la boucle d'utilisation de tools

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 email, 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 l'appel d'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 de tout fournisseur. Le SDK de chaque fournisseur enveloppe exactement cette 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 boucle d'utilisation de tools suffit pour un très grand nombre de tâches réelles. Ne passez aux patterns plus sophistiqués que lorsque celui-ci commence à échouer.

Pattern 2 : ReAct (raisonner, puis agir)

ReAct signifie « Reasoning and Acting ». Le modèle écrit une 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 →ève 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 expédier un bureau assis-debout à Denver le plus vite ? »

Une simple boucle de tools pourrait interroger 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 d'expédition 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 ê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 debug : quand il se trompe, vous voyez exactement quelle pensée l'a égaré. ReAct est le pattern de référence pour les tâches qui demandent plusieurs recherches dépendantes.

L'article original 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 risque de 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 réclamations clients récentes pour chacun.

> 5. Rédiger une comparaison d'une page.

Ensuite il déroule la liste. L'avantage : sur les 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 emails.

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 sinon. 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 boucle de reflection fait générer un brouillon à l'agent, puis le fait changer de rôle pour critiquer ce brouillon, puis 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 cela gère les clients sans commande ? Est-ce que "le trimestre dernier" utilise les bonnes dates ? Y a-t-il des jointures susceptibles de 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 boucle d'auto-correction serrée. Ce pattern brille pour le code, l'écriture structurée, et tout ce qui a une notion claire de « correct ».

Une boucle de reflection minimale :

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

for _ in range(2):   # limiter le nombre d'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 : limitez toujours la boucle. Sans plafond, la reflection peut tourner en rond en « améliorant » indéfiniment et faire gonfler votre facture.

Pattern 5 : routing (aiguiller vers des spécialistes)

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

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

• Questions de facturation → aiguiller vers l'agent facturation (il a les tools de remboursement).
• Bugs techniques → aiguiller vers l'agent de diagnostic (il peut lire les logs).
• Questions « Comment faire... ? » → aiguiller vers un modèle rapide et bon marché 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 à mettre au point qu'un agent unique qui essaie de tout faire. Et il fait économiser : envoyez les questions faciles à un petit modèle bon marché et réservez le modèle coûteux 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)

C'est ainsi que 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 équipes rivales. Les systèmes réels 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 email client, lancer une passe de reflection avant l'envoi. Un agent de recherche pourrait planifier le rapport, puis utiliser une boucle de tools pour chaque section.

Commencez par le pattern le plus simple qui pourrait fonctionner (généralement la simple boucle de tools) 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 des fournisseurs, Building Effective Agents d'Anthropic est une excellente lecture gratuite.

Points clés

• Commencez par la boucle d'utilisation de tools. Donnez des tools au modèle, exécutez-les, renvoyez les résultats, répétez. La plupart des tâches ne demandent rien de plus.
• Adaptez le pattern à la tâche. ReAct pour les recherches exploratoires et dépendantes ; un planner pour les tâches longues et multi-étapes ; la reflection pour tout ce qui a une réponse « correcte » ; le routing quand les requêtes se rangent dans des catégories claires.
• Limitez toujours vos boucles. La reflection et ReAct peuvent tourner indéfiniment. Fixez un nombre maximal d'itérations et un budget.
• Utilisez le routing pour économiser et rester simple. Envoyez les requêtes faciles à un modèle bon marché 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.