Vous lancez hermes update, vous redémarrez l’agent et vous lui demandez ce qui s’est passé lors du refactoring de la veille. Il marque une pause, puis répond qu’il n’a aucune trace de quoi que ce soit. Vous ouvrez config.yaml : memory.provider: honcho est toujours bien là, et tout le bloc memory.honcho est intact. Seule chose manquante : le code — le provider a quitté le dépôt core, et votre mise à jour n’a remplacé que la moitié « core ».

Rien n’a été perdu. Vous avez sous les yeux le type de panne le plus vicieux qui soit : une config qui pointe vers une implémentation qui n’existe plus. La PR #114569, fusionnée dans main le 18 septembre 2026, est conçue exactement pour cet état : quand Hermes constate que le provider de mémoire configuré est absent, il le réinstalle depuis le catalogue de plugins, au pin revu par la revue. Voici comment il en décide, par quel chemin passe l’installation, ce qui se passe quand elle échoue, et si vous devez faire quoi que ce soit.

Ce qui ne change pas : nom, config, données

Le point rassurant de cette migration, c’est que seul le code déménage. Quand un plugins/memory/<name> embarqué devient un plugin autonome du catalogue :

• le nom du provider ne change pas (memory.provider: honcho continue de fonctionner) ;
• la section de config ne change pas (toutes les clés sous memory.<name> restent intactes) ;
• le répertoire de données ne change pas (tout ce dont votre agent se souvenait est là où il était) ;
• les noms d’outils ne changent pas (les instructions que l’agent garde en mémoire sur l’usage de la mémoire n’ont pas à être réapprises).

Le seul changement, c’est que le code réside désormais sous HERMES_HOME/plugins/<name>. En théorie, l’effet visible pour l’utilisateur aurait dû se limiter à une réinstallation silencieuse. Cette PR transforme cette théorie en réalité.

Deux hooks : hermes update et l’init de l’agent

Le nouveau module hermes_cli/memory_provider_migration.py expose un seul point d’entrée, migrate_home(). Il fait trois choses : lire memory.provider pour ce home, vérifier si le nom se résout encore là où Hermes regarde (le répertoire embarqué, les plugins utilisateur de ce home, un entry point), et — uniquement s’il ne se résout nulle part — chercher une entrée de catalogue portant le même nom. Les trois doivent concorder avant qu’une installation ne démarre.

Deux points d’appel différents couvrent deux habitudes de mise à jour différentes :

• hermes update l’exécute pour chaque home de profile partageant le virtualenv. C’est l’endroit naturel : la mise à jour reconstruit déjà les dépendances, et celles des plugins sont réappliquées sous les pins du core.
• L’init de l’agent l’exécute quand load_memory_provider renvoie None — c’est-à-dire quand le provider ne peut pas être chargé du tout — une fois par processus et par nom. Ce hook existe pour les utilisateurs du desktop, qui mettent à jour depuis l’application et ne lancent jamais hermes update à la main.

L’installation elle-même emprunte le chemin normal d’installation des plugins : le pin revu de l’entrée de catalogue, la kill list, les contraintes de dépendances et l’activation à l’installation. Rien n’obtient de raccourci sous prétexte que c’est automatique, et aucune source personnalisée n’est substituée.

Un interrupteur compte ici. Comme cette étape installe du code, elle respecte security.allow_lazy_installs (activé par défaut). Si vous l’avez désactivé pour des raisons de sécurité, la migration automatique n’aura pas lieu — et le log le dit, plutôt que de laisser la mémoire mourir en silence.

Quand l’installation échoue : une vraie commande, pas une amnésie silencieuse

La meilleure habitude d’ingénierie dans ce changement, c’est que l’échec est visible et immédiatement exploitable. Trois cas de figure, trois sorties :

Situation	Comportement
Le catalogue n’a aucune entrée pour ce provider	Un avertissement nommant précisément la commande hermes plugins install <source> à lancer, ou suggérant un autre memory.provider
Le catalogue l’a, mais l’installation échoue (réseau, uv, kill list)	Le texte d’erreur de l’installateur lui-même, plus la même ligne de commande
security.allow_lazy_installs est désactivé	Une ligne de log indiquant que la config a empêché l’installation automatique

