Agents et workflows

Jusqu’ici, presque tout ce que nous avons construit tenait dans un aller-retour : une requête, une réponse, parfois quelques tours d’outils. Mais certaines tâches réelles ne se plient pas à ce format — elles exigent plusieurs appels au modèle, articulés dans le temps. Pour les structurer, deux architectures dominent : les workflows et les agents. Cette dernière section du cours leur est consacrée.

Choisir entre workflows et agents

La distinction tient à une question : savez-vous, à l’avance, quelles étapes mènent au résultat ? Les workflows conviennent quand vous pouvez visualiser les étapes exactes que Claude doit suivre — ou quand votre interface contraint les utilisateurs à un ensemble de tâches connu. Ce sont des séries d’appels prédéfinis : votre code fixe la séquence, Claude exécute chaque étape. Les agents prennent le relais quand vous ne savez pas exactement quelle tâche ou quels paramètres seront donnés à Claude : on lui remet un objectif et un ensemble d’outils, et c’est le modèle qui détermine comment les combiner, étape après étape, en fonction de ce qu’il découvre.

La conséquence pratique : un workflow est plus prévisible, plus testable, souvent moins cher — préférez-le chaque fois que le chemin est connu. L’agent achète de la flexibilité au prix du contrôle — réservez-le aux problèmes dont le chemin dépend réellement de l’entrée.

Exemple de workflow : Image vers CAD

Un exemple concret pour ancrer l’idée. L’utilisateur dépose une image d’une pièce métallique, et l’application produit un fichier STEP — le format standard de la CAO 3D :

1. Envoyer l’image à Claude pour une description détaillée
2. Demander à Claude d’utiliser CadQuery pour modéliser l’objet
3. Créer un rendu 3D du modèle
4. Demander à Claude de noter le rendu par rapport à l’image originale. Si des problèmes existent, corriger et recommencer

C’est un workflow au sens strict : les quatre étapes sont écrites dans le code, toujours dans cet ordre, quelle que soit l’image. Claude intervient plusieurs fois avec des rôles différents — décrire, coder, juger — mais il ne choisit jamais la séquence. Notez l’étape 4 : elle referme une boucle, et cette boucle est un motif si fréquent qu’il porte un nom.

Le pattern évaluateur-optimiseur

Ce motif — le pattern évaluateur-optimiseur — organise le travail entre deux rôles. Un producteur prend une entrée et crée une sortie : ici, le code CadQuery généré depuis la description. Un évaluateur note cette sortie selon des critères : la comparaison du rendu 3D à l’image d’origine. Si l’évaluateur rejette, son feedback repart vers le producteur, qui retente en tenant compte des défauts signalés ; le cycle continue jusqu’à validation. On obtient ainsi une qualité qu’un appel unique n’atteint presque jamais — le système se corrige lui-même, sans intervention humaine, jusqu’à passer la barre fixée.

Les deux rôles peuvent être joués par le même modèle avec des prompts différents, par deux modèles, ou par un modèle et un vérificateur en code — l’évaluation par code des sections précédentes était déjà une variante de ce schéma. Identifier ces patterns vous donne des recettes réutilisables : la plupart des fonctionnalités multi-étapes que vous aurez à construire se ramènent à quelques motifs de ce genre, assemblés différemment.

Points clés à retenir

• Workflow = séquence d’appels prédéfinie par votre code ; agent = objectif + outils, Claude décide du chemin
• Critère de choix : les étapes sont-elles connues d’avance ? Oui → workflow ; non → agent
• Le workflow est plus prévisible et testable ; l’agent achète la flexibilité au prix du contrôle
• Pattern évaluateur-optimiseur : produire, noter, réinjecter le feedback, boucler jusqu’à validation
• Ces patterns sont des recettes réutilisables — la plupart des systèmes multi-étapes en combinent quelques-uns