Hermes Agent : quand faire confiance aux checkpoints et au rollback

Les checkpoints deviennent vraiment utiles le jour où Hermes commence à toucher à de vrais fichiers.

À partir de là, la bonne question n’est plus seulement “est-ce qu’il sait faire”. La vraie question, c’est : qu’est-ce que je récupère si le tour part mal ?

C’est exactement là que /rollback compte.

Pas comme une magie qui rend tout sûr.

Comme une marche arrière immédiate.

Ce que tu auras à la fin
Une vision claire de ce qu’est un checkpoint Hermes, de ce que /rollback permet vraiment, des cas où ça rassure utilement, et de la différence nette entre un checkpoint, un historique de session, Git et un vrai backup.

Ce que change vraiment un checkpoint Hermes

Un checkpoint Hermes ne remplace pas ton workflow de versioning. Il ne remplace pas non plus une architecture propre, une review humaine ou un minimum de discipline.

Ce qu’il change, c’est beaucoup plus concret.

Il change le niveau de confiance opérationnelle avec lequel tu laisses Hermes modifier des fichiers réels.

Sans checkpoint, chaque modification un peu lourde donne la même sensation : si le résultat est mauvais, il faut réparer à la main, fouiller le diff, ou espérer que Git te sauve alors que tu n’as peut-être même pas encore commité l’état précédent.

Avec les checkpoints, tu sais qu’avant certaines opérations destructives, Hermes a pris un instantané de l’état courant. Si le tour part mal, tu peux revenir en arrière proprement.

Dit autrement, les checkpoints ne servent pas à mieux versionner ton projet.

Ils servent à oser laisser Hermes travailler sans transformer chaque tour en inspection anxieuse.

Pourquoi ce sujet compte

Le sujet n’est pas la mise à jour au sens large, ni la prudence générale.

Le sujet, c’est plus précis : jusqu’où la promesse d’un checkpoint tient quand Hermes agit vraiment sur le disque.

Dès que cette question devient centrale, il faut sortir du flou. Un rollback utile n’est pas juste “un point de retour existe”. C’est un point de retour dont tu comprends le périmètre, les limites et les faux sentiments de sécurité.

Ce qui déclenche un checkpoint

La logique utile à retenir est simple : Hermes prend automatiquement un checkpoint avant certaines opérations qui s’apprêtent à modifier le working tree.

Ça couvre d’abord les outils de fichier comme write_file et patch.

Ça couvre aussi plusieurs commandes terminal destructives ou potentiellement destructives, par exemple rm, mv, sed -i, truncate, shred, les redirections de sortie avec >, ainsi que certains usages Git comme git reset, git clean ou git checkout.

Le point important n’est pas d’apprendre cette liste par cœur.

Le point important, c’est de comprendre l’intention : avant que quelque chose puisse casser ton état de travail, Hermes essaie de prendre un filet de sécurité.

Il faut aussi retenir deux détails très concrets.

D’abord, les checkpoints sont activés par défaut.

Ensuite, Hermes ne crée pas une pluie d’instantanés à chaque micro-action. Il fait au plus un checkpoint par dossier et par tour. Donc si un même tour touche plusieurs fichiers dans le même périmètre, tu peux te retrouver avec un checkpoint qui capture tout ce lot d’un coup.

C’est utile, parce que ça évite le spam.

Mais c’est aussi une limite à avoir en tête : on n’est pas sur un historique chirurgical de chaque frappe.

Ce que Hermes protège vraiment avant de toucher au disque

Le détail qui change beaucoup de choses, c’est que cette sécurité ne s’appuie pas sur ton vrai .git.

Hermes garde son propre mécanisme dans un shadow git repo séparé. En clair, il utilise une couche à part pour stocker ses checkpoints, au lieu de salir l’historique réel de ton projet.

C’est une bonne nouvelle pour deux raisons.

La première, c’est que ton dépôt Git reste ton dépôt Git. Tu gardes ton historique normal, tes branches, tes commits et tes PR sans pollution parasite.

