Agents et outils

Après les workflows et leurs patterns, place à l’autre architecture : les agents. Les agents diffèrent des workflows structurés sur le point essentiel — au lieu de définir une séquence rigide, vous donnez à Claude un objectif et un ensemble d’outils, puis le laissez déterminer comment les combiner. Le plan n’est plus dans votre code ; il naît dans le modèle, à chaque exécution, en fonction de la demande.

La puissance de la combinaison d’outils

Ce déplacement du plan a une conséquence remarquable : la couverture fonctionnelle explose sans que la boîte à outils grandisse. Reprenez nos trois outils datetime du projet de rappels (get_current_datetime, add_duration_to_datetime, set_reminder) — trois fonctions simples, et regardez la variété des requêtes qu’elles couvrent :

• « Quelle heure est-il ? » → un seul outil
• « Quel jour serons-nous dans 11 jours ? » → deux outils chaînés
• « Programme un rappel pour mercredi prochain » → trois outils en séquence
• « Quand expire ma garantie de 90 jours ? » → Claude demande d’abord des précisions à l’utilisateur

Personne n’a écrit ces quatre scénarios : ils émergent de la combinaison. Le dernier cas est le plus révélateur — face à une demande sous-spécifiée (garantie achetée quand ?), l’agent ne plante pas et n’invente pas : il pose la question manquante. Ce comportement-là non plus n’était pas programmé.

Les outils doivent être abstraits

D’où la question centrale de la conception d’agents : quels outils fournir ? La clé, contre-intuitive, est de fournir des outils raisonnablement abstraits plutôt qu’hyper-spécialisés. La tentation naturelle est d’écrire un outil par cas d’usage — c’est exactement ce qui tue la combinaison : des outils trop étroits ne s’assemblent pas, et chaque nouveau besoin exige un nouvel outil.

Claude Code illustre le principe parfaitement. L’agent de programmation d’Anthropic accomplit des tâches d’une immense variété — déboguer, refactorer, écrire des tests, migrer des projets — avec une poignée d’outils génériques :

• bash : exécuter des commandes
• glob : trouver des fichiers
• grep : chercher dans le contenu
• read / write / edit : manipuler des fichiers
• webfetch : récupérer une URL

Pas d’outil « Refactorer » ni « Lancer les tests » : Claude détermine comment accomplir ces tâches en combinant les outils de base — un grep pour trouver les usages, des read pour comprendre, des edit pour modifier, un bash pour vérifier. Les capacités viennent de la composition, pas du catalogue.

Bonne pratique

Transposons à un cas concret : un agent de création de vidéos pour réseaux sociaux. Des outils efficaces seraient :

• bash : accès à FFMPEG pour le traitement vidéo
• generate_image : créer des images à partir de texte
• text_to_speech : convertir du texte en audio
• post_media : publier du contenu

Observez le niveau d’abstraction : chaque outil est assez général pour servir dans plusieurs contextes — bash couvre à lui seul tout ce que FFMPEG sait faire, découpe, sous-titres, conversion — mais assez spécifique pour accomplir un travail concret. C’est l’équilibre à viser : en dessous (un outil « ajouter_sous_titres_jaunes »), l’agent est corseté ; au-dessus (un outil « faire_la_video »), il n’y a plus d’agent du tout, juste une fonction qu’on espère magique.

Points clés à retenir

• Un agent reçoit un objectif et des outils ; le plan de combinaison naît dans le modèle, pas dans votre code
• Trois outils simples couvrent des dizaines de scénarios — les capacités émergent de la composition
• Face à une demande incomplète, un bon agent demande les précisions manquantes
• Préférez des outils abstraits et composables aux outils hyper-spécialisés qui ne s’assemblent pas
• Référence : Claude Code et ses outils génériques (bash, grep, read/write/edit) — pas d’outil « Refactorer »