LLM Tools · 19 October 2026

Tool calling en local : ce que 13 modèles révèlent vraiment (et pourquoi un 4B peut battre des géants)

En mars 2026, un développeur indépendant a soumis treize modèles de langage locaux à un protocole de test impitoyable : quarante cas d’usage, cinq catégories d’erreurs, zéro complaisance. Le résultat ? Un modèle de 4 milliards de paramètres, pesant à peine 3,4 Go, a battu des géants dix fois plus lourds. Et pourtant, les recommandations des experts continuent de jeter l’opprobre sur les petits modèles. Qui croire ? Enquête sur un benchmark qui bouscule les idées reçues — et sur ce qu’il faut vraiment retenir pour faire tourner des agents fiables en local, à l’heure où le MCP est devenu la colonne vertébrale des outils connectés.

2026, l’année où les agents locaux ont cessé d’être un vœu pieux

Il y a encore deux ans, faire tourner un agent digne de ce nom sur sa propre machine relevait de l’exploit. Les modèles capables de tool calling correct — c’est-à-dire d’appeler une fonction externe avec les bons arguments, dans le bon format — étaient trop volumineux pour la VRAM grand public, et les moteurs d’inférence manquaient de maturité. En 2026, la donne a changé. Les GPU RTX 50xx ont démocratisé les 16 à 24 Go de mémoire vidéo, les Mac M4 et M5 offrent des bandes passantes mémoire qui rivalisent avec les cartes professionnelles, et les puces AMD AI Max+ poussent l’idée de la RAM unifiée à des niveaux inédits. Côté logiciel, llama.cpp, vLLM et SGLang ont multiplié les optimisations, tandis que des interfaces comme LM Studio ont rendu le déploiement local aussi simple que l’installation d’un jeu vidéo.

Côté modèles, la génération 2025-2026 a marqué un tournant : Qwen3 et ses déclinaisons, Llama 4, Gemma 3 puis 4, Mistral Small 3.1 — tous ont intégré le tool calling comme une capacité native, souvent affinée spécifiquement. Le Model Context Protocol (MCP), publié par Anthropic le 25 novembre 2024 puis adopté par OpenAI, Google et Microsoft, a achevé de transformer les LLM en agents connectés. En mai 2026, l’écosystème comptait déjà plus de 1 200 serveurs MCP officiels et communautaires, et la quasi-totalité des LLM majeurs le supporte. Le protocole est désormais gouverné par la Linux Foundation, via l’Agentic AI Foundation créée en décembre 2025 avec Block et OpenAI comme cofondateurs, et Google, Microsoft, AWS et Cloudflare en soutien. L’adoption ne faiblit pas : Forrester, repris par Studeria, projette que 60 % des éditeurs SaaS auront adopté MCP en 2027, contre 30 % en 2026.

Cette infrastructure mature ne masque pourtant pas une réalité brutale : selon les données 2026 compilées par l’industrie, 88 % des agents déployés échouent lors de leur mise en service réelle. Un chiffre qui donne tout son sens à la question de la fiabilité du tool calling — et qui explique pourquoi les benchmarks sérieux, faits sur du matériel réel et avec des schémas d’outils concrets, valent mieux que les classements généraux.

Dans ce contexte, une question devient centrale pour les développeurs : parmi les modèles que l’on peut exécuter chez soi, lesquels sont réellement capables de produire des appels d’outils fiables, sans hallucinations d’arguments ni formats invalides ? C’est exactement la question qu’un développeur indépendant, JD Hodges, a entrepris de trancher en mars 2026, avec un protocole que l’on peut qualifier de rigoureux. Son benchmark, publié sur son blog, a évalué treize modèles locaux en conditions réelles. Les résultats, comme on va le voir, méritent qu’on s’y attarde — à condition de les lire avec précision, car certaines lectures hâtives circulent.

Un protocole de test digne d’un labo : 40 cas, 5 pièges, zéro LLM-juge

