Hermes Agent : garder un setup propre, léger et maintenable

Un setup Hermes devient rarement mauvais d’un coup. Il s’alourdit couche après couche, jusqu’au moment où tu n’es plus sûr de ce qui sert encore vraiment.

Ce tuto parle de ça. Pas de performance, pas de debug pur, mais de ménage utile : décider ce qu’il faut garder, couper ou retirer pour que le setup reste lisible et supportable dans le temps.

Ce que tu auras à la fin
Des critères concrets pour décider ce qui reste et ce qui part, une logique simple pour désactiver un tool, retirer une skill ou couper un serveur MCP, et une routine légère de maintenance.

Pour qui est ce tuto
Ton setup fonctionne encore, mais tu veux éviter qu’il devienne opaque, lourd, et pénible à faire évoluer.

Comment un setup Hermes se dégrade sans bruit

La dégradation d’un setup Hermes est rarement brutale. Ce n’est pas une panne, ce n’est pas un bug, c’est une lente accumulation. Tu ne te lèves pas un matin en constatant que ton agent est devenu illisible : tu te lèves un matin en réalisant que tu hésites à y toucher.

Ce qui arrive concrètement, c’est que chaque petite décision, prise isolément, paraît parfaitement raisonnable. Tu ajoutes un tool parce qu’il a été utile sur une tâche précise. Tu écris une skill pour une demande récurrente. Tu branches un serveur MCP pour tester une intégration. Tu ajustes un bout de config pour corriger un comportement bizarre. Rien de tout ça n’est une erreur au moment où tu le fais.

Le problème, c’est que personne ne retire jamais rien. Le tool reste actif longtemps après la disparition de son cas d’usage. La skill continue à s’appliquer sur des patterns qui n’ont plus grand-chose à voir avec ton usage réel. Le serveur MCP tourne encore alors que tu ne l’as pas sollicité consciemment depuis des semaines. Le bout de config griffonné il y a trois mois pour corriger un problème ponctuel est toujours là, et tu n’oses plus y toucher parce que tu ne te souviens plus exactement pourquoi il avait été ajouté.

C’est ça, l’accumulation invisible. Chaque couche, prise seule, est défendable. Empilées sans relecture, elles finissent par former un setup que plus personne ne comprend, et dont plus personne ne sait ce qui pilote vraiment le comportement.

À quoi ressemble un setup encore sain

Un setup sain n’est pas un setup vide, et ce n’est pas non plus un setup petit par principe. C’est un setup dont tu peux expliquer chaque couche simplement.

Tu peux dire, pour chaque tool actif, pourquoi il est là et quel genre de demande le justifie. Tu peux dire, pour chaque skill, ce qu’elle fait et dans quel cas elle sort. Tu peux dire, pour chaque serveur MCP branché, ce qu’il apporte que tu n’aurais pas autrement. Tu peux regarder ta config et comprendre, en la lisant, ce qui va se passer au prochain lancement.

Un setup sain, ce n’est pas forcément un setup avec peu de couches. C’est un setup où chaque couche a une raison d’être maintenant, pas il y a six mois. Un setup avec dix tools bien cadrés, tous utilisés, tous défendables, est plus sain qu’un setup avec trois tools dont deux sont des vestiges.

Le bon test est très simple : si quelqu’un ouvrait ton setup aujourd’hui, arriverais-tu à lui expliquer en quelques phrases ce qu’il voit ? Pas à justifier chaque ligne comme un avocat, juste à lui dire : “voilà ce qui est actif, voilà pourquoi, voilà ce que ça change”. Si la réponse traîne, si tu dois réfléchir longtemps, si tu commences à dire “alors ça, c’était pour…”, c’est que le setup a déjà commencé à dériver.

Les signes qu’il faut faire du ménage

Tu n’as pas besoin d’un tableau de bord pour détecter qu’un setup Hermes commence à peser. Les signaux sont très concrets, et tu les reconnais facilement une fois que tu sais quoi chercher.

Le premier, c’est quand tu ne sais plus ce qui sert. Tu ouvres une session, quelque chose se passe, et tu n’es pas sûr de la couche en train de produire ce comportement. Tu hésites : est-ce le modèle, un tool, une skill, un serveur MCP, ou un reste de config ? Ce flou n’est jamais anodin. Il signe que le setup a dépassé ce que tu arrives à garder en tête.

