J’ai remplacé Telegram par Buzz : mon architecture privée avec deux agents Hermes

J’ai donc testé une autre approche : Buzz comme espace de communication auto-hébergé, relié à deux agents Hermes Agent que je contrôle moi-même. Le premier, Jarvis, tourne chez moi. Le second, Régis, tourne sur un serveur privé que j’administre. Chacun possède sa propre identité et ne rejoint que les espaces auxquels je l’autorise.

L’objectif n’est pas de bricoler un chatbot de plus. Il est de reprendre le contrôle sur la couche la plus sensible d’un système agentique : l’endroit où passent les conversations, les ordres, les fichiers et les accès aux outils.

Note de cadrage : dans cet article, je prends volontairement un peu de recul ; ce n’est pas un tutoriel d’installation. La procédure complète se trouve dans la documentation officielle de Nous Research. Vous pouvez aussi demander un coup de main à Hermes lui-même : il peut vous guider pendant l’installation et le paramétrage. De votre côté, prévoyez une machine pour héberger le relay, PostgreSQL et les services associés, puis installez Buzz Desktop. Une fois l’URL du relay et votre identité renseignées, vous êtes connecté.

Pourquoi sortir de Telegram pour les usages sensibles ?

Telegram reste excellent pour démarrer. Le bot est simple à créer, les notifications fonctionnent partout et Hermes s’y connecte rapidement. Je continue à le considérer comme un bon canal d’appoint.

Mais il faut être précis sur le modèle de sécurité : les Secret Chats de Telegram bénéficient d’un chiffrement de bout en bout, pas les échanges ordinaires avec des bots. Telegram rappelle aussi qu’un bot ou une mini-app IA tierce constitue un service tiers avec sa propre politique de confidentialité.

Ce n’est pas dramatique pour demander la météo. Cela devient plus discutable lorsqu’un agent peut consulter des fichiers privés, piloter une infrastructure, interagir avec Home Assistant, lancer des scripts, recevoir des documents professionnels ou déclencher des tâches planifiées.

Un agent doté d’outils n’est plus une simple fenêtre de chat. C’est une interface d’administration conversationnelle.

— notes terrain

Buzz : une messagerie pensée comme un control plane

Buzz, développé en open source par Block, se présente comme un espace où humains et agents partagent les mêmes canaux sur un relay que l’on peut héberger soi-même. Chaque message, réaction ou événement de workflow prend la forme d’un événement Nostr signé. Humains et agents utilisent le même modèle d’identité et la même piste d’audit.

Dans mon installation, Buzz joue trois rôles : l’interface utilisateur avec les canaux et les messages, le relay privé qui transporte les événements, puis le point de rencontre de mes agents. Jarvis et Régis ne partagent pas mon identité personnelle. Dans les canaux communs, ils répondent à leur mention plutôt que de bondir sur chaque phrase comme deux stagiaires sous Red Bull.

Je garde aussi les réponses à plat dans le canal principal. Je préfère une conversation lisible entre humains et agents à vingt fils automatiques façon Slack sous stéroïdes.

Hermes v0.19.1 : le connecteur Buzz devient natif

La version Hermes Agent v0.19.1, publiée le 30 juillet 2026, intègre désormais le connecteur Buzz/Nostr. Buzz apparaît dans hermes gateway setup avec sa configuration, ses utilisateurs autorisés et le support des canaux comme des messages privés.

Le connecteur officiel privilégie une souscription WebSocket Nostr authentifiée pour recevoir les événements presque immédiatement. En mode auto, il bascule sur du polling si cette connexion ne peut pas être établie. Les réponses sortantes passent encore par le binaire officiel buzz. Le Markdown, les images et les réponses rattachées à un message sont pris en charge.

Point important : la clé Nostr privée utilisée par Hermes reste un secret. Elle doit être stockée dans ~/.hermes/.env ou dans un fichier d’identifiants protégé, jamais dans config.yaml, un message ou un journal.

Mes réglages terrain

gateway:
  platforms:
    buzz:
      enabled: true
      extra:
        channels: []
        home_channel: "<canal-principal>"
        require_mention: true
        transport: auto
        allow_all_users: false
        allowed_users:
          - "<clé-publique-autorisée>"

display:
  platforms:
    buzz:
      interim_assistant_messages: false
      tool_progress: off

• channels: [] laisse Hermes découvrir tous les canaux rejoints ; après l’ajout d’un nouveau canal, je redémarre le gateway pour repartir avec un état propre.
• home_channel reste explicite pour savoir où arrivent les notifications et les tâches planifiées.
• require_mention: true évite que les deux agents commentent chaque message d’un canal partagé.
• allow_all_users: false ferme l’accès par défaut ; seules les clés publiques listées peuvent piloter l’agent.
• Les messages intermédiaires restent masqués. Les utilisateurs voient le résultat final, pas chaque lecture de fichier ou commande exécutée.

Mon architecture privée à deux agents

