Appel d'outils

Le mécanisme qui permet à un modèle de langage d'émettre des requêtes structurées pour faire exécuter du code, interroger des bases de données ou consulter des API externes.

6 min de lecture

#écosystème
#API
#JSON
#agent

En une phrase

L’appel d’outils est le mécanisme par lequel un modèle de langage formule une demande textuelle structurée (comme du code JSON) pour confier une action concrète à un programme externe au lieu de deviner la réponse.

L’analogie

Imagine un architecte enfermé dans un bureau sans fenêtre ni téléphone. S’il doit calculer la résistance d’une poutre complexe ou connaître la météo prévue demain sur le chantier, il est physiquement incapable de mesurer lui-même la température ou de faire tourner une simulation 3D.

En revanche, il dispose d’un carnet de formulaires standardisés. Sur l’un d’eux, il inscrit méticuleusement les paramètres nécessaires : « Formulaire Météo : Ville = Marseille, Date = Demain ». Il glisse cette feuille sous la porte. De l’autre côté, son assistant de bureau prend la feuille, consulte un baromètre réel, note la valeur mesurée sur le papier, et reglisse le formulaire sous la porte. L’architecte lit le chiffre certifié et peut alors finaliser ses plans en toute confiance.

L’appel d’outils fonctionne exactement ainsi : le modèle de langage est l’architecte enfermé. Il ne dispose d’aucun accès direct aux réseaux ou aux ordinateurs. Il se contente de remplir un formulaire textuel strict que l’application hôte lit et exécute pour lui.

Comment ça marche

Un modèle de langage autorégressif ne possède aucun bras mécanique, aucun socket réseau et aucune capacité innée à exécuter du code. Par nature, son unique pouvoir consiste à prédire des jetons statistiques les uns après les autres. Pour lui permettre d’interagir avec le monde réel, les concepteurs de systèmes d’IA ont mis au point un protocole d’échange rigoureux fondé sur des formats de données standardisés.

La description des outils disponibles

Avant même que tu ne poses ta première question, l’application qui héberge le modèle injecte dans l’invite système une liste d’outils autorisés. Chaque outil est décrit au moyen d’un schéma formel, généralement standardisé au format JSON Schema.

Ce schéma documente précisément :

Le nom unique de la fonction (par exemple obtenir_meteo_actuelle).
Une description textuelle claire expliquant à quoi sert l’outil et dans quelles circonstances l’activer.
La liste des paramètres attendus, leur type informatique (chaîne de caractères, entier, booléen) et leur caractère obligatoire ou optionnel.

Par exemple, pour consulter la météo, le modèle reçoit la consigne qu’il existe une fonction prenant en paramètre obligatoire une ville sous forme de texte et une unité de température optionnelle. Le modèle n’apprend pas à coder cette fonction : il apprend simplement à reconnaître quand un problème humain exige son utilisation.

La décision d’interruption et l’émission structurée

Lorsque tu demandes : « Quel temps fait-il actuellement à Lyon et quel vêtement dois-je porter ? », le modèle commence sa passe avant habituelle.

Au lieu de tenter de prédire des jetons au hasard pour inventer la météo du jour (ce qui produirait une hallucination pure), les couches d’attention du modèle associent ta demande à la description de l’outil obtenir_meteo_actuelle. Le modèle prend alors la décision de suspendre la conversation naturelle.

Il émet des jetons spéciaux d’appel de fonction et rédige un objet structuré :

{
  "name": "obtenir_meteo_actuelle",
  "arguments": {
    "ville": "Lyon",
    "unite": "celsius"
  }
}

Dès que cet objet est refermé, le modèle s’arrête de générer et renvoie un signal d’interruption spécifique dans ses métadonnées, souvent nommé finish_reason: "tool_calls".

L’exécution par l’environnement hôte

C’est ici que réside la séparation fondamentale du système : le modèle de langage ne lance aucun appel réseau. C’est le programme hôte (le serveur de l’API, ton application Python ou ton environnement local) qui intercepte la réponse.

