Les sandboxes, c'etait l'etape un. Les agents ont besoin de vrais bureaux.

E2B et les plateformes sandbox similaires ont vu juste sur un point : laisser un agent IA executer du code dans un conteneur isole, recuperer le resultat, tout jeter. Propre, rapide, pas cher. Pour executer une fonction Python ou traiter un CSV, ca suffit largement.

Sauf que le travail des agents change. Ils naviguent sur des sites, remplissent des formulaires, manipulent des documents, enchainent des workflows sur plusieurs heures. Et les sandboxes n'ont jamais ete concues pour ca. Elles ont ete concues pour l'execution de code, et elles le font bien. Le probleme, c'est que l'execution de code represente une part de plus en plus mince de ce qu'on demande aux agents.

Ce que les sandboxes font bien

Une sandbox demarre en moins d'une seconde. Ca ne coute presque rien par invocation. L'isolation du code non fiable est solide. Et le modele mental est limpide : entree, sortie, environnement detruit.

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

Je dis que l'industrie construit des agents de plus en plus capables, puis les enferme dans des environnements concus pour executer des scripts.

La ou le modele craque

Des qu'on depasse le "execute cette fonction, renvoie le resultat", les sandboxes commencent a poser probleme.

Aucune persistance

Une sandbox meurt apres chaque tache. Fichiers, configs, contexte : tout disparait. On peut bricoler une couche de persistance, serialiser l'etat, le recharger dans un nouveau conteneur. Mais la on construit de la gestion d'etat par-dessus une architecture dont le principe fondateur est justement l'absence d'etat. A un moment, on se bat contre l'outil au lieu de s'en servir.

Un agent qui itere sur un codebase pendant trois jours ne devrait pas avoir a reconstruire son environnement a chaque session.

Pas d'ecran

La plupart des sandboxes offrent un terminal, point. Pas de navigateur, pas d'interface graphique, pas de retour visuel. Ca suffisait quand les agents se contentaient d'executer 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 ca dans une sandbox : "Va sur ce site, trouve la page tarifs, extrais les details des offres." L'agent doit passer par de l'automatisation headless, parser du HTML brut, et esperer 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 majorite des logiciels au monde ont ete concus pour elle.

Pas d'acces systeme

Les sandboxes verrouillent l'OS volontairement. Impossible d'installer des paquets, de lancer des services, de configurer quoi que ce soit au niveau systeme. C'est justifie cote securite. Mais ca 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 donnees 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 apres coup. On ne peut pas le regarder travailler, intervenir s'il deraille, ou comprendre pourquoi il a pris telle decision. Pour une execution de 5 secondes, pas de souci. Pour une tache de recherche de 3 heures, c'est piloter a l'aveugle.

C'est une question de confiance. Si on deploie des agents en contexte professionnel, il faut pouvoir verifier ce qu'ils font, pas juste lire le resultat final.

Une seule tache a la fois

Les sandboxes gerent une tache par session. Mais le vrai travail implique plusieurs applications en parallele : un navigateur pour la recherche, un terminal pour le traitement, un editeur pour les notes, un tableur pour l'analyse. Le tout persistant entre les sessions.

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

Ce qu'un bureau apporte

On a construit Le Bureau autour d'une idee differente : donner a l'agent le meme environnement qu'un humain utiliserait. Chaque agent recoit un bureau Linux persistant avec une interface graphique accessible en VNC. Il peut ouvrir un navigateur, installer des logiciels, gerer des fichiers. Le bureau survit entre les sessions : les livrables, les configs et les outils restent en place.

Concretement, ca donne :

• L'agent et l'operateur voient le meme ecran en temps reel via le streaming VNC. On peut observer, intervenir, approuver des actions.
• Le disque persiste. L'agent reprend la ou il s'est arrete, sans ceremonie de serialisation.
• Acces OS complet. apt install ce qu'il faut. Lancer des services. Configurer le systeme.
• Environnement Linux standard : ajouter un outil, c'est juste installer un logiciel. Pas d'adaptateurs SDK, pas de wrappers.

Exemples concrets

Recherche web. Un agent qui analyse les tarifs de concurrents a besoin d'un vrai navigateur avec rendu JavaScript, gestion des cookies, et la capacite de voir a quoi ressemble reellement la page. L'automatisation headless fait la moitie du chemin. Un bureau avec Chrome fait le reste.

Traitement de documents. Convertir des Word en PDF, generer des rapports depuis un tableur, monter des presentations. C'est banal avec LibreOffice sur un bureau. Dans une sandbox, on se retrouve avec des convertisseurs en ligne de commande au support de format approximatif.

Developpement. Un agent qui configure un projet a besoin d'un terminal, d'un editeur, d'un navigateur pour la doc, d'une base de donnees pour les tests, et de pouvoir installer des dependances systeme. Un bureau persistant avec VS Code et une toolchain configuree, c'est un environnement de dev. Une sandbox, c'est un REPL.

Taches sur plusieurs jours. Certains travaux s'etalent sur des jours ou des semaines : surveiller un pipeline, gerer un deploiement, mener un projet de recherche. Ca demande de la persistance, des processus en arriere-plan, des taches planifiees, et la capacite de reprendre apres interruption. Le modele sandbox ephemere ne colle tout simplement pas avec du travail qui n'a pas de frontiere "fini en 30 secondes".

Les sandboxes ont toujours leur place

Si l'agent execute une fonction Python et renvoie un nombre, prenez une sandbox. Demarrage plus rapide, cout moindre, moins de complexite. Du traitement par lots sur des milliers de micro-taches independantes ? Les sandboxes sont faites pour ca.

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

Ou ca va

La direction est claire. Les modeles savent deja voir des ecrans et manipuler des interfaces graphiques. Cette capacite ne va faire que progresser. Et a mesure qu'elle progresse, les agents auront besoin d'environnements plus riches.

On voit deja les fournisseurs de sandboxes greffer de la persistance et du streaming d'interface. Les fournisseurs de bureaux (nous compris) travaillent sur des temps de demarrage plus courts. Les deux modeles convergent, et le resultat ressemblera davantage a un bureau qu'a une sandbox, parce que c'est ce que le travail exige.

Les sandboxes etaient la bonne abstraction pour les agents qui executent du code. Les bureaux sont la bonne abstraction pour les agents qui travaillent. L'ecart entre les deux ne fait que grandir.

---

Le Bureau fournit des bureaux cloud persistants pour agents IA. Environnement Linux complet, acces VNC, supervision en temps reel. Essayez gratuitement pendant la beta.