2026 : l’année où le function calling est devenu le système nerveux des agents

Il y a trois ans, le function calling était une curiosité de laboratoire. Quand OpenAI l’a introduit en juin 2023, il s’agissait surtout de permettre à GPT-3.5 de sortir un objet JSON propre au lieu d’un texte libre. Aujourd’hui, en 2026, ce mécanisme est devenu le socle invisible de tout ce qu’on appelle « agent ». Une application agentique qui ne fait pas d’appels d’outils n’est pas une application agentique : c’est un chatbot qui réfléchit tout seul dans son coin.

La bascule est mesurable. Selon les données compilées par notre rédaction, 40 % des applications d’entreprise intégraient des agents spécialisés en 2026, contre seulement 5 % en 2025. Et 80 % des entreprises déclarent prévoir d’utiliser des agents IA dans leurs processus. Autrement dit : la quasi-totalité des développeurs qui construisent aujourd’hui quelque chose d’un peu sérieux avec un LLM touchent, de près ou de loin, au tool calling.

Mais 2026 est aussi l’année où la couche de liaison s’est réorganisée autour d’un standard : le Model Context Protocol (MCP), poussé par la Agentic AI Foundation créée en décembre 2025 sous l’égide de la Linux Foundation, avec Block et OpenAI comme cofondateurs et le soutien affiché de Google, Microsoft, AWS et Cloudflare. Ce protocole ouvert, qui permet à un assistant ou un agent d’utiliser des outils et des données externes, a changé la question : il ne s’agit plus seulement de savoir quel format de schéma utiliser, mais comment exposer ses outils une fois pour toutes à tous les modèles. Nous y revenons en détail plus bas.

Le problème de fond demeure néanmoins : la couche native de chaque fournisseur — celle qui relie le modèle au monde extérieur au niveau du JSON — n’est pas standardisée. OpenAI parle de tools avec function.parameters. Anthropic parle de tool_use avec input_schema. Google parle de FunctionDeclaration avec parameters. Mistral reprend la grammaire OpenAI. Et les modèles open-weights, eux, dépendent de templates de chat comme Hermes ou ToolACE qui varient d’un modèle à l’autre.

Résultat : ce qui devrait être un détail d’implémentation est devenu une décision d’architecture. Choisir son format d’outil, c’est choisir son degré de lock-in, sa capacité à changer de modèle en une ligne, et sa résilience face aux prochaines évolutions. Cet article propose un comparatif argumenté et opérationnel, avec les forces, les faiblesses et les verdicts pour chaque approche.

Anatomie d’un appel d’outil : ce que chaque fournisseur met vraiment dans le JSON

Commençons par le socle commun. Partout, le principe est le même : le développeur décrit les fonctions disponibles (nom, description, paramètres en JSON Schema), le modèle retourne un objet JSON structuré indiquant quelle fonction appeler et avec quels arguments, puis l’application exécute la fonction, capture le résultat et le réinjecte dans la conversation. Le modèle ne fait jamais l’appel lui-même — c’est une distinction cruciale, souvent mal comprise. Un article de bird.com (8 septembre 2026) le formule clairement : le tool calling demande à un logiciel d’exécuter une action, là où le function calling désigne historiquement la capacité du modèle à formater sa sortie ; l’exécution reste toujours du ressort de l’application.

Mais dès qu’on descend d’un niveau, les divergences apparaissent.

OpenAI expose le function calling via le champ tools, où chaque outil a type: "function", puis function.name, function.description et function.parameters décrit en JSON Schema. C’est la grammaire historique, celle que tout le monde a copiée. OpenAI recommande désormais les « Structured Outputs » pour rendre le function calling plus fiable, en contraignant le modèle à respecter strictement le schéma plutôt qu’à l’approximer. Depuis la bêta publique du 10 septembre 2026, l’Agents API d’OpenAI pousse la logique un cran plus loin : elle livre le « harness » Codex, où le modèle remplit du JSON et où le harnais se charge d’appeler les outils, avec une organisation en session / turn / item (jsonsort.com, 20 septembre 2026). C’est un glissement conceptuel important : la responsabilité de l’exécution sort du code applicatif pour être confiée à une couche dédiée.

