Vous voyez la pastille de mise à jour, vous cliquez vers la page de release, et vous obtenez un paragraphe : c’est une release corrective, elle regroupe environ 81 pull requests fusionnées depuis la v0.22.4, et le compte rendu curaté arrive avec la v0.23.0. Aucune liste de changements, aucun point fort, rien sur le correctif que vous attendez depuis deux semaines. La seule question qui compte vraiment avant de taper hermes update reste donc sans réponse : mettre à jour aujourd’hui, ou attendre ?

La réponse courte, c’est que ce tag est un point de contrôle, pas une livraison de fonctionnalités — et le corps de la release dit bien, en une ligne, qu’une partie est laissée sans documentation ici exprès. Ces lignes délibérément omises s’avèrent être la partie utile : cet article les couvre, avec les chiffres et le chemin de mise à jour par plateforme.

Une release corrective est un point de contrôle, pas une livraison de fonctionnalités

Hermes produit deux types de releases. Les releases de fonctionnalités ont des noms, des sections et des captures d’écran. Les releases correctives prennent tout ce qui a été fusionné depuis le tag précédent et coupent un nouveau point stable, pour que chaque canal de distribution — la release GitHub utilisée par le CLI et le script d’installation, l’application Microsoft Store, Docker et Hermes Cloud — porte un code identique. Rien dedans n’a été conçu pour elle ; ce sont quelques jours de travail mis en lot.

L’ampleur du lot, comptée au commit bf0203a794a :

• 231 commits hors merge sur 804 fichiers modifiés, à +35 212 / −17 885 lignes
• 81 pull requests fusionnées et 30 issues fermées

Comparez maintenant avec la v0.22.4, deux jours plus tôt : 14 commits hors merge sur 82 fichiers et 13 PR fusionnées, publiée le 21 octobre. Même équipe, même canal, six fois le volume. Cette comparaison est la vraie histoire de ce tag. Tout ce qui a été fusionné le 22 et au petit matin du 23 n’a pas eu de compte rendu individuel ; il a été replié dans un rollup.

Un détail d’horodatage : le corps de la release date la sortie au 22 octobre 2026, alors que GitHub a publié le tag le 23 octobre à 05:28 UTC. Les deux sont exacts — ce moment correspond au soir du 22 en Californie.

Un diff de 35 000 lignes sans liste de fonctionnalités n’est pas un diff plein de fonctionnalités : ce sont des refactorisations, des déplacements vers des plugins, du travail sur les dépendances et des petits correctifs. C’est le sujet du reste de cet article.

Les quatre changements que vous avez probablement déjà lus

Quatre éléments de cette fenêtre ont déjà leur propre article ici. Une ligne chacun, avec le lien au cas où vous l’auriez manqué :

• La connexion Nous a été refaite pour que chaque login soit une simple connexion d’appareil, que le résultat dise qui s’est connecté, et pour que les connecteurs proposent une connexion plutôt que de larguer les visiteurs en mode invité. Plus de détails dans comment la connexion se transmet entre l’application et le navigateur.
• Les backends de délégation sont devenus pluggables, routables par mapping de modèle ou par profile, commutables par session. Le parcours du routage par backend couvre la configuration.
• Les plans à fenêtre d’usage s’affichent désormais en barres de progression et en cartes de limite dans /usage, y compris la récupération après un changement de modèle. Ce que signifie chaque jauge est dans le décodage des fenêtres d’usage.
• Les installations Windows à demi mises à jour ont eu un vrai correctif plutôt qu’une consigne de réessayer. L’histoire du lanceur explique pourquoi le repin de Python les cassait.

Tout ce qui suit est le reste des 81.

Ce que les notes disent avoir laissé de côté exprès

Le corps de la release affirme, en toutes lettres, qu’une partie de cette fenêtre n’est pas documentée exprès. Lu attentivement, ce n’est pas de la modestie : ces changements ne prennent sens qu’en phrases, pas en lignes de changelog. Ils se répartissent en trois groupes.

hermes update retient désormais une release qu’il n’acceptera pas

Le premier groupe concerne le comportement de mise à jour, et pour quiconque vit dans le CLI, c’est la partie la plus pratique de la release.

• Une release stable qu’Hermes refuse d’accepter est maintenant retenue au lieu de vous être proposée. Auparavant, la vérification pouvait faire apparaître une release comme disponible, vous cliquiez, et la mise à jour déclinait. Cette boucle coûte un clic et, pire, elle vous apprend à ne plus croire la pastille. Désormais, l’option n’est simplement pas présentée.
• Sous Windows, hermes update ne reste plus bloqué sur l’ancien lanceur après un repin de Python. Le repin change l’interpréteur que le lanceur doit appeler ; c’est le lanceur périmé qui laissait les installations à demi mises à jour.
• hermes update peut récupérer un gateway suspendu après un .git endommagé. L’élément le moins glamour, et probablement celui qui sauve le plus d’après-midis : un dépôt corrompu laissait auparavant le gateway à l’arrêt, et le chemin de réparation le remet en marche au lieu de vous demander de réparer git d’abord.

