Hermes Agent : le guide complet pour démarrer en local

Hermes Agent fait partie de ces outils qu’on installe “pour voir” et qu’on finit par garder, parce qu’ils changent vraiment la façon de bosser en local. Mais entre l’installation, la config, les modèles, les tools, les skills et la sécurité, il y a dix portes d’entrée possibles, et beaucoup font perdre du temps dès le départ.

Ce guide est la bonne porte. Pas un dump de commandes, pas une doc recopiée : un chemin clair pour démarrer proprement, sans fausser le départ.

Ce que tu vas obtenir à la fin Une vision nette de ce qu’est Hermes Agent, de ce qu’il fait bien, de ce qu’il ne fait pas, et un parcours balisé pour lancer ta première session locale sans te noyer dans la config.

Pour qui est ce guide Tu sais utiliser un terminal, tu as déjà joué avec un modèle local ou un LLM en API, et tu veux passer au cran au-dessus : un vrai agent, piloté depuis ta machine, qui exécute des choses pour toi. Si tu n’as jamais ouvert un terminal, commence par un tuto d’initiation avant celui-ci.

Contexte Ce guide reste volontairement générique. Il ne dépend pas d’une version précise d’Hermes Agent ni d’un OS particulier. Les commandes exactes, les chemins de config et les détails d’install sont traités dans les tutos dédiés de la série.

1. C’est quoi Hermes Agent, exactement

Première chose à poser clairement : un agent, ce n’est pas un chat.

Un chat LLM, tu lui parles, il répond. C’est un tour de parole. Tu fais le travail autour : copier-coller, vérifier, exécuter, relancer.

Un agent, c’est un LLM qui peut utiliser des outils au milieu de son raisonnement. Il lit, il écrit, il appelle une fonction, il regarde le résultat, il décide de la suite. Ce n’est pas de la magie : c’est une boucle “réfléchir → agir → observer → recommencer” pilotée par un modèle de langage, avec des garde-fous que tu définis.

Hermes Agent, c’est une implémentation de cette logique : un runtime qui orchestre un modèle, des outils, une config et un contexte de travail, le tout pilotable en local.

Les briques principales à garder en tête :

Le modèle : le cerveau. Local (via llama.cpp ou équivalent) ou distant, selon ton choix.
Les tools : ce que l’agent peut faire. Lire un fichier, lancer une commande, interroger une API, etc.
La configuration : ce que l’agent a le droit de faire, avec quoi, et dans quel cadre.
Le contexte : ce qu’il voit à un instant donné — l’historique de la conversation, les fichiers montés, l’état.

Ce qu’il fait bien

Enchaîner plusieurs étapes sans que tu aies à tout coller à la main.
Lire un dossier, naviguer, chercher, résumer.
Appeler des outils selon ce que tu demandes, et intégrer la réponse.
Rester piloté : tu gardes la main, tu valides, tu corriges.

Ce qu’il ne fait pas magiquement

Deviner ce que tu veux quand ta demande est floue.
Remplacer un modèle médiocre par de la config.
Être “autonome” au sens où on n’aurait plus rien à surveiller.
Protéger ton système si tu lui as donné toutes les clés.

Un agent local reste un outil. Puissant, oui. Intelligent dans la limite du modèle derrière. Jamais responsable à ta place.

2. À quoi ça sert vraiment en local

On voit passer beaucoup de démos agentiques impressionnantes. En pratique, en local, les usages qui tiennent sur la durée sont plus terre-à-terre, et tant mieux.

Un exemple typique : tu récupères un repo que tu ne connais pas, tu lances l’agent à la racine, tu lui demandes de te résumer l’arborescence et de pointer les fichiers clés. Deux minutes plus tard, tu as une carte du terrain que tu aurais mis une demi-heure à construire à la main. C’est ce genre de gain qui finit par rendre l’outil indispensable — rien de spectaculaire, juste du temps rendu, souvent.

Quelques cas d’usage génériques où un agent local devient réellement utile :

Explorer un projet. Un repo inconnu, une base de code héritée, un dossier de notes en vrac.
Automatiser des tâches répétitives. Renommer, classer, reformater, extraire des données depuis plusieurs fichiers.
Prototyper vite. Écrire un petit script, le tester, le corriger, le relancer, sans quitter le terminal.
Travailler hors ligne ou sur des données sensibles. Pas de cloud, pas d’envoi extérieur, pas de question à se poser sur qui lit quoi.
Apprendre en manipulant. Un agent qui t’explique ce qu’il fait pendant qu’il le fait, c’est un excellent prof pour comprendre un outil.