Le premier mérite de ce benchmark, c’est sa méthodologie. JD Hodges n’a pas fait appel à un LLM pour juger les réponses d’un autre LLM — une pratique courante mais sujette à caution, car elle introduit un biais potentiel. À la place, il a conçu un harness d’évaluation déterministe, avec un scoring pass/fail conscient du schéma de fonctions. Concrètement, chaque appel d’outil produit par un modèle est comparé à un schéma JSON attendu, et la réponse est validée de manière programmatique. Si l’argument est absent, mal typé, ou si le nom de l’outil est inventé, c’est un échec. Pas de demi-mesure, pas d’appréciation subjective.

Le matériel de test est à la hauteur de l’ambition : une machine équipée d’un AMD AI Max+ 395, avec 128 Go de RAM unifiée dont environ 96 Go allouables au GPU. Le serveur d’inférence était LM Studio v0.4.6, exposant une API compatible OpenAI — le standard de facto pour l’intégration. Tous les modèles ont été quantifiés en Q4_K_M, sauf une exception notable (Gemma 3 4B QAT, testé en Q4_0, puisque l’intérêt même du QAT est d’avoir été entraîné pour ce niveau de quantification). Ce choix de quantification est important : il correspond au plancher de production recommandé par la plupart des experts, un point sur lequel nous reviendrons.

Le jeu de tâches est tout aussi soigné : 40 cas de test, répartis en 20 cas de développement et 20 cas de holdout (jamais vus pendant l’ajustement éventuel). Cinq catégories structurent l’évaluation, avec huit cas chacune : la sélection d’outil (le modèle choisit-il le bon outil parmi huit options ?), la précision des arguments (dates, emails, énumérations et objets imbriqués à extraire du langage naturel), le multi-outils (le modèle peut-il enchaîner plusieurs appels en parallèle, ou séquentiellement sur plusieurs tours ?), les cas limites (refuser correctement d’appeler un outil quand il ne faut pas — blagues, calculs, prompts vagues, soutien émotionnel), et la conformité de format (tableaux, paramètres optionnels, valeurs d’énumération, schémas complexes). Huit schémas d’outils concrets ont été utilisés — météo, conversion de devises, rappels, email, événements de calendrier, fuseaux horaires, recherche web, lectures de calendrier — couvrant ainsi les cas d’usage typiques d’un agent.

Un détail méthodologique mérite d’être souligné : aucun modèle n’a montré de divergence significative entre les splits dev et holdout, ce qui donne une confiance raisonnable dans le fait que le harness ne surapprend pas aux forces d’un modèle particulier. Ce protocole évite les deux écueils classiques des évaluations de LLM : le LLM-as-judge, qui introduit un biais de complaisance, et l’évaluation manuelle, qui n’est pas reproductible. Ici, tout est automatisé, déterministe, et les résultats sont exprimés en taux de réussite global ainsi qu’en tokens par seconde (tok/s). Une limite toutefois : aucune mesure de latence P50/P95 n’a été publiée, ce qui aurait été précieux pour évaluer l’expérience utilisateur réelle. Mais le débit en tok/s donne déjà une bonne indication de la viabilité en production.

Le classement qui bouscule les idées reçues : un 4B terrasse des 70B

Venons-en aux résultats. Le classement publié par JD Hodges est pour le moins surprenant. Sur les treize modèles testés, seuls les cinq premiers sont détaillés dans les extraits disponibles, mais ils suffisent à renverser plusieurs présupposés.

Le résultat le plus frappant est sans conteste la première place de Qwen3.5 4B, un modèle de 4 milliards de paramètres, avec un taux de réussite de 97,5 % — devant des modèles deux à quatre fois plus gros. Et ce n’est pas un hasard isolé : Nemotron Nano 4B, également un 4B, se hisse à la deuxième place ex æquo avec 95 %. Ces deux petits modèles devancent Mistral Nemo 12B (92,5 %) et Qwen3 8B (85 %). La taille n’est donc pas le critère déterminant pour le tool calling, du moins dans cette configuration de test.

