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 :

Pouvez-vous décrire les étapes exactes ?
    ↓
OUI → Workflow
    ↓
NON → Avez-vous vraiment besoin de flexibilité ?
    ↓
OUI → Agent (avec conscience des compromis)
NON → Repensez votre architecture

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.

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