L’application hôte lit le texte JSON émis, vérifie sa validité syntaxique, extrait les arguments et déclenche le véritable code informatique :

Elle interroge l’API d’un service météorologique réel avec les arguments fournis.
Elle reçoit les données brutes authentifiées (par exemple : { "temperature": 14, "condition": "pluie battante" }).
Elle encapsule cette observation brute dans un nouveau message portant le rôle technique tool.

La réinjection et la synthèse finale

Le programme hôte renvoie alors l’ensemble de la conversation augmentée au modèle de langage : ton message initial, l’appel de fonction émis par le modèle, et la réponse factuelle renvoyée par le capteur externe.

Le modèle effectue une seconde passe d’inférence. Il lit la réponse technique fournie par l’outil comme s’il s’agissait d’un fait avéré placé dans sa mémoire de travail. Il peut désormais reprendre sa liberté rédactionnelle pour répondre à ta demande initiale : « Il fait actuellement 14 °C à Lyon sous une pluie battante. Je te conseille vivement de prendre un imperméable et un parapluie avant de sortir. »

Dans la vraie vie

L’appel d’outils transforme un simple générateur de prose en un moteur décisionnel capable d’agir sur son environnement numérique.

On le retrouve dans une multitude d’applications quotidiennes :

Recherche documentaire et navigation web : Lorsque tu interroges un assistant sur un événement qui s’est produit ce matin, le modèle formule un appel vers un moteur de recherche web, lit les premiers extraits de pages et t’en fait la synthèse avec des sources à jour.
Interprétation de code et mathématiques : Face à une équation différentielle complexe ou à un calcul financier lourd, le modèle écrit un script Python court et appelle un interpréteur sécurisé (sandbox). Il lit le résultat exact du calcul plutôt que d’effectuer des multiplications approximatives dans ses poids.
Gestion d’agendas et d’e-mails : Un assistant personnel peut vérifier tes disponibilités sur Google Calendar, créer un rendez-vous le mardi suivant à 14 heures et t’envoyer un e-mail de confirmation via des connecteurs d’outils dédiés.
Connexion aux bases de données d’entreprise : Un modèle peut traduire une question en langage naturel (« Quels sont nos cinq clients les plus actifs ce mois-ci ? ») en une requête SQL valide, la confier au serveur de base de données et commenter les résultats obtenus pour la direction.

Idées reçues

« Le modèle de langage se connecte directement à Internet ou à ma base de données lorsqu’il utilise un outil. » C’est rigoureusement faux. Un modèle de langage ne possède aucun accès matériel ou réseau ; il ne fait qu’émettre une chaîne de caractères textuelle que le logiciel hôte choisit ou non d’exécuter.
« L’appel d’outil garantit que le modèle ne produira aucune erreur dans les paramètres demandés. » Même avec un schéma JSON strict, le modèle peut halluciner un nom de paramètre inexistant, inverser deux dates ou inventer un identifiant client fictif. L’application hôte doit systématiquement valider la charge utile avant toute exécution.
« L’appel d’outil est une fonctionnalité magique réservée aux modèles géants propriétaires. » De nombreux modèles légers et ouverts sont aujourd’hui spécifiquement entraînés avec des jetons spéciaux d’appel d’outils, permettant de déclencher des fonctions fiables sur un simple ordinateur portable.

Pour aller plus loin

Toolformer: Language Models Can Teach Themselves to Use Tools — Timo Schick et al., 2023 (EN) : Le papier de recherche fondateur démontrant comment un modèle apprend par lui-même à identifier le bon moment pour solliciter une calculatrice ou un moteur de recherche.
Appel d’outils et assistants conversationnels — Mistral AI, 2024 (FR) : Documentation et annonces détaillant la prise en charge native des jetons d’appel de fonctions dans les modèles francophones ouverts.
Gorilla: Large Language Model Connected with Massive APIs — Shishir G. Patil et al., 2023 (EN) : Une étude approfondie sur la capacité des modèles à choisir le bon outil parmi des milliers d’API documentées sans se tromper de schéma.