Pour qui c’est pertinent

Tu bosses souvent en terminal.
Tu as déjà un setup local fonctionnel (ou tu es prêt à en monter un).
Tu veux garder tes données chez toi.
Tu aimes comprendre ce qui tourne plutôt que cliquer sur “Accepter”.

Pour qui ce n’est pas idéal (aujourd’hui)

Tu cherches un assistant “zéro config” dans un navigateur.
Ton matériel ne peut pas faire tourner un modèle local correct et tu ne veux pas brancher un modèle distant.
Tu attends un produit fini et stable à la ChatGPT. Un agent local, ça se bricole un peu, surtout au début.

Rien de grave : choisir le bon outil pour la bonne phase fait partie du métier.

3. Ce qu’il faut avant de commencer

La meilleure manière de rater un démarrage, c’est de vouloir tout installer le même soir : l’agent, un modèle lourd, dix tools, trois MCP, une skill compliquée. Tu finis à 2h du matin avec rien qui marche et zéro idée d’où ça coince.

Avant de toucher à Hermes Agent, pose le décor.

Niveau minimum attendu

Savoir utiliser un terminal (cd, ls, cat, éditeur de texte).
Comprendre ce qu’est une variable d’environnement.
Avoir déjà installé un outil en ligne de commande au moins une fois.
Idéalement, avoir déjà fait tourner un LLM quelque part, même via une API.

Si deux de ces points te manquent, ce n’est pas bloquant, mais prévois un peu de marge.

Environnement général

Un OS que tu connais. Linux, macOS ou WSL sous Windows sont des terrains naturels pour ce genre d’outils.
Un dossier de travail propre, versionné si possible. Tu vas toucher à des fichiers de config, autant avoir un filet.
De quoi lire une doc sans paniquer : une page de doc officielle ouverte quelque part ne t’a jamais tué.

Matériel et modèle

On peut faire tourner un agent local avec un modèle distant (API) ou un modèle local. Les deux sont valables, et au démarrage, commencer avec un modèle léger mais suffisant est souvent plus malin qu’attaquer direct avec le plus gros truc que ta machine peut avaler.

Règle simple : le modèle doit être confortable à faire tourner sur ta machine pendant de longues sessions. Si chaque réponse prend trois minutes et fait fondre ton GPU, tu ne vas rien apprendre, tu vas juste attendre.

Philosophie “faire simple d’abord”

Au premier lancement, tu veux :

Un modèle unique.
Aucun tool exotique.
Une config minimale.
Un objectif clair : “voir l’agent répondre, exécuter une commande simple, lire un fichier”.

Pas plus. On ajoute des briques après avoir vu la base tourner.

4. Installer Hermes Agent proprement

Ce guide n’est pas un tuto d’installation pas-à-pas. L’installation précise dépend de ton OS, de ta version d’Hermes Agent et de comment tu gères tes environnements (Python, conteneurs, gestionnaire de paquets). Un tuto dédié couvrira ça en détail.

Ce qu’il faut comprendre de la logique générale, peu importe la version :

Isoler l’environnement. Un environnement dédié (virtualenv, dossier projet propre, conteneur) t’évite des conflits qui te feraient perdre des heures.
Installer depuis une source de confiance. La source officielle du projet, pas un mirror trouvé au hasard.
Vérifier que le binaire ou le point d’entrée répond. Avant de toucher à quoi que ce soit d’autre, tu veux voir l’agent se lancer et afficher sa version ou son aide.
Ne rien configurer avant d’avoir vu l’outil répondre au moins une fois. Si tu empiles dix fichiers de config avant le premier lancement, tu ne sauras pas ce qui casse quand ça cassera.

Bonne pratique : garde une trace écrite de ton installation. Les versions, les chemins, les choix. Dans six mois, tu te remercieras.

Pour le pas-à-pas complet, va sur Installer Hermes Agent sur Windows, WSL et Linux.

5. Les premières commandes à connaître

Chaque version d’Hermes Agent a sa CLI propre, mais la logique, elle, ne bouge pas tellement. Plutôt que te balancer une liste de commandes précises qui seront fausses dans deux mises à jour, voici ce que tu dois chercher à faire pendant ta toute première heure avec l’outil.

Les quatre choses à savoir faire au début

