E2B : des sandboxes cloud pour exécuter du code produit par un LLM
Open-source, secure environment with real-world tools for enterprise-grade agents.
En bref
- De quoi s’agit-il ?
- E2B est une infrastructure open source qui isole l'exécution de code généré par une IA dans des sandboxes cloud, pilotées par un SDK Python ou JavaScript. Le projet est mûr côté SDK, mais l'auto-hébergement reste une affaire de Terraform sur AWS ou GCP.
- À qui s’adresse-t-il ?
- E2B convient aux équipes qui font déjà tourner du code non fiable produit par un modèle et qui veulent déléguer la partie isolation à un service, avec un SDK Python ou JavaScript. Il ne convient pas à qui doit tout faire tourner sur un parc Linux existant ou sur Azure : le guide d'auto-hébergement ne couvre qu'AWS et GCP, et la mention Azure et machine Linux générique reste décochée dans le README.
- 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. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- 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 : du code non fiable dans votre processus
Un agent qui écrit du Python doit bien finir par l'exécuter quelque part. L'exécuter dans le processus qui appelle le modèle revient à donner à une sortie de LLM les mêmes droits que votre application : accès au système de fichiers, au réseau, aux variables d'environnement, aux identifiants. Le README d'E2B formule l'objectif sans détour : faire tourner du code généré par une IA dans des sandboxes isolées, dans le cloud, et contrôler ces sandboxes depuis un SDK JavaScript ou Python. La cible est donc l'équipe qui construit un agent, un copilote ou un interpréteur de code, et qui ne veut pas écrire elle-même la couche d'isolation, de cycle de vie et de streaming des sorties.
Le projet ne se présente pas comme un moteur d'exécution local. C'est une infrastructure : un service qui crée des environnements à la demande, les expose via une API, et fournit des clients pour les piloter. Cette séparation est le choix de conception central, et elle a des conséquences pratiques sur le déploiement, le coût et la latence, qu'on retrouve dans toutes les sections qui suivent.
Ce que reçoit le SDK quand vous appelez create()
Le mécanisme visible dans le README tient en trois objets. Sandbox.create() démarre un environnement isolé et renvoie un handle. Ce handle expose des sous-API spécialisées : sandbox.commands.run() pour exécuter une commande shell et récupérer stdout, et, dans un package séparé, runCode() pour du code interprété. La documentation donne l'exemple d'un x = 1; x += 1; x qui renvoie 2 via execution.text, ce qui indique que le SDK ne se contente pas de capturer stdout : il remonte aussi les valeurs évaluées et les résultats structurés.
Cette séparation en packages est le point d'architecture à retenir. Le SDK de base (pip install e2b, npm i e2b) ne sait lancer des commandes que dans un shell. Pour exécuter du code avec un modèle d'exécution dédié, il faut installer e2b-code-interpreter ou @e2b/code-interpreter. Pour piloter une souris, un clavier, des captures d'écran et le streaming d'un bureau, il faut un troisième package, e2b-desktop ou @e2b/desktop, avec des appels comme desktop.launch('google-chrome') et desktop.screenshot(). Trois niveaux de capacité, trois dépendances distinctes : vous ne payez en surface d'API que ce que vous installez.
Le README ne détaille pas l'implémentation interne des sandboxes, ni le mécanisme d'isolation, ni la façon dont les images sont construites. Ces éléments sont renvoyés vers le dépôt e2b-dev/infra et la documentation. Toute affirmation sur le niveau d'isolation réel (namespaces, microVM, gVisor) serait donc une supposition de ma part, et je ne la fais pas.
Mise en route : trois commandes et une variable d'environnement
Le parcours d'installation est court. Côté Python, pip install e2b ; côté JavaScript, npm i e2b. Il faut ensuite une clé API, obtenue après inscription sur e2b.dev, puis exposée dans l'environnement sous le nom E2B_API_KEY, avec la forme e2b_***. Le SDK la lit depuis cette variable : le README ne montre aucun passage explicite de la clé en argument.
Le premier programme tient en quelques lignes. En Python, un bloc with Sandbox.create() as sandbox ouvre la sandbox, sandbox.commands.run('echo "Hello from E2B!"') renvoie un objet dont result.stdout contient la sortie. En TypeScript, la même séquence avec await Sandbox.create() et une variable const sandbox. Le contexte with en Python suggère que la sandbox est libérée à la sortie du bloc, ce qui est le comportement attendu d'un gestionnaire de contexte, mais le README ne décrit pas la politique d'expiration côté service.
Pour le code interprété, l'import change : from e2b import Sandbox devient import { Sandbox } from '@e2b/code-interpreter' en TypeScript, et le paquet Python correspondant est e2b-code-interpreter. Un détail qui compte : la classe s'appelle Sandbox dans les trois packages. Un copier-coller d'un exemple de commandes vers un exemple de code interpreter sans changer la ligne d'import produit donc un objet qui a la bonne forme mais pas la bonne méthode. C'est le genre d'erreur que la documentation ne signale pas explicitement.
Auto-hébergement : Terraform, AWS et GCP, et rien d'autre
Le README renvoie vers un guide d'auto-hébergement situé dans le dépôt e2b-dev/infra. L'infrastructure y est décrite comme déployée avec Terraform. La liste des fournisseurs pris en charge est explicite et vaut la peine d'être lue telle quelle : AWS et GCP sont marqués comme pris en charge, Azure et la machine Linux générique ne le sont pas. C'est la contrainte la plus concrète du projet.
Si votre organisation est sur Azure, ou si vous espériez installer E2B sur un serveur que vous administrez déjà, le chemin n'est pas documenté. Cela ne veut pas dire qu'il est impossible, mais il n'existe pas de procédure de référence dans le matériel fourni. Pour une équipe qui a déjà des compétences Terraform et un compte AWS ou GCP, en revanche, l'auto-hébergement est un chemin prévu, pas un contournement.
Il faut noter la répartition des dépôts. Le dépôt principal contient les SDK et la documentation ; l'infrastructure vit dans un dépôt séparé. Adopter E2B en auto-hébergement signifie donc suivre deux bases de code, avec des cycles de publication potentiellement différents. Le README ne donne aucune information sur la compatibilité entre une version de SDK et une version d'infrastructure, ce qui est une lacune réelle pour quiconque prévoit de mettre à jour l'un sans l'autre.
Le cas où E2B n'est pas le bon outil
E2B suppose un appel réseau vers un service qui crée la sandbox. Si votre contrainte est l'exécution hors ligne, sur un poste de développeur ou dans un environnement sans accès sortant, l'architecture décrite ici ne répond pas au besoin : le SDK pilote des sandboxes distantes, pas un processus local isolé. De même, si votre charge est un unique script de quelques lignes exécuté une fois par requête, la mise en place d'un service de sandbox, d'une clé API et d'un cycle de vie d'environnement ajoute une couche dont le bénéfice n'est pas évident face à un sous-processus restreint.
Le point le plus délicat concerne l'image de la sandbox. Le README ne liste nulle part les outils, runtimes ou bibliothèques préinstallés dans l'environnement par défaut. Or c'est précisément ce qui détermine si votre code généré s'exécute ou échoue sur un import manquant. Un agent qui produit du code utilisant une bibliothèque scientifique non présente dans l'image se heurtera à une erreur d'exécution, et le matériel fourni ne permet pas de savoir à l'avance lesquelles sont disponibles. C'est une vérification à faire avant de s'engager, pas après.
Enfin, la question du périmètre de confiance reste ouverte. Le projet s'intitule "secure environment", mais le README ne documente ni le modèle de menace, ni les garanties d'isolation, ni la politique de sortie réseau des sandboxes. Une équipe qui traite du code hostile, et pas seulement du code maladroit généré par un modèle, doit obtenir ces réponses ailleurs que dans ce README.
Face à un conteneur Docker que vous gérez vous-même
L'alternative la plus directe est un conteneur Docker lancé à la demande depuis votre application, avec les mêmes appels d'exécution. La différence n'est pas dans le principe d'isolation mais dans ce que vous prenez en charge. Avec Docker, vous gérez le cycle de vie du conteneur, le nettoyage après incident, la limitation de ressources, la journalisation des sorties et la montée en charge. Avec E2B, ces éléments sont délégués à un service, et vous consommez une API. Le prix de cette délégation est la dépendance à un service externe et à sa disponibilité, plus la question du traitement des données que vous envoyez exécuter.
L'autre différence tient à la surface fonctionnelle. Un conteneur Docker expose un shell, et vous construisez vous-même l'interprétation de code et le contrôle de bureau. E2B fournit ces deux couches comme des packages distincts, avec runCode() d'un côté et les appels launch() et screenshot() de l'autre. Si votre agent doit interagir avec une interface graphique, refaire cette partie sur Docker représente un travail substantiel que le SDK Desktop évite.
Le choix se ramène donc à une question de compétences disponibles : une équipe qui exploite déjà des conteneurs en production trouvera probablement l'auto-hébergement Terraform d'E2B plus lourd qu'une solution maison, tandis qu'une équipe sans cette expertise gagnera à externaliser.
Licence, versions et coût de suivi
Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation des mentions de licence et d'état des modifications. Elle comporte aussi une clause de brevets. Je ne donne pas d'avis juridique : faites relire l'usage prévu par votre service juridique, en particulier si vous redistribuez l'infrastructure modifiée.
Le rythme de publication observé est élevé. Les versions fournies montrent e2b@2.49.0 et @e2b/python-sdk@2.49.0 datées du même jour, précédées de e2b@2.48.0 le même jour également. Deux versions en une journée sur le paquet principal, avec des numéros mineurs alignés entre le paquet npm et le paquet PyPI. Cette synchronisation est une bonne nouvelle pour la parité des SDK, mais elle implique un rythme de mise à jour soutenu si vous suivez les versions de près. Une stratégie de version figée, avec des montées planifiées, est plus réaliste qu'un suivi continu pour une équipe petite.
Le coût de maintenance dépend surtout du mode de déploiement choisi. En service hébergé, la maintenance se limite au SDK et à la clé API. En auto-hébergement, il faut ajouter le suivi du dépôt d'infrastructure, l'état Terraform sur AWS ou GCP, et la compatibilité entre les deux dépôts, point sur lequel le matériel fourni ne dit rien. C'est là que se concentre l'essentiel de l'effort à long terme.
Conclusion éditoriale
E2B convient aux équipes qui font déjà tourner du code non fiable produit par un modèle et qui veulent déléguer la partie isolation à un service, avec un SDK Python ou JavaScript. Il ne convient pas à qui doit tout faire tourner sur un parc Linux existant ou sur Azure : le guide d'auto-hébergement ne couvre qu'AWS et GCP, et la mention Azure et machine Linux générique reste décochée dans le README. Avant d'adopter, vérifiez le contenu réel de la sandbox par défaut, les packages déjà présents dans l'image, et si votre cas d'usage exige le SDK Code Interpreter ou Desktop plutôt que le SDK de base.
Notes de la communauté