Tool calling : comment les agents IA utilisent des outils

Qu'est-ce que le tool calling ?

Le tool calling (aussi appelé function calling ou tool use) est la capacité clé qui permet à un agent IA d'aller au-delà de la simple génération de texte. Le LLM reçoit des descriptions lisibles par machine d'outils, de fonctions, d'API et de sources de données, et génère au besoin un appel structuré avec des paramètres, que l'application environnante exécute. Le résultat revient au modèle sous forme d'observation, et celui-ci planifie l'étape suivante. Le LLM passe ainsi du statut de générateur de texte à celui d'acteur capable d'agir.

Les trois réponses essentielles d'emblée :

• Que se passe-t-il techniquement ? Le modèle ne renvoie pas du texte continu, mais un appel structuré : un nom de fonction et des arguments au format JSON. L'application exécute cet appel et renvoie le résultat au modèle.
• Qui appelle réellement ? Pas le LLM lui-même. Le modèle propose un appel ; l'exécution effective, y compris le contrôle des droits et la validation, relève du code environnant. Cette séparation est le fondement de toute architecture de sécurité.
• Pourquoi est-ce la capacité clé des agents ? Sans tool use, un LLM reste un conseiller qui ne sait que parler. Seul le tool calling transforme le moteur de raisonnement en agent qui perçoit, planifie, agit et observe : la boucle complète Perceive → Reason → Act → Observe.

Un exemple concret : vérifier les disponibilités et réserver un créneau

Imaginons qu'un agent doive réserver une séance de conseil pour un client. Le modèle dispose de deux outils, chacun avec un nom, une description et un schéma de paramètres :

1. get_availability(date: string) : renvoie les créneaux libres pour une date.
2. book_appointment(slot_id: string, customer_email: string) : réserve un créneau.

Le déroulement :

1. Reason : L'utilisateur écrit « Reste-t-il un créneau libre mardi prochain dans la matinée ? ». Le modèle comprend qu'il a d'abord besoin des disponibilités.
2. Act : Au lieu d'une réponse textuelle, le modèle renvoie un appel structuré : get_availability(date: "2026-06-16").
3. Execute : C'est l'application, et non le modèle, qui appelle la véritable API du calendrier et reçoit deux créneaux libres.
4. Observe : Le résultat (["09:00", "10:30"]) est renvoyé au modèle sous forme d'observation.
5. Loop : Le modèle pose une question de suivi ou, après confirmation, appelle book_appointment(...).

Important : l'étape d'écriture (book_appointment) est irréversible dans ses effets. C'est précisément ici qu'il faut une étape human-in-the-loop ou de confirmation avant que l'agent n'exécute l'action.

La mécanique du function calling

Dans toutes les API de LLM courantes, le function calling suit le même schéma de base, quel que soit le fournisseur :

1. Définition de l'outil : Chaque outil est décrit par un JSON Schema : son nom, une description en langage naturel de sa finalité et ses paramètres typés. Cette description est la seule information sur laquelle le modèle s'appuie pour décider si et comment il utilise l'outil.
2. Sélection de l'outil : Lors de l'étape de raisonnement, le modèle choisit l'outil adapté et renseigne les paramètres. Il s'appuie pour cela uniquement sur les descriptions fournies et sur le contexte de la conversation.
3. Sortie structurée : Au lieu de prose, le modèle fournit un objet lisible par machine. Si un mode strict ou les Structured Outputs sont activés, le fournisseur impose par constrained decoding que les arguments respectent le schéma. Sans ce mode, le modèle peut générer des arguments invalides. Dans les deux cas, l'exécuteur valide les paramètres, car des arguments conformes au schéma ne garantissent ni des valeurs admissibles ni les droits nécessaires.
4. Exécution & observation : L'appel est exécuté, le résultat renvoyé, et la boucle continue jusqu'à ce que l'objectif soit atteint ou qu'un critère d'arrêt (limite d'itérations, erreur, guardrail) se déclenche.

Le principal enseignement pratique : quand un agent agit de travers, la cause se trouve généralement non pas dans le modèle, mais dans la définition de l'outil. Anthropic formule la règle sans détour : si un ingénieur humain ne peut pas dire clairement quel outil utiliser dans une situation donnée, un agent ne le peut pas non plus.

