Tool calling : comment un agent IA appelle des outils externes

Sans tool calling, un modèle de langage ne sait faire qu'une chose : produire du texte à partir de texte. Il ne peut ni consulter une base de données à jour, ni envoyer un message, ni déclencher une action dans un logiciel tiers. Le tool calling est le pont qui relie un modèle à un système extérieur. C'est ce qui transforme un modèle qui discute en un agent IA capable d'agir, la brique de base derrière tout agent autonome.

Définition détaillée

Le tool calling, appelé aussi function calling, désigne la capacité d'un modèle de langage à répondre à une requête non pas uniquement par du texte, mais par une demande structurée d'exécuter une fonction précise, avec des arguments remplis selon un schéma défini à l'avance. La documentation d'Anthropic décrit le principe ainsi : le modèle détermine s'il doit appeler un outil en fonction de la requête et de la description de l'outil, puis renvoie un appel structuré que l'application exécute (côté client) ou que le fournisseur exécute lui-même (côté serveur, pour certains outils intégrés). La documentation d'OpenAI, qui a popularisé le terme function calling en 2023, décrit un mécanisme identique : le modèle répond avec un appel de fonction lisible par une machine plutôt qu'avec du texte libre, à charge pour l'application de l'exécuter.

Les deux fournisseurs de référence convergent sur la définition de fond : une fonction est décrite par un nom, une description en langage naturel, et un schéma JSON qui liste ses paramètres attendus. Le modèle s'appuie uniquement sur ces trois éléments pour décider s'il doit appeler l'outil et comment remplir ses arguments. Aucune divergence significative n'existe entre les deux approches sur ce principe de base ; les différences se situent dans les détails d'implémentation (formats d'appel parallèle, outils fournis nativement par le fournisseur, gestion des erreurs).

Le tool calling est ce qui distingue un simple chatbot d'un système capable d'agir sur le monde réel : consulter une base de données, chercher sur le web, écrire dans un fichier, envoyer un message, déclencher un paiement. C'est aussi la brique de base qui rend possible le protocole MCP, pensé pour standardiser la manière dont les outils sont décrits et exposés à un modèle.

Comment ça marche

Le déroulé d'un appel d'outil suit toujours le même schéma en plusieurs étapes. D'abord, l'application définit une liste d'outils disponibles pour le modèle, chacun avec son nom, sa description et son schéma d'arguments. Ensuite, le modèle reçoit la requête de l'utilisateur accompagnée de cette liste d'outils, et décide, en fonction du contexte, s'il doit répondre directement en texte ou demander l'exécution d'un outil.

S'il choisit d'appeler un outil, le modèle renvoie une réponse structurée qui contient le nom de l'outil et les valeurs de ses arguments, sans exécuter quoi que ce soit lui-même. C'est l'application qui reçoit cette demande, exécute réellement l'action (appeler une API, lire une base, écrire un fichier), puis renvoie le résultat au modèle sous une forme que celui-ci peut lire. Le modèle poursuit alors sa réponse en s'appuyant sur ce résultat, et peut enchaîner plusieurs appels d'outils successifs si la tâche le demande.

Ce découpage est important pour la sécurité : le modèle ne fait jamais tourner de code lui-même, il ne fait que proposer un appel. C'est l'application qui garde la main sur ce qui est réellement exécuté, et qui peut refuser un appel si les conditions ne sont pas réunies.

Exemple concret avec Atako

Chez Atako, le tool calling est au cœur du fonctionnement d'un agent. Chaque intégration connectée (Slack, Notion, GitHub, HubSpot, et une quarantaine d'autres) expose un ensemble d'actions précises, comme post_message sur Slack ou create_issue sur GitHub, que l'agent peut appeler quand il juge que la tâche le demande.

Mais chez Atako, un appel d'outil ne s'exécute jamais directement. Il passe d'abord par un contrôle de permission : la plateforme vérifie qu'un « grant » existe pour cet agent et cette connexion précise, que l'action demandée figure bien dans la liste d'actions autorisées de ce grant, et que la portée accordée (lecture seule ou lecture-écriture) couvre bien l'action en question. Si l'une de ces conditions n'est pas remplie, l'appel est refusé et l'échec est journalisé. Ce chemin de décision, agent qui propose un appel puis plateforme qui vérifie avant d'exécuter, est exactement la logique de sécurité que le tool calling permet de mettre en place : le modèle propose, l'infrastructure décide.

Erreurs fréquentes

Une erreur courante consiste à croire que le modèle exécute lui-même l'outil qu'il appelle. Ce n'est jamais le cas : le modèle produit une demande structurée, c'est toujours une application ou une plateforme qui exécute réellement l'action et qui peut, à tout moment, la refuser.

Deuxième erreur : penser que donner accès à un outil à un modèle revient à lui donner un accès total et illimité à ce service. Un système de tool calling bien conçu limite précisément les actions disponibles, avec des permissions par action et par portée, plutôt qu'un accès générique « tout ou rien ».

Troisième erreur : sous-estimer l'importance de la description de l'outil. Le modèle ne dispose que du nom, de la description et du schéma d'arguments pour décider quand et comment appeler un outil. Une description vague ou ambiguë produit des appels mal choisis ou des arguments incorrects, même avec un modèle performant.

Enfin, certains confondent tool calling et MCP. Le tool calling est le mécanisme de base, présent depuis 2023 chez les grands fournisseurs de modèles. MCP est un protocole plus récent qui standardise la façon dont les outils sont décrits et connectés à un modèle, pour éviter de redévelopper une intégration différente pour chaque outil et chaque fournisseur.