Gérer les réponses Tool Use

Fonction prête, schéma prêt : envoyons le tout à l’API et regardons ce qui revient. Quand Claude décide d’utiliser un outil, il renvoie une structure de réponse spéciale qui nécessite un traitement soigneux — c’est elle qu’il faut apprendre à lire avant d’écrire la moindre boucle d’exécution.

Configuration du choix d’outil (toolChoice)

Premier réglage à connaître : le paramètre toolChoice offre trois options pour contrôler quand Claude utilise les outils :

La troisième option est particulièrement utile pour les tests : forcer l’appel de votre nouvel outil garantit d’exercer le chemin de code que vous venez d’écrire, sans dépendre de l’humeur du routage. Elle resservira aussi, plus tard, pour l’extraction de données structurées.

Structure de message multi-parties

Posez une question qui appelle l’outil — « quelle heure est-il ? » — et inspectez la réponse. Quand Claude veut utiliser un outil, il renvoie un message assistant avec plusieurs parties de contenu :

1. Partie texte : explication en langage naturel, par exemple « Je peux vous aider à trouver l’heure actuelle. »
2. Partie ToolUse : données structurées indiquant quel outil exécuter et avec quels arguments

Les deux parties ont des destinataires différents : le texte est pour l’humain — votre interface peut l’afficher pendant que l’outil travaille —, la partie ToolUse est pour votre code.

Contenu de la partie ToolUse

• toolUseId : identifiant unique nécessaire pour renvoyer le résultat
• name : nom exact de l’outil (tel que défini dans votre schéma JSON)
• input : dictionnaire d’arguments que Claude veut passer à votre fonction

Le toolUseId mérite un arrêt : c’est la clé d’appariement du protocole. Quand vous renverrez le résultat, c’est cet identifiant qui dira à Claude quel appel il conclut — indispensable dès que plusieurs outils sont demandés dans une même réponse.

Flux conversationnel avec les outils

Situons la réponse dans le déroulé complet. Le pattern est : message utilisateur, réponse assistant avec demande d’outil, message utilisateur avec résultat d’outil, réponse finale de l’assistant. L’historique complet des messages doit être maintenu à chaque étape — y compris les parties ToolUse dans les messages assistant : les supprimer briserait les références des résultats à venir.

Mise à jour des fonctions utilitaires

Nos utilitaires manipulaient des chaînes ; ils doivent maintenant accepter des listes de parties. Rendez-les flexibles :

def add_user_message(messages, content):
    if isinstance(content, str):
        user_message = {"role": "user", "content": [{"text": content}]}
    else:
        user_message = {"role": "user", "content": content}
    messages.append(user_message)

def add_assistant_message(messages, content):
    if isinstance(content, str):
        assistant_message = {"role": "assistant", "content": [{"text": content}]}
    else:
        assistant_message = {"role": "assistant", "content": content}
    messages.append(assistant_message)

Le test isinstance fait le tri : une chaîne est emballée comme avant, une liste de parties passe telle quelle. L’appelant n’a plus à se soucier du format — l’historique accepte tout ce que la conversation produit.

Mettez également à jour votre fonction chat pour renvoyer le texte et la liste complète des parties :

def chat(messages, system=None, temperature=1.0, stop_sequences=[], tools=None):
    # ... code existant ...

    response = client.converse(**params)

    text = response["output"]["message"]["content"][0]["text"]
    parts = response["output"]["message"]["content"]

    return text, parts

Le retour double est la clé : le texte pour l’affichage, mais surtout parts — la réponse brute, avec ses éventuelles parties ToolUse — car c’est elle que la suite du pipeline devra archiver et traiter. Ne renvoyer que le texte, comme avant, jetterait précisément l’information qui pilote le Tool Use.

Vérifier la raison d’arrêt

Dernier réflexe à installer : vérifiez toujours le champ stopReason dans la réponse de Claude. Quand il vaut "tool_use", Claude ne vous donne pas une réponse — il attend un résultat d’outil pour continuer. C’est votre signal pour extraire les informations de la partie ToolUse et exécuter la fonction demandée : exactement le travail de la prochaine leçon.

Points clés à retenir

• toolChoice : auto (défaut), any, ou outil forcé — ce dernier précieux pour tester vos outils
• Une réponse à outil est multi-parties : texte pour l’humain, ToolUse (id, nom, arguments) pour votre code
• Le toolUseId appariera résultat et demande — conservez-le précieusement
• Utilitaires flexibles (chaîne ou parties) et chat qui renvoie texte + parties brutes
• stopReason == "tool_use" = Claude attend un résultat, pas une nouvelle question