Hermes Agent ne répond pas

Un test qui divise le problème par deux

Ouvrez le tableau de bord Hermes et posez à l’agent une question banale qui ne nécessite aucun outil. Ce qui se passe ensuite divise les cinq causes en deux groupes, et vous évite de déboguer la mauvaise moitié.

• Vous obtenez une réponse. L’instance tourne et le fournisseur du modèle accepte les requêtes. Votre problème vient de l’appel d’outils ou de la tâche elle-même, et non de la configuration.
• Vous obtenez une erreur. Le fournisseur vous refuse : clé invalide, solde vide, limite de débit ou nom de modèle retiré.
• Rien ne se passe, ou la page ne se charge pas. Soit l’instance est en panne, soit votre accès à elle l’est. Ce sont deux pannes différentes avec des correctifs différents, expliqués ci-dessous.

L’instance tourne-t-elle vraiment ?

Vérifiez l’instance dans votre tableau de bord Flux plutôt que de juger d’après l’interface de l’agent, car un conteneur bloqué dans une boucle de redémarrage paraît parfois vivant par intermittence. Les causes habituelles sont la mémoire et une tâche longue qui ne s’est jamais terminée.

La mémoire est le premier point à vérifier si vous êtes passé au-delà d’un usage léger. L’offre à 4 GB convient à un agent personnel qui fait des tâches planifiées et ponctuelles, mais c’est la concurrence qui consomme la RAM : plusieurs tâches en même temps, une longue exécution de recherche en plusieurs étapes avec un gros ensemble de travail, ou une tâche qui télécharge et traite des fichiers. Si votre usage a changé de forme et que l’agent a commencé à tomber, c’est l’offre à 8 GB qui signale qu’elle est nécessaire, et non un défaut.

Un cas voisin est celui d’un agent qui se bloque au lieu de planter. Une boucle d’agent qui attend un outil qui ne répond jamais, par exemple un appel réseau vers un service en panne, reste bloquée indéfiniment et ressemble exactement à un agent mort. Redémarrer l’instance la débloque, et l’historique d’exécution indique en général l’étape où il s’est arrêté.

La clé du fournisseur, le solde et le nom du modèle

Hermes fonctionne avec votre propre clé : le silence le plus fréquent vient donc de votre fournisseur d’IA et non de l’agent. Quatre pannes produisent le même symptôme, et toutes les quatre se corrigent côté fournisseur :

Recollez la clé au lieu de la relire et de décider qu’elle semble correcte. Une espace en fin de chaîne passe un contrôle visuel mais fait échouer chaque requête.

Les limites de débit frappent les agents plus durement que les chatbots

Cette question mérite sa propre section, car les agents atteignent très facilement les limites. Un assistant de chat fait une requête par message humain. Un agent fait une requête par étape de sa boucle de raisonnement, et une tâche en plusieurs étapes peut produire des dizaines d’appels en une minute, sans que vous fassiez quoi que ce soit.

OpenRouter est un choix courant pour Hermes, et son offre gratuite rend l’effet concret. Les variantes gratuites de modèles, dont l’identifiant se termine par :free, sont limitées à 20 requêtes par minute, et le quota journalier est de 50 requêtes si vous avez acheté moins de $10 de crédits au total sur le compte, puis monte à 1000 par jour une fois ce seuil atteint. Un agent qui traite une tâche de recherche peut épuiser 50 requêtes quotidiennes en une seule exécution, et il s’arrête alors au milieu de la tâche sans explication évidente.

Si votre agent termine les tâches courtes mais échoue systématiquement sur les longues, c’est presque certainement la cause. La solution est soit une variante payante du modèle, soit accepter ce plafond et garder des tâches réduites. Un rechargement ponctuel relève le plancher quotidien ; il ne relève pas la limite par minute, de sorte qu’une boucle très bavarde peut toujours atteindre 20 requêtes par minute, quelle que soit la somme dépensée.

L’agent parle mais n’agit jamais

C’est une panne que l’on diagnostique rarement correctement, car rien ne produit d’erreur. L’agent répond avec fluidité, décrit ce qu’il va faire, puis ne le fait tout simplement pas. Aucun outil ne s’exécute, aucun fichier n’apparaît, rien ne se passe en dehors de la conversation.

La cause, c’est le modèle. Un agent fonctionne en demandant au modèle d’émettre un appel d’outil structuré, et tous les modèles ne le supportent pas. Si vous orientez Hermes vers un modèle sans appel d’outils, vous obtenez un interlocuteur conversationnel compétent, mais discrètement privé de sa capacité d’action. Ce n’est pas cassé : il n’a simplement pas de mains.

Vérifiez que le modèle choisi annonce l’appel d’outils ou de fonctions parmi ses capacités, et privilégiez un modèle que le fournisseur documente explicitement pour un usage agentique. C’est aussi pourquoi le modèle le moins cher est souvent une fausse économie pour un agent : la capacité à suivre fiablement un protocole d’appel d’outils compte bien plus que le prix brut par token, puisque l’intérêt même est que l’agent exécute.

Une version plus subtile du même problème est un modèle qui supporte l’appel d’outils mais le fait de façon peu fiable, en produisant des appels mal formés qui échouent silencieusement et sont relancés. Si votre agent fonctionne à moitié et que l’historique d’exécution est plein de tentatives répétées sur la même étape, essayez un modèle plus performant avant de supposer que la tâche est en cause.

Quand l’agent fonctionne mais que vous ne pouvez pas l’atteindre

Hermes embarque un maillage Tailscale pour que l’agent puisse atteindre votre réseau privé, et de nombreuses personnes utilisent ce même maillage pour atteindre le tableau de bord. Cela crée un mode de panne où l’agent est parfaitement sain, ses tâches planifiées tournent toujours, et vous n’avez tout simplement aucun chemin pour l’atteindre.

Les clés d’authentification expirent, et les clés d’appareil aussi : une instance inutilisée pendant des mois peut donc disparaître du tailnet sans qu’aucune erreur ne soit survenue. Vérifiez la console d’administration Tailscale : si l’appareil est absent ou non autorisé, générez une nouvelle clé d’authentification et reconnectez-le. L’indice de cette cause est que les tâches planifiées ont continué de tourner alors que le tableau de bord était injoignable.

L’image inverse est aussi utile à connaître. Si l’agent peut atteindre le tableau de bord mais pas vos services internes, le maillage fonctionne pour vous et ne fonctionne pas pour lui, ce qui signifie en général que l’appareil a perdu son autorisation, et non que les services ont changé d’adresse.

La liste de contrôle

1. Posez à l’agent une question banale dans le tableau de bord. Une réponse valide à la fois l’instance et le fournisseur en une seule étape.
2. Vérifiez l’instance dans votre tableau de bord Flux pour une boucle de redémarrage, et contrôlez la RAM si votre charge a augmenté.
3. Vérifiez dans le tableau de bord du fournisseur une clé invalide, un solde vide, une limite de débit ou un nom de modèle retiré.
4. Si les longues tâches échouent et que les courtes réussissent, supposez une limite de débit et vérifiez votre quota journalier avant tout le reste.
5. Si l’agent parle mais n’agit jamais, vérifiez que le modèle choisi supporte l’appel d’outils.
6. Si le tableau de bord est injoignable alors que les tâches planifiées ont continué de tourner, vérifiez dans Tailscale si un appareil ou une clé d’authentification a expiré.

Presque tous les cas tombent sur les étapes un, trois ou cinq. Un agent a plus de points de défaillance qu’un assistant de chat, parce qu’il fait davantage, et chacun laisse une empreinte différente.