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

Les trois gestes des 90 premières secondes

Régénérer la réponse → recharger la page (sur mobile, quitter complètement l'application et la rouvrir) → se déconnecter puis se reconnecter. Une coupure ponctuelle est réglée par l'un de ces trois gestes, et ponctuel est le cas normal. Si en revanche ça s'arrête exactement au même endroit à chaque fois, c'est le signe qu'une des causes précises ci-dessous est en jeu, et non un aléa.

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

C'est l'étape que les autres listes de dépannage sautent, et celle qui fait gagner le plus de temps. Ouvrez status.openai.com. Si un incident est en cours, aucun réglage local n'y changera rien et attendre est la seule option. Si rien n'est signalé, la cause est locale et l'étape suivante la circonscrit. Faire cette vérification avant de toucher aux réglages évite de passer vingt minutes à vider des caches pendant une panne.

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

Procédez dans cet ordre, chaque étape écartant tout ce qui précède : (1) couper VPN et proxy ; (2) ouvrir une fenêtre de navigation privée — cela retire extensions et cache d'un seul geste ; (3) essayer un autre navigateur ou un autre appareil ; (4) changer de réseau. L'étape à partir de laquelle ça remarche désigne la cause. Si l'erreur n'apparaît que dans les longues conversations, aucune des quatre n'est en cause : reportez l'essentiel dans une nouvelle conversation.

Pour les développeurs : la même coupure côté API

En appelant l'API avec stream: true, la même panne se présente comme une connexion Server-Sent Events qui se termine sans finish_reason. Le statut HTTP est 200 — tout allait bien au moment d'envoyer les en-têtes — donc une vérification du seul code de statut ne la détecte pas ; sous charge s'y ajoutent 429 et 529 overloaded_error. Trois choses la rendent supportable : (1) traiter un flux terminé sans finish_reason comme à rejouer, pas comme une réponse complète ; (2) réessayer les 429, 500 et 529 avec un backoff exponentiel et du jitter ; (3) derrière un proxy, vérifier son idle timeout et désactiver la mise en tampon des réponses — un proxy qui tamponne transforme un flux qui marche en un long blocage. Pour circonscrire, streamez d'abord sans proxy :

# Streamer directement, sans proxy sur le chemin, et voir où ça s'arrête.
curl -N https://api.kunavo.com/v1/chat/completions \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-6","stream":true,
       "max_tokens":300,
       "messages":[{"role":"user","content":"compte lentement de 1 à 20"}]}'

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

Quasiment jamais. Le message indique que la connexion qui transportait la réponse a été coupée avant la fin. Ce que vous avez écrit n'en est pas la cause. Les causes sont la charge côté OpenAI, un réseau instable, une extension de navigateur ou une session expirée, ou une conversation devenue assez longue pour que les réponses expirent.

Que faire si régénérer ne suffit pas ?

Vérifiez d'abord status.openai.com — pendant un incident, rien de local n'aide. S'il n'y a pas d'incident, ouvrez une fenêtre privée sur un autre réseau : ce seul test retire d'un coup les extensions, le cache et votre liaison habituelle. Si ça marche, remettez chaque élément un par un jusqu'à ce que ça recasse. Si ça échoue partout et uniquement dans une longue conversation, reportez l'essentiel dans une nouvelle.

Est-ce que ça arrive sur d'autres IA ?

La formulation est celle de ChatGPT, mais tout assistant qui diffuse ses réponses en streaming peut casser de la même façon. Claude affiche un message indiquant qu'il n'a pas pu générer la réponse complète ; en appel direct à l'API, cela se présente comme un flux SSE qui se termine sans finish_reason, ou sous charge comme une 529 overloaded_error.

Pourquoi l'erreur revient-elle plus souvent dans les longues conversations ?

Chaque tour renvoie tout le fil, donc une longue conversation signifie une génération plus longue tenue sur une seule connexion ouverte. Plus cette connexion reste ouverte, plus un timeout de proxy, une bascule réseau ou un hoquet amont ont d'occasions de la rompre. Repartir d'une conversation neuve avec un résumé de l'essentiel change généralement plus les choses que n'importe quel réglage de navigateur.