Un agent n8n reçoit un 200 OK, mais le client voit un chat vide : analyse d'un bug du silence

Des nœuds verts, un 200 OK de Meta et un chat vide côté cliente. Voilà à quoi ressemble le deuxième « bug du silence » d'un agent IA sur n8n, objet d'une analyse récente publiée sur Habr. C'est déjà la deuxième histoire de ce type chez l'auteur, et la formulation dit l'essentiel : le système estimait avoir fait son travail, alors que la personne est restée sans réponse. L'annonce est brève ; ce qui suit se limite donc à ce qu'elle affirme, et aux mécanismes généraux qui provoquent ce genre de situation dans les agents de messagerie.

Ce que l'on sait de l'analyse

L'annonce contient peu de faits, mais ils sont parlants. Le workflow n8n s'est exécuté sans erreur : chaque nœud est passé au vert. La requête vers l'API de Meta a renvoyé 200 OK. Pourtant, l'utilisatrice n'a pas vu la réponse de l'agent, et le chat était vide. L'annonce ne précise ni le canal concerné ni l'endroit de la chaîne où le texte a disparu. Les détails figurent dans la version complète de l'article sur Habr.

Pour les agents IA, c'est le type de défaillance le plus pénible. Il n'y a aucune exception, aucune alerte ne se déclenche, les logs sont propres. On ne découvre le problème que par le client lui-même, s'il n'est pas déjà parti.

Où le silence se cache d'ordinaire

Ce symptôme a plusieurs causes typiques. On ignore laquelle a joué ici, mais toutes produisent le même tableau : « tout est vert, pas de réponse ».

• Un code 200 signifie réception, pas livraison. Les API de messagerie placent généralement le message dans une file et communiquent le sort de la livraison plus tard, via des webhooks de statut distincts.
• Une sortie du modèle vide ou corrompue. Un LLM peut renvoyer une chaîne vide, un JSON tronqué ou un marqueur technique à la place du texte. Pour n8n, ce sont des données valides, et le nœud d'envoi s'exécute normalement.
• Les restrictions de la plateforme. Les messageries imposent des fenêtres de réponse, des exigences sur les modèles de messages et des règles de modération. Un message peut être accepté sans jamais être affiché à l'utilisateur.
• Un mauvais champ dans l'expression. Si le nœud d'envoi prend le texte à un chemin qui n'existe pas dans les données, n8n insère une valeur vide sans lever d'erreur.
• Les accès concurrents et les doublons. Des webhooks répétés, des exécutions parallèles et une mémoire de conversation partagée peuvent écraser la réponse avant son envoi.

Tous ces cas ont un point commun : le succès est mesuré du côté de l'infrastructure, et non du côté de l'humain.

Comment détecter ces bugs

Première mesure : ajouter une vérification du contenu avant l'envoi. Un simple nœud de filtrage qui écarte les chaînes vides, les textes trop courts ou ceux qui contiennent des marqueurs techniques élimine toute une classe d'erreurs. Si la vérification échoue, le workflow doit basculer sur une branche d'erreur au lieu de poursuivre son chemin au vert.

Deuxième mesure : ne pas considérer 200 OK comme l'étape finale. Il faut enregistrer les statuts de livraison reçus par webhook et les rapprocher des messages sortants grâce à l'identifiant. Tout message sans confirmation de « livraison » après un délai donné devient un incident.

Troisième mesure : instaurer une métrique au niveau de la conversation. La part des messages entrants pour lesquels aucune réponse non vide n'est partie en N secondes reflète l'état réel de l'agent mieux que les statistiques d'exécutions réussies. C'est aussi la base d'une alerte dans le chat de travail de l'équipe.

Quatrième mesure : configurer un Error Workflow dans n8n, ainsi qu'un fallback dédié. Si l'agent reste muet, le client reçoit un court « Nous avons bien reçu votre message, nous vous répondrons dans les meilleurs délais », et l'opérateur reçoit une notification accompagnée du contexte de la conversation.

Cinquième mesure : lancer des conversations synthétiques. Un compte de test qui écrit régulièrement à l'agent et attend la réponse détecte le silence avant les utilisateurs réels. Pour une entreprise dont le chat avec le bot est le principal canal de vente ou de support, ce contrôle coûte moins cher qu'une seule demande perdue.

L'histoire publiée sur Habr illustre bien une leçon générale sur l'exploitation des agents : la fiabilité se mesure à ce que l'utilisateur a vu, pas à ce qu'affiche le tableau de bord de l'orchestrateur.