Patterns de workflow d'agents IA : 7 patterns et quand chacun l'emporte vraiment (2026)

Patterns de workflow d'agents IA : 7 patterns et quand chacun l'emporte vraiment (2026)

Les patterns de workflow d'agents IA ont enfin des chiffres : en janvier 2026, Google Research a évalué 180 configurations d'agents et constaté que le même changement de coordination fait gagner 80,9 % à un raisonnement financier parallélisable, tout en écrasant la planification séquentielle jusqu'à −70 % sur PlanCraft. Même levier, résultats opposés. La variable qui tranche est la décomposabilité de la tâche, pas le nombre d'agents, et les sept patterns ci-dessous sont jugés sur des données publiées plutôt que sur des diagrammes d'éditeurs.

• Sept patterns comptent : sequential, routing, parallelization, orchestrator-workers, reflection, ReAct, plan-and-execute.
• La décomposabilité de la tâche décide du gagnant. Le travail parallélisable y gagne ; le travail séquentiel se dégrade.
• Commencez avec un seul agent. N'en ajoutez un deuxième que si l'agent seul plafonne sous ~85 % de précision.

Patterns de workflow d'agents IA en un coup d'œil : ce que disent les données

Les sept patterns d'agents IA sont sequential (chaînage de prompts), routing (aiguillage), parallelization (fan-out/fan-in), orchestrator-workers, reflection (évaluateur-optimiseur), ReAct et plan-and-execute. Cinq documentations d'éditeurs les nomment différemment, mais ces sept formes couvrent toutes les taxonomies qu'Anthropic, OpenAI, Vercel, Microsoft et Google Cloud publient aujourd'hui. Human-in-the-loop n'est pas l'un des sept : c'est une couche de contrôle qui enveloppe n'importe lequel d'entre eux.

Lisez la colonne « mesuré » avec scepticisme. Trois lignes portent de vrais chiffres ; quatre portent « aucune mesure publique », ce qui est l'état honnête du domaine en 2026. Cinq éditeurs publient cinq noms différents pour ce qui est en réalité trois ou quatre formes sous-jacentes. La dernière colonne existe pour que vous puissiez relier chacun de ces noms à la forme qu'il recouvre, et le reste de l'article déroule une famille à la fois.

Deux colonnes que personne n'aborde dans les résultats de recherche sont le coût en tokens et le budget de latence. Sequential et routing sont les moins gourmands sur les deux ; orchestrator-workers est le plus coûteux sur les deux ; parallelization échange des tokens contre du temps d'horloge. Choisissez le pattern selon la ressource que votre tâche contraint vraiment, pas selon le diagramme qui impressionne.

Que sont les patterns de workflow d'agents IA (et quelles sont les 4 étapes d'un workflow IA) ?

Les patterns de conception de workflow d'agents IA sont des formes réutilisables pour organiser les appels au LLM, l'usage d'outils et la logique de contrôle en un système. Les sept qui reviennent dans toutes les taxonomies d'éditeurs sont sequential, routing, parallelization, orchestrator-workers, reflection, ReAct et plan-and-execute. Chacun arbitre différemment entre coût en tokens, latence et précision ; le bon choix dépend donc de la structure de la tâche plutôt que du framework que vous utilisez.

Un workflow d'agent IA typique déroule quatre étapes, en boucle :

1. Planifier : le modèle décide de la prochaine action, compte tenu du but et de l'historique.
2. Agir : il appelle un outil, ce qui en 2026 signifie généralement un serveur MCP ou un function call. Model Context Protocol (MCP) standardise cette couche d'outils entre les modèles.
3. Observer : le résultat de l'outil revient dans le contexte comme un nouveau message.
4. Réfléchir / boucler : le modèle juge si le résultat est suffisant, puis boucle ou s'arrête.

Chaque pattern de cet article est une manière différente de câbler ces quatre étapes. Sequential fixe l'ordre dans le code. ReAct laisse le modèle choisir l'étape suivante à chaque tour. Orchestrator-workers répartit la boucle entre plusieurs modèles.

