Le mode background d'Hermes : utile, imprévisible, parfois en boucle
Le mode /bg d'Hermes rend un vrai service : lancer une tâche et récupérer la main. Mais trois expériences distinctes m'ont appris qu'un résultat qui revient tout seul doit d'abord être mis à l'épreuve avant d'être cru. Cinquième article de la série.
Par Nicolas Cousin — Publié le 13 octobre 2026
Le mode background d'Hermes : utile, imprévisible, parfois en boucle
TL;DR
L'article précédent a mesuré à quel point le local sur CPU est lent pour
de l'interactif. Le mode background d'Hermes (/bg) change la donne : la
tâche tourne dans une session séparée, et je récupère la main
immédiatement. Trois expériences distinctes avec ce mode m'ont appris trois
choses différentes : c'est un vrai usage pour la veille et le batch, un
même prompt peut donner deux résultats différents d'une exécution à
l'autre, et un agent livré à lui-même peut boucler indéfiniment sur ses
propres outils. Un résultat qui revient tout seul ne mérite pas une
confiance automatique.
Sommaire
- Une session qui tourne pendant que je fais autre chose
- Même prompt, deux résultats différents
- Quand Hermes boucle sur ses propres outils
- Ce qui relie ces trois expériences
Une session qui tourne pendant que je fais autre chose
/bg <prompt>
Hermes lance la tâche dans une session séparée et rend la main immédiatement, au lieu de me faire attendre devant un terminal pendant que le modèle traite le prompt. C'est la première fois que la lenteur du CPU local, mesurée dans l'article précédent, cesse d'être un problème en soi : elle devient un délai que je n'ai plus besoin de regarder passer.
Les cas d'usage qui en profitent sont ceux où la réponse n'a pas besoin d'être immédiate et où je peux juger le résultat après coup plutôt que pendant : veille technologique, synthèse de documents, génération de tests, classification, enrichissement de contenu, transformations batch. Le point commun entre ces usages, c'est qu'une réponse en retard de quelques minutes ne coûte rien, alors qu'elle coûterait cher en usage interactif. L'idée centrale : lent, local et en arrière-plan peut rester économiquement intéressant, précisément parce que je n'ai plus à regarder l'horloge.
Reste une question que cette première expérience ne pose pas encore : peut-on faire confiance au résultat qui revient, sans l'avoir vu se construire ?
Même prompt, deux résultats différents
Première réponse à cette question, et elle n'est pas rassurante. Deux
/bg lancés séparément, même modèle, même prompt, même type de recherche
web attendue : un des deux résultats affirme que .NET 10 est encore en
développement, l'autre trouve correctement .NET 10, F# 10 et les sources
officielles.
Rien dans le prompt n'explique cet écart. Les causes possibles sont
multiples et je n'ai pas isolé laquelle domine : résultats DuckDuckGo
différents d'une recherche à l'autre, ordre de ces résultats, sampling du
modèle, décisions de tool calling qui divergent d'une exécution à l'autre
sans que l'agent perde le contrôle pour autant (contrairement à ce qu'on
verra juste après), trajectoire agentique différente. Ce qui compte pour
la suite, ce n'est pas la cause exacte, c'est la conséquence : le mode
background ne peut pas se contenter de renvoyer une réponse, il doit être
entouré d'une chaîne qui la met à l'épreuve. Pour une veille technique
fiable, la séquence que je retiens est : Search → collecte → validation → synthèse → contrôle, pas Search → réponse.
Quand Hermes boucle sur ses propres outils
Deuxième limite, plus radicale que la première : ici, l'agent ne se
trompe pas silencieusement, il ne s'arrête plus du tout. Hermes a
déclenché un garde-fou intégré (loop_web_search_cap), pas un réglage que
j'avais posé moi-même, après 50 appels web_search sans progression.
Laissé sans limite explicite dans le prompt, l'agent a continué à chercher
au lieu de s'arrêter et de synthétiser ce qu'il avait déjà trouvé.
À la différence de la variabilité du paragraphe précédent, celle-ci a une cause identifiable : l'absence de contrainte explicite dans le prompt. Les garde-fous qui règlent le problème sont simples à énoncer, mais doivent être écrits, pas supposés :
Utilise web_search au maximum 5 fois.
Ne répète jamais une recherche identique.
Après les recherches, arrête d'utiliser les outils.
Un nombre maximal d'appels, l'interdiction de requêtes identiques et une condition d'arrêt explicite : sans ces trois éléments, rien n'empêche un agent en arrière-plan de tourner indéfiniment sur lui-même pendant que je suis parti faire autre chose, ce qui est précisément le moment où je ne suis pas là pour l'interrompre.
Ce qui relie ces trois expériences
Ces trois expériences ne sont pas trois incidents séparés à cocher, ce sont trois réponses à la même question posée en ouverture : que se passe-t-il quand personne ne regarde l'agent travailler ? Le mode background résout le problème de latence mesuré dans l'article précédent, mais seulement si deux autres problèmes distincts sont explicitement traités, pas juste constatés : la fiabilité du résultat, qui demande une chaîne de validation plutôt qu'une confiance par défaut, et la capacité de l'agent à savoir s'arrêter, qui demande des limites écrites dans le prompt plutôt que supposées. Ce ne sont pas la même chose : la première touche à la justesse de ce que l'agent trouve, la seconde à sa capacité à reconnaître qu'il doit cesser de chercher. Le gain de temps du background ne vaut que si le résultat qu'il produit peut être vérifié sans avoir dû surveiller tout le trajet pour y arriver.