Agents et outils

Après les workflows et leurs chemins prédéfinis, l’autre architecture : les agents donnent à Claude un objectif et un ensemble d’outils, puis le laissent déterminer comment les combiner pour atteindre l’objectif. Le plan quitte votre code pour naître dans le modèle — et toute la conception d’un agent se ramène alors à une question : quels outils lui donner ?

La puissance des outils combinables

Commençons par mesurer ce que la combinaison produit. Avec ces outils datetime de base :

• get_current_datetime
• add_duration_to_datetime
• set_reminder

Claude peut gérer des requêtes complexes :

Personne n’a programmé ces trois scénarios : ils émergent de la composition — trois outils simples couvrent un espace de demandes bien plus vaste que trois fonctionnalités codées en dur. Et le comportement le plus révélateur n’est pas dans le tableau : Claude peut même demander des informations manquantes — « Quand expire ma garantie 90 jours ? » → il demande la date d’achat. Face à une demande sous-spécifiée, l’agent ne plante pas et n’invente pas : il complète. Ce réflexe non plus n’était pas programmé.

Outils abstraits > outils spécialisés

D’où le principe central de conception, contre-intuitif au premier abord : préférez les outils abstraits aux outils spécialisés. Claude Code l’illustre avec des outils tous génériques : Bash pour lancer une commande, Read, Write et Edit pour les fichiers, et des outils de recherche.

Pas d’outil « refactoriser le code » ou « installer les dépendances » — et pourtant l’agent refactorise et installe à longueur de journée : Claude détermine comment utiliser les outils de base pour accomplir des tâches complexes : une recherche pour trouver les usages, des lectures pour comprendre, des modifications, une commande pour vérifier. Cette abstraction lui permet de gérer des scénarios non prévus lors de la conception : la tentation d’un outil par cas d’usage est exactement ce qui tue la composition — des outils trop étroits ne s’assemblent pas, et chaque besoin nouveau exigerait son outil.

Bonnes pratiques : outils combinables

Transposons le principe à un autre agent — un créateur de vidéos social media :

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

Cet ensemble permet des workflows simples mais aussi des expériences interactives où l’agent peut générer un exemple, obtenir l’approbation, puis procéder — la boucle humain-dans-le-circuit émerge naturellement d’outils composables, sans qu’on l’ait codée.

À vous de jouer

Abstraire vos outils. Listez les outils d’un agent que vous voudriez construire. Pour chacun, demandez-vous s’il est trop étroit (un outil par cas d’usage) ou trop large (un outil qui fait tout). Réécrivez la liste avec trois à cinq outils composables, et vérifiez que trois demandes différentes peuvent s’y résoudre.

Sources officielles : Agents and tools (Claude Academy) · Building effective agents (Anthropic : les patterns de workflows et les agents)

Points clés à retenir

• Agent = objectif + outils ; le plan de combinaison naît dans le modèle à chaque exécution
• Trois outils simples couvrent des dizaines de scénarios — les capacités émergent de la composition
• Face au sous-spécifié, un bon agent demande les précisions manquantes au lieu d’inventer
• Outils abstraits et composables > outils hyper-spécialisés qui ne s’assemblent pas (référence : Claude Code)
• Le bon niveau d’abstraction : général pour composer, concret pour accomplir un vrai travail