Aller au contenu principal

Agents et outils

Mis à jour le 30 juillet 2026

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 :

RequêteOutils utilisés
« Quelle heure est-il ? »get_current_datetime
« Quel jour dans 11 jours ? »get_current_datetime + add_duration_to_datetime
« Rappel gym mercredi »Les 3 outils en séquence

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 / read / write / edit / glob / grep

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 — un grep pour trouver les usages, des read pour comprendre, des edit pour modifier, un bash 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 :

OutilCapacité
bashTraitement vidéo via FFmpeg
generate_imageCréer des images
text_to_speechConvertir texte en audio
post_mediaUploader sur les plateformes sociales

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.

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