Hermes Agent : mettre à jour sans casser ce qui marche

Une mise à jour d’Hermes est terminée quand ton usage fonctionne encore, pas seulement quand l’installation affiche un message de réussite. Pour le vérifier, il faut avoir un point de comparaison : la même demande, le même fichier et le même modèle avant et après.

Nous allons préparer ce repère, sauvegarder les données, examiner la mise à jour proposée, puis rejouer un essai court. Le parcours concerne une installation source gérée sur Linux ou WSL, sans modifications personnelles du code d’Hermes. Il ne demande pas de changer de modèle, de serveur MCP ou de canal de mise à jour en même temps.

1. Identifier l’installation à mettre à jour

Il te faut un accès au terminal de la machine, une installation Hermes déjà utilisable, un accès au modèle habituel et assez d’espace libre pour une sauvegarde. Les petits blocs de préparation utilisent Bash et Python 3, sur Linux ou WSL. Si Hermes ne fonctionne déjà plus, commence par comprendre cette panne : tu n’aurais pas de référence fiable pour comparer.

Nous prendrons default comme profil d’essai. Remplace ce nom si ton usage habituel passe par un autre profil. Vérifie d’abord ce qui est installé :

command -v hermes
hermes --version
hermes update --help
hermes backup --help
python3 --version

Note la version affichée et, si disponible, la référence de code. L’aide de mise à jour doit proposer --plan et --check ; celle de sauvegarde, --output et --keep. Si ces options manquent, consulte la procédure correspondant à ta version avant de continuer.

La méthode dépend de l’installation :

Le plan permet de vérifier le type d’installation et les services concernés, sans appliquer la mise à jour :

hermes -p default update --plan

Repère le chemin de l’installation, les processus actifs et leur mode de redémarrage. Si le plan indique une installation empaquetée ou gérée par un autre système, suis la méthode annoncée. Ne force pas la commande du parcours source.

2. Préparer un cas de référence

Choisis une raison précise de mettre à jour : une correction attendue, une fonction utile ou une recommandation de maintenance. Note-la en une phrase. Nous vérifierons ensuite un usage très simple : lire un fichier local sans le modifier.

Pour cet essai, le profil doit utiliser le backend local et disposer d’un outil de lecture. Si tu dois d’abord clarifier où les outils travaillent, consulte le parcours local, Docker et SSH.

Crée un dossier neuf hors de l’installation et du dossier de données Hermes. Le bloc suivant le place dans ton dossier personnel avec un nom libre :

essai_update=$(mktemp -d "$HOME/essai-hermes-update.XXXXXX") &&
cd "$essai_update" &&
printf 'Projet : Silex\nRepère : cuivre-52\n' > repere.txt &&
pwd &&
cat repere.txt

Note le chemin affiché et garde ce terminal ouvert pendant le parcours. Lance une nouvelle conversation depuis ce dossier :

hermes -p default chat

Note le modèle et le fournisseur réellement utilisés. Donne ensuite cette consigne :

L’expression « service externe » vise ici les outils ; un modèle cloud reçoit toujours le contenu nécessaire à la réponse. Le fichier d’essai ne contient aucune donnée privée.

Vérifie l’appel de lecture et les deux lignes retournées. Conserve le résultat dans ta note. Si cet essai échoue déjà, règle le problème avant de l’utiliser comme référence. Termine le tour puis quitte la conversation avec /exit pour revenir au terminal.

Ce petit contrôle ne couvre pas tout ton usage. Si la mise à jour doit corriger un problème précis, ajoute un cas court qui le reproduit. Si tu utilises un outil important ou une messagerie, prévois aussi son contrôle après la mise à jour, dans un espace d’essai adapté.

3. Sauvegarder les données avant de changer le code

Attends la fin des tâches en cours et prévois une période sans nouveau travail. Un gateway peut encore être actif après la fermeture du chat. Vérifie les services repérés dans le plan ; les tâches planifiées et les autres interfaces ne doivent pas produire de nouveaux résultats pendant ta comparaison.

La sauvegarde complète d’Hermes couvre des données et réglages sélectionnés, avec des exclusions. Elle ne contient pas le code de l’application, ni tous les fichiers de travail présents ailleurs sur la machine. Garde donc la référence de version et sauvegarde séparément les projets ou services externes dont tu dépends.

Dans le même terminal, crée un dossier privé pour l’archive. Le nom choisi évite d’écraser une ancienne sauvegarde et --keep 0 désactive la suppression des anciennes archives par cette commande :

sauvegarde_update=$(mktemp -d "$HOME/sauvegarde-hermes.XXXXXX") &&
hermes -p default backup --keep 0 --output "$sauvegarde_update/donnees-avant-update.zip"

Attends la fin. Le compte rendu doit annoncer une sauvegarde complète, pas une archive partielle ni « aucun fichier à sauvegarder ». Relis le périmètre et les exclusions indiqués. Si plusieurs profils ou dossiers de données personnalisés sont concernés, vérifie leur présence au lieu de supposer qu’une commande couvre tout.

Contrôle ensuite que l’archive est lisible :

python3 -m zipfile -t "$sauvegarde_update/donnees-avant-update.zip"