Une distinction compte avant le catalogue. Un workflow suit des chemins de code prédéterminés ; un agent confie le contrôle au modèle. Anthropic trace la ligne ainsi dans Building Effective Agents : « Les workflows offrent prévisibilité et cohérence pour des tâches bien définies, tandis que les agents sont la meilleure option quand flexibilité et décisions pilotées par le modèle sont nécessaires à l'échelle. »

Si vous cherchez les types classiques d'agents en IA (réflexe simple, basé sur un modèle, basé sur un but, apprenant), cette taxonomie précède les LLM ; les sept patterns ci-dessus sont ceux qui décident si votre système sera livré.

Les patterns déterministes : sequential, routing et parallelization

Trois patterns gardent le contrôle dans votre code plutôt que dans le modèle. Ce sont les moins chers à exécuter et les plus simples à déboguer, et le conseil de l'équipe Claude en mars 2026 est sans détour quant au point de départ : « Commencez avec le pattern le plus simple qui résout votre problème. Par défaut, sequential. »

Sequential (chaînage de prompts)

Un appel alimente le suivant. Vous découpez une tâche difficile en étapes ordonnées, et chaque étape reçoit la sortie de la précédente en entrée. Le gain est la lisibilité : vous pouvez inspecter chaque résultat intermédiaire et mettre chaque étape en cache. Évitez-le quand les sous-tâches sont indépendantes, car vous payez de la latence pour un ordonnancement dont vous n'avez pas besoin. Si l'état doit survivre entre les étapes ou entre les sessions, c'est un problème de mémoire, pas un problème de chaînage ; voyez notre guide sur la mémoire des agents pour la frontière. Son seul appui publié est un défaut : aucune étude ne mesure un gain du chaînage lui-même, car c'est la référence que tous les autres patterns paient en plus pour battre.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Routing (aiguillage)

Un classifieur peu coûteux lit l'entrée et la dispatche vers un prompt ou un modèle spécialiste. OpenAI le formule ainsi dans la documentation Agents SDK : « Un agent de triage achemine la conversation vers un spécialiste, et ce spécialiste devient l'agent actif pour le reste du tour. » Évitez le routing quand le classifieur est moins fiable qu'un chemin généraliste unique, car chaque mauvais aiguillage est une réponse fausse silencieuse. Le mode d'échec nommé ici est la perte de contexte lors du transfert : le spécialiste ne voit que ce que le routeur transmet. Conserver la trace complète est une décision d'ingénierie du contexte, et la rater explique pourquoi les systèmes aiguillés semblent oublieux. Le calcul en tokens plaide quand même pour le routing : le classifieur tourne sur un petit modèle (gpt-4o-mini ci-dessus), donc un routeur ajoute quelques centaines de tokens bon marché par requête plutôt qu'un deuxième appel coûteux.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Parallelization (fan-out/fan-in)

Les sous-tâches indépendantes s'exécutent en parallèle, puis une étape de fusion les combine. Anthropic distingue sectioning (diviser le travail) et voting (exécuter la même tâche plusieurs fois et comparer). C'est la forme que Google Research a mesurée à +80,9 % par rapport à un agent seul sur le raisonnement financier parallélisable en janvier 2026, précisément parce que la tâche se décomposait proprement. Évitez-la dès que l'étape n+1 dépend de la sortie de l'étape n ; paralléliser une chaîne de dépendances ne fait que réordonner plus vite des réponses fausses. La latence est l'autre moitié du gain : les appels indépendants s'exécutent simultanément, donc le temps d'horloge baisse à peu près avec le nombre de workers tandis que le total de tokens reste plat.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs Plan-and-Execute : quel pattern de raisonnement choisir ?

ReAct entrelace raisonnement et action : le modèle réfléchit, appelle un outil, observe le résultat, et décide seulement alors de l'étape suivante. Plan-and-execute écrit le plan complet avant tout appel d'outil, puis exécute les étapes dans l'ordre. ReAct s'adapte aux imprévus en cours de route ; plan-and-execute paie d'avance un gros appel de planification et fait confiance au trajet.