Anthropic utilise input_schema et tool_choice. La logique est proche, mais le nom change — et avec lui, toute la plomberie de votre code. Un adaptateur naïf qui traduit parameters en input_schema fonctionne dans 90 % des cas, puis casse sur les cas limites : objets imbriqués profonds, contraintes additionalProperties, énumérations complexes.

Google passe par FunctionDeclaration avec un champ parameters. Là encore, même idée, format différent. La documentation Gemini fournie dans nos sources traite surtout de l’Interactions API, ce qui complique la comparaison directe des formats de function calling — signe que Google lui-même ne met pas cette couche au premier plan de sa communication.

Mistral reprend la grammaire OpenAI (tools avec function.parameters), ce qui en fait le choix le plus « portable » par défaut : un code écrit pour OpenAI fonctionne souvent tel quel.

Les modèles open-weights (Llama 3/4, Qwen) sont le Far West. Ils ne disposent pas d’API unifiée : ils s’appuient sur des templates de chat comme Hermes ou ToolACE, qui encodent les outils dans le prompt système selon des conventions propres. Le résultat est que le même modèle peut se comporter différemment selon le template utilisé — et qu’un template mal choisi peut faire chuter le taux de succès des appels d’outils de façon spectaculaire. C’est précisément ce que les « harnais » open source viennent corriger : un guide publié le 18 septembre 2026 en recense onze, avec licences et règles de configuration, pour faire tourner des agents sur Ollama, LM Studio ou llama.cpp (lefilia.fr, hoton.ai).

Fournisseur	Champ racine	Schéma des paramètres	Sélection forcée	Portabilité
OpenAI	tools[]	function.parameters (JSON Schema)	tool_choice	Référence de facto
Anthropic	tools[]	input_schema	tool_choice	Adaptateur requis
Google	FunctionDeclaration	parameters	non précisé	Adaptateur requis
Mistral	tools[]	function.parameters	tool_choice	Quasi-identique OpenAI
Open-weights	Templates (Hermes, ToolACE) + harnais	Variable selon template	Variable	Fragile, dépend du template

Le verdict ici est simple : si vous voulez maximiser la portabilité sans écrire d’abstraction, Mistral et OpenAI sont les plus proches. Si vous visez Anthropic ou Google, prévoyez une couche de traduction dès le premier jour — pas après. Et si vous voulez éviter complètement ce problème, la réponse 2026 s’appelle MCP : exposer vos outils une fois via un serveur MCP, et laisser chaque client (Claude, ChatGPT, agents maison) s’y brancher avec son propre format natif.

MCP : le standard qui a déplacé le problème (et créé le sien)

Le Model Context Protocol mérite sa propre section, parce qu’il a changé la façon dont on pense le tool calling. L’idée est simple : au lieu de décrire vos outils dans le format propriétaire de chaque fournisseur, vous montez un serveur MCP qui expose des outils, des ressources et des prompts selon un protocole unique. N’importe quel client compatible — un assistant, un agent, un IDE — peut alors découvrir et appeler ces outils sans que vous ayez à maintenir cinq adaptateurs.

L’adoption a été rapide et large en 2026. Forrester, repris par Studeria (4 septembre 2026), projette que 30 % des éditeurs SaaS adopteront MCP en 2026, puis 60 % en 2027. Les intégrations concrètes pleuvent : Maxon a intégré un serveur MCP natif dans Cinema 4D 2026.4, donnant aux assistants compatibles (Claude, ChatGPT) accès aux outils du logiciel — ordre dans la scène, variations, passes de rendu, UV (render.ru, 30 septembre 2026). Webflow propose un serveur MCP qui laisse une IA lire et modifier un site, avec les garde-fous à poser (agence-synqro.fr, 7 septembre 2026). Et Apple a fait un pas plus radical : Safari 27 embarque un serveur MCP natif exposant 17 outils d’automatisation aux agents — sans aucun contrôle MDM pour le désactiver côté entreprise, ce que forkast.news (20 septembre 2026) souligne comme un angle mort (iphonesoft.fr, 18 septembre 2026).