Le contrôle ne doit signaler aucun fichier corrompu. Ouvre aussi la liste des fichiers dans ton gestionnaire d’archives et vérifie que les réglages, sessions et mémoires que tu veux conserver sont présents. Ce test de lecture ne vaut pas un essai complet de restauration.

Conserve le chemin dans ta note et une copie sur ton support de sauvegarde habituel. L’archive peut contenir des identifiants et des conversations : garde-la privée, sans l’envoyer dans un chat ni la déposer dans un dépôt Git public.

Les sauvegardes automatiques réalisées pendant une mise à jour constituent une protection supplémentaire, mais peuvent être partielles ou échouer sans bloquer la suite. Elles ne remplacent pas cette préparation. De même, le rollback de fichiers ne remet pas à lui seul toute l’installation Hermes dans son état précédent.

4. Examiner ce qui sera proposé

Avant de lancer l’installation :

hermes -p default update --check

Cette commande compare la version avec la cible du canal choisi, sans installer le nouveau code ni redémarrer les gateways. Elle peut récupérer des métadonnées Git : « vérifier » ne signifie donc pas « aucune écriture sur le disque ».

Note la cible annoncée et lis les notes de version correspondantes. Repère notamment les migrations de données, changements de configuration et incompatibilités avec tes plugins. Si tu es déjà à jour, il n’y a rien à appliquer : conserve ta référence et termine ici. Une erreur de vérification ne signifie pas que l’installation est à jour.

Dans le fonctionnement actuel, une installation source officielle suit normalement les versions stables, sauf choix antérieur ou situation particulière. Garde le canal observé pendant cet essai. Passer de main à stable peut revenir à un code plus ancien ; ce changement mérite sa propre préparation.

Le schéma relie la décision aux mêmes essais avant et après. Un message d’installation réussie ne suffit pas : il faut aussi retrouver le comportement attendu et comprendre les avertissements.

5. Appliquer une seule mise à jour

Tu peux poursuivre si la cible est comprise, la sauvegarde vérifiée et les activités en cours terminées. Ferme les autres conversations et interfaces qui utilisent cette installation. Si tu travailles par SSH, utilise ta session persistante habituelle et prévois de rester disponible pendant l’opération.

hermes -p default update

Lis les questions et les messages au fil de l’opération. Nous n’utilisons ni acceptation automatique ni option de forçage. La cible peut avoir évolué depuis la vérification ; si la commande annonce autre chose, réévalue ce changement avant de continuer.

Le programme peut préparer ses dépendances, proposer des réglages et redémarrer des services. Attends leur résultat. Si un changement local du code, un conflit ou une incompatibilité apparaît, arrête ce parcours générique pour traiter ce cas précis. N’ajoute pas en même temps une mise à jour Python, un nouveau modèle ou une réinstallation de MCP pour essayer de faire disparaître l’erreur.

6. Rejouer les contrôles avec la nouvelle version

Depuis le terminal, relève la version et l’état annoncé des services :

hermes --version
hermes -p default update --plan

Compare avec ta note initiale et le compte rendu de mise à jour. Un service peut encore fonctionner avec l’ancien code ou demander un redémarrage manuel. Un plugin peut aussi avoir été désactivé pendant la préparation des dépendances. Résous les avertissements concernant ton usage avant de le reprendre.

Retourne explicitement dans le dossier d’essai puis ouvre une nouvelle conversation :

cd "$essai_update" &&
cat repere.txt &&
hermes -p default chat

La variable essai_update existe dans le terminal conservé depuis l’étape 2. Si tu l’as fermé, utilise à la place le chemin exact que tu avais noté. Vérifie que le modèle et le fournisseur sont les mêmes, puis recopie la consigne de lecture de l’étape 2.

Une petite variation de formulation ne suffit pas à conclure à une régression. En revanche, un outil indisponible, une lecture inventée, une erreur nouvelle ou un service resté sur l’ancien code demandent une explication.

7. Consigner la décision avant de reprendre

Quelques lignes suffisent. Voici une trame à remplir avec tes résultats réels :

Si les essais retenus passent et que les avertissements sont compris, reprends ton usage. Si un point important reste douteux, conserve les messages d’erreur et suspends cette reprise. Cherche d’abord quelle étape a échoué : installation, démarrage, accès au modèle, outil ou service.

Si un retour arrière devient nécessaire

Revenir au code précédent et restaurer des données sont deux opérations différentes. Une nouvelle version peut avoir modifié le format des sessions ; l’ancienne ne sait pas forcément le relire. Certaines rétrogradations sont donc refusées. Ne contourne pas ce refus avec un changement de version forcé.

Avant toute restauration, vérifie la procédure correspondant aux deux versions et conserve séparément les données nouvelles que tu souhaites garder. Restaurer une sauvegarde antérieure ne récupère pas les messages ni les résultats créés depuis. Le guide officiel de mise à jour détaille les migrations concernées et les limites des retours arrière.

Pour les installations avec plusieurs profils, gateways ou interfaces, prépare aussi la reprise de chaque service. Le tuto gateway aide à distinguer un processus lancé au premier plan d’un service installé.

Les options du parcours ont été recoupées avec les commandes update et backup, ainsi que le mécanisme de sauvegarde. Leurs détails peuvent différer sur une ancienne installation : l’aide de ta version et ses notes de mise à jour restent les premiers repères.