Pourquoi une IA ne répond jamais deux fois pareil, et que change le mode réflexion ?

Vous l’avez certainement remarqué, votre chatbot ne répond jamais de la même façon à une même question. D’un côté, il y a une part de hasard dans le choix des mots que les éditeurs dosent avec des réglages. De l’autre, on retrouve des modèles dits "de raisonnement", avec une phase de réflexion que l’on paie sans toujours la voir.

Que se passe-t-il vraiment entre votre question et la réponse retournée par un chatbot IA ? Et à quoi servent ces réglages ?

Comment une IA écrit sa réponse : un morceau de mot après l’autre, à la loterie

Un assistant comme ChatGPT ou Claude ne possède pas de réponse toute faite. Il l’écrit morceau par morceau. Ou plutôt token par token. Ce dernier peut être un mot, une partie de mot ou un signe de ponctuation. À chaque étape, le modèle doit deviner lequel vient ensuite.

Nous détaillons ce mécanisme dans un dossier sur les paramètres d'IA. Le modèle calcule un score pour chaque token de son vocabulaire, convertit ces scores en probabilités, puis en retient un. Imaginons la phrase "Le chat dort sur le…". Le modèle peut donner 40% de chances à "canapé", 30% à "tapis”, 20% à "lit", et répartir les 10% restants entre des milliers d’autres tokens. Il pourrait toujours retenir "canapé", le plus probable. Mais par défaut, il fait autrement. Il tire au sort en respectant ces pourcentages, comme sur une roue de loterie dont les cases seraient plus ou moins larges. "Canapé" sort donc 4 fois sur 10, "tapis" 3 fois sur 10, et ainsi de suite. C’est ce qui rend les réponses variables d’une fois à l’autre. Le token tiré s’ajoute à la phrase, puis le calcul recommence pour le suivant.

Température et top-p : deux réglages pour doser le hasard

Les éditeurs disposent de deux réglages pour encadrer ce tirage. Le premier est la température. C’est en quelque sorte la molette du hasard. Quand elle est basse, le modèle choisit presque toujours le token en tête, et les réponses se ressemblent. A contrario, quand elle est haute, elle élargit les petites cases de la roue : des tokens moins probables passent plus souvent, et les réponses varient. À 0, il n’y a plus de tirage. Le modèle prend toujours le favori. Cette méthode s’appelle l’échantillonnage « glouton » (greedy). Dans l’API d'OpenAI, la température va de 0 à 2 et vaut 1 par défaut.

Le second réglage s’appelle le top-p. Il écarte les candidats improbables avant le tirage. Le principe : on classe les tokens par probabilité décroissante, puis on additionne leurs probabilités en partant du haut, jusqu’à atteindre un seuil. Tous les tokens suivants sont exclus. Avec un top-p de 0,9 dans notre exemple, le modèle garde "canapé", "tapis" et "lit", qui totalisent 90%, et ignore les autres. Le tirage reste possible, mais seulement entre ces trois candidats, dont les probabilités sont recalculées pour retomber à 100% : "canapé" sort alors environ 44% du temps, "tapis" 33% et "lit" 22%. Les spécialistes parlent aussi de "nucleus sampling". OpenAI conseille de modifier la température ou le top-p, pas les deux.

Ces réglages servent à choisir un comportement. Une valeur basse convient quand on veut des réponses stables, par exemple pour extraire une information ou écrire du code. Une valeur haute convient quand on cherche de la variété, pour des idées ou un texte créatif. Cette variabilité est donc voulue. En contrepartie, on ne retombe pas forcément sur la même réponse.

Température 0, et pourtant 80 réponses différentes sur 1000 essais

Si le modèle prend toujours le favori à température 0, la réponse devrait être identique à chaque essai. En pratique, ce n’est pas le cas. En septembre 2025, Horace He et ses collègues de Thinking Machines Lab ont publié un test. Ils ont envoyé 1000 fois la même requête au modèle Qwen3-235B, à température 0, en demandant des réponses de 1000 tokens. Résultat : 80 réponses différentes. Une même version revient 78 fois, les autres se répartissent le reste. Les réponses sont identiques pendant les 102 premiers tokens, puis elles divergent au 103e. Le modèle n’était pas en mode réflexion et le phénomène touche donc aussi les modèles classiques.