ReAct décide de l'étape suivante après chaque observation ; plan-and-execute s'engage sur tout le trajet avant le premier appel d'outil.

ReAct vient de Yao et al. (arXiv 2210.03629, v1 octobre 2022, v3 mars 2023), qui rapporte +34 % de réussite en absolu sur ALFWorld et +10 % sur WebShop par rapport aux références d'imitation et d'apprentissage par renforcement, avec seulement un ou deux exemples in-context. C'est la boucle par défaut de la plupart des agents outillés, et c'est une lacune du 3e résultat de recherche : la documentation d'orchestration de Microsoft Learn, 7 133 mots, omet totalement ReAct. Ce rythme observer-décider explique pourquoi ReAct traite mieux les tâches ouvertes (« parcourez jusqu'à trouver X ») que n'importe quel plan établi d'avance : le plan devrait deviner ce que contiennent les pages avant de les lire.

Plan-and-execute vient de Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), qui élabore d'abord un plan divisant la tâche en sous-tâches, puis les exécute. L'article rapporte une victoire sur le chain-of-thought zero-shot sur les dix datasets évalués ; nous ne citons aucun chiffre unique car l'abstract n'en publie aucun. Utilisez-le quand le trajet est prévisible et que replanifier après chaque étape gaspillerait des tokens. La contrepartie est la fragilité : si l'étape trois échoue, une boucle plan-and-execute a besoin d'un crochet de replanification explicite, alors que ReAct replanifie par construction.

La ligne des preuves mesurées est le signe honnête. ReAct a un article de 2022 avec des chiffres par tâche ; plan-and-execute a un balayage sur dix datasets et aucun chiffre phare, ce qui explique en partie qu'il soit cité plus souvent qu'il n'est benchmarké.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Ce plafond d'itérations n'est pas optionnel. Une boucle ReAct sans sortie brûle des tokens jusqu'à épuiser votre budget ; max_steps est le garde-fou le moins cher de tout cet article. Plan-and-execute a besoin du même garde-fou un niveau plus haut : plafonnez les replanifications, pas seulement les étapes, sinon un plan défaillant se régénérera indéfiniment.

Les patterns de qualité : reflection, evaluator-optimizer et human-in-the-loop

