Hermes Agent : la routine propre pour l'utiliser au quotidien

Tu as maintenant vu les briques une par une. Le vrai sujet, au quotidien, c’est l’arbitrage : quand rester en prompt simple, quand sortir un tool, quand une skill vaut le coup, et quand MCP mérite vraiment d’entrer dans la boucle.

Ce tuto ne redéfinit pas chaque brique. Il te donne une routine courte pour choisir la bonne couche au bon moment, puis garder la session lisible du début à la fin.

Ce que tu auras à la fin
Une vision claire de ce qu’est une session Hermes propre, une règle simple pour choisir entre prompt, tool, skill et serveur MCP, une routine légère d’ouverture et de fin de session, et un cadre d’erreurs à éviter pour ne pas voir une bonne session dériver en bazar.

Pour qui est ce tuto
Tu as déjà vu les briques séparément et tu veux maintenant une règle d’usage simple pour savoir laquelle sortir selon la tâche du moment.

À quoi ressemble une session Hermes propre

Une session propre n’a rien de spectaculaire. Au contraire : c’est une session où il ne se passe pas grand-chose d’inutile. Un objectif clair en tête, une demande formulée sobrement, l’agent qui répond, et toi qui avances. Pas de théâtre, pas d’empilement, pas de démonstration de setup.

Ce que tu cherches, c’est une session lisible. Tu peux dire à tout moment ce que tu essaies d’obtenir, pourquoi tu as activé telle ou telle couche, et ce que chacune apporte concrètement. Le jour où tu n’arrives plus à répondre à ces trois questions, la session a déjà commencé à déraper.

Une session propre, c’est aussi une session où les couches actives ont une raison d’être maintenant, pas “au cas où”. Un tool branché qui ne sert pas, une skill active qui n’a rien à voir avec ta tâche, un serveur MCP allumé par habitude : ce sont tous des parasites. Chacun pris isolément ne casse rien. Empilés, ils rendent la session illisible, et c’est à ce moment que tu commences à ne plus comprendre d’où viennent les comportements que tu observes.

Commencer par la demande la plus simple possible

Le premier réflexe sain, c’est de partir en prompt simple. Pas par paresse, par discipline. Tant que tu n’as pas formulé clairement ce que tu veux, brancher une couche supplémentaire ne sert à rien. Tu ne fais que déplacer le flou sur une autre brique.

Formule ta demande comme si tu n’avais rien d’autre qu’un chat texte. Si ça répond correctement, tu as gagné du temps et tu n’as rien à ranger derrière. Si ça ne répond pas bien, tu sais au moins pourquoi : le besoin était mal exprimé, ou il lui manque un accès concret à quelque chose. Dans les deux cas, tu as appris quelque chose d’utile pour choisir la couche suivante.

Ce qu’il faut éviter, c’est le réflexe inverse : sortir d’emblée tool, skill et MCP parce qu’on les a sous la main. Quand tu fais ça, tu ne sais plus distinguer ce qui vient du modèle, ce qui vient de tes couches, et ce qui vient d’une demande mal posée. Tu débogues à l’aveugle dès la première minute.

Quand rester en prompt simple

Il y a beaucoup de situations où le prompt simple est non seulement suffisant, mais supérieur à tout le reste.

Tâches ponctuelles. Une question que tu ne poseras probablement jamais plus sous cette forme. Aucune raison de figer quoi que ce soit autour.
Demandes non répétitives. Tu explores un sujet, tu creuses une idée, tu demandes une relecture rapide sur un texte. Rien à empaqueter.
Besoin encore flou. Tu sens ce que tu veux sans pouvoir encore le décrire. Une skill posée sur un besoin flou va geler le flou, pas le résoudre.
Premier test d’une idée. Tu veux voir si le modèle tient la route sur un type de tâche avant d’investir du temps à la cadrer. Reste léger tant que tu n’as pas validé que ça vaut le coup.

La règle tient en une phrase : tant qu’un échange texte suffit, un échange texte suffit. Tu ne sors l’artillerie lourde que si tu as une raison concrète de le faire.

Quand utiliser un tool

Sors un tool quand la réponse a besoin d’un accès réel que le texte seul ne peut pas donner : lire un fichier, explorer un dossier, lancer une commande, appeler une ressource. Le critère tient en une question : sans ce tool, est-ce que la réponse serait forcément approximative ou reconstruite ? Si oui, il a sa place. Sinon, reste en prompt simple.

Quand une skill vaut le coup

Une skill vaut le coup quand la tâche revient souvent, avec le même cadre de sortie, et que tu en as marre de répéter les mêmes consignes. Pas avant. Une skill sert à figer une méthode qui fonctionne déjà, pas à donner une forme solennelle à un besoin encore flou.

Quand MCP devient pertinent

MCP devient pertinent quand il te manque une capacité externe bien identifiée et que ta base tient déjà sans elle. Pas pour faire plus avancé, pas pour meubler le setup, mais pour brancher proprement une brique extérieure dont tu connais déjà l’utilité.

La séquence reste donc simple : base stable, puis extension. Si tu ne sais pas encore ce qui manque exactement, ce n’est probablement pas le moment de brancher un serveur MCP.

