Jeudi après-midi, vous vous apprêtez à déployer le dernier build sur une poignée de machines de l’équipe. Vous ouvrez la note de version et vous trouvez un paragraphe, plus une ligne indiquant que le récapitulatif complet arrivera avec v0.23.0. Ce que vous voulez vraiment savoir est plus étroit : le quotidien de vos collègues va-t-il changer, que manque-t-il dans ce tag, et faut-il mettre à jour maintenant ou attendre ?

Cet article répond à ces trois questions pour v0.22.7. Publiée le 3 novembre 2026, c’est une version purement corrective dont le rôle est de transformer la file de fusions accumulée depuis v0.22.6 en un numéro de version que vous pouvez installer, annuler et épingler dans un manifeste de déploiement.

L’ampleur de la fenêtre

Les mesures publiées sont prises au commit b200f5bc60e :

• 174 PR fusionnées
• 581 commits hors fusion sur 554 fichiers modifiés, +24 012 / −3 144 lignes
• 29 issues fermées

C’est un ordre de grandeur de moins que le récapitulatif précédent : v0.22.6 embarquait 776 PR et 3 448 commits. L’intention est claire — pas une nouvelle version de fonctionnalités, mais un point stable après deux semaines de correctifs. La note précise que la documentation complète et relue de tout ce qui est sorti depuis v0.22.0 arrivera avec v0.23.0, et que rien dans cette fenêtre n’est laissé de côté.

Au-delà des chiffres, voici les changements qui vous concernent vraiment.

Ce qui est déjà dans ce tag

1. Web Access Start nomme désormais l’étape en cours

Un clic sur Start dans le panneau Web Access du bureau déclenche trois choses en une seule requête : construire la webapp (plusieurs minutes la première fois), enregistrer la connexion Nous et redémarrer le gateway. Le panneau affichait auparavant un unique « Starting » pour toute la manœuvre, si bien qu’un build de plusieurs minutes semblait bloqué, et rouvrir le panneau en pleine construction vous rendait un autre bouton Start, comme si le premier clic s’était évaporé.

Le panneau nomme maintenant l’étape — construction, configuration de la connexion, redémarrage — et compte le temps écoulé depuis Start. La progression est suivie par le backend, par gateway, sous start_progress sur /api/webapp-access/status : c’est pourquoi un panneau rouvert ou une seconde fenêtre affichent le même état ; le panneau relit ce statut une fois par seconde, uniquement tant que sa requête Start est en attente et que la fenêtre est visible. Un backend plus ancien dépourvu du champ n’est pas interrogé du tout.

Si quelqu’un dans votre équipe a décrit le premier Start comme « on aurait dit que ça avait planté », cette version supprime les conjectures.

2. Les tâches planifiées peuvent publier dans un Group Chat

Les salons de groupe du Bot Mode sont désormais une vraie cible de livraison. Le champ deliver d’une tâche cron accepte :

deliver: room:<room_id>@<profile>

La sortie arrive dans le salon sous forme d’un message unique, étiqueté avec le nom de la tâche et un tag Scheduled. L’essentiel est la règle de réveil : seuls les bots que vous mentionnez avec @ prennent la parole. Une publication planifiée qui ne nomme personne reste un message dans le salon et ne déclenche aucun appel au modèle ; @all s’adresse à tout le monde. Un avis d’échec est également publié, et ne lance jamais de tour.

Les salons ont aussi gagné deux champs que chaque membre voit en haut de son tour, modifiables depuis Room settings :

• Purpose — à quoi sert le salon, jusqu’à 500 caractères
• Shared notes — jusqu’à 4 Ko

Écrivez une fois « c’est le salon ops, consultez d’abord le planning d’astreinte » au lieu de le répéter dans chaque message.

Le même lot a ajouté le lead routing, activable par salon : quand un message ne nomme personne, un bot lead décide qui doit le prendre et le salon affiche une ligne discrète du type ada gave this to linus, pour que vous voyiez le choix et puissiez le corriger. Les valeurs par défaut ne bougent pas — les salons sans lead continuent en round-robin séquentiel, où tout le monde répond. Pour les équipes où cinq ou six bots d’un même salon se jettent sur chaque message, ce commutateur vaut l’essai.