Puisqu’à température 0, il n’y a plus de tirage au sort, le modèle retient simplement le token qui a le meilleur score. Ce n’est donc pas le tirage qui est en cause : le problème se situe plus tôt, dans le calcul des scores. Si l’un d’eux varie très légèrement, le favori peut changer.

Une première hypothèse pointait la puce GPU. Elle réalise des milliers d’opérations en parallèle, et certaines additions (dites “atomiques”) se terminent dans un ordre qui varie d’une exécution à l’autre. Or changer l’ordre d’une série d’additions peut modifier les dernières décimales du résultat. Mais les auteurs ont écarté cette piste. Ils expliquent que ces additions sans ordre garanti n’interviennent pratiquement pas dans le calcul d’une réponse. Et une même requête traitée dans les mêmes conditions donne le même résultat à chaque fois.

Le lot de requêtes, ou comment les autres utilisateurs changent votre réponse

Il faut prendre en compte qu’une requête n’est pas traitée de manière isolée. Pour rentabiliser leurs GPU, les serveurs regroupent les requêtes de plusieurs utilisateurs et les calculent en même temps pour former un lot (ou batch). La taille de ce lot dépend du nombre de personnes qui interrogent le service à cet instant. Elle change donc d’une seconde à l’autre, sans que vous puissiez la connaître ni la contrôler.

La taille du lot a une conséquence sur le calcul des scores. Pour les ces derniers, le GPU additionne des milliers de nombres, et les programmes qui exécutent ces additions les regroupent différemment selon la taille du lot. Sur le papier, l’ordre ne devrait rien changer. Mais pour un ordinateur, la donne est différente car il arrondit le résultat à chaque étape. Or ces arrondis ne tombent pas au même endroit selon l’ordre des opérations.

Ces écarts sont minuscules, et la plupart du temps ils ne changent rien. Mais quand deux tokens ont des scores presque identiques, une variation de la dernière décimale suffit à changer le favori. Le modèle retient alors un autre token. Comme chaque token dépend de ceux qui précèdent, le reste de la réponse part dans une autre direction. C’est d’ailleurs ce que montre le test. Les réponses sont identiques jusqu’au 102e token, puis elles se séparent au 103e.

Thinking Machines a donc conçu des noyaux de calcul qui additionnent toujours dans le même ordre, quelle que soit la taille du lot. Dans ce cas, les 1000 réponses du test deviennent identiques. Mais les calculs, eux, sont plus lents. Sur un modèle plus petit, Qwen-3-8B, le traitement passe de 26 à 42 secondes avec un noyau d’attention optimisé, et à 55 secondes sans cette optimisation.

Une réflexion qui se paie en tokens que l’on ne voit pas

Un modèle de raisonnement ne répond pas tout de suite. Il commence par écrire une longue réflexion, étape par étape, que l’on appelle chaîne de pensée. Ce brouillon est du texte généré token par token, comme le reste. Pourquoi passer par l’écrit ? Un modèle de langage est composé de couches de calcul empilées. Dans un même calcul, l’information circule dans un seul sens, des premières couches vers les dernières. Le modèle ne peut pas revenir en arrière pour s’appuyer sur un résultat intermédiaire. Il n’a qu’un moyen : écrire ce résultat sous forme de tokens, lesquels sont ensuite relus comme n’importe quel texte. Ces tokens servent donc de mémoire de travail, un peu comme des opérations que l’on poserait sur une feuille plutôt que de les faire de tête. C’est ce qu’expliquent les auteurs d’un texte de recherche publié en juillet 2025. Pour les tâches assez difficiles, c’est-à-dire celles qui demandent beaucoup d’étapes enchaînées, les modèles de type Transformer (l’architecture utilisée par les assistants actuels) doivent passer par la chaîne de pensée. Écrire permet donc de raisonner plus loin.