La deuxième, c’est que le checkpoint Hermes reste un filet de sécurité local et immédiat, indépendant de ta logique de versioning long terme.

C’est exactement comme ça qu’il faut le voir : un airbag, pas la boîte noire complète.

Cas 1 — Hermes modifie un fichier et le résultat part de travers

Tu demandes à Hermes de réécrire une doc d’installation dans docs/install.md.

L’intention est bonne. Le résultat, non.

Le ton est trop sec, une partie utile a disparu, et deux sous-titres ont été fusionnés alors qu’ils devaient rester séparés.

Sans checkpoint, tu entres dans le mode réparation : diff, copier-coller, annulation manuelle, ou bricolage de mémoire.

Avec un checkpoint, tu peux revenir à l’état précédent immédiatement.

La commande utile, c’est simplement :

/rollback

Tu regardes la liste, tu identifies le checkpoint juste avant la modification, puis tu restaures par exemple avec :

/rollback 2

Ce que tu gagnes ici, c’est de la sérénité immédiate. Tu peux laisser Hermes tenter une vraie réécriture, pas juste micro-éditer sous surveillance permanente.

Ce qu’il faut surveiller, en revanche, c’est le périmètre du tour. Si le même tour a touché plusieurs fichiers dans le même dossier, un rollback complet peut revenir sur tout ce paquet.

Autre point utile : la restauration complète annule aussi le dernier tour de chat. Donc tu ne fais pas juste revenir les fichiers. Tu remontes aussi la conversation à ce point-là.

C’est précisément ce qui en fait une vraie marche arrière, et pas juste un petit “undo” cosmétique.

Cas 2 — Tu veux vérifier avant de restaurer

Deux fichiers ont bougé dans une passe de nettoyage. Rien n’a l’air catastrophique, mais quelque chose te gratte. Tu ne veux pas restaurer tout sans voir ce qui a changé.

C’est exactement le bon moment pour utiliser le rollback comme un outil de lecture.

La commande utile ici :

/rollback diff 3

L’idée n’est pas de restaurer tout de suite.

L’idée est d’abord de comparer l’état courant avec le checkpoint 3 pour voir si le problème est réel, où il se trouve, et si un retour complet se justifie.

C’est un très bon réflexe quand Hermes a fait un patch presque bon, mais avec un détail douteux. Par exemple :

• un bloc markdown déplacé un peu trop haut
• une suppression de commentaire qui n’était pas souhaitée
• une commande de nettoyage plus large que prévu

Ce que tu gagnes, c’est de la précision.

Tu ne passes pas de “j’ai un doute” à “je restaure tout” en aveugle.

Cas 3 — Tu ne veux restaurer qu’un seul fichier

Hermes a touché plusieurs choses dans un même mouvement. La plupart sont bonnes. Un seul fichier doit revenir.

Exemple crédible : tu lui as demandé de remettre de l’ordre dans une petite zone de docs. Il a bien amélioré docs/faq.md, mais il a aussi trop simplifié docs/install.md.

Tu ne veux surtout pas perdre le bon travail.

Tu veux juste récupérer ce fichier-là.

La commande utile ressemble à ça :

/rollback 4 docs/install.md

Là, tu utilises le checkpoint 4 comme source de restauration pour un seul chemin.

C’est précisément le genre de détail qui rend le mécanisme exploitable au quotidien. Sans ça, le rollback serait souvent trop brutal pour être utilisé sereinement.

Ce que tu gagnes, c’est une marche arrière précise.

Ce qu’il faut surveiller, c’est le bon numéro de checkpoint et le bon chemin de fichier. Si tu vas trop vite, tu peux restaurer le mauvais état ou le mauvais fichier.

Les premières commandes qui comptent vraiment

Tu n’as pas besoin d’un pavé de référence pour être utile tout de suite.

Les quatre commandes qui comptent au début sont celles-là :

/rollback
/rollback 3
/rollback diff 3
/rollback 3 docs/install.md

