Votre bot se bloque à 3 h du matin sur un portail fournisseur qui réclame une connexion. Il vous le signale dans le chat et termine son tour, et tout ce qui suit n’est plus que supposition : sur quelle page il s’est arrêté, s’il a abîmé le formulaire qu’il a soumis une minute plus tôt. Le temps que vous vous en occupiez, la session a refroidi, et il a peut-être cliqué ailleurs entre-temps. Bot Screen existe pour supprimer ces suppositions. Sur un hôte Linux headless, chaque profil a désormais son propre bureau, diffusé en direct dans Hermes Desktop. Vous pouvez regarder le bot travailler, prendre la main sur le clavier et la souris quand il a besoin de vous, puis rendre la main et le laisser continuer.

Ce que c’est réellement

En une phrase : chaque bot dispose de son propre bureau Xfce, qui tourne sur l’hôte gateway.

• Le computer_use du bot (automatisation du bureau) et son navigateur avec interface (browser.headed: true) agissent sur cet écran.
• L’écran est diffusé dans un panneau de Hermes Desktop via noVNC.
• Chaque profil a son propre écran, son propre profil de navigateur et ses propres cookies.
• Le point important : l’écran vit sur l’hôte gateway, pas sur votre portable. Fermez l’application, rabattez l’écran — le bot continue de travailler sur le serveur.

C’est là toute la différence avec le bureau à distance vers ma propre machine : l’agent tourne sur le serveur, le bureau tourne sur le serveur, et votre client n’est qu’une fenêtre ouverte dessus.

À quoi ça sert : connexions, 2FA, CAPTCHAs, paiements

Le bot ne doit pas franchir ces étapes tout seul, et il ne doit pas se bloquer en vous attendant :

1. Il tombe sur une connexion, une étape 2FA, un CAPTCHA ou un paiement, le dit dans sa réponse et termine son tour.
2. La demande vous parvient dans le chat que vous utilisez — Telegram, Slack, Desktop.
3. Quand vous êtes disponible, ouvrez le panneau et cliquez sur Take over. La bordure devient rouge ; votre clavier et votre souris pilotent l’écran.
4. Connectez-vous, résolvez le CAPTCHA, validez le paiement.
5. Cliquez sur Hand back. Le bot reprend le contrôle et recapture l’écran avant de poursuivre.

Deux détails valent la peine d’être signalés. Un bot ne garde jamais un appel d’outil ouvert en attendant que vous arriviez — la prise de contrôle vient toujours de vous. Et quand deux observateurs se disputent un même écran, c’est le Take over le plus récent qui l’emporte ; le contrôleur précédent repasse en simple observateur. Hand back et connexion perdue sont d’ailleurs deux choses distinctes : si vous rabattez l’écran ou si le Wi-Fi coupe pendant que vous détenez le contrôle, vous le conservez — le bot reste exclu d’un écran sur lequel vous êtes peut-être en pleine connexion — jusqu’à ce que vous vous reconnectiez et rendiez la main. Si un rechargement laisse le panneau affirmer qu’un humain détient encore le contrôle, un bouton Hand back (force) apparaît.

Premiers pas

Prérequis : l’hôte gateway tourne sous Linux. Les hôtes macOS et Windows disposent déjà d’un affichage réel, et le panneau n’y est pas proposé.

Les paquets du bureau (le Xvnc de TigerVNC plus le cœur de Xfce) ne sont jamais installés en silence — hermes update et les installations neuves laissent la machine telle quelle. Quand ils manquent, le panneau Desktop affiche Install on host : un clic lance le gestionnaire de paquets sur cet hôte, en demandant le mot de passe sudo de cet hôte dans une carte masquée (le mot de passe n’est transmis qu’à cet hôte et n’est jamais stocké).

L’image Docker officielle — celle qui alimente aussi Hermes Cloud — relève du second cas : le gateway tourne sous un utilisateur non privilégié et l’image n’a pas de sudo, donc le panneau affiche la ligne exacte et un opérateur l’exécute une fois en root dans le conteneur :

docker exec -u 0 <container> apt-get install -y \
  tigervnc-standalone-server xfce4-panel xfwm4 xfdesktop4 xfce4-settings \
  xfce4-terminal dbus-x11 x11-xserver-utils x11-utils xauth fonts-dejavu-core

Les mêmes opérations depuis un shell :

hermes computer-use screen status     # installed? running? who holds control?
hermes computer-use screen start      # start this profile's screen
hermes computer-use screen stop       # refuses while a human holds control
hermes computer-use screen stop --force   # force it, and clear a stuck lease
hermes computer-use screen install [-y]   # run apt/dnf/pacman
hermes -p research computer-use screen start   # another profile's screen

L’écran est désactivé par défaut et rien ne le démarre à votre place. bot_desktop.auto_start vaut false ; activez-le et un hôte headless monte son écran au premier appel computer_use du bot ou à la première utilisation d’un navigateur avec interface. Ce défaut est délibéré — installer TigerVNC pour une raison sans rapport ne doit pas faire surgir un écran que personne n’a demandé.

bot_desktop:
  geometry: "1440x900"      # screen size; the viewer scales to fit the pane
  auto_start: false         # true = start on first computer_use / headed browser use
  min_free_memory_mb: 1536  # refuse to start below this much free memory (0 = never check)
  idle_stop_minutes: 30     # stop a screen nobody used for this long (0 = keep it up)

Faites d’abord le calcul de mémoire

Le bureau coûte peu ; c’est le navigateur qui coûte. Mesuré sur l’image officielle :

