Le simulateur de tool calling
Déroulez pas à pas la boucle tool_use : le message utilisateur part vers le modèle,
le modèle émet un bloc
tool_use (une demande, pas une action !),
votre code exécute l'appel réel, renvoie un tool_result, et le modèle produit sa réponse finale.
⭐ « Le modèle n'exécute jamais rien. Il émet une requête structurée.
Votre code exécute l'appel réel — avec vos autorisations, votre validation, votre journalisation. »
🙋Message
utilisateur
utilisateur
🧠Le modèle
réfléchit
réfléchit
📨Bloc
tool_use
tool_use
🔧Votre code
exécute
exécute
📬tool_result
renvoyé
renvoyé
💬Réponse
finale
finale
Choisissez un scénario puis cliquez sur « Étape suivante ». Chaque étape est commentée ici.
L'atelier : construisez une définition d'outil
Une définition d'outil comporte trois éléments : un name, une description
(qui est un prompt : le modèle route en la lisant !) et un input_schema
(JSON Schema — norme de description de structures JSON).
Glissez-déposez les pièces de gauche dans les emplacements de droite. Attention : certaines pièces sont des pièges — l'atelier vous le dira.
Glissez-déposez les pièces de gauche dans les emplacements de droite. Attention : certaines pièces sont des pièges — l'atelier vous le dira.
Objectif : l'outil 🗄️ chercher_client
3 règles : une chose · nom clair · cas limites documentés
🧰 Pièces disponibles
Astuce : lisez chaque pièce comme le ferait le modèle. Laquelle vous permettrait de bien router ?
🏗️ Votre définition d'outil
name — l'identifiant technique
description — le mode d'emploi (c'est un prompt !)
input_schema — les paramètres (plusieurs pièces possibles)
Aperçu JSON en direct
{ }
Check-list sécurité : avant d'exposer un outil
Le principe du moindre privilège (principle of least privilege) : n'exposer que les outils
dont l'agent a strictement besoin. Chaque outil est une porte que vous ouvrez —
passez cette check-list pour chaque outil, avant toute mise en production.
Cliquez sur un item pour le valider (et lire pourquoi il compte).