Agents et workflows

01Workflow ou agent

Un agent, c’est un logiciel à qui vous confiez un travail entier. Pas une instruction — le travail. Vous lui donnez un objectif et un ensemble d’outils (recherche, e-mail, vos fichiers, tout ce que la tâche exige), et il travaille en boucle : regarder où on en est, décider du prochain geste, l’accomplir, regarder à nouveau. Il s’arrête quand le travail est fait.

La première question de toute construction d’agent n’est donc pas comment. C’est si. Ce travail a-t-il vraiment besoin d’un agent ?

Les agents sont l’option coûteuse : plus de pièces mobiles à coordonner, des coûts d’exécution plus élevés, plus de façons d’échouer. Parfois ce prix vaut la peine d’être payé — pour un travail ouvert où personne ne peut écrire les étapes à l’avance. La plupart du temps, un montage fixe plus simple fait le travail pour une fraction du coût. Trancher cette question délibérément, avant de construire quoi que ce soit, voilà la véritable première décision de conception.

Voici comment la prendre. Cinq signes révélateurs, chacun avec une réponse « workflow » et une réponse « agent » :

• —Le plan. Si vous pouvez énumérer les étapes exactes dans le code, choisissez un workflow — le code est le plan. Si vous pouvez donner l’objectif et les outils mais pas le chemin, c’est le territoire de l’agent. Découvrir le chemin, c’est ce pour quoi vous payez le modèle.
• —Le rayon d’impact. Quand les erreurs coûtent cher et que chaque étape exige son propre garde-fou, le workflow gagne. Vous avez écrit les étapes, donc une barrière peut se placer exactement là où est le risque. Avec un agent, le risque se déplace — le modèle choisit l’ordre — donc le filet de sécurité doit être l’ensemble d’outils lui-même. Le non-déterminisme est acceptable quand les outils enregistrés bornent tout ce que l’agent peut faire.
• —La traçabilité. Un workflow est facile à surveiller : chaque étape est un appel que vous pouvez journaliser et tracer, et sur lequel vous pouvez lever des alertes avec les outils que vous faites déjà tourner. Un agent demande plus que ça — ce qu’il a vu, ce qu’il a fait, pourquoi — avant qu’on puisse lui faire confiance en production.
• —Les entrées. Des entrées connues et bien contraintes — un formulaire fixe, un format connu — pointent vers un workflow. Des entrées qui varient de façon imprévisible en contenu et en structure réclament quelque chose capable d’absorber la surprise et d’agir quand même.
• —Le rythme. La même séquence, à chaque exécution ? Workflow. Le travail exige un séquençage créatif, l’ordre des outils inventé au fil du travail ? C’est le terrain de jeu de l’agent.

Une progression soutient les cinq signes : commencez par un seul appel. Ajoutez un workflow quand le travail a des étapes que vous pouvez écrire. Ne passez à l’agent que lorsque la variabilité dépasse ce que ces étapes peuvent absorber.

02Les cinq schémas de workflow

Les écrits d’ingénierie d’Anthropic nomment cinq formes récurrentes. Toutes reposent sur la même brique : le LLM augmenté. C’est un modèle doté de retrieval, d’outils et de mémoire, qui écrit ses propres requêtes de recherche, choisit ses propres outils, décide quelles informations garder. Les schémas ne diffèrent que sur une seule chose — la part de pilotage qu’ils laissent au modèle. L’examen vous donne régulièrement un scénario et demande quelle forme convient :

