Lorsqu'Anthropic a publié Building Effective Agents fin 2024, elle a fait quelque chose de rare pour l'industrie : elle a donné aux ingén

Lorsque Anthropic a publié Building Effective Agents fin 2024, elle a fait quelque chose de rare pour l'industrie : elle a donné aux ingénieurs un vocabulaire commun. Au lieu d'un énième manifeste sur l'intelligence artificielle générale, le guide proposait six modèles clairs pour structurer les systèmes LLM. Un an et demi plus tard, en 2026, le paysage semble radicalement différent. Le Model Context Protocol est devenu un standard universel. Claude a acquis de nouvelles capacités. La plupart des organisations ont désormais au moins un agent en production. Dans ce contexte, il est légitime de se demander si ces six modèles comptent toujours, ou s'ils appartiennent aux archives, aux côtés des poids de modèles de l'année dernière.

Pour le savoir, j'ai testé les six modèles face à un modèle local dans un dépôt séparé. La réponse est oui. Ils tiennent toujours la route. Mais pas parce qu'ils sont des lois immuables. Ils tiennent la route parce que les dix-huit derniers mois d'expérience en production ont validé la logique fondamentale de ce framework.

Ce que le framework nous a réellement apporté

Il vaut la peine de mémoriser précisément ces six modèles : Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers et Autonomous Agents. Le dernier est essentiellement une boucle dans laquelle le modèle planifie, agit, observe et recommence jusqu'à ce qu'une condition soit remplie.

De nombreux ingénieurs enchaînaient déjà des prompts ou déléguaient des tâches à des threads de travail avant la parution du guide. Ce qu'Anthropic a fourni, c'est une taxonomie. L'« agent » de l'un était le « workflow » de l'autre, et l'« appel d'outil multi-étapes » d'un troisième. Le guide a organisé ce désordre en catégories aux limites claires. Cela a permis de débattre des compromis sans se comprendre mutuellement. Dans un domaine noyé par le battage médiatique, un langage précis constitue une sorte d'infrastructure.

L'industrie a construit par-dessus, et non autour

En 2026, ces catégories sont intégrées à la manière dont les équipes conçoivent leurs systèmes. Anthropic les enseigne toujours dans ses cours Academy. Les articles de recherche et les blogs d'ingénierie utilisent toujours ces six catégories pour décrire les nouvelles architectures. Ce genre de longévité est inhabituel pour une discipline qui renouvelle sa pile technologique chaque trimestre.

La raison est simple. L'industrie n'a pas remplacé le framework. Elle a construit par-dessus. De nouveaux outils comme MCP et les standards plus récents Agent Skills font office de plomberie. Ils facilitent la connexion d'un modèle à une base de données, l'exposition d'un outil ou la gestion de l'état. Mais ils ne changent pas la logique de savoir quand utiliser un routeur plutôt qu'un orchestrateur. Un meilleur tuyau ne réécrit pas le plan de la maison.

Les données de production en 2026 le confirment. Le modèle de déploiement le plus courant reste un appel unique d'utilisation d'outil couplé à une révision humaine. Le deuxième plus courant est un workflow multi-étapes avec exactement un transfert à une personne. Tous deux sont les descendants directs du Prompt Chaining et du Routing. Les boucles entièrement autonomes restent l'exception, et non la règle, dans les systèmes en direct.

La retenue a gagné le marché

Le meilleur conseil du guide original était aussi celui qui a été le plus souvent ignoré en 2024 : utilisez le modèle le plus simple qui fonctionne. Ne déployez pas un agent entièrement autonome si un chemin codé en dur suffit à accomplir la tâche.

Le marché a fini par l'internaliser. La plupart des projets pilotes d'agents échouent encore, et ils échouent pour la même raison prévisible. Les équipes empilent les abstractions jusqu'à ce que plus personne ne puisse tracer la limite de décision. Lorsque le système dérive, le débogage devient de l'archéologie. Les entreprises qui ont réussi en production sont celles qui ont fait preuve de retenue. Elles ont privilégié l'utilisation d'outils en un seul tour. Elles n'ont ajouté une couche de routage qu'après avoir constaté l'incohérence d'un prompt unique. Elles ont traité l'autonomie comme un risque à justifier, et non comme une fonctionnalité à célébrer.

Ce n'est pas un argument contre l'ambition. C'est un argument en faveur de la composition. Les modèles fonctionnent mieux lorsqu'on les combine délibérément, plutôt que de se tourner par réflexe vers l'option la plus complexe du menu.

Là où les coutures commencent à lâcher

Le framework n'est pas un remède miracle. Il existe des limites concrètes qui apparaissent dès que l'on quitte le stade du prototype.

For high-frequency, low-cost tasks, deterministic code still wins. An LLM should not be normalizing a CSV column when pandas can do it in milliseconds without hallucinating. Avoid autonomous loops if you cannot define a crisp evaluation goal. Without a clear stopping condition, the model will iterate until it invents a reason to stop. For high-stakes decisions that require external grounding, do not rely solely on the model’s internal knowledge. And watch for bottlenecks in data retrieval. Any pattern that depends on vector search or external APIs can choke if your database is slow or your context window is clogged with irrelevant chunks.

These are not hypothetical edge cases. They are the constraints that separate a working demo from a system that survives the weekend.

A Rigid Check and a Wrong Failure

I learned the practical value of this framework while building my test repository. I was implementing the Evaluator-Optimizer pattern. My evaluator started as a hardcoded regex that scanned the model’s output for specific keywords. The model returned a correct, well-reasoned answer that happened to use synonyms instead of the exact words I was hunting. The evaluator flagged it as a failure.

The model was right. My check was too rigid.

Fixing it required more than expanding a word list. I switched the evaluator itself to an LLM-based judgment. That cost extra tokens and a few more milliseconds, but it restored the evaluation to the right level of abstraction. The pattern itself was sound. I had simply chosen the wrong implementation for the task. That is exactly the kind of mistake the framework is meant to prevent. Some evaluations need code. Others need a model. Knowing which is which is the whole point.

How to Use Them Now

Treat these six patterns as a starting point, not absolute law. Begin with a single prompt. If quality is inconsistent across input types, add a routing layer to send different requests to specialized prompts. If you need multiple independent perspectives before making a call, use Parallelization. If the task is large and divisible, try Orchestrator-Workers. Only reach for the full autonomous loop when the problem space is too wide to pre-map and when you have a reliable