« Erreur dans le flux de messages » dans ChatGPT — causes et solution

Les trois gestes des 90 premières secondes

Régénérer la réponse → recharger la page (sur mobile, fermer complètement l’application puis la rouvrir) → se déconnecter puis se reconnecter. Une coupure ponctuelle se résout avec l’un de ces trois gestes, et le cas ponctuel est le plus courant. Si, en revanche, la réponse s’arrête toujours exactement au même endroit, cela indique que l’une des causes précises ci-dessous agit, plutôt qu’un incident passager.

Déterminer d’abord si le problème vient de chez vous

C’est l’étape que les autres listes de solutions oublient, et celle qui fait gagner le plus de temps. Ouvrez status.openai.com. Si un incident est en cours, aucun réglage local ne le résoudra et attendre est la seule option. Si rien n’est indiqué, la cause est locale et l’étape suivante permettra de la circonscrire. Effectuer cette vérification avant de modifier les réglages évite de passer vingt minutes à vider les caches pendant une panne.

Isoler la cause locale de l’extérieur vers l’intérieur

Procédez dans cet ordre, car chaque couche écarte tout ce qui précède : (1) désactiver le VPN et le proxy ; (2) ouvrir une fenêtre privée — cela supprime les extensions et le cache en une seule fois ; (3) essayer un autre navigateur ou un autre appareil ; (4) changer de réseau. La couche à partir de laquelle le fonctionnement revient est la cause. Si l’erreur apparaît uniquement dans les fils longs, aucune des quatre n’est en cause : transférez l’essentiel dans une nouvelle discussion.

Pour les développeurs : la même interruption dans l’API

Lors d’un appel à l’API avec stream: true, cette même défaillance se manifeste par une connexion Server-Sent Events qui se termine sans finish_reason. L’état HTTP est 200 — tout fonctionnait lorsque les en-têtes ont été envoyés — ; vérifier uniquement le code d’état ne la détecte donc pas. Sous charge, vous verrez également 429 et 529 overloaded_error. Trois mesures la rendent gérable : (1) traiter un flux terminé sans finish_reason comme réessayable, et non comme une réponse complète ; (2) relancer les requêtes 429, 500 et 529 avec un backoff exponentiel et du jitter ; (3) si un proxy est interposé, vérifier son délai d’inactivité et désactiver la mise en tampon des réponses — un proxy qui met en tampon transforme un flux fonctionnel en long blocage. Pour circonscrire le problème, transmettez d’abord la requête sans proxy :

# Transmitir directamente, sin proxy por medio, y ver dónde se detiene.
curl -N https://api.kunavo.com/v1/chat/completions \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","stream":true,
       "max_tokens":300,
       "messages":[{"role":"user","content":"cuenta despacio del 1 al 20"}]}'

« Erreur dans le flux de messages » : est-ce ma faute ?

Presque jamais. Le message indique que la connexion qui transportait la réponse a été interrompue avant la fin. Ce que vous avez écrit n’en est pas la cause. Les causes sont une charge élevée du côté d’OpenAI, un réseau instable, une extension de navigateur ou une session expirée, ou encore un fil devenu suffisamment long pour que les réponses expirent.

Que faire si la régénération ne résout pas le problème ?

Consultez d’abord status.openai.com — pendant un incident, rien de local ne peut aider. S’il n’y a aucun incident, ouvrez une fenêtre privée sur un autre réseau : ce test unique retire simultanément les extensions, le cache et votre liaison habituelle. Si cela fonctionne, réintroduisez chaque élément jusqu’à ce que le problème réapparaisse. Si l’échec survient partout et uniquement dans une longue conversation, transférez l’essentiel dans une nouvelle discussion.

Cela arrive-t-il aussi avec d’autres IA ?

La formulation est propre à ChatGPT, mais tout assistant qui transmet les réponses en streaming peut être interrompu de la même manière. Claude affiche un message indiquant qu’il n’a pas pu générer la réponse complète ; lors d’un appel direct à l’API, cela apparaît comme un flux SSE qui se termine sans finish_reason, ou, sous charge, comme une erreur 529 overloaded_error.

Pourquoi cela se produit-il davantage dans les longues conversations ?

Chaque tour renvoie l’intégralité du fil ; une longue conversation implique donc une génération plus longue maintenue sur une seule connexion ouverte. Plus cette connexion reste ouverte, plus les occasions qu’un délai d’expiration de proxy, un changement de réseau ou un incident en amont l’interrompe sont nombreuses. Commencer une nouvelle discussion avec un résumé de l’essentiel améliore généralement davantage la situation que n’importe quel réglage du navigateur.