Tools et function calling : donner des mains à votre agent

Demandez à un modèle de langage « Quel temps fait-il à Tokyo en ce moment ? » et il fera l'une de ces deux choses : deviner, ou avouer qu'il n'en sait rien. Il n'a aucune fenêtre sur le monde extérieur. Il peut raisonner et écrire, mais il ne peut pas *chercher une information* ni *faire* quoi que ce soit.

Les tools changent cela. Un tool est une fonction que votre agent peut appeler : une consultation météo, une requête en base de données, une action « envoyer un email », une calculatrice. Vous décrivez le tool, le modèle décide quand l'utiliser, et votre agent a soudain des mains.

Ce qu'est réellement un « tool »

Un tool (aussi appelé function dans ce contexte) est un morceau de code que vous possédez déjà, emballé pour que l'IA puisse le demander.

Vous donnez trois choses au modèle :

• Un nom, comme get_weather.
• Une description en langage clair : ce qu'il fait et quand l'utiliser.
• Les paramètres qu'il accepte, décrits dans un format structuré appelé JSON Schema (une manière standard de préciser « ce champ est du texte, celui-là un nombre, celui-ci est obligatoire »).

Le modèle n'exécute jamais votre code. Il lit seulement ces descriptions et, quand cela paraît utile, dit : « Merci d'appeler get_weather avec city = Tokyo. » Votre programme exécute la vraie fonction et renvoie la réponse.

Voici une définition de tool concrète. Ce format est quasi identique chez OpenAI, Anthropic et Google :

{
  "name": "get_weather",
  "description": "Get the current weather for a city. Use this whenever the user asks about weather, temperature, or conditions.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "The city name, e.g. 'Tokyo' or 'Paris'"
      },
      "units": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "Temperature units"
      }
    },
    "required": ["city"]
  }
}

Remarquez tout ce que fait la description. « Use this whenever the user asks about weather » n'est pas de l'ornement. C'est une instruction. Le modèle la lit pour décider *s'il faut* appeler le tool.

La boucle requête-réponse

Voici l'idée centrale, plus simple qu'elle n'en a l'air. Le modèle et vous jouez à tour de rôle.

1. Vous envoyez le message de l'utilisateur ainsi que la liste des tools disponibles.
2. Le modèle répond de deux façons possibles : une réponse texte normale, ou une demande d'appel de tool (avec les arguments renseignés).
3. S'il demande un tool, votre code exécute la vraie fonction et renvoie le résultat.
4. Le modèle lit le résultat et soit répond à l'utilisateur, soit demande un autre tool.

Cette boucle se répète jusqu'à ce que le modèle ait ce qu'il lui faut. Ces allers-retours, c'est ce que l'on appelle le function calling ou le tool calling.

Déroulons un échange réel :

• Utilisateur : « Dois-je prendre un parapluie à Tokyo aujourd'hui ? »
• Modèle : (sans bavardage) « Appelle get_weather avec city='Tokyo'. »
• Votre code : appelle l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → météo, récupère {"condition": "rain", "temp_c": 14}.
• Vous renvoyez ce résultat.
• Modèle : « Oui, prenez un parapluie. Il pleut à Tokyo et il fait environ 14 °C. »

Le modèle a pris une décision (j'ai besoin de données en direct), vous avez fait le travail (appelé l'API), et le modèle a transformé le résultat brut en réponse utile.

Un squelette de code indépendant du fournisseur

Les noms de fonctions exacts diffèrent selon le fournisseur, mais la forme est toujours la même. Voici la boucle en pseudo-Python, qui reflète le fonctionnement de tous les grands SDK :

tools = [get_weather_definition]   # le JSON schema ci-dessus
messages = [{"role": "user", "content": "Umbrella in Tokyo today?"}]

while True:
    response = model.generate(messages=messages, tools=tools)

    if response.wants_tool_call:
        call = response.tool_call          # ex. get_weather(city="Tokyo")
        result = run_my_function(call.name, call.arguments)

        # réinjecte le vrai résultat dans la conversation
        messages.append(response.as_message())
        messages.append({
            "role": "tool",
            "name": call.name,
            "content": result
        })
        continue        # on reboucle pour que le modèle utilise le résultat

    # aucun tool nécessaire : on a une réponse finale
    print(response.text)
    break

Relisez la boucle. Le while True est toute l'astuce : continuer aussi longtemps que le modèle demande des tools, puis s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter quand il produit une réponse simple. Un agent capable d'appeler plusieurs tools à la suite (rechercher un client, puis vérifier ses commandes, puis rédiger une réponse) n'est que cette boucle exécutée quelques fois de plus.

Si vous voulez le standard sous-jacent à ces définitions de paramètres JSON, la documentation JSON Schema est la référence canonique et gratuite.

Bons tools et tools frustrants

Le modèle ne peut utiliser que ce que vous décrivez bien. La plupart des échecs d'agents remontent à des définitions de tools bâclées, pas à un modèle « bête ».

Rédigez les descriptions comme un brief à un nouvel arrivant

