Hermes et Cua Spaces : quel ordinateur votre agent utilise-t-il vraiment ?

Un agent affirme avoir ouvert le navigateur. Lequel ? Si son terminal est dans une machine virtuelle mais que ses outils de bureau utilisent encore votre ordinateur, la réponse compte avant de lui confier une vraie tâche.

Le plugin Cua Spaces pour Hermes, ajouté au catalogue officiel le 20 octobre 2026 et mis à jour le 21, relie les opérations de terminal, de fichiers et de code à un ordinateur distinct que l’on peut observer. Hermes est un projet d’agent de Nous Research ; Cua fournit l’environnement informatique et ses outils d’accès. Ensemble, ils rendent concrètement visible l’environnement de travail de l’agent.

Le détail important est la frontière entre plateformes. Sur les Spaces Linux compatibles disposant des logiciels requis, le bureau et le navigateur peuvent suivre le terminal dans le Space. La documentation précise que ces outils restent sur l’hôte pour les Spaces macOS et Windows. Ce guide explique la distinction, propose une configuration limitée et montre où un ordinateur partagé facilite l’examen du travail.

Image principale : schéma éditorial original d’un agent et de son ordinateur de travail. Il ne représente ni installation terminée ni benchmark.

Un ordinateur de travail distinct rend la tâche plus facile à examiner

Pensez au Space comme à l’établi de l’agent. L’utilisateur choisit les outils, fichiers et comptes qu’il y place ; une autre personne peut regarder la même surface pendant l’activité. Le bénéfice est concret : le résultat dépend moins d’un journal de terminal privé que seul l’opérateur voit.

Prenons l’examen fictif d’un petit outil interne. L’agent installe les dépendances, lance une application de test et explore quelques fiches exemples. Un collègue observe, signale un état manquant, puis l’agent poursuit. L’ordinateur partagé fournit un objet commun de discussion : tous deux voient le même environnement et le même résultat.

Cette visibilité ne décide pas de la justesse du travail. La personne qui examine doit toujours connaître le résultat attendu ; l’agent peut encore suivre une instruction erronée. L’établi facilite l’inspection, sans remplacer la définition de la tâche.

Le plugin sépare aussi le processus de l’agent d’une partie de son activité. Hermes peut rester là où il fonctionne déjà tandis que les opérations de terminal et de fichiers se déroulent dans le Space. C’est utile pour obtenir une machine reproductible sans déplacer d’un coup toute une installation existante.

Capture de la documentation Cua montrant un bureau Linux dans le visualiseur Spaces. Elle illustre l’ordinateur visible, pas une tâche Hermes exécutée pour cet article. Source : Cua AI, Inc., ressource documentaire à révision fixe, utilisée sous licence MIT.

La frontière du terminal diffère de celle du bureau

La documentation annonce les opérations de terminal, fichiers et code sur Linux, macOS et Windows. Son tableau plus précis limite Bot Desktop, computer_use et le routage du navigateur aux Spaces Linux compatibles. Cette réserve importe davantage qu’une affirmation générale selon laquelle l’agent fonctionne « dans un bac à sable ».

Le parcours bureau Linux demande une version de Hermes contenant le changement pertinent postérieur à 0.22.2, Cua CLI 0.7.0 ou ultérieur et une pile de bureau dans le Space. La documentation identifie aussi des configurations laissant les outils sur l’hôte. Vérifiez l’ensemble avant de supposer une frontière commune à tous les outils.

Comparaison fonctionnelle : documentation officielle du plugin Hermes, vérifiée le 27 octobre 2026. Elle décrit cette intégration, pas tous les déploiements Cua possibles.

On peut facilement manquer ce détail dans une installation autrement réussie. Une commande peut renvoyer le nom d’hôte du Space alors qu’une action graphique ultérieure atteint une autre machine. Valider le terminal prouve sa cible, pas celle de l’outil suivant.

Pour chaque famille d’outils autorisée, faites un contrôle inoffensif et reconnaissable. Avant un compte réel, regardez le navigateur effectivement ciblé. Pour les fichiers, utilisez un exemple à emplacement non ambigu. Quelques petites vérifications expliquent mieux un environnement mixte qu’une grosse tâche échouant à mi-parcours.

Schéma original fondé sur les frontières d’outils documentées. Il distingue processus de l’agent, backend terminal et parcours conditionnel du bureau.

Spaces temporaires et persistants entraînent des responsabilités différentes

Le plugin peut créer un Space pour une exécution ou rejoindre celui que l’utilisateur nomme. Ce choix dépasse la commodité : il change la survie des fichiers, la responsabilité du nettoyage et le comportement documenté des confirmations de commandes.

