Hermes répond à côté, oublie une contrainte ou échoue sur un outil qui fonctionnait jusque-là. Avant de changer le modèle ou de retoucher la configuration, il faut rendre le problème assez précis pour pouvoir le comparer.
Nous allons noter le symptôme, vérifier la session active et rejouer une demande courte. L’objectif est de trouver une piste utile, puis de la confirmer sans empiler les changements.
1. Décrire ce qui ne fonctionne plus
Ce parcours suppose une installation Hermes déjà utilisée et un accès à sa conversation dans le terminal. Il te faut la demande qui pose problème, sa réponse ou son message d’erreur, et quelques lignes pour prendre des notes. Attends la fin des actions en cours avant de comparer les sessions ; ne rejoue pas une opération qui envoie un message, supprime des fichiers ou déclenche un achat.
Si Hermes ne démarre plus ou n’arrive pas à joindre le modèle, reste sur cette erreur technique. L’exercice de conversation des étapes suivantes ne peut pas encore servir de comparaison.
| Ce que tu observes | Ce qu’il faut relever |
|---|---|
| Le modèle ne répond pas | Message exact, moment de l’échec, provider utilisé. |
| Un outil échoue | Nom de l’outil, action demandée, erreur retournée. |
| La réponse est inadéquate | Consigne précise non respectée et résultat attendu. |
| Un détail a disparu | Information manquante et endroit où elle avait été fournie. |
Écris un symptôme observable. « Hermes est moins bon » est difficile à tester ; « il donne une autre date que celle présente dans le texte » fournit déjà un critère de contrôle.
Garde une copie locale de la demande et du résultat avant toute modification. Pour une erreur d’outil, conserve aussi le message complet : une réponse finale rassurante ne remplace pas la vérification de l’action.
2. Vérifier le contexte réellement actif
Dans un autre terminal, relève la version installée :
hermes --version
Dans la conversation concernée, affiche ensuite son état. Les commandes qui commencent par / se saisissent dans Hermes, pas dans Bash :
/status
Note le modèle, le provider, le profil, l’identifiant de session et le dossier de travail affichés. Vérifie notamment que tu utilises le modèle attendu : un changement effectué dans une autre interface ou une autre session ne décrit pas forcément celle-ci.
Puis regarde la place occupée par le contexte :
/context
Cette vue aide à repérer le poids de l’historique, des instructions, des mémoires et des outils. Elle ne mesure pas la qualité du raisonnement. Un contexte chargé est une piste ; il ne suffit pas à expliquer une mauvaise réponse.
Si une commande manque dans ta version, consulte /help et la documentation correspondante. Ne mets pas Hermes à jour au milieu de cette comparaison uniquement pour obtenir le même affichage.
3. Construire une demande facile à vérifier
Voici un petit cas de référence. Il permet de comparer une extraction d’informations et le respect d’un format. Il ne teste ni les fichiers, ni MCP, ni le fonctionnement de tous les outils.
Dans la session concernée, envoie cette consigne telle quelle :
À partir du texte ci-dessous uniquement, donne trois lignes au format :
Projet : …
Date : …
Statut : …
N’ajoute ni introduction ni commentaire. Cette tâche ne nécessite aucun outil.
Texte : Le projet Silex doit être relu le 18 novembre. Son statut est « en attente de relecture ».
Date : 18 novembre
Statut : en attente de relecture
Compare les trois informations et la présence éventuelle de texte ajouté. Note l’écart exact, sans demander immédiatement à Hermes de se corriger : cette relance changerait déjà le contexte de l’essai.
La phrase « aucun outil » exprime une consigne ; elle ne désactive pas techniquement les capacités de la session. Vérifie les appels affichés si leur utilisation fait partie du problème.
Si ce petit essai réussit, cela ne signifie pas que le problème initial a disparu. Réduis alors ta demande d’origine jusqu’à obtenir un exemple court qui conserve le symptôme : un paragraphe mal résumé, une contrainte oubliée ou une lecture de fichier qui échoue. Conserve les données nécessaires et un résultat attendu clair.
4. Comparer avec une nouvelle session
Pour notre premier essai, le changement choisi est le passage à une nouvelle conversation. Note d’abord l’identifiant de l’ancienne session et garde ses résultats. Puis, dans Hermes :
/new
Lis la confirmation éventuelle avant de poursuivre. Réaffiche /status : l’identifiant de session doit avoir changé. Vérifie que le modèle, le provider, le profil et le dossier correspondent toujours à ton point de départ. Si une valeur diffère, note-la : la comparaison ne porte plus seulement sur l’historique.
Rejoue exactement la consigne de l’étape 3, ou le cas réduit que tu as construit. Compare avec le résultat précédent, sur les mêmes critères.
La règle pour la suite reste la même : nommer le changement et comparer, avant d’en ajouter un autre.
Un changement, puis une comparaison
Une amélioration est un indice, pas encore une cause prouvée.
Si le symptôme disparaît, refais un essai dans des conditions comparables et note si l’amélioration se maintient. Les réponses d’un modèle peuvent varier : quelques réussites donnent de la confiance pour cette tâche, pas une garantie générale.
Si le symptôme persiste, ne conclus pas automatiquement que la consigne ou le modèle est responsable. Le petit essai a seulement montré que changer de session n’a pas suffi dans les conditions observées.
5. Choisir la prochaine vérification
Choisis une piste à partir du symptôme et de ce qui a changé récemment. Repars d’un état connu avant chaque nouvelle modification réversible. Ne désactive pas au hasard plusieurs outils ou toutes les mémoires.
| Piste | Vérification utile |
|---|---|
| Modèle inattendu | Compare le modèle actif dans /status avec ta référence. |
| Détail perdu | Vérifie s’il figure encore dans le contexte utile ou s’il a été résumé. |
| Outil absent | Consulte /tools avant de changer ses réglages. |
| Outil en erreur | Vérifie sa cible, ses accès et son message d’échec. |
| Skill inadaptée | Identifie celle qui a réellement été chargée et la consigne qu’elle ajoute. |
| Serveur MCP | Distingue connexion au serveur, outil disponible et résultat de l’appel. |
Une skill installée n’est pas nécessairement chargée dans la conversation. De même, une liste d’outils disponibles ne prouve pas qu’un appel réussira. Ces distinctions évitent de corriger la mauvaise couche.
Pour approfondir une piste, reprends le parcours correspondant : vérifier les outils utiles, tester un serveur MCP ou distinguer mémoire et historique.
Si tu testes un réglage, note sa valeur initiale avant de le modifier. En l’absence d’amélioration, remets ce réglage à sa valeur de départ avant d’en essayer un autre. Ce retour concerne le réglage identifié : il ne demande pas de restaurer toute l’installation ni d’effacer les sessions.
6. Consigner le résultat avant de reprendre
Quelques lignes suffisent pour ne pas refaire les mêmes essais demain. Voici une note illustrative, à adapter à tes observations :
Référence : consigne Silex, trois informations à extraire.
Changement : nouvelle session, même modèle et même profil vérifiés.
Observation : les trois informations sont correctes dans ce nouvel essai.
Conclusion : piste liée au contexte de session, cause non confirmée.
Suite : vérifier une tâche représentative avant de reprendre le travail.
Si une correction tient, reprends progressivement ton usage réel et vérifie son résultat. Si le problème reste ouvert, conserve la version, l’environnement, la demande minimale, l’erreur exacte et les essais déjà effectués. Ce dossier sera bien plus utile qu’une succession de changements non notés.
Avant de transmettre un extrait de configuration ou de journal, relis-le et retire les secrets ainsi que les données privées. Aucun envoi de diagnostic n’est nécessaire pour suivre ce tutoriel.
Garder un point de comparaison pour la prochaine fois
Conserve une petite demande représentative qui fonctionne et la note du contexte utilisé. Elle pourra aussi servir après un changement de modèle ou une mise à jour d’Hermes.
Pour éviter que les couches s’accumulent sans raison, poursuis avec un setup propre, léger et maintenable et la routine d’utilisation quotidienne.
Les commandes et distinctions de ce parcours s’appuient sur la référence officielle des commandes de conversation, le guide de diagnostic de qualité et la FAQ Hermes. Les affichages peuvent varier selon la version installée.