Bureaux cloud pour agents IA : guide pratique

Bureaux cloud pour agents IA : guide pratique

Une sandbox d'exécution de code permet à un agent IA de lancer des scripts. Une vraie machine virtuelle avec un bureau, un système de fichiers et un accès réseau lui permet de faire ce que fait un développeur : naviguer sur le web, coder dans un IDE, installer des paquets, et reprendre demain là où il s'est arrêté aujourd'hui.

On a construit Le Bureau autour de cette idée. Cet article explique pourquoi on pense que le bureau complet est la bonne abstraction pour du vrai travail d'agent, comment l'architecture fonctionne, et comment en lancer un.

Ce qu'est concrètement un bureau agent

C'est une VM Linux avec un environnement de bureau graphique. L'agent s'y connecte via VNC pour voir et cliquer, via un terminal pour la ligne de commande, et via un chat pour recevoir des instructions et rendre compte.

Ce qui le distingue d'une VM classique :

1. Runtime agent pré-installé. La VM embarque OpenClaw prêt à l'emploi. Pas de config, l'agent bosse tout de suite.
2. Disque persistant. Fichiers, repos git, configs : tout survit aux redémarrages. L'agent reprend où il en était.
3. BYOK pour les clés API. Vous injectez vos propres clés (Anthropic, OpenAI, OpenRouter). Elles sont injectées de façon sécurisée au provisioning et restent dans la VM.
4. Mission Control. Un tableau de bord pour observer ce que font les agents, valider les actions sensibles, et intervenir quand ça déraille.
5. Provisioning par API. Création, démarrage, arrêt, destruction via REST. Adapté à la gestion de flotte et au CI/CD.

Les bureaux distants existent depuis des décennies. La différence ici, c'est d'assembler l'isolation VM, l'outillage agent et une couche de gestion pensée pour des opérateurs non humains.

Pourquoi des vrais bureaux et pas des sandboxes

La première génération d'infra pour agents, c'était les sandboxes : des environnements légers et éphémères pour exécuter du code. Ça marche pour des tâches précises (lancer un script Python, jouer une suite de tests), mais ça bloque vite.

Les agents ont besoin d'écran

Les API de computer use comme celle d'Anthropic permettent aux agents de manipuler des interfaces graphiques : cliquer, remplir des formulaires, naviguer dans des applis. Une sandbox n'a pas de serveur d'affichage. Un bureau avec VNC donne à l'agent un vrai framebuffer qu'il peut observer et contrôler.

Les agents ont besoin que l'état persiste

Un projet de code sur plusieurs jours implique des fichiers, un historique git et un environnement qui doivent survivre entre les sessions. Les sandboxes jettent tout à la sortie. Un bureau persistant garde tout, comme votre poste de travail.

Les agents doivent faire plusieurs choses à la fois

Le vrai travail, c'est passer du navigateur au terminal, de l'IDE à la doc. Une sandbox expose en général un seul point d'entrée (exécution de code). Un bureau permet à l'agent de faire tourner Chrome, VS Code et un terminal côte à côte.

Les agents ont besoin du root

Installer des paquets, modifier la config système, lancer des services en arrière-plan : ça demande un vrai OS, pas un environnement d'exécution verrouillé. Une VM Ubuntu avec sudo donne à l'agent les mêmes capacités que vous.

Les environnements contraints font échouer les agents

Quand un agent tombe sur une dépendance manquante, un format de fichier non géré, ou un outil qui ne marche qu'en GUI, il bloque. Les bureaux complets réduisent ces impasses.

Le compromis, c'est la consommation de ressources. Une VM de bureau demande plus de CPU, de RAM et de stockage qu'une sandbox. Pour un agent qui enchaîne des tâches complexes sur plusieurs outils pendant plusieurs jours, ce surcoût se rentabilise vite.

Bureau vs sandbox vs conteneur

Le bon choix dépend de la charge de travail.

Quand utiliser quoi :

• Bureau : L'agent navigue sur le web, utilise des applis GUI, travaille sur plusieurs sessions, ou a besoin d'un OS complet. C'est le créneau de Le Bureau.
• Sandbox : L'agent exécute un bout de code et retourne un résultat. Pas de GUI, pas de persistance.
• Conteneur : L'agent fait tourner un service dans un environnement reproductible. Pipelines de build, pas du travail interactif.

En production, la plupart des setups combinent les trois. On fournit des bureaux complets pour l'espace de travail principal ; des sandboxes gèrent les sous-tâches d'exécution isolées.

Comment ça marche sous le capot

1. Virtualisation

Chaque bureau est une VM QEMU/KVM tournant sur Proxmox. Isolation matérielle entre les VM, gestion du cycle de vie via l'API Proxmox.