Une routine simple d’ouverture de session

Pas de pseudo-rituel, juste quelques réflexes légers qui évitent 80 % des dérives.

Vérifie ce que tu veux faire. Une phrase claire, dans ta tête ou à l’écrit. Si tu n’arrives pas à la formuler, ce n’est pas le moment d’ouvrir l’agent, c’est le moment de prendre deux minutes pour clarifier.
Regarde si la base suffit. Le modèle nu, sans couches, peut-il répondre à ça ? Si oui, tu n’ajoutes rien.
N’ajoute qu’une couche si nécessaire. Un tool, une skill ou un serveur MCP. Un seul, pas trois. Et tu dois pouvoir dire pourquoi.
Garde une logique d’usage lisible. Si, en cours de session, tu ne sais plus ce qui est actif et pourquoi, tu fais une pause et tu ranges avant de continuer.

C’est tout. Ce n’est pas une méthode révolutionnaire, c’est une discipline minimale. Son intérêt, c’est qu’elle est assez légère pour tenir dans la durée, et c’est la seule chose qui compte.

Une routine simple de fin de session

La fin de session est la partie que tout le monde zappe, et c’est précisément là que le passif s’accumule. Une session terminée mais jamais rangée laisse des couches actives qui reviendront te hanter à la prochaine ouverture.

Quelques réflexes suffisent :

Vérifie le résultat. Est-ce que tu as obtenu ce que tu voulais, ou seulement quelque chose qui ressemble à ce que tu voulais ?
Note ce qui a servi. Deux lignes dans un carnet, rien de sophistiqué. Quel tool a été utile, quelle skill a changé quelque chose, quel serveur MCP a vraiment apporté une capacité concrète.
Retire ce qui n’a rien apporté. Une couche activée pour rien, c’est une couche à désactiver avant la prochaine session. Sinon, elle devient un décor permanent dont tu oublies la raison d’être.
Garde le setup propre. Pas de tool actif orphelin, pas de skill en conflit avec une autre, pas de serveur MCP branché “au cas où”.

L’idée, c’est d’éviter l’accumulation invisible. Personne ne remarque le jour où ça dérape, parce que rien ne casse bruyamment. On se réveille juste un matin avec un setup illisible dont on ne sait plus quoi retirer sans risquer de casser quelque chose.

Les erreurs qui transforment une bonne session en bazar

Quelques schémas reviennent souvent et méritent d’être nommés, parce qu’ils sont insidieux.

Trop de couches d’un coup. Tu actives un tool, une skill et un serveur MCP dans la même session pour tester. Dès qu’un résultat est bizarre, tu n’as aucun moyen de savoir d’où ça vient.
Usage réflexe de MCP ou des skills. Tu les lances par habitude, même quand la tâche ne le justifie pas. Le coût en lisibilité se paie plus tard, pas sur le coup.
Absence de test simple. Tu ne fais jamais tourner la tâche en prompt nu pour comparer. Tu crois que tes couches apportent quelque chose, mais tu ne l’as jamais vraiment vérifié.
Pas de point de comparaison. Tu n’as aucun souvenir de comment ça se comportait avant ton dernier changement. Tu ne peux donc pas dire si ça va mieux, moins bien, ou pareil.
Session qui dérive. Tu es parti pour une tâche précise, tu en fais cinq autres au passage, et à la fin tu ne sais plus laquelle a échoué, laquelle a réussi, ni pourquoi.
Complexité ajoutée par principe. “Puisque j’ai le setup, autant m’en servir.” C’est exactement l’inverse d’une routine saine. Tu dois pouvoir justifier chaque couche par la tâche en cours, pas par le simple fait qu’elle existe.

Ce que tu ne dois pas faire

Quelques lignes rouges, simples à retenir.

Ne sors pas tools, skills et MCP par réflexe. La base suffit bien plus souvent que tu ne le crois.
Ne garde pas des couches actives juste parce qu’elles existent. Une couche qui ne sert pas à la tâche en cours est une couche à désactiver, pas un décor.
Ne confonds pas session compliquée et session avancée. Une session avancée, c’est une session où tu obtiens un résultat précis avec le minimum de couches. Une session compliquée, c’est souvent juste une session mal rangée.
N’empile pas sans relire. Si tu ne peux pas dire à voix haute ce qui est actif et pourquoi, tu as déjà trop empilé.
N’oublie pas que le but est d’obtenir un résultat, pas d’exhiber le setup. Ce que tu veux, c’est une configuration utile et lisible, dans cet ordre.

Une routine saine n’est pas une routine rigide. C’est juste un garde-fou contre tes propres réflexes quand une session commence à s’emballer. Elle ne t’empêche pas d’explorer. Elle t’empêche de te perdre.

La suite logique

Tu as maintenant une règle d’usage simple : prompt tant que ça suffit, tool quand il faut agir, skill quand un cadre revient, MCP quand une capacité externe manque vraiment.

Le reste, c’est de l’hygiène : une couche à la fois, une vraie raison, un rangement en fin de session. Une routine propre n’est pas spectaculaire. C’est justement pour ça qu’elle tient.

La suite logique, c’est le moment où malgré ça une session déraille, et comment la remettre sur les rails sans repartir de zéro.