Le protocole lui-même a continué d’évoluer. Fin septembre 2026, OpenAI a ajouté des webhooks événementiels qui donnent à MCP sa « troisième jambe de communication » : après la requête et la réponse, l’agent peut désormais réagir à des événements du monde extérieur au lieu de simplement l’interroger (forkast.news, 29 septembre 2026). C’est une bascule : l’agent passe d’un mode « je demande » à un mode « on me notifie ».

Mais MCP n’est pas une baguette magique, et 2026 a aussi révélé ses angles morts. Le premier est la surface d’attaque. Un article des ayinedjimi-consultants (19 septembre 2026) le dit sans détour : l’infrastructure IA est la nouvelle cible des attaquants, et les pipelines LLM, MCP et agents constituent une surface que personne ne surveille vraiment. Un serveur MCP mal cloisonné, c’est un accès direct aux outils de votre système offert à un agent — et par ricochet à quiconque parvient à manipuler son contexte. Le second angle mort est la gouvernance : quand un navigateur grand public expose 17 outils sans interrupteur d’administration, la question n’est plus technique mais politique.

Le troisième est plus insidieux : MCP ne résout pas la fiabilité. Il standardise le transport, pas la décision. Un agent branché sur quinze serveurs MCP ne devient pas fiable par magie — il sollicite en pratique une demi-douzaine de serveurs par tâche, et la qualité dépend toujours de la description des outils et de la discipline du modèle.

Appels parallèles et streaming : là où les implémentations divergent vraiment

C’est ici que les différences cessent d’être cosmétiques. Les appels parallèles (parallel tool calls) sont supportés par OpenAI, Anthropic et Gemini — mais avec des implémentations différentes. Concrètement, cela signifie qu’un modèle peut demander l’exécution simultanée de plusieurs outils dans une même réponse, par exemple « cherche la météo à Paris » et « cherche la météo à Lyon » en un seul tour.

Le piège classique : l’ordre des appels n’est pas déterministe. Si vos outils ont des dépendances (l’un a besoin du résultat de l’autre), vous ne pouvez pas compter sur l’ordre de retour. Il faut soit interdire le parallélisme via tool_choice, soit concevoir vos outils pour qu’ils soient indépendants. C’est une contrainte d’architecture, pas un détail d’implémentation.

Le streaming des tool calls est encore plus subtil. La fragmentation des arguments JSON en chunks est confirmée par plusieurs sources indépendantes : les arguments arrivent en morceaux (delta.tool_calls[] côté OpenAI, content_block_delta côté Anthropic). Cela change tout pour l’UX : au lieu d’attendre 2 à 3 secondes qu’un appel d’outil soit entièrement formulé, vous pouvez afficher les arguments au fur et à mesure. Mais cela impose de reconstruire le JSON partiel côté client — et de gérer les cas où le flux s’interrompt au milieu d’une chaîne de caractères.

Un chiffre pour mesurer l’enjeu : dans un scénario type de chaîne de tool calling à quatre allers-retours, la latence avant la première réponse visible atteint 3,2 secondes (4 × 800 ms). Le streaming des arguments est précisément ce qui permet de casser cette attente perçue. Sans lui, l’utilisateur fixe un écran vide. Avec lui, il voit l’agent « réfléchir à voix haute ». Et l’arithmétique se gâte vite : un agent enchaînant huit appels séquentiels à 800 ms dépasse les six secondes avant la moindre réponse utile. C’est le « mur de la seconde » que documente notre dossier sur la latence du tool calling.

Autre piège documenté : l’idempotence. Un appel d’outil peut être émis deux fois si le réseau vacille ou si le modèle se répète. Si votre outil n’est pas idempotent (par exemple, un paiement), vous doublez l’effet. La parade standard : un identifiant unique par appel, vérifié côté serveur avant exécution.

