Exécution de code avec MCP : efficacité des tokens pour les agents complexes

L'exécution de code avec MCP désigne un pattern d'agent dans lequel un agent IA, au lieu d'enchaîner de nombreux appels d'outils individuels, écrit et exécute du code qui appelle les outils MCP de manière programmatique dans une sandbox. La consommation de tokens et la latence baissent sensiblement, car les définitions d'outils et les résultats intermédiaires sont traités dans le contexte du code, au lieu de passer intégralement par la fenêtre de contexte du modèle de langage. C'est une optimisation pour les workflows complexes et gourmands en données, pas un remplacement des appels d'outils classiques.

Réponses rapides

• Ce que c'est : l'agent génère un programme qui appelle les outils MCP comme des fonctions ; seul le résultat final condensé revient au modèle.
• À quoi ça sert : l'efficacité en tokens et en latence quand il y a beaucoup d'outils, beaucoup d'étapes et de gros résultats intermédiaires.
• Ce qu'il faut : une sandbox isolée, des tokens à portée limitée et le moindre privilège, car le code exécutable produit par le modèle est une surface d'attaque à part entière.

Le problème : les appels d'outils passent mal à l'échelle

Le Model Context Protocol (MCP) a été lancé par Anthropic le 25 novembre 2024 comme standard ouvert pour connecter les applications d'IA à des systèmes externes, par exemple des systèmes de fichiers, des bases de données, des applications métier et des outils de développement. Techniquement, MCP repose sur JSON-RPC 2.0 avec deux transports standard : stdio pour les serveurs locaux et un transport HTTP que la révision 2025-03-26 de la spécification (mars 2025) a fait passer de l'ancien HTTP+SSE à Streamable HTTP. La même révision a apporté OAuth 2.1 et les annotations d'outils. Le batching JSON-RPC, introduit en même temps, a été supprimé par la révision 2025-06-18. En 2026, MCP est le standard de facto pour la communication entre agents et outils ; le 9 décembre 2025, Anthropic a fait don du protocole à l'Agentic AI Foundation (AAIF), nouvellement créée sous l'égide de la Linux Foundation. À ce moment-là, selon Anthropic, les SDK totalisaient plus de 97 millions de téléchargements mensuels en Python et TypeScript.

Dans le pattern classique, l'agent appelle chaque outil séparément. Chaque appel passe par le modèle de langage (LLM) : le modèle voit la définition de l'outil, formule l'appel, reçoit le résultat complet dans sa fenêtre de contexte et décide de l'étape suivante. Pour les tâches simples, c'est idéal : transparent et facile à auditer. Dans les workflows complexes, en revanche, deux gouffres à tokens apparaissent :

1. Définitions d'outils chargées en amont. Si un agent dispose de dizaines ou de centaines d'outils MCP, leurs descriptions doivent être chargées à l'avance dans le contexte. Cela représente souvent des milliers de tokens avant même que l'agent commence à travailler.
2. Résultats intermédiaires dans le contexte. Un outil qui renvoie une longue liste, un gros document ou une réponse d'API volumineuse l'écrit en entier dans la fenêtre de contexte, même si l'agent n'a besoin que de trois valeurs. Dans les chaînes en plusieurs étapes, cela s'additionne.

La solution : l'agent écrit du code

Le pattern d'exécution de code, qu'Anthropic a publié fin 2025 comme approche d'ingénierie, inverse la logique. L'agent génère un programme, généralement en Python ou en TypeScript, qui traite les outils MCP comme des fonctions importables. Ce code s'exécute dans une sandbox. Le filtrage, les boucles, les branchements et les agrégations se font là, dans le contexte d'exécution du code. Seul le résultat final condensé revient dans la fenêtre de contexte du modèle.

Un pseudocode permet de montrer la différence. La tâche : l'agent doit trouver dans le CRM tous les contacts dont la dernière commande a rapporté plus de 10 000 euros de chiffre d'affaires.

Approche classique, avec de nombreux appels d'outils via le modèle :

LLM: ruf get_contacts() auf

-> 5.000 Kontakte (vollständig in den Kontext)

LLM: für jeden Kontakt ruf get_last_order(id) auf

-> 5.000 weitere Tool-Calls, jeder einzeln durchs Modell

LLM: filtere die mit Umsatz > 10.000

-> erneut große Datenmengen im Kontext

Exécution de code, avec un programme généré :

# vom Agenten generierter, in der Sandbox ausgeführter Code

kontakte = mcp.crm.get_contacts()

umsaetze = {k.id: mcp.crm.get_last_order(k.id).umsatz for k in kontakte}

return [{"name": k.name, "umsatz": umsaetze[k.id]} for k in kontakte if umsaetze[k.id] > 10000]

Dans le second cas, le modèle ne voit ni les 5 000 contacts ni les 5 000 réponses de commande. Il ne voit que le code qu'il a écrit et, à la fin, la liste filtrée. Les appels d'outils eux-mêmes se déroulent de manière programmatique, et non comme des tours de LLM individuels. Cela économise à la fois des tokens et de la latence, car les boucles s'exécutent sans allers-retours avec le modèle.

Un second effet est la découverte d'outils à la demande : au lieu de charger toutes les définitions d'outils à l'avance, l'agent peut parcourir les serveurs MCP disponibles et leurs fonctions comme un répertoire de modules et n'importer que celles dont il a réellement besoin. La charge initiale reste ainsi faible, même si des centaines d'outils étaient théoriquement disponibles.