Lancer l’agent et voir qu’il répond. Un “hello” basique, rien de plus. Si cette étape ne marche pas, toutes les suivantes sont une perte de temps.
Afficher l’aide et la version. Tu dois savoir quelle version tu fais tourner. Tu dois savoir lister les sous-commandes disponibles.
Lancer une session interactive simple. Pas de tool, pas de MCP, rien. Juste parler à l’agent, voir les temps de réponse, voir si le modèle branché répond correctement.
Quitter proprement. Ça paraît bête, mais apprendre comment arrêter, comment interrompre, comment reprendre, ça t’évitera des sessions fantômes et des fichiers de lock bizarres.

Ton premier vrai test utile

Une fois ces quatre points passés, donne à l’agent une tâche minuscule mais réelle : lui demander de lire un fichier texte précis de ton dossier de travail et de t’en résumer le contenu en trois phrases. C’est bête, c’est court, et c’est exactement le test qui te dit si la boucle “modèle ↔ outil ↔ retour” fonctionne de bout en bout. Si ce test passe, tu as une base saine. S’il rate, tu sais précisément quoi regarder avant d’aller plus loin.

Erreurs fréquentes au début

Lancer la commande depuis un mauvais dossier et récupérer un contexte vide.
Oublier d’activer l’environnement isolé qu’on a pris la peine de créer.
Confondre “l’agent ne répond pas” et “le modèle rame” — ce n’est pas le même problème.
Fermer le terminal en pleine session au lieu de quitter proprement.

Un tuto dédié aux commandes utiles au quotidien suivra dans la série.

6. Brancher un modèle local

C’est souvent ici que ça coince. Pas parce que c’est compliqué techniquement, mais parce qu’on mélange trois notions : le runtime qui fait tourner le modèle, l’endpoint qui expose le modèle à l’agent, et le modèle lui-même.

Pose ces trois notions et tout devient plus simple.

Le runtime

C’est le programme qui charge le modèle en mémoire et le fait tourner. llama.cpp et ses dérivés sont les plus répandus pour l’inférence locale. Selon ton matériel (CPU seul, GPU Nvidia, GPU AMD, Apple Silicon), tu vas choisir une build adaptée. Ce runtime est indépendant de l’agent — il vit sa vie.

L’endpoint

La plupart des runtimes modernes exposent une API HTTP locale compatible avec le format OpenAI. Concrètement : une URL du type http://127.0.0.1:<port>, à laquelle l’agent envoie ses requêtes comme si c’était une API distante. C’est ce qui permet à Hermes Agent de “parler” à ton modèle local sans avoir à tout réinventer.

Le modèle

Le fichier de poids, en général au format GGUF pour les runtimes de type llama.cpp. Tu le télécharges, tu le poses dans un dossier propre, tu l’indiques au runtime au lancement.

La logique de branchement

Le runtime se lance avec un modèle et ouvre un endpoint local.
Hermes Agent est configuré pour pointer vers cet endpoint.
Tu parles à Hermes Agent, qui envoie au modèle, qui répond, qui remonte à toi.

C’est tout. Si ça ne marche pas, le problème est presque toujours dans une de ces trois cases :

Le runtime n’est pas lancé ou a planté.
L’endpoint n’est pas le bon (port, adresse, protocole).
Le modèle choisi ne correspond pas au format attendu ou est trop lourd pour ta machine.

Choisir un premier modèle

Ne prends pas le plus gros. Prends un modèle réputé pour bien suivre les instructions, assez petit pour répondre vite sur ta machine, et testé par d’autres dans le cadre d’un usage agent. La vitesse de feedback compte énormément quand tu apprends : un modèle qui répond en deux secondes t’apprend dix fois plus en une soirée qu’un modèle qui répond en trente.

Pour le branchement complet côté runtime, endpoint et premier test, voir Hermes Agent + llama.cpp : brancher un modèle local proprement.

7. Comprendre la configuration

La config d’Hermes Agent, c’est le fichier où tu dis à l’agent qui il est, quoi utiliser, et ce qu’il a le droit de faire. Ne pas la comprendre, c’est piloter à l’aveugle.

Sans entrer dans des champs précis qui varient selon la version, voici les grandes familles de réglages à identifier en priorité :