Et bien sûr, cette réflexion est facturée. Les API facturent au token, avec un tarif pour l’entrée (votre question) et un tarif plus élevé pour la sortie (ce que le modèle écrit). À titre d’exemple, nous rapportions le mois dernier que Haiku 5.5 est facturé 0,10 dollar le million de tokens en entrée et 0,50 dollar en sortie, soit cinq fois plus, tant que le prompt ne dépasse pas 100 000 tokens (au-delà, les tarifs passent à 0,50 et 2,50 dollars). Or la réflexion compte comme de la sortie. Chez OpenAI, les tokens de raisonnement restent invisibles pour l’utilisateur, mais ils occupent la fenêtre de contexte, c’est-à-dire la quantité maximale de texte que le modèle peut garder sous les yeux en même temps, et sont facturés comme des tokens de sortie. Chez Anthropic, l’API peut renvoyer un résumé sur demande, mais c’est la réflexion complète qui est facturée. Un champ indique combien de tokens de sortie facturés correspondent au raisonnement interne, un total supérieur à ce que contient le résumé que l’on voit.

Le volume est difficile à prévoir. OpenAI conseille de réserver au moins 25 000 tokens pour le raisonnement et la réponse lors des premiers essais, puis d’ajuster. Chez Anthropic, le développeur fixe un plafond au nombre de tokens que le modèle peut écrire en une réponse (le paramètre max_tokens). La réflexion compte dans ce plafond, au même titre que la réponse visible. Plus le modèle réfléchit, moins il lui reste de place pour répondre.

Les éditeurs proposent aussi un réglage de l’effort. Il s'agit d'un curseur qui indique au modèle combien il doit réfléchir, de "low" (peu) à "max" (au maximum). Plus l’effort est élevé, plus la réflexion s’allonge, ce qui produit plus de tokens de sortie. C’est le cas de Claude Opus 4.7 , pour lequel Anthropic a ajouté un niveau intermédiaire, "xhigh", entre "high" et "max".

Pour maîtriser la consommation, l’entreprise propose d’ajuster cet effort, de fixer un budget de tâche ou de demander des réponses plus concises. Elle conseille aussi de mesurer l’effet sur son propre trafic.

Réfléchir plus longtemps ne donne pas toujours une réponse plus juste

Apple a publié en juin 2025 une étude intitulée "The Illusion of Thinking”. Les chercheurs ont testé o3-mini, DeepSeek-R1 et Claude 3.7 Sonnet en mode réflexion sur quatre casse-têtes : la tour de Hanoï, Checker Jumping (des sauts de pions), River Crossing (une traversée de rivière) et Blocks World (un empilement de blocs). Ces jeux ont l'avantage de pouvoir être rendus plus difficiles à volonté. Dans la tour de Hanoï, par exemple, il suffit d’ajouter des disques, et la solution demande alors beaucoup plus de déplacements. Trois régimes apparaissent. Sur les problèmes simples, les modèles classiques font mieux que les modèles de raisonnement. Sur les problèmes moyens, la réflexion supplémentaire apporte un avantage. Sur les problèmes difficiles, les deux types de modèles échouent presque systématiquement : leur taux de réussite tombe à près de zéro. Les chercheurs parlent d’“effondrement”. Il survient à partir d’un seuil de difficulté qui dépend du modèle.

Dans le détail, les modèles consacrent d’abord de plus en plus de tokens à réfléchir à mesure que le problème se complique. Puis, juste avant l’effondrement, ils en consacrent moins, alors qu’il leur en reste en réserve. Ils réfléchissent donc moins au moment où le problème se complique. Sur les cas simples, Claude 3.7 Sonnet en mode réflexion trouve souvent la bonne solution tôt, puis continue d’explorer des pistes fausses.

Peut-on se fier à la chaîne de pensée ?

