e2b-dev/code-interpreter : exécuter du code généré par un LLM dans un bac à sable distant
Python & JS/TS SDK for running AI-generated code/code interpreting in your AI app
En bref
- De quoi s’agit-il ?
- Le dépôt fournit un modèle de sandbox et un extracteur de données de graphiques, tandis que les SDK Python et JS/TS ont migré vers le monorepo E2B. Voici ce que le README permet réellement de conclure, et ce qu'il laisse en suspens.
- À qui s’adresse-t-il ?
- À adopter si vous voulez exécuter du code produit par un LLM sans héberger vous-même l'isolation, et si l'API E2B vous convient. À éviter si vous devez garder l'exécution sur votre infrastructure ou si vous cherchez un interpréteur local.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 5 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : du code non fiable qui doit quand même s'exécuter
Un assistant qui génère du Python pour analyser un fichier CSV doit bien finir par lancer ce Python quelque part. L'exécuter dans le processus de l'application revient à donner à un modèle de langage un accès direct au système de fichiers et au réseau de l'hôte. Le README présente E2B comme une infrastructure open source qui exécute du code généré par IA dans des sandboxes isolées dans le cloud. Le public visé est donc l'équipe qui construit une application d'analyse de données conversationnelle, pas le data scientist qui veut un notebook interactif. Les topics du dépôt confirment cette orientation : openai, anthropic, cohere, llm, jupyter. Le projet se place entre le modèle et le résultat, pas entre l'utilisateur et le modèle.
Ce qui reste dans ce dépôt, et ce qui n'y est plus
Point à lire avant toute chose : une note du README indique que les sources des SDK @e2b/code-interpreter et e2b-code-interpreter vivent désormais dans le monorepo E2B, sous packages/code-interpreter-js et packages/code-interpreter-python. Les issues et pull requests SDK doivent être ouvertes là-bas. Ce dépôt conserve le template de sandbox et l'extracteur de données de graphiques. La conséquence pratique est double. D'abord, un correctif dans le SDK ne se dépose pas ici. Ensuite, le code que vous lisez dans ce dépôt décrit l'environnement d'exécution, pas la couche qui parle au service. Les releases récentes portent d'ailleurs des noms de paquets publiés (@e2b/code-interpreter@2.7.1, @e2b/code-interpreter-python@2.9.1), avec deux numéros de version distincts, ce qui suggère des cycles de publication séparés entre JavaScript et Python. Le dépôt n'est pas archivé, et le dernier push est daté du 7 septembre 2026.
Le mécanisme : une sandbox persistante et un état de session
L'exemple du README montre un objet Sandbox créé côté client, puis deux appels successifs à runCode. Le premier pose x = 1, le second évalue x+=1; x et renvoie 2 dans execution.text. La variable survit donc entre les appels : la sandbox maintient un état d'interpréteur, ce qui correspond à un noyau de type Jupyter. C'est la différence structurante avec une fonction d'exécution sans état, où chaque appel repart de zéro. En Python, l'objet est utilisé comme gestionnaire de contexte (with Sandbox.create() as sandbox), ce qui indique que la fermeture de la sandbox est liée à la sortie du bloc. En JavaScript, la création se fait avec await Sandbox.create(). Le résultat n'est pas seulement du texte : le README mentionne un extracteur de données de graphiques parmi les composants conservés dans ce dépôt, ce qui laisse entendre que les sorties peuvent inclure des représentations de figures. Le README ne détaille pas le format de ces sorties, ni la manière de les récupérer.
Mise en route : deux commandes et une variable d'environnement
L'installation se fait avec npm i @e2b/code-interpreter ou pip install e2b-code-interpreter. Il faut ensuite une clé API obtenue après inscription sur e2b.dev, à placer dans la variable d'environnement E2B_API_KEY, au format e2b_***. Le premier programme tient en quelques lignes : Sandbox.create(), puis runCode('x = 1'), puis une seconde exécution dont le résultat est lu via execution.text. Le README renvoie à docs.e2b.dev pour la suite et à un cookbook séparé (e2b-dev/e2b-cookbook) pour des exemples avec différents LLM et frameworks. Rien dans le matériel fourni ne décrit les paramètres de runCode, la gestion des erreurs, les délais d'expiration, ni le comportement de la sandbox en cas d'interruption réseau. Ce sont précisément les points qu'un lecteur voudra vérifier dans la documentation avant de s'engager.
Personnaliser le template : la vraie porte de sortie
Le README consacre une section à la personnalisation : si vous avez besoin de paquets supplémentaires ou d'un autre runtime, vous construisez votre propre template de sandbox Code Interpreter. Le guide se trouve dans template/README.md, qui décrit aussi la construction du template de production code-interpreter-v1. C'est l'élément le plus important du dépôt pour une équipe qui a des dépendances exotiques, par exemple une bibliothèque scientifique compilée ou une version figée de Python. La contrepartie n'est pas documentée dans le matériel fourni : construire et maintenir un template, c'est un artefact de plus à versionner et à reconstruire à chaque montée de version de paquets. Le README ne dit rien sur la cadence de reconstruction ni sur la compatibilité entre un template et une version donnée du SDK.
Limites et cas où l'outil ne convient pas
La limite la plus nette est architecturale : l'exécution a lieu dans le cloud d'E2B, pas chez vous. Le README parle explicitement de sandboxes isolées dans le cloud, et le parcours d'installation passe par une inscription et une clé API. Si une contrainte réglementaire ou contractuelle interdit de faire sortir des données ou du code vers un service tiers, ce projet n'est pas l'outil adapté, quelle que soit la qualité de l'isolation. Deuxième réserve : le matériel fourni ne contient aucune information sur les performances, la latence de démarrage d'une sandbox, les quotas, ni la tarification. Un lecteur qui a besoin de chiffres ne les trouvera pas ici. Troisième réserve, plus documentaire : le README est court et renvoie largement vers des ressources externes. Les questions concrètes (que se passe-t-il si le code généré boucle indéfiniment, comment les erreurs remontent-elles, la sandbox a-t-elle un accès réseau) restent sans réponse dans ce que nous avons. Enfin, pour un simple calcul déterministe ou l'exécution de code que vous avez écrit vous-même, la machinerie d'une sandbox distante est disproportionnée : un sous-processus local suffit.
L'alternative : un noyau Jupyter que vous hébergez
L'alternative la plus proche est un déploiement Jupyter auto-hébergé, avec Jupyter Kernel Gateway ou un serveur Enterprise Gateway, derrière un conteneur par session. La différence n'est pas cosmétique. Avec E2B, vous ne gérez ni l'orchestration des conteneurs, ni l'isolation réseau, ni le cycle de vie des noyaux : vous appelez Sandbox.create() et vous fermez le bloc. Avec un déploiement Jupyter maison, vous gardez le contrôle total du réseau, des images et des journaux, mais vous prenez en charge l'isolation, l'élimination des sessions orphelines et la limitation des ressources. Le modèle d'état est comparable dans les deux cas (un noyau persistant, des cellules successives), ce qui rend la migration conceptuellement simple et opérationnellement coûteuse. Le choix se résume donc à un arbitrage entre contrôle et charge d'exploitation, pas entre deux paradigmes d'exécution.
Maintenance, versions et licence
Le suivi des versions demande de l'attention : les SDK sont publiés depuis le monorepo, avec des numéros distincts pour JavaScript (2.7.1) et Python (2.9.1). Une équipe qui utilise les deux langages doit donc suivre deux fils de publication, et le README précise que les issues SDK se traitent dans e2b-dev/E2B. Le dépôt sous licence Apache-2.0 permet l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation des mentions de copyright et du texte de licence, et une clause de brevets. Le README ne mentionne aucun fichier NOTICE ni condition supplémentaire. Pour un avis juridique, consultez votre service compétent : ce paragraphe décrit le texte de la licence, il ne l'interprète pas. Enfin, la personnalisation du template crée une dette de maintenance propre : chaque mise à jour de paquets dans le template doit être reconstruite et testée contre la version du SDK en service.
Conclusion éditoriale
À adopter si vous voulez exécuter du code produit par un LLM sans héberger vous-même l'isolation, et si l'API E2B vous convient. À éviter si vous devez garder l'exécution sur votre infrastructure ou si vous cherchez un interpréteur local. Vérifiez d'abord le contenu de template/README.md et la disponibilité de packages/code-interpreter-python dans le monorepo.
Notes de la communauté