Reprendre une session Hermes : retrouver un contexte sans laisser une conversation dériver
Tu travailles sur un projet depuis 45 minutes avec Hermes. Tu as posé six questions, l’agent a fait des recherches, modifié des fichiers, exécuté des commandes. Et puis tu dois fermer le terminal. Réunion, pause, fin de journée. Quand tu reviens, tu pourrais tout recommencer depuis le début. Ou tu pourrais reprendre exactement là où tu en étais.
La reprise de session, c’est le mécanisme qui te permet de ne pas perdre le fil. Pas juste un historique de chat. Tout le contexte : les messages, les appels d’outils, les réponses, les fichiers touchés. Comme si tu n’étais jamais parti.
Pourquoi reprendre une session plutôt que recommencer
Recommencer une session, c’est repartir de zéro. Tu perds le contexte accumulé. L’agent ne sait plus ce que tu as déjà exploré, ce qui a marché, ce qui a échoué. Tu dois tout réexpliquer.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Reprendre une session, c’est différent. Tu retrouves l’état exact de la conversation. L’agent se souvient de tout. Tu peux enchaîner directement sur la prochaine étape sans refaire le chemin.
Le cas le plus évident : un debugging qui s’étale sur plusieurs jours. Tu identifies un bug le lundi, tu explores des pistes, tu trouves une cause probable. Le mardi, tu reprends la session et tu continues l’investigation sans avoir à résumer le lundi.
Autre cas : un projet long avec des allers-retours. Tu construis un script, tu le testes, tu corriges, tu ajoutes une fonctionnalité. Chaque session reprend la précédente. Le contexte s’accumule au lieu de se perdre.
Les trois façons de reprendre une session CLI
Hermes propose trois mécanismes de reprise. Chacun correspond à un besoin différent.
| Commande | Ce qu’elle fait | Quand l’utiliser |
|---|---|---|
hermes --continue ou hermes -c |
Reprend la session CLI la plus récente | Retour rapide après une pause courte |
hermes --resume <session_id> ou hermes -r <session_id> |
Reprend une session spécifique par son ID | Quand tu connais l’ID exact de la session |
hermes -c "mon projet" ou hermes --resume "refactoring auth" |
Reprend par nom de session ou par titre | Quand tu as nommé tes sessions et que tu veux retrouver un projet précis |
hermes --continue est le plus rapide. Tu fermes le terminal, tu le rouvres, tu tapes hermes -c, et tu es de retour dans la dernière conversation. Pas besoin de te souvenir d’un ID.
hermes --resume <session_id> est plus précis. Chaque session a un ID unique, affiché quand tu quittes. Tu peux aussi le retrouver avec hermes sessions list. Utile quand tu alternes entre plusieurs projets et que la session la plus récente n’est pas celle que tu veux reprendre.
La reprise par titre est la plus pratique sur la durée. Si tu as nommé ta session avec /title Refactoring Auth, tu peux la retrouver avec hermes --resume "refactoring auth". Même chose avec hermes -c "mon projet" qui reprend la session la plus récente dans la lignée de ce nom.
Ce que la reprise restaure (et ce qu’elle ne restaure pas)
Quand tu reprends une session, voici ce que tu retrouves :
- L’historique complet des messages, questions et réponses.
- Tous les appels d’outils que l’agent a faits : recherches web, lectures de fichiers, exécutions de commandes.
- Les fichiers modifiés pendant la session précédente (ils sont toujours sur ton disque).
- Le contexte de la conversation, comme si tu n’avais jamais quitté.
Un panneau « Previous Conversation » s’affiche entre le bandeau d’accueil et la zone de saisie. Il te donne un récapitulatif compact de ce qui s’est passé avant. Tu vois d’un coup d’oeil où tu en étais sans avoir à relire tout l’historique.
Ce que la reprise ne fait pas :
- Elle ne recrée pas l’état du système si des fichiers ont été modifiés entre-temps par autre chose.
- Elle ne restaure pas les processus en cours d’exécution (un serveur lancé dans la session précédente, par exemple).
- Elle ne remplace pas une documentation. Le contexte de la conversation est restauré, mais les décisions importantes que tu as prises pendant la session ne sont pas structurées pour être retrouvées dans trois mois.
Reprendre une session, c’est retrouver le fil d’une conversation. Documenter un projet, c’est extraire les décisions structurantes pour qu’elles survivent au contexte de la conversation. La reprise est un outil de continuité court terme. La documentation est un outil de mémoire long terme. Les deux sont utiles, mais ils ne servent pas le même objectif.
Nommer ses sessions pour s’y retrouver
Sans nom, une session est juste un ID technique. 20260715_093022_a1b2c3. Tu ne sais plus ce qu’elle contenait sans l’ouvrir.
Nommer une session prend trois secondes. Tu tapes /title Mon Projet dans la conversation, et c’est fait. Tu peux aussi renommer plus tard avec hermes sessions rename <id> <titre>.
Avec des noms, hermes sessions list devient lisible. Tu vois « Refactoring Auth », « Debug CI Pipeline », « Rédaction article reprise session ». Tu sais exactement laquelle reprendre.
Et la reprise par titre fonctionne : hermes --resume "debug ci pipeline" retrouve la bonne session même si tu ne te souviens pas de l’ID.
Ce qui se passe quand la conversation devient trop longue
Les conversations longues posent un problème technique : la fenêtre de contexte a une limite. Si ta session fait 200 tours, tu ne peux pas tout faire tenir dans le contexte du modèle.
Hermes gère ça automatiquement avec la compression de contexte. Quand la conversation approche la limite, les tours du milieu sont résumés. Les 3 premiers tours et les 20 derniers sont toujours préservés intacts. Le reste est compressé en résumés.
Tu vois un indicateur dans la barre de statut : un compteur de compressions et une jauge de contexte avec un code couleur. Vert en dessous de 50%, jaune entre 50 et 80%, orange entre 80 et 95%, rouge au-delà.
La compression est configurable dans config.yaml. Tu peux ajuster le seuil de déclenchement et choisir un modèle dédié pour la summarization si tu veux économiser sur le modèle principal.
Ce qui est important : la reprise fonctionne même après compression. Tu retrouves une version résumée mais fonctionnelle de l’historique. Les 20 derniers tours sont intacts, donc le contexte immédiat est toujours là.
Reprendre ne remplace pas documenter
Reprendre une session, c’est pratique. Mais ça a une limite : le contexte reste dans la conversation. Si tu changes de machine, si la base SQLite est corrompue, si tu archives de vieilles sessions, tu perds l’historique.
Et surtout, une conversation n’est pas une documentation. Les décisions importantes que tu prends pendant une session (choix d’architecture, arbitrage technique, raison d’un refactoring) méritent d’être écrites quelque part où tu pourras les retrouver dans six mois sans avoir à relire 80 tours de conversation.
La reprise de session est un outil de continuité. La documentation est un outil de mémoire. Les deux sont complémentaires.
Si tu veux comprendre comment structurer tes décisions pour qu’elles survivent au contexte d’une conversation, tu peux regarder la différence entre un second cerveau et une mémoire d’IA. C’est le sujet de l’article sur la mémoire persistante, et ça complète directement ce que tu viens de lire.
Tu peux faire une demande d’accès à la formation Second Cerveau sur kavyro.com pour apprendre à documenter tes décisions structurantes hors de tes conversations agent.