Enfin, la validation stricte des outils hallucinés est devenue une pratique de base. Les modèles inventent parfois des noms d’outils qui n’existent pas, ou des arguments hors énumération. Un seuil empirique circule chez les praticiens : au-delà de 50 outils déclarés dans une même requête, la fiabilité chute. Mieux vaut exposer peu d’outils, bien décrits, que cinquante outils approximatifs. Une étude de Lasso publiée le 17 septembre 2026 ajoute une couche inattendue : le filigrane de texte (watermarking) modifie les refus des LLM et, avec eux, le comportement des appels d’outils (unite.ai). Autrement dit, une technique de traçabilité peut dégrader la fiabilité agentique — un compromis à connaître.

Le vrai coût d’un outil : tokens fantômes, latence cachée et tarifs 2026

Parlons argent. Chaque schéma d’outil déclaré consomme des tokens — c’est le « coût fantôme » du function calling. Une description verbeuse, une énumération de vingt valeurs, un objet imbriqué sur trois niveaux : tout cela entre dans la fenêtre de contexte à chaque appel, et se paie à chaque tour. Un agent productif enchaîne typiquement 3 à 8 appels d’outils par requête utilisateur, ce qui multiplie mécaniquement le coût de chaque schéma déclaré.

Les chiffres précis sur ce surcoût par fournisseur manquent cruellement. Aucune donnée indépendante ne documente, dans nos sources, la consommation exacte de tokens supplémentaires induite par un schéma complexe chez OpenAI versus Anthropic. C’est une lacune réelle du secteur : les fournisseurs ne publient pas de comptabilité détaillée du coût des schémas.

Ce qu’on a, en revanche, ce sont des tarifs et des latences revendiqués par un comparatif tiers (HolySheep AI), qu’il faut prendre avec des pincettes — la source est un revendeur avec un conflit d’intérêt manifeste, et sa méthodologie n’est pas publiée. Ces chiffres sont donc à traiter comme indicatifs, pas comme canoniques :

Modèle (selon HolySheep)	Précision revendiquée	Latence revendiquée	Prix input / output (par MTok)
OpenAI GPT-4.1	97,2 %	800–1200 ms	$8 / $32
Anthropic Claude Sonnet 4.5	96,8 %	1000–1500 ms	$15 / $75
Google Gemini 2.5 Flash	95,4 %	600–900 ms	$2,50 / $10
DeepSeek V3.2	94,1 %	150–300 ms	$0,42 / $1,68

Ces chiffres proviennent d’un benchmark interne non reproductible, et HolySheep se classe évidemment premier dans son propre comparatif (98,7 % de précision, latence < 50 ms, coût 85 % inférieur). À prendre pour ce que c’est : du marketing. La leçon méthodologique est plus importante que les chiffres eux-mêmes — exigez des benchmarks publics.

Les références académiques existent : Berkeley Function Calling Leaderboard (BFCL), ToolBench, API-Bank. Ce sont elles qu’il faut consulter pour comparer sérieusement les fournisseurs. Aucune de ces sources n’apparaît dans les comparatifs commerciaux, ce qui en dit long sur leur rigueur.

Côté latence, un ordre de grandeur utile circule : une stack RAG optimisée (Azure AI Search + OpenAI) affiche une latence P50 de 1,0 seconde, contre 0,5 seconde pour une stack custom optimisée à 350 req/s. Les gains d’optimisation atteignent 2× à 2,4× selon les benchmarks tiers. Autrement dit : la latence du tool calling n’est pas qu’une affaire de modèle — c’est aussi une affaire d’infrastructure.

Et le coût total d’un agent, lui, ne se lit pas dans la grille tarifaire du modèle. Notre dossier sur le coût réel des agents le chiffre : un agent correctement architecturé tourne entre 29 et 50 dollars par mois, quand le même agent mal conçu dépasse les 200 dollars — un facteur de 4 à 7. L’écart ne vient pas du prix du token mais de ce qu’on lui envoie : contextes gonflés, schémas verbeux, appels redondants. La discipline du schéma d’outil est donc aussi une discipline budgétaire.

