Vous voyez « Hermes Agent v0.21.5 released » dans un flux, vous cliquez, et le corps du message tient en un paragraphe : c’est un tag correctif qui fige la fenêtre dans une release stable pour les images Docker et les déploiements hébergés, et la synthèse complète est reportée à v0.22.0. Vous lancez hermes update, le terminal annonce que la mise à niveau a réussi. Et ensuite — qu’avez-vous réellement obtenu ? Rien de ce que vous avez lu ne vous le dit, et vous n’êtes même pas certain que mettre à jour aujourd’hui était le bon choix. Ce n’est pas de la paranoïa ; c’est ce que les tags correctifs font aux gens. Ce billet traite donc d’une seule chose, étroite et pratique : comment répondre à cette question sans attendre les release notes.

Pourquoi les tags correctifs sortent souvent sans notes

Réglez ce point une bonne fois et vous cesserez de vous reposer la question toutes les quelques semaines.

Hermes publie deux sortes de tags. Une release sémantique — v0.20.0, v0.21.0 — s’accompagne d’une longue synthèse : points forts, domaines fonctionnels, crédits des contributeurs. Un tag daté comme celui-ci, v2026.9.24, répond à un autre besoin : sceller tout ce qui sépare le tag précédent de maintenant dans une seule version stable et tirable.

Pourquoi cela doit-il exister ? Parce que les images Docker, Hermes Cloud et les déploiements hébergés se construisent tous à partir du tag de release le plus récent, pas de main. Un correctif que vous mergez sur main n’atteint pas les utilisateurs du cloud tant qu’il n’est pas dans un tag. Quand assez de choses se sont accumulées, un tag correctif ferme la fenêtre.

Le prix à payer, c’est que rien de ce qui se trouve dans la fenêtre n’est documenté ni nommé individuellement. Cette fenêtre compte 460 PR fusionnées, 1 610 commits non fusionnés, 4 828 fichiers modifiés (+164 132 / −149 440) et 475 issues fermées depuis v0.21.4, mesurés au commit f97608f178d1ffeca59860195ab7da295f7c8e5f. Le corps de la release précise explicitement que rien n’est laissé de côté : tout sera documenté ensemble dans v0.22.0, qui couvrira tout depuis v0.21.0.

Autrement dit : « pas de release notes » ne veut pas dire « rien dedans ». Votre mise à niveau est réelle. La liste n’est simplement pas encore écrite.

Étape 1 : déterminez sur quelle version vous êtes

Ne vous fiez pas au ressenti. Une seule commande :

hermes --version

Vous obtiendrez quelque chose comme Hermes Agent v0.21.5 (2026.9.24) · upstream <commit>. Notez la relation entre les deux numéros :

Ce que vous voyez	Ce que cela signifie
v2026.9.24	Le tag daté — le nom affiché sur la page GitHub de la release
v0.21.5	La version sémantique — utilisée dans les artefacts, les noms d’images et votre config.yaml

C’est la même release, pas deux. Voir v2026.9.24 sur GitHub alors que votre machine affiche v0.21.5 est normal — n’essayez pas de « corriger » cela.

Sur une installation git, vous pouvez aussi voir sur quel commit vous êtes :

cd ~/path/to/hermes-agent && git log --oneline -1

Sur Docker, lisez le tag de l’image : nousresearch/hermes-agent:v2026.9.24 est cette release. Celle-ci ajoute aussi un axe de variantes — :latest-desktop / :main-desktop / :v*-desktop embarquent Xvnc/Xfce et le Chromium headed de Playwright, ce qui livre Bot Screen sur les déploiements hébergés. Ces paquets ne peuvent pas être installés à l’exécution sur l’image publiée (utilisateur non privilégié, pas de sudo, /opt/hermes scellé), donc la couche d’image est le seul chemin.

Étape 2 : sautez les 460 PR, lisez la comparaison

Le lien de comparaison « full changelog » est le point d’entrée qui fait autorité :

https://github.com/NousResearch/hermes-agent/compare/v2026.9.21...v2026.9.24