Vague :

search : cherche des choses

Clair :

search_help_articles : recherche dans la base de connaissances support interne les articles sur la facturation, les remboursements et les paramètres de compte. Renvoie les 3 articles les plus pertinents. À utiliser avant de répondre à toute question de politique.

La seconde version indique au modèle *ce qu'il y a dedans*, *ce qu'il récupère* et *quand y recourir*.

Gardez les paramètres serrés

Chaque paramètre optionnel est une occasion pour le modèle de se tromper. Utilisez enum (une liste fixe de valeurs autorisées) quand il n'y a que quelques options valides, comme ["celsius", "fahrenheit"]. Marquez les champs obligatoires comme obligatoires. Moins d'entrées, plus claires : moins d'erreurs.

Renvoyez des résultats que le modèle peut vraiment lire

Renvoyez des données propres et étiquetées :

{"condition": "rain", "temp_c": 14, "city": "Tokyo"}

et pas un mur de HTML brut ou un log de 500 lignes. Le modèle doit interpréter tout ce que vous renvoyez, donc facilitez-lui la tâche.

Les tools courants que vous construirez vraiment

Dès que la boucle devient évidente, vous voyez des tools partout. Quelques patterns présents dans presque tous les agents réels :

• Retrieval : chercher dans une base de connaissances, consulter un document, interroger une base de données. C'est ainsi que vous ancrez un agent dans *vos* données.
• Actions : envoyer un email, crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → un événement d'agenda, ouvrir un ticket de support, rembourser une commande. Elles *modifient* quelque chose, donc traitez-les avec soin (voir plus bas).
• Calcul : une calculatrice, un convertisseur de devises, un utilitaire de calcul de dates. Les modèles sont notoirement fragiles en arithmétique exacte, donc confier les maths à une vraie fonction est un gain de fiabilité rapide.
• Handoffs : appeler un autre agent ou un modèle spécialisé. En 2026 c'est courant : un agent « routeur » décide quel tool spécialisé ou quel sous-agent doit traiter une demande.

Tools en lecture seule et tools d'action

Il y a une vraie différence entre un tool qui *lit* (récupérer la météo, chercher des articles) et un tool qui *agit* (envoyer un email, débiter une carte).

Les tools de lecture présentent peu de risque : au pire, l'agent consulte une information inutile. Les tools d'action peuvent faire des dégâts si le modèle se trompe. Pour ceux-là, ajoutez un garde-fou : exiger une confirmation humaine avant l'envoi, limiter ce que le tool peut toucher, ou journaliser chaque appel. Un tool « envoyer un remboursement » devrait probablement plafonner le montant et demander l'approbation d'une personne pour tout montant élevé.

C'est une décision de conception, pas un détail de code. Décidez dès le départ quels tools votre agent peut déclencher seul et lesquels nécessitent un humain dans la boucle.

La place des fournisseurs

Tous les grands fournisseurs prennent en charge ce même pattern de tool calling, et chacun propose un agent SDK de plus haut niveau (une boîte à outils logicielle qui exécute la boucle pour vous, pour ne pas avoir à écrire le while True à la main) :

• OpenAI Agents SDK
• Claude Agent SDK (Anthropic)
• Google Agent Development Kit (ADK)

Ils gèrent la plomberie : transmettre les tools, analyser les tool calls, réinjecter les résultats. Le concept que vous venez d'apprendre est le socle des trois. Quand vous serez prêt pour la syntaxe propre à chaque fournisseur, consultez les blocs d'approfondissement dédiés.

Une autre chose à connaître : il existe un standard ouvert en plein essor, le Model Context Protocol (MCP), qui permet de définir un tool *une seule fois* et de le brancher sur des agents de différents fournisseurs. Voyez-le comme un adaptateur universel pour tools. D'ici 2026, c'est de plus en plus la manière par défaut dont les équipes partagent des tools entre systèmes.

À retenir

• Un tool, c'est votre code, décrit pour le modèle. Donnez-lui un nom clair, une description en langage simple et des paramètres typés (JSON SchemaSchemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète →). Le modèle demande l'appel ; votre code l'exécute réellement.
• Tout le moteur est une boucle. Envoyer le message et les tools, vérifier si le modèle veut un tool, l'exécuter, réinjecter le résultat, répéter jusqu'à obtenir une réponse simple.
• Rédigez les descriptions comme un brief. Indiquez ce que fait le tool, ce qu'il renvoie et quand l'utiliser. La plupart des échecs d'agents viennent de définitions de tools vagues, pas du modèle.
• Séparez les tools de lecture des tools d'action. Tout ce qui modifie le monde (envoyer, débiter, supprimer) a besoin d'un garde-fou : confirmation, limites ou journalisation.
• Commencez par le concept, puis choisissez un SDK. L'OpenAI Agents SDK, le Claude Agent SDK et Google ADK exécutent tous cette même boucle pour vous, et MCPMCPUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète → vous permet de réutiliser un même tool sur les trois.