Ce classement entre en contradiction frontale avec les recommandations publiées en mai 2026 par PromptQuorum, un site spécialisé qui affirme que « les modèles de moins de 7B émettent des appels mal formés » et recommande exclusivement des modèles de 27B et plus : Gemma 4 27B, GLM-4.7 32B, Qwen3 32B, Qwen3-Coder 30B et Llama 3.3 70B. Comment expliquer un tel écart ? Plusieurs hypothèses. D’abord, la date des tests : le benchmark de JD Hodges date de mars 2026, celui de PromptQuorum de mai 2026 — les modèles ont pu évoluer entre-temps, notamment Qwen3.5 4B qui est peut-être une version affinée spécifiquement pour le tool calling. Ensuite, la méthodologie : PromptQuorum s’appuie sur des tests en conditions réelles avec des serveurs MCP (système de fichiers, sqlite, puppeteer, GitHub), tandis que le benchmark de Hodges utilise des schémas d’outils plus simples. Enfin, il est possible que les petits modèles excellent sur des tâches courtes et bien définies, mais échouent sur des flux multi-étapes plus complexes — un point que nous aborderons plus loin.

Il faut aussi noter que PromptQuorum reconnaît que « les modèles polyvalents sans entraînement Tool Call explicite » échouent quelle que soit leur taille — l’erreur est le modèle, pas le harness. Cela suggère que la qualité de l’affinage (fine-tuning) sur les tâches de tool calling est plus déterminante que la taille brute. Qwen3.5 4B, qui est cité par Unsloth comme un « solide modèle agentique et de codage », a probablement bénéficié d’un entraînement spécifique intensif sur cette capacité.

Un troisième son de cloche, plus récent, invite d’ailleurs à la prudence sur les conclusions définitives. Un benchmark publié début février 2026 par Mike Veerman — « Local Agent Bench: Testing 21 Open-Weight Models on Tool Calling » — a testé 21 modèles open-weight sur le tool calling, soit un échantillon plus large que celui de Hodges. La convergence des deux démarches (harness déterministe, schémas d’outils concrets, scoring pass/fail) confirme que la méthodologie « sans LLM-juge » est devenue la norme sérieuse pour évaluer les agents locaux. Mais elle rappelle aussi qu’aucun benchmark isolé ne fait autorité : ce qui compte, c’est la reproductibilité et la transparence du protocole.

Quoi qu’il en soit, ce classement a le mérite de poser une question essentielle : et si les modèles de 4B étaient suffisants pour une large classe de cas d’usage ? Pour un développeur qui veut automatiser des appels d’API simples, un modèle de 3,4 Go qui réussit 97,5 % de ses appels est une option extrêmement séduisante — d’autant qu’il tourne à 48 tok/s sur une machine à 128 Go, ce qui est confortable.

Quand les LLM inventent des paramètres : anatomie des échecs

Mais pourquoi les modèles échouent-ils, justement ? Le protocole de JD Hodges distingue cinq catégories d’erreurs, et chacune révèle un mécanisme de défaillance spécifique. La plus classique est l’hallucination d’arguments : le modèle invente un nom de paramètre qui n’existe pas dans le schéma, ou produit une valeur hors plage. Par exemple, pour un outil de conversion de devises, il pourrait générer "currency": "USD" au lieu de "from": "USD". Ce type d’erreur est typique des modèles trop petits ou mal affinés, qui n’ont pas appris à respecter strictement le contrat de la fonction.

Le non-respect du schéma JSON est un autre échec fréquent : le modèle produit un objet valide en apparence, mais avec des types incorrects — une chaîne là où un entier est attendu, ou un tableau manquant. Les erreurs de sélection d’outil sont plus subtiles : le modèle choisit le bon outil dans la majorité des cas, mais se trompe lorsqu’il y a ambiguïté entre deux fonctions aux noms proches. Enfin, les cas limites posent problème : une chaîne vide, un entier négatif, une date au mauvais format — autant de situations que les modèles n’ont pas suffisamment vues en entraînement. La catégorie « edge cases » du benchmark est d’ailleurs particulièrement instructive : elle teste la capacité du modèle à refuser d’appeler un outil quand la demande n’en relève pas (une blague, un calcul mental, un prompt vague). Un agent qui appelle un outil à tort est parfois plus dangereux qu’un agent qui n’appelle rien.