L'image de base est un snapshot doré : Ubuntu 22.04, XFCE4, KasmVNC, OpenClaw, Chrome, VS Code. Les nouveaux bureaux clonent ce template, ce qui maintient le démarrage sous les 90 secondes.

2. Réseau

Chaque VM reçoit une IP privée sur le réseau de l'hôte. L'accès externe passe par des proxies WebSocket authentifiés :

• Proxy VNC relie le viewer navigateur au serveur KasmVNC de la VM.
• Proxy terminal relie xterm.js dans le navigateur au shell de la VM via ttyd.
• Proxy chat route les messages entre l'interface web et OpenClaw via SSH.

Toutes les connexions proxy exigent un token de session valide. Aucun port de la VM n'est exposé directement.

3. Couche agent

OpenClaw tourne dans la VM en tant que runtime. Il reçoit les instructions via CLI, les exécute en computer use (observation d'écran, contrôle souris/clavier) et commandes shell, puis rapporte les résultats par le chat.

L'agent s'authentifie auprès des API LLM avec la propre clé de l'utilisateur, injectée au provisioning. La clé reste dans la VM et n'en sort pas. Le suivi d'utilisation se fait par bureau.

4. Couche de gestion

L'appli web fournit Mission Control : création de bureaux, supervision des agents, gestion des clés API, configuration des espaces de travail. Tout ce qui est dans l'interface est aussi dispo via API REST.

Schéma d'architecture

Navigateur
    |
    +-- Viewer VNC ----> Proxy WebSocket --> VM:6080 (KasmVNC)
    +-- xterm.js ------> Proxy WebSocket --> VM:7681 (ttyd)
    +-- Panneau Chat ---> API REST --------> VM:SSH --> OpenClaw CLI
    +-- Mission Control-> API REST --------> PostgreSQL + API Proxmox
    |
Agent (dans la VM)
    +-- OpenClaw -------> API LLM (clé utilisateur)
    +-- Navigateur, IDE, Terminal (local à la VM)

Démarrer

Tout le processus prend moins de trois minutes.

Prérequis

• Un compte Le Bureau (lebureau.talentai.fr)
• Un espace de travail (créé automatiquement à la première connexion)

Étape 1 : Créer un bureau

Depuis Mission Control, cliquez sur New Computer. Choisissez une offre :

Donnez-lui un nom (par ex. dev-agent-01), cliquez Provisionner. La VM boot depuis l'image dorée, c'est prêt en 60 secondes environ.

Étape 2 : Se connecter

Quand le statut passe à Running, cliquez pour ouvrir le viewer. Trois panneaux :

1. VNC à gauche : l'écran de l'agent en temps réel. Vous pouvez regarder ou prendre la main.
2. Terminal en bas : un shell dans la VM.
3. Chat à droite : envoyez des instructions, lisez les réponses.

Étape 3 : Lui donner du travail

Dans le chat, tapez une tâche :

Clone le dépôt github.com/myorg/myproject et mets en place l'environnement de dev.

L'agent ouvre un terminal, lance les commandes git, installe les dépendances et rapporte sa progression. Vous suivez tout ça en direct dans le viewer VNC.

Étape 4 : Via l'API (optionnel)

Générez une clé API depuis Mission Control dans Settings :

## Lister les bureaux
curl -H "Authorization: Bearer VOTRE_CLE_API" \
  https://lebureau.talentai.fr/api/desktops

## Créer un bureau
curl -X POST \
  -H "Authorization: Bearer VOTRE_CLE_API" \
  -H "Content-Type: application/json" \
  -d '{"name": "ci-agent", "workspaceId": "ws_xxx"}' \
  https://lebureau.talentai.fr/api/desktops

## Envoyer une tâche
curl -X POST \
  -H "Authorization: Bearer VOTRE_CLE_API" \
  -H "Content-Type: application/json" \
  -d '{"message": "Lance la suite de tests et rapporte les résultats"}' \
  https://lebureau.talentai.fr/api/desktops/DESKTOP_ID/chat

Étape 5 : Arrêter ou détruire

Arrêtez un bureau pour garder son état, ou détruisez-le pour libérer les ressources. Les deux se font depuis Mission Control ou l'API. Un bureau arrêté garde son disque. Un bureau détruit efface tout.

Supervision avec Mission Control

Un seul agent, c'est gérable. À dix, il faut de la visibilité.

Chaque bureau affiche son état (provisioning, running, stopped, error) en temps réel via server-sent events. Pas besoin de rafraîchir la page.

Toutes les conversations sont stockées en base. Vous pouvez relire ce qu'un agent a fait des jours après, même après des redémarrages. Vous voyez aussi quels bureaux tournent, depuis combien de temps, et sur quelles tâches.

Pour les opérations sensibles (déploiement en prod, achats, modifications d'infra), l'agent se met en pause et demande votre accord avant de continuer.

Des alertes vous préviennent en cas d'erreur agent, d'activité inhabituelle ou de seuil de ressources atteint. La gestion de flotte permet de créer, démarrer, arrêter et détruire des bureaux en masse, avec organisation par espace de travail et suivi des coûts.

Sécurité

Confier un OS complet à un agent IA pose des questions légitimes. Voici comment on y répond.

Chaque bureau tourne dans sa propre VM KVM avec noyau, système de fichiers et pile réseau dédiés. Un agent compromis ne peut atteindre ni les autres VM ni l'hôte. C'est de l'isolation matérielle, pas des namespaces de conteneurs.

Modèle BYOK pour les clés : vous apportez les vôtres. Elles sont injectées dans la VM au provisioning et restent dedans. Aucune clé ne transite par nos serveurs à l'exécution.

Des règles de firewall empêchent la communication entre VM. Les bureaux d'espaces de travail différents sont isolés, et le trafic sortant peut être restreint à des domaines spécifiques.

Toutes les requêtes API, messages de chat et actions de gestion sont logués pour une piste d'audit complète. Des plafonds CPU, mémoire et stockage par offre évitent les problèmes de voisinage bruyant. L'agent accède aux API LLM et à son propre système de fichiers, rien d'autre.

Tarifs

Détails sur la page tarifs.

Choisir entre les fournisseurs

Le Bureau vise les agents qui ont besoin d'un vrai bureau : navigation, code, applis GUI, projets persistants. Le tarif mensuel fixe convient aux agents qui tournent en continu.

E2B se concentre sur l'exécution de code courte durée. Si votre agent ne fait que lancer des snippets Python, la facturation à la seconde peut revenir moins cher.

Scrapybara couvre l'automatisation web. Si votre agent n'interagit qu'avec des sites, un navigateur cloud peut suffire.

Browserbase fournit de l'infra navigateur headless. Bon pour du scraping à volume, pas pour du travail agent généraliste.

Windows 365 for Agents est la proposition de Microsoft sur ce créneau. À considérer si vous avez besoin de Windows et êtes déjà sur Azure, mais c'est Windows uniquement et tarifé pour les grands comptes.

FAQ

Quelle différence entre un bureau cloud et une sandbox ?

Un bureau, c'est une VM complète : GUI, stockage persistant, accès sudo. L'agent l'utilise comme vous utilisez votre poste. Une sandbox est éphémère, sans GUI, avec un accès limité. Bureau pour le travail complexe, sandbox pour l'exécution de code isolée.

C'est rapide à provisionner ?

Environ 60 secondes. La VM boot depuis une image pré-construite avec Ubuntu 22.04, XFCE4, OpenClaw, Chrome et VS Code. Aucune config manuelle.

C'est sécurisé ?

Chaque bureau est une VM KVM avec son propre noyau et sa pile réseau. Les clés API restent dans la VM (modèle BYOK). Les VM ne peuvent pas communiquer entre elles. Tout est logué. Voir la section sécurité plus haut.

Plusieurs agents sur un même bureau ?

C'est possible, mais on recommande un agent par bureau pour une meilleure isolation et un monitoring indépendant. L'API permet de provisionner plusieurs bureaux facilement.

Comment marche la persistance ?

Chaque bureau a un disque virtuel qui survit aux redémarrages. Arrêtez un bureau : le disque est préservé. Redémarrez-le : tout est là où l'agent l'a laissé. Seule la destruction supprime le stockage.

Quels outils les agents peuvent utiliser ?

Tout ce qui tourne sous Linux. L'image dorée inclut Chrome, VS Code, Python 3, Node.js et git. Les agents installent ce qu'ils veulent via les dépôts Ubuntu, pip, npm, cargo, etc.

Je peux utiliser mon propre framework agent ?

Oui. C'est une VM Linux standard. OpenClaw est pré-installé par commodité, mais vous lancez ce que vous voulez. VNC et le terminal marchent quel que soit le logiciel qui tourne dedans.

La suite

On travaille sur l'orchestration de flotte, les workflows de validation, et l'intégration CI/CD. L'objectif : que gérer 50 bureaux agents soit aussi simple que d'en gérer 5.

Si vous voulez tester, l'offre gratuite est dispo pendant la bêta. Provisionnez un bureau, donnez une tâche à votre agent, et voyez jusqu'où il va. Les instructions ci-dessus prennent environ trois minutes.

Pour un tuto pas à pas, consultez notre guide sur le déploiement de votre premier bureau agent IA.

---

Le Bureau est une plateforme de bureaux cloud pour agents IA. lebureau.talentai.fr