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

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 interruption ponctuelle est résolue par l’une de ces trois actions, et c’est le cas normal. Si la génération s’arrête exactement au même endroit à chaque fois, cela indique qu’une des causes précises ci-dessous agit, plutôt qu’un simple hasard.

Commencez par déterminer si le problème vient de vous

C’est l’étape que les autres listes de dépannage omettent, et celle qui fait gagner le plus de temps. Ouvrez status.openai.com. Si un incident est en cours, aucun réglage local ne changera quoi que ce soit et attendre est la seule solution. Si rien n’est signalé, la cause est locale et l’étape suivante permettra de la cerner. Effectuer cette vérification avant de modifier les paramètres évite de passer vingt minutes à vider le cache pendant une panne.

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

Suivez cet ordre, car chaque couche élimine toutes les causes situées au-dessus : (1) désactiver le VPN et le proxy ; (2) ouvrir une fenêtre privée — cela désactive en une fois les extensions et le cache ; (3) tester un autre navigateur ou appareil ; (4) changer de réseau. La couche à partir de laquelle le service refonctionne est la cause. Si l’erreur apparaît uniquement dans les conversations longues, aucune des quatre couches n’est responsable : transférez l’essentiel dans une nouvelle conversation.

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

Avec l’API et stream: true, la même panne se manifeste par une connexion Server-Sent Events qui se termine sans finish_reason. Le statut HTTP est 200 — tout fonctionnait au moment de l’envoi des en-têtes —, donc vérifier uniquement le code de statut ne suffit pas ; sous charge, des erreurs 429 et 529 overloaded_error peuvent également apparaître. Trois mesures rendent ce cas tolérable : (1) traiter un flux terminé sans finish_reason comme pouvant être relancé, et non comme une réponse complète ; (2) réessayer les erreurs 429, 500 et 529 avec un backoff exponentiel et du jitter ; (3) s’il y a un proxy sur le chemin, vérifier son délai d’inactivité et désactiver la mise en mémoire tampon des réponses — un proxy qui met les réponses en tampon transforme un flux fonctionnel en blocage prolongé. Pour délimiter le problème, transmettez d’abord sans proxy :

# Transmitir direto, sem proxy no caminho, e ver onde para.
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":"conte devagar de 1 a 20"}]}'

« L’erreur dans le flux de messages est-elle de ma faute ? »

Presque jamais. Le message indique que la connexion qui transportait la réponse a été interrompue avant sa fin. Ce que vous avez écrit n’en est pas la cause. Les causes sont une charge du côté d’OpenAI, un réseau instable, une extension du navigateur ou une session expirée, ou encore une conversation devenue assez longue pour que les réponses dépassent le délai imparti.

Et si régénérer la réponse ne suffit pas ?

Consultez d’abord status.openai.com : pendant un incident, aucune action locale ne vous aidera. S’il n’y a aucun incident, ouvrez une fenêtre privée sur un autre réseau : ce seul test désactive les extensions, efface le cache et élimine votre connexion habituelle en une fois. Si cela fonctionne, réintroduisez chaque élément jusqu’à reproduire l’erreur. Si l’échec se produit partout et uniquement dans une conversation longue, transférez l’essentiel dans une nouvelle conversation.

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

La formulation vient de ChatGPT, mais tout assistant qui transmet les réponses en streaming peut subir le même problème. Claude affiche un message indiquant qu’il n’a pas pu générer la réponse complète ; dans 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 arrive-t-il plus souvent dans les conversations longues ?

Chaque tour renvoie l’intégralité du fil ; une conversation longue implique donc une génération plus longue soutenue par une seule connexion ouverte. Plus cette connexion reste ouverte, plus un délai d’expiration du proxy, un changement de réseau ou un incident en amont risque de la rompre. Commencer une nouvelle conversation avec un résumé des éléments importants est généralement plus efficace que n’importe quel réglage du navigateur.