Les patterns agentiques d'Anthropic, expliqués en français#

Six façons d'organiser plusieurs appels à un modèle. Choisis la plus simple qui résout ton problème, pas la plus impressionnante.

Temps de lecture : 16 min | Niveau : Avancé

Ce que tu sauras faire après#

• Distinguer un workflow d'un agent, et savoir lequel te faut.
• Reconnaître les six patterns et le problème que chacun résout.
• Choisir un pattern à partir de ton symptôme, en 30 secondes.
• Appliquer chaque pattern à un cas data concret.
• Savoir quand ne PAS construire de système agentique.

1. La règle avant les patterns#

L'article Building effective agents d'Anthropic commence par un conseil qu'il faut lire deux fois :

"We recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all."

Et plus loin :

"Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense."

"For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough."

Traduction pour ton quotidien : avant de construire une orchestration à cinq étages, vérifie qu'un seul bon prompt avec les bons documents ne suffit pas. Neuf fois sur dix, il suffit.

2. Workflow ou agent ?#

La distinction posée par l'article :

"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage."

En clair :

Les cinq premiers patterns ci-dessous sont des workflows. Le sixième est un agent.

Dans ton métier, la majorité des besoins réels sont des workflows. Un agent autonome est justifié quand tu ne peux pas écrire le chemin à l'avance : par exemple "trouve pourquoi ce pipeline échoue une fois sur cinq depuis trois semaines".

3. La brique de base : le LLM augmenté#

Avant les patterns, la brique commune. L'article l'appelle augmented LLM : un modèle enrichi de recherche, d'outils et de mémoire. Il peut "generat[e] their own search queries, select[] appropriate tools, and determin[e] what information to retain".

                +----------------------+
   requete ---> |   LLM augmente       | ---> reponse
                |  - recherche         |
                |  - outils            |
                |  - memoire           |
                +----------------------+

Tous les patterns qui suivent assemblent plusieurs de ces briques.

4. Pattern 1 : Prompt chaining (chaînage)#

Schéma#

entree -> [LLM 1] -> sortie 1 -> [controle] -> [LLM 2] -> sortie 2 -> [LLM 3] -> livrable
                                     |
                                  si KO : stop ou correction

Quand l'utiliser#

"This workflow is ideal for situations where the task can be easily and cleanly decomposed into fixed subtasks."

Traduction : quand tu connais les étapes à l'avance et qu'elles sont toujours les mêmes.

Exemples donnés par l'article : générer un texte marketing puis le traduire ; créer un plan de document, le vérifier, puis écrire.

Exemple data#

La migration Oracle vers BigQuery du fichier 03-prompt-chaining.md : inventaire, traduction, revue, tests. Quatre étapes fixes, dans cet ordre, toujours.

Autre exemple : documenter un modèle dbt.

1. Lire le SQL          -> liste des colonnes et de leur origine
2. Lire les sources     -> definition metier de chaque colonne source
3. Croiser              -> fichier schema.yml complet

Le piège#

Si tu ajoutes des if partout dans ta chaîne, ce n'est plus un chaînage. C'est du routing (pattern suivant) ou de l'orchestration (pattern 4). Ne force pas.

5. Pattern 2 : Routing (aiguillage)#

Schéma#

                  +-> [LLM specialise A] -> reponse
entree -> [classifieur] -> [LLM specialise B] -> reponse
                  +-> [LLM specialise C] -> reponse

Quand l'utiliser#

"Routing works well for complex tasks where there are distinct categories that are better handled separately, and where classification can be handled accurately."

Les deux conditions comptent : des catégories vraiment distinctes, ET une classification fiable. Si ton classifieur se trompe une fois sur trois, le routing empire les choses.

Deux exemples donnés par l'article :

• Diriger des demandes de support (général, remboursement, technique) vers des processus différents.
• Envoyer les questions simples vers un petit modèle, et les questions complexes vers un modèle plus capable.

Exemple data#

Un assistant interne sur ta plateforme data :

Question de l'utilisateur
        |
   [classifieur, modele rapide, effort low]
        |
   +----+----+----------------+------------------+
   |         |                |                  |
"c'est quoi" "donne-moi     "pourquoi mon     "modifie ce
 (definition)  ce chiffre"    DAG a echoue"     modele dbt"
   |           |                |                  |
 glossaire   outil SQL      outil logs        agent code
 (pas de LLM)  + gros LLM    + gros LLM        (pattern 6)

