E2B Desktop Sandbox : un bureau virtuel pour agents qui pilotent une souris

Le problème : un LLM ne peut pas cliquer

Un modèle de langage produit du texte. Beaucoup de tâches utiles se terminent dans une interface graphique : remplir un formulaire dans un navigateur, ouvrir un IDE, manipuler une application de bureau sans API. Brancher un LLM sur ces tâches suppose trois choses que le projet tente de fournir d'un bloc : une machine isolée, un moyen d'agir sur la souris et le clavier, et un retour visuel pour que l'agent ou l'humain qui l'observe voie ce qui se passe. Le README résume la cible en une phrase : un « open source secure virtual desktop ready for Computer Use ». Le public visé est donc l'ingénieur qui construit un agent de type computer use et qui ne veut pas assembler lui-même l'hyperviseur, le serveur VNC et l'authentification du flux. Le projet se présente comme un modèle de sandbox posé au-dessus d'E2B Sandbox, pas comme un framework d'agent complet.

Ce qui vit encore dans ce dépôt, et ce qui n'y vit plus

C'est le point le plus important pour quiconque évalue le projet aujourd'hui. Une note du README indique que les sources des SDK @e2b/desktop et e2b-desktop ont été déplacées vers le monorepo E2B, sous packages/desktop-js et packages/desktop-python, et que les tickets et pull requests SDK doivent désormais y être ouverts. Ce dépôt conserve le modèle de sandbox et les exemples. Les versions publiées confirment deux chaînes distinctes : @e2b/desktop-python@2.4.2 en juillet 2026 et @e2b/desktop@2.3.1 en juin 2026. La conséquence pratique est double. D'abord, lire l'historique des commits de ce dépôt ne vous dira rien sur l'évolution de l'API Python ou JavaScript. Ensuite, un correctif sur un comportement de souris se dépose ailleurs que là où vous avez trouvé l'exemple. Le dépôt reste utile comme référence de modèle et comme vitrine d'usage, mais il n'est plus le centre de gravité du code que vous allez importer.

Créer un bureau, lancer une application, ouvrir un flux

Le mécanisme visible dans le README tient en quatre étapes. On instancie un sandbox avec Sandbox.create(), on lance une application par son nom (desktop.launch('google-chrome'), avec vscode et firefox cités comme alternatives), on attend avec desktop.wait(10000) que la fenêtre apparaisse, puis on démarre un flux. Le commentaire du README précise que dix secondes correspondent à l'attente d'ouverture de l'application dans l'exemple, pas à une garantie. Le flux accepte un window_id, obtenu via desktop.get_current_window_id() ou desktop.get_application_windows("Firefox") pour cibler une application précise. Sans window_id, c'est le bureau entier qui est diffusé. L'authentification s'active avec require_auth=True, et la clé se récupère par desktop.stream.get_auth_key() avant de construire l'URL avec desktop.stream.get_url(auth_key=auth_key). Le contrôle de la souris passe par une API plate et explicite : left_click, right_click, middle_click, double_click, scroll avec un signe positif vers le haut, move_mouse(x, y), drag((100, 100), (200, 200)), mouse_press et mouse_release. Les équivalents JavaScript suivent la même nomenclature en camelCase. Rien dans ce que montre le README ne décrit un modèle de perception ni une boucle de décision : l'agent, c'est vous.

La contrainte du flux unique

Le README encadre le streaming de fenêtre d'un avertissement en trois points : une erreur est levée si l'application visée n'est pas encore ouverte, le flux se ferme quand l'application se ferme, et plusieurs flux simultanés ne sont pas pris en charge. Il faut arrêter le flux courant avant d'en démarrer un autre pour une autre application. Cette dernière règle a des conséquences de conception qu'il vaut mieux voir avant d'écrire l'agent. Un scénario qui alterne entre deux fenêtres, par exemple copier une valeur depuis un navigateur et la coller dans un éditeur, impose une chorégraphie de stop et start à chaque bascule. Si votre agent s'appuie sur une capture d'écran pour décider de son action suivante, cette alternance devient un coût par étape. La parade la plus simple est de diffuser le bureau entier plutôt qu'une fenêtre, ce que l'API permet en omettant window_id. On perd le cadrage serré sur une application, on gagne la stabilité du flux. Le README ne documente pas de coût de bande passante ni de latence pour l'une ou l'autre option, et je ne peux pas trancher ce point à partir de ce matériel.

Mise en route : clé, paquet, variables

