Le pattern de génération de code plutôt que d'appels d'outils

Fin 2025, Cloudflare et Anthropic ont publié indépendamment des recherches aboutissant à la même conclusion : les LLM produisent de meilleurs résultats lorsqu’ils écrivent du code contre des API que lorsqu’ils génèrent des appels d’outils structurés. Les implémentations diffèrent, mais l’intuition sous-jacente est partagée, et elle a des implications directes sur l’évolution de MCP.

Le mode Code de Cloudflare

L’approche de Cloudflare, détaillée dans leur recherche de septembre 2025, convertit les schémas d’outils MCP en interfaces API TypeScript. Au lieu de présenter au modèle des définitions d’outils brutes et de lui demander de générer des appels d’outils JSON, le mode Code fournit au modèle des définitions de types TypeScript et lui demande d’écrire du code qui appelle ces API.

Le modèle ne voit jamais les définitions d’outils brutes. Il voit du TypeScript familier — interfaces, signatures de fonctions, annotations de types — et écrit du code contre elles.

Les résultats de leur benchmark sur 31 événements calendrier :

81 % de tokens en moins comparé aux appels d’outils traditionnels
Meilleure exactitude : l’agent en mode écriture de code a correctement utilisé new Date() pour déterminer la date actuelle ; l’agent en mode appel d’outils ne pouvait pas accéder aux fonctions de date dans le paradigme d’appel d’outils et a créé tous les événements un an dans le passé
Logique plus riche : l’agent en mode écriture de code pouvait utiliser des boucles, des conditionnelles, des variables et la gestion des erreurs — toute l’expressivité d’un langage de programmation plutôt que d’être limité à un appel d’outil à la fois

Le mécanisme clé : lorsque le modèle écrit du code, il peut regrouper des opérations, réutiliser des résultats intermédiaires et appliquer du flux de contrôle. Avec les appels d’outils, chaque opération est un aller-retour distinct dans la fenêtre de contexte du modèle. Le code se compose naturellement ; les appels d’outils s’accumulent.

// Mode Code : le modèle écrit ceci
const today = new Date();
for (let i = 0; i < 31; i++) {
  const eventDate = new Date(today);
  eventDate.setDate(today.getDate() + i);
  await calendar.createEvent({
    title: `Daily standup`,
    date: eventDate.toISOString(),
    duration: 30
  });
}

// Appel d'outil traditionnel : le modèle génère 31 appels séparés
// {"tool": "create_event", "args": {"title": "Daily standup", "date": "2025-09-01", ...}}
// {"tool": "create_event", "args": {"title": "Daily standup", "date": "2025-09-02", ...}}
// ... (29 de plus)

La version code est plus concise, plus exacte (calcul dynamique de la date) et plus efficace (une seule opération logique contre 31 allers-retours).

L’exécution de code d’Anthropic avec MCP

La recherche d’Anthropic emprunte un chemin d’implémentation différent mais arrive à la même destination. Leur approche présente les outils MCP comme des modules de code accessibles par le système de fichiers que les agents découvrent à la demande. Plutôt que de charger des définitions d’outils dans la fenêtre de contexte, l’agent écrit du code qui importe et appelle ces modules.

Leur cas de test Google Drive vers Salesforce a montré l’amélioration la plus spectaculaire :

MCP traditionnel : 150 000 tokens
Exécution de code : 2 000 tokens
Réduction : 98,7 %

L’explication est architecturale. Avec MCP traditionnel, chaque résultat intermédiaire passe par la fenêtre de contexte du modèle. Télécharger un fichier depuis Google Drive — le modèle voit le contenu complet du fichier dans son contexte. Analyser les métadonnées du fichier — retour dans le contexte. Téléverser vers Salesforce — un autre aller-retour avec la réponse complète. Chaque étape pollue la fenêtre de contexte avec des données dont le modèle n’a pas besoin pour sa prochaine décision.

Avec l’exécution de code, les données restent dans un sandbox. Le modèle écrit un script qui télécharge, traite et téléverse. Les données intermédiaires vivent dans des variables au sein du sandbox, n’entrant jamais dans la fenêtre de contexte. Le modèle reçoit seulement le résultat final : succès ou échec, avec les détails pertinents.

