Claude « presque en train de terminer de réfléchir » : signification et comment résoudre le problème

Si Claude est bloqué sur "almost done thinking" et que vous vous demandez si quelque chose est cassé — ce n’est pas le cas. Ce statut signifie que Claude est en extended thinking (son mode de raisonnement) : il prépare la réponse avant de commencer à écrire. Quelques secondes, voire 20 à 30 secondes, dans cet état, c’est normal. Ce qui n’est pas normal, c’est d’attendre des minutes sans rien recevoir en retour. Ce sont deux problèmes différents, et ce guide les distingue et vous donne la solution pour chacun.

Ce que signifie réellement « presque fini de réfléchir »

"Presque en train de terminer de réfléchir" est l’étiquette que Claude affiche pendant l’exécution de son passage de raisonnement étendu. Au lieu de répondre immédiatement, jeton par jeton, le modèle consacre un budget de jetons de "réflexion" à élaborer un plan, puis produit la réponse visible. C’est le même mécanisme qui se cache derrière "réfléchir avec un effort élevé" dans Claude Code et les indicateurs de raisonnement dans les applications Claude.

La façon la plus claire de l’interpréter : l’expression est un signal de progression, pas une erreur. Comme l’exprime un fil r/ClaudeCode, la pause de raisonnement prolongé est « Claude qui planifie avant d’exécuter, pas un problème de serveur ». Donc, quand vous voyez claude presque en train de finir de réfléchir, le modèle travaille — la seule question est de savoir s’il travaille trop longtemps.

Une ligne approximative à tracer :

Secondes à ~30 s de réflexion → normal, surtout pour les tâches de raisonnement complexe ou de codage.
Des minutes sans aucune sortie, à répétition → quelque chose ne va pas ; passez directement aux corrections ci-dessous.

Pourquoi cela prend si longtemps (ou se bloque complètement)

La lenteur et un véritable blocage ont des causes différentes. Trois choses provoquent le cas de lenteur :

Profondeur de réflexion étendue. Lors d’une recherche rapide, Claude peut avoir tendance à fournir plus d’effort de raisonnement que nécessaire pour la tâche — il « réfléchit » intensément à une question qui n’en avait pas besoin.
Appels d’outils séquentiels. Dans une utilisation agentique (Claude Code), la majeure partie du temps écoulé ne vient pas du raisonnement du modèle — ce sont les appels d’outils. Une analyse de la latence de Claude Code a mesuré chaque lecture de fichier, recherche ou exécution de test à environ 300–800 ms comme aller-retour synchrone, et note qu’ils ne s’exécutent pas en parallèle par défaut — ainsi, une invite vague qui déclenche une douzaine d’appels exploratoires additionne ces allers-retours en plus de dix secondes avant que le vrai travail ne commence.
Encombrement du contexte. L’intégralité de la transcription est renvoyée au modèle à chaque tour. À mesure qu’une session se remplit, les réponses ralentissent et la qualité baisse — la même analyse a observé un ralentissement notable une fois qu’une session dépasse environ 60% de la fenêtre de contexte, bien que le point exact varie (c’est l’effet « perdu au milieu » sur les détails enfouis au fond de la conversation).

Le vrai blocage est un échec distinct. Un problème suivi de Claude Code (#32526) décrit de nouvelles sessions qui restent bloquées sur « thinking » et ne produisent jamais de sortie — aucune erreur, même pour un simple « hello » — tandis qu’une session déjà ouverte continue de fonctionner correctement. Ce signalement provenait d’une configuration lourde : de nombreux hooks PreToolUse, plusieurs serveurs MCP, plus de 80 compétences enregistrées et un fournisseur personnalisé (Bedrock). Si la vôtre ne renvoie jamais le moindre token, considérez cela comme un blocage, pas comme de la lenteur.

Comment le corriger

Corrections rapides (essayez-les d’abord)

/clear pour effacer la conversation et repartir à zéro — le remède le plus rapide contre l’encombrement du contexte.
/compact pour résumer et réduire le contexte. Notez que c’est volontairement avec perte, alors enregistrez d’abord tout élément important dans un fichier.
Redémarrez la session, ou revenez à une session plus ancienne qui répond encore — la solution de contournement vers laquelle la plupart des utilisateurs se tournent en cas de blocage.

Contrôlez le niveau d'effort

Le levier de vitesse le plus souvent négligé est l’effort. Claude a tendance à se régler par défaut sur un raisonnement élevé/maximal ; adapter l’effort à la tâche permet d’obtenir de grands gains de vitesse sans perte de qualité sur les tâches courantes. Une fiche pratique :

Tâche	Effort	Pourquoi
Recherche rapide, résumé, mise en forme	`low`	Aucun raisonnement approfondi nécessaire ; quasi instantané
Codage standard, rédaction	`medium`	Équilibré
Architecture, débogage difficile, math	`high` / `xhigh`	Ça vaut l'attente

Si l’opacité vous gêne (Claude masque les détails de réflexion par défaut), Claude Code peut afficher un résumé de réflexion afin que vous puissiez au moins voir ce qu’il est en train de faire.

Quand c’est vraiment bloqué, pas seulement lent

Si vous obtenez zéro sortie, c'est un blocage, pas de la profondeur :

Réduisez la charge au démarrage — désactivez temporairement les hooks PreToolUse supplémentaires, les serveurs MCP inutilisés et les skills, puis rouvrez la session.
Vérifiez votre fournisseur — les IDs de modèle personnalisés et les passerelles (Bedrock et similaires) apparaissent dans un certain nombre de rapports de blocage.
Exécutez avec --verbose pour voir ce qu'il fait réellement : une longue série de lectures de fichiers indique un problème d'appel d'outil ; une première réponse lente sans appels d'outil indique une latence ou le contexte.

Avancé : contrôler la réflexion depuis l’API

Les applications vous offrent un contrôle limité sur la réflexion. L'API vous donne ce contrôle directement — et c'est la solution pratique si vous avez besoin d'une latence prévisible. Les mêmes niveaux d'effort de la fiche mémo ci-dessus sont un paramètre de l'API, et vous pouvez également désactiver complètement la réflexion étendue :

message = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=4096,
    thinking={"type": "adaptive"},        # Claude décide combien réfléchir
    output_config={"effort": "low"},      # low | medium | high | max — plafonne la profondeur
    # ou, pour ignorer complètement la réflexion étendue :
    # thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "..."}],
)