Le provider et le modèle. À qui l’agent parle pour raisonner. Modèle local via endpoint, modèle distant via API, ou les deux configurés en parallèle.
Les paramètres d’inférence. Température, longueur maximale, éventuels paramètres de sampling. Au début, les valeurs par défaut suffisent presque toujours. Ne touche à rien avant d’avoir une raison précise.
Les tools disponibles. La liste des outils que l’agent peut appeler. C’est ici qu’on décide de ce à quoi il a accès.
Les permissions et limites. Ce qu’il peut exécuter, dans quel dossier, avec quels droits. Le point le plus critique du fichier.
Le contexte de travail. Dossier courant, fichiers visibles par défaut, éventuels prompts système.

Erreurs de config classiques

Copier un fichier de config trouvé quelque part sans comprendre ce qu’il active.
Activer tous les tools “au cas où”.
Mettre des chemins en dur qui n’existent pas sur ta machine.
Laisser des valeurs de debug en place (“true” partout) et s’étonner que l’agent soit bavard.
Stocker des secrets directement dans le fichier de config versionné.

Règle saine : tu ajoutes une option seulement quand tu sais pourquoi tu l’ajoutes. Si tu ne peux pas l’expliquer à voix haute en une phrase, enlève-la.

Pour lire les vrais réglages sans casser ton setup, enchaîne avec Hermes Agent : comprendre et régler la config sans tout casser.

8. Outils, MCP et skills : par où commencer

Trois mots qui reviennent tout le temps autour des agents. Posons-les simplement.

Tool
Une fonction que l’agent peut appeler. “Lire ce fichier”, “lancer cette commande”, “chercher dans ce dossier”. Un tool, c’est une capacité concrète, limitée, définie.

MCP (Model Context Protocol)
Un protocole standard pour que des serveurs externes puissent exposer des tools à un agent, de manière uniforme. Au lieu d’écrire chaque tool à la main, tu branches un serveur MCP et l’agent récupère les tools qu’il propose. C’est une brique d’intégration, pas une magie — un serveur MCP mal choisi ou mal configuré t’ajoute des problèmes plus qu’il n’en résout.

Skill
Une mini-compétence empaquetée : souvent un prompt, parfois quelques instructions, éventuellement des tools, regroupés autour d’un usage précis. “Revue de code”, “analyse de logs”, “tri de fichiers”. Une skill, c’est une manière de capitaliser sur une façon de faire qui marche, pour la rejouer plus tard sans réécrire les instructions à chaque fois.

Par où commencer concrètement

Dans l’ordre, quand tu découvres l’outil :

Zéro tool. Fais parler l’agent tout court. Vérifie que le modèle suit tes instructions.
Un ou deux tools très simples. Typiquement : lire un fichier, lister un dossier. Des trucs sûrs, utiles, immédiatement parlants.
Un vrai cas d’usage. Une tâche concrète que tu aurais faite à la main : l’agent la fait, tu regardes comment il s’y prend.
Ensuite seulement, MCP et skills. Quand tu maîtrises la base, tu ajoutes une couche. Pas avant.

Exemple parlant pour le “vrai cas d’usage” : un dossier rempli de captures d’écran au nom illisible, que tu veux renommer et classer par date. Demande à l’agent de te proposer un plan avant de toucher à quoi que ce soit, regarde ce qu’il propose, corrige, puis laisse-le exécuter sur trois fichiers de test avant de l’élargir au dossier entier. Tu apprends énormément juste en observant comment il découpe la tâche.

L’erreur classique, c’est de brancher dix tools et trois serveurs MCP avant même d’avoir vu l’agent lire un fichier. Tu te retrouves avec un tableau de bord que tu ne comprends pas, et quand ça casse, tu ne sais même pas où regarder.

Des tutos dédiés couvrent les tools, MCP et skills de manière plus approfondie.

9. Les erreurs fréquentes

Après un certain nombre de premières prises en main ratées (les siennes et celles des autres), les mêmes écueils reviennent. Les connaître à l’avance, c’est en éviter la moitié.

Vouloir tout faire d’un coup
Installer, configurer, brancher un modèle, activer cinq tools, tester trois skills, le tout dans la même session. Tu n’apprends rien et au premier bug tu ne sais pas d’où il vient. Une chose à la fois.

Mauvais modèle local
Un modèle trop petit qui ne suit pas les instructions, ou un modèle trop gros qui rend chaque aller-retour insupportable. Les deux cassent l’expérience. Un modèle moyen bien choisi et rapide vaut mieux qu’un modèle énorme qui rame.

Trop de tools
Plus un agent a d’outils, plus il peut en choisir un mauvais. Au début, moins c’est mieux.

