Hermes Agent : quand un seul profile ne suffit plus
Un seul profile suffit longtemps.
Puis un jour, il commence à tout mélanger.
Pas parce qu’Hermes casse. Parce que les usages divergent : un contexte projet, un contexte perso, un agent joignable ailleurs, quelques routines, un peu de mémoire, des réglages qui n’ont plus intérêt à rester ensemble.
Le symptôme n’est pas spectaculaire. C’est une soupe lente.
Même mémoire pour des usages différents, mêmes skills partout, même logique de config, même historique, alors que les rôles ont déjà bifurqué.
C’est là que les profiles deviennent utiles.
Pas pour faire plus propre en vitrine.
Pour séparer les contextes d’Hermes quand ils n’ont plus intérêt à vivre ensemble.
Ce que tu auras à la fin
Une vision claire de ce qu’un profile change vraiment, des cas où la séparation vaut le coup, des premières commandes qui comptent, et de la discipline que ça ajoute une fois qu’Hermes commence à vivre ailleurs que dans un seul terminal.
Ce que change vraiment un profile
Un profile Hermes, ce n’est pas juste un raccourci pratique.
C’est un environnement Hermes séparé.
Chaque profile a son propre config.yaml, son propre .env, son propre SOUL.md, ses propres mémoires, sessions, skills, cron jobs, gateway et état Hermes. Tu ne changes donc pas juste une préférence. Tu changes de contexte de travail.
Avec un seul profile, tout finit par pousser dans le même chez-lui. Tant que tu n’as qu’un seul usage clair, ce n’est pas un problème. Mais dès que tes usages divergent, le mélange commence à coûter.
Les profiles servent à éviter ça.
Ils te permettent par exemple d’avoir un Hermes projet qui garde sa mémoire et sa config, et un Hermes plus général qui ne ramasse pas ce bruit. Ou un Hermes dédié à une messagerie, sans obliger ton profile terminal principal à porter exactement la même logique.
Il y a aussi un point très concret : un profile devient sa propre commande. Si tu crées projet, tu peux ensuite lancer projet chat, projet doctor ou projet gateway start. Et si tu ne veux pas changer ton profile par défaut, tu peux viser un autre profile ponctuellement avec hermes -p <nom>.
En revanche, il ne faut pas lui faire dire plus qu’il ne dit. Un profile isole l’environnement Hermes. Ce n’est pas une VM, ni un conteneur, ni une frontière magique autour de tout ton système.
Pourquoi ce sujet arrive maintenant
Trop tôt, les profiles ne font que multiplier la config.
Le sujet devient utile quand la question n’est plus seulement “comment je lance Hermes ?” mais “quel contexte dois-je protéger de quel autre ?”.
À partir du moment où usages, rythmes, niveaux d’exposition ou mémoires divergent, un seul profile peut devenir le mauvais contenant.
Dans quels cas ça vaut vraiment le coup
Les profiles commencent à être rentables dans quatre cas très simples.
Quand tu as plusieurs usages réels. Par exemple un usage perso et un usage projet.
Quand tu as plusieurs niveaux de risque ou de surface d’action. Le Hermes que tu pilotes à la main n’a pas forcément besoin d’être le même que celui qui vit dans une messagerie.
Quand tu as plusieurs canaux ou plusieurs rythmes. Le Hermes que tu consultes en direct et celui qui exécute des tâches planifiées n’ont pas forcément intérêt à partager exactement le même contexte.
Quand tu as plusieurs logiques de mémoire et de comportement. Mais garde le point central : un profile ne sert pas à “ajouter de la mémoire”. Il sert à séparer des contextes. Si ton vrai sujet est la couche mémoire elle-même, va lire Hermes Agent : comprendre les 4 couches de mémoire persistante.
En revanche, un profile de plus ne vaut rien s’il ne sépare rien d’important.
Cas 1 — Séparer un Hermes perso et un Hermes projet
La situation de départ
Tu as commencé avec un seul Hermes, ce qui est normal.
Tu t’en sers pour des questions générales, un peu de terminal, puis de plus en plus pour un projet qui dure. Ce projet a ses propres habitudes, ses propres fichiers, parfois son propre ton, et surtout un contexte qui n’a pas forcément à se mélanger au reste.
Au début, ça passe.
Puis ton Hermes “général” devient aussi ton Hermes “projet”. La mémoire accumule des choses qui n’ont rien à voir, et le SOUL.md que tu veux pour le projet n’est pas forcément celui que tu veux partout.
Ce qu’on gagne
Là, un profile séparé a du sens.
Le démarrage le plus simple consiste souvent à cloner juste la base utile, puis repartir avec une mémoire fraîche :
hermes profile create projet --clone
Cette commande récupère la config, le .env et le SOUL.md du profile courant, sans recopier tout l’historique ni toute la mémoire. Tu repars donc d’une base cohérente, mais avec un vrai nouveau contexte.
Ensuite, tu peux l’utiliser directement :
projet chat
Et si tu veux en faire ton profile principal pendant un moment :
hermes profile use projet
Puis revenir plus tard au profile de base :
hermes profile use default
Le gain n’est pas cosmétique. Tu évites que ton agent projet ramasse tout le reste, et tu évites que ton Hermes général se remplisse d’un contexte projet qui n’a de sens qu’à un seul endroit.
Ce qu’il faut surveiller
Un profile projet a du sens pour un vrai projet durable, pas pour chaque petit dossier. Sinon tu te retrouves à multiplier les profiles au lieu de clarifier ton usage.
Pourquoi ça reste une brique avancée
Parce que le gain n’existe que si ton usage est déjà réel. Sans usage stabilisé, tu vas juste copier du flou dans un deuxième tiroir.
Cas 2 — Séparer un profile terminal principal et un profile gateway ou cron
La situation de départ
Ton Hermes principal te sert à la main. Tu l’ouvres dans le terminal, tu ajustes, tu testes, tu changes parfois d’idée en cours de route.
À côté, tu veux peut-être un Hermes joignable via gateway, ou un Hermes qui porte quelques tâches planifiées. Pas un deuxième cerveau universel. Juste un agent avec un rôle plus cadré : recevoir, répondre, livrer un résultat, exécuter une routine.
Avec un seul profile, tout cela vit alors dans le même contexte. Même logique de mémoire, même .env, mêmes skills, même gateway.
Ce qu’on gagne
Un profile dédié permet de séparer le Hermes que tu pilotes à la main du Hermes qui vit ailleurs ou agit dans le temps.
Par exemple :
hermes profile create gateway-bot --clone
Puis, sans toucher à ton profile par défaut, tu peux lancer son gateway ponctuellement :
hermes -p gateway-bot gateway start
Ou utiliser directement l’alias créé automatiquement avec le profile :
gateway-bot gateway start
Si tu veux vérifier ce que porte ce profile avant de le lancer, tu peux inspecter son état :
hermes profile show gateway-bot
C’est une séparation utile quand un Hermes reste très interactif et qu’un autre doit surtout répondre, livrer ou exécuter une routine.
Tu gardes un Hermes principal pour le terminal, avec ses essais et ses changements. Et à côté, un Hermes plus cadré pour la messagerie, les notifications ou les routines planifiées. Tu réduis ainsi les collisions de contexte et le mélange des rôles.
Ce qu’il faut surveiller
Le fait d’avoir un profile séparé ne transforme pas automatiquement un mauvais usage en bon usage. Si ton gateway est mal cadré, ou si tes tâches cron sont floues, le problème restera le même. Il sera juste mieux rangé.
Pourquoi ça reste une brique avancée
Parce qu’à ce stade, tu sépares des points d’entrée, des rythmes de travail et des usages qui n’ont plus intérêt à cohabiter.
Cas 3 — Pourquoi plusieurs profiles peuvent devenir une mauvaise idée si tu les crées trop tôt
La situation de départ
Tu découvres les profiles, tu trouves ça propre, et tu crées perso, code, veille, tests et mobile dans la foulée.
Dans la vraie vie, tu n’as pourtant qu’un seul usage stable. Tu ne sais plus lequel est ton défaut, lequel a la bonne config, lequel porte les bons tokens, ni lequel tu es en train de nourrir.
Ce qu’on perd
On perd du temps mental.
Tu disperses la mémoire au lieu de l’organiser. Tu crées plusieurs endroits à régler, à vérifier et à maintenir, sans vraie séparation utile derrière. Tu as l’impression d’avoir un setup plus propre, alors qu’en pratique tu as surtout fabriqué plus de frottement.
Pourquoi ça dérape vite
Un profile inutile est une dette douce. Il ne casse pas tout de suite. Il t’oblige juste à te rappeler davantage de choses pour un bénéfice faible ou nul.
Ce qu’il faut retenir
Tant qu’un seul usage clair suffit, un seul profile suffit.
Les premières commandes vraiment utiles
Tu n’as pas besoin de retenir toute la référence pour commencer. Les commandes qui comptent vraiment tiennent dans peu de place.
Créer un profile vierge :
hermes profile create labo
Créer un profile en récupérant la base du profile courant :
hermes profile create projet --clone
Créer un vrai fork complet d’un Hermes existant :
hermes profile create backup --clone-all
Créer depuis un profile précis plutôt que depuis le courant :
hermes profile create audit --clone --clone-from projet
Basculer le profile par défaut :
hermes profile use projet
Revenir au profile de base :
hermes profile use default
Cibler un autre profile pour une seule commande, sans changer le défaut :
hermes -p gateway-bot gateway start
Lister ce qui existe déjà :
hermes profile list
Inspecter proprement un profile :
hermes profile show projet
Renommer un profile :
hermes profile rename projet client-a
Exporter un profile :
hermes profile export projet
Importer un profile :
hermes profile import projet.tar.gz
Supprimer un profile :
hermes profile delete projet
Tu n’as pas besoin de tout utiliser tout de suite. Mais voir la carte complète aide à comprendre que les profiles ne sont pas juste un petit sélecteur. C’est une vraie couche de gestion de contextes.
Ce que les profiles ajoutent comme discipline
Les profiles rendent un setup plus lisible seulement si tu les traites avec un minimum de rigueur.
D’abord, chaque profile doit avoir un rôle clair. Pas un nom joli. Un rôle.
Ensuite, il faut savoir ce qui change vraiment d’un profile à l’autre : le modèle, le SOUL.md, les tokens, les cron jobs, le canal de gateway, ou la mémoire. Si la réponse est “rien de précis”, le profile est probablement superflu.
Il faut aussi savoir où tu es. Le profile activé par hermes profile use devient ton Hermes implicite. Si tu oublies souvent le profile courant, mieux vaut rester simple et utiliser -p ponctuellement plutôt que changer le défaut sans arrêt.
Enfin, il faut garder en tête qu’un profile séparé n’est pas une excuse pour relâcher le cadrage. Un mauvais cron dans un profile dédié reste un mauvais cron.
Ce qu’il vaut mieux avoir déjà stabilisé avant
Avant d’ouvrir plusieurs profiles, il faut surtout connaître la frontière que tu veux poser.
Pas “j’en crée un au cas où”. Une frontière concrète : rôle, mémoire, canal, fréquence, ou niveau d’exposition.
Il faut aussi un Hermes principal déjà stable. Sinon tu vas dupliquer du flou, pas isoler un usage.
Et si la séparation concerne la messagerie ou les routines, il faut savoir ce que tu cherches à isoler, pas juste recopier un contexte par réflexe.
Les erreurs fréquentes
La première erreur, c’est de séparer trop tôt.
La deuxième, c’est de croire qu’un profile sert d’abord à ranger joliment, alors qu’il sert surtout à isoler des contextes qui commencent à se gêner.
La troisième, c’est de basculer sans arrêt le profile par défaut et de ne plus savoir lequel tu utilises vraiment.
La quatrième, c’est de créer un profile dédié à gateway ou cron sans revoir ce qu’il porte réellement.
La cinquième, c’est de dupliquer trop large par réflexe. --clone ou --clone-all sont utiles, mais seulement si tu sais pourquoi tu copies.
Ce que tu ne dois pas faire
- Ne crée pas plusieurs profiles juste parce que la fonction existe.
- Ne découpe pas un usage encore flou.
- Ne confonds pas séparation Hermes et isolation totale de ton système.
- Ne mets pas gateway, cron, tests et usage principal dans le même sac quand les logiques ont déjà divergé.
- Ne transforme pas les profiles en collection décorative.
La suite logique
Le vrai intérêt des profiles n’est pas d’en avoir plusieurs.
C’est d’empêcher des contextes différents de se polluer.
Quand un seul contexte suffit, reste simple. Quand ça se mélange, sépare net.
Après ça, la suite n’est pas d’empiler des profiles. C’est de mieux tenir la mémoire, les permissions et les marches arrière de chacun.