Introduction au Tool Use

Nouvelle section, et un cap majeur du cours : les outils (tools) permettent à Claude d’accéder à des informations du monde extérieur, résolvant l’une de ses limitations les plus fondamentales. Par défaut, Claude n’a accès qu’aux informations sur lesquelles il a été entraîné — un savoir figé à sa date de coupure. Il ne peut pas fournir d’informations en temps réel comme la météo actuelle ou les dernières nouvelles, et encore moins consulter vos bases de données internes. Les outils lèvent ce mur, et transforment un générateur de texte en brique d’application connectée.

Comment fonctionne le Tool Use

Le processus suit un flux spécifique impliquant plusieurs allers-retours entre votre serveur et Claude :

1. Requête initiale : vous envoyez à Claude une question accompagnée d’instructions sur comment obtenir des données supplémentaires
2. Demande d’outil : Claude analyse la question et demande des données externes spécifiques
3. Récupération des données : votre serveur exécute du code pour récupérer les informations demandées
4. Réponse finale : Claude utilise les données externes pour fournir une réponse complète et informée

L’étape 3 corrige d’emblée l’intuition la plus répandue : Claude n’exécute jamais rien lui-même. Il formule une demande structurée — quel outil, quels arguments — et c’est votre code qui effectue réellement l’opération avant de lui renvoyer le résultat. Cette répartition n’est pas un détail d’implémentation, c’est la propriété de sécurité centrale du mécanisme : vous décidez quels outils existent, ce qu’ils acceptent, et ce qu’ils refusent.

Exemple concret : la météo

Déroulons le flux sur le cas d’école. Quand un utilisateur demande la météo, vous incluez dans votre requête initiale à Claude les détails sur comment récupérer les données météo actuelles. Claude reconnaît qu’il a besoin d’informations météo en temps réel et demande à votre serveur de les obtenir. Votre serveur appelle une API météo, récupère les données en direct, et les renvoie à Claude. Finalement, Claude combine la question originale avec les données fraîches pour fournir une réponse précise et actuelle — « 14 degrés et couvert à Paris », au lieu d’un « je n’ai pas accès à la météo » ou, pire, d’une température inventée.

Défis d’implémentation

Un avertissement honnête avant de plonger : le Tool Use peut paraître déroutant, non parce qu’il est difficile, mais parce qu’il y a un décalage entre le flux logique et la façon dont vous écrivez le code. L’implémentation ne suit pas le même ordre que les étapes conceptuelles.

En pratique, vous devez :

1. Écrire la fonction outil en premier
2. Créer une spécification de schéma JSON
3. Gérer les parties ToolUse et ToolResult
4. Inclure le schéma avec votre requête

Autrement dit, on construit d’abord la fin de la chaîne (la fonction qui s’exécutera à l’étape 3 du flux), puis sa description, puis la plomberie des échanges — alors que l’exécution commencera par la requête initiale. Cette navigation entre différentes parties de l’implémentation est la raison pour laquelle le Tool Use semble complexe au début. La clé est de comprendre que chaque étape du flux logique nécessite des composants de code spécifiques, que vous construirez dans un ordre différent de celui dans lequel ils s’exécutent — et c’est exactement le programme des prochaines leçons : fonctions d’abord, schémas ensuite, boucle de conversation enfin.

Points clés à retenir

• Les outils donnent à Claude l’accès au monde extérieur : temps réel, systèmes internes, actions
• Flux en quatre temps : question + outils → demande d’outil → exécution par votre code → réponse informée
• Claude ne fait que demander : votre code exécute — vous gardez le contrôle total du périmètre
• L’ordre d’implémentation (fonction → schéma → plomberie) diffère de l’ordre d’exécution : c’est normal
• Les prochaines leçons construisent chaque composant sur le projet fil rouge du système de rappels