Accueil › Glossaire › Code Execution LLM

Code Execution LLM

Un code execution LLM est un grand modèle de langage capable d’écrire du code (Python, JavaScript, etc.), de l’exécuter dans un environnement isolé (sandbox), de récupérer les résultats (sorties texte, graphiques, fichiers) et de les intégrer dans sa réponse.

Un LLM classique génère du texte, y compris du code. Mais il ne peut pas le tester. Il ne voit pas les erreurs d’exécution, ne peut pas vérifier un calcul, ni produire un graphique à partir de données réelles. Le code execution résout cette limite en donnant au modèle un « ordinateur » virtuel pour exécuter ce qu’il écrit.

C’est la capacité qui a rendu le Code Interpreter de ChatGPT si populaire : vous uploadez un fichier CSV, le LLM écrit un script Python, l’exécute, et vous retourne un graphique ou un tableau nettoyé. Le code execution est un cas spécifique de tool-augmented LLM où l’outil est un interpréteur de code dans un sandbox sécurisé.

Comment fonctionne un Code Execution LLM

Le mécanisme suit la boucle standard du function calling, avec le code comme outil :

La boucle Write-Execute-Observe

1. Analyse de la requête : l’utilisateur pose une question ou donne une tâche. Le LLM détermine qu’il a besoin d’exécuter du code pour répondre correctement, par exemple pour effectuer un calcul précis, analyser un fichier ou générer un graphique.

2. Génération du code : le LLM écrit un script (généralement Python) adapté à la tâche. Il peut utiliser des bibliothèques standards (pandas, matplotlib, numpy, etc.) présentes dans l’environnement sandbox.

3. Exécution dans le sandbox : le code est envoyé à un environnement d’exécution isolé (conteneur Docker, machine virtuelle, ou runtime WebAssembly). Ce sandbox n’a aucun accès au système hôte : il ne peut ni lire vos fichiers système, ni accéder au réseau (sauf si explicitement autorisé), ni modifier quoi que ce soit en dehors de son périmètre.

4. Récupération des résultats : le sandbox renvoie la sortie standard (stdout), les erreurs éventuelles (stderr), et les fichiers générés (graphiques PNG, fichiers CSV transformés, etc.).

5. Synthèse : le LLM intègre les résultats dans sa réponse. Si une erreur est survenue, il peut corriger son code et relancer l’exécution (boucle itérative).

6. Itération : sur des tâches complexes, le modèle peut enchaîner plusieurs blocs de code, chaque exécution s’appuyant sur les résultats de la précédente. C’est comparable à l’exécution cellule par cellule dans un notebook Jupyter.

Les implémentations grand public

ChatGPT : Code Interpreter / Advanced Data Analysis

Le Code Interpreter de ChatGPT (renommé Advanced Data Analysis puis réintégré sous le nom générique de code execution) est le produit qui a popularisé le concept. Disponible sur les plans Plus ($20/mois), Pro ($200/mois) et Business, il permet de :

Uploader des fichiers (CSV, Excel, PDF, images) directement dans la conversation. Le LLM écrit du Python pour les analyser, les transformer ou les visualiser. Les graphiques et fichiers générés sont téléchargeables.

L’environnement d’exécution de ChatGPT est un sandbox Python avec les bibliothèques de data science les plus courantes pré-installées (pandas, numpy, matplotlib, seaborn, scipy, etc.). L’accès réseau est désactivé par défaut. C’est l’un des rares chatbots à proposer l’exécution de code dans un contexte grand public sans aucune configuration technique.

Le Code Interpreter donne à ChatGPT un avantage concret pour le debugging Python : il peut réellement exécuter du code pour tester des hypothèses, ce que ni Claude ni Gemini ne proposent de manière aussi intégrée dans l’interface de chat.

Claude : exécution de code et Claude Code

