Vous tapez hermes update, le terminal défile, et la dernière ligne annonce que la mise à niveau a réussi. Mais qu’avez-vous réellement installé — un commit arrivé hier, ou une release découpée il y a trois jours ? Sur une machine qui tourne en continu, la question compte : vous ne voulez pas passer à côté d’un correctif, et vous ne voulez pas non plus vous réveiller en suivant main sur un état que personne n’a encore foulé.

v0.21.7 traite exactement ce point. Ce n’est pas un empilement de fonctionnalités ; c’est un changement de politique. Une installation depuis les sources se met désormais à jour vers la dernière release publiée, et non vers chaque commit de main. Cet article couvre les deux aspects concrets : sur quel canal se trouve votre installation, et comment prouver ce que vous exécutez.

Ce qui a réellement changé, c’est la source de vos mises à jour

Une installation de Hermes via git signifiait autrefois que hermes update tirait l’arbre de travail jusqu’à la pointe de main. Les correctifs arrivaient vite, et vous vous teniez sur un sol mouvant : main change tous les jours, des états à moitié fusionnés peuvent subsister pendant des heures, et votre machine peut se mettre à jour pendant l’un d’eux.

À partir de v0.21.7, le défaut est le suivant : passer uniquement à la dernière release vX.Y.Z. Les règles méritent d’être lues une par une, car elles façonnent votre intuition sur le point de savoir si vous êtes en retard :

• Plus ancien que le dernier tag → vous montez jusqu’à ce tag.
• Déjà en avance sur le dernier tag (par exemple si vous avez suivi main auparavant) → rien ne bouge. Votre installation reste où elle est et attend la prochaine release. Rien n’est jamais ramené en arrière.
• Forks et miroirs → ils continuent de suivre main, sans changement.
• Microsoft Store, MSIX et l’application desktop fournie → le packaging est inchangé ; ils avancent avec leurs propres builds.

Cette deuxième règle est celle que l’on lit à tort comme « les mises à jour sont cassées ». Elle est délibérée : ramener une installation qui suit main vers un tag transformerait une mise à jour de routine en rétrogradation, et Hermes ne fait pas cela.

Canal A : les releases stables (le nouveau défaut)

Rien à configurer — une installation depuis les sources démarre ici. Vous obtenez le tag publié le plus récent, qui est v0.21.7 à l’heure où ces lignes sont écrites.

À qui cela convient : à quiconque préfère que quelqu’un d’autre foule le sol en premier. Une release est un point stable distillé à partir d’une fenêtre, et elle ne deviendra pas autre chose du jour au lendemain.

Canal B : chaque commit (activation explicite)

Pour continuer à suivre chaque commit de main, une seule commande :

hermes update --set-channel main

Une fois réglé, l’ancien comportement revient. Le retour en arrière se fait avec le même type de commande :

hermes update --set-channel stable

Si votre build est antérieur à ces flags, lancez d’abord un simple hermes update pour obtenir une version qui comprend les canaux, puis basculez.

Le canal est un état persistant, pas un flag one-shot pour une seule mise à jour. Réglez-le une fois et chaque mise à jour ultérieure s’y conforme — ne le glissez donc pas dans un script que vous oublierez.

Où se trouve l’interrupteur sur le desktop

Sur l’application desktop, c’est Settings ▸ About ▸ Updates, qui comporte un interrupteur Update channel (Stable releases / Every commit). Il n’a de sens que pour une installation depuis les sources : les installations Store, MSIX et fournies ne sont pas affectées par votre choix.

La boîte de dialogue de mise à jour vous indique également sur quel canal vous êtes actuellement, vous n’avez donc plus à vous fier à un « je crois que je l’ai réglé une fois ».

Deux interruptions du quotidien corrigées dans la même release

Deux autres éléments du corps de la release relèvent de la catégorie « on s’en fiche jusqu’au jour où ça vous arrive » :

Le raisonnement survit au resume. Avec les modèles de raisonnement Anthropic ou Bedrock Converse, la pensée signée est rejouée correctement après hermes chat --resume et au tour de gateway suivant, et les modèles de raisonnement Bedrock Converse ne sont plus rejetés sur les sessions reprises. Le mécanisme mérite son propre décryptage — quelles routes lisent quels champs, et ce qui se passe quand une route rejette un champ — et nous l’avons traité séparément : voir le guide du rejeu du raisonnement.

Les mises à jour n’échouent plus derrière certains pare-feux. Les installations sur main récupéraient auparavant un enregistrement de release auquel certains pare-feux régionaux répondaient par un 403, ce qui faisait échouer la mise à jour purement et simplement. La vérification utilise désormais votre token GitHub lorsqu’il est défini (GITHUB_TOKEN, ou gh auth login), et signale une limite de débit GitHub comme une limite de débit plutôt que comme un échec opaque.

Ce qui a atterri dans cette fenêtre

Les chiffres d’ampleur proviennent du corps officiel de la release, mesurés au commit 1fd18277267152893a8a24792b79213e7ca3f899 :

Métrique	Valeur
Commits non fusionnés	740
Fichiers modifiés	4 156 (+86 775 / −26 980)
PR fusionnées	204
Issues fermées	69

Comme pour v0.21.6, les notes complètes et éditorialisées arrivent avec v0.22.0, qui documentera tout depuis v0.21.0, y compris les points forts, les domaines fonctionnels et les crédits complets des contributeurs. Le corps de v0.21.7 liste aussi une série d’éléments délibérément laissés sans catalogue ici : des plugins qui exécutent les actions intégrées de l’application, la bulle pet du SDK de plugins, des skills installés en cours de session qui atteignent le modèle sans reconstruction du prompt, Krea 2 Medium Turbo comme voie d’images pour les abonnés payants avec un fallback FAL, des mises à jour desktop plus rapides, des installations épinglées qui ne récupèrent que l’épinglage, des marques de compaction émises vers Relay, et de nouveaux plugins communautaires. Nous les couvrons un par un — l’article sur les actions de plugins est déjà en ligne : actions de plugins desktop et bulle pet.

Prouver quelle version vous avez

Trois commandes, choisissez celle qui correspond à votre installation :

# version (une installation git indique aussi la distance au-delà du tag et le commit court)
hermes version

# canal actuel et source de mise à jour (installations depuis les sources)
hermes update --help

# installations desktop / via l'installateur
hermes doctor

Si vous soupçonnez qu’une mise à jour a rapporté un succès sans rien changer, vérifiez si le tag a bougé dans hermes version, puis lisez hermes update --verbose. Pour le contexte sur les canaux, voir notre précédent guide du canal stable ; pour le pipeline de release qui a découpé ce tag, voir l’article sur la release v0.21.6.

Mise à niveau

# CLI
hermes update

# Desktop : se met à jour tout seul. Microsoft Store : mise à jour via le Store.

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

Une petite vérification après la mise à niveau, pour confirmer que le canal et la version sont bien ceux attendus :

hermes version
hermes config get agent.max_turns      # confirme aussi que la mise à jour a laissé votre config tranquille

En une phrase : v0.21.7 fait passer la mise à jour du statut de chose que l’on surveille sur main à celui de chose que l’on peut laisser tranquille — au prix de savoir sur quel canal on est. Réglez-le une fois et laissez le prochain tag faire le reste.