Le premier cas ne consomme même pas d'appel LLM : une définition de glossaire est une recherche dans une table. C'est le genre d'économie que le routing permet.

Prompt de classifieur#

Classe la question de l'utilisateur dans exactement une categorie.

<question>
[LA_QUESTION]
</question>

Categories :
- DEFINITION : demande le sens d'un terme metier ou d'un indicateur
- CHIFFRE : demande une valeur qui se trouve dans l'entrepot
- INCIDENT : signale ou interroge un echec de pipeline
- MODIFICATION : demande de changer du code ou un modele
- AUTRE : ne rentre dans aucune des categories precedentes

Reponds uniquement par ce JSON :
{"categorie": "...", "confiance": "haute|moyenne|basse", "raison": "une phrase"}

Si la confiance est basse, mets AUTRE.

La dernière ligne est importante : un routeur doit avoir une sortie de secours. Sans elle, il force une catégorie et se trompe.

6. Pattern 3 : Parallélisation#

Schéma, variante "sectioning" (découpage)#

              +-> [LLM sur morceau 1] -+
entree -> split -> [LLM sur morceau 2] -+-> agregation -> resultat
              +-> [LLM sur morceau 3] -+

Schéma, variante "voting" (vote)#

              +-> [LLM, tentative 1] -+
entree -------+-> [LLM, tentative 2] -+-> consensus -> resultat
              +-> [LLM, tentative 3] -+

Quand l'utiliser#

"Parallelization is effective when the divided subtasks can be parallelized for speed, or when multiple perspectives are needed for higher confidence results."

Les deux variantes, selon l'article :

• Sectioning : découper des sous-tâches indépendantes et les exécuter en parallèle.
• Voting : lancer la même tâche plusieurs fois pour obtenir des sorties diverses.

Exemples cités : mise en place de garde-fous avec un filtrage séparé ; revue de vulnérabilités de code ; évaluation de l'acceptabilité d'un contenu.

Exemple data - sectioning#

Auditer la qualité de 50 modèles dbt. Chaque modèle est indépendant : 50 appels en parallèle, puis un appel final qui agrège le rapport.

from concurrent.futures import ThreadPoolExecutor

def auditer(modele):
    return appel_llm(PROMPT_AUDIT, modele, effort="medium")

with ThreadPoolExecutor(max_workers=8) as pool:
    rapports = list(pool.map(auditer, les_50_modeles))

synthese = appel_llm(PROMPT_SYNTHESE, rapports, effort="high")

Exemple data - voting#

Une requête SQL va tourner sur 4 To en production. Tu ne veux pas te tromper.

Appel 1 : "Cette requete contient-elle un fan-out ?"        -> oui / non + preuve
Appel 2 : "Cette requete gere-t-elle mal les NULL ?"        -> oui / non + preuve
Appel 3 : "Cette requete a-t-elle un probleme de fuseau ?"  -> oui / non + preuve

Trois angles séparés, trois réponses indépendantes. C'est plus fiable qu'un seul appel "trouve tous les problèmes", parce que chaque appel a un objectif unique.

Le piège#

La parallélisation coûte cher en appels. Elle ne se justifie que si la vitesse ou la fiabilité valent le surcoût. Pour une tâche de routine, non.

7. Pattern 4 : Orchestrateur-workers#

Schéma#

                  +-> [worker 1] -+
entree -> [orchestrateur] -> [worker 2] -+-> [synthetiseur] -> resultat
                  +-> [worker N] -+
                       ^
        l'orchestrateur decide COMBIEN de workers et QUOI leur donner

Quand l'utiliser#

"This workflow is well-suited for complex tasks where you can't predict the subtasks needed."

La différence avec la parallélisation est là : en parallélisation, toi tu découpes. En orchestration, le modèle découpe, parce que tu ne peux pas savoir à l'avance combien de morceaux il y aura.

Exemples de l'article : changements de code complexes touchant plusieurs fichiers ; recherche et analyse multi-sources.

Exemple data#

"Le chiffre d'affaires du dashboard ne correspond plus à celui du reporting finance. Trouve pourquoi."

Tu ne peux pas écrire le plan à l'avance. L'orchestrateur, lui, peut :