Il en découle trois règles de conception :

• Limiter le nombre d'outils : En 2026, la bonne pratique consiste à charger activement 3-7 outils ; à partir d'environ 10 outils, le choix de l'outil se dégrade de façon mesurable. Dans les évaluations MCP internes d'Anthropic, la recherche dynamique d'outils a fait passer la précision de sélection des outils de 49 % à 74 % (Opus 4) et de 79,5 % à 88,1 % (Opus 4.5).
• Éviter les chevauchements : Deux outils qui pourraient plausiblement répondre à la même requête posent un problème qu'aucun prompt ne résout. Une clause claire « quand ne pas l'utiliser » dans la description est l'élément le plus efficace, et souvent oublié.
• Des noms et des paramètres sans ambiguïté : Des noms parlants et des paramètres au typage strict réduisent les erreurs d'interprétation avant qu'elles ne surviennent.

Le lien avec MCP : un standard pour connecter les outils

Sans standard, chaque intégration d'outil doit être câblée séparément, avec du code d'intégration spécifique par agent, par API et par source de données. Le Model Context Protocol (MCP) résout ce problème M×N : il définit un protocole unifié par lequel un agent (client MCP) communique de manière standardisée avec des outils et des sources de données (serveurs MCP).

MCP est donc le « comment » derrière le tool calling, dès que les outils ne résident plus dans son propre code, mais sont mis à disposition sous forme de serveurs réutilisables. Un serveur MCP fournit des outils, des ressources et des prompts ; l'agent les découvre à l'exécution et les appelle selon le même schéma de function calling. Le niveau de maturité est élevé : la spécification MCP actuelle porte la version 2026-07-28 et fonctionne avec des requêtes sans état et autonomes. En décembre 2025, le projet a été confié à la Linux Foundation (Agentic AI Foundation), et il existe déjà plus de 10 000 serveurs MCP.

Alors que MCP standardise la connexion agent ↔ outil, le protocole complémentaire A2A (Agent-to-Agent) régit la communication agent ↔ agent dans les systèmes multi-agents. Depuis juin 2025, A2A relève lui aussi de la Linux Foundation et est soutenu par plus de 150 organisations. Pour le tool calling pur, MCP est le standard pertinent ; A2A ne devient important que lorsque plusieurs agents collaborent.

Sécurité : les permissions des outils sont une obligation, pas une option

Dès qu'un agent touche des systèmes réels (écrire dans des bases de données, envoyer des e-mails, exécuter du code), la sécurité des outils devient l'exigence centrale. La bonne nouvelle : comme le LLM se contente de proposer les appels et que le code environnant les exécute, le point de contrôle se trouve exactement là où il doit être.

Trois écueils pratiques sont particulièrement fréquents : traiter les agents comme déterministes alors que le choix de l'outil est probabiliste ; ne pas mettre en place d'observabilité, si bien que les erreurs de la boucle restent invisibles ; et ne pas prévoir de human-in-the-loop pour les actions irréversibles. Dans les contextes sensibles à la conformité s'ajoute un point : les actions d'écriture sur des données personnelles relèvent des obligations du RGPD, et les décisions automatisées produisant des effets juridiques peuvent tomber sous le coup de l'article 22 du RGPD (à titre informatif, ceci ne constitue pas un conseil juridique).

Conclusion

Le tool calling est le mécanisme qui transforme un LLM en agent : le modèle propose des appels structurés, le code les exécute, le résultat détermine l'étape suivante. La qualité se joue à trois niveaux : des définitions d'outils précises et sans chevauchement, un ensemble d'outils actifs restreint (3-7) avec découverte dynamique, et une architecture de sécurité fondée sur le moindre privilège, la validation, les étapes de confirmation et l'observabilité. MCP fournit pour cela le standard ouvert qui fait passer la connexion des outils d'intégrations isolées à des serveurs réutilisables. Si tu maîtrises ces bases, tu construis des agents qui agissent en production de manière fiable et contrôlée.