Le deuxième, c’est quand tu hésites à toucher au setup. Pas parce qu’il est délicat, mais parce que tu ne sais plus ce que tu risques de casser. Un setup sain est un setup où tu te sens libre de retirer une couche sans stress. Le jour où chaque modification te paraît risquée, c’est que tu as perdu la carte du territoire.

Le troisième, c’est quand chaque bug semble venir de partout. Tu débogues, tu isoles, tu reviens à une base, et tu as quand même du mal à pointer la vraie cause. Souvent, ce n’est pas parce que le bug est compliqué : c’est parce qu’il y a trop de couches actives pour que la cause saute aux yeux.

Le quatrième, et c’est peut-être le plus révélateur, c’est quand tu te surprends à garder des choses “au cas où”. Une skill que tu n’utilises plus mais que tu laisses active parce que, sait-on jamais. Un tool dont tu ne te sers plus mais qu’il serait “dommage de retirer”. Un serveur MCP que tu n’as pas sollicité depuis longtemps mais que tu maintiens parce qu’il est déjà branché. Le “au cas où” est le carburant numéro un de l’accumulation.

Comment décider quoi garder

La question n’est jamais “est-ce que cette couche peut servir un jour ?”. La réponse à cette question est toujours oui, et c’est précisément pour ça qu’elle ne mène nulle part. La vraie question est : est-ce que cette couche sert maintenant, et suffisamment, pour justifier sa présence ?

Quelques critères qui aident à trancher honnêtement :

Utilité réelle. Est-ce que tu l’as utilisée récemment, de façon consciente, pour une tâche concrète ? Pas “elle s’est déclenchée toute seule”, pas “elle était là quand j’en ai eu besoin par hasard”. Utilisée volontairement.
Fréquence. Est-ce que c’est un usage régulier, ou un cas qui ne revient presque jamais ? Une skill qui sert une fois par an ne mérite pas forcément de rester active en permanence.
Lisibilité. Est-ce que tu peux expliquer simplement ce qu’elle fait ? Si tu ne peux plus, c’est déjà un problème, indépendamment de son utilité.
Stabilité. Est-ce qu’elle tient dans le temps, ou est-ce que tu dois la rafistoler à chaque changement de version ? Une couche qui demande de la maintenance permanente pour un bénéfice faible est une mauvaise affaire.
Coût mental. Est-ce qu’elle ajoute à la charge que tu dois garder en tête quand tu utilises Hermes ? Si oui, pour combien de bénéfice réel ?

Si, pour une couche donnée, tu n’arrives pas à répondre clairement à au moins la moitié de ces questions, tu as déjà ta réponse. Ce n’est pas forcément un “retire” immédiat, mais c’est au minimum un “relis, et justifie”.

Quand désactiver un tool

Un tool se désactive quand il ne sert plus réellement, ou quand il est devenu plus gênant qu’utile. Les cas typiques sont assez lisibles une fois que tu les connais.

Il y a le tool plus utilisé. Tu l’avais branché pour une tâche récurrente, cette tâche a disparu ou a changé de forme, et le tool est resté là. Il ne gêne pas visiblement, mais il n’apporte plus rien. Désactive-le, et tu verras vite si quelque chose te manque.

Il y a le tool redondant. Tu en as deux qui font à peu près la même chose parce que tu les as ajoutés à des moments différents sans les comparer. Un seul suffit presque toujours. Garder les deux, c’est juste ouvrir une porte à des comportements incohérents selon celui que l’agent décide d’appeler.

Il y a le tool qui s’active au mauvais moment. Celui qui sort régulièrement quand tu ne le voulais pas, celui qui parasite tes sessions sur des tâches où il n’a rien à faire. Si tu passes plus de temps à compenser ses déclenchements qu’à bénéficier de son apport, il est temps de le couper.

Et il y a le tool qui ajoute plus de doute que de valeur. Tu ne sais jamais trop quand il va se déclencher, tu n’es jamais sûr de ce qu’il va produire, tu le surveilles plus qu’il ne t’aide. Un tool qui te force à douter en permanence est un mauvais tool, même s’il est techniquement impressionnant.

Quand retirer une skill

Les skills sont particulièrement sensibles à l’accumulation. Elles sont faciles à écrire, faciles à brancher, et étonnamment difficiles à retirer, parce qu’elles représentent du travail et qu’on a l’impression de jeter quelque chose.

