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_datetimeadd_duration_to_datetimeset_reminder
Claude peut gérer des requêtes complexes :
| Requête | Outils 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 :
| Outil | Capacité |
|---|---|
bash | Traitement vidéo via FFmpeg |
generate_image | Créer des images |
text_to_speech | Convertir texte en audio |
post_media | Uploader 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