Ce n’est pas une haute disponibilité parfaite. Les deux agents n’ont pas exactement le même rôle ni le même environnement. J’obtiens néanmoins une vraie résilience opérationnelle : Jarvis reste proche de mon réseau local, tandis que Régis peut continuer certaines tâches lorsque mon installation domestique est indisponible.

Attention : privé ne veut pas dire chiffré de bout en bout

C’est la nuance la plus importante de cet article. Buzz permet d’héberger son relay et de contrôler les adhésions, les identités, la rétention et le stockage. Son modèle de sécurité actuel repose sur TLS pour le transport, sur le contrôle d’accès du relay et sur le chiffrement de la couche de stockage. Le chiffrement de bout en bout des messages privés est présenté comme une piste future, pas comme une propriété disponible aujourd’hui.

En production, TLS doit être terminé au niveau du relay ou d’un reverse proxy : Buzz ne l’impose pas lui-même. Le projet est encore pré-1.0 et le rate limiting n’est pas actuellement appliqué par le relay. Si celui-ci est exposé à Internet, j’ajoute donc une limitation de débit au niveau du proxy, un pare-feu, des services non publics par défaut et une politique de mise à jour régulière.

Il faut aussi regarder jusqu’au modèle. Si Buzz et Hermes tournent chez vous mais que chaque message complet part vers une API cloud, vous contrôlez le transport et l’exécution, pas l’inférence. C’est déjà un gain, mais ce n’est pas une souveraineté de bout en bout.

Ma recommandation est pragmatique : reprendre d’abord le contrôle du canal et des agents, puis router les tâches sensibles vers un modèle local. Mon article sur les mini-PC IA DGX Spark et GB10 montre justement ce que ce dernier étage implique côté matériel. Vouloir tout rendre souverain en une soirée reste la meilleure façon de construire une cathédrale inutilisable.

Séparer les identités et sortir les secrets des conversations

J’utilise trois identités : la mienne, celle de Jarvis et celle de Régis. Cette séparation évite de donner aux agents les pouvoirs du propriétaire et rend les journaux plus lisibles. Je sais quelle identité a parlé, quel agent a exécuté une action et laquelle révoquer en cas de problème.

La même logique vaut pour les clés API. Auto-héberger le tuyau ne transforme pas le chat en coffre-fort. La documentation Hermes sur les secrets prévoit aujourd’hui Bitwarden Secrets Manager, 1Password et un command helper pour interroger d’autres coffres. Bitwarden peut injecter les clés au démarrage et centraliser leur rotation, avec un compte machine distinct par environnement.

• Une identité machine par agent, avec uniquement les droits nécessaires.
• Aucun secret dans les messages, les prompts, les captures ou les logs.
• Rotation centralisée et révocation testée avant d’en avoir réellement besoin.
• Administration séparée : un agent ne doit pas pouvoir supprimer sans contrôle le superviseur qui le fait vivre.
• Sauvegardes chiffrées avec une restauration réellement testée.

Ce que Buzz change dans mon usage quotidien

Le bénéfice le plus visible n’est pas technique. Je dispose d’un espace où plusieurs agents peuvent participer à la même conversation sans mélanger leurs identités. Je peux interpeller Jarvis pour une tâche liée à la maison, puis Régis pour une opération hébergée, tout en gardant un historique commun.

Les nouveaux canaux deviennent des contextes de travail : veille, infrastructure, projets personnels ou automatisations. Buzz n’est plus une intégration ajoutée à Telegram. Il devient mon control plane privé pour les agents IA.

Le prix à payer est l’exploitation. Il faut maintenir les mises à jour, surveiller les sauvegardes, protéger les identités, renouveler les certificats et comprendre ce qui est exposé. Une infrastructure personnelle abandonnée pendant deux ans peut être moins sûre qu’un SaaS bien opéré. On ne reprend pas seulement le contrôle : on reprend aussi les astreintes.

Héberger Hermes sans héberger son canal ne règle qu’une moitié du problème. Buzz ferme la boucle : interface, transport, identités et agents restent dans le même périmètre de contrôle.

— verdict

Pour un usage occasionnel, cette architecture est probablement excessive. Pour un agent capable de lire des fichiers, piloter des outils et travailler en continu, elle devient au contraire très rationnelle. Pour commencer plus simplement, mon guide Hermes Agent Desktop sur Windows permet déjà de tester l’agent, sa mémoire, ses skills et ses tâches planifiées.

Sources

• Hermes Agent v0.19.1 — release du 30 juillet 2026.
• Documentation officielle Hermes Agent — connecteur Buzz.
• Code source du connecteur Buzz livré avec Hermes v0.19.1.
• Dépôt officiel Buzz par Block.
• Buzz — modèle d’identité, d’accès et de chiffrement.
• FAQ Telegram — Cloud Chats, Secret Chats et bots tiers.
• Hermes Agent — intégration Bitwarden Secrets Manager.
• Hermes Agent — modèle de sécurité et périmètre de confiance.