Introduction à l'utilisation d'outils

Tout ce que Claude sait, il l’a appris pendant son entraînement — et son savoir s’arrête là. Pas de météo du jour, pas de cours de bourse, pas d’accès à votre base de données clients. Les outils lèvent cette limite : ils permettent à Claude d’accéder à des informations du monde extérieur, au-delà de ce qu’il a appris. C’est la fonctionnalité qui transforme un générateur de texte en brique d’application — et le sujet de toute cette section.

Le problème sans outils

Quand un utilisateur demande « Quel temps fait-il à Paris ? », Claude n’a d’autre choix honnête que de répondre qu’il n’a pas accès aux données météo en temps réel. Frustrant pour l’utilisateur — et pourtant préférable à l’alternative, qui serait d’inventer une température plausible. Le même mur se dresse devant toutes les questions dont la réponse vit hors du modèle : l’état d’une commande, le solde d’un compte, le contenu d’un document interne. Or ce sont précisément les questions qu’une application réelle reçoit à longueur de journée.

Comment fonctionne le tool use

L’idée centrale tient en une phrase : votre code exécute, Claude décide. Le tool use suit un schéma d’échanges précis :

1. Requête initiale : vous envoyez la question de l’utilisateur avec des instructions sur les sources de données externes disponibles
2. Demande d’outil : Claude analyse la question et décide qu’il a besoin d’informations supplémentaires, puis demande des données spécifiques
3. Récupération des données : votre serveur exécute le code pour récupérer les informations auprès d’API ou bases de données externes
4. Réponse finale : vous renvoyez les données à Claude, qui génère alors une réponse complète

Relisez l’étape 3, car elle corrige l’intuition la plus répandue : Claude n’exécute jamais rien. Il n’appelle pas l’API météo, ne se connecte pas à votre base — il émet une demande structurée (« appelle l’outil météo avec ville=Paris »), et c’est votre code qui exécute réellement l’opération, puis lui renvoie le résultat. Le modèle reste un cerveau sans mains ; vos outils sont les mains, et vous en gardez le contrôle total — c’est vous qui décidez quels outils exister, ce qu’ils acceptent, et ce qu’ils refusent.

Ce que cela débloque

Ce protocole en quatre temps ouvre quatre capacités qui changent la nature des applications possibles. Les informations en temps réel, d’abord : accéder à des données absentes de l’entraînement — météo, cours, actualités, état du système. L’intégration de systèmes externes, ensuite : connecter Claude à vos bases de données, vos API internes, vos services métier, et en faire une interface en langage naturel vers votre infrastructure. Les réponses dynamiques : au lieu d’un savoir figé à la date d’entraînement, des réponses fondées sur les informations les plus récentes, récupérées au moment de la question. Et enfin l’interaction structurée : grâce aux schémas d’outils que nous verrons bientôt, Claude sait exactement quelles informations demander et sous quelle forme — les échanges entre modèle et code suivent un contrat précis, pas du texte libre à parser.

Les prochaines leçons construisent ce mécanisme de bout en bout sur le projet de rappels : d’abord la fonction d’outil, puis son schéma, puis la boucle de conversation qui relie le tout.

Points clés à retenir

• Le savoir de Claude s’arrête à son entraînement : sans outils, pas de temps réel ni d’accès à vos systèmes
• Protocole en quatre temps : question + outils disponibles → demande d’outil → exécution par votre code → réponse finale
• Claude n’exécute jamais rien : il demande, votre code agit — vous gardez le contrôle total
• Les outils débloquent temps réel, intégration de systèmes, réponses à jour et échanges structurés
• La suite de la section implémente ce mécanisme pas à pas sur le projet de rappels