Les agents IA ont besoin de vrais bureaux

Les sandboxes, c'était l'étape un. Les agents ont besoin de vrais bureaux.

E2B et les plateformes sandbox similaires ont vu juste sur un point : laisser un agent IA exécuter du code dans un conteneur isolé, récupérer le résultat, tout jeter. Propre, rapide, pas cher. Pour exécuter une fonction Python ou traiter un CSV, ça suffit largement.

Sauf que le travail des agents change. Ils naviguent sur des sites, remplissent des formulaires, manipulent des documents, enchaînent des workflows sur plusieurs heures. Et les sandboxes n'ont jamais été conçues pour ça. Elles ont été conçues pour l'exécution de code, et elles le font bien. Le problème, c'est que l'exécution de code représente une part de plus en plus mince de ce qu'on demande aux agents.

Ce que les sandboxes font bien

Une sandbox démarre en moins d'une seconde. Ça ne coûte presque rien par invocation. L'isolation du code non fiable est solide. Et le modèle mental est limpide : entrée, sortie, environnement détruit.

Pour du traitement par lots, des scripts ponctuels, des transformations de données rapides, la sandbox reste le bon outil. Je ne dis pas qu'il faut s'en débarrasser.

Je dis que l'industrie construit des agents de plus en plus capables, puis les enferme dans des environnements conçus pour exécuter des scripts.

Là où le modèle craque

Dès qu'on dépasse le "exécute cette fonction, renvoie le résultat", les sandboxes commencent à poser problème.

Aucune persistance

Une sandbox meurt après chaque tâche. Fichiers, configs, contexte : tout disparaît. On peut bricoler une couche de persistance, sérialiser l'état, le recharger dans un nouveau conteneur. Mais là on construit de la gestion d'état par-dessus une architecture dont le principe fondateur est justement l'absence d'état. À un moment, on se bat contre l'outil au lieu de s'en servir.

Un agent qui itère sur un codebase pendant trois jours ne devrait pas avoir à reconstruire son environnement à chaque session.

Pas d'écran

La plupart des sandboxes offrent un terminal, point. Pas de navigateur, pas d'interface graphique, pas de retour visuel. Ça suffisait quand les agents se contentaient d'exécuter des scripts. Maintenant on a des agents computer use qui naviguent sur des sites, lisent des mises en page et interagissent avec des applications graphiques.

Essayez ça dans une sandbox : "Va sur ce site, trouve la page tarifs, extrais les détails des offres." L'agent doit passer par de l'automatisation headless, parser du HTML brut, et espérer que la page n'a pas besoin de JavaScript pour s'afficher. Sur un bureau, l'agent ouvre Chrome et regarde la page. Comme vous le feriez.

L'interface graphique n'est pas un bonus. La majorité des logiciels au monde ont été conçus pour elle.

Pas d'accès système

Les sandboxes verrouillent l'OS volontairement. Impossible d'installer des paquets, de lancer des services, de configurer quoi que ce soit au niveau système. C'est justifié côté sécurité. Mais ça veut aussi dire qu'un agent ne peut pas monter un environnement de dev, installer LibreOffice pour du traitement de documents, ou lancer une base de données pour tester.

Ce ne sont pas des besoins exotiques. C'est le quotidien.

Impossible d'observer

Quand un agent tourne dans une sandbox, on voit la sortie après coup. On ne peut pas le regarder travailler, intervenir s'il déraille, ou comprendre pourquoi il a pris telle décision. Pour une exécution de 5 secondes, pas de souci. Pour une tâche de recherche de 3 heures, c'est piloter à l'aveugle.

C'est une question de confiance. Si on déploie des agents en contexte professionnel, il faut pouvoir vérifier ce qu'ils font, pas juste lire le résultat final.

Une seule tâche à la fois

Les sandboxes gèrent une tâche par session. Mais le vrai travail implique plusieurs applications en parallèle : un navigateur pour la recherche, un terminal pour le traitement, un éditeur pour les notes, un tableur pour l'analyse. Le tout persistant entre les sessions.

Ce n'est pas un cas limite. C'est comme ça que le travail intellectuel fonctionne.

Ce qu'un bureau apporte

On a construit Le Bureau autour d'une idée différente : donner à l'agent le même environnement qu'un humain utiliserait. Chaque agent reçoit un bureau Linux persistant avec une interface graphique accessible en VNC. Il peut ouvrir un navigateur, installer des logiciels, gérer des fichiers. Le bureau survit entre les sessions : les livrables, les configs et les outils restent en place.

Concrètement, ça donne :

• L'agent et l'opérateur voient le même écran en temps réel via le streaming VNC. On peut observer, intervenir, approuver des actions.
• Le disque persiste. L'agent reprend là où il s'est arrêté, sans cérémonie de sérialisation.
• Accès OS complet. apt install ce qu'il faut. Lancer des services. Configurer le système.
• Environnement Linux standard : ajouter un outil, c'est juste installer un logiciel. Pas d'adaptateurs SDK, pas de wrappers.

Exemples concrets

Prenons un agent qui analyse les tarifs de concurrents. Il a besoin d'un vrai navigateur avec rendu JavaScript, gestion des cookies, et la capacité de voir à quoi ressemble réellement la page. L'automatisation headless fait la moitié du chemin. Un bureau avec Chrome fait le reste.

Le traitement de documents, c'est pareil. Convertir des Word en PDF, générer des rapports depuis un tableur, monter des présentations. Banal avec LibreOffice sur un bureau. Dans une sandbox, on se retrouve avec des convertisseurs en ligne de commande au support de format approximatif.

Le développement est un autre cas évident. Un agent qui configure un projet a besoin d'un terminal, d'un éditeur, d'un navigateur pour la doc, d'une base de données pour les tests, et de pouvoir installer des dépendances système. Un bureau persistant avec VS Code et une toolchain configurée, c'est un environnement de dev. Une sandbox, c'est un REPL.

Et puis il y a le travail qui s'étale sur des jours ou des semaines : surveiller un pipeline, gérer un déploiement, mener un projet de recherche. Ça demande de la persistance, des processus en arrière-plan, des tâches planifiées, et la capacité de reprendre après interruption. Le modèle sandbox éphémère ne colle pas avec du travail qui n'a pas de frontière "fini en 30 secondes".

Les sandboxes ont toujours leur place

Si l'agent exécute une fonction Python et renvoie un nombre, prenez une sandbox. Démarrage plus rapide, coût moindre, moins de complexité. Du traitement par lots sur des milliers de micro-tâches indépendantes ? Les sandboxes sont faites pour ça.

La question n'est pas "sandbox ou bureau". C'est une question d'adéquation entre l'infrastructure et le travail. Le calcul ponctuel et sans état va dans les sandboxes. Le travail avec état, sur la durée, multi-applications, va sur un bureau.

Où ça va

Les modèles savent déjà voir des écrans et manipuler des interfaces graphiques. Cette capacité ne va faire que progresser, et les agents auront besoin d'environnements plus riches pour en tirer parti.

On voit déjà les fournisseurs de sandboxes greffer de la persistance et du streaming d'interface. Les fournisseurs de bureaux (nous compris) travaillent sur des temps de démarrage plus courts. Les deux modèles convergent, et le résultat ressemblera davantage à un bureau qu'à une sandbox. Le travail l'exige.

Les sandboxes étaient la bonne abstraction pour les agents qui exécutent du code. Les bureaux sont la bonne abstraction pour les agents qui travaillent.

---

Le Bureau fournit des bureaux cloud persistants pour agents IA. Environnement Linux complet, accès VNC, supervision en temps réel. Essayez gratuitement pendant la bêta.