Claude propose l’exécution de code dans l’interface claude.ai pour les abonnés Pro et supérieurs. Le modèle peut écrire et exécuter du code Python directement dans la conversation pour analyser des données, effectuer des calculs ou générer des visualisations.

Mais c’est Claude Code qui pousse le concept le plus loin. Cet outil terminal permet à Claude Opus 4.6 de travailler directement dans votre codebase : il lit des fichiers, exécute des commandes, lance des tests, analyse les stack traces et peut même créer des pull requests sur GitHub. Claude Code transforme le LLM en ingénieur logiciel autonome qui opère dans votre vrai environnement de développement, pas dans un sandbox isolé.

Claude Cowork, la fonctionnalité agentique de Claude pour macOS et Windows, étend cette capacité en permettant au modèle de manipuler des fichiers, exécuter des scripts et produire des livrables multi-étapes sur votre bureau.

Gemini : code execution dans l’API

Gemini propose l’exécution de code via l’API (Google AI Studio et Vertex AI). Le modèle peut générer et exécuter du Python dans un environnement sandboxé. L’intégration avec l’écosystème Google (Colab, BigQuery) est un avantage pour les workflows data science, mais l’expérience d’exécution de code dans l’interface grand public de Gemini est moins polie que celle de ChatGPT.

OpenAI Codex : l’agent de code autonome

OpenAI Codex (lancé en 2025) est un agent de code qui s’exécute dans un environnement cloud sandboxé. Vous lui assignez une tâche (corriger un bug, implémenter une fonctionnalité, écrire des tests), il clone votre dépôt, travaille de manière autonome, et vous soumet le résultat sous forme de pull request ou de diff. Chaque tâche Codex tourne dans un conteneur isolé avec accès réseau contrôlé.

Le sandbox : la pièce maîtresse

Pourquoi un sandbox est indispensable

Exécuter du code généré par un LLM sans sandbox est un risque de sécurité majeur. Le modèle peut générer du code qui, intentionnellement ou non, effectue des opérations dangereuses : suppression de fichiers, exfiltration de données, fork bombs (consommation infinie de ressources), ou accès réseau non autorisé.

Le sandbox fournit plusieurs couches de protection :

Isolation du système de fichiers : le code n’a accès qu’à un répertoire de travail temporaire, jamais au système hôte.

Isolation réseau : l’accès internet est désactivé par défaut. Si nécessaire, il peut être activé avec des politiques restrictives (whitelist de domaines).

Limites de ressources : CPU, mémoire et temps d’exécution sont plafonnés. Un script qui boucle indéfiniment est tué après le timeout.

Pas de persistance : l’environnement est détruit après l’exécution (ou après expiration de la session). Rien ne survit au-delà de la tâche.

Technologies de sandbox

Trois approches techniques dominent :

L’approche conteneur Docker est la plus répandue en production. Le WebAssembly gagne du terrain pour les cas d’usage légers (analyse de données, calculs simples) grâce à son démarrage quasi instantané et l’absence de dépendance à une infrastructure de conteneurs. ChatGPT utilise un sandbox basé sur des conteneurs. Certains fournisseurs récents utilisent Pyodide (Python dans WASM) pour des exécutions côté navigateur.

Plateformes de sandbox cloud

Pour construire votre propre code execution LLM, plusieurs plateformes fournissent l’infrastructure sandbox :

Patterns d’architecture

Pattern intégré (Code Interpreter)

Dans ce pattern, le sandbox est un outil que l’agent appelle ponctuellement. L’agent reste dans un « plan de contrôle » et envoie des blocs de code au sandbox quand il en a besoin. C’est le modèle de ChatGPT Code Interpreter : le LLM décide d’écrire et exécuter du code, récupère le résultat, puis continue la conversation.

Ce pattern convient aux tâches ponctuelles : analyser un fichier, effectuer un calcul, générer un graphique. Le sandbox est éphémère : il est créé pour l’exécution et détruit ensuite.