La logique derrière chacune est simple.

/rollback liste les checkpoints et donne une vue de départ.

/rollback 3 restaure l’état du checkpoint 3.

/rollback diff 3 te montre ce qui sépare l’état courant de ce checkpoint.

/rollback 3 docs/install.md ne restaure qu’un seul fichier depuis ce checkpoint.

Franchement, pour démarrer proprement, ça suffit largement.

Ce que rollback ajoute comme sécurité, et ce qu’il ne remplace pas

C’est le nœud du sujet.

Le rollback ajoute une sécurité immédiate sur l’état de travail quand Hermes s’apprête à modifier des fichiers ou à lancer des opérations destructives.

Mais il ne remplace pas le reste.

Il faut garder la différence nette :

• Checkpoint Hermes : filet de sécurité local, rapide, lié aux modifications de fichiers
• Historique de session : trace conversationnelle, pas système de versioning du projet
• Git classique : historique durable, branches, commits, review, partage
• Backup général : protection contre la perte de machine, la corruption disque, l’erreur large ou le besoin de restauration plus profond

C’est pour ça qu’un checkpoint peut rassurer à tort.

Tu vois une marche arrière. Tu oublies parfois de demander ce qu’elle couvre vraiment.

Hermes te protège dans l’instant.

Git te protège dans la durée.

Et un backup te protège quand le problème dépasse largement Hermes.

Ce qu’il vaut mieux avoir déjà stabilisé avant

Les checkpoints aident vraiment quand le reste du cadre est déjà à peu près propre.

Avant de trop compter dessus, il vaut mieux avoir stabilisé trois choses.

D’abord, ton répertoire de travail. Tu dois savoir d’où Hermes agit réellement. Sinon, même une bonne marche arrière devient floue.

Ensuite, ton usage Git de base. Pas besoin d’être obsessionnel. Mais il faut déjà comprendre ce que Git tient et ce qu’Hermes ne tient pas.

Enfin, ton périmètre de consigne. Un rollback sauve un état de fichiers. Il ne sauve pas une demande floue ou un “vas-y nettoie tout” lancé trop large.

Erreurs fréquentes

La première erreur, c’est de croire que checkpoint veut dire “je peux être moins précis dans mes consignes”.

Non.

Le rollback te donne une marche arrière. Il ne transforme pas une mauvaise demande en bonne demande.

La deuxième, c’est d’oublier que le mécanisme est par dossier et par tour, pas forcément par mini-action. Tu peux donc restaurer plus large que ce que tu avais en tête si tu ne regardes pas ce que couvre le checkpoint.

La troisième, c’est de confondre rollback et historique de chat. Reprendre une session, relire l’historique ou retrouver une consigne n’est pas la même chose que restaurer un état de travail.

La quatrième, c’est de croire que parce qu’Hermes garde ses checkpoints dans une couche séparée, tu n’as plus besoin de commits propres. C’est l’inverse.

Ce que tu ne dois pas faire

Ne traite pas les checkpoints comme une permission implicite pour lancer des opérations plus agressives “parce qu’au pire je rollback”.

Ne remplace pas tes commits par des checkpoints.

Ne crois pas qu’un shadow repo local vaut un vrai backup.

Ne confonds pas confort d’essai et sécurité absolue.

Et ne laisse pas le mot “rollback” te donner une illusion de contrôle total. Plus le périmètre est large, plus cette illusion coûte cher.

La suite logique

Tu comprends maintenant ce qu’un checkpoint promet vraiment, ce qu’un rollback peut réparer, et les cas où cette promesse tient mal.

Si ton sujet, c’est surtout l’ordre de changement, les tests juste après update, la trace minimale et le point de retour, va lire le tuto dédié : Hermes Agent : mettre à jour sans casser ce qui marche.

Si ton sujet devient où Hermes agit réellement quand il utilise le terminal, la suite logique est : Hermes Agent : où Hermes exécute vraiment avec Docker et SSH.