Workflows vs agents

Dernière leçon du cours, et une question d’architecte pour la clore : workflows ou agents ? Nous avons exploré les deux — les patterns de workflows (chaînage, parallélisation, routage, évaluateur-optimiseur) et la boucle d’agent avec ses outils. Il reste à trancher la question que tout projet réel finit par poser : lequel choisir, et sur quels critères. Chacune des deux architectures a ses avantages et ses compromis — mais la recommandation finale, elle, est nette.

Workflows

Un workflow est une série d’appels à Claude prédéfinis pour résoudre un problème connu. L’image juste est celle de la recette : vous connaissez les ingrédients et les étapes, le modèle exécute chaque étape avec talent, mais la séquence est la vôtre.

Cette structure fixe est la source de tous leurs points forts. Claude se concentre sur une sous-tâche à la fois, d’où une meilleure précision que face à un problème monolithique. L’évaluation devient naturelle : chaque étape étant connue, on peut la tester isolément, mesurer sa qualité, l’améliorer sans toucher au reste — tout l’outillage d’évaluation de ce cours s’applique maillon par maillon. Et l’exécution est prévisible et fiable : mêmes étapes, même ordre, à chaque fois.

Le revers est l’inverse exact : les workflows sont moins flexibles, dédiés à des types de tâches spécifiques — la recette du gâteau ne fait pas de soupe. L’expérience utilisateur est plus contrainte : l’application propose des parcours définis, pas une conversation ouverte où tout est possible.

Agents

L’agent inverse le contrat : Claude reçoit un ensemble d’outils de base et doit formuler lui-même un plan pour accomplir la tâche. Au lieu de suivre un chemin prédéterminé, il détermine créativement comment gérer les défis — il choisit ses outils, interprète les résultats, ajuste sa stratégie en cours de route.

Ce que cela achète : une expérience utilisateur bien plus flexible — l’utilisateur demande ce qu’il veut, pas ce que l’interface prévoit —, une capacité à combiner les outils de manières inattendues que personne n’avait scriptées, et même la faculté de générer leurs propres entrées ou de demander des précisions quand la tâche est ambiguë.

Ce que cela coûte : un taux de réussite plus bas que les workflows — plus de liberté, c’est plus d’occasions de se tromper, et les erreurs se composent au fil des étapes. Et une instrumentation difficile : comment tester un système dont le chemin change à chaque exécution ? L’évaluation, si simple maillon par maillon, devient un problème de recherche sur un agent complet.

Recommandation

Les agents sont fascinants techniquement — c’est la partie de l’ingénierie IA dont tout le monde parle. Mais votre objectif premier en tant qu’ingénieur est de résoudre des problèmes de manière fiable, et les utilisateurs ne se soucient pas que vous ayez construit un agent sophistiqué : ils veulent un produit qui fonctionne 100 % du temps. Un workflow prévisible qui réussit toujours vaut mieux qu’un agent brillant qui réussit souvent.

Privilégiez toujours les workflows quand c’est possible. Les agents ne devraient être utilisés que quand le chemin de la solution ne peut pas être prédéterminé — quand la variété des demandes rend toute recette impossible. Et même alors, les leçons de ce cours restent votre filet : outils bien conçus, inspection de l’environnement, évaluation systématique. C’est sur ces fondations, plus que sur l’architecture choisie, que se joue la fiabilité de ce que vous construirez.

Points clés à retenir

• Workflow = recette prédéfinie : précision, testabilité maillon par maillon, exécution prévisible
• Agent = plan formulé par le modèle : flexibilité maximale, mais taux de réussite plus bas et tests difficiles
• Les erreurs d’agent se composent au fil des étapes — la liberté a un coût statistique
• Les utilisateurs jugent la fiabilité, pas la sophistication de l’architecture
• Règle finale : workflow par défaut, agent seulement quand le chemin ne peut pas être prédéterminé

Testez vos connaissances

Dernière vérification des acquis avant de clore le cours.

1. Comment le SDK s'authentifie-t-il sur Vertex AI sans clé API Anthropic ?

Réponse : Via les Application Default Credentials de Google Cloud (gcloud auth application-default login) : AnthropicVertex les détecte automatiquement — aucun secret dans le code.

2. Où active-t-on les modèles Claude dans Google Cloud ?

Réponse : Dans le Model Garden de la console Vertex AI : activation modèle par modèle et projet par projet, avec la facturation portée par le projet.

3. Comment marque-t-on un contenu à mettre en cache ?

Réponse : Avec cache_control: {“type”: “ephemeral”} sur un bloc en forme longue — posé sur le dernier outil ou le dernier bloc du système, il couvre tout ce qui précède (1024 tokens minimum).

4. Quel réglage force Claude à appeler un outil précis, et à quoi sert-il surtout ?

Réponse : tool_choice: {“type”: “tool”, “name”: …} — indispensable pour l’extraction de données structurées : la réponse est alors un appel d’outil dont les arguments sont le JSON voulu, déjà parsé.

5. Workflow ou agent : quelle est la règle de décision finale du cours ?

Réponse : Workflow par défaut — précis, testable, prévisible ; agent seulement quand le chemin ne peut pas être prédéterminé et que la flexibilité prime réellement.

Acquis validés ? La certification officielle vous attend sur Anthropic Academy — et vos projets GCP aussi.