Tu dois retirer une skill quand elle est trop rigide par rapport à ton usage réel. Tu l’avais écrite pour un format précis, et ton usage a évolué. Elle continue à imposer son cadre à des demandes qui n’ont plus rien à voir. Elle ne t’aide plus, elle te contraint.

Tu dois la retirer quand elle est devenue trop bavarde. Une skill qui rajoute systématiquement des sections, des rappels, des avertissements ou du décor à des réponses qui n’en ont pas besoin finit par polluer tes sessions. Tu l’avais peut-être voulue verbeuse, mais ton besoin a changé.

Tu dois la retirer quand tu ne la relis plus. Une skill qu’on ne relit jamais est une skill qui finira par produire quelque chose de complètement inadapté. Si tu n’as plus envie de la relire, c’est probablement qu’elle n’est plus vraiment à toi.

Et tu dois la retirer quand elle est utilisée sans que tu t’en rendes compte. Tu constates, en remontant une session, qu’elle a façonné la réponse alors que tu n’y pensais même plus. Une skill active doit être une skill assumée. Si elle agit en sous-main, soit tu la réassumes consciemment, soit tu la retires.

Quand couper un serveur MCP

Les serveurs MCP sont la couche la plus coûteuse à garder pour rien, parce qu’ils ajoutent une dépendance externe à ton setup. Chaque serveur branché est une surface en plus : un truc qui peut changer, casser, devenir lent, ou simplement cesser d’être pertinent.

Le premier cas où tu dois couper un serveur MCP, c’est quand il est devenu décoratif. Tu l’avais branché pour un cas d’usage, ce cas d’usage a disparu, et le serveur tourne encore. Il ne coûte peut-être rien visuellement, mais il fait partie du paysage de couches que tu dois garder en tête pour comprendre ton setup.

Le deuxième cas, c’est quand il a été ajouté récemment et jamais réellement intégré. Tu voulais tester, tu as branché, tu n’as jamais fait l’effort de l’inclure vraiment dans ton usage. Ce n’est pas grave, c’est normal. Ce qui serait une erreur, ce serait de le laisser là indéfiniment en attendant que l’intégration se fasse toute seule.

Le troisième cas, c’est quand sa complexité dépasse son bénéfice. Il apporte quelque chose, d’accord, mais il ajoute aussi de la configuration, des points de défaillance, des comportements à comprendre. Si le gain net n’est pas clair, la question ne devrait même pas se poser.

Et le quatrième cas, c’est quand il devient source de confusion. Tu ne sais plus trop quand l’agent s’en sert, tu ne sais plus trop ce qu’il apporte par rapport au modèle seul, tu as l’impression qu’il complique plus qu’il n’éclaire. Coupe-le, observe quelques sessions, et tu sauras vite si tu en avais vraiment besoin.

Garder une config lisible dans le temps

Une config Hermes qui a vécu commence souvent à ressembler à une strate géologique. Tu vois bien qu’il y a eu plusieurs époques, plusieurs corrections, plusieurs essais. Certains blocs ne sont même plus sûrs d’être utiles. D’autres sont là depuis si longtemps que plus personne n’ose les toucher.

Le meilleur réflexe, c’est de relire. Pas de tout réécrire, pas de tout refondre : juste de relire. Une config qu’on n’a pas relue depuis trois mois est une config dont on ne sait déjà plus tout. Relis-la comme si tu ne l’avais pas écrite. Les blocs qui ne te parlent plus immédiatement sont des candidats au nettoyage.

Deuxième réflexe : ne pas laisser de restes. Une option que tu avais ajoutée pour un test, une valeur bricolée pour corriger un comportement ponctuel, un commentaire “à revoir” vieux de plusieurs semaines : ce sont des restes. Soit ils ont une raison d’être aujourd’hui et tu la formules clairement, soit ils n’en ont plus et tu les retires.

Troisième réflexe : revenir à des bases simples quand tu doutes. Si un bloc de config te paraît opaque, reviens à la version la plus simple qui fait le travail, et vois ce qui te manque vraiment. Souvent, ce qui manque est beaucoup moins que ce que tu avais empilé.

Et enfin, accepte qu’une config n’est pas un monument. Elle doit bouger, mais rester relisible.

Une routine légère de maintenance

Rien de tout ça ne suppose une usine. Tu n’as pas besoin d’un processus, d’un tableau de bord, ni d’une checklist à dix-huit points. Tu as besoin d’une petite revue régulière, assez courte pour que tu la fasses vraiment, assez fréquente pour que l’accumulation n’ait pas le temps de s’installer.

