La première fois que vous installez Hermes, il vous demande si vous voulez activer les shared metrics locales. La plupart des gens répondent non par réflexe et n’y pensent plus jamais. Puis un jour vous voulez savoir ce qu’il aurait envoyé, vous ouvrez la doc, et vous tombez sur un mur de noms de métriques et de jargon de fenêtre de consentement. Alors vous fermez l’onglet.

Voici l’ensemble en une seule passe. La version courte : tout est désactivé par défaut ; la collecte et la transmission sont deux opt-ins distincts ; ce qui est enregistré, ce sont des compteurs bornés, jamais les prompts, le contenu des fichiers, les chemins, les valeurs de réglages ni le texte des erreurs. Et un changement fusionné le 6 octobre rend ces compteurs réellement utiles pour vous, pour la première fois.

Deux interrupteurs, pas une case à cocher

La config se trouve sous telemetry.shared_metrics dans config.yaml :

telemetry:
  shared_metrics:
    enabled: false   # collecte en local — désactivé par défaut
    send: false      # transmission à Nous — désactivé par défaut
    endpoint: "https://telemetry.nousresearch.com/v1/telemetry"

Trois choses à savoir :

• enabled collecte, send transmet. Ce sont des opt-ins indépendants. Avec seulement enabled activé, tout reste sur votre machine et n’en sort jamais.
• send exige enabled et ne l’implique jamais. Mettez send: true avec enabled: false et Hermes journalise une erreur au lieu d’activer discrètement la collecte à votre place — un flag de transmission ne devrait pas pouvoir démarrer la collecte.
• Seuls les paquets dont toute la période tombe dans une fenêtre de consentement enregistrée sont envoyés. Activez aujourd’hui et rien d’avant aujourd’hui n’est téléversé rétroactivement.

L’endpoint n’est délibérément pas surchargeable par une variable d’environnement, et une adresse non-HTTPS est refusée sauf si elle pointe vers localhost.

Ce qui est réellement enregistré

La liste officielle est longue, mais tout se résume à un principe : des compteurs bornés, des ensembles de valeurs fermés. Quelques exemples représentatifs :

Métrique	Ce qu’elle enregistre
hermes.process.exit	Comment un processus CLI / TUI / gateway / cron s’est terminé : proprement, crash (famille exception uniquement), tué, watchdog
hermes.tool_overhead.count	Nombre mis en buckets d’outils activés et des tokens que leurs définitions ajoutent à chaque requête
hermes.tool_enabled_unused.count	Quels toolsets par défaut vous avez activés et jamais utilisés
hermes.feature_disabled.count	Quels toolsets, skills, plugins ou réglages vous avez désactivés
hermes.provider_setup.count	Où la configuration du provider a échoué, et dans quelle classe d’échec
hermes.desktop.onboarding	À quelle étape du premier lancement les gens s’arrêtent

Les noms n’apparaissent tels quels que lorsqu’ils sont fournis par Hermes — un toolset, skill ou plugin personnalisé est enregistré comme custom. Les réglages enregistrent le chemin de la clé, jamais la valeur. Le résumé de la doc est précis : jamais les prompts, les fichiers, les chemins, les valeurs de réglages ni le texte des erreurs.

Nouveau : les échecs disent maintenant pourquoi

Avant la PR #133809, la télémétrie savait qu’un run avait échoué et à quelle étape il était mort — mais pas pourquoi. Trois chiffres rendaient l’angle mort évident : 22–27 % des installs CLI qui tentaient une mise à jour ont rencontré un échec ce jour-là (14–18 % sur desktop) ; environ 35 % des événements d’installation de skill échouent et environ 33 % des installations de plugin ; et 12 % des mises à jour git échouées affichaient failed_stage=other, ce qui signifie que toutes les marques d’étape étaient passées et que le run échouait quand même.

Le nouveau failure_class est un ensemble fermé, dérivé à chaque site de raise ou à partir du type d’exception — le texte du message n’est jamais lu. Exemples :

