Déployer Hermes Agent sur Signal (signal-cli)

Pourquoi faire tourner Hermes Agent sur Signal

Si votre modèle de menace met les métadonnées en premier, Signal est la messagerie en laquelle vous avez déjà confiance. Le chiffrement de bout en bout est activé par défaut, le serveur ne stocke presque rien au-delà d'un numéro de téléphone et d'un dernier horodatage de connexion, et le protocole lui-même est en open source. Placer votre agent IA sur la même surface garde chaque prompt, chaque réponse et chaque fichier que vous lui confiez dans la même enveloppe.

Hermes Agent prend en charge Signal nativement via signal-cli, un daemon non officiel mais bien maintenu qui parle le protocole Signal pour vous. Le gateway Hermes dialogue avec signal-cli en HTTP en utilisant JSON-RPC pour les actions sortantes et Server-Sent Events pour le flux entrant, donc tout le runtime tient sur un VPS à 5 USD, sur votre portable, ou sur un Raspberry Pi derrière un NAT et envoie et reçoit quand même en temps réel.

Ce guide déroule toute la mise en place : installer signal-cli, le lier à votre compte Signal comme appareil secondaire, lancer le daemon HTTP, le brancher au runtime Hermes et les pièges qui mordent au premier déploiement. Si vous avez déjà installé Hermes sur une surface plus publique, le tutoriel Slack et le guide Telegram couvrent le même bout de la stack et méritent d'être ouverts côte à côte.

Ce qu'il vous faut avant de commencer

Un déploiement Signal propre demande cinq éléments sur l'hôte :

Une installation de Hermes Agent qui tourne. Le guide Hermes Agent sur Docker est le point de départ le plus propre si vous n'en avez pas encore.
Une clé API d'un fournisseur de modèle. Anthropic, OpenAI, OpenRouter et tout endpoint compatible OpenAI conviennent. Le runtime s'en sert pour vraiment répondre aux messages.
Un compte Signal déjà activé sur un appareil principal (votre téléphone). signal-cli se lie comme appareil secondaire, exactement comme Signal Desktop - il n'enregistre pas un nouveau compte.
Java Runtime Environment 21 ou plus récent. Le jar de signal-cli ne démarre pas en JRE 17 dans les builds actuels. Le binaire natif GraalVM évite cette contrainte si vous préférez un seul exécutable.
Environ 20 minutes pour la première installation. Les redéploiements suivants prennent moins d'une minute.

Le numéro de téléphone que vous utilisez n'a pas besoin d'être celui de votre téléphone du quotidien. Beaucoup de personnes qui s'auto-hébergent dédient un second numéro (une eSIM bon marché, un numéro Twilio, ou une ligne Google Voice qui accepte les SMS) pour que le compte du bot reste opérationnellement séparé.

Étape 1 - Installer signal-cli sur votre hôte

Sur Debian ou Ubuntu, installez Java et récupérez la dernière release de signal-cli :

