Vous faites tourner trois profils du même bot sur une seule machine : l’un surveille un canal de support, l’autre publie un résumé quotidien, le troisième patrouille en arrière-plan. Lundi, vous en ajoutez un quatrième et il n’apparaît tout simplement pas dans la liste des bots du bureau — à côté, l’état du gateway indique « arrêté », alors vous redémarrez tout le gateway et vous coupez au passage les deux instances qui travaillaient vraiment. Mais ce qui vous tracasse davantage, c’est l’autre question : ces profils, sur la même machine, voient-ils discrètement les identifiants, la mémoire et les sessions les uns des autres ?

v0.21.2 répond aux deux. Aucune fonctionnalité vedette n’est au programme : les deux objectifs sont on ne peut plus terre à terre — que chaque profil de la machine garde ce qui lui appartient, et que le bureau cesse d’ouvrir un backend par profil.

Un seul processus de gateway, trois jeux de bots

Commençons par le début : un profil est en pratique une installation Hermes autonome, avec sa propre configuration, ses propres identifiants, sa propre mémoire et son propre historique de sessions. Pour que plusieurs profils sur une même machine n’aient pas chacun besoin de leur gateway, Hermes embarque un multiplexeur : un unique processus de gateway qui héberge en même temps les bots de plusieurs profils. Partager ce processus, c’est précisément l’intérêt — et précisément le risque : tout ce qui est résolu « globalement » à l’intérieur peut fuir d’un profil vers un autre.

La forme habituelle de ces installations, c’est un profil principal plus quelques profils secondaires, qui partagent le processus et une partie de l’état d’exécution. Pour organiser votre machine ainsi, le guide des profils multi-instances détaille ce qui peut être partagé et ce qui doit rester séparé.

v0.21.2 (tag v2026.9.11, publiée le 11 septembre 2026, surnommée officiellement « The state.db Patch Release ») est la version corrective qui suit v0.21.1, et elle n’est pas petite : depuis v0.21.1, elle représente 947 commits hors fusion, 1 869 fichiers modifiés (+182 504 / -15 564) et 312 pull requests fusionnées, venant de 140 contributeurs. La liste complète, bloc par bloc, se trouve sur la page de version v0.21.2 ; voici les parties qui n’ont rien à voir avec state.db mais qui changent votre quotidien.

Sept fuites fermées d’un coup

Ce qu’il faut craindre dans une installation multi-profils, ce n’est pas un plantage mais une fuite silencieuse : un profil qui utilise les droits, les secrets ou les fichiers d’un autre, avec toutes les interfaces qui paraissent normales. Sept pull requests de cette version visent exactement cela :

PR	Ce qui franchissait la limite	Comportement désormais
#107616	Les bots d’un profil secondaire héritaient de l’allow-list du profil par défaut ; la liste des droits était résolue entre profils	chaque profil résout sa propre allow-list
#107617	Les adaptateurs pouvaient envoyer des identifiants vers l’hôte du profil par défaut	les identifiants voyagent avec le profil qui les possède
#107630	Les serveurs MCP en stdio recevaient les secrets du vault du profil par défaut	ils ne reçoivent que les secrets du profil courant
#107609	La livraison MEDIA: pouvait transporter le .env, l’auth.json ou le state.db d’un autre profil	la livraison reste cantonnée au profil qui la déclenche
#107620 / #107626	Les callbacks Feishu drive, et les réponses de webhook sur un chemin propre à un profil, pouvaient atterrir sur un autre profil	callbacks et réponses restent sur le profil routé
#107611	Un profil secondaire pouvait récupérer le token bearer Nous d’un profil frère dans la mémoire du processus	les tokens ne sont plus réutilisés entre profils

#107616 mérite une phrase à part. L’allow-list définit la frontière de droits d’un bot, et elle était auparavant résolue par rapport au profil par défaut : tout ce que vous aviez ouvert sur le profil principal était hérité par un profil secondaire. Pour deux bots aux tâches sans rapport, cela revenait à offrir les droits du profil principal à l’autre. Le contexte de ce point est dans l’article sur l’allow-list par profil.

Lu dans son ensemble, le tableau donne un test utile : tout ce qui est partagé « au niveau du processus » — mémoire interne, vault, hôtes d’adaptateurs, canaux de livraison — a toujours été la surface fragile du mode multi-profils. Cette série ne corrige pas cas par cas : elle rattache chaque point de résolution à la frontière du profil.

Le bureau n’ouvre plus un backend par profil

Le deuxième bloc concerne le démarrage du Bot Mode du bureau, et le symptôme était bien visible. Auparavant, au démarrage et à chaque tick du roster, le bureau créait ou composait un backend pour chaque profil ; survoler la liste des bots avec la souris créait un backend pour chaque ligne ; changer de profil pouvait créer des backends primaires en double. Autant de profils, autant de multiples de processus backend, et les surnuméraires se disputaient le même gateway.