• Skills : ambiguous, auth_rejected, fetch_failed, invalid_bundle, not_found, rate_limited, scan_blocked, stale_index ;
• Plugins : clone_failed, deps_declined, git_missing, incompatible, manifest_invalid, removed_from_catalog ;
• MCP : auth_required, config_invalid, connect_failed, missing_credentials, server_start_failed ;
• Toutes catégories : none, exception, filesystem_error, network, other, permission.

Le mauvais étiquetage other est corrigé aussi : une mise à jour partielle — la vérification post-redémarrage a trouvé une gateway ou un backend desktop qui n’était pas revenu sur le nouveau code, sans raison d’arrêt — affiche désormais failed_stage=verify avec une vraie raison. Les installations de skill et de plugin portent aussi un champ registry, qui sépare enfin « l’index officiel a servi une entrée cassée » de « l’URL que vous avez tapée est morte ». Ces deux cas se ressemblaient auparavant.

Pourquoi une installation fraîche laisse un reçu local pendant 7 jours

Un install.sh / install.ps1 tout neuf ne rapportait rien du tout auparavant, parce que la question de consentement vient après l’installation. Désormais l’installer écrit un petit fichier sous $HERMES_HOME/telemetry/shared_metrics/pending_installs/ quand il termine — ou quand une étape échoue. Il ne contient que des tokens d’ensembles fermés et deux horodatages.

Son cycle de vie répond aux deux inquiétudes évidentes :

• L’installer n’envoie jamais rien. Il laisse une note locale. Le rapport a lieu plus tard, au démarrage de Hermes, et seulement si la collecte est active à ce moment-là.
• La note vit au maximum 7 jours. Un reçu qu’aucun démarrage n’a compté en 7 jours est supprimé sans être rapporté, donc une vieille installation n’est jamais comptée sous une version plus récente de Hermes. Toute réponse de refus supprime immédiatement les reçus non rapportés.
• Un appel unique --stage n’écrit rien, et une installation interrompue par Ctrl-C ou SIGTERM est enregistrée comme interrupted.

Donc si vous avez répondu non pendant l’installation, la note est supprimée ; si vous n’avez jamais redémarré Hermes, elle expire d’elle-même.

L’activer ou le désactiver

• Guidé : hermes setup telemetry pose les deux questions séparément.
• Plus tard : hermes tools, ou l’interrupteur dans les réglages du Desktop.
• Manuel : modifiez le bloc config.yaml ci-dessus.

Désactiver la collecte retire le consentement d’envoi avec elle — la transmission ne peut pas survivre à la collecte. La doc précise explicitement que désactiver les shared metrics arrête la nouvelle collecte mais ne supprime pas en silence les données locales déjà collectées ; vider ce répertoire, c’est votre choix.

Ce que cela signifie pour vous

Si vous lisiez ceci comme « encore un interrupteur de vie privée », voici l’essentiel : désactivé par défaut, consentement en deux étapes, contenu limité à des ensembles de valeurs fermés, et même les raisons d’échec sont enregistrées comme des catégories fixes plutôt que comme du texte d’erreur. Si vous le lisiez comme « qu’est-ce que ça m’apporte », le nouveau failure_class est la réponse — vos échecs d’installation et de plugin arrivent désormais dans un bucket nommé, et un dashboard ne peut plus confondre « un registry renvoie des 404 en masse » avec « vous avez fait une faute de frappe dans une URL ».

En bref

Désactivé par défaut, collecte et transmission séparées, et ce qui est enregistré, ce sont des catégories et des comptages plutôt que votre contenu. Activez send si vous voulez contribuer ces compteurs à Nous ; ne changez rien sinon, et la note laissée par l’installer disparaîtra discrètement en une semaine.

Pour voir d’abord comment Hermes gère vos données en local, lisez chiffrement des secrets et stockage Keychain ; pour démarrer, consultez le guide d’installation.