Quand ça casse : erreurs de schéma, hallucinations d’arguments et stratégies de récupération

Le function calling échoue. Souvent. Et les modes d’échec varient selon l’écosystème.

Les quatre familles d’erreurs les plus fréquentes : JSON malformé (le modèle oublie une accolade), arguments hors énumération (il invente une valeur), appels d’outils inexistants (il hallucine un nom de fonction), et boucles infinies (il rappelle le même outil en espérant un résultat différent). Le taux d’échec global des agents en production est estimé à 88 % — un chiffre brutal, cité par Patronus AI dans un rapport industriel 2026, qui rappelle que le POC qui marche n’est pas le service qui tient. Un agent de support client non surveillé dépasse d’ailleurs les 30 % de tâches ratées après seulement trois semaines d’exploitation.

La parade commence par la validation côté client. Ne faites jamais confiance au JSON retourné : validez-le contre votre schéma (Pydantic, Zod, JSON Schema validator) avant d’exécuter quoi que ce soit. Si la validation échoue, renvoyez l’erreur au modèle avec un message explicite — « le champ date doit être au format ISO 8601 » — et laissez-le corriger. C’est le pattern du retry avec correction, et il fonctionne étonnamment bien.

Deuxième parade : le fallback vers un modèle plus contraint. Si un modèle créatif hallucine trop d’arguments, basculez sur un modèle plus petit mais plus discipliné pour les appels d’outils critiques. C’est une stratégie d’hybridation qui gagne du terrain : un gros modèle pour raisonner, un petit pour exécuter. Notre dossier sur le routage manuel des LLM détaille cette grille « tâche → modèle → outil ».

Troisième parade : la journalisation. Un article récent d’apidog (26 août 2026) le rappelle avec justesse : « Appel d’outil, 200 » n’explique rien. Il faut enregistrer les arguments exacts, le schéma utilisé, le résultat brut, la latence et l’identifiant d’appel — tout en caviardant les données sensibles. C’est la condition pour diagnostiquer un échec au lieu de le subir.

Quatrième parade, plus récente : le harnais. La Tribune (1er septembre 2026) résume la tendance : depuis quelques semaines, le monde de l’IA ne jure plus que par ces outils qui supervisent ce que le modèle peut ou ne peut pas faire. Le harnais exécute les outils, gère la mémoire et les permissions, et applique les règles de sécurité à la place du modèle. C’est la réponse structurelle au problème de fiabilité : on ne demande plus au LLM d’être sage, on l’encadre.

Mâcher le travail au modèle : la checklist opérationnelle

Tout ce qui précède se résume en une conviction : la fiabilité d’un agent ne se joue pas dans le modèle, elle se joue dans la préparation du terrain. Voici la liste de ce qu’un praticien doit faire avant d’appeler le modèle.

Décrire peu, décrire bien. Exposez le minimum d’outils nécessaires à la tâche, avec des descriptions qui disent quand appeler l’outil, pas seulement ce qu’il fait. Un outil dont la description est ambiguë sera mal appelé, quel que soit le modèle.

Typer strictement. Utilisez les Structured Outputs ou un schéma JSON strict pour contraindre la sortie. Un schéma permissif est une invitation à l’hallucination d’arguments.

Valider avant d’exécuter. Aucun appel d’outil ne doit partir sans validation contre le schéma. C’est non négociable, et c’est bon marché.

Rendre idempotent. Chaque outil qui a un effet de bord (paiement, envoi, écriture) doit accepter un identifiant d’appel et ignorer les doublons.

Standardiser l’exposition. Montez vos outils en serveur MCP plutôt qu’en cinq adaptateurs propriétaires. Vous gagnerez la portabilité et vous préparerez l’arrivée de nouveaux modèles sans réécriture.

Encadrer par un harnais. Confiez l’exécution, les permissions et la mémoire à une couche dédiée plutôt qu’au code applicatif éparpillé. C’est ce qui distingue un agent qui tient d’un agent qui ment.