La chaîne de pensée n’est utile que si elle reflète ce qui a réellement guidé la réponse. On dit alors qu’elle est “fidèle”. Anthropic a mesuré cette fidélité. Ses chercheurs ont glissé un indice dans des questions posées à Claude 3.7 Sonnet et à DeepSeek R1, puis ils ont regardé si la chaîne de pensée le mentionnait quand le modèle s’en servait vraiment. En moyenne, l’indice est cité dans 25% des cas pour Claude et 39% pour R1. La fidélité baisse sur les questions difficiles. Les chaînes infidèles sont nettement plus longues que les chaînes fidèles, ce qui écarte l’idée d’un souci de concision.

Lire la chaîne de pensée sert aussi à repérer des comportements indésirables. C’est le rôle d’un “moniteur”, un programme chargé de la surveiller. Une étude d’OpenAI de mars 2025 montre toutefois des limites. Quand l’avis du moniteur sert à entraîner le modèle, celui-ci apprend à cacher ses intentions dans sa chaîne de pensée, et presque toutes ses tricheries échappent au moniteur. OpenAI recommande donc d’éviter une supervision forte appliquée directement aux chaînes de pensée.

Cette surveillance devient plus difficile sur les modèles récents. OpenAI a publié GPT-6 Astra le 3 septembre dernier. Dans sa fiche système, la société écrit que la “monitorabilité” d’Astra, c’est-à-dire la facilité à repérer un comportement problématique en lisant sa chaîne de pensée, a baissé par rapport à GPT-5.6 Sol. Astra sait aussi mieux façonner sa propre chaîne de pensée quand on le lui demande. Sur des chaînes de 750 à 1 250 tokens, il la modifie comme demandé dans 60,9% des cas, contre 16,1% pour GPT-5.6 Sol. Or un modèle capable de modifier sa chaîne de pensée à volonté la rend moins fiable pour le surveiller. Quand on lui dit simplement qu’un moniteur est présent, il génère nettement moins de tokens de raisonnement.

Sur les modèles de raisonnement, le réglage du hasard disparaît

Les modèles de raisonnement posent un autre problème : sur plusieurs d’entre eux, les éditeurs retirent les réglages présentés au début. Chez OpenAI, le guide du modèle récent demande de supprimer temperature, top_p et top_logprobs (qui affiche les tokens les plus probables) dès que le modèle réfléchit, c’est-à-dire dès que l’effort de raisonnement n’est pas réglé sur “none”. Or GPT-6 Astra et GPT-6.1 Sol n’offrent pas cette option : ils réfléchissent toujours. Ces réglages ne sont donc plus utilisables sur ces deux modèles.

Chez Anthropic, la restriction a commencé avec Claude Opus 4.7, lancé le 16 avril 2026. Depuis, elle s’applique à tous les modèles qui ont suivi, d’Opus 4.8 à Sonnet 5, puis aux versions 5.5 (Opus, Sonnet et Haiku). Sur ces modèles, une valeur non standard de temperature top_p renvoie une erreur HTTP 400, c’est-à-dire un refus de la requête.

La règle va même plus loin avec la version d’API 2026-10-21. Avec elle, envoyer l’un de ces trois paramètres déclenche l’erreur, y compris à sa valeur par défaut. Les développeurs doivent donc les retirer de leurs requêtes. Le SDK Python v1.0, annoncé dans les notes du 20 août 2026, les supprime d’ailleurs des méthodes Messages. À la place, l’API propose un paramètre d’effort, de "low" à "max".

Le réglage change donc de nature. Il ne dose plus le hasard, mais l’effort de réflexion. Dans les documents que nous avons consultés, aucune raison n’est donnée à ce changement.

Pour autant, le hasard ne disparaît pas. C’est son réglage qui disparaît. Le tirage au sort reste actif. Avec les valeurs par défaut (une température de 1 chez Anthropic), le modèle continue de piocher parmi les tokens possibles, comme sur la roue de loterie décrite plus haut. À cette variabilité voulue s’ajoute celle du serveur, liée à la taille du lot de requêtes. Et comme le mode "glouton" à température 0 n’est plus accessible, impossible désormais de neutraliser le premier ni de limiter l’effet du second.