Pattern découplé (Agent dans le sandbox)

Dans ce pattern, c’est l’agent lui-même (ou sa logique d’exécution) qui réside à l’intérieur du sandbox. Le sandbox reste actif entre les appels, maintient un état persistant (fichiers, variables, bibliothèques installées), et le LLM interagit avec lui sur la durée.

C’est le modèle de Claude Code, de Codex et des agents de code autonomes. L’agent clone un dépôt, installe des dépendances, écrit du code, lance des tests, corrige les erreurs, et soumet le résultat. Le sandbox vit pendant toute la durée de la tâche (minutes à heures).

Ce pattern est plus complexe à mettre en place mais indispensable pour les tâches de développement logiciel réelles : compilation, exécution de suites de tests, interactions avec des bases de données locales.

Cas d’usage concrets

Analyse de données

C’est le cas d’usage le plus courant pour le grand public. Uploadez un fichier CSV ou Excel, demandez « analyse ce fichier et montre-moi les tendances », et le LLM écrit un script pandas/matplotlib, l’exécute, et retourne des graphiques et un résumé statistique. ChatGPT excelle ici grâce à son Code Interpreter directement intégré dans l’interface de chat.

Calculs précis

Les LLM sont notablement mauvais en arithmétique pure. Demandez « quel est 2 847 × 9 362 ? » à un LLM sans code execution, et il peut se tromper. Avec un sandbox, le modèle écrit print(2847 * 9362), exécute, et retourne le résultat exact : 26 653 214. C’est la raison pour laquelle les chaînes de raisonnement complexes bénéficient d’un sandbox : le modèle peut vérifier ses étapes de calcul.

Génération de visualisations

Le LLM écrit du code matplotlib, seaborn ou plotly, l’exécute, et produit des graphiques de qualité professionnelle. L’utilisateur peut itérer (« change les couleurs », « ajoute un titre », « passe en histogramme ») et le modèle adapte le code à chaque tour.

Transformation de fichiers

Convertir un format de fichier, nettoyer des données, fusionner des spreadsheets, extraire du texte d’un PDF : le sandbox donne au LLM les mains pour manipuler concrètement les fichiers, pas seulement en décrire la transformation théorique.

Prototypage rapide

Les outils de vibe coding comme Lovable, Bolt et v0 reposent sur l’exécution de code en temps réel : le LLM génère du code React/HTML, l’exécute dans un sandbox web, et affiche le résultat en prévisualisation. L’utilisateur voit immédiatement le rendu et peut itérer.

Développement logiciel autonome

Claude Code, OpenAI Codex et Cursor Agent Mode utilisent l’exécution de code pour résoudre des issues GitHub de bout en bout. L’agent lit le code existant, écrit les modifications, exécute les tests, corrige les régressions, et soumet un diff propre. Les benchmarks montrent que Claude Opus 4.6 atteint les meilleurs scores sur SWE-bench pour la résolution autonome de bugs réels.

Limites et risques

Sécurité

Le risque principal est l’évasion de sandbox : du code malveillant qui exploite une faille du conteneur pour accéder au système hôte. Les mitigations incluent l’utilisation de runtimes renforcés (gVisor, Firecracker), la désactivation stricte du réseau, et des limites de ressources agressives. En production, ne faites jamais confiance au code généré par le LLM : traitez-le comme du code non fiable (untrusted), car c’est exactement ce qu’il est.

Coût et latence

Chaque exécution de code ajoute de la latence (1 à 10 secondes selon la complexité) et du coût (infrastructure sandbox + tokens supplémentaires pour le code et les résultats dans le contexte). Un agent qui itère 5 fois sur un script avec corrections multiplie le coût. Surveillez le nombre moyen d’exécutions par requête utilisateur.

Langages supportés

