Asymétrie des données d'entraînement LLM pour l'utilisation d'outils

Les grands modèles de langage apprennent à partir de ce qu’ils ont vu. La qualité de leurs résultats sur n’importe quelle tâche est directement proportionnelle à la quantité de travail similaire apparaissant dans leurs données d’entraînement. Cela crée une asymétrie mesurable entre deux façons de connecter les agents IA aux outils externes : générer des commandes CLI familières versus générer des appels d’outils MCP structurés.

L’écart dans le corpus d’entraînement

Claude, GPT et leurs pairs ont ingéré des millions de dépôts GitHub, des réponses Stack Overflow, des articles de blog et des pages de documentation. Des outils comme bq (CLI BigQuery, depuis 2011), gcloud (depuis 2013), aws CLI, kubectl et psql ont plus d’une décennie d’exemples d’utilisation réelle : fils de dépannage, code de tutoriels, scripts de production, configurations CI/CD et tutoriels de blog.

L’appel d’outils MCP, en revanche, nécessite que les modèles génèrent du JSON structuré correspondant à des schémas spécifiques. Ce sont des formats que les modèles ont rencontrés principalement dans des données d’entraînement synthétiques créées spécifiquement pour enseigner l’utilisation des outils. Le volume, la diversité et la qualité de ces données d’entraînement sont de plusieurs ordres de grandeur inférieurs à ce qui existe pour les outils CLI établis.

L’équipe d’ingénierie de Cloudflare a capturé l’asymétrie avec une analogie :

Faire effectuer des tâches à un LLM avec des appels d’outils, c’est comme mettre Shakespeare à travers un cours d’un mois en mandarin puis lui demander d’écrire une pièce en cette langue. Ce ne sera tout simplement pas son meilleur travail.

Quand Claude génère bq query --nouse_legacy_sql 'SELECT COUNT(*) FROM dataset.table', il s’appuie sur des patterns qu’il a vus des milliers de fois dans de vraies bases de code. Quand il génère un appel d’outil MCP avec un schéma JSON qu’il a découvert au moment de l’exécution, il travaille à partir d’un corpus beaucoup plus petit et plus artificiel.

Les preuves de benchmark

Deux efforts de recherche indépendants fin 2025 ont quantifié l’écart.

L’expérience Code Mode de Cloudflare

Cloudflare a testé leur hypothèse en demandant à des agents de créer 31 événements de calendrier en utilisant deux approches : les appels d’outils MCP traditionnels et l’écriture de code TypeScript contre les mêmes APIs.

L’approche par code a utilisé 81% moins de tokens. Mais le résultat qualitatif était plus révélateur. L’agent qui écrivait du code a correctement appelé new Date() pour déterminer la date actuelle avant de créer les événements. L’agent d’appels d’outils, manquant de cette capacité dans le paradigme des appels d’outils, a créé les 31 événements un an dans le passé.

L’agent écrivant du code avait accès à toute l’expressivité d’un langage de programmation — variables, flux de contrôle, arithmétique de dates, gestion des erreurs. L’agent d’appels d’outils était limité à remplir des paramètres JSON pour chaque appel individuel.

La recherche sur l’exécution de code d’Anthropic

L’étude indépendante d’Anthropic a testé un workflow Google Drive vers Salesforce : télécharger un document et le joindre à un enregistrement.

Avec les appels d’outils MCP traditionnels, le workflow a consommé 150 000 tokens. Avec l’exécution de code, il est tombé à 2 000 tokens — une réduction de 98,7%.

Le mécanisme explique l’ampleur. Avec les MCP traditionnels, chaque résultat intermédiaire passe par la fenêtre de contexte du modèle. Télécharger un fichier ? Le modèle voit la réponse complète. Parser les métadonnées ? Retour par la fenêtre de contexte. Joindre à Salesforce ? Encore un aller-retour. Avec l’exécution de code, les données restent dans un sandbox. Le modèle ne reçoit que le résultat final dont il a réellement besoin.

Ce n’est pas juste une histoire d’efficacité des tokens. La pollution de la fenêtre de contexte par les résultats intermédiaires dégrade la capacité du modèle à raisonner sur la tâche globale. Un contexte plus petit signifie une meilleure attention sur ce qui reste.

Pourquoi cela importe pour le data engineering

Pour les data engineers travaillant avec BigQuery, Snowflake ou Postgres, cette asymétrie a des conséquences pratiques.

Une commande bq query consomme 15-30 tokens. Une commande bq ls en consomme environ 10. L’appel d’outil MCP équivalent — avec sa surcharge de schéma JSON et sa réponse structurée — coûte généralement 150-250 tokens par invocation, plus le coût de surcharge de la fenêtre de contexte initial du chargement des définitions d’outils.

Quand vous exécutez des dizaines d’opérations dans une session — exploration de schémas, profilage de données, itération sur des transformations — la différence se compose de pourcentages en ordres de grandeur.

# ~20 tokens, pattern vu des millions de fois dans les données d'entraînement
bq ls --format=pretty my_dataset

# ~15 tokens, extrêmement bien représenté dans les données d'entraînement
bq show --schema --format=prettyjson my_dataset.my_table

# ~40 tokens, pattern familier
bq query --nouse_legacy_sql '
SELECT COUNT(*) as rows, MIN(created_at), MAX(created_at)
FROM my_dataset.my_table
'

Claude génère ces commandes naturellement et parse leur sortie de manière fiable. Les commandes sont compactes. Les résultats s’écoulent directement. Pas de définitions d’outils nécessaires, pas de surcharge de schéma JSON.

L’asymétrie n’est pas permanente

Cet avantage est spécifique aux outils avec de larges empreintes de données d’entraînement. Il ne s’applique pas uniformément.

Pour les APIs sans équivalents CLI — Salesforce, HubSpot, Jira, Notion — il n’y a pas de pattern de ligne de commande bien établi sur lequel le modèle peut s’appuyer. Demander à Claude de générer des commandes curl brutes avec des tokens OAuth pour ces services est sujet aux erreurs. Un serveur MCP qui gère l’authentification et présente des interfaces d’outils propres améliore réellement la fiabilité pour ces cibles.

Au fur et à mesure que l’adoption de MCP croît et que davantage d’exemples d’appels d’outils apparaissent dans les bases de code publiques, l’écart dans les données d’entraînement se rétrécira. Les modèles affinés spécifiquement pour l’utilisation d’outils s’amélioreront. Mais pour les outils avec une décennie ou plus de données d’utilisation CLI — bq, gcloud, aws, kubectl, psql, git — l’asymétrie persistera probablement pendant des années car l’avantage des données d’entraînement est si important.

L’implication plus large

La leçon s’étend au-delà de tout outil spécifique. Lors de l’évaluation de toute intégration MCP, demandez-vous : un CLI existe-t-il déjà ? Quelle est l’empreinte de ses données d’entraînement ? Quelles capacités MCP ajoute-t-il par rapport à ce qu’il abstrait ?

Si le CLI est bien établi et que le modèle le génère déjà avec fluidité, MCP ajoute de la surcharge sans ajouter de capacité pour les opérations simples. Si aucun CLI n’existe, ou si le CLI est obscur, ou si le workflow nécessite des réponses structurées et des pistes d’audit, MCP apporte une valeur réelle.

Le pattern industriel émergent de conversion des schémas d’outils en interfaces de code — permettant aux LLMs d’écrire du code contre des APIs plutôt que de générer des appels d’outils — suggère que l’industrie converge vers cette compréhension. Rencontrez les modèles là où leurs données d’entraînement sont les plus solides.