Avant, le signalement se limitait à une ligne de niveau DEBUG, et rien d’autre : d’où un symptôme réduit, côté utilisateur, à « l’agent ne se souvient soudain plus de rien ». La fonction contient aussi une règle délibérément sobre : elle ne lève jamais d’exception. Le commentaire le dit sans détour : une mémoire hors service ne doit pas emporter la mise à jour ni l’agent avec elle.

Un petit correctif de syntaxe d’installation dont dépend la migration

La même PR fait correctement analyser hermes plugins install owner/repo#subdir. Auparavant, le # était collé à l’URL de clone, si bien qu’aucun plugin livré dans un sous-répertoire de son dépôt principal ne pouvait être installé de cette façon.

Cette syntaxe n’a rien de théorique. Honcho livre son plugin à l’intérieur de son dépôt principal : sa source après migration est donc plastic-labs/honcho#hermes-plugin-honcho ; celle de supermemory est supermemoryai/hermes-supermemory. La PR a validé tout le cheminement sur une installation réelle : dans un checkout de test où les honcho et supermemory embarqués avaient été supprimés, avec memory.provider: honcho défini et un vrai AIAgent(), l’init de l’agent a installé plugins/honcho depuis le dépôt du mainteneur, résolu ses dépendances (honcho-ai, httpx) dans les pins du core, puis l’a chargé. Le panneau de configuration desktop de honcho affichait toujours ses 33 champs, la CLI hermes honcho était toujours découverte, et un second démarrage ne faisait rien du tout.

Ce qu’il faut faire maintenant : cinq minutes de vérification

Cette PR pose les fondations — elle ne retire rien du core à elle seule. Mais la direction est publique : les providers de mémoire intégrés s’en vont vers les dépôts de leurs mainteneurs et vers le catalogue (la PR mentionne la discussion avec les mainteneurs de Hindsight, Honcho et Supermemory). Autant donc savoir où vous en êtes :

1. Regardez quel provider vous utilisez : hermes config get memory.provider. S’il s’agit de l’un des providers embarqués (honcho, supermemory, mem0 et compagnie), notez le nom.
2. Vérifiez s’il est actuellement embarqué ou installé comme plugin autonome : hermes plugins list. Après une future mise à jour, le voir installé depuis le dépôt du mainteneur sera la norme, pas un problème.
3. Si une mise à jour laisse un jour l’agent amnésique, commencez par lancer la ligne hermes plugins install indiquée dans le log. Une fois la mémoire rétablie, vérifiez avec hermes doctor la santé de la base d’état et du WAL — le diagnostic de WAL volumineux que nous détaillons dans le guide du live-writer est le point de départ à privilégier.

Si vous préférez commencer par la vue d’ensemble, le guide du catalogue de plugins et la référence hermes plugins expliquent comment les entrées de catalogue sont revues et installées. Et si vous utilisez Honcho pour le routage des sessions et des workspaces, les réglages de ce guide de routage continuent de fonctionner sans modification après la migration.

État des versions publiées

Ces commits ont été fusionnés dans main le 18 septembre 2026, et le tag le plus récent est v0.21.3 (nom de tag v2026.9.14, publié le 14 septembre) : les hooks de migration ne sont donc pas encore dans une version taguée. Les installations via git qui lancent hermes update les ont déjà ; les utilisateurs de l’image Docker et du cloud les auront avec le prochain tag. Vérifiez où vous en êtes :

hermes --version
hermes update

Pour situer le contexte, la page de release v0.21.3 précise que les notes complètes et vérifiées de tout ce qui suit v0.21.0 arriveront avec v0.22.0 — attendez-vous à ce que le déménagement des providers de mémoire soit l’une des sections à lire à ce moment-là.

La leçon

La partie intéressante n’est pas l’installation automatique. C’est la classe de panne qu’elle met au jour : quand une config référence une implémentation qui est partie ailleurs, l’utilisateur ne voit pas d’erreur — il voit une capacité disparaître sans bruit. Trois habitudes valent d’être reprises du correctif : considérer « l’implémentation est absente » comme un état à part entière, qu’il faut détecter ; faire passer la réparation automatique par le chemin déjà revu, plutôt que par un raccourci ; et quand la réparation est impossible, afficher une commande que quelqu’un peut réellement lancer — depuis du code qui ne fera jamais tomber la mise à jour ni l’agent.