CONCEPTS — DU MODÈLE AU SYSTÈME · TOOL CALLING
Sources officielles et travaux de recherche vérifiés au 18 juillet 2026.
Un modèle de langage annonce qu'il va consulter votre base de données, puis affiche le résultat. Un autre déclare envoyer un e-mail, et l'e-mail part. L'impression est saisissante : la machine agit. Elle n'a pourtant rien fait. Elle a produit du texte — un fragment particulièrement bien formé, décrivant une action souhaitée — et c'est un programme qui a lu ce fragment et exécuté l'opération. La documentation d'Anthropic le formule sans détour : « le modèle n'exécute jamais rien de lui-même » ; il émet une requête structurée, votre code fait tourner l'opération, le résultat revient dans la conversation.
Ce malentendu n'est pas un détail de vocabulaire. C'est la frontière dont découle tout le reste : qui répond d'une action erronée, où placer les contrôles, pourquoi un JSON impeccable peut contenir une bêtise, et pourquoi la sécurité d'un agent ne se joue jamais dans le modèle mais dans la couche qui l'entoure.
Le modèle ne fait rien : il demande
Le fonctionnement est d'une sobriété désarmante. Vous envoyez votre message habituel, plus un catalogue d'outils : pour chacun, un nom, une description en langue naturelle, un schéma des paramètres attendus. Le modèle lit tout cela comme le reste du prompt. S'il juge qu'un outil aiderait, il ne répond pas par une phrase mais par un bloc structuré nommant l'outil et remplissant ses arguments.
Là s'arrête son rôle. OpenAI décrit le partage des tâches sans ambiguïté : le modèle décide quelle fonction de votre code exécuter et quels arguments lui passer, mais c'est votre backend qui procède à l'exécution. Même mécanique chez Mistral, où la spécification par schéma JSON décrit type, nom, description et champs requis, rien de plus.
Le modèle est donc un conseiller très rapide qui ne tient aucun stylo. Toute la puissance — et tout le danger — vient de ce que vous branchez derrière ses suggestions. C'est ce qui sépare un agent capable d'exécuter d'un simple assistant conversationnel : non pas une différence de modèle, mais une différence de plomberie.
La boucle d'appel d'outil, en cinq temps. Votre application envoie le prompt et le catalogue ; le modèle renvoie une intention structurée ; votre code exécute ; le résultat repart vers le modèle, qui conclut ou redemande un outil. Une seule étape franchit la frontière du monde réel — la troisième, et elle vous appartient entièrement.
La boucle, tour après tour
Un appel isolé ne sert pas à grand-chose : ce qui rend le mécanisme opérationnel, c'est la boucle. Anthropic la documente en cinq étapes pilotées côté client — requête avec le catalogue, réponse contenant des blocs d'appel, exécution locale, nouvelle requête portant les résultats, répétition tant que le modèle réclame des outils. Le pilote, c'est votre programme. Vous choisissez quand vous arrêter et ce que vous refusez d'exécuter.
Un modèle peut aussi demander plusieurs outils d'un coup. Anthropic autorise l'appel parallèle par défaut, désactivable, et précise que l'API ne prescrit aucun ordre d'exécution. OpenAI offre le même levier. Le gain est réel : trois appels indépendants de deux cents millisecondes prennent deux cents millisecondes au lieu de six cents. Le risque l'est tout autant — des outils partageant un état peuvent produire des résultats faux sans lever la moindre erreur.
Chaque tour rallonge par ailleurs le contexte. Les résultats d'outils s'y empilent, et ce qu'on garde ou jette devient central — c'est le sujet de la mémoire des agents, et l'une des raisons pour lesquelles les architectures multi-agents cloisonnent ces historiques.
Sorties structurées : demander poliment du JSON, ou contraindre le décodage
Pour qu'un programme exploite une réponse, elle doit être parfaitement formée. Or un modèle est une machine à probabilités : rien ne l'empêche d'ajouter une phrase avant son JSON, d'oublier une accolade ou d'inventer un champ. Deux familles de solutions coexistent, et on les confond souvent.
La première consiste à demander. Vous écrivez « réponds uniquement en JSON conforme à ce schéma », éventuellement via un mode JSON générique. Le modèle obéit la plupart du temps — et « la plupart du temps » est précisément le problème : vous devez valider, détecter l'échec, réessayer.
La seconde consiste à contraindre. On n'agit plus sur le prompt mais sur le décodage. À chaque étape, le moteur d'inférence calcule quels tokens restent compatibles avec le schéma et neutralise tous les autres en poussant leur score à moins l'infini. Le modèle ne peut plus produire une sortie invalide : les chemins interdits n'existent plus. C'est l'approche des grammaires formelles de llama.cpp, du décodage guidé de vLLM, ou de la bibliothèque open source Outlines éditée par dottxt, qui construit un automate à états finis indexé sur le vocabulaire du modèle.
Les grandes plateformes vendent aujourd'hui cette garantie comme un service. OpenAI a introduit ses Structured Outputs le 6 août 2024, avec 100 % de conformité mesurée sur des évaluations de schémas complexes pour le modèle de référence de l'époque. Chez Anthropic, les sorties structurées combinent un format JSON et un mode strict pour les paramètres d'outil, au prix de restrictions : propriétés additionnelles interdites, tous les champs obligatoires.
Deux niveaux de garantie. À gauche, la consigne dans le prompt : sortie espérée, jamais assurée, validation et réessai à votre charge. À droite, le décodage contraint : les tokens incompatibles avec le schéma sont masqués à chaque étape, la forme est garantie. La limite est commune aux deux colonnes — une structure valide ne dit rien de l'exactitude du contenu.
Ce que la contrainte garantit, et ce qu'elle ne garantit pas
Vient alors la confusion la plus coûteuse du domaine. Contraindre le décodage garantit la syntaxe. Cela ne garantit rien de la justesse.
La documentation des grammaires de llama.cpp est franche : « le modèle n'a aucune visibilité sur le schéma ». La grammaire est un filtre extérieur à la génération — le modèle produit ce qu'il aurait produit, amputé des chemins interdits. Structure toujours valide, contenu potentiellement faux : un champ date_de_livraison sera une date bien formée, rien ne dit qu'elle corresponde à quoi que ce soit.
Les erreurs de terrain le confirment. La taxonomie ToolScan recense sept types d'erreurs récurrentes dans l'usage d'outils : appels insuffisants, valeurs incorrectes, noms d'arguments hallucinés, types invalides, appels redondants, fonctions inexistantes, formatage invalide. La contrainte de décodage n'élimine que le dernier. Anthropic observe que les défaillances les plus fréquentes sont le mauvais choix d'outil et les paramètres incorrects, surtout quand deux outils portent des noms voisins.
Contraindre le format d'une réponse garantit qu'elle sera lisible par une machine. Cela ne garantit pas qu'elle soit vraie. La forme et le fond relèvent de deux mécanismes différents, et un seul des deux est sous contrôle technique.
— Principe de la génération structurée
Le prix du format : une controverse non tranchée
Imposer un format a-t-il un coût sur la qualité du raisonnement ? Le débat public n'est toujours pas clos.
D'un côté, l'étude « Let Me Speak Freely? », publiée à EMNLP 2024 (prépublication du 5 août 2024), mesure une dégradation sévère. Sur le jeu de raisonnement mathématique GSM8K, en passant du texte libre au JSON imposé : GPT-3.5-Turbo chute de 76,60 % à 49,25 %, LLaMA 3 8B de 74,73 % à 48,90 %, Claude 3 Haiku de 86,51 % à 23,44 % — soixante-trois points perdus. Sur une tâche de raisonnement symbolique, LLaMA 3 8B tombe de 70,07 % à 28,00 %. L'explication avancée est mécanique : le mode JSON force un ordre « réponse d'abord » qui empêche la chaîne de raisonnement de se dérouler avant la conclusion. Remède proposé : générer en langue naturelle, convertir ensuite.
De l'autre, une contestation méthodologique frontale. Dans « Say What You Mean », dottxt soutient que le protocole était biaisé : les prompts de la condition libre différaient sensiblement de ceux de la condition structurée, ces derniers ne donnant pas au modèle assez d'information pour résoudre la tâche. En rejouant l'expérience avec une méthodologie corrigée sur un modèle ouvert, dottxt affirme ne pas retrouver la dégradation.
Deux réserves avant de conclure — et nous ne conclurons pas. D'abord, dottxt édite précisément une bibliothèque de décodage contraint : ce contradicteur est juge et partie, ce qui n'invalide pas son argument mais impose de le lire comme une position intéressée. Ensuite, à la date de ce relevé, l'étude d'origine n'a publié ni rétractation ni correctif. Ce qui fait consensus entre les deux camps tient dans la formule de dottxt : la génération structurée ne peut pas « magiquement faire comprendre à un modèle ce que vous voulez ». La contrainte fiabilise la forme ; elle ne crée aucune connaissance absente.
| Approche | Ce qui est garanti | Ce qui ne l'est pas | Où ça s'exécute | Coût et limites |
|---|---|---|---|---|
| Consigne dans le prompt | Rien. Une forte probabilité, pas une garantie. | Validité syntaxique, absence de texte parasite, champs, types. | Nulle part : c'est du texte. | Gratuit, mais impose validation et réessais — latence et tokens imprévisibles. |
| Mode JSON générique | Une sortie qui s'analyse comme du JSON valide. | La conformité à votre schéma : noms, types, énumérations. | Côté fournisseur, pendant la génération. | Peu coûteux, laisse toute la validation métier à votre charge. |
| Schéma imposé via l'API | Conformité au schéma fourni ; validation stricte des paramètres d'outil. | L'exactitude des valeurs : un argument inventé peut être valide. | Côté fournisseur, sur son infrastructure. | Schémas restreints (propriétés additionnelles interdites, champs tous obligatoires chez Anthropic) ; dépendance à la plateforme. |
| Décodage contraint local | Validité syntaxique stricte vis-à-vis d'une grammaire ou d'une expression régulière. | La justesse du contenu — « le modèle n'a aucune visibilité sur le schéma ». | Dans votre moteur d'inférence, sur vos machines. | Contrôle total, mais grammaire à écrire et maintenir ; des constructions naïves ralentissent l'échantillonnage. |
Passer à l'échelle : quand le catalogue d'outils devient le problème
Sur trois outils, tout va bien. Le problème apparaît quand le catalogue grossit — et il grossit vite, d'autant que les protocoles standardisés de connexion d'outils apparus depuis 2024 ont rendu le branchement de nouvelles capacités presque trivial.
Le premier coût est arithmétique. Les définitions occupent le contexte avant qu'un seul mot utile ait été échangé. Anthropic chiffre le phénomène : cinq connecteurs totalisant cinquante-huit outils consomment environ 55 000 tokens avant le début de la conversation ; un connecteur de plus fait franchir la barre des 100 000. En interne, l'éditeur rapporte avoir mesuré des définitions pesant à elles seules 134 000 tokens. Ce n'est plus un détail de facturation, c'est une fenêtre de contexte qui disparaît.
Le second coût est cognitif : plus le catalogue est long, plus le modèle se trompe d'outil. En ne rendant visibles à la demande que les outils pertinents, la même source mesure une précision de sélection passant de 49 % à 74 % pour Opus 4, de 79,5 % à 88,1 % pour Opus 4.5, tandis que l'usage de tokens tombe d'environ 77 000 à 8 700 sur le scénario testé. Faire orchestrer les appels par du code plutôt que par des allers-retours successifs produit un effet voisin : de 43 588 à 27 297 tokens sur des tâches de recherche complexes, avec un gain de précision. Le principe est constant — moins le modèle voit d'options à la fois, mieux il choisit. Pour évaluer cela, la référence publique reste le Berkeley Function Calling Leaderboard, qui distingue appels simples, multiples, parallèles et scénarios agentiques multi-tours.
Là où ça devient dangereux : agir sur la foi d'un contenu non fiable
Tant qu'un modèle produit du texte, une erreur reste une erreur de texte. Dès qu'il déclenche des actions, elle devient un effet dans le monde réel. Les attaquants l'ont compris avant tout le monde.
Le chercheur indépendant Simon Willison — à qui l'on doit le terme « injection de prompt » — a nommé « lethal trifecta » la combinaison de trois ingrédients : accès à des données privées, exposition à du contenu non fiable, capacité de communication vers l'extérieur. Le mécanisme sous-jacent est que les modèles ne savent pas distinguer de façon fiable les instructions des données. Un agent qui lit un e-mail, un ticket ou une page web traite ce contenu exactement comme les consignes de son opérateur. Quiconque peut écrire sur une surface que l'agent lit peut donc orienter son comportement — c'est le sujet de notre article sur l'injection de prompt, cette faille sans correctif.
Les référentiels ont suivi. Dans l'édition 2025 du Top 10 OWASP pour les applications à base de LLM, l'injection de prompt conserve la première place pour la deuxième édition consécutive, et une catégorie « Excessive Agency » apparaît, visant les systèmes dotés de trop de fonctionnalités, de permissions ou d'autonomie. Trois causes racines : accès à plus d'outils que nécessaire, privilèges trop élevés, décisions sans supervision adéquate. Autrement dit, le moindre privilège appliqué au tool calling.
La pratique va dans ce sens, avec une nuance inquiétante. Une étude d'Anthropic du 18 février 2026 sur l'usage réel de son API publique relève que 80 % des appels d'outils proviennent d'agents disposant d'au moins un garde-fou, que 73 % des agents intègrent une forme de supervision, et que 0,8 % seulement des actions observées apparaissent irréversibles. Mais la même étude signale une fatigue d'approbation mesurable : dans un produit d'auto-approbation existant, 20 % des nouveaux utilisateurs activent l'auto-approbation complète, proportion dépassant 40 % chez les utilisateurs expérimentés. Le garde-fou existe ; il est aussi ce qu'on désactive en premier quand il agace. D'où la nécessité de le concevoir comme un garde-fou systémique et non comme une boîte de dialogue. Les outillages le permettent : l'SDK d'agents d'OpenAI permet de marquer un outil comme nécessitant approbation, suspend l'exécution jusqu'à décision explicite, et sait persister des décisions durables.
Une gêne apparaît alors en production : ces allers-retours prennent du temps. Chaque tour de boucle est un appel complet au modèle, avec sa file d'attente, son traitement du prompt et sa génération mot à mot — pendant que l'utilisateur regarde un curseur clignoter. Le prochain article de cette série ira chercher d'où vient réellement cette attente : ce que fait un moteur d'inférence quand il regroupe des requêtes, pourquoi le streaming change la perception sans changer le total, et ce que le décodage spéculatif permet vraiment de gagner.
Une question, un projet IA ?
Vous branchez un modèle sur vos systèmes métier et cherchez où placer la frontière entre suggestion et exécution — échangeons sur votre contexte.
Prendre contact →Pour aller plus loin : côté pratique, nos décryptages d'outils IA montrent comment ces mécanismes d'appel d'outil se traduisent dans les plateformes que vous utilisez déjà ; et pour situer le sujet dans une architecture complète, l'article sur les agents, du chat statique à l'IA qui exécute pose le cadre dont le tool calling est le moteur.