Hermes Agent : un collaborateur IA qui travaille dans le terminal

Hermes Agent est un assistant IA conversationnel. C’est la bille qui tourne dans ce projet : sans lui, Refer n’existe pas, et chaque article publié ici est d’abord produit par une conversation avec lui. À ne pas confondre avec le modèle lui-même : c’est l’interface, l’agent, le collaborateur qui vit dans le terminal.

Ce n’est pas un CMS, pas plus qu’une API. C’est un programme qui reçoit des demandes en français, les découpe en actions concrètes, les exécute en lisant et écrivant des fichiers, en lançant des commandes, et en consolidant les résultats dans des artefacts bien identifiés — des branches Git, des pull requests, des commentaires.

Ce que fait un agent dans un terminal

Un agent comme Hermes ne se contente pas de répondre à une question. Il agit, et il laisse une trace.

Quand on lui demande de « préparer un article sur Hugo », il ne donne pas une réponse aphasique. Il va dans le dossier du projet, il lira la structure existante, il rédige un brouillon au format attendu, il lancera les vérifications automatiques, il créera une branche, et il ouvrira une pull request. Chaque étape est une commande, chaque commande est un commit, chaque commit est visible dans l’historique.

Cette trace est la partie la plus importante. Un assistant qui ne fait que répondre ne laisse rien derrière lui. Un agent laisse un dépôt de travail, des preuves et un suivi. Rien n’est publié sans validation explicite : tout passe par une revue, un merge, une publication qui peut être refusée.

Pourquoi le terminal est l’endroit idéal

Le terminal est un environnement relationnel. Il n’y a pas d’interface graphique qui intermédiaire, il n’y a pas de formulaires à remplir, il n’y a qu’une ligne de commande et des fichiers. L’agent y voit :

• Des fichiers : la source du projet, les articles, les scripts de validation, la configuration.
• Des commandes : les vérifications automatiques, les builds Hugo, les appels aux outils.
• Des dépôts : Git pour les branches et les commits, GitHub pour les pull requests et les revues.

Elle ne « devine » pas ce qui se trouve ailleurs. Elle le vérifie. Elle lit un fichier, elle exécute une commande, elle regarde la sortie, et elle s’en sert pour la suite. C’est ça, en pratique, la différence entre un modèle de langage et un agent : le modèle génère du texte, l’agent génère des actions et les valide avec le monde.

Le travail est tracé, pas improvisé

Dans Refer, chaque article suit le même parcours, sans exception :

1. La conversation — le propriétaire du blog demande un article. L’agent s’interroge, vérifie les conventions, et commence à travailler.
2. La préparation — il écrit un brouillon au format Markdown, avec les champs de front matter requis, un résumé, une date, un titre.
3. La validation — il lance le script de contrôle du contenu, puis le build Hugo en local.
4. La publication — il ouvre une pull request sur GitHub. Pas fait maison, pas directement sur la production.
5. La revue — le propriétaire consulte la prévisualisation, accepte ou corrige.
6. La publication — après validation explicite, le merge et le déploiement automatiques en production.

Ce circuit est la garantie que l’IA ne fait que proposer. Le humain détient le bouton final. Rien n’est jamais publié sans une décision explicite.

Ce que cela change dans la pratique

Un agent ne remplace pas le propriétaire, il change ce que celui-ci doit faire.

Avant, préparer un article demandait de savoir où placer le fichier, quel format de front matter utiliser, lancer la commande de validation, corriger les erreurs, relancer le build. Tout cela relève de la bureaucratie du travail, et c’est exactement ce qu’un agent sait faire.

À la place, le propriétaire passe son temps sur ce qui compte vraiment : le sujet, la source, la clarté du texte, la décision de publier. L’agent se charge de la machinerie. Résultat : plus de friction entre l’idée et le rendu, et plus de cérémonie avant chaque publication.

Limites à garder en tête

Un agent est une aide, pas une vérité.

Il peut générer du texte cohérent et tenir pour vrai ce qui est faux. Il peut produire un fichier qui passe les vérifications mais ne répond pas à la demande. Il peut suivre la lettre d’une consigne en oubliant l’esprit. C’est pourquoi le circuit de publication inclut toujours un être humain : la revue, la décision, l’approbation.

Les agents peuvent aussi tourner trop loin. Un bout de code peut être généré et validé sans que personne n’ait bien compris pourquoi. Un article peut être structuré et sans sources. La trace Git existe, oui, mais une trace est une mention, pas une compréhension.

Il faut donc garder l’ordre des choses :

• D’abord vérifier, ensuite générer.
• D’abord demander, ensuite valider.
• D’abord lire, ensuite écrire.

Un outil pour un travail collaboratif

Hermes Agent ne veut pas remplacer le développeur ni le rédacteur. Il veut magasinner la machine. Il rend le travail reproductible : une idée, une commande, un dossier, un historique. Et il le rend observable : tout ce qui est fait est dans Git, tout ce qui est proposé est dans une pull request, tout ce qui est publié passe par une revue.

À l’usage, un agent ne fait pas l’ouvrier, il fait l’ouvrage. La main reste humaine, dans la décision de valider, de corriger, de laisser passer ou de partir.

Cette distinction, c’est celle que Refer cherche à illustrer : un journal où chaque article sort d’une conversation, d’un dépôt, et d’une revue. Pas d’IA devenue véritable, pas de publication automatique. Une machine qui travaille, et un humain qui décide.