Orchestrateur analyse la demande et decide :
  -> worker A : comparer les definitions des deux indicateurs
  -> worker B : comparer les filtres appliques de chaque cote
  -> worker C : comparer les perimetres de dates
  -> worker D : verifier les rafraichissements des deux sources

(4 workers ici, mais ca aurait pu etre 2 ou 7)

Synthetiseur : croise les 4 retours -> "l'ecart vient du filtre sur les avoirs"

Ce que la doc ajoute sur les sous-agents#

Les modèles récents orchestrent des sous-agents nativement : "Claude's latest models orchestrate subagents natively. These models can recognize when tasks would benefit from delegating work to specialized subagents and do so proactively without requiring explicit instruction."

Mais il y a un avertissement : "Watch for overuse." Certains modèles lancent des sous-agents là où un simple grep aurait suffi. Prompt correctif donné par la doc :

Use subagents when tasks can run in parallel, require isolated context, or involve
independent workstreams that don't need to share state. For simple tasks, sequential
operations, single-file edits, or tasks where you need to maintain context across steps,
work directly rather than delegating.

8. Pattern 5 : Évaluateur-optimiseur#

Schéma#

entree -> [generateur] -> proposition -+
              ^                        |
              |                        v
              +---- retour ------- [evaluateur]
                                       |
                              accepte ? -> sortie

Quand l'utiliser#

"This workflow is particularly effective when we have clear evaluation criteria, and when iterative refinement provides measurable value."

Les deux conditions : des critères clairs, et un gain mesurable à chaque itération. Si tu ne sais pas dire ce qui est "mieux", ce pattern tourne en rond.

Exemples de l'article : traduction littéraire avec des retours nuancés ; recherches complexes en plusieurs tours nécessitant une analyse exhaustive.

Exemple data#

Optimiser une requête BigQuery qui coûte trop cher.

Generateur  : propose une version optimisee de la requete
Evaluateur  : verifie 4 criteres
              1. le resultat est-il strictement identique ? (requete de controle)
              2. le volume scanne estime a-t-il baisse ?
              3. la requete reste-t-elle lisible ?
              4. utilise-t-elle bien le partitionnement et le clustering ?
              -> verdict + retours precis
Boucle      : maximum 3 tours

Le critère 1 est celui qui rend le pattern honnête : une optimisation qui change le résultat n'est pas une optimisation.

Le piège#

Toujours borner le nombre de tours. Deux ou trois. Au-delà, tu paies pour des micro-améliorations, et l'évaluateur finit par chercher des problèmes qui n'existent pas.

9. Pattern 6 : Agent autonome#

Schéma#

        humain donne l'objectif
                |
                v
     +--> [LLM planifie]
     |          |
     |          v
     |     [appelle un outil]
     |          |
     |          v
     |     [observe le resultat]
     |          |
     |     objectif atteint ? --non--+
     |                                |
     +--------------------------------+
                |
               oui
                v
         resultat + point d'arret humain

Quand l'utiliser#

"Agents can be used for open-ended problems where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path."

Exemples de l'article : tâches de code type SWE-bench avec modifications multi-fichiers ; usage de l'ordinateur.

Exemple data#

"Ce DAG Airflow échoue une fois sur cinq depuis trois semaines. Trouve pourquoi."

Tu ne peux pas écrire le plan : la cause peut être un quota API, une race condition, une donnée source qui change de format, un problème de fuseau. L'agent explore : il lit les logs, compare les runs en échec et en succès, regarde les données d'entrée, formule une hypothèse, la teste.

Les garde-fous obligatoires#

Un agent qui agit sur des systèmes réels doit être encadré. La doc donne un prompt à cet effet, dont voici le cœur :

Consider the reversibility and potential impact of your actions. You are encouraged to
take local, reversible actions like editing files or running tests, but for actions that
are hard to reverse, affect shared systems, or could be destructive, ask the user before
proceeding.

Traduis-le dans ton contexte data :

Actions autorisees sans demander :
- lire des logs, lire des tables, lancer un SELECT avec dry_run
- ecrire dans le dataset [DATASET_BAC_A_SABLE]

Actions qui exigent ma confirmation explicite :
- declencher ou relancer un DAG en production
- ecrire dans un dataset de production
- modifier une variable ou une connexion Airflow
- tout DROP, DELETE, TRUNCATE, ou git push --force

L'autre garde-fou, c'est la limite d'itérations. Un agent sans plafond peut boucler longtemps et cher.

10. Choisir en 30 secondes#