sudo apt update
sudo apt install -y curl openjdk-21-jre
VERSION=$(curl -s https://api.github.com/repos/AsamK/signal-cli/releases/latest | jq -r .tag_name | sed 's/^v//')
curl -L -o /tmp/signal-cli.tar.gz \
  "https://github.com/AsamK/signal-cli/releases/download/v${VERSION}/signal-cli-${VERSION}-Linux.tar.gz"
sudo tar -xf /tmp/signal-cli.tar.gz -C /opt
sudo ln -sf "/opt/signal-cli-${VERSION}/bin/signal-cli" /usr/local/bin/signal-cli
signal-cli --version

Si vous préférez un binaire statique unique sans dépendance JRE, le build natif GraalVM disponible sur la page des releases est un remplaçant direct et évite le cycle de mises à jour Java.

Étape 2 - Lier signal-cli à votre compte Signal

signal-cli rejoint votre compte comme appareil lié, exactement comme Signal Desktop. Générez une URL d'approvisionnement et faites afficher un QR code par le daemon :

signal-cli link -n "hermes-agent"

La commande imprime une URL sgnl://linkdevice?... et un QR dans le terminal. Sur votre téléphone, ouvrez Signal, allez dans Paramètres -> Appareils liés -> Lier un nouvel appareil et scannez le QR. En quelques secondes, le terminal affiche quelque chose comme :

Associated with: +12025550123

Ce numéro en E.164 est votre valeur SIGNAL_ACCOUNT pour la suite de la configuration. L'état disque de l'identité liée vit sous ~/.local/share/signal-cli/. Sauvegardez ce dossier avant de détruire l'hôte - c'est le seul endroit où les clés de l'appareil lié sont stockées, et relier depuis zéro invalide l'historique en attente.

Étape 3 - Lancer le daemon HTTP signal-cli

Le gateway Hermes parle à signal-cli en HTTP, donc le daemon doit tourner en mode HTTP attaché à un port uniquement local :

signal-cli -a +12025550123 daemon --http 127.0.0.1:8080

Le flag --http expose un endpoint JSON-RPC pour l'envoi et un flux Server-Sent Events pour la réception. Attachez-le à 127.0.0.1 et à rien d'autre ; le daemon ne fait aucune authentification de son côté, donc tout processus capable d'atteindre le port peut envoyer des messages comme s'il était vous. Si le gateway tourne dans Docker sur le même hôte, host.docker.internal:8080 ou un réseau Docker partagé fonctionnent sans exposer le port au LAN.

Pour des déploiements de longue durée, posez une unit systemd pour que le daemon redémarre après un reboot. Le wiki de signal-cli propose un modèle prêt à l'emploi ; les seuls champs à remplir sont le numéro de compte et l'adresse de bind.

Un terminal divisé montrant les logs du daemon signal-cli à gauche et les logs du gateway Hermes à droite, tous deux connectés via localhost:8080

Étape 4 - Configurer le runtime Hermes

Ouvrez ~/.hermes/.env (ou le .env que votre conteneur lit) et ajoutez :

SIGNAL_HTTP_URL=http://127.0.0.1:8080
SIGNAL_ACCOUNT=+12025550123
SIGNAL_ALLOWED_USERS=+33611222333,+12025557788
SIGNAL_GROUP_ALLOWED_USERS=group.abc123==
SIGNAL_HOME_CHANNEL=+33611222333

Une note sur chacune :

SIGNAL_HTTP_URL - l'endpoint du daemon local de l'étape 3. Toujours http://, toujours loopback ou réseau privé.
SIGNAL_ACCOUNT - le numéro en E.164 de l'identité Signal liée. Doit correspondre exactement à ce que signal-cli link a affiché.
SIGNAL_ALLOWED_USERS - numéros E.164 ou UUIDs Signal séparés par virgule autorisés à parler au bot. Sans cette variable (et sans appariement DM), le gateway refuse chaque message entrant comme valeur sûre par défaut. C'est le contrôle de sécurité le plus important de toute la stack.
SIGNAL_GROUP_ALLOWED_USERS (optionnel) - IDs de groupe séparés par virgule où le bot peut répondre. Les IDs viennent de signal-cli listGroups -d. Laissez vide pour désactiver le support des groupes.
SIGNAL_HOME_CHANNEL (optionnel) - la cible de livraison par défaut pour les tâches planifiées, les cron jobs et les notifications déclenchées par des skills. Sans valeur, la sortie proactive va au premier utilisateur autorisé.

Faites chmod 600 ~/.hermes/.env après avoir sauvegardé. La combinaison de l'identité Signal liée et de vos clés fournisseur de modèle permet à quiconque a accès en lecture d'usurper le bot et de brûler vos tokens - traitez le fichier comme une clé SSH.

Étape 5 - Démarrer le gateway et envoyer le premier message

Redémarrez le gateway Hermes pour qu'il récupère le nouvel environnement :

hermes gateway restart

Suivez les logs et cherchez deux lignes, dans cet ordre :

signal: connecting to http://127.0.0.1:8080
signal: subscribed to receive stream for +12025550123

Depuis le téléphone autorisé, ouvrez Signal et envoyez un DM au numéro du bot. Hermes répond dans le même fil, avec mémoire persistante et contexte des skills intacts - le tutoriel mémoire et skills raconte ce qui se passe en dessous. Les pièces jointes jusqu'à 100 Mo passent par la même API d'upload Signal qu'un message normal, donc captures, messages vocaux et PDFs circulent sans tuyauterie supplémentaire.

Un fil Signal montrant un échange privé entre un utilisateur et le bot Hermes, avec les indicateurs de chiffrement de bout en bout visibles en haut de l'écran

Les fautes qui mordent en premier

Cinq erreurs expliquent presque tout "le setup Signal est cassé" au support :

Oublier de lier l'appareil. Lancer signal-cli daemon sur un compte non lié n'imprime aucune erreur - le daemon démarre et refuse silencieusement chaque message. Si les logs montrent zéro événement et zéro tentative d'envoi, lancez signal-cli listAccounts et vérifiez que votre numéro y figure.

Mauvaise version de JRE. Les builds actuels de signal-cli exigent JRE 21. Sur des serveurs anciens coincés en JRE 17 ou 11, le jar échoue avec une erreur de version de classe dès que vous appelez --http. Soit vous mettez Java à jour, soit vous utilisez le binaire natif GraalVM.

SIGNAL_ALLOWED_USERS vide. Le défaut est de refuser tout le monde. C'est délibéré - un numéro fuité de la compte du bot laisserait n'importe qui dans le monde envoyer des prompts et brûler vos tokens. Le bot qui paraît mort à un testeur de première fois qui a oublié d'ajouter son propre numéro est la fausse alerte la plus fréquente.

Daemon attaché sur 0.0.0.0. Le daemon HTTP ne fait aucune authentification. L'attacher à une interface publique veut dire que quiconque atteint le port peut envoyer des messages Signal comme s'il était vous. Toujours 127.0.0.1 ou réseau Docker privé.

État d'appareil lié obsolète. Relancer signal-cli link écrase le dossier d'état local. Le nouveau lien fonctionne, mais Hermes regarde soudain une identité différente de celle déclarée dans le .env. Soit vous gardez l'ancien SIGNAL_ACCOUNT au moment de relier, soit vous mettez à jour le env avec le nouveau numéro imprimé par la commande.

Si le problème a l'air Signal mais les symptômes paraissent plus généraux - réponses qui manquent, dérive de mémoire, erreurs du fournisseur - le guide de troubleshooting Telegram couvre les problèmes de gateway et de fournisseur en plus de profondeur. La plupart sont indépendants de la surface.

Signal à côté de Telegram et Slack

| Critère | Signal | Telegram | Slack | |---|---|---|---| | Temps de setup | 20 min (lien + daemon) | 5 min (token BotFather) | 15 min (manifest + 2 tokens) | | Chiffrement | E2E par défaut | Chats secrets en opt-in | Côté serveur uniquement | | Métadonnées stockées | Presque rien | Historique côté serveur | Rétention par workspace | | Modèle de compte | Numéro de téléphone lié | Compte bot, sans numéro | Utilisateur bot dans le workspace | | Champ d'allowlist | SIGNAL_ALLOWED_USERS (E.164) | TELEGRAM_ALLOWED_USERS (numérique) | SLACK_ALLOWED_USERS (numérique) | | Idéal pour | Individus et petites équipes orientés vie privée | Usage personnel, mobile-first, voice-mode | Workflows d'équipe et contexte de canaux |

Les trois surfaces ne sont pas exclusives. Le même runtime Hermes livre aux trois en même temps, multiplexant sur un seul stockage mémoire. Un founder avec un agent personnel sur Signal et un agent d'équipe sur Slack depuis la même installation est un schéma courant.

Sauter la plomberie Signal

Les étapes ci-dessus sont faisables mais elles vous laissent l'hôte sur les bras : maintenir signal-cli à jour, sauvegarder l'état de l'appareil lié, faire tourner le JRE, surveiller les redémarrages du daemon. Pour une installation personnelle, c'est très bien. Pour tout ce que vous voulez en ligne en quelques minutes et oublier ensuite, Hermify provisionne un runtime Hermes managé avec le pont Signal prêt à être lié, chiffre votre config SIGNAL_* au repos et garde le daemon signal-cli en bonne santé sur un serveur persistant où vous n'avez jamais besoin de vous connecter en SSH.

Vous apportez le numéro Signal et une clé de fournisseur de modèle ; la plateforme s'occupe de tout en dessous. Si vous voulez comparer ce qui reste sous votre contrôle et ce qui est délégué, la comparaison entre auto-hébergement et managé déroule les chiffres de maintenance et de coût. Et si le coût est le frein, le guide des VPS bon marché montre à quoi ressemble vraiment un auto-hébergement à 5 USD/mois. Lancez-vous avec Hermify quand vous voulez sauter la plomberie pour de bon.