Le tool calling (aussi appelé function calling) est le mécanisme par lequel un grand modèle de langage, au lieu de simplement produire du texte, émet une requête structurée pour invoquer l'une des fonctions que vous lui avez décrites — read_file, search_code, run_tests, peu importe — attend que votre runtime l'exécute, puis poursuit son raisonnement une fois le résultat réinjecté. Le modèle n'exécute jamais rien lui-même ; il produit une intention au format JSON, votre harnais fait le travail, et la sortie revient sous la forme d'un nouveau message dans la conversation.Cet aller-retour, c'est toute l'astuce. Vous fournissez au modèle une liste de schémas d'outils (nom, description, arguments en JSON-schema) en amont. À chaque tour, il peut répondre en texte clair ou choisir un outil et en remplir les arguments. Votre code l'exécute, ajoute le résultat, et la boucle continue jusqu'à ce que le modèle décide qu'il a terminé. Chaque agent de code moderne — Claude Code, Cursor, Codex, Copilot, Windsurf — n'est, au fond, qu'une boucle de tool calling enveloppée autour d'un système de fichiers et d'un shell.
Pourquoi le tool calling compte en 2026
Il compte parce que le tool calling est ce qui a transformé les chatbots en agents. Un modèle qui ne sait que parler n'est qu'une autocomplétion très coûteuse ; un modèle capable d'appeler grep, d'ouvrir un fichier et de lancer votre suite de tests peut réellement boucler. C'est le substrat de l'agentic coding et la raison d'être de MCP — MCP est essentiellement une façon standard de livrer des définitions d'outils à n'importe quel agent qui le parle.Voici la partie que personne ne met sur la page marketing : le tool calling est aussi l'endroit où votre facture de tokens explose discrètement. Trois choses s'accumulent. Premièrement, chaque schéma d'outil vit dans le prompt — à chaque tour, pour toute la session. Chargez une douzaine de serveurs MCP sans discernement et vous avez dépensé des milliers de tokens avant même que le modèle ne lise une seule ligne de votre code. Deuxièmement, les résultats d'outils sont recollés verbatim. Un agent de code qui appelle un outil « lister le répertoire » ou « lire un fichier » déversera joyeusement la sortie brute, non filtrée, dans sa context window, et vous payez pour tout cela — puis vous repayez à chaque tour suivant où elle reste en contexte. Troisièmement, la boucle est multi-tours par conception, donc cette inflation se compose.Je passe une grande partie de mon temps exactement là-dessus. Les corrections qui font vraiment bouger les choses sont peu glorieuses : charger les définitions d'outils à la demande (lazy-load) pour qu'un agent ne paie que les serveurs MCP qu'il utilise à ce tour-ci, et appliquer de l'output filtering sur les résultats d'outils pour qu'un dump de répertoire de 600 lignes devienne les huit lignes dont le modèle avait besoin. C'est une grande partie de ce que Tokenade fait automatiquement — chargement MCP paresseux, output filtering, semantic code search pour que l'agent récupère les trois bonnes fonctions au lieu de lire trente fichiers, plus un dashboard qui vous montre les économies par session. Il se place devant Claude Code, Cursor, Codex, Copilot et les autres, il est source-available (MIT), et l'offre gratuite couvre ≈ 10M tokens par mois avant Pro à 19,90 $/mois. Si votre boucle d'agent vous semble coûteuse, la couche de tool calling est le premier endroit où je regarderais — voir comment réduire la consommation de tokens d'un agent de code IA.
Quand NE PAS l'utiliser
Génération de texte one-shot. Si vous voulez seulement un résumé, une traduction ou de la prose, ne câblez pas d'outils. Les schémas coûtent des tokens à chaque tour et vous n'y gagnez rien ; une simple complétion est plus économique et plus simple.
Quand un appel déterministe ferait l'affaire. Si votre code sait déjà qu'il doit lire config.json, lisez-le, tout simplement. Faire transiter cette décision par le modèle ajoute un aller-retour réseau, de la latence et des tokens pour « décider » quelque chose qui n'était pas réellement une décision.
Petits modèles avec beaucoup d'outils. Définissez vingt outils quasi identiques et un petit modèle choisira le mauvais ou hallucinera les arguments. Des outils moins nombreux et bien décrits valent mieux qu'un menu tentaculaire — et gardez les schémas hors du contexte tant qu'ils ne sont pas nécessaires.