Le rythme exact t’appartient. Une revue toutes les quelques semaines suffit largement pour un usage personnel. Ce qui compte, ce n’est pas la fréquence précise, c’est qu’elle existe et que tu t’y tiennes.

La logique tient en quelques questions :

Qu’est-ce qui est actif en ce moment dans mon setup ?
De tout ça, qu’est-ce que j’ai réellement utilisé récemment ?
Qu’est-ce que je garde, qu’est-ce que je coupe, qu’est-ce que j’archive ?
Est-ce qu’il y a une couche que je ne saurais plus expliquer simplement ?

C’est tout. Pas de grand ménage annuel, pas de refonte dramatique, pas de remise à plat théâtrale. Juste une petite inspection régulière qui empêche le setup de grossir seul pendant des mois. La maintenance légère est presque toujours moins coûteuse que le grand sauvetage.

Une variante utile, pour les couches dont tu n’es pas sûr : désactive d’abord, retire ensuite. Couper sans supprimer te laisse le temps d’observer. Si rien ne te manque après quelques sessions, tu sais que tu peux retirer pour de bon. C’est une façon honnête de tester l’utilité réelle d’une couche sans tout casser.

Les erreurs les plus fréquentes

La plus commune, et de loin, c’est de garder au cas où. C’est un réflexe compréhensible, mais il est presque toujours perdant. Une couche gardée “au cas où” est une couche qui, neuf fois sur dix, ne servira pas avant d’avoir été oubliée, et qui, entre-temps, aura pesé sur la lisibilité de ton setup.

La deuxième, c’est de ne jamais rien retirer. Tu ajoutes, tu ajustes, tu branches, mais tu ne coupes jamais. Un setup qui ne fait que grossir finit mécaniquement par devenir opaque. Ajouter et retirer font partie du même geste.

La troisième, c’est de confondre richesse et qualité. Un setup avec beaucoup de couches n’est pas un meilleur setup. Il est juste plus chargé. La qualité d’un setup se mesure à ce qu’il produit de façon fiable, pas à ce qu’il affiche.

La quatrième, c’est d’avoir peur de toucher à un setup devenu opaque. Plus tu attends, plus il devient opaque, et plus tu as peur. C’est un cercle fermé. La seule façon d’en sortir est de commencer petit : une seule couche relue, une seule couche désactivée, une seule observation. Pas de grande remise à plat, juste un premier pas.

Et la cinquième, c’est d’accumuler des couches qu’on ne relit plus. Une couche qui n’est plus relue n’est plus vraiment à toi. Elle agit en ton nom, mais tu ne sais plus exactement comment. C’est la définition même d’un setup qui commence à dériver.

Ce que tu ne dois pas faire

Tu ne dois pas transformer Hermes en vitrine technique. Un setup n’est pas là pour impressionner, il est là pour te servir. Si tu commences à ajouter des couches parce qu’elles ont l’air avancées, tu n’optimises plus ton usage, tu construis un décor.

Tu ne dois pas garder une couche juste parce qu’elle a demandé du travail. Le temps passé à la mettre en place n’a aucun rapport avec son utilité aujourd’hui. Une skill qui t’a coûté un après-midi mais qui ne sert plus doit partir aussi facilement qu’une skill écrite en cinq minutes.

Tu ne dois pas tout supprimer d’un coup sans comprendre. Le but n’est pas de vider le setup, c’est de le garder honnête. Une maintenance brutale, menée sous le coup d’une frustration, finit presque toujours par casser des choses qui fonctionnaient et par laisser des choses qui ne fonctionnent pas.

Tu ne dois pas croire que plus c’est complexe, plus c’est avancé. Les setups les plus solides ne sont presque jamais les plus chargés. Ils sont ceux où chaque couche tient debout toute seule, et où tu peux encore expliquer l’ensemble en quelques phrases.

Et tu ne dois surtout pas laisser le setup grossir seul pendant des mois en te disant que tu feras le tri “plus tard”. Plus tard, le tri sera beaucoup plus douloureux, et tu auras perdu la mémoire de la moitié des décisions que tu avais prises.

La suite logique

Un setup propre ne fait pas plus de bruit. Il rend juste le reste plus simple : debug plus net, sécurité plus lisible, mises à jour moins risquées.

Ce n’est pas la partie la plus glamour de la série. C’est pourtant celle qui évite qu’Hermes finisse en placard technique qu’on n’ose plus ouvrir.