Pour un Space créé par le plugin, le comportement par défaut est la suppression à la sortie de Hermes. Le plugin y ignore les confirmations Hermes de commandes risquées, car il considère le Space comme le bac à sable. Pour un Space nommé existant, les confirmations restent et le plugin ne l’arrête ni ne le supprime.

Le choix est clair. Un environnement temporaire convient à un test jetable sur données synthétiques, avec export avant la sortie. Un environnement persistant convient à une tâche longue dont l’état doit survivre entre sessions, à condition qu’une personne soit responsable du nettoyage et des ressources continues.

Un établi persistant peut aussi accumuler du contexte oublié. Session de navigateur, fichier généré ou ancienne dépendance peuvent influencer une nouvelle tâche sans être mentionnés dans la demande. Si la reproductibilité compte, documentez le contenu et décidez si chaque travail commence depuis une image propre ou un état volontairement entretenu.

C’est une décision d’exploitation, pas une garantie automatique de sécurité. Une machine temporaire peut accéder à des services externes avec des identifiants fournis ; une machine nommée peut contenir des fichiers sensibles. Choisissez ensemble environnement et permissions selon la tâche réelle.

Configurez une tâche Linux avant d’inviter l’équipe

La procédure suit le parcours documenté et ajoute des vérifications proposées. Elle n’a pas été exécutée pour cet article. Commencez par un environnement jetable et des fichiers exemples, sans données métier réelles.

1. Préparer des installations compatibles. Suivez les guides officiels Cua et Hermes, puis les prérequis actuels du plugin. Utilisez une révision Hermes compatible et Cua CLI à partir de 0.7.0 pour le bureau Linux.

2. Installer et activer le plugin. La commande documentée ci-dessous installe l’intégration. Examinez la dépendance Python demandée et les invitations d’activation avant de continuer.

   ShellExécuter dans Terminal

   hermes plugins install https://github.com/trycua/hermes-cua-spaces
   

3. Choisir le backend terminal. Orientez Hermes vers Cua, puis choisissez un Space jetable ou nommé.

   ShellExécuter dans Terminal

   hermes config set terminal.backend cua
   

4. Préparer le bureau Linux si nécessaire. Le plugin peut installer ses dépendances documentées dans le Space. Il lui faut les permissions et l’accès réseau décrits par le guide officiel.

   ShellExécuter dans Terminal

   hermes config set plugins.entries.cua-spaces.settings.desktop true
   

5. Vérifier la cible avant d’agir. Demandez le nom d’hôte et le système d’exploitation, puis examinez le Space dans le visualiseur. Contrôlez séparément bureau et navigateur si la tâche les utilise.

6. Exécuter une petite tâche réversible. Faites par exemple créer un fichier texte, relire son contenu et ouvrir une page de test locale. Définissez le résultat attendu puis inspectez l’artefact réel.

7. Tester la fin de session. Exportez ce qui doit rester et confirmez le cycle de vie choisi. Une tâche n’est pas complètement réussie si sa seule sortie disparaît avec le Space temporaire.

Gardez le premier travail assez court pour qu’une personne suive toute la séquence. Le premier résultat utile n’est pas une démonstration sophistiquée : c’est la certitude de savoir quelle machine a reçu chaque action et où sont les fichiers. L’équipe pourra ensuite ajouter un processus plus réaliste.

L’ordinateur partagé aide aux tests, aux transmissions et aux démonstrations

Trois usages illustrent l’intérêt de l’approche. Ce sont des propositions, pas des résultats mesurés ou des déploiements clients. Chacun demande un résultat explicite et une personne capable de le juger.

Un test de bon fonctionnement d’un outil interne peut utiliser un Space Linux avec application exemple et données synthétiques. L’agent suit un parcours défini sous observation. Les preuves utiles sont le comportement visible de l’application et la sortie sauvegardée, pas l’affirmation de l’agent qu’il a terminé.

Une transmission de développement peut conserver l’environnement pendant qu’une autre personne vérifie la reproduction d’un bug. Elle inspecte les mêmes fichiers et états, demande une reproduction plus étroite puis poursuit. La persistance aide seulement si les états intentionnels et ceux à réinitialiser sont connus.

Une démonstration de processus navigateur peut présenter un parcours avec un compte de test. Un collègue intervient sur un écran ambigu et explique le choix voulu. Avant un compte réel, l’équipe doit vérifier la frontière des outils et définir les actions permises dans ce compte.

