Introduction au tool use

Le concept

Le tool use, ou utilisation d’outils, étend les capacités de Claude en lui donnant accès à des fonctions externes. Un point d’architecture doit être clair avant tout le reste : Claude n’exécute pas de code. Il demande à votre application d’exécuter une fonction, puis se sert du résultat qu’elle lui renvoie. Le modèle décide, votre code agit. Cette répartition n’est pas une limitation technique subie, c’est ce qui vous laisse le contrôle sur tout ce qui touche à vos systèmes.

Le déroulé d’un échange avec outil

La conversation se déroule en six temps :

1. Définir les outils : décrivez les outils disponibles avec leur nom, description et schéma d’entrée
2. Envoyer une requête : Claude reçoit le prompt et la liste des outils
3. Claude demande un outil : si nécessaire, Claude génère une requête d’outil (avec stop_reason: "tool_use")
4. Exécuter l’outil : votre code extrait les paramètres et exécute la fonction
5. Retourner le résultat : envoyez le résultat à Claude dans un message tool_result
6. Réponse finale : Claude utilise le résultat pour formuler sa réponse

L’étape 3 mérite d’être soulignée : Claude peut demander un outil, il n’y est pas contraint. Si la question ne le nécessite pas, il répond normalement. Votre code doit donc traiter les deux cas, et c’est le stop_reason qui vous dit dans lequel vous êtes.

Décrire un outil

Chaque outil se définit par trois champs, et le soin apporté à chacun détermine la fiabilité de l’ensemble : name porte le nom de l’outil, description en détaille l’usage, et input_schema décrit en JSON les paramètres attendus. La calculatrice ci-dessous illustre les trois à la fois.

tools = [
    {
        "name": "calculatrice",
        "description": "Effectue des opérations mathématiques simples.",
        "input_schema": {
            "type": "object",
            "properties": {
                "operation": {
                    "type": "string",
                    "enum": ["addition", "soustraction", "multiplication", "division"],
                    "description": "L'operation a effectuer"
                },
                "operande1": {"type": "number", "description": "Premier nombre"},
                "operande2": {"type": "number", "description": "Second nombre"}
            },
            "required": ["operation", "operande1", "operande2"]
        }
    }
]

La description n’est pas de la documentation à destination de vos collègues : c’est le seul élément sur lequel Claude s’appuie pour décider s’il doit appeler cet outil plutôt qu’un autre. Une description floue produit des appels au mauvais moment. Le schéma, lui, contraint la forme des paramètres — l’enum restreint operation à quatre valeurs, et required interdit les appels incomplets. Chaque contrainte que vous exprimez ici est une erreur que vous n’aurez pas à rattraper dans votre code.

L’appel

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=500,
    tools=tools,
    messages=[
        {"role": "user", "content": "Combien font 1984135 multiplie par 9343116 ?"}
    ]
)

Si response.stop_reason == "tool_use", Claude veut utiliser un outil : extrayez les paramètres, exécutez la fonction, renvoyez le résultat. L’exemple est bien choisi, car cette multiplication est exactement le genre de calcul qu’un modèle de langage produit de façon plausible mais fausse. Avec une calculatrice à disposition, le résultat devient exact — non parce que le modèle a progressé en arithmétique, mais parce qu’il a délégué.

Ce que cela débloque

Le raisonnement se généralise à tout ce que Claude ne peut pas faire seul. Les calculs mathématiques précis en sont le cas d’école. L’accès à des données en temps réel — météo, cours boursiers — en est un autre, puisque aucune connaissance figée ne peut couvrir ce qui change chaque minute. L’interaction avec vos bases de données ou vos API entre dans la même catégorie : votre catalogue produits n’a jamais fait partie de l’entraînement du modèle, et un outil est le moyen de l’y amener.

Cette leçon ne fait qu’ouvrir le sujet. Le tool use est couvert en détail dans un cours dédié plus avancé, où l’on aborde les outils multiples, les appels successifs et la gestion des erreurs d’exécution. L’essentiel à retenir ici est le partage des rôles : le modèle formule l’intention, votre code garde la main sur l’action.