L'appel d'outils : comment un LLM passe à l'action

Un modèle de langage, seul, ne sait faire qu’une chose : produire du texte. Il ne peut pas consulter ta base de données, envoyer un e-mail ni vérifier la météo. L’appel d’outils, qu’on appelle aussi function calling ou tool use, est exactement ce qui débloque tout le reste. C’est la première brique à comprendre avant de parler d’agents.

L’idée en une phrase

Tu décris au modèle une liste d’outils disponibles, chacun avec son nom, ce qu’il fait et les paramètres qu’il attend. Quand une question dépasse ses connaissances, le modèle ne répond pas n’importe quoi : il demande à utiliser un outil, en précisant les bons arguments¹.

Attention à un point souvent mal compris. Le modèle n’exécute jamais l’outil lui-même. Il renvoie une demande structurée, du type « appelle meteo(ville) avec ville égale Lille ». C’est ton code, à toi, qui exécute la fonction et renvoie le résultat au modèle, qui rédige alors sa réponse finale².

Le déroulé concret

flowchart LR
  U["Ta question"] --> M["Le modèle"]
  M --> D{"Besoin d'un outil ?"}
  D -->|Non| R["Réponse directe"]
  D -->|Oui| T["Demande : appeler outil(args)"]
  T --> C["Ton code exécute l'outil"]
  C --> M
  M --> R2["Réponse finale, ancrée sur le résultat"]

Le mécanisme est le même chez tous les grands fournisseurs. OpenAI parle de function calling, Anthropic de tool use, Google de function calling, mais le principe est identique : décrire les outils, laisser le modèle choisir, exécuter de ton côté¹².

Ne pas confondre avec les sorties structurées

Une confusion fréquente mérite d’être levée. Les structured outputs forcent le modèle à répondre dans un format précis, par exemple un JSON conforme à un schéma. L’appel d’outils, lui, sert à déclencher une action. La bonne règle : les sorties structurées pour mettre en forme une réponse, l’appel d’outils pour faire quelque chose dans le monde réel³.

Le lien avec MCP

Si tu as lu mon article sur MCP, une question se pose vite : à quoi sert un standard comme MCP si l’appel d’outils existe déjà ? La réponse tient en un mot : la portée. L’appel d’outils est propre à chaque application et à chaque modèle. Tu redéfinis tes fonctions à chaque projet. MCP standardise la façon dont les outils sont décrits et partagés, pour qu’un même serveur d’outils fonctionne avec n’importe quel modèle compatible³. Les deux ne s’opposent pas. MCP est une couche au-dessus de l’appel d’outils.

Pourquoi c’est la base des agents

Un agent n’est rien d’autre qu’un modèle à qui on a donné des outils et la possibilité de les enchaîner. Il observe un résultat, décide de l’étape suivante, rappelle un outil, et recommence jusqu’à atteindre son but⁴. Tout part de cette mécanique simple. Une fois qu’elle est claire, les frameworks comme LangGraph et CrewAI deviennent beaucoup plus faciles à comprendre : ils ne font qu’organiser, fiabiliser et mettre à l’échelle cette boucle.

L’essentiel à retenir

L’appel d’outils transforme un générateur de texte en quelque chose qui peut agir. Le modèle décide quand et comment utiliser un outil, ton code l’exécute, et la réponse finale s’appuie sur un résultat réel plutôt que sur une supposition. C’est peu de chose sur le papier, et pourtant c’est le point de départ de tout ce qui suit dans cette série.