• —Prompt chaining — des sous-tâches fixes en séquence. Chaque appel traite la sortie du précédent. Des portes programmatiques vérifient les résultats intermédiaires entre les maillons. Vous payez la latence pour gagner en précision sur des tâches décomposables (rédiger, vérifier, réviser).
• —Routing — classifier l’entrée d’abord, puis la confier à un prompt ou à un modèle spécialisé. L’exemple préféré de l’examen : les questions faciles à un petit modèle rapide, les difficiles à un modèle de pointe, pour que la plupart des tokens soient facturés au tarif le moins cher. Prérequis : les entrées tombent vraiment dans des catégories distinctes, et un classifieur peut les trier avec précision.
• —Parallelization — lancer plusieurs appels à la fois. Deux saveurs. Sectioning : des sous-tâches indépendantes s’exécutent séparément et fusionnent dans le code — répondre au client, puis passer la réponse au crible des règles. Voting : la même tâche s’exécute plusieurs fois, pour renforcer la confiance. Répartir les problèmes entre les appels améliore la qualité, pas seulement la vitesse.
• —Orchestrator-workers — un modèle central décompose la tâche, délègue des morceaux à des workers qu’il définit lui-même, puis assemble les résultats. À utiliser quand vous ne pouvez pas énumérer les sous-tâches à l’avance — une refonte qui peut toucher un nombre inconnu de fichiers.
• —Evaluator-optimizer — un générateur et un critique travaillent en boucle, l’un contre l’autre. Il convient quand deux choses sont vraies : les réponses s’améliorent visiblement avec du feedback, et un modèle peut fournir ce feedback lui-même.

La question la plus tranchante de ce groupe : pourriez-vous écrire les sous-tâches avant qu’aucune entrée n’arrive ? Si oui, parallelization. Si le modèle doit les inventer à chaque requête, orchestrator-workers. Sur un schéma, les deux se ressemblent — et l’examen le sait.

Une couche de plus. Parce que l’orchestrateur décide de la délégation au moment de l’exécution, ce schéma est déjà du pilotage par le modèle — c’est là que les workflows commencent à devenir des agents. Managed Agents le dit explicitement : quand son coordinateur délègue, il crée les sessions worker au moment de l’exécution, chacune isolée dans son contexte.

03La boucle de l’agent, et quatre endroits pour la faire tourner

Retirez le marketing, et un agent n’est qu’une boucle. Le modèle regarde l’état courant et, soit demande un outil, soit répond. Votre harness exécute ce qui a été demandé. Le résultat revient dans la conversation. On répète. Un cycle complet est un tour. La boucle ne se termine que lorsque le modèle produit une réponse qui ne contient aucun appel d’outil. C’est ça — pas un message qui semble fini — la condition de sortie.

Reculez encore d’un cran : la boucle est le schéma. Le schéma ne change jamais. Qui la fait tourner est un choix d’implémentation, pas de conception. Quatre surfaces, par transfert croissant de responsabilité :

• —Les Client SDKs — l’API Messages brute. Vous écrivez la boucle vous-même. Le bon choix quand vous avez besoin d’un contrôle exact sur chaque requête.
• —Le Claude Agent SDK — une bibliothèque qui fait tourner le moteur de Claude Code dans votre processus. Il apporte des outils intégrés (fichiers, shell, web), des permissions, des sessions, des sous-agents, des hooks et des connexions MCP. Le bon choix quand vous voulez le harness mais devez l’auto-héberger — par exemple sur votre propre cluster Kubernetes.
• —Managed Agents — Anthropic héberge à la fois le harness et le bac à sable. Vous définissez l’agent une fois — modèle, prompt système, outils, serveurs MCP — puis vous y faites référence par ID, vous envoyez des événements, et vous recevez les résultats en flux. Le bon choix pour des sessions longues et asynchrones quand vous ne voulez pas gérer vous-même le sandboxing ni le stockage de session.
• —Le CLI Claude Code — le même moteur, guidé par un humain dans un terminal.

La documentation attache un avertissement à tous les frameworks, et l’examen lui fait écho. Une abstraction qui masque les prompts et les réponses invite à de mauvaises suppositions sur ce qu’elle fait sous le capot. Si vous utilisez un harness, sachez quel code il exécute réellement.

Managed Agents porte une contrainte qui tranche la question avant que le confort n’ait son mot à dire. Ses sessions sont avec état et stockées côté Anthropic. Et la fonction n’est actuellement pas éligible au Zero Data Retention ni à une BAA HIPAA — à jour de septembre 2026.

Les charges de travail avec ces exigences restent sur l’Agent SDK ou sur une boucle brute, même si le chemin géré convient bien par ailleurs.

Quelle que soit la surface choisie, quatre tâches sont sur la liste :

