Vous avez trois sessions Hermes qui travaillent en parallèle : une surveille la CI, une trie les issues, une rédige le rapport hebdomadaire. Vous fixez le terminal et le dashboard, en jugeant « sur quelle étape en est-il » à partir des logs — vous voyez la sortie, mais vous ne voyez pas l’agent. Imaginez maintenant ces agents comme quelques petits personnages dans un bureau : qui est à son poste en train d’écrire du code, qui est en salle de réunion pour le standup, qui déplace des cartes sur le tableau — lisible d’un coup d’œil au lieu de patauger dans les logs. C’est la proposition.

C’est ce que fait Hermes3D : un frontend open-source de bureau virtuel 3D (MIT, 105 étoiles, par LukeTheDev) qui transforme vos agents Hermes en personnages se déplaçant dans un bureau partagé. C’est un projet communautaire (le README précise explicitement qu’il n’est pas affilié aux équipes du backend d’agent), il n’exécute lui-même aucun agent — c’est purement la couche de visualisation, connectée à la gateway JSON-RPC de Hermes directement ou via un adaptateur de gateway. Il convient aux développeurs qui veulent voir leur équipe d’agents travailler. Le projet a été activement mis à jour le 20 août.

À quoi cela ressemble vraiment

Le cœur est un environnement de bureau rétro /office : chaque agent connecté est un personnage se déplaçant dans un monde 3D partagé. Ce n’est pas qu’un économiseur d’écran, cependant :

• Regardez les agents travailler en temps réel — qui exécute quelle tâche, la progression d’un coup d’œil ;
• Tenez des standups — les agents connectés à GitHub et Jira tiennent des réunions dans une salle de conférence ;
• Relisez les PR — parcourez les pull requests depuis l’intérieur du bureau ;
• Bureau kanban — un tableau intégré qui affiche directement les données hermes kanban du backend : glisser une carte vers Working met la tâche en file en ready, seul le dispatcher peut la passer à running, et le statut est réécrit dans Hermes ;
• Entraînez les skills dans la salle de sport, et un système de concierge pour réinitialiser les sessions et nettoyer le contexte.

En clair : le dashboard est la console de contrôle ; Hermes3D est la passerelle d’observation où vous entrez dans votre équipe d’agents. Envie d’un aperçu d’abord ? Le dépôt embarque une gateway de démonstration intégrée, vous pouvez donc vous promener dans le bureau sans installer aucun framework d’agent.

Deux façons de se connecter

Hermes3D prend en charge trois runtimes ; deux comptent pour Hermes :

1. Hermes Agent (direct) — recommandé : Studio parle lui-même la gateway JSON-RPC de Hermes, sans processus d’adaptateur. Nécessite un hermes serve en boucle locale sur l’hôte Hermes (machine A).
2. API HTTP Hermes + adaptateur de gateway : npm run hermes-adapter démarre un adaptateur qui parle le protocole WebSocket de la gateway Hermes3D d’un côté et appelle l’API HTTP Hermes (par défaut http://localhost:8642) de l’autre. Idéal quand le backend n’est pas local ou que vous préférez le chemin API HTTP.

Déploiement sur deux machines : le tutoriel direct Tailscale (la forme la plus courante)

La forme canonique du tutoriel officiel est deux machines : la machine A exécute le backend Hermes, la machine B exécute Hermes3D, et Tailscale les relie de manière sécurisée. La chaîne :

Browser <-> Studio server (Machine B) <-> Tailscale <-> hermes serve (Machine A)

Machine A — l’hôte Hermes :

Première étape, épingler un token de session — le secret partagé entre les deux machines, stocké sous un nom dédié. Ne touchez pas à HERMES_DASHBOARD_SESSION_TOKEN lui-même : Hermes charge ~/.hermes/.env avec override=True, donc l’épingler écraserait le token frais que l’appli desktop frappe pour son propre backend à chaque lancement, et l’appli meurt au démarrage :

echo "HERMES3D_OFFICE_TOKEN=$(openssl rand -hex 32)" >> ~/.hermes/.env

Deuxième étape, démarrez le backend en boucle locale (--host 127.0.0.1 n’est pas optionnel : se lier à l’adresse du tailnet active la porte de connexion et casse l’authentification par token) :

HERMES_DASHBOARD_SESSION_TOKEN="$(grep '^HERMES3D_OFFICE_TOKEN=' ~/.hermes/.env | cut -d= -f2)" \
  hermes serve --host 127.0.0.1 --port 9120 --skip-build

Troisième étape, publiez sur le tailnet (le port --https doit réellement être libre — si 443 est pris, utilisez 10000/8443) :

tailscale serve --yes --bg --https=10000 http://127.0.0.1:9120

Vérifiez le tunnel de bout en bout avant de toucher à la machine B : curl -s -H "Host: localhost" https://<machine-a>.<tailnet>.ts.net:10000/api/status doit renvoyer du JSON.

Quatrième étape, gardez-le en marche : macOS utilise une plist launchd, Linux une unité utilisateur systemd, les deux lisant le token depuis .env au lancement — le secret reste hors des définitions de service et hors de ps. Tailscale Serve persiste entre les redémarrages une fois configuré avec --bg.

Machine B — l’hôte Hermes3D :

git clone https://github.com/iamlukethedev/Hermes3D.git hermes3d
cd hermes3d && npm install && cp .env.example .env && npm run dev

Ouvrez http://localhost:3000 et remplissez l’écran de connexion : Backend = Hermes Agent (direct), Gateway URL = wss://<machine-a>.<tailnet>.ts.net:10000 (donnez la racine du serveur, pas /api/ws — Studio ajoute le chemin), Token = celui de la première étape. Vous arrivez dans le bureau avec un personnage par profile hermes-agent.

La frontière de sécurité (l’auteur est d’une honnêteté rafraîchissante)

• Le token de session est un identifiant bearer pour tout votre agent — traitez-le comme une clé API : ne le committez jamais, faites-le tourner en redémarrant avec une nouvelle valeur ;
• Rien n’est exposé à l’internet public : hermes serve se lie à la boucle locale, et Tailscale Serve ne publie qu’à l’intérieur de votre tailnet ;
• Toute personne de votre tailnet qui apprend le token peut atteindre le backend — utilisez les ACL Tailscale sur les tailnets multi-membres.

Le tableau de dépannage est aussi pré-tracé : wrong version number/EPROTO = wss:// vers un port en clair (utilisez le port --https) ; 403 = token incohérent (si ça marchait jusqu’à un redémarrage, c’est généralement que le token n’a jamais été épinglé) ; 401 = vous avez atteint le hermes dashboard protégé plutôt que le hermes serve en boucle locale ; 400 Invalid Host header = vieux build, mettez Studio à jour.

Ça vaut le coup d’essayer ?

Si vous exécutez régulièrement plusieurs sessions Hermes et que votre sens de « ce que fait l’agent » vit au niveau du défilement des logs, Hermes3D offre une perspective réellement différente — et son bureau kanban réutilise vos données hermes kanban existantes sans aucune configuration supplémentaire. C’est un jeune projet de 105 étoiles, mais le README, la documentation d’architecture et le tutoriel sont écrits avec un soin inhabituel. Reste que c’est un frontend communautaire : la gateway JSON-RPC porte la connexion, et le comportement, les permissions et les flux d’approbation de l’agent ne changent pas du tout — votre configuration multi-profiles et votre orchestration live des subagents continuent de fonctionner exactement comme avant ; vous gagnez juste des yeux. Pour d’autres projets de l’écosystème, parcourez notre page écosystème.