Dans les trois cas, observation et contrôle doivent avoir des responsables clairs. Deux personnes modifiant simultanément le même écran compliquent l’explication du résultat. Une convention simple suffit : pause, décision de la personne qui examine, reformulation de l’étape suivante, reprise.

Chiffrez séparément l’ordinateur, la connexion et le modèle

La page tarifaire de Cua, vérifiée le 27 octobre 2026, indique que les utilisateurs fournissent leurs propres ordinateurs ou machines cloud. Le service apporte application, partage et relais ; matériel et cloud restent facturés séparément. L’usage du modèle constitue encore un poste distinct du budget.

L’offre Free annonce 2 sessions en direct et 20 heures distantes par mois. Pro coûte 18 dollars par mois, ou 180 dollars facturés annuellement. Teams coûte 30 dollars par siège et par mois, ou 300 dollars par siège facturés annuellement ; les équivalents mensuels annuels sont respectivement 15 et 25 dollars.

Ces montants décrivent les offres publiées à la date de vérification, pas le coût d’une tâche achevée. Il faut aussi tenir compte de la durée de fonctionnement des machines, de l’usage du modèle lors des reprises et du temps de révision.

La page présente plusieurs capacités comme futures : liens de partage expirants, historique d’audit, SSO et export d’audit. Prenez ces mentions au pied de la lettre. Une fonction annoncée pour plus tard ne doit pas devenir une dépendance d’un déploiement actuel.

Pour comparer, estimez un mois du processus réel plutôt que les abonnements seuls. Notez sessions, temps distant, disponibilité des machines et temps de contrôle. L’exercice peut révéler qu’une machine persistante est pratique mais reste inutilement allumée entre de courtes tâches.

Guide opérationnel original. Les quatre contrôles sont des critères d’acceptation proposés, pas une certification du plugin ni une mesure de sécurité.

Mesurez si une autre personne comprend le résultat

La transmission est souvent l’évaluation la plus révélatrice. Demandez à quelqu’un qui n’a pas écrit la consigne initiale d’inspecter l’environnement et d’expliquer les changements. Si l’opérateur doit reconstruire chaque étape de mémoire, le processus conserve un problème d’observabilité.

Pour un petit pilote, contrôlez quatre résultats concrets : la bonne machine a reçu le travail, le résultat correspond à la tâche, la sortie existe hors de tout environnement jetable et l’état restant est compris. Ces critères proposés sont plus utiles que l’impression globale d’un agent productif.

Conservez les échecs aussi soigneusement que les réussites. Ouvrir le mauvais navigateur révèle autre chose que choisir la mauvaise fiche dans le bon navigateur. Le premier problème concerne routage et configuration ; le second, interprétation de la tâche ou révision.

Le guide officiel Cua pour Hermes documente aussi les intégrations Driver et MCP. Ce sont des parcours distincts avec leur comportement propre. Choisissez-en un délibérément et décrivez-le dans les notes d’équipe, sans mélanger plusieurs instructions dans une configuration inexpliquée.

La frontière utile est celle que l’équipe sait désigner

Donner un ordinateur à un agent devient pratique lorsque les personnes identifient la cible, examinent le travail et récupèrent le résultat. Hermes avec Cua Spaces propose une intégration concrète, dont les détails de plateforme et de cycle de vie méritent une vérification avant les tâches réelles.

La question à emporter dans un essai est simple : un collègue peut-il montrer l’ordinateur utilisé et expliquer ce que l’agent y est autorisé à faire ? Une réponse claire transforme un bureau visible en environnement utile. Elle rend aussi le prochain échec plus facile à diagnostiquer et la transmission suivante plus digne de confiance.

Sources

• Catalogue de plugins Hermes : Cua Spaces — ajout le 20 et mise à jour le 21 octobre 2026 ; routage, configuration et cycle de vie.
• Cua : guide d’intégration Hermes — vérifié le 27 octobre 2026 ; autres parcours Driver et MCP.
• Tarifs Cua Spaces — vérifiés le 27 octobre 2026 ; offres, quotas, ordinateurs fournis par l’utilisateur et fonctions futures.
• Capture officielle du visualiseur Spaces et licence MIT à la même révision — ressource documentaire Cua AI, Inc.

Sources vérifiées le 27 octobre 2026. Commandes documentées et scénarios illustratifs. Aucune installation, aucun audit d’isolation ni benchmark de coût par tâche n’a été réalisé pour cet article.

Une recommandation de Telli.sh

Vous cherchez un endroit consultable pour les notes de configuration, enregistrements de tests et décisions autour d’un agent ? Rassemblez vos références dans Telli.sh pour garder des transmissions compréhensibles.