Vous gérez deux profiles : un assistant personnel et un bot d’équipe, chacun avec son propre bot Telegram ou Feishu. À 3h du matin, la tâche planifiée du bot d’équipe se termine — et le résultat est livré depuis votre bot personnel. Pire encore : la livraison échoue parfois avec Bot not in chat — la tâche a réussi, mais personne n’a jamais vu le résultat. Un correctif fusionné le 31 août (PR #99375) déracine toute cette classe de croisements par la racine : c’est le profile propriétaire de la tâche — et non le processus qui l’a exécutée — qui décide quel bot livre le message cron.

La cause racine : l’identité de livraison suivait la mauvaise « personne »

Dans la conception multi-profile de Hermes, chaque profile possède sa propre configuration, ses propres identifiants, sa propre base de sessions et ses propres bots de messagerie. Mais avant ce correctif, la livraison cron avait un défaut fatal : l’identité de livraison suivait le processus qui exécutait la tâche au lieu du profile propriétaire.

Concrètement : vous démarrez le gateway depuis votre profile principal, et il héberge au passage les tâches du profile B. Quand la tâche de B s’exécute, le système lit les identifiants du « processus courant » — ceux du profile principal — et le résultat de B part donc via le bot du profile principal. Livraison vers le groupe de B ? Le bot n’est pas dans ce groupe, donc erreur. Livraison vers le chat du profile principal ? Le message atterrit au mauvais endroit. La tâche a réussi, mais le résultat s’est volatilisé.

Et ce n’était que la moitié du problème. cron status mentait de la même façon : il considérait le gateway de n’importe quel profile actif comme une preuve de bonne santé — même lorsque le planificateur du profile B ne tournait pas du tout. Le statut semblait vert alors que les tâches de B ne se déclencheraient jamais.

Le correctif : quatre causes racines, un seul principe

La PR #99375 rassemble les commits de neuf contributeurs et répare chaque maillon de cette chaîne, autour d’un seul principe : l’identité de livraison doit venir du profile propriétaire de la tâche. Concrètement :

• Le tick de chaque profile reçoit sa propre carte d’adaptateurs : lors du multiplexage (_start_multiplex), le tick de chaque profile reçoit sa propre carte d’adaptateurs de plateforme ; les adaptateurs partagés sont réservés au profile par défaut et ne servent jamais de repli pour les profiles secondaires non connectés ;
• Le périmètre des secrets du profile couvre désormais la livraison : auparavant, le périmètre était réinitialisé juste après l’exécution de la tâche, si bien que les replis standalone-send résolvaient les tokens de plateforme du processus en cours ; désormais, le périmètre couvre _deliver_result de bout en bout ;
• Les IDs des chats de référence sont résolus depuis les secrets du profile propriétaire : l’ID du chat cible et l’ID du fil sont résolus via get_secret sous le périmètre du profile propriétaire, au lieu de variables d’environnement brutes ;
• Les tâches du profile écrivent leurs sessions dans leur propre state.db : la SessionDB est construite via contextvars.copy_context(), si bien que les exécutions cron de B cessent de persister leurs sessions dans la base du profile par défaut ;
• Sauvetage de pré-vol des profiles satellites : les satellites routés via gateway.profile_routes lisent directement la configuration principale, échouent en mode fail-closed et ne fuient aucune variable d’environnement ;
• cron status dit la vérité : la découverte du PID systemd est limitée au nom de service de ce profile, et un heartbeat jamais reçu est signalé comme un avertissement, pas comme un feu vert.

Comment vérifier sur votre machine

Après la mise à jour vers le dernier main, vérifiez d’abord que le statut du planificateur de votre profile est désormais digne de confiance :

# Statut du planificateur propre à un profile — pas un feu vert « un gateway est vivant »
hermes -p work cron status

Puis exécutez une tâche cron avec livraison et observez si le message vient bien du bot de ce profile et atterrit dans son chat de référence. Pour quiconque fait tourner plusieurs profiles sur plusieurs plateformes, c’est une amélioration d’expérience immédiatement visible : les résultats ne disparaissent plus, les croisements sont éliminés et les messages fantômes « la tâche a réussi mais personne ne l’a reçue » s’arrêtent.

Quand pouvez-vous l’utiliser

La PR #99375 a été fusionnée le 31 août 2026 et n’est que sur main — pas encore dans une release. Elle corrige un ensemble de signalements réels d’utilisateurs : #94862, #97909, #99028, #98790, #97476 — tous des plaintes du type « le message n’est jamais arrivé » ou « le statut ment ».

Les profiles multiples sont l’une des capacités les plus sous-estimées de Hermes : chaque profile possède sa propre identité, sa propre mémoire et ses propres bots. Pour bien les utiliser, commencez par notre guide complet multi-profile et le routage multi-profile Feishu ; le playbook cron complet se trouve dans le guide complet d’automatisation cron.