11. Ton template prêt à copier#

Template A - Choisir le pattern#

Je dois construire : [DECRIS_TON_BESOIN].

Contexte :
- Volume : [COMBIEN_D_ELEMENTS_PAR_JOUR]
- Les etapes sont-elles connues a l'avance ? [OUI/NON/PARTIELLEMENT]
- Criticite : [ce qui casse si le resultat est faux]
- Budget / latence acceptable : [CONTRAINTE]

Parmi ces patterns : prompt chaining, routing, parallelisation, orchestrateur-workers,
evaluateur-optimiseur, agent autonome, ou un simple appel unique.

1. Dis lequel tu recommandes et pourquoi, en 3 phrases.
2. Dis quel pattern PLUS SIMPLE pourrait suffire, et ce que je perdrais.
3. Donne le schema en texte du flux retenu.
4. Liste les points de controle humains necessaires.

La question 2 est la plus importante. Elle t'empêche de sur-construire.

Template B - Prompt d'orchestrateur#

Tu es l'orchestrateur d'une equipe d'agents specialises.

Objectif : [L_OBJECTIF_GLOBAL].

Outils disponibles pour tes workers :
- [OUTIL_1] : [CE_QU_IL_FAIT]
- [OUTIL_2] : [CE_QU_IL_FAIT]

Etape 1. Dans <plan>, decoupe l'objectif en sous-taches independantes. Pour chacune :
son objectif en un verbe, l'outil a utiliser, le format de son retour.
Ne cree pas plus de [N] sous-taches.

Etape 2. Dans <delegation>, produis un JSON : une entree par sous-tache, avec
{"id": "...", "consigne": "...", "outil": "...", "format_retour": "..."}

Regle : si une sous-tache depend du resultat d'une autre, dis-le explicitement dans
"depend_de". Ne lance pas en parallele des taches dependantes.

Template C - Prompt d'évaluateur#

Tu evalues une production. Tu ne l'as pas ecrite. Sois exigeant mais precis.

<objectif_initial>
[CE_QUI_ETAIT_DEMANDE]
</objectif_initial>

<production>
[CE_QUI_A_ETE_PRODUIT]
</production>

Criteres, dans cet ordre de priorite :
1. [CRITERE_BLOQUANT, ex: le resultat est-il strictement identique a l'original ?]
2. [CRITERE_PRINCIPAL, ex: le cout a-t-il baisse ?]
3. [CRITERE_SECONDAIRE, ex: la lisibilite]

Reponds avec ce JSON :
{
  "verdict": "ACCEPTE | A_AMELIORER | REJETE",
  "par_critere": [{"numero": 1, "note": "ok|ko", "justification": "..."}],
  "retours_actionnables": ["consigne precise pour le prochain tour"],
  "vaut_il_le_coup_d_iterer": true
}

Si le critere 1 est KO, le verdict est REJETE, sans discussion.
Si les ameliorations restantes sont marginales, mets "vaut_il_le_coup_d_iterer": false.

À retenir#

• Cherche d'abord la solution la plus simple. Souvent, un seul appel bien construit suffit.
• Workflow = le chemin est dans ton code. Agent = le chemin est décidé par le modèle.
• Six patterns : chaînage, routing, parallélisation, orchestrateur-workers, évaluateur-optimiseur, agent autonome.
• Le routing a besoin d'une classification fiable et d'une catégorie de secours.
• L'évaluateur-optimiseur a besoin de critères clairs et d'une limite de tours.
• Un agent autonome exige des garde-fous explicites sur les actions irréversibles, et un plafond d'itérations.
• Soigne tes outils autant que tu soignerais une interface humaine : "plan to invest just as much effort in creating good agent-computer interfaces (ACI)".

Sources#

• Building effective agents - Anthropic Engineering
• Prompting best practices - Anthropic
• Writing effective tools for AI agents - Anthropic Engineering
• Effective context engineering for AI agents - Anthropic Engineering
• Tool use with Claude - Anthropic
• Claude Code - Overview
• anthropics/claude-cookbooks - code d'exemple sur les six patterns agentiques : patterns/agents/basic_workflows.ipynb (chaînage, routing, parallélisation), patterns/agents/orchestrator_workers.ipynb, patterns/agents/evaluator_optimizer.ipynb
• anthropics/claude-quickstarts - une boucle d'agent autonome minimale, outils locaux et MCP : agents/agent.py