• —Enregistrer les outils — chacun avec son schéma, pour que le modèle sache ce qui existe et comment l’appeler.
• —Cadrer le prompt système — un prompt trop large fait errer le routage des outils ; un prompt qui nomme la tâche unique et ses outils rend le routage cohérent.
• —Exécuter chaque appel d’outil — le modèle émet la requête ; quelque chose que vous avez écrit l’exécute et renvoie le résultat.
• —Définir la sortie — avant que la boucle ne tourne, pas pendant.

Cette dernière tâche mérite son propre paragraphe. La boucle se termine quand le modèle répond sans appel d’outil — mécaniquement vrai, mais « le modèle s’est arrêté » n’est pas une condition de sortie. Sans ligne d’arrivée que vous avez fixée, le modèle peut continuer à appeler des outils au-delà de l’utile. Décidez ce que « terminé » signifie avant de lancer, et faites respecter cette définition par la boucle.

Dernière question de câblage : où placer un contrôle humain ? Demandez-vous quel est le pire résultat si cette étape s’exécute sans vérification. Trois points d’insertion couvrent l’essentiel :

• —Avant un appel destructeur — une écriture, une suppression, un envoi. Un mauvais geste ici ne peut pas être annulé.
• —Après le plan, avant l’exécution. Un mauvais plan parfaitement exécuté reste mauvais.
• —Sur une sortie inattendue — un drapeau d’erreur, un résultat vide, une valeur hors limites. Ce sont les défaillances qu’un retry ne répare pas.

04Lire le flux

L’interface de requête de l’Agent SDK produit un flux de messages typés. Cinq types comptent :

• —SystemMessage — des métadonnées de cycle de vie. Un message « init » au départ, un message « compact_boundary » après la compaction de la conversation.
• —AssistantMessage — la sortie du modèle. Un message par bloc de contenu (blocs de texte, blocs d’utilisation d’outils) ; les blocs d’une même réponse partagent un ID de message.
• —UserMessage — les résultats d’outils qui remontent vers le modèle, plus toute saisie humaine injectée en cours de boucle.
• —StreamEvent — les deltas incrémentaux, si vous avez demandé le streaming partiel des messages.
• —ResultMessage — la fin de la boucle : texte final, usage de tokens, coût, ID de session. Vérifiez son sous-type — « success » n’est pas la seule valeur.

Deux détails d’implémentation qui deviennent des questions d’examen. Premièrement : rien ne garantit que le message de résultat soit le dernier élément du flux. Des événements système peuvent suivre, donc itérez jusqu’au bout plutôt que de sortir tôt.

Deuxièmement : dans le SDK TypeScript, les blocs de contenu sont un niveau plus profond qu’en Python — message.message.content, pas message.content. Les événements de hook disponibles diffèrent aussi entre les deux langages de SDK ; tous les événements n’existent pas dans les deux (à jour de septembre 2026).

05Comment l’utilisation des outils s’exécute vraiment

Le contrat que l’examen veut vous faire intérioriser : Claude n’exécute jamais rien. Il émet une requête structurée — un nom d’outil plus des arguments. Autre chose l’exécute. Ce « autre chose » vient en exactement trois saveurs :

• —Les outils définis par l’utilisateur — vous écrivez le schéma, votre code exécute l’appel, votre code renvoie le tool_result. Claude ne voit que le schéma et le résultat, jamais l’implémentation.
• —Les outils à schémas Anthropic — bash, text_editor, memory et leurs cousins. Anthropic publie le schéma. Les modèles sont entraînés sur ces signatures exactes, ce qui rend les appels plus fiables — mais votre application les exécute quand même. C’est la ligne que les gens ratent.
• —Les server tools — web_search, web_fetch, code_execution, tool_search. Une liste qui s’allonge : à jour de septembre 2026. Définis par Anthropic, exécutés sur l’infrastructure d’Anthropic. Vous ne construisez jamais de tool_result pour ceux-ci ; la réponse contient déjà le résultat.

Avec des outils côté client, votre code se cale sur le stop_reason de la réponse. Quand il vaut « tool_use », exécutez les outils demandés. Ajoutez les résultats comme blocs tool_result dans un nouveau message utilisateur. Renvoyez la conversation. Continuez la boucle tant que stop_reason vaut « tool_use ». Les autres raisons d’arrêt sont « end_turn », « max_tokens », « stop_sequence » et « refusal ».

