Partie 11 · Claude qui agit pour toi
C'est quoi un agent IA : la définition officielle d'Anthropic en 8 minutes
Tu sauras distinguer un workflow d'un vrai agent, et tu reconnaîtras les 5 patterns d'agents publiés par Anthropic en décembre 2024.
Le mot "agent IA" est partout sur LinkedIn depuis 18 mois. Tu as déjà entendu "agent autonome", "workflow agentique", "swarm d'agents".
Le problème, c'est que personne ne définit le mot pareil.
Anthropic, l'entreprise qui a créé Claude, a publié en décembre 2024 un papier de recherche intitulé Building Effective AI Agents qui pose une définition claire. Tu vas apprendre cette définition et tu sauras reconnaître à quoi tu as affaire la prochaine fois que quelqu'un te vend "son agent IA".
En 8 minutes de lecture, tu comprends la différence entre un workflow et un agent, et tu connais les 5 patterns d'orchestration qu'Anthropic recommande. Ce guide s'adresse à toute personne qui a déjà utilisé Claude et qui veut comprendre comment construire des automatisations plus poussées.
Tu lis le chapitre 59 d'un manuel de 67 chapitres disponible sur claude-pour-les-debutants.fr.
La distinction Anthropic en 1 phrase
Anthropic distingue deux familles de systèmes qui utilisent un modèle d'IA pour agir.
✦ Un workflow, c'est un système où le modèle suit un chemin de code prédéfini par un humain.
✦ Un agent, c'est un système où le modèle décide lui-même de ses prochaines actions et de l'utilisation de ses outils.
La différence tient au contrôle. Dans un workflow, c'est l'humain qui a écrit l'ordre des étapes à l'avance.
Dans un agent, le modèle choisit dynamiquement quelle étape vient ensuite, en fonction de ce qu'il observe.
→ Workflow = train sur rails. Agent = chauffeur de taxi qui décide de la route.
Pourquoi cette distinction compte
Cette distinction n'est pas un détail théorique. Elle change ce que tu peux automatiser et combien ça va te coûter.
Un workflow est prévisible. Tu sais à l'avance combien d'appels au modèle il va faire, donc tu peux estimer le coût.
Tu sais aussi à quelle étape il peut casser, donc tu peux mettre des garde-fous précis. Un agent est imprévisible.
Le modèle peut décider de faire 3 appels ou 30, selon la difficulté de la tâche. Il peut explorer une piste qui se révèle inutile, puis revenir en arrière.
▸ Conséquence pratique : si ta tâche est répétitive et bien définie (classer des emails, extraire des données d'un PDF, traduire un texte), tu construis un workflow. Si ta tâche est ouverte et que tu ne peux pas anticiper toutes les étapes (debugger un bug inconnu, résoudre un ticket support complexe), tu construis un agent.
Le papier Anthropic insiste sur ce point : "Le succès dans l'espace LLM ne consiste pas à construire le système le plus sophistiqué. Il s'agit de construire le bon système pour vos besoins." Commencer simple est la règle.
Le pattern 1, le prompt chaining
Le pattern le plus simple, c'est l'enchaînement de prompts.
Tu décomposes une tâche complexe en plusieurs étapes successives. À chaque étape, le modèle traite la sortie du précédent.
Tu peux ajouter des contrôles entre chaque étape pour vérifier que le résultat intermédiaire est correct avant de continuer.
▸ Exemple concret : tu veux générer un article de blog. Étape 1, tu demandes à Claude de produire un plan détaillé. Étape 2, tu vérifies que le plan contient bien les 5 sections attendues. Étape 3, tu demandes à Claude de rédiger chaque section. Étape 4, tu demandes à Claude de relire et de corriger.
→ Tu utilises ce pattern quand la tâche se décompose proprement en sous-tâches séquentielles, et que tu veux contrôler la qualité à chaque étape.
Le pattern 2, le routing
Tu utilises un premier appel au modèle pour classer l'input, puis tu diriges chaque catégorie vers la bonne tâche spécialisée.
Tu demandes au modèle de regarder ta demande, de la classer dans une catégorie, puis de déclencher le bon traitement. Ça te permet d'avoir des prompts ultra-spécialisés pour chaque catégorie au lieu d'un prompt généraliste qui fait tout moyennement.
▸ Exemple concret : ton service client reçoit 1000 messages par jour. Tu utilises un premier appel pour classer chaque message (remboursement / question technique / résiliation / autre). Puis tu envoies chaque catégorie à un workflow dédié avec ses propres consignes, ses propres modèles de réponse, et son propre escalade vers un humain si besoin.
↳ Tu utilises ce pattern quand tes inputs sont variés mais qu'ils se rangent en catégories distinctes qui méritent chacune un traitement spécifique.
Le pattern 3, la parallelization
La parallélisation lance plusieurs appels au modèle en même temps, puis combine les résultats.
Il existe deux variantes. La première s'appelle le sectioning et découpe une tâche en sous-tâches indépendantes qui s'exécutent en parallèle. La deuxième s'appelle le voting et lance plusieurs fois la même tâche pour obtenir plusieurs réponses, puis tu gardes la plus fréquente ou tu combines.
▸ Exemple sectioning : tu veux analyser 100 fichiers PDF. Tu lances 10 appels Claude en parallèle, chacun traite 10 fichiers, et tu combines les résultats à la fin.
▸ Exemple voting : tu poses à Claude une question sensible (est-ce qu'un email est une tentative de phishing ?). Tu poses la même question 5 fois avec des températures différentes. Si 4 réponses sur 5 disent "oui", tu as davantage confiance dans le verdict.
→ Tu utilises ce pattern quand la vitesse compte (parallélisation pure) ou quand tu veux réduire le risque d'erreur (voting majoritaire).
Le pattern 4, l'orchestrateur-ouvriers
L'orchestrateur est un modèle central qui décompose une tâche imprévisible et délègue à d'autres modèles.
C'est le premier pattern qui s'approche d'un vrai agent. L'orchestrateur lit la demande, décide combien d'ouvriers lancer et avec quelles instructions, puis attend leurs résultats et les synthétise.
▸ Exemple concret : tu veux refactorer un code Python sur 50 fichiers. L'orchestrateur lit ta demande, identifie les 50 fichiers concernés, lance 50 ouvriers en parallèle (chacun avec un fichier différent), récupère les modifications, et te livre la synthèse.
↳ La différence avec la parallélisation simple, c'est que tu ne sais pas à l'avance combien d'ouvriers seront lancés. C'est l'orchestrateur qui décide en fonction de ce qu'il découvre.
Le pattern 5, l'évaluateur-optimiseur
Tu fais travailler deux modèles en boucle. Tu demandes au premier d'écrire une réponse. Tu demandes au second de la critiquer. Tu fais tourner la boucle jusqu'à atteindre la qualité voulue.
C'est le pattern le plus utile pour les tâches où tu peux mesurer objectivement la qualité du résultat, mais où la première tentative n'est presque jamais parfaite.
▸ Exemple concret : tu veux générer un texte en anglais qui doit absolument respecter une grille de lecture niveau collège. Le générateur écrit une première version. L'évaluateur mesure le niveau de lecture et liste ce qui dépasse. Le générateur réécrit en tenant compte du feedback.
La boucle s'arrête quand le niveau cible est atteint.
→ Tu utilises ce pattern quand tu peux automatiser la critique (tests unitaires, métriques de qualité, vérifications factuelles) et que la première sortie est rarement bonne du premier coup.
Le vrai agent autonome
Le vrai agent autonome est le cas extrême du pattern orchestrateur-ouvriers, où l'orchestrateur tourne en boucle jusqu'à finir la tâche ou abandonner.
L'agent reçoit une mission ouverte. Il décide de ses prochaines actions en fonction de ce qu'il observe à chaque tour.
Il utilise des outils (lecture de fichiers, exécution de code, requêtes web). Il peut reprendre 50 ou 500 fois la même boucle observation-décision-action avant de rendre son rapport final.
Les exemples concrets qui marchent aujourd'hui sont surtout dans 2 domaines : le support client (l'agent lit le ticket, consulte la documentation, propose une réponse, et escalade si besoin) et le code (l'agent lit le bug, explore le code, propose un patch, lance les tests, et corrige tant que ça casse).
↳ Le critère pour qu'un vrai agent fonctionne : les critères de succès doivent être mesurables. Sans ça, l'agent ne sait pas quand s'arrêter.
La règle d'or sur le design des outils
Anthropic insiste fortement sur un point qui passe souvent inaperçu.
"Les définitions et spécifications d'outils devraient recevoir autant d'attention de prompt engineering que vos prompts globaux."
Concrètement, ça veut dire que la documentation que tu donnes au modèle pour décrire un outil (que fait-il, quels paramètres prend-il, quels résultats renvoie-t-il) doit être aussi soignée que ton prompt principal. Un outil mal documenté, c'est un agent qui l'utilise mal ou qui l'utilise pas.
✦ La règle pratique : pour chaque outil que tu exposes à ton agent, tu écris la documentation comme si tu la donnais à un nouveau collègue qui démarre lundi.
Un prompt pour reconnaître le bon pattern
Tu vas copier ce prompt pour aider Claude à te recommander le bon pattern selon ta tâche.
<role>Tu es un architecte de systèmes IA qui aide à choisir le bon
pattern d'agent selon la nature de la tâche, en t'appuyant sur le
papier Anthropic "Building Effective AI Agents".</role>
<context>
Voici la tâche que je veux automatiser :
{DESCRIPTION_TACHE}
Voici les contraintes :
- Volume estimé : {VOLUME_PAR_JOUR}
- Critère de succès mesurable : {OUI_OU_NON_EXPLICATION}
- Tolérance à l'erreur : {FAIBLE_MOYENNE_ELEVEE}
</context>
<task>
1. Classe ma tâche dans la grille Anthropic
(workflow vs agent autonome).
2. Recommande le pattern le plus adapté parmi les 5 (prompt chaining,
routing, parallelization, orchestrator-workers, evaluator-optimizer)
ou agent autonome.
3. Explique en 3 phrases pourquoi ce pattern et pas un autre.
4. Donne-moi 2 risques principaux et comment les mitiger.
5. Estime grossièrement le nombre d'appels au modèle par exécution.
</task>
<constraints>
Reste pédagogue, pas de jargon inutile. Si plusieurs patterns sont
acceptables, dis-le et donne le tradeoff.
</constraints>
→ Tu remplis les 3 variables, tu colles dans claude.ai, et tu obtiens un avis structuré. Si la réponse te paraît douteuse, tu relances avec des contraintes plus précises.
Un dernier mot
La hype autour des "agents IA" est dangereuse parce qu'elle pousse à construire des systèmes complexes là où un simple prompt suffirait.
La leçon centrale d'Anthropic, c'est de commencer par la solution la plus simple qui marche. Un seul appel au modèle avec un bon prompt résout 80 pour cent des cas.
Tu n'as besoin d'un workflow que quand la tâche se décompose proprement. Tu n'as besoin d'un agent que quand la tâche est vraiment ouverte et que les critères de succès sont mesurables.
Maintenant que tu connais la grille, tu peux lire n'importe quelle annonce produit IA et savoir si c'est un vrai agent ou juste un workflow déguisé en marketing.
→ Essaie Claude maintenant : claude.ai
→ Chapitre suivant : Computer Use, l'ordinateur piloté par Claude
Ce chapitre t'a aidé ?
Sois le premier à donner ton avis.