La plupart des sandbox grand public ne supportent que Python. C’est suffisant pour l’analyse de données et le scripting, mais limitant pour le développement web (JavaScript/TypeScript), le calcul scientifique (R, Julia), ou la programmation système (Rust, C++). Les sandbox open source comme llm-sandbox et OpenSandbox supportent 7+ langages, mais les environnements intégrés aux chatbots restent centrés sur Python.

Hallucination de code

Le LLM peut écrire du code qui semble correct mais produit des résultats erronés. Par exemple, un script d’analyse qui filtre mal les données ou utilise une formule statistique incorrecte. L’exécution réussit (pas d’erreur), mais le résultat est faux. C’est une forme d’hallucination particulièrement insidieuse car l’utilisateur fait confiance au résultat « calculé ».

La contre-mesure est de demander au LLM d’expliquer sa démarche pas à pas, d’afficher les données intermédiaires, et de vérifier les résultats sur un échantillon connu.

Construire votre propre code execution agent

Via MCP (la plus simple)

Le package open source llm-sandbox propose un serveur MCP intégré. L’installation est directe :

pip install 'llm-sandbox[mcp-docker]'

Ajoutez le serveur dans la configuration de votre client MCP (Claude Desktop, Gemini CLI, etc.), et votre LLM dispose immédiatement d’outils run_python_code et run_javascript_code. Le code s’exécute dans un conteneur Docker local, isolé de votre système.

Via API (plus de contrôle)

Pour une intégration dans votre propre application, utilisez une plateforme comme E2B, Modal ou Together :

1. Définissez un outil execute_code dans votre schéma de function calling avec un paramètre code (string) et optionnellement language.

2. Quand le LLM appelle cet outil, envoyez le code à l’API sandbox.

3. Récupérez stdout, stderr et les fichiers générés.

4. Renvoyez les résultats au LLM pour la suite de la conversation.

5. Implémentez une limite de 3 à 5 tentatives en cas d’erreur d’exécution : le LLM peut corriger son code et réessayer.

Recherche académique : LLM-in-Sandbox

Le papier « LLM-in-Sandbox Elicits General Agentic Intelligence » (publié en janvier 2026 par des chercheurs de Microsoft) démontre que donner à un LLM un accès à un sandbox de code généralisé améliore significativement ses performances sur des tâches non-coding : raisonnement scientifique, compréhension de documents longs, planification, production vidéo et musicale. L’idée clé est que l’exécution de code n’est pas juste un outil de programmation mais une capacité de raisonnement computationnel générale.

La tendance est au « code as universal tool » : plutôt que de construire des outils spécifiques pour chaque tâche (un outil météo, un outil CRM, un outil calcul), le LLM écrit du code qui appelle les API nécessaires. Le sandbox devient le méta-outil qui remplace tous les autres. Certains déploiements MCP utilisent déjà cette approche (Cloudflare « Code Mode »), avec des réductions de consommation de tokens de plus de 98% par rapport au chargement de définitions d’outils traditionnelles.

Évolutions et tendances

La commoditisation de l’exécution de code avance rapidement. Les sandbox cloud (E2B, Modal) proposent des démarrages en moins d’une seconde et un scaling automatique à des dizaines de milliers de sessions simultanées. Le coût par exécution baisse continuellement.

Le WebAssembly (Pyodide) permet d’exécuter du Python directement dans le navigateur sans infrastructure serveur. C’est l’approche utilisée par certains outils de vibe coding pour des prévisualisations instantanées.

Les agents de code autonomes (Claude Code, Codex) brouillent la frontière entre « code execution comme outil » et « code execution comme mode opératoire principal ». L’agent ne fait plus juste un calcul ponctuel : il développe, teste et déploie du logiciel de manière autonome.

L’open source progresse : llm-sandbox (7 langages, support MCP, Docker/Podman/Kubernetes) et OpenSandbox (SDK multi-langage, protocole unifié) offrent des alternatives viables aux solutions cloud pour les organisations qui veulent garder le contrôle de leur infrastructure.