Les patterns de qualité dépensent des tokens en plus pour améliorer la qualité de sortie, et ils ne paient que si la qualité est mesurable. Reflection (Anthropic l'appelle evaluator-optimizer) fait tourner un générateur et un critique en boucle : un modèle rédige, un autre critique, le brouillon s'améliore. Si vous ne pouvez pas noter la sortie avec un test, une grille ou un modèle évaluateur, le critique n'est que des tokens en plus qui argumentent seuls. Construire ce scoreur est la partie difficile ; notre guide sur l'évaluation des agents en production couvre ce qu'exige une fonction de score utilisable. Quand la condition préalable tient, le pattern est une assurance bon marché : Anthropic décrit evaluator-optimizer comme deux appels LLM en boucle, l'un qui génère et l'un qui critique, ce qui achète un gain de qualité mesurable contre quelques secondes de latence en plus.

Le mode d'échec que personne ne schématise est la réflexion emballée : le critique et le générateur bouclent à l'infini, ou pire, oscillent. Le correctif est un plafond d'itérations dur plus un arrêt en l'absence d'amélioration, écrits dans le code plutôt que demandés dans le prompt :

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop est une couche de contrôle, pas un huitième pattern. Il enveloppe n'importe lequel des sept : un humain approuve avant qu'une étape irréversible s'exécute. Seuls 2 des 6 premiers résultats de recherche en parlent. Placez le guichet sur les actions irréversibles, les dépenses réelles et tout ce qui quitte votre système comme communication externe. Tout le reste doit s'exécuter sans surveillance ou ne pas s'exécuter. Le guichet lui-même doit être du code simple, pas un autre LLM : une file d'approbation, un seuil de dépense, une liste blanche de domaines. Confier à un modèle la décision de faire intervenir un humain vide l'idée de son sens.

Le multi-agent vaut-il 15× plus de tokens ? Ce que disent vraiment les benchmarks

Orchestrator-workers est le septième pattern : un agent chef décompose une tâche, délègue des morceaux à des agents workers et fusionne ce qu'ils renvoient. Le « multi-agent » est ce pattern poussé à l'extrême, pas une forme distincte ; la vraie question est donc de savoir quand l'orchestrateur mérite sa surcharge.

Quand utiliser le multi-agent plutôt qu'un agent seul ? Seulement quand un agent seul plafonne sous environ 85 % de précision sur la tâche. Cette règle empirique a circulé sur r/AI_Agents (2026-04-23) en même temps que l'étude de Google Research, et elle colle aux données mesurées : au-dessus de cette barre, ajouter des agents ajoute du coût et de l'amplification d'erreurs sans ajouter de précision.

Voici, côte à côte, tous les chiffres publiés que nous avons pu vérifier :

Un avertissement avant d'aller plus loin : tous les chiffres Google Research ci-dessus viennent du billet de blog du 2026-01-28, et l'article derrière (arXiv 2512.08296) a été révisé depuis ; sa version actuelle rapporte 260 configurations et R² = 0,373 plutôt que les 180 et 0,513 du blog. La direction tient dans les deux cas ; les chiffres exacts dépendent de la version que vous lisez.

Deux de ces lignes sont régulièrement mal citées, alors voici le calcul. Le 15× d'Anthropic est mesuré par rapport à une interaction de chat, et son chiffre pour l'agent seul est 4×. Le multi-agent coûte donc environ 15 / 4 = 3,75× les tokens d'un agent seul, pas 15×. Et l'amplification d'erreurs de 17,2× pour des agents indépendants contre 4,4× pour des agents centralisés, mesurée par Google Research, signifie qu'un orchestrateur contient environ 17,2 / 4,4 = 3,9× moins d'amplification d'erreurs que de laisser les agents tourner sans supervision.

En lisant le compte-rendu d'Anthropic à la lumière des chiffres de Google Research, notre lecture est que la décomposabilité, pas le nombre d'agents, est la variable qui tranche. La tâche de recherche d'Anthropic se divisait proprement en sous-recherches parallèles, donc plus d'agents aidaient. Les tâches de planification séquentielle de Google ne se divisaient pas, donc plus d'agents se gênaient.

Cela rejoint ce que disent les praticiens une fois les systèmes en production. Sur r/AI_Agents, un fil intitulé « Multi agent systems are a total nightmare in production » (2026-04-23, 56 points, 68 commentaires) venait d'un auteur qui a livré plus de 20 systèmes clients : « Ceux qui restent réellement en marche… sont presque ridiculement simples », et « chaque fois qu'un agent parle à un autre, vous perdez du contexte. C'est comme le jeu du téléphone arabe. » Le commentaire en tête résume toute la section : « essayez de résoudre votre problème avec un seul agent. Si cet agent a plus de 85 % de précision, un système multi-agent n'ajoutera aucune valeur. »

Avant d'ajouter un agent, essayez les correctifs bon marché qu'Anthropic a mesurés : une description d'outil améliorée a produit une baisse de 40 % du temps de complétion de tâche, et l'appel d'outils en parallèle a réduit le temps de recherche jusqu'à 90 %. Les deux battent un deuxième agent en coût. Si vous passez quand même au multi-agent dans un vrai outil, les sous-agents de Claude Code sont un orchestrator-workers que vous pouvez inspecter ligne par ligne.

Même pattern, cinq noms : une table de Rosette des frameworks

Les mêmes quatre formes apparaissent sous des noms différents dans la documentation de chaque éditeur, et les noms ne passent pas d'un framework à l'autre. « Magentic » et « group chat » de Microsoft ne veulent rien dire dans l'OpenAI SDK tant que vous ne les traduisez pas, et cette taxe de traduction est un coût réel que cette table supprime.

Cinq éditeurs, cinq vocabulaires, trois ou quatre formes réelles. Le coût pratique apparaît quand vous changez de framework : une équipe qui passe de l'Agent Framework de Microsoft à l'OpenAI SDK doit relier « magentic » à agents-as-tools et « group chat » à un graphe de handoff avant que la moindre ligne de code ne passe. La taxonomie en onze noms de Google Cloud est la plus longue, la liste en sept noms d'Anthropic est la plus citée, et les trois noms du blog Claude sont ceux que vous implémenterez en premier. Lisez la forme, puis lisez le SDK. Les en-têtes de colonnes sont les documentations elles-mêmes : Anthropic, le blog Claude, l'OpenAI Agents SDK, le Vercel AI SDK, Microsoft Learn et Google Cloud. Une fois les formes repérées, choisir un framework est une décision séparée ; notre panorama des meilleurs frameworks d'agents IA en 2026 et le comparatif LangGraph vs CrewAI vs OpenAI Agents SDK couvrent ce choix.

Quand ne faut-il PAS utiliser de workflow agentique ?

Souvent, il ne le faut pas. L'échelle de décision la plus votée sur r/AI_Agents (2026-03-09) le dit simplement : « Si des instructions si…alors suffisent, utilisez ça. Ensuite, si les workflows traditionnels suffisent, utilisez ça. Sinon, utilisez l'IA agentique. » Deux des trois premiers résultats de recherche sont des documentations cloud qui, par construction, ne peuvent pas vous dire de construire moins. Nous le pouvons. Les données de cet article pointent dans la même direction : les deux plus gros gains mesurés (+80,9 % et +90,2 %) viennent tous deux de tâches qui se décomposaient proprement, et la pire perte mesurée (−70 %) vient d'avoir forcé des agents sur une tâche qui ne se décomposait pas.

Les modes d'échec sont nommés, et chacun porte désormais un chiffre :

• Perte de contexte lors des transferts : chaque message d'agent à agent perd de l'état (le constat « téléphone arabe » de r/AI_Agents, 2026-04-23).
• Amplification d'erreurs : 17,2× pour des agents indépendants contre 4,4× en centralisé (Google Research, 2026-01-28).
• Boucles de réflexion emballées : plafonnez les itérations et arrêtez en l'absence d'amélioration, comme dans le code ci-dessus.
• Dégradation des tâches séquentielles : 39 à 70 % de moins quand vous parallélisez un travail qui ne se décompose pas (Google Research, 2026-01-28).
• Explosion des coûts : environ 15× les tokens d'un chat pour un système multi-agent (Anthropic, 2025-06-13).

Chacun de ces modes d'échec a un plafond qui s'écrit en dix lignes de code, et le plafond coûte toujours moins cher que l'agent que vous alliez ajouter.

Walden Yan, de Cognition, a plaidé la même chose côté constructeur dans Don't Build Multi-Agents (2025-06-12) : « Partagez le contexte, et partagez les traces complètes des agents, pas seulement les messages individuels », et « Les actions portent des décisions implicites, et des décisions contradictoires donnent de mauvais résultats. » La comparaison de r/AI_Agents est celle à laquelle nous revenons sans cesse : « le multi-agent se met à ressembler beaucoup aux microservices. Puissant quand les frontières sont réelles, douloureux quand elles sont inventées. »

Comment Techsy choisit ses patterns

L'échelle ci-dessous est notre lecture des résultats de Google Research et d'Anthropic, plus les fils de praticiens, pas un résultat mesuré qui nous soit propre. Nous la parcourons de haut en bas et nous nous arrêtons à la première ligne qui convient :

Trois choses découlent des données de cet article. Commencez en sequential, parce qu'Anthropic le dit et que rien dans les résultats de recherche ne le contredit. Ne parallélisez que ce qui se décompose, parce que le même changement de coordination mesuré à +80,9 % l'a aussi été à −70 %. Et traitez un deuxième agent comme un dernier recours, parce que la facture en tokens est réelle et que l'amplification d'erreurs est mesurée. Le fil conducteur est qu'ajouter des agents est un mouvement de mise à l'échelle, pas un mouvement de qualité : les benchmarks ne le récompensent que là où le travail se divise, et les fils de praticiens le confirment partout ailleurs. Si vous voulez un deuxième avis sur une architecture avant de la construire, Demandez une consultation gratuite.

Questions fréquemment posées

Quels sont les 7 patterns d'agents IA ?

Les sept sont sequential (chaînage de prompts), routing (aiguillage), parallelization (fan-out/fan-in), orchestrator-workers, reflection (évaluateur-optimiseur), ReAct et plan-and-execute. Ils reviennent sous des noms différents dans toutes les taxonomies d'éditeurs, d'Anthropic à Google Cloud. Human-in-the-loop est discuté à leurs côtés, mais c'est une couche de contrôle qui enveloppe n'importe lequel des sept, pas un huitième pattern.

Quelles sont les 4 étapes d'un workflow d'agent IA ?

Planifier, agir, observer, réfléchir. Le modèle planifie une prochaine étape, agit en appelant un outil, observe le résultat de l'outil qui entre dans le contexte, puis réfléchit à savoir si le but est atteint et boucle ou s'arrête. Chaque pattern de cet article est une manière différente de câbler ces quatre étapes.

Quelle différence entre un workflow IA et un agent IA ?

Un workflow suit des chemins de code prédéterminés ; un agent laisse le modèle diriger son propre flux de contrôle. La règle d'Anthropic : les workflows pour la prévisibilité sur des tâches bien définies, les agents pour la flexibilité quand des décisions pilotées par le modèle sont nécessaires à l'échelle. La plupart des systèmes en production sont des workflows avec quelques étapes d'agent à l'intérieur.

ReAct vs plan-and-execute : lequel utiliser ?

Utilisez ReAct quand l'étape suivante dépend de ce que le dernier outil a renvoyé et que le trajet peut changer en cours de route. Utilisez plan-and-execute quand le trajet est prévisible à l'avance et que replanifier après chaque étape gaspillerait des tokens. ReAct a mesuré +34 % sur ALFWorld (Yao et al., 2022) ; plan-and-execute a battu le CoT zero-shot sur dix datasets (Wang et al., 2023).

Ai-je besoin d'un framework comme LangGraph pour utiliser ces patterns ?

Non. Chaque bloc de code de cet article est un simple appel SDK, et les patterns précèdent les frameworks qui les nomment. Un framework mérite sa place sur la persistance d'état, les nouvelles tentatives et le tracing, pas sur le pattern lui-même. Si vous en choisissez un, notre comparatif de frameworks couvre les compromis.

Comment empêcher une boucle de réflexion de tourner à l'infini ?

Deux garde-fous, tous deux dans le code : un plafond d'itérations dur (nous utilisons 4 tours) et un arrêt en l'absence d'amélioration qui stoppe dès que la réécriture du critique ne score pas mieux que le brouillon actuel. Ne faites pas confiance au prompt pour terminer la boucle ; le modèle n'a aucune idée de ce que les choses coûtent.

Quand un agent seul suffit-il ?

Quand il dépasse environ 85 % de précision sur la tâche. Cette heuristique, qui a circulé sur r/AI_Agents (2026-04-23) avec l'étude de Google Research, colle aux benchmarks : au-dessus de cette barre, des agents en plus ajoutent du coût et de l'amplification d'erreurs sans ajouter de précision. Mesurez la référence de l'agent seul avant de concevoir plus gros.

Où trouver des exemples de patterns de workflow d'agents IA avec du code ?

Les cinq blocs Python ci-dessus couvrent sequential, routing, parallelization, ReAct et reflection, tous en simples appels SDK que vous pouvez reprendre directement. Pour des exemples aux couleurs des éditeurs, le Vercel AI SDK livre du TypeScript exécutable par pattern et la documentation de l'OpenAI Agents SDK couvre handoffs et agents-as-tools. Les liens vers les deux figurent dans la liste des sources ci-dessous.

Sources

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28) ; article : arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (mis à jour 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23) ; Wait, are workflows actually better than multi-agent systems? (2026-03-09)