Le cas délicat, c’est « pause_turn ». Les server tools tournent dans une boucle qui leur est propre, à l’intérieur de l’infrastructure d’Anthropic, et cette boucle a une limite d’itérations. Si la limite est atteinte en plein travail, vous recevez pause_turn — le travail n’est pas terminé. Renvoyez la conversation telle quelle, réponse en pause incluse, et le modèle continue.

Une règle liée. Si le modèle demande un server tool et l’un de vos outils clients dans le même groupe parallèle, le server tool ne s’exécute qu’après que vous avez renvoyé les résultats de votre outil.

06Sous-agents

Un sous-agent est une instance de Claude avec sa propre conversation, son propre prompt et éventuellement un jeu d’outils restreint, engendrée par un parent. Dans l’Agent SDK, vous les définissez de trois façons : dans le code, comme fichiers markdown dans .claude/agents/, ou en utilisant le sous-agent généraliste intégré. En définir un dans le code tient en trois champs. Une description, qui dit au modèle quand y faire appel. Un prompt, qui sert de prompt système. Des surcharges optionnelles d’outils et de modèle. Quatre raisons d’y recourir :

• —L’isolation de contexte — les lectures et le raisonnement du sous-agent se passent dans sa propre fenêtre. Seul son message final revient au parent. C’est un geste de gestion de contexte autant qu’un geste de spécialisation.
• —Le parallélisme — des sous-agents indépendants (un vérificateur de style, un scan de sécurité, une vérification de couverture) s’exécutent en parallèle.
• —Les instructions spécialisées — un prompt système accordé à un seul travail.
• —La restriction d’outils — un relecteur de documentation limité aux outils en lecture seule ne peut physiquement pas modifier de fichiers, quoi que la tâche lui donne envie de faire.

07Une page pour réviser

Six sections de prose sont au-dessus de cette ligne. Voici le même domaine en trois tableaux — la distinction sur laquelle repose chaque question de scénario, les cinq schémas que l’examen nomme, et les quatre surfaces entre lesquelles il vous demande de choisir. Si vous ne relisez qu’une chose la veille, relisez ceci.

Une ligne à tracer à travers tout cela : les idées sont stables, les détails produit ne le sont pas. Qui décide de la prochaine étape, les cinq schémas, la boucle, le partage le-modèle-demande-et-le-harness-exécute — tout cela survivra à n’importe quel changement de produit. Les faits datés — la liste de conformité de Managed Agents, la liste des server tools, les événements de hook qui existent dans chaque langage de SDK — ont été vérifiés auprès de la documentation officielle en septembre 2026, et ils sont du genre de détail qui peut changer entre deux éditions de l’examen. Tout ce qui, sur cette page, est estampillé « à jour de » tombe dans ce second groupe ; revérifiez-le auprès de la documentation vivante la semaine où vous passez l’examen.

08Les pièges de ce domaine

• —« Un agent est une évolution du workflow » — non. La solution la plus simple qui fonctionne gagne ; les agents paient leur flexibilité en latence et en coût.
• —« Orchestrator-workers est la parallelization sous un nouveau nom » — non. Les sous-tâches de la parallelization sont fixées à l’avance ; un orchestrateur les invente à chaque entrée.
• —« Claude exécute les outils » — jamais. Il demande ; votre code ou les serveurs d’Anthropic exécutent.
• —« Tout stop_reason autre que tool_use signifie terminé » — pause_turn signifie un travail de server tool inachevé ; renvoyez et continuez.
• —« Le message de résultat est le dernier élément du flux » — itérez le flux jusqu’au bout et vérifiez le sous-type.
• —« Le modèle s’arrêtera quand il aura fini » — non. Sans condition de sortie que vous avez définie, il peut continuer à appeler des outils au-delà de l’utile. Définissez « terminé », dans le code.

09Vérifiez vos acquis

Trois questions, à peu près dans le registre de l’examen. Chacune se déplie pour montrer la réponse et — plus utilement — pourquoi les mauvaises options sont mauvaises.