OpenClaw ne répond pas : comment en trouver la cause

Vous envoyez un message et rien ne revient. Un assistant auto-hébergé a quatre endroits où une réponse peut se perdre, et ils paraissent identiques depuis la fenêtre de discussion. Les tester dans l'ordre prend environ cinq minutes et transforme un bot muet en un défaut précis et réparable.

Les quatre couches

Avant de modifier quoi que ce soit, sachez ce que vous testez. Un message traverse ces quatre couches, et n'importe laquelle peut l'avaler sans qu'aucune erreur ne vous parvienne :

1. L'instance. OpenClaw tourne-t-il réellement sur votre serveur ?
2. Le fournisseur de modèle. Le modèle de langage accepte-t-il vos requêtes ?
3. L'intégration de discussion. Le message atteint-il seulement OpenClaw ?
4. Le chemin réseau. Pouvez-vous, ainsi que la plateforme, joindre l'instance ?

Un seul test divise immédiatement le problème en deux : envoyez un message dans l'interface web d'OpenClaw. Si vous obtenez une réponse, les couches un et deux fonctionnent et le problème vient de l'intégration. Sinon, arrêtez de regarder le bot.

Couche 1 : l'instance tourne-t-elle ?

Ouvrez votre tableau de bord Flux et vérifiez que l'instance est active et ne redémarre pas en boucle. Un conteneur qui meurt et revient sans cesse est la forme la moins évidente de ce problème, car le service semble présent entre deux redémarrages.

La cause habituelle d'une boucle de redémarrage est la mémoire. Si vous avez pointé OpenClaw vers un modèle local plutôt qu'une API hébergée, les poids du modèle doivent tenir dans la même RAM que le reste. Un modèle 7B quantifié en 4 bits pèse environ 4 GB à lui seul, avant tout contexte de conversation et avant le processus de l'assistant. Sur l'offre à 4 GB, cela ne peut pas fonctionner, et l'offre à 8 GB est le minimum réaliste pour l'inférence locale. Vous pouvez soit passer à une offre supérieure, soit pointer l'assistant vers un modèle hébergé, où le gros du calcul se fait sur le matériel du fournisseur et votre instance n'a besoin que de conserver la conversation.

Si vous n'arrivez pas du tout à joindre l'interface web, notez-le et passez à la couche quatre avant de supposer que l'instance est en panne.

Couche 2 : le fournisseur de modèle vous rejette-t-il ?

OpenClaw est indépendant du modèle et vous apportez votre propre clé, ce qui signifie que le silence le plus courant n'a rien à voir avec OpenClaw. Quatre défaillances côté fournisseur produisent un assistant qui cesse de répondre, et depuis la fenêtre de discussion elles sont indiscernables :

• La clé est invalide ou a été régénérée. Les clés sont révoquées, recréées et collées avec un espace en trop. Recollez-la au lieu de la lire et de conclure qu'elle a l'air correcte.
• Le solde de crédit est épuisé. Les comptes à l'usage cessent de traiter les requêtes dès que le solde tombe à zéro, sans aucun avertissement dans votre assistant.
• Vous êtes limité en débit. Les nouveaux comptes chez tous les grands fournisseurs disposent de paliers à faible nombre de requêtes par minute. Une rafale de messages, ou une boucle d'agent qui appelle le modèle en continu, atteindra ce plafond, et chaque requête rejetée ne renvoie rien d'utile au chat.
• Le nom du modèle n'existe plus. Les fournisseurs retirent leurs identifiants de modèles, et une configuration écrite il y a des mois peut pointer vers un modèle depuis retiré. La requête échoue comme un mauvais modèle plutôt que comme une mauvaise clé, ce qui prête à confusion.

Consultez le tableau de bord du fournisseur : ses pages d'utilisation, de facturation et de limites de débit vous indiquent en quelques secondes laquelle de ces quatre situations vous concerne, et toutes se règlent chez le fournisseur et non dans OpenClaw.

Couche 3 : l'intégration de discussion

Si l'interface web répond et que le bot ne répond pas, le message n'arrive jamais. Chaque plateforme a une cause dominante qu'il vaut la peine de connaître.

Telegram : le mode confidentialité

Les bots créés via BotFather ont le mode confidentialité activé par défaut. Dans un groupe, un bot dans cet état ne reçoit que les messages commençant par une commande slash, ou qui répondent au bot ou le mentionnent directement. Tout le reste n'est jamais transmis à votre serveur : votre assistant n'ignore donc pas les gens, il ne les a tout simplement jamais entendus. C'est pourquoi le même bot répond parfaitement à vos messages privés et paraît mort dans un groupe.

