Tools et function calling : donner des mains à votre agent

# 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 admettre qu'il ne sait pas. 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 la donne. Un tool est une fonction que votre agent peut appeler : une consultation météo, une requête en base, une action « envoyer un email », une calculatrice. Vous décrivez le tool, le modèle décide quand l'utiliser, et voilà votre agent doté de mains.

Ce qu'est réellement un « tool »

Un tool (aussi appelé function dans ce contexte) est un morceau de code que vous avez 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 d'énoncer « 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 lui semble utile, dit : « Appelle 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* doit appeler le tool.

La boucle requête-réponse

Voici l'idée centrale, plus simple qu'il n'y paraît. Le modèle et vous jouez à tour de rôle.

1. Vous envoyez le message de l'utilisateur plus la liste des tools disponibles.

2. Le modèle répond de deux manières 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 répond à l'utilisateur ou demande un autre tool.

Cette boucle se répète jusqu'à ce que le modèle ait ce qu'il lui faut. Cet aller-retour, c'est ce qu'on appelle le function calling ou 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 (il me faut des données live), vous avez fait le travail (appelé 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 →), et le modèle a transformé le résultat brut en réponse utile.

Une esquisse de code indépendante du fournisseur

Les noms de fonctions diffèrent selon le fournisseur, mais la forme reste la même. Voici la boucle en pseudo-Python, telle qu'elle fonctionne dans tous les SDK majeurs :

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éinjecter le vrai résultat dans la conversation
        messages.append(response.as_message())
        messages.append({
            "role": "tool",
            "name": call.name,
            "content": result
        })
        continue        # reboucler pour que le modèle utilise le résultat

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

Relisez la boucle. Le while True est toute l'astuce : continuer tant que le modèle réclame 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 (retrouver un client, vérifier ses commandes, rédiger une réponse), c'est 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 contre tools frustrants

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

Rédigez les descriptions comme un briefing à une nouvelle recrue

Vague :

> search : cherche des choses

Clair :

> search_help_articles : cherche 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 interne.

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

Gardez des 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 réellement lire

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

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

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

Les tools courants que vous construirez vraiment

Une fois la boucle assimilée, vous voyez des tools partout. Quelques schémas présents dans presque tous les agents réels :

• Retrieval : chercher dans une base de connaissances, retrouver 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 support, rembourser une commande. Elles *changent* quelque chose, donc traitez-les avec précaution (voir plus bas).
• Calcul : une calculatrice, un convertisseur de devises, un utilitaire de calcul de dates. Les modèles sont notoirement instables 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 « router » décide quel tool spécialisé ou sous-agent doit traiter une demande.

Tools en lecture seule contre tools d'action

Il y a une vraie différence entre un tool qui *lit* (get weather, chercher des articles) et un tool qui *agit* (envoyer un email, débiter une carte).

Les tools de lecture sont peu risqués : au pire, l'agent consulte une information dont il n'avait pas besoin. 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 envoi, limiter ce que le tool peut toucher, ou logger chaque appel. Un tool « send refund » devrait sans doute plafonner le montant et faire valider par un humain tout ce qui est important.

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 exigent un humain dans la boucle.

La place des fournisseurs

Tous les grands fournisseurs supportent ce même schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → de tool calling, et chacun livre un agent SDK de plus haut niveau (une boîte à outils logicielle qui exécute la boucle à votre place, pour ne pas é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, parser 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 dernière chose à connaître : il existe un standard ouvert en pleine croissance, 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 de partager des tools entre systèmes.

Points clés

• Un tool est votre code, décrit pour le modèle. Donnez-lui un nom clair, une description en langage courant 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 ; c'est votre code qui l'exécute.
• Tout le moteur est une boucle. Envoyer le message plus 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 briefing. 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) exige un garde-fou : confirmation, limites ou logging.
• Commencez par le concept, puis choisissez un SDK. L'OpenAI Agents SDK, le Claude Agent SDK et le Google ADK exécutent tous cette même boucle pour vous, et MCP permet de réutiliser un même tool avec tous.