Introduction à l'utilisation d'outils

Par défaut, Claude ne sait que ce qu’il a appris pendant son entraînement : il ne voit ni l’actualité, ni vos bases de données, ni l’heure qu’il est. Les outils (tools) comblent ce manque. Ils lui donnent un moyen structuré de demander une information fraîche ou une action, que votre application exécute pour lui. Cette section construit pas à pas un assistant qui s’en sert.

Le problème sans outils

Demandez à Claude, par l’API et sans outil : « Quel temps fait-il à Lyon en ce moment ? ». La seule réponse honnête est qu’il n’a pas accès à la météo en temps réel. L’utilisateur repart sans réponse, alors qu’une API météo l’aurait fournie en une fraction de seconde.

Un contrat entre votre application et Claude

L’utilisation d’outils est un contrat. Vous déclarez les opérations disponibles et la forme de leurs paramètres ; Claude décide quand les appeler et avec quels arguments. Le point essentiel : le modèle n’exécute jamais rien lui-même. Il émet une demande structurée, votre code (ou la plateforme, pour les outils serveur) réalise l’opération, et le résultat revient dans la conversation.

L’aller-retour en quatre temps

1. Requête initiale : vous envoyez la question de l’utilisateur et la description des outils disponibles.
2. Demande d’outil : Claude constate qu’il lui manque une information. Sa réponse s’arrête sur une demande d’appel (stop_reason vaut "tool_use"), qui porte le nom de l’outil et ses arguments.
3. Exécution : votre code appelle l’API météo, la base de données ou la fonction concernée.
4. Réponse finale : vous renvoyez le résultat à Claude, qui rédige sa réponse à partir de la question et des données fraîches.

Trois familles d’outils

La documentation classe les outils selon l’endroit où leur code s’exécute.

Sur l’API Claude, la famille des outils serveur compte aussi la lecture de pages web et l’exécution de code. Sur Vertex, offre gérée par Google, ces deux outils ne sont pas disponibles : la recherche web est le seul outil serveur.

L’essentiel de cette section porte sur la première famille, de loin la plus utilisée. Les leçons 32 et 33 présentent un outil de chacune des deux autres : l’éditeur de texte et la recherche web.

Quand utiliser un outil, et quand s’en passer

Un outil s’impose dès que la tâche demande ce que le texte seul ne peut pas fournir :

• Une action : envoyer un courriel, écrire un fichier, enregistrer un rappel.
• Une donnée fraîche ou interne : un prix du jour, la météo, le contenu de votre base.
• Une sortie de forme garantie : un objet JSON aux champs précis plutôt qu’un paragraphe à analyser.
• Un système existant : une API interne, un système de fichiers, une base de données.

La documentation donne un signal simple : si vous écrivez une expression régulière pour retrouver une décision dans le texte de Claude, cette décision aurait dû être un appel d’outil.

À l’inverse, un outil est inutile quand Claude peut répondre avec ses seules connaissances (résumer, traduire, expliquer), ou quand l’aller-retour supplémentaire coûterait plus de temps que la tâche elle-même.

À vous de jouer

Repérer les besoins. Prenez une application que vous connaissez et listez trois questions d’utilisateur auxquelles Claude ne peut pas répondre seul. Pour chacune, notez l’outil qu’il faudrait : son nom, ce qu’il reçoit, ce qu’il renvoie, et sa famille.

Sources officielles : Introducing tool use (Claude Academy) · How tool use works (documentation Claude) · Claude Models on Google Cloud (Google managed) (documentation Claude : outils disponibles sur Vertex)

Points clés à retenir

• Les outils donnent à Claude un accès structuré aux données fraîches et aux actions.
• Claude n’exécute rien : il demande, votre code (ou la plateforme, pour les outils serveur) exécute.
• L’aller-retour : requête avec outils, demande tool_use, exécution, résultat renvoyé, réponse finale.
• Trois familles : outils définis par vous, outils à schéma Anthropic, outils serveur.
• Pas d’outil quand le texte seul suffit : chaque appel ajoute un aller-retour.