Sur les modèles Claude actuels (Opus 4.6 et plus), vous ne définissez pas un budget fixe de tokens — vous définissez un niveau d’effort (low pour un travail rapide, jusqu’à max), ou vous désactivez complètement la réflexion étendue. C’est le même levier que les applications masquent, exposé sous forme de paramètre que vous contrôlez. (Consultez la documentation officielle sur la réflexion étendue pour la référence actuelle — les noms des paramètres peuvent changer selon les versions du SDK, alors vérifiez celle que vous utilisez.)

Tout point de terminaison compatible avec Anthropic peut effectuer ces appels — l’API officielle, ou un miroir compatible comme AIReiter, où la requête ci-dessus fonctionne sans modification. Le choix de l’un ou de l’autre importe moins que l’enseignement à retenir : le contrôle du raisonnement se situe au niveau de l’API, et les applications ne l’exposent pas.

Claude « devient-il moins bon » ?

C’est la question qui se cache derrière la plupart des recherches « why is claude almost done thinking forever », et la réponse honnête est : en général, ce n’est pas permanent. Une grande partie de la régression perçue est attribuable à des changements de comportement par défaut — des ajustements côté serveur des budgets de réflexion, ou des valeurs par défaut plus prudentes déployées dans les mises à jour — plutôt qu’au fait que le modèle soit devenu moins intelligent. Il y a beaucoup d’échanges dans la communauté à ce sujet, et la conclusion qui revient sans cesse est la même : l’expérience s’améliore une fois que vous reprenez le contrôle — définissez le niveau d’effort, nettoyez les sessions surchargées, et fournissez des prompts structurés. Si Claude vous semble moins bon cette semaine, changez ces trois choses avant d’en conclure qu’il est cassé.

FAQ

Que signifie « almost done thinking » ?

Cela signifie que Claude est en mode de raisonnement étendu, en train d’élaborer un plan avant d’écrire la réponse — un état d’avancement normal, pas une erreur. Cela signale un problème uniquement lorsqu’il ne se résout jamais.

Pourquoi Claude met-il autant de temps à réfléchir ?

Trois causes habituelles : un niveau d'effort par défaut élevé, des appels d'outils séquentiels lents (~300–800 ms chacun) dans les sessions agentiques, et une fenêtre de contexte surchargée. Réduire le niveau d'effort, diminuer le nombre d'appels d'outils et effacer le contexte peuvent tous aider.

Claude reste-t-il parfois bloqué en train de réfléchir ?

Oui — distinct de la lenteur. De nouvelles sessions peuvent rester bloquées sur « thinking » et ne jamais renvoyer de sortie, souvent lié à des configurations lourdes de hook/MCP/skill ou à des fournisseurs personnalisés. Redémarrez la session ou revenez à une session fonctionnelle.

Claude ne termine pas la réponse — que dois-je faire ?

Traitez-le comme un blocage : /clear ou redémarrez, réduisez la charge de démarrage et vérifiez votre fournisseur. Si c’est lent plutôt que bloqué, baissez le niveau d’effort et réduisez le contexte.

Puis-je faire penser Claude plus vite ?

Oui. Définissez low/medium pour les tâches routinières, gardez les sessions courtes, et pour un contrôle total appelez l'API avec un niveau d'effort inférieur ou le raisonnement étendu désactivé.