Trois commandes suffisent pour l'installation, telles que le README les donne. Côté Python, pip install e2b-desktop. Côté JavaScript, npm install @e2b/desktop. Avant cela, il faut créer un compte E2B et définir la variable d'environnement E2B_API_KEY avec la clé obtenue. C'est le seul paramètre d'authentification mentionné dans le matériel fourni. Le cycle de vie se termine par desktop.kill(), présent dans l'exemple mais commenté, ce qui laisse entendre que la libération des ressources est à votre charge. Aucun fichier de configuration, aucune clé de configuration au-delà de E2B_API_KEY n'apparaît dans le README. Les exemples fournis dans le dépôt se répartissent en deux familles : basic-python et basic-javascript d'un côté, streaming-apps-python et streaming-apps-javascript de l'autre. Deux projets liés sont cités comme démonstrations complètes : Open Computer Use, décrit comme du computer use bâti sur des LLM entièrement open source, et Surf, un agent OpenAI Computer Use qui tourne en application Next.js. Ces deux références sont plus instructives que l'extrait de README pour juger de la forme réelle d'une boucle d'agent.

Le point faible : pas de recette de boucle d'agent

Le dépôt fournit des primitives, pas une politique. Il n'y a pas de gestion d'attente après une action, pas de mécanisme de vérification qu'un clic a produit l'effet attendu, pas de gestion d'erreur décrite pour une application qui ne se lance pas. L'exemple le plus révélateur est le wait(10000) : une durée fixe, choisie pour la démonstration, insérée entre le lancement et le streaming. Un agent en production devra remplacer cette constante par une attente conditionnelle, et le matériel fourni ne dit pas quelles primitives existent pour cela. Autre angle mort : le README ne décrit aucune isolation réseau, aucun quota de ressources, aucun délai d'expiration de sandbox. La promesse d'isolation entre sandboxes est énoncée en introduction, sans détail sur ce qui est isolé. Pour un cas d'usage où l'agent manipule des identifiants ou des données sensibles, cette absence de documentation est le premier élément à lever avant de s'engager, et elle ne se lève pas en lisant ce dépôt.

Face à un navigateur piloté par Playwright ou Selenium

L'alternative la plus directe pour une tâche web n'est pas un autre bureau virtuel, c'est l'automatisation de navigateur. Playwright et Selenium pilotent le DOM et exposent des sélecteurs, des attentes sur des conditions précises et des captures ciblées. L'agent raisonne alors sur une structure de page, pas sur des coordonnées. La différence d'approche est nette : ici, move_mouse(100, 200) et left_click(x=100, y=200) supposent que l'agent sait où se trouve la cible et que la mise en page ne bouge pas entre la décision et l'action. Un décalage de quelques pixels, une bannière qui apparaît, et le clic tombe à côté. En échange, le bureau virtuel couvre ce que Playwright ne couvre pas : une application native, un IDE, un logiciel sans API. Le choix se fait donc sur la nature de la cible, pas sur la qualité des deux outils. Si toutes vos cibles sont des pages web, le bureau graphique ajoute une couche de perception par pixels et une contrainte de flux unique sans rien apporter.

Licence, maintenance et ce qu'il reste à vérifier

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'avis de licence. Je ne donne pas d'avis juridique : faites relire la notice si vous redistribuez le modèle. Le coût de maintenance se lit dans la structure du projet plus que dans son code. Le déplacement des SDK vers le monorepo E2B signifie que vos dépendances Python et JavaScript évoluent sur un calendrier que ce dépôt ne pilote pas, et que les numéros de version divergent déjà entre les deux langages. Un correctif de comportement de souris se suivra dans packages/desktop-python, pas ici. Concrètement, avant d'adopter, vérifiez que la version du paquet que vous installez correspond à une version publiée du monorepo, et testez vous-même le comportement de fermeture de flux décrit dans l'avertissement du README : c'est le point qui casse le plus silencieusement une boucle d'agent, puisque le flux se ferme avec l'application sans que votre code en soit averti autrement.

Conclusion éditoriale

À adopter si vous voulez donner à un agent un bureau complet (Chrome, Firefox, VS Code) sans écrire vous-même la couche VM, le flux vidéo et l'authentification du flux. À éviter si votre agent n'a besoin que de lire des pages web : un navigateur headless coûte moins cher et se parallélise sans la contrainte de flux unique. Avant de vous engager, vérifiez deux points précis : que le paquet e2b-desktop que vous installez correspond bien à la version publiée dans le monorepo E2B, et que votre boucle d'agent tolère l'arrêt du flux à la fermeture de la fenêtre ciblée.

Sources officielles

1. e2b-dev/desktop on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases