Hermes Desktop : agents personnels opérationnels

Hermes Desktop offre à Hermes une surface d'opérateur : chat, fichiers, profils, cron, accès aux passerelles et backends distants réunis en un seul endroit. Le runtime d'agent personnel Hermes Desktop dispose désormais de la couche de contrôle qui manquait aux agents en continu.

La question utile est plus simple : pouvez-vous voir ce que fait l'agent, quel rôle il utilise et comment récupérer en cas de panne ?

C'est pourquoi je considère Hermes Desktop comme la vraie nouveauté, même si les captures d'écran ressemblent à une mise à jour produit. Les éléments utiles sont les profils, une configuration bureau adaptée aux accès distants, l'intégration du Portal et les politiques autour des agents locaux.

• Hermes Desktop est une surface partagée sur le même état d'agent. La documentation officielle indique que Desktop, CLI, TUI, tableau de bord et passerelle réutilisent la même configuration de base plutôt que de créer des agents distincts.
• Les profils accueillent désormais les rôles d'agent récurrents. Ils séparent la configuration, `.env`, `SOUL.md`, la mémoire, les sessions, les compétences, les tâches cron et l'état de la passerelle, tandis que l'isolation du système de fichiers nécessite encore des limites explicites au niveau du backend.
• Nous Portal supprime la prolifération de comptes à la première utilisation. Un seul flux OAuth peut configurer l'accès aux modèles et l'accès au Tool Gateway, sans demander aux utilisateurs de connecter un à un les outils de recherche, de navigation, de génération d'images, de synthèse vocale et de sandbox.
• La problématique des agents locaux devient une problématique de sécurité. NVIDIA et Microsoft parlent désormais d'identité, de confinement, de politique et d'OpenShell pour les agents qui accèdent à votre ordinateur principal.

Ce qui a changé avec Hermes Desktop

Hermes Desktop est important parce qu'il repose sur le même cœur Hermes Agent que le terminal et la passerelle. La documentation est explicite : l'application partage la configuration, les clés API, les sessions, les compétences et la mémoire avec le CLI, le TUI et le tableau de bord.

Cela donne à Hermes une forme différente. Un agent en ligne de commande peut être utile pour les personnes qui travaillent déjà dans des shells. Une application de bureau avec chat, navigation dans les fichiers, rail de prévisualisation, profils, compétences, cron, messagerie et Command Center rend l'agent inspectable pour des travaux de longue durée.

Le détail qui m'importe est la continuité d'état. Il est possible de démarrer une session sur une surface Hermes et de la reprendre ailleurs, car toutes les surfaces communiquent avec le même état d'agent. C'est à ce moment que Hermes commence à ressembler à quelque chose que l'on peut vraiment faire fonctionner sur plusieurs surfaces.

Pour transformer un workflow d'agent récurrent en processus métier, le service d'automatisation IA de webvise est la solution la plus adaptée. La portée utile dépasse rarement l'interface de chat : elle concerne la limite du workflow, les identifiants, la porte de validation et le chemin de récupération autour de l'agent.

Les profils sont les rôles d'agent désormais

Les profils Hermes constituent désormais le point de départ le plus propre pour les rôles d'agent récurrents. Un profil est son propre répertoire personnel Hermes, avec sa propre configuration, son fichier de secrets, son fichier de personnalité, ses mémoires, ses sessions, ses compétences, ses tâches cron et sa base d'état.

Cette séparation d'état est suffisante pour les rôles récurrents. Un profil de recherche peut conserver des habitudes de revue de sources et des outils de navigation. Un profil rédacteur peut garder des règles de rédaction et des contraintes de style.

Un profil ingénieur peut conserver des commandes de dépôt et des habitudes de test. Chacun peut faire tourner son propre processus de passerelle et son nom de service.

Cela a modifié mes propres notes de configuration les 8 et 9 juin 2026. Je pensais en boîtes séparées pour des agents distincts. Une fois les profils intégrés dans l'architecture réelle, la configuration par défaut la plus propre est devenue : une installation Hermes, Desktop comme surface d'opérateur et les profils comme découpage des rôles.

La même documentation précise clairement la limite : les profils ne sandboxent pas le système de fichiers. Un backend terminal local fonctionne toujours avec le même accès au système de fichiers que le compte utilisateur. Pour définir un répertoire de départ prévisible pour la passerelle et les tâches cron, configurez `terminal.cwd` dans la configuration Hermes. Pour un confinement plus strict, utilisez un backend comme Docker, SSH, Modal, Daytona ou Singularity.

C'est là que le premier article sur les profils Hermes reste d'actualité. Dans le guide des profils Hermes, la règle était simple : créez un profil quand un rôle se répète et nécessite une mémoire, des outils, un état de passerelle ou des tâches planifiées séparés. Desktop rend cette règle plus facile à appliquer, car le changement de profil est maintenant visible.

La configuration qui a du sens aujourd'hui

La configuration que j'adopterais aujourd'hui : une installation Hermes sur une machine distante, Hermes Desktop connecté via Remote Gateway et les profils comme rôles d'agent. Telegram ou un autre canal de messagerie devrait généralement pointer vers un profil assistant. Cet assistant peut déléguer aux profils chercheur, ingénieur, rédacteur ou réviseur via des commandes explicites ou des tâches Kanban.

Cela garde le point d'entrée humain propre. Un message est envoyé à un assistant. L'assistant route le travail vers un profil disposant de la mémoire et des outils appropriés. Les travaux de longue durée deviennent des tâches durables plutôt que de disparaître dans un chat compressé.

Je conserverais tout de même une surface de réparation en dehors de Hermes : un outil externe pour les journaux, les redémarrages de passerelle, les modifications de configuration et le recâblage de profils défaillants.

Si une équipe demandait à webvise de cartographier cela, je commencerais par le tableau des permissions avant d'écrire des compétences. Le travail d'automatisation IA commence à porter ses fruits quand le responsable, les outils, les identifiants et les portes de validation sont suffisamment clairs pour qu'une mauvaise exécution d'agent soit immédiatement visible.

Le Portal supprime la prolifération de comptes

La documentation officielle de Nous Portal présente `hermes setup --portal` comme le chemin de configuration le plus rapide. Un seul flux OAuth définit Nous comme fournisseur d'inférence, permet à l'utilisateur de choisir un modèle et active le Tool Gateway.

C'est important parce que la configuration d'un agent échoue généralement avant le premier workflow utile. La recherche nécessite un compte. L'automatisation du navigateur en nécessite un autre. La génération d'images, la synthèse vocale et le sandboxing de terminal ajoutent encore plus de clés, de tableaux de bord, de soldes et de points de défaillance.

Le Portal regroupe l'accès à plus de 300 modèles et un Tool Gateway pour la recherche et l'extraction, la génération d'images, la synthèse vocale, les sessions de navigateur cloud et un sandbox terminal optionnel. La liste exacte des modèles évoluera. La direction produit est stable : Hermes cherche à réduire la configuration d'un premier agent utile à une seule commande plutôt qu'à cinq comptes fournisseurs.

Le Portal change également l'emplacement des secrets. La documentation indique qu'OAuth laisse un jeton de rafraîchissement dans `~/.hermes/auth.json` et génère des JWT à courte durée de vie par requête, plutôt que de remplir `.env` d'une douzaine de clés API à longue durée de vie. C'est une meilleure hygiène de configuration, mais cela nécessite tout de même des règles au niveau des rôles.

Le travail sérieux consiste toujours à décider quel profil détient quel identifiant, quel outil peut modifier des données et quelle action nécessite une validation. Accordez aux agents des comptes nommés et des clés API nommées dans la mesure du possible. Gardez les secrets dans la configuration, `.env` ou les chemins d'environnement des conteneurs, pas dans les transcriptions de chat.

Les agents locaux ont besoin de politiques avant l'autonomie

Hermes Desktop est arrivé au moment où les annonces matérielles se sont intensifiées. Dans son article RTX AI Garage, NVIDIA a écrit qu'Hermes avait dépassé 140 000 étoiles GitHub en moins de trois mois et était, la semaine précédente, l'agent le plus utilisé sur OpenRouter.

Les 31 mai et 2 juin 2026, Microsoft et NVIDIA ont publié le volet Windows de cette même histoire. L'article Windows de Microsoft mentionne l'identité appliquée par le système d'exploitation, le confinement et la gérabilité. L'article développeur de NVIDIA évoque les Microsoft eXecution Containers, OpenShell, la création de politiques, le routage d'inférence et l'obfuscation des données personnelles.

C'est la bonne direction pour Hermes. Un agent personnel avec accès aux fichiers, au terminal, au navigateur, à la mémoire, à la voix, au cron et aux routes de passerelle finit par toucher la même machine que l'on utilise pour la banque, le code, les documents et les comptes professionnels. La capacité est déjà là. La difficulté est de limiter qui peut lire des fichiers, dépenser de l'argent, exposer des secrets ou modifier la production.

La documentation OpenShell énonce clairement le tableau des risques : exfiltration de données, vol d'identifiants, utilisation non autorisée d'API et élévation de privilèges. J'avais déjà soutenu dans la couche opérateur Hermes à 30 jours que les contrats de transfert et les portes de permission importent après la première démo. Desktop et les profils rendent ces portes plus visibles. OpenShell et les primitives de politique Windows pointent vers la prochaine limite : le système d'exploitation.

Comment tester la configuration cette semaine

Commencez avec un seul runtime et trois profils. Faites du profil assistant la route par défaut orientée vers l'humain. Faites du chercheur et du rédacteur des travailleurs séparés. Gardez les secrets hors du profil rédacteur.

La première métrique de succès est simple : pouvez-vous demander à l'assistant un résumé étayé par des sources, observer comment il route la tâche, inspecter le résultat et voir quel profil a touché quels fichiers ou outils ? Si la réponse est oui, vous avez une surface d'opérateur. Si la réponse est enfouie dans une transcription de chat, vous avez une démo.

Chez webvise, ce type de recherche sur la configuration d'agents détermine quels workflows méritent l'automatisation et lesquels doivent rester des outils validés. Une bonne première cartographie couvre le processus récurrent, les outils qu'il utilise et les actions qui seraient problématiques si un agent se trompait.