Workflows vs agents : comment choisir ?

Les patterns de workflows sont en place, la boucle d’agent aussi : reste la question que tout projet réel finit par poser — lequel choisir ? La réponse n’est pas une affaire de goût mais d’arbitrage mesurable, et cette leçon donne la grille de décision.

Comparaison détaillée

Lisez le tableau colonne par colonne : le workflow gagne sur quatre critères sur cinq, et l’agent n’en gagne qu’un — la flexibilité. Mais ce critère unique est parfois celui qui compte : quand les demandes des utilisateurs sont réellement imprévisibles, aucune séquence prédéfinie ne les couvrira. Toute la décision consiste à savoir si votre cas a vraiment besoin de cette flexibilité, ou si c’est la fascination technique qui parle. Notez aussi la ligne testabilité : tout l’outillage d’évaluation de ce cours s’applique naturellement aux étapes connues d’un workflow ; évaluer un agent dont le chemin change à chaque exécution est un problème autrement plus dur.

La recommandation

Privilégiez toujours les workflows quand c’est possible. N’utilisez les agents que lorsqu’ils sont véritablement nécessaires.

La raison de cette fermeté : les utilisateurs ne jugent pas la sophistication de votre architecture, ils jugent la fiabilité du produit. Un workflow prévisible qui réussit toujours vaut mieux qu’un agent brillant qui réussit souvent. L’arbre de décision tient en deux questions :

La dernière branche mérite un mot : si vous ne pouvez pas décrire les étapes mais n’avez pas non plus besoin de flexibilité, le problème est probablement mal découpé — souvent, un routage vers plusieurs workflows spécialisés couvre ce qu’on prenait pour un besoin d’agent.

Cas typiques

Workflow pour :

• Extraction de données depuis des documents
• Génération de contenu avec révision
• Pipeline avec validations intermédiaires

Agent pour :

• Assistants de programmation (Claude Code)
• Agents de recherche explorant des sources inconnues
• Tâches ouvertes où l’utilisateur peut demander n’importe quoi

Le fil qui sépare les deux listes : dans la première, le chemin est connu d’avance — même si chaque étape est complexe ; dans la seconde, le chemin dépend de ce qu’on découvre en route — la structure du code, le contenu des sources, la demande de l’utilisateur. Et même quand l’agent s’impose, les leçons du cours restent votre filet : outils bien décrits, inspection de l’environnement, évaluation continue — c’est là-dessus, plus que sur l’architecture, que se joue la fiabilité finale.

Quand un agent s’impose, vous n’êtes pas obligé d’écrire sa boucle vous-même : le tool runner du SDK la fait tourner (leçon 38), le Claude Agent SDK fournit la boucle et les outils de Claude Code, et Claude Managed Agents, en bêta, exécute la boucle et l’environnement des outils sur l’infrastructure d’Anthropic.

À vous de jouer

Trancher sur un cas réel. Prenez une fonctionnalité que vous envisagez de confier à un agent. Essayez d’en écrire les étapes : si vous y arrivez, écrivez le workflow ; sinon, notez ce qui empêche de les écrire, et la façon dont vous évaluerez l’agent avant de le mettre en production.

Sources officielles : Workflows vs agents (Claude Academy) · Building effective agents (Anthropic : les patterns de workflows et les agents) · Agent SDK overview (documentation Claude Code) · Managed Agents (documentation Claude)

Points clés à retenir

• Le workflow gagne sur précision, testabilité, prédictibilité et complétion ; l’agent ne gagne que la flexibilité
• Règle : workflow par défaut, agent seulement quand la flexibilité est réellement nécessaire
• Deux questions décident : étapes descriptibles ? besoin réel de flexibilité ?
• Ni étapes connues ni besoin de flexibilité = problème mal découpé — pensez routage
• Les utilisateurs jugent la fiabilité, pas la sophistication de l’architecture