Pour corriger cela, envoyez un message à BotFather, ouvrez les paramètres du bot et désactivez le mode confidentialité du groupe. Retirez ensuite le bot du groupe puis rajoutez-le, car le paramètre s'applique au moment où le bot rejoint le groupe.

Discord : le Message Content Intent

Depuis 2022, Discord traite le texte des messages comme une donnée privilégiée. Un bot sans le Message Content Intent activé reste connecté, apparaît toujours en ligne et reçoit des événements de message dont le contenu est vide. Le résultat est un bot manifestement actif qui ne réagit à absolument rien.

Activez-le dans le Discord Developer Portal, sous votre application, puis Bot, Privileged Gateway Intents, et redémarrez l'intégration. Pendant que vous y êtes, vérifiez que le bot a la permission de lire et d'envoyer des messages dans le salon précis : les réglages au niveau du salon l'emportent discrètement sur les rôles au niveau du serveur, et un bot qui a la permission sur le serveur peut rester muet dans un salon.

WhatsApp : la session

Les connexions WhatsApp sont liées à une session liée et non à un jeton permanent. Or les sessions expirent, sont déconnectées depuis le téléphone, ou cassent lorsque l'appareil reste hors ligne longtemps. Une intégration WhatsApp muette est le plus souvent une session à relier de nouveau. Rescannez le code et testez à nouveau avant de chercher ailleurs.

Toutes les plateformes : le jeton lui-même

Quelle que soit la plateforme, vérifiez que le jeton affiché dans votre tableau de bord est le bon. Régénérer un jeton de bot dans la console de la plateforme invalide immédiatement l'ancien, et il est très facile de régénérer un jeton en cherchant autre chose puis d'oublier de coller le nouveau.

Couche 4 : le chemin réseau

Si vous accédez à OpenClaw via Tailscale, l'assistant peut être parfaitement en bonne santé alors que vous ne pouvez tout simplement pas l'atteindre. Les clés d'authentification expirent, et les clés d'appareil aussi : une instance qui tourne sans être touchée depuis des mois peut disparaître de votre tailnet sans qu'aucune erreur ne soit apparue. Vérifiez la console d'administration Tailscale et confirmez que l'appareil est toujours listé et autorisé. Sinon, générez une nouvelle clé d'authentification puis redéployez ou reconnectez.

Cette couche explique un schéma qui prête à confusion : le bot continue de répondre dans le chat alors que l'interface web reste inaccessible pour vous. L'instance va bien et tourne ; seule votre route vers elle est coupée.

Il répond, mais mal

Une réponse lente ou tronquée est un problème différent du silence, et il s'agit en général de l'une de deux causes. Les longues conversations finissent par dépasser la fenêtre de contexte du modèle : les requêtes commencent alors à échouer ou l'assistant perd la première partie du fil. Commencer une nouvelle conversation est la solution immédiate. Par ailleurs, un grand modèle local sur un matériel modeste est tout simplement lent, et une réponse qui prend une minute peut expirer quelque part dans la chaîne avant d'être livrée. Si vous avez besoin de rapidité sur une petite instance, un modèle hébergé battra toujours un modèle local.

La liste de contrôle en cinq minutes

1. Envoyez un message dans l'interface web d'OpenClaw. Une réponse là-bas signifie que le problème vient de l'intégration ; l'absence de réponse signifie que le problème vient de l'instance, du fournisseur ou de votre accès à celle-ci.
2. Vérifiez l'instance dans votre tableau de bord Flux pour une boucle de redémarrage, et la RAM si vous utilisez un modèle local.
3. Vérifiez dans le tableau de bord du fournisseur de modèle une clé invalide, un solde vide, une limite de débit ou un nom de modèle retiré.
4. Pour Telegram, désactivez le mode confidentialité dans BotFather et rajoutez le bot au groupe.
5. Pour Discord, activez le Message Content Intent et vérifiez les permissions au niveau des salons.
6. Pour WhatsApp, reliez de nouveau la session.
7. Si l'interface web est inaccessible mais que le chat fonctionne, vérifiez dans Tailscale qu'un appareil ou une clé d'authentification n'a pas expiré.

Presque tous les cas se règlent aux étapes un, trois ou quatre. Le schéma à retenir : un assistant auto-hébergé a plus de pièces mobiles qu'un service SaaS précisément parce que vous les possédez, et les posséder signifie que la panne peut toujours être localisée.

Pour aller plus loin

Vous débutez avec l'un de ces outils ? Commencez par le guide d'auto-hébergement d'OpenClaw, ou lisez sur le choix d'un modèle d'IA si vous hésitez entre un fournisseur hébergé et un modèle local. Pour les intégrations elles-mêmes, voir Telegram, Discord et WhatsApp.