Les salons de groupe ont aussi adopté la disposition de chat native : une seule colonne, avec l’état en direct de chaque membre visible dans la liste au lieu d’être deviné.

3. La carte Telegram renvoie vers une configuration qui fonctionne sur Team Gateway

Si vous faites tourner Telegram sur un Team Gateway, la carte Hermes Cloud vous envoyait dans un flux de configuration mono-machine qui se terminait sur un mur de permissions. Elle pointe désormais vers la liaison de compte Portal, qui fonctionne sous Team Gateway. Petit changement, mais c’était un blocage net pour le modèle de déploiement à bot partagé.

Ce qui reste sur main uniquement

C’est la partie qui fait mal lors des mises à jour : une PR fusionnée sur GitHub ne signifie pas que le changement est dans le tag que vous venez d’installer. Plusieurs correctifs ont atterri sur main après la découpe de v0.22.7 et attendront la prochaine version :

• Avis de sécurité des dépendances — les alertes undici, zod, fast-uri, qs, pypdf et pyasn1 qui atteignaient le seuil d’ancienneté de publication sont traitées.
• Slash final de l’émetteur OAuth MCP — les connexions pour les émetteurs qui ne diffèrent que par une barre oblique finale (Otter.ai entre autres) aboutissent maintenant.
• Nouveaux chats sur bureau distant — les connexions par ticket public échouaient à chaque nouveau chat avec Session unavailable / invalid_params, parce que le canal canonique d’autorité de session n’était sélectionné que si l’URL portait le marqueur privé native_dial, alors que le gateway annonçait déjà session_authority: true dans gateway.ready. Le correctif négocie à partir de cette annonce.
• Une bibliothèque de skills plus petite — sept skills optionnels sont retirés et les dépôts fournisseurs Notion, Airtable et Shopify deviennent des sources de confiance.
• Fenêtres de bureau réduites — moins de travail de streaming quand la fenêtre est réduite, aperçus inactifs bridés et détection vocale qui continue de fonctionner quand la fenêtre n’est pas visible.

Pour savoir si une PR est dans le build que vous exécutez, comparez l’ascendance avec le tag plutôt que de vous fier aux horodatages de fusion :

git fetch --tags origin
git merge-base --is-ancestor <merge_commit_sha> v0.22.7 && echo "in tag" || echo "main only"

Comment mettre à jour

Choisissez la ligne qui correspond à votre installation :

# CLI / installateur
hermes update

# Docker / Hermes Cloud
docker pull nousresearch/hermes-agent:stable

# Application Microsoft Store
# se met à jour via le Store, pas via ce tag

Les builds de bureau installés depuis le .exe / .dmg n’ont aucun changement embarqué dans cette version et suivront la prochaine version embarquée.

Faites un snapshot d’abord, surtout sous Windows — non pas parce qu’une version corrective est risquée, mais parce que l’updater touche state.db, et un snapshot transforme une mauvaise surprise en surprise banale :

hermes backup --quick

Mettre à jour maintenant, ou attendre une semaine

Trois décisions rapides :

• Vous utilisez Web Access ou les salons Bot Mode : mettez à jour. Les deux différences se voient chaque jour.
• Vous avez une installation CLI mono-agent, sans salons ni bureau distant : attendre une version est raisonnable, et vous récupérez les correctifs main-only d’un coup.
• Vous faites passer le trafic des modèles derrière un proxy qui inspecte le TLS : attendez et lisez d’abord notre analyse de la régression SSL_CERT_FILE, car elle touche chaque appel au modèle.

Un numéro de version n’est que de l’emballage. Ce qui décide si vous agissez aujourd’hui, c’est de savoir si cette fenêtre a touché les boutons que vous pressez chaque matin.

Pour aller plus loin : le décryptage de la fenêtre v0.22.6, le guide du chat de groupe Bot Mode, toutes les versions, installation et mise à jour.