open-computer-use : un agent qui pilote un bureau Linux dans un bac à sable E2B
AI computer use powered by open source LLMs and E2B Desktop Sandbox
En bref
- De quoi s’agit-il ?
- Le projet e2b-dev/open-computer-use branche des modèles open source sur un bureau Linux hébergé dans un sandbox E2B, avec un flux vidéo côté client et une séparation explicite entre localisation visuelle et décision d'action.
- À qui s’adresse-t-il ?
- À adopter si vous voulez expérimenter le computer use avec des modèles ouverts sans monter vous-même une machine virtuelle : le couple E2B Desktop Sandbox plus config.py rend le changement de modèle mécanique. À éviter si vous avez besoin d'un pilotage fiable de votre propre poste de travail ou d'un déploiement sans dépendance à un service cloud tiers, car le sandbox est ici le seul environnement d'exécution et le README ne documente aucune exécution locale.
- 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 68 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 : faire agir un modèle sur un bureau, pas seulement en parler
Un modèle de langage qui décrit une manipulation d'interface ne fait rien. Il faut un environnement où cliquer, taper et lancer des commandes ont un effet réel, et où une erreur ne détruit pas la machine de l'utilisateur. C'est le point de départ de open-computer-use. Le README présente le projet comme un ordinateur Linux cloud sécurisé, propulsé par E2B Desktop Sandbox et contrôlé par des LLM open source. Autrement dit, l'agent ne raisonne pas dans le vide : il dispose d'un clavier, d'une souris et d'un shell, et il opère sur une machine distante jetable. Le public visé est assez précis. Ce sont des développeurs qui veulent tester des modèles de computer use sans écrire eux-mêmes la boucle perception-action, et qui acceptent en échange de dépendre d'E2B pour l'exécution. Le dépôt est en Python, publié sous Apache-2.0, et le README insiste sur un point : l'agent utilise Ubuntu, mais il est conçu pour fonctionner avec n'importe quel système d'exploitation. Cette phrase mérite d'être lue avec prudence, car le sandbox fourni est bien un bureau Linux.
Trois modèles plutôt qu'un, et pourquoi cela change la boucle
La conception la plus intéressante du projet tient dans la séparation des rôles. Le fichier config.py distingue un grounding_model, un vision_model et un action_model. Le README donne cet exemple : grounding_model = providers.OSAtlasProvider(), vision_model = providers.GroqProvider("llama3.2"), action_model = providers.GroqProvider("llama3.3"). Le modèle de grounding sert à localiser un élément à l'écran, le modèle de vision à interpréter ce qui est affiché, le modèle d'action à décider quoi faire. Cette décomposition a une conséquence pratique : on peut faire tourner la localisation sur un modèle spécialisé disponible gratuitement sur Hugging Face Spaces, et réserver un modèle plus coûteux à la seule prise de décision. C'est un choix d'ingénierie, pas une simple liste de fournisseurs. Il impose aussi une contrainte : chaque modèle doit être exposé via providers.py, et le README demande explicitement une pull request si vous en ajoutez un. Les fournisseurs listés couvrent Fireworks, OpenRouter, Llama API, Groq, DeepSeek, Google, OpenAI, Anthropic, Moonshot, Mistral AI, plus OS-Atlas et ShowUI via Hugging Face Spaces. Tous ne font pas tout : Llama 3.2 est décrit comme vision seule chez Fireworks, vision et action chez Groq, tandis que DeepSeek est action seule. Lire cette liste avant de configurer quoi que ce soit évite de perdre une soirée.
Le flux : un sandbox qui streame son écran, un utilisateur qui peut interrompre
Le README résume le fonctionnement en quelques lignes : l'agent opère l'ordinateur via le clavier, la souris et des commandes shell, et l'affichage du sandbox est diffusé en direct sur la machine cliente. Un utilisateur peut mettre l'agent en pause et lui donner une instruction à tout moment. C'est un point de contrôle important, car un agent qui clique sans surveillance est difficile à arrêter. La capture d'écran voyage donc du sandbox vers le client, et le client peut injecter un prompt au milieu d'une exécution. Le dépôt renvoie vers une image d'architecture dans assets/ et vers un article de blog pour les détails du design. Je n'ai pas ce contenu sous les yeux, donc je ne peux pas décrire le protocole exact entre le client et le sandbox, ni la fréquence de capture, ni le format d'échange. Ce que le matériel fourni permet d'affirmer s'arrête là : il y a un flux vidéo, il y a une boucle d'action, et il y a une intervention humaine possible.
Mise en route : poetry, ffmpeg et un fichier .env
L'installation suppose Python 3.10 ou plus récent, git, une clé API E2B et une clé pour au moins un fournisseur de LLM. Sur macOS, le README propose brew install poetry ffmpeg. ffmpeg n'est pas décoratif : c'est lui qui rend le flux d'affichage exploitable côté client. Le dépôt se clone avec git clone https://github.com/e2b-dev/open-computer-use/, puis on crée un fichier .env dans le dossier open-computer-use. La variable obligatoire est E2B_API_KEY. S'y ajoutent les clés des fournisseurs réellement utilisés dans config.py : FIREWORKS_API_KEY, OPENROUTER_API_KEY, LLAMA_API_KEY, GROQ_API_KEY, GEMINI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, MOONSHOT_API_KEY. Le README précise que les Hugging Face Spaces ne demandent pas de clé, mais que HF_TOKEN reste nécessaire pour contourner les limites de débit de Gradio. C'est une subtilité facile à manquer : le grounding via OS-Atlas ou ShowUI n'a pas de clé propre, et pourtant sans HF_TOKEN l'appel peut être refusé. Le lancement se fait en deux temps, poetry install puis poetry run start. On peut passer une consigne directement : poetry run start --prompt "use the web browser to get the current weather in sf". Le README indique que le flux d'affichage apparaît quelques secondes après le démarrage du programme Python.
Ce que le dépôt ne dit pas sur la fiabilité
Les limites les plus visibles ne sont pas techniques, elles sont documentaires. Le README annonce la prise en charge de plus de dix LLM, mais ne publie aucun taux de réussite, aucune mesure de latence, aucune comparaison entre modèles. Il n'y a pas de section sur les cas d'échec connus, ni sur les tâches que l'agent ne sait pas accomplir. C'est un manque réel quand on doit décider d'un déploiement. Un agent qui pilote un bureau se trompe de façon coûteuse : un clic au mauvais endroit peut valider un formulaire, supprimer un fichier ou envoyer un message. Le fait que le sandbox soit isolé limite les dégâts, mais ne les supprime pas si l'agent est connecté à des services externes depuis l'intérieur du sandbox. Autre point : le projet dépend d'E2B pour l'exécution et de Hugging Face Spaces pour le grounding par défaut. Ce sont deux services externes dans le chemin critique. Le README ne décrit aucune procédure de repli si l'un des deux est indisponible. Enfin, la liste des versions de modèles citées (Llama 3.2, Llama 3.3, Gemini 2.0 Flash, GPT-4o) vieillit vite, et rien n'indique comment le dépôt gère les dépréciations côté fournisseur.
Face à un agent qui code plutôt qu'un agent qui clique
L'alternative la plus proche n'est pas un autre projet de computer use, c'est une approche différente du même besoin : donner à l'agent un shell et des outils en ligne de commande plutôt qu'un écran et une souris. Un agent qui exécute des commandes dans un conteneur obtient un résultat déterministe, journalisable, et reproductible. open-computer-use fait le pari inverse : il passe par la perception visuelle et la simulation d'entrée, ce qui permet d'attaquer des interfaces qui n'ont pas d'API, mais introduit une couche d'incertitude à chaque étape. La différence n'est pas une question de qualité, c'est une question de nature du problème. Si votre tâche consiste à remplir un formulaire web sans API, l'approche visuelle est la seule disponible. Si votre tâche consiste à manipuler des fichiers ou à interroger un service, un shell sera plus rapide à déboguer et plus simple à tester. Le choix de open-computer-use se justifie quand l'interface graphique est le seul point d'entrée.
Maintenance, licence et coût réel d'un tel montage
Le dépôt est sous Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation de la licence et des mentions. Je ne donne pas d'avis juridique : faites relire le texte si vous intégrez le code dans un produit distribué. Le coût de maintenance se répartit sur trois postes. D'abord les modèles : chaque fournisseur peut retirer ou renommer une version, et le README indique lui-même que les contributions à providers.py sont attendues, ce qui suggère que la liste est maintenue à la main. Ensuite les dépendances : poetry gère l'environnement, et ffmpeg doit être présent sur la machine cliente, ce qui complique un déploiement sur un poste verrouillé. Enfin le service E2B : chaque session de sandbox consomme du quota, et le README ne donne aucune estimation de durée de vie d'un sandbox ni de coût par tâche. Le dépôt n'a pas de release publiée au moment de la rédaction, donc il n'existe pas de version étiquetée sur laquelle épingler une dépendance. Cela signifie que suivre la branche master est le seul mode d'installation documenté, avec ce que cela implique de surprises possibles.
Conclusion éditoriale
À adopter si vous voulez expérimenter le computer use avec des modèles ouverts sans monter vous-même une machine virtuelle : le couple E2B Desktop Sandbox plus config.py rend le changement de modèle mécanique. À éviter si vous avez besoin d'un pilotage fiable de votre propre poste de travail ou d'un déploiement sans dépendance à un service cloud tiers, car le sandbox est ici le seul environnement d'exécution et le README ne documente aucune exécution locale. Avant de vous engager, vérifiez trois choses concrètes : la disponibilité de OS-Atlas et ShowUI sur Hugging Face Spaces, la présence du fichier providers.py pour le modèle que vous visez, et le fait que la commande poetry run start exige ffmpeg sur la machine cliente.
Notes de la communauté