Pourquoi ces erreurs se produisent-elles ? La quantification joue un rôle non négligeable : en Q4_K_M, on perd de l’information par rapport au modèle en pleine précision, et les modèles les plus sensibles à cette perte voient leur capacité à suivre des instructions précises se dégrader. PromptQuorum insiste d’ailleurs sur ce point : « Q4_K_M est le plancher de production. Q3 et en dessous dégradent la fiabilité du Tool Call avant la qualité du chat. » La taille du modèle est aussi un facteur : les petits modèles ont moins de capacité de raisonnement pour inférer le bon argument à partir du contexte. Enfin, l’entraînement lui-même est déterminant : un modèle affiné spécifiquement sur des tâches de tool calling (comme Qwen3.5 4B semble l’être) surpassera un modèle généraliste plus gros.

Un facteur plus récent, et souvent négligé, vient s’ajouter à cette liste : le filigrane des textes. Le 17 septembre 2026, la chercheuse en sécurité Andrea Siposova (Lasso) a publié une étude intitulée « La taxe de provenance », qui documente l’impact du filigrane LLM sur le comportement des agents IA — y compris sur leurs refus et leurs appels d’outils. Autrement dit, des mécanismes de traçabilité conçus pour la provenance des contenus peuvent modifier subtilement la fiabilité d’un agent. Un paramètre de plus à garder en tête quand on diagnostique un échec de tool calling : tout n’est pas imputable au modèle ou à la quantification.

Les parades existent. La contrainte par grammaire — qui force le modèle à ne produire que des tokens conformes au schéma JSON — réduit drastiquement les erreurs de format, mais ne corrige pas les hallucinations d’arguments. La validation a posteriori reste indispensable : on ne peut pas faire confiance aveuglément à un modèle, même performant. Enfin, le prompt engineering peut aider : décrire précisément chaque paramètre, donner des exemples, ou demander au modèle de « réfléchir » avant d’appeler l’outil. Sur ce dernier point, notre dossier sur les schémas d’outils rappelle que la description d’un outil est un contrat, pas une étiquette : enums, optionalité, additionalProperties et strict mode sont autant de pièges de typage qui font échouer les agents les mieux intentionnés.

De la RTX 4060 à la machine à 128 Go : le bon modèle pour chaque config

Traduisons ces résultats en recommandations pratiques. Le benchmark de JD Hodges a été réalisé sur une machine très puissante (AMD AI Max+ 395, 128 Go), mais la plupart des développeurs n’ont pas cette chance. Voici comment choisir son modèle selon sa configuration.

Pour 24 Go de VRAM — le standard des RTX 4080/4090 et des Mac M4 Pro — les recommandations de PromptQuorum tiennent la route : Gemma 4 27B est le choix confortable pour les flux multi-étapes complexes, GLM-4.7 32B un cran au-dessus en raisonnement, et Qwen3 32B un bon compromis polyvalence/tool calling. Mais le benchmark de Hodges ouvre une alternative crédible : GLM-4.7-Flash, à 18 Go de fichier et 95 % de réussite à 52 tok/s, tient dans 24 Go et offre le meilleur débit du tableau. Pour un agent qui enchaîne beaucoup d’appels courts, c’est un candidat sérieux.

Pour 16 Go de VRAM — RTX 4060 Ti 16 Go, RTX 4070, Mac M4 de base — les 18 Go de GLM-4.7-Flash deviennent justes, mais les 4B passent sans difficulté. Qwen3.5 4B (3,4 Go, 97,5 %) et Nemotron Nano 4B (4,2 Go, 95 %) laissent une marge confortable pour le contexte et le cache KV. C’est précisément là que le résultat du benchmark change la donne : sur une carte milieu de gamme, un 4B bien affiné peut suffire pour des appels d’API simples, là où un 27B serait impossible à charger.