L’intuition partagée

Les deux approches exploitent la même asymétrie des données d’entraînement : les LLM se sont entraînés extensivement sur du code, pas sur des formats d’appels d’outils synthétiques. Écrire du TypeScript ou du Python est ce pour quoi ces modèles ont été construits. Générer du JSON structuré correspondant à des schémas arbitraires est une compétence acquise enseignée via un fine-tuning relativement limité.

Le pattern peut être résumé ainsi : convertissez les interfaces d’outils en interfaces de code, puis laissez le modèle écrire du code. Le modèle reste dans sa modalité la plus forte (génération de code) tout en accédant aux outils externes.

Pour les data engineers, ce pattern se manifeste déjà naturellement dans Claude Code. Quand Claude écrit bq query --nouse_legacy_sql '...' et pipe le résultat via jq pour le traitement, il fait exactement ce que Cloudflare et Anthropic décrivent : écrire du code (commandes shell) contre une API bien connue (la CLI bq) plutôt que de générer des appels d’outils structurés. La CLI bq est effectivement une “interface de code” vers BigQuery que le modèle parle couramment.

Implications pour l’avenir de MCP

Cette recherche n’invalide pas MCP. Elle suggère que l’évolution de MCP se dirigera vers des interfaces basées sur du code plutôt que vers des appels d’outils JSON-schema.

Court terme : attendez-vous à ce que les clients MCP (Claude Code, Cursor, outils similaires) convertissent en interne les schémas d’outils en représentations de code avant de les présenter au modèle. L’expérience développeur reste la même — vous construisez toujours des serveurs MCP de la même façon — mais le modèle voit des interfaces TypeScript ou Python plutôt que des schémas JSON.

Moyen terme : les serveurs MCP pourraient exposer des SDK de code en parallèle des définitions d’outils. Au lieu d’une interface tools/call (ou en complément), les serveurs pourraient fournir des modules importables que les agents peuvent utiliser dans des sandboxes d’exécution de code.

Long terme : la distinction entre “appel d’outil” et “exécution de code” pourrait s’estomper entièrement. Le modèle écrit du code qui appelle des outils, le protocole MCP gérant la communication sous-jacente de manière transparente.

Ce que cela signifie concrètement aujourd’hui

Pour les data engineers utilisant Claude Code aujourd’hui, la conclusion pratique est simple :

Les commandes CLI pour les outils bien établis (bq, gcloud, gsutil, dbt, git) sont déjà le pattern “génération de code plutôt qu’appels d’outils”. Le modèle écrit du code shell contre des interfaces familières. C’est le chemin le plus efficace pour les outils avec une représentation approfondie dans les données d’entraînement.
MCP pour les outils sans CLI (Salesforce, HubSpot, API internes) offre encore de la valeur parce qu’il n’existe pas de pattern de code établi pour le modèle. MCP fournit une interface structurée qui vaut mieux que rien, même si elle n’est pas aussi efficace que la génération de code contre une CLI familière.
Les configurations hybrides sont la réponse pratique. Laissez le modèle utiliser la CLI pour les outils qu’il connaît bien, MCP pour les outils qu’il ne connaît pas, et faites confiance au fait que l’infrastructure sous-jacente convergera avec le temps :

{
  "mcpServers": {
    "salesforce": {
      "command": "npx",
      "args": ["-y", "@mcp/salesforce-server"]
    }
  },
  "permissions": {
    "allow": [
      "Bash(bq *)",
      "Bash(gcloud *)",
      "Bash(gsutil *)",
      "Bash(dbt *)"
    ]
  }
}

Surveillez les améliorations côté client. À mesure que Claude Code et d’autres clients MCP adoptent en interne des patterns d’exécution de code, l’écart d’efficacité entre CLI et MCP se réduira — potentiellement sans aucune modification de votre code de serveur MCP.

La façon dont les agents IA interagissent avec les outils évolue encore rapidement. Investir dans des serveurs MCP est raisonnable parce que le protocole devient une infrastructure. Les patterns d’appels d’outils pourraient être supplantés par des patterns d’exécution de code à mesure que les clients évoluent. Construire des serveurs avec des outils propres et bien documentés laisse de la place pour cette transition sans nécessiter de modifications du serveur.