Mesurer. Journalisez chaque appel, chaque échec, chaque latence. Sans traces, pas d’amélioration — et pas de facture maîtrisée.

Évaluer. Un juge LLM bien étalonné vaut mieux qu’un ressenti. Notre dossier sur les juges LLM détaille les quatre péchés à éviter (verbosité, auto-préférence, dérive, contamination) et le protocole d’étalonnage que tout le monde saute.

Le fil conducteur de ces huit points est le même : on ne rend pas un LLM fiable en le suppliant d’être rigoureux dans le prompt. On le rend fiable en lui retirant les occasions de se tromper. C’est ça, lui mâcher le travail.

Verdict : quelle stack pour quel profil en 2026

Pour un projet qui démarre aujourd’hui et veut éviter le lock-in : MCP comme couche d’exposition des outils, un modèle au choix derrière, et un harnais pour l’exécution. C’est la combinaison la plus pérenne, et elle absorbe les changements de modèle sans réécriture.

Pour un projet déjà engagé sur OpenAI : restez-y, mais isolez la définition des outils dans une couche unique, et prévoyez la migration vers MCP quand le besoin de multi-modèle se fera sentir. L’Agents API et son harness Codex simplifient l’exécution, au prix d’une dépendance plus forte à l’écosystème.

Pour un projet sensible à la confidentialité ou au coût : les modèles open-weights avec un harnais adapté (Ollama, LM Studio, llama.cpp) sont désormais viables, à condition de choisir un template de chat éprouvé et de tester le taux de succès des appels d’outils avant la mise en production.

Pour un projet qui doit tenir en production : la question n’est plus « quel modèle » mais « quelle observabilité ». 88 % d’échec en production, c’est le prix de l’absence de harnais, de traces et d’évaluations. Le modèle est le courant ; l’installation, c’est vous.

Sources

• The AI Rankings — What Is MCP? The Model Context Protocol Explained (2026), 4 octobre 2026
• forkast.news — MCP Events Complete the Agent Communication Model, 29 septembre 2026
• forkast.news — Safari 27 Ships a Native MCP Server, 20 septembre 2026
• render.ru — Maxon intègre un serveur MCP dans Cinema 4D 2026.4, 30 septembre 2026
• jsonsort.com — OpenAI Agents API 2026 : JSON Schema, Tool Calling, 20 septembre 2026
• ayinedjimi-consultants.fr — LLM pipelines et MCP : la surface d’attaque que personne ne surveille, 19 septembre 2026
• iphonesoft.fr — Safari 27 : le navigateur d’Apple se met à l’IA avec un serveur MCP, 18 septembre 2026
• lefilia.fr — Meilleurs frameworks d’agents open source pour LLM locaux en 2026, 18 septembre 2026
• hoton.ai — Meilleurs harnais d’agents Open Source pour les LLM locaux en 2026, 18 septembre 2026
• unite.ai — L’étude Lasso : le filigrane texte modifie les refus des LLM et les appels d’outils, 17 septembre 2026
• bird.com — Qu’est-ce que le tool calling, et en quoi diffère-t-il du function calling ?, 8 septembre 2026
• agence-synqro.fr — MCP Webflow : comment les IA lisent et modifient un site, 7 septembre 2026
• studeria.fr — Modèles IA 2026 : GPT-6, Claude Opus 5, Gemini, Grok, 4 septembre 2026
• jsonmin.com — Après OpenAI DevDay 2026, comment change le développement, 2 septembre 2026
• latribune.fr — La nouvelle obsession de la tech : de bons « harnais » pour maîtriser les IA, 1er septembre 2026
• radnoumane.com — RAG, MCP et function calling : le kit de survie des développeurs en 2026, 15 mars 2026
• Dossiers internes du magazine : « Orchestration multi-outils », « Choisir le bon LLM pour chaque tâche », « Tool calling en 2026 : latence, MCP, harnais », « Juges LLM », « Agents LLM et tool calling : de la démo qui ment à la production qui tient », « Le coût réel d’un agent LLM en production ».