Trop de pouvoir donné à l’agent
Droits d’écriture partout, exécution de commandes arbitraires sans filet, accès à tout le home. Un jour ou l’autre, un prompt ambigu plus un modèle trop zélé égale une session où tu expliques à ton disque dur ce qu’il s’est passé. On n’en est pas à la catastrophe systématique, mais la sagesse élémentaire dit : le moins de droits possible, pour commencer.

Config copiée sans compréhension
Un fichier trouvé sur un forum ou un repo inconnu, collé tel quel. Ça “marche” au début, et six semaines plus tard tu ne sais toujours pas ce que fait la moitié des lignes. Écris ta config, même minimale. Comprendre bat copier.

Confondre lenteur et bug
Un modèle local qui met dix secondes à démarrer sa réponse, ce n’est pas un bug. Vérifie l’activité du runtime avant de tout redémarrer.

Ne pas lire les logs
Les agents modernes loggent beaucoup. Les logs contiennent 80 % des réponses à tes problèmes. Apprends juste à les ouvrir et à les parcourir calmement.

10. Sécurité : ce qu’il ne faut pas faire

Un agent local a accès à ta machine. Ça veut dire qu’il faut penser sécurité dès le premier jour, pas “plus tard quand tout marchera”.

Pas besoin d’un manuel de trente pages. Quatre principes simples suffisent au départ.

Ne pas exposer les secrets
Tes clés d’API, tes tokens, tes mots de passe ne doivent jamais vivre en clair dans un fichier de config que tu versionnes ou que l’agent peut lire sans raison. Variables d’environnement, gestionnaire de secrets, fichiers exclus du versioning : choisis ton système, mais pose-le tout de suite.

Ne pas donner trop de droits
Limite le périmètre de l’agent à un dossier de travail dédié. Ne lui donne pas accès à l’intégralité de ton home, à des dossiers système, ou à des dossiers contenant des données sensibles, tant que tu n’as pas une raison précise. Un dossier ~/hermes-lab/ dédié, et rien d’autre pour commencer : c’est moche, mais c’est sain.

Ne pas le laisser écrire ou exécuter sans cadre
Si tu actives des tools capables de modifier des fichiers ou de lancer des commandes, impose un cadre : dossier restreint, validation manuelle pour les opérations destructrices, mode “dry run” quand il existe. Mieux vaut un agent légèrement plus lent qui demande confirmation qu’un agent brillant qui a effacé ton projet.

Rester propre dans l’environnement
Dossier de travail dédié, historique versionné, sauvegardes régulières. Tout ça n’est pas spécifique à Hermes Agent — c’est de l’hygiène de base — mais un agent accélère tout, y compris les erreurs. Autant avoir un filet.

Règle générale à garder en tête : un agent exécute au nom de l’utilisateur qui le lance. Il a tes droits. Traite-le en conséquence.

Couvert plus loin dans la série, dans un tuto sécurité dédié.

11. Par où continuer après ce guide

Ce guide te donne la carte. Il ne te donne pas tout le territoire — c’est volontaire. Essayer de tout couvrir dans un seul article, c’est le meilleur moyen de ne rien transmettre vraiment.

Démarrer avec un agent local, ce n’est pas monter un cockpit d’ingénieur fusée. C’est comprendre trois ou quatre briques, les faire tourner une à une, et refuser la tentation d’en empiler quinze avant d’en maîtriser deux. Pris doucement, Hermes Agent devient un outil qu’on garde. Pris à la va-vite, il devient une fenêtre de plus qu’on ferme au bout de trois jours.

Choisis le démarrage propre.

Par où commencer si tu débutes

Installer Hermes Agent proprement, dans un environnement isolé.
Brancher un modèle local léger via llama.cpp, rapide à interroger.
Faire une première session sans aucun tool, juste pour sentir l’outil.
Ajouter un ou deux tools de lecture simples (lire un fichier, lister un dossier).
Relire ta propre config et t’obliger à justifier chaque ligne.

À ce stade, tu as de quoi t’approprier l’outil sans te mettre en danger.

Lire ensuite

D’autres articles de la série Hermes Agent approfondissent, un par un, les points laissés volontairement généraux ici :

Installation détaillée, étape par étape.
Branchement d’un modèle local avec llama.cpp.
Configuration : lecture ligne par ligne d’un fichier minimal.
Tools, MCP et skills : exemples concrets et cadrage.
Sécurité d’un agent local au quotidien.

Et si tu veux monter une machine cohérente pour ce type d’usage, nos guides configs TekBrut peuvent te servir de point de départ.