Exemple chiffré

Un calcul simplifié illustre le levier. Hypothèse : un agent doit identifier les meilleurs clients dans un CRM et les enrichir avec des données de commande. Les chiffres sont illustratifs. Ils indiquent des ordres de grandeur et ne constituent pas un benchmark. La colonne classique représente d'ailleurs le cas le plus favorable : elle ne compte que la charge initiale et une seule liste brute de 5 000 enregistrements. Les 5 000 appels individuels à get_last_order du pseudocode ci-dessus ne sont pas inclus. Chacun d'eux ajouterait sa propre réponse de commande et un aller-retour avec le modèle. Le total classique serait donc plusieurs fois plus élevé.

Dans le tableau, le poste décisif n'est pas la charge initiale, mais les résultats intermédiaires : ils sont traités dans le code et n'occupent pas de contexte du modèle. C'est précisément là que se trouve le levier. Plus les volumes de données sont importants et plus il y a d'itérations, plus l'écart se creuse. Pour une simple requête isolée, en revanche, le calcul s'inverse : le surcoût lié à la génération et à l'exécution d'un programme dépasse le bénéfice.

Anthropic donne des valeurs concrètes dans son article d'ingénierie du 4 novembre 2025. Dans l'exemple, un agent charge la transcription d'une réunion depuis Google Drive et la joint à un lead Salesforce. Avec des appels d'outils directs, la transcription passe deux fois par le modèle. Pour une réunion de deux heures, cela peut représenter 50 000 tokens supplémentaires. Si les outils sont disponibles sous forme de fichiers et que l'agent ne charge que les définitions nécessaires à la tâche en cours, la consommation passe, selon Anthropic, de 150 000 à 2 000 tokens, soit une baisse de 98,7 %.

Quand c'est pertinent, et quand ça ne l'est pas

L'exécution de code est une optimisation, pas un pattern standard pour tout. Elle convient aux workflows multi-outils récurrents et gourmands en données. Pour les actions simples et ponctuelles, les appels d'outils directs restent plus rapides, moins chers et plus transparents : la trace montre chaque étape directement, sans détour par du code généré.

Sécurité : la sandbox est obligatoire

La plus grande différence par rapport aux appels d'outils classiques touche à la sécurité : avec le pattern d'exécution de code, le système lance du code exécutable généré par un modèle de langage. C'est une surface d'attaque à part entière. Pour MCP, un modèle de confiance délibérément optimiste est documenté en 2026, qui assimile la correction syntaxique à la sécurité sémantique. S'y ajoutent des classes d'attaques concrètes : l'injection de prompt indirecte via les descriptions de serveurs, le Tool Poisoning (PoC d'Invariant Labs, avril 2025), le squatting de serveurs look-alike et le Full-Schema Poisoning de CyberArk, où chaque partie d'un schéma d'outil peut devenir un vecteur d'injection. Le durcissement est expressément du ressort de l'exploitant.

Pour l'exécution de code, cela signifie concrètement :

• Sandbox isolée. Le code généré s'exécute dans un environnement d'exécution cloisonné, sans accès étendu aux fichiers ni au réseau, avec des limites de ressources et de temps contre les boucles infinies et l'épuisement des ressources.
• Tokens à portée limitée. Des serveurs MCP derrière OAuth 2.1 (depuis la révision 2025-03-26 de la spécification, mars 2025) avec les autorisations minimales nécessaires. Le code n'a accès qu'à ce que la tâche exige.
• Moindre privilège et aucune installation autonome. Les agents ne doivent ni charger ni installer d'eux-mêmes des serveurs MCP provenant de registres non fiables.
• Journalisation d'audit complète. Chaque appel d'outil depuis le code de la sandbox est journalisé, avec une trace de bout en bout, des versions de modèle figées et une corrélation via un ID de trace. Dans les secteurs réglementés de la zone DACH (Allemagne, Autriche, Suisse), les auditeurs et les autorités de surveillance peuvent exiger ce type de preuves.

Exécuter du code de modèle sans ces couches de protection, c'est obtenir l'efficacité des tokens au prix d'un risque considérable pour la sécurité et la protection des données. Dans les secteurs réglementés de la zone DACH, c'est exclu.

Pour les agences et les décideurs B2B

Pour les agences et les éditeurs d'IA qui transforment leurs services en produits, l'exécution de code avec MCP est le levier direct sur les unit economics des produits agentiques. Un acteur qui exploite des services multi-tenant (par exemple des agents SEO, newsletter ou de recherche) paie chaque exécution en tokens ; le pattern d'exécution de code réduit ces coûts de façon mesurable dans les workflows gourmands en données et diminue en même temps la latence, ce qui améliore la qualité perçue du produit. Pour démarrer concrètement, il s'agit de passer en revue les agents existants basés sur MCP pour repérer les workflows qui traversent beaucoup d'outils et de gros résultats intermédiaires, de basculer précisément ceux-là vers l'exécution de code et d'intégrer dès le premier jour la sandbox, les scopes OAuth 2.1 et la journalisation d'audit. Pour les décideurs B2B, l'essentiel est ceci : le pattern est une décision d'architecture par workflow, pas un changement de plateforme. Il s'appuie sur le standard MCP, déjà établi, et peut être introduit progressivement sans abandonner l'intégration d'outils existante.