Élément	Empreinte
Gateway au repos	~300 MB
Xvnc + Xfce	~220 MB
Chromium avec interface ouvert pendant une prise de contrôle	0,5–1 GB (~550 MB pour une page)
CPU	quasiment gratuit (bureau au repos ≈ 0,01 cœur)
Disque, paquets sous Debian 13	~930 MB

Comptez 1,1–1,5 GB par écran ouvert avec un navigateur. La recommandation officielle : 4 GB font tourner le bureau, 8 GB sont le confort pour une prise de contrôle avec navigateur. Avant de démarrer, Hermes vérifie que l’hôte — ou le cgroup de son conteneur, selon ce qui est le plus serré — dispose de min_free_memory_mb de mémoire libre ; en dessous, il refuse et le dit dans le panneau, et un écran déjà en cours n’est jamais arrêté par cette vérification. Les écrans inactifs s’arrêtent après idle_stop_minutes (30 par défaut) et reviennent à l’usage suivant.

Nouveau depuis le 2026-09-23 : deux variantes d’image

Un déploiement hébergé (Fly Machines, instances de conteneurs Azure) ne peut rien installer à l’exécution, donc les paquets doivent être intégrés à l’image. La CI publie désormais deux variantes de chaque version :

• les tags sans suffixe (:latest, :v*) — sans les paquets ;
• les tags -desktop (:latest-desktop, :v*-desktop) — avec TigerVNC, les composants Xfce et le Chromium de la distribution.

Tirez le tag suffixé sur une instance hébergée et Bot Screen est là. Réserve du jour, énoncée sans détour dans la doc : rien dans le provisionneur ne sélectionne encore -desktop, donc une instance hébergée démarre toujours en version slim — tirer soi-même le tag suffixé fonctionne. Construire sa propre image reste optionnel ; l’argument de build officiel est désactivé par défaut pour qu’un simple docker build . reste léger :

docker build --build-arg HERMES_BOT_DESKTOP=1 -t hermes-agent:screen .

Un jour plus tard (2026-09-24), un changement complémentaire est arrivé : chaque image, y compris les tags slim sans bureau, embarque désormais la build complète de Chromium au lieu du shell headless plus léger de Playwright — un seul navigateur épinglé et vérifié par somme de contrôle sert à la fois à la navigation headless et aux sessions Bot Screen avec interface, au prix d’une image plus volumineuse.

Les sessions de navigateur survivent au passage de relais

C’est l’aspect le plus concret de Bot Screen : l’outil navigateur du bot et l’icône Browser du panneau sont le même navigateur. Chaque bot embarque un unique répertoire de données utilisateur persistant (<HERMES_HOME>/bot-desktop/browser-profile), donc pendant une prise de contrôle vous êtes dans les fenêtres et le pot à cookies du bot — et ce à quoi vous vous connectez est ce que le bot utilisera ensuite, dans cette exécution comme dans toutes les sessions suivantes, jusqu’à ce que le site expire la connexion.

Activez browser.headed: true si vous voulez que la navigation propre du bot soit elle aussi visible à l’écran. À noter que le dock n’est initialisé qu’une seule fois, au premier démarrage d’écran pour un profil : le garde-fou est le fichier de disposition du panneau <HERMES_HOME>/bot-desktop/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. Tant qu’il existe, modifier AGENT_BROWSER_EXECUTABLE_PATH ou AGENT_BROWSER_PROFILE puis redémarrer ne réépingle pas l’icône Browser — supprimez ce fichier et le dock se reconstruit au prochain screen start.

La frontière de sécurité : une surface de travail, pas un sandbox

La doc le dit sans détour, et cela vaut la peine d’être répété dans l’esprit, mot pour mot : la socket RFB de l’écran, l’affichage X, le profil de navigateur et le fichier de lease de contrôle appartiennent tous à l’utilisateur OS du gateway. Tout processus tournant sous cet utilisateur — un autre bot sur le même hôte, et l’outil terminal du bot lui-même — peut y accéder directement, en contournant le panneau et le lease. Le lease est une barrière au niveau de l’outil sur computer_use et les outils navigateur, pas une barrière OS.

Une frontière est plus large que l’utilisateur OS : le port DevTools de Chromium (l’icône Browser du dock et chaque lancement d’agent-browser en annoncent un sur la loopback) est accessible par n’importe quel utilisateur local de l’hôte, et Chromium n’offre aucune restriction par utilisateur pour cela. Faire tourner chaque bot sous son propre utilisateur OS sort du périmètre ; si cet isolement compte pour vous, ou si l’hôte a des utilisateurs locaux non fiables, placez les bots sur des hôtes séparés.

Deux détails de timing : le pont WebSocket met en cache sa décision de lease pendant jusqu’à 250 ms, donc une prise de contrôle effectuée par un autre processus est appliquée dans cette fenêtre. Et le display_ticket à usage unique de 30 secondes de la visionneuse voyage comme paramètre de requête dans l’URL à dessein (noVNC ne sait pas négocier de sous-protocoles WebSocket), ce qui signifie que le journal d’accès d’un proxy inverse peut enregistrer un ticket déjà consommé.

La version courte : ne saisissez pas de secrets dans un bot auquel vous ne les confieriez pas.

Ce qu’il faut retenir

Bot Screen transforme l’histoire du bot bloqué sur une page de connexion — devinette à l’aveugle — en un clic, une prise de contrôle et un retour de main, l’écran restant sur le serveur pour que votre portable puisse aller et venir. Désactivé par défaut, récupéré quand il est inactif et soumis à une vérification de mémoire explicite, il ne grignotera pas discrètement une petite instance. Pour aller plus loin, lisez le guide Bot Mode pour comprendre comment les profils deviennent des bots nommés, ce qu’un conteneur Docker partagé implique pour les agents parallèles, et le reste de cette fenêtre sur la page de release v0.21.5.