Il est énorme, mais vous n’en avez besoin que de trois tranches : les nouveaux fichiers (surtout les nouvelles pages sous website/docs/, qui signalent l’arrivée d’une fonctionnalité), le diff de config_defaults.py (qui signale de nouvelles clés de config) et le diff de hermes_cli/ (qui signale de nouvelles commandes ou options). Parcourir ces trois tranches vaut mieux que lire les titres de PR de haut en bas.

Étape 3 : huit choses déjà utilisables dans cette fenêtre

Tout ce qui suit est bien présent dans ce tag. Chaque point vient avec ce que vous tapez réellement.

1. Desktop gagne des catalogues français, allemand et espagnol complets

Desktop embarque désormais des catalogues d’interface complets pour les trois, sélectionnables sous Settings → Appearance → Language. display.language: fr|de|es, ainsi que les alias régionaux comme fr-CA, de-AT et es-419, se résolvent vers le catalogue correspondant au lieu de retomber sur l’anglais. Les noms de produits et les identifiants (Hermes, MCP, API, OAuth, identifiants de modèles) restent non traduits.

2. Un réglage de direction du texte : Auto / RTL / LTR

Plus bas sur la même page se trouve Chat display → Text direction. Chaque bloc de prose de chat déduisait auparavant sa direction de son premier caractère fort, ce qui se trompe à coup sûr sur un paragraphe arabe qui commence par un nom latin. Désormais vous pouvez le dire explicitement : Auto conserve l’ancien comportement, RTL/LTR applique un dir à la prose et aux deux composers. Le code reste LTR, l’habillage de l’application ne bascule pas, et aucun caractère de contrôle bidi n’est ajouté à votre texte. C’est une préférence de lecture dans l’interface, pas une clé de config.yaml.

3. Les livraisons webhook peuvent se refléter dans la session du chat cible

Une livraison était auparavant fire-and-forget, donc répondre « quelle build ? » dans ce chat vous valait « à qui faites-vous référence ? ». Une route peut maintenant l’activer :

hermes webhook subscribe ci-alerts \
  --prompt "build {route} failed: {payload}" \
  --deliver telegram \
  --mirror-to-session

Un abonnement réussi affiche une ligne supplémentaire indiquant que chaque livraison est reflétée dans la session du chat cible. Désactivé par défaut ; seul un vrai booléen true l’active. Les limites sont traitées dans le guide dédié, lié plus bas.

4. Ajouter un modèle par slug depuis chaque sélecteur de modèles

Une nouvelle ligne de pied de menu Add custom model… transforme le champ de recherche du menu de modèles en saisie de slug, en proposant une ligne par provider configuré au fil de la frappe, et le slug mémorisé reste dans la liste comme une ligne normale avec un × de suppression. Fonctionne dans le menu du composer, la boîte de dialogue de changement de modèle, Settings → Model et la liste d’édition des modèles.

5. Les voix locales ne se rechargent plus à chaque réveil

Une nouvelle clé de config, tts.keep_warm_seconds, défaut 60 :

hermes config get tts.keep_warm_seconds    # 60
hermes config set tts.keep_warm_seconds 0  # décharger immédiatement

Après la libération du dernier lease, le déchargement attend ce délai ; réactiver la parole dans cette fenêtre l’annule et réutilise le modèle chargé. Cela compte surtout pour les conversations vocales en wake-only, qui se terminent juste après leur préchauffage d’environ 2 s et perdaient auparavant la voix chargée quelques millisecondes plus tard.

6. La boucle vocale du desktop commence à lire votre config

Read Aloud ne prononce plus de textes de remplacement anglais comme code block omitted ou link et ne fait plus disparaître silencieusement les tableaux — les blocs de code et les URL passent en silence, et les tableaux prononcent leur ligne d’en-tête à la place. L’arrêt vocal lit désormais voice.stop_phrases (défaut ["stop"]) ; il correspondait auparavant à une liste anglaise codée en dur, donc un utilisateur russophone disant отбой comme l’y invitait le message se le voyait envoyé à l’agent comme prompt. Le déclencheur de lecture de la barge-in utilise désormais voice.barge_in_threshold_multiplier (défaut 3.0) au lieu d’un 0.14 codé en dur qui se situait au-dessus du niveau de parole d’un casque Bluetooth HFP, ce qui explique que parler par-dessus une réponse ne l’interrompait jamais.

7. Les raccourcis vocaux par touches de fonction sont réassignables

La dictée ponctuelle est désormais une action clavier composer.dictate non liée, distincte de la conversation vocale, réutilisant le chemin de capture canonique de Desktop pour les F-keys, Caps Lock, Delete, Space et les combinaisons de modificateurs ; une F12 assignée atteint le renderer tandis qu’une F12 non assignée conserve le comportement DevTools. Dans la même fenêtre, les touches de fonction macOS ont aussi été corrigées — l’analyseur du TUI préserve intacts les séquences de terminal F1–F12, et le dock de travail en direct gagne Ctrl+R comme repli portable de F7.

8. Une série de pannes qui ne frappaient que les Windows localisés

• Sous Windows français, espagnol ou allemand, %Z levait une UnicodeEncodeError à l’intérieur de strftime, parce que les noms de fuseaux arrivent sous forme d’octets de page de code ANSI qui se décodent en surrogates isolés. hermes_time.safe_strftime() s’en charge désormais, et sur les locales saines sa sortie est identique octet pour octet à avant, donc l’invariant du cache de prompt tient.
• Le [gateway-crash] ... UnicodeDecodeError: 'gbk' codec can't decode qui défilait sous Windows chinois est corrigé : la sortie des processus enfants est désormais épinglée en UTF-8.
• C:\...\report.html et les chemins UNC \\server\share\... sont reconnus comme des chemins et s’affichent correctement en aperçu, au lieu d’être concaténés au répertoire de travail en /repo/C:\....
• Sur un démarrage à froid Windows, la boucle d’événements du backend local se bloque pendant 12–28 s pendant l’import des modules du gateway, et une sonde de démarrage fixe de 10 s l’enregistrait comme un échec de démarrage. Un backend lancé par cette application attend désormais tant que l’enfant est vivant, jusqu’à un plafond de 90 s.

Auto-vérification en cinq minutes

Après la mise à niveau, ceci confirme que vous avez bien la nouvelle surface (sur v0.21.5 ou plus récent) :

hermes --version                                        # attendez v0.21.5 (2026.9.24)
hermes config get tts.keep_warm_seconds                 # 60
hermes config get voice.stop_phrases                    # - stop
hermes config get voice.barge_in_threshold_multiplier   # 3.0
hermes webhook list                                     # indique quelles routes font un miroir

Quand vous devriez vraiment attendre v0.22.0

Vous ne devriez pas. Tout ce qui se trouve dans un tag correctif est déjà le code qui tourne sur votre machine — aucun document ne conditionne votre mise à niveau. Deux groupes ont toutefois une raison d’attendre : les distributeurs en aval (ceux qui empaquettent les images ou produisent des builds internes pour une équipe) et quiconque écrit un tutoriel sur cette fenêtre, parce que leur liste se lira mieux.

Si Hermes n’est qu’un outil que vous utilisez, le seul test qui compte est : tel problème précis que vous rencontrez est-il corrigé ici ? Cette fenêtre a quantité de candidats — prenez n’importe lequel des huit groupes ci-dessus et essayez.

En bref

• Un tag correctif sans notes est un mécanisme, pas un haussement d’épaules : il existe pour que les images Docker et les déploiements hébergés récupèrent des correctifs qui vivent sur main.
• La version a deux formes ; v2026.9.24 et v0.21.5 sont une seule release.
• Pour la liste, parcourez trois tranches de la comparaison — les nouvelles docs, le diff de config_defaults.py, le diff de hermes_cli/.
• Huit groupes de changements de cette fenêtre sont utilisables dès maintenant, des nouveaux catalogues de Desktop aux quatre correctifs de crash liés à la localisation Windows.

Pour le relevé plus complet de cette fenêtre, notre page de release v0.21.5 la regroupe par domaine fonctionnel ; pour la fenêtre corrective précédente, voir le parcours de la fenêtre v0.21.4. Le miroir webhook a son propre guide, et les changements vocaux sont traités dans keep-warm et le streaming phrase par phrase. Vous partez d’une machine vierge ? Le guide d’installation donne le chemin complet.