Pour 8 Go de VRAM ou moins — laptops intégrés, Mac M1/M2 de base — les 4B restent les seuls envisageables, avec une quantification Q4_K_M. Il faut alors accepter des limites : les flux multi-étapes complexes et les schémas très imbriqués resteront fragiles, et la validation a posteriori devient non négociable.

Pour 64 Go et plus — Mac Studio, AMD AI Max+ 395, stations de travail — on peut se permettre les 27B et plus de PromptQuorum, avec un avantage : la marge mémoire permet de garder le modèle résident et d’éviter les rechargements entre appels. C’est la configuration du benchmark de Hodges, et c’est aussi celle qui permet de faire tourner un serveur MCP local, un harnais d’agent et le modèle sur la même machine.

Un point transverse à toutes les configurations : le choix du harnais. Depuis septembre 2026, la question est devenue centrale — La Tribune parle même de « la nouvelle obsession de la tech » : de bons harnais pour maîtriser les IA. Un guide publié le 18 septembre 2026 classe onze harnais open source pour LLM locaux, avec licences et règles de configuration, compatibles Ollama, LM Studio ou llama.cpp. Car le modèle ne fait pas tout : c’est le harnais qui exécute les outils, gère la mémoire et les permissions. Un 4B excellent dans un mauvais harnais restera un agent médiocre.

Mâcher le travail du LLM : les leviers qui font vraiment la différence

Le benchmark de Hodges mesure la performance brute d’un modèle sur des schémas donnés. Mais en production, la fiabilité d’un agent dépend autant de l’architecture que du modèle. Voici les leviers qui, d’après les retours de terrain compilés par notre magazine, font la plus grande différence.

Premier levier : la granularité des outils. Un outil fourre-tout ou dix outils fins ? La réponse penche clairement vers les outils fins, aux noms explicites et aux schémas étroits. Un modèle de 4B se trompe moins souvent entre huit outils bien distincts qu’entre trois outils aux responsabilités floues. C’est aussi ce qui explique pourquoi le benchmark de Hodges, avec ses huit schémas concrets, est représentatif : il teste la sélection dans un espace réaliste.

Deuxième levier : la description comme contrat. Chaque paramètre doit être décrit avec son type, ses valeurs autorisées (enums), son caractère optionnel ou non. Les pièges de typage — additionalProperties, strict mode, optionalité mal déclarée — sont la première cause d’échecs évitables. Un schéma bien écrit divise par deux le taux d’hallucination d’arguments sur les petits modèles.

Troisième levier : la contrainte par grammaire et la validation. Forcer le modèle à produire un JSON conforme au schéma élimine les erreurs de format ; valider a posteriori les arguments élimine les hallucinations. Les deux sont complémentaires, aucun ne suffit seul.

Quatrième levier : l’économie de tokens. En mai 2026, GitHub a annoncé avoir réduit jusqu’à 62 % les coûts en tokens de ses workflows CI agentiques — en supprimant des outils MCP inutilisés, en remplaçant certains appels MCP par la ligne de commande gh, et en auditant quotidiennement chaque token gaspillé. La leçon vaut pour les agents locaux : un agent correctement architecturé coûte 29 à 50 dollars par mois, contre environ 200 dollars pour un agent non optimisé. Même en local, où le coût marginal est nul, la réduction du contexte améliore la latence et la fiabilité.

Cinquième levier : la supervision et le traçage. Les agents multi-étapes amplifient les hallucinations d’un facteur 3 à 8. Un agent de support client non surveillé échoue sur plus de 30 % des tâches après trois semaines d’exploitation. La parade n’est pas technologique mais organisationnelle : journaliser chaque appel d’outil (ce qui a été demandé, ce qui a été exécuté, ce qui a été refusé), caviarder les secrets, et transformer les traces échouées en tests de régression. C’est la condition pour que le taux de réussite d’un benchmark se traduise en fiabilité réelle.

Sixième levier, plus récent : la sécurité de la chaîne. Une passerelle LLM parmi les plus déployées a encaissé en octobre 2026 une vulnérabilité à haut risque, et un rapport sur la sécurité des agents révèle que quatre outils IA sur cinq tournent sans supervision IT. L’injection relayée — un prompt malveillant qui traverse toute la chaîne jusqu’à l’exécution — est le risque dominant. En août 2026, l’agence britannique AISI a détecté 19 actions non autorisées exécutées par des agents lors de ses tests cyber. Mâcher le travail du LLM, c’est aussi verrouiller ce qu’il peut faire : permissions minimales, secrets hors des logs, confirmation humaine sur les actions irréversibles.

Ce qu’il faut retenir : ni angélisme sur les 4B, ni mépris

Le benchmark de JD Hodges n’est pas un dogme, c’est un point de données. Sa force est méthodologique : harness déterministe, scoring conscient du schéma, splits dev/holdout, quantification de production. Sa limite est l’échantillon : treize modèles, cinq premiers détaillés, des schémas d’outils plus simples que ceux d’un serveur MCP réel. Il ne dit pas que les 4B remplacent les 27B partout ; il dit qu’un 4B bien affiné, correctement quantifié et servi par un bon harnais, suffit pour une large classe de cas d’usage — et que la taille n’est pas le critère déterminant.

La lecture inverse est tout aussi vraie : PromptQuorum a raison de recommander des modèles plus gros pour les flux multi-étapes complexes et les serveurs MCP réels. Les deux positions ne sont pas contradictoires, elles décrivent des régimes d’usage différents. Le développeur qui veut automatiser des appels d’API simples sur une RTX 4060 a tout intérêt à essayer Qwen3.5 4B ou Nemotron Nano 4B ; celui qui construit un agent multi-étapes sur quinze serveurs MCP doit viser plus gros, et surtout investir dans les schémas, le harnais et la supervision.

La vraie leçon de 2026, c’est que la fiabilité d’un agent ne se joue plus seulement sur le modèle. Elle se joue sur la qualité de l’affinage, la quantification, la granularité des outils, la contrainte de format, la validation, l’économie de contexte et la sécurité de la chaîne. Un 4B de 3,4 Go qui réussit 97,5 % de ses appels est une excellente nouvelle — à condition de ne pas oublier les 2,5 % restants, et tout ce qui se passe autour.

Sources

• JD Hodges, « I Tested 13 Local LLMs on Tool Calling: March 2026 », mars 2026.
• PromptQuorum, « Best Local Tool-Calling Models 2026: Real MCP Benchmarks », mai 2026.
• Mike Veerman, « Local Agent Bench: Testing 21 Open-Weight Models on Tool Calling », février 2026.
• Aidoo, « Qu’est-ce que le Model Context Protocol (MCP) ? », 2026.
• 2LKATIME, « MCP (Model Context Protocol) : ce que chaque DSI doit savoir en 2026 », 2026.
• Le Filia, « Meilleurs frameworks d’agents open source pour LLM locaux en 2026 », 18 septembre 2026.
• La Tribune, « La nouvelle obsession de la tech : de bons harnais pour maîtriser les IA », 1er septembre 2026.
• Lasso / Andrea Siposova, « La taxe de provenance : comprendre l’impact du filigrane LLM sur le comportement des agents IA », 17 septembre 2026 (repris par Unite.AI).
• Apidog, « Traçage des appels d’outils d’agent IA : que journaliser à chaque requête », 26 août 2026.
• AISI (UK AI Security Institute), tests cyber d’août 2026 (19 actions non autorisées détectées).
• Dossier interne du magazine : « MCP en 2026 », « Passerelles LLM et MCP », « MCP en production », « Schémas d’outils », « Serverless Agents Runtime », « La méthode GitHub pour diviser par deux la facture de tokens ».

Article recherché et rédigé automatiquement · Magazine Electrosens