Les trois tournent autour de la commande de mise à jour qui refuse de vous laisser dans un état que vous ne pouvez pas comprendre. Aucune n’ajoute de flag ; chacune retire une façon de rester coincé.

Le cœur continue de maigrir

Le second groupe, c’est la migration continue des fonctionnalités intégrées vers des plugins.

hermes import-agent, la migration OpenClaw, hermes mcp serve et le backend Singularity ont tous quitté le cœur pour des plugins. Setup remarque maintenant qu’un autre agent est déjà installé chez vous et vous propose l’importateur, au lieu de vous laisser le découvrir seul.

Si après la mise à jour une commande que vous utilisiez la semaine dernière a disparu, vérifiez le catalogue de plugins avant de conclure à une suppression. Ce n’est pas nouveau — la v0.22.4 avait déplacé les mêmes commandes — mais c’est avec la v0.22.5 que cela cesse de ressembler à un nettoyage ponctuel pour ressembler à l’architecture.

Dans le même groupe : les commandes slash de plugin peuvent désormais vous demander de choisir une option avant de continuer. Une commande qui s’exécutait avec un comportement figé peut faire une pause et présenter un choix. Petit changement d’interface, grand changement pour ce qu’un plugin peut être : une commande avec une branche, pas seulement une macro.

Et un élément porte honnêtement l’étiquette expérimentale : un client d’événements MCP en mode webhook. N’asseyez pas encore un workflow dessus.

Desktop : épingler par glisser, des badges, et un bot qui dit qui travaille

Le troisième groupe est l’application desktop, où les changements sont petits mais tombent chaque jour.

• Épinglage par glisser dans la barre latérale. Les entrées de la barre latérale peuvent être glissées vers une position épinglée au lieu de vivre là où l’application décide de les mettre.
• Installation de plugin en un clic avec badges de niveau. Installer depuis l’application est une seule action, et le badge annonce le niveau avant que vous cliquiez.
• Electron 44, Pillow 13, et une série de mises à jour de sécurité des dépendances. Rien à configurer ; la raison de les prendre, c’est que vous préférez ne pas continuer à faire tourner les anciennes versions.
• Le chat de groupe indique à nouveau quel bot travaille. Correction d’une régression : avec plusieurs bots dans un salon, cet indicateur est le seul moyen de savoir qui répond, et sans lui le salon paraît cassé plutôt que lent.
• Une conversation dont le répertoire de travail a disparu le dit maintenant clairement. Les échecs vagues à cet endroit envoient les gens auditer le modèle, le réseau et leur prompt avant que quiconque vérifie si le dossier existe encore.
• Les longues réponses de Claude DirectSDK ne sont plus coupées par le minuteur de blocage. Si un provider lent vous a déjà tronqué une réponse en pleine phrase, c’est la ligne à retenir.

Mettre à jour, plateforme par plateforme

Où vous faites tourner Hermes	Comment la v0.22.5 vous arrive
Installation CLI	hermes update, ou relancer la ligne d’installation
Application Microsoft Store	via le Store
Application desktop depuis l’installeur (.exe / .dmg)	inchangée dans cette release ; elle bouge avec la prochaine release groupée
Docker / Hermes Cloud	nousresearch/hermes-agent:stable (ou :latest)

La troisième ligne est celle qu’on lit mal : un correctif qui livre le CLI, l’application Store, Docker et le Cloud ne reconstruit pas forcément les bundles .exe et .dmg. Un utilisateur du desktop peut lancer hermes update, voir le CLI passer en v0.22.5, et rester sur le build desktop précédent — comportement correct, pas une mise à jour ratée.

Quand attendre la v0.23.0

Attendez si ce que vous voulez, c’est le récit plutôt que le binaire. Les notes curatées de toute cette fenêtre — tout depuis la v0.22.0, avec les points forts, les fonctionnalités groupées par domaine et la liste complète des contributeurs — arrivent avec la v0.23.0. Un tag rollup vous dit ce qui a bougé ; il ne vous dira jamais pourquoi quelqu’un l’a construit.

Mettez à jour maintenant si l’un de ces points est votre problème : une vérification de mise à jour qui propose une release puis la refuse, une installation Windows coincée sur un ancien lanceur, un gateway laissé à l’arrêt après un .git endommagé, de longues réponses tronquées sur Claude DirectSDK, un chat de groupe incapable de dire quel bot travaille, ou une session qui échoue parce que son répertoire de travail a disparu. Ce n’est pas une liste de fonctionnalités. C’est une raison décente de bouger aujourd’hui.

Et 81 PR en deux jours sans compte rendu n’est pas un signal d’alarme — c’est ainsi qu’un projet à ce rythme maintient cinq canaux de distribution sur le même code. Le compte rendu existe ; il est programmé pour la prochaine release de fonctionnalités.