Cette version touche à la fois le chemin de démarrage et le rendu de la liste : #108069, #108107, #108118, #108134, #107969, #108112. Concrètement, la scène du début ne se reproduit plus : ajouter un profil n’impose plus de redémarrer le gateway au milieu de la nuit, et la liste des bots ne se remplit plus d’entrées fantômes à l’état douteux.

Les corrections de comportements « qui n’ont aucun sens »

Au-delà de ces deux blocs, la version nettoie une série de petits comportements qui agaçaient en silence depuis longtemps. Aucun n’est spectaculaire isolément ; ensemble, ils forment un mur contre lequel on butte chaque jour.

Cron. Un « exécuter maintenant » hors des heures rondes n’annule plus la prochaine exécution planifiée (#106306) ; une exécution manuelle que vous avez tuée ne bloque plus le créneau de cinq minutes suivant (#106733) ; une tâche passée d’unique à récurrente continue de se déclencher (#106532) ; une tâche sans modèle épinglé s’exécute avec le modèle capturé à sa création (#106499) ; et hermes profile create --clone-all ne recopie plus les tâches cron (#106478). Ce dernier point compte surtout en multi-profils, car cloner un profil sert en général à réutiliser une configuration, pas à exécuter deux fois la même tâche planifiée sur le second profil.

Kanban. kanban promote refuse désormais une tâche parente non terminée (#106550), et kanban_request_review refuse un profil relecteur inconnu (#106547). Les deux transforment « accepter silencieusement une mauvaise entrée » en « refuser clairement ».

Outils et mémoire. Quand un serveur MCP en stdio meurt en pleine requête, l’appel d’outil n’est plus rejoué (#106546) — un rejeu signifie qu’une écriture peut-être déjà exécutée se produit une seconde fois, ce qui rend ce correctif particulièrement précieux. Une revue d’arrière-plan composée uniquement de skills ne peut plus supprimer d’entrées de mémoire (#106310) ; la mémoire mem0 ne perd plus les tours longs (#106542) ; tool_search préfère ne rien renvoyer plutôt que cinq outils sans rapport qui ne partagent qu’un mot (#106676) ; le sudo NOPASSWD distant ne déclenche plus de demande d’approbation (#107939) ; et la lecture RSS et Reddit n’est plus active par défaut (#105873).

Mises à jour et quota. La vérification des mises à jour interroge désormais l’API GitHub une fois par jour, au lieu d’un git fetch toutes les 30 minutes (#107648) ; hermes update indique la vraie raison d’un échec et ne reste plus bloqué sur un fetch figé (#108053).

Fournisseurs et routage. /model et le routage automatique auxiliaire ne facturent pas un fournisseur que vous n’avez pas choisi (#107366) ; Hermes ne bascule jamais tout seul vers un fournisseur pour lequel vous n’avez pas d’identifiants (#107281) ; les Bedrock Guardrails prennent effet (#107815).

Cache. Le passage entre le bureau et la TUI ne reconstruit plus le system prompt, et ne casse donc plus le cache de prompt (#105844) — une économie bien réelle pour qui jongle entre les deux interfaces toute la journée.

Ce que vous devez faire

La mise à jour tient en une commande :

hermes update

Quelques points méritent ensuite une vérification :

• Si vous avez configuré une allow-list de droits sur une machine multi-profils, chaque profil résout désormais la sienne (#107616) : vérifiez que les listes des profils secondaires sont bien celles que vous voulez.
• Si vous comptiez sur hermes profile create --clone-all pour emporter les tâches cron, il faut maintenant les recréer à la main (#106478).
• Si vous voulez continuer à utiliser RSS ou Reddit comme sources de contenu, activez-les explicitement : ils sont désactivés par défaut (#105873).
• Si une tâche planifiée n’a pas de modèle épinglé, elle s’exécute maintenant avec le modèle capturé au moment de sa création (#106499).
• La vérification des mises à jour passe une fois par jour (#107648) : n’y voyez pas un ralentissement, elle a simplement cessé de récupérer des données toutes les demi-heures.

Un dernier mot sur le chantier state.db, qui n’est pas le sujet ici : v0.21.0 a réécrit la gestion des connexions du stockage de sessions, ce qui a rendu state.db fragile dans certaines installations, et v0.21.2 ferme cette classe de problèmes. Nous l’avons traité séparément — les détails sont dans verrous et conflits d’écriture de state.db.

En résumé

v0.21.2 est un correctif de durcissement typique : aucune fonctionnalité à mettre en avant, et 947 commits hors fusion et 312 pull requests fusionnées consacrés surtout à reprendre les frontières. Avec un seul profil, le changement le plus visible est sans doute que le bureau ne traîne plus une pile de backends fantômes. Avec plusieurs profils sur une machine, la version compte beaucoup plus : de l’allow-list de droits aux secrets du vault et aux hôtes d’identifiants, jusqu’aux tokens en mémoire de processus, sept fuites entre profils se referment d’un coup.

Le multi-profil cesse d’être une configuration qui « marche, mais sans jamais vraiment rassurer » : chaque profil garde ce qui lui appartient, et le bureau n’ouvre que les backends dont il a besoin. C’est exactement ce que corrige cette version.