Utiliser plusieurs outils

La boucle multi-tours de la leçon précédente a coûté un vrai effort de conception — mais c’était un investissement, et cette leçon en touche les dividendes. Une fois cette infrastructure en place, ajouter un outil supplémentaire ne demande plus que quelques lignes à des endroits bien identifiés : la boucle, elle, ne change jamais. C’est le signe d’une architecture réussie : le coût du premier outil est élevé, celui du dixième est marginal.

Les trois outils du système de rappels

Pour le démontrer, transformons notre démo en embryon de système de rappels, avec trois outils complémentaires :

1. get_current_datetime : connaître la date et l’heure
2. add_duration_to_datetime : calculer les dates futures
3. set_reminder : programmer un rappel

Remarquez la complémentarité : aucun de ces outils ne suffit seul à traiter une demande réelle (« rappelle-moi dans trois jours »), mais leur combinaison couvre le parcours complet — savoir quand on est, calculer une échéance, agir dessus. C’est un pattern général : on conçoit rarement un outil isolé, on conçoit une petite boîte à outils dont Claude composera les pièces.

Ajouter les outils à la conversation

Premier point de branchement : la liste tools passée à l’API s’allonge.

response = chat(messages, tools=[
    get_current_datetime_schema,
    add_duration_to_datetime_schema,
    set_reminder_schema
])

Claude reçoit désormais les trois schémas à chaque requête et choisit librement lequel appeler, dans quel ordre, ou aucun. Ce choix repose entièrement sur les descriptions rédigées dans les schémas — c’est ici que le soin mis à les écrire (leçon 24) paie : des descriptions qui se chevauchent ou restent vagues produisent des appels erratiques, des descriptions nettes produisent un routage fiable. Gardez aussi en tête que chaque schéma ajouté est envoyé avec chaque requête et consomme des tokens d’entrée : une boîte à outils se garde ciblée.

Mettre à jour le routage

Second point de branchement : la fonction run_tool, qui fait le lien entre le nom demandé par Claude et la fonction Python réelle.

def run_tool(tool_name, tool_input):
    if tool_name == "get_current_datetime":
        return get_current_datetime(**tool_input)
    elif tool_name == "add_duration_to_datetime":
        return add_duration_to_datetime(**tool_input)
    elif tool_name == "set_reminder":
        return set_reminder(**tool_input)

La syntaxe **tool_input mérite un arrêt : les arguments générés par Claude arrivent sous forme de dictionnaire, et le double astérisque les déballe en arguments nommés — le dictionnaire {"date_format": "%H:%M"} devient l’appel get_current_datetime(date_format="%H:%M"). C’est ce qui permet à run_tool de rester générique sans connaître la signature de chaque fonction. Dans une version durcie, on ajouterait une branche finale qui retourne un message d’erreur explicite pour un nom d’outil inconnu — renvoyé à Claude, il lui permettrait de se corriger au lieu de faire échouer silencieusement le tour.

Test avec une requête complexe

L’intérêt de la boucle se révèle sur une demande qui exige un enchaînement : « Programme un rappel pour mon rendez-vous chez le médecin. C’est 177 jours après le 1er janvier 2050. »

1. Claude utilise add_duration_to_datetime pour calculer le 27 juin 2050
2. Claude appelle set_reminder avec la date calculée

Personne n’a écrit ce plan : Claude l’a déduit de la demande et des descriptions d’outils. Le second appel dépend du résultat du premier — la date calculée devient l’argument du rappel — et c’est précisément ce que notre boucle multi-tours autorise : à chaque tour, le modèle voit les résultats précédents et décide de la suite, jusqu’à pouvoir répondre.

Processus en trois étapes pour ajouter un outil

Le rituel d’extension du système tient désormais en trois gestes :

1. Ajouter le schéma dans la liste tools de run_conversation
2. Ajouter un cas dans la fonction run_tool
3. Implémenter la fonction d’outil elle-même

Rien d’autre ne bouge — ni la boucle, ni la gestion des messages, ni le traitement des erreurs. C’est cette stabilité qui rend l’approche viable en production, où les boîtes à outils comptent vite des dizaines d’entrées.

Points clés à retenir

• L’infrastructure multi-tours ne s’écrit qu’une fois : chaque outil supplémentaire ne coûte que trois petits ajouts
• Les outils se conçoivent en boîte cohérente — Claude compose leurs appels pour couvrir la demande
• Le choix d’outil repose sur les descriptions des schémas : nettes = routage fiable, vagues = appels erratiques
• **tool_input déballe le dictionnaire d’arguments généré par Claude en arguments nommés
• Sur une demande complexe, Claude chaîne seul les appels, chaque appel pouvant dépendre du résultat du précédent