La température

Pendant des années, la température a été le premier réglage que l’on apprenait à manipuler sur une API de modèle de langage. Elle l’est beaucoup moins aujourd’hui : sur les modèles Claude récents, elle n’est plus réglable, et la version d’API publiée par Anthropic le 21 octobre 2026 la refuse purement et simplement. Cette leçon vous explique ce qu’elle faisait — parce que le mécanisme reste utile pour comprendre un modèle de langage —, ce qui a changé, et comment obtenir autrement ce que vous lui demandiez.

Ce que fait la température

Un modèle génère du texte en trois temps. Votre texte est d’abord découpé en tokens ; pour chaque nouveau token, le modèle calcule ensuite une probabilité pour chaque candidat possible du vocabulaire ; enfin, un token est choisi parmi ces candidats. La température n’agit que sur cette dernière étape : elle ne change pas les probabilités calculées, elle change la façon de piocher dedans. Proche de 0, le tirage retient presque toujours le candidat le plus probable ; à 1, il respecte les probabilités, ce qui laisse leur chance aux candidats moins évidents.

Une conséquence est souvent oubliée : une température basse ne rend pas un modèle plus exact, elle le rend plus constant. S’il se trompe avec une température proche de 0, il se trompera de la même façon à chaque appel. C’est pour cette raison que la température n’a jamais été un bon outil de qualité, seulement un outil de variabilité.

Ce qui a changé en 2026

Anthropic a d’abord restreint le paramètre modèle par modèle, puis l’a retiré de l’API. Le tableau suivant résume la situation telle que la documente la plateforme Claude au 5 novembre 2026.

Sur Google Cloud, la version d’API voyage dans le corps de la requête, champ anthropic_version, et non dans un en-tête. La documentation y accepte deux valeurs : vertex-2023-10-16, la version historique de Vertex, et 2026-10-21. Les SDK 0.x envoyaient la première. Depuis la version 2.0 du SDK Python, publiée le 21 octobre 2026, AnthropicVertex envoie la seconde, comme le client principal.

Sans ces paramètres, une requête est échantillonnée avec leurs valeurs par défaut, dont une température de 1,0 : c’est exactement ce qui se passait déjà quand vous ne les envoyiez pas. Le guide de migration d’Anthropic est explicite sur un point qui vous concerne directement : aucun autre réglage ne remplace la température. Si une requête dépend vraiment d’une valeur basse sur un modèle ancien, la seule option documentée est de la conserver sur l’ancienne version d’API (2023-06-01, ou vertex-2023-10-16 sur Vertex), en sachant que ce modèle finira lui aussi par être retiré.

Le code, avant et après

Le code ci-dessous est celui qu’on écrivait jusqu’au printemps 2026. Il échoue désormais sur tous les modèles actuels :

# Ancienne pratique, refusée : TypeError avec le SDK Python 1.x et suivants
# (le paramètre n'existe plus), erreur 400 de l'API avec un SDK plus ancien
message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    temperature=0,          # refusé
    messages=[{"role": "user", "content": "Quelle est la formule de l'eau ?"}],
)

La version correcte se contente de retirer la ligne. La fonction chat du cours n’a donc pas de paramètre temperature, contrairement à celle du cours officiel :

def chat(messages, system=None):
    params = {"model": model, "max_tokens": 4096, "messages": messages}
    if system:
        params["system"] = system
    message = client.messages.create(**params)
    return "".join(block.text for block in message.content if block.type == "text")

Ce que montre le cours officiel

La leçon « Temperature » de Claude Academy enseigne encore ce réglage, avec un curseur de démonstration et des plages conseillées : de 0 à 0,3 pour les réponses factuelles, le code, l’extraction et la modération ; de 0,4 à 0,7 pour le résumé, le contenu pédagogique et la résolution de problèmes ; de 0,8 à 1 pour le brainstorming, l’écriture créative et le marketing. Son code fonctionne parce qu’il combine Claude Haiku 4.5, modèle antérieur à Opus 4.7, et une version 0.x du SDK, qui envoie sur Vertex la version historique vertex-2023-10-16. Avec le SDK actuel ou un modèle récent, ce code échoue : retenez le mécanisme, pas le réglage.

Obtenir autrement ce que vous demandiez à la température

La plupart des usages de la température se ramenaient à deux besoins opposés : de la constance pour les tâches factuelles, de la variété pour les tâches créatives. Les deux se pilotent maintenant par le contenu de la requête plutôt que par un curseur.

Pour la constance, le levier le plus efficace est la précision de la consigne : un format de sortie décrit sans ambiguïté, quelques exemples de réponses attendues, et, quand la réponse doit être exploitée par du code, les sorties structurées, qui imposent un schéma JSON. Une extraction de données décrite de cette façon varie très peu d’un appel à l’autre, et surtout, elle varie sur la forme plutôt que sur le fond.

Pour la variété, demandez-la explicitement. Plutôt que d’appeler trois fois le modèle en espérant trois réponses différentes, demandez-lui dans un seul appel trois propositions qui ne se ressemblent pas, en précisant sur quoi elles doivent différer :

question = (
    "Propose trois noms pour une startup d'IA. Les trois doivent être très "
    "différents : un nom descriptif, un nom inventé, un nom tiré d'un mot "
    "français. Pour chacun, une phrase de justification."
)
print(chat([{"role": "user", "content": question}]))

Reste le cas des évaluations, où l’on fixait autrefois la température à 0 pour comparer deux versions d’un prompt à armes égales. Ce raccourci n’existe plus, et il n’était d’ailleurs pas fiable : même à 0, une reproductibilité parfaite n’a jamais été garantie. La pratique saine consiste à exécuter chaque cas plusieurs fois et à regarder la dispersion des scores, pas un score isolé — le module consacré aux évaluations y revient en détail.

Un dernier piège de vocabulaire : le paramètre effort, que vous rencontrerez avec les modèles récents, ne remplace pas la température. Il règle la quantité de réflexion et de tokens que le modèle s’autorise, donc la profondeur et le coût d’une réponse, pas son caractère aléatoire.

À vous de jouer

Constance et variété. Exécutez trois fois de suite la même question factuelle, puis la question créative ci-dessus, et comparez. Vous constaterez que la question factuelle bien cadrée donne des réponses très proches, et que la question créative donne de la variété précisément parce que vous l’avez demandée. C’est la logique à retenir : la variabilité se décide dans la consigne.

Voir l’erreur. Ajoutez temperature=0 à un appel avec le SDK actuel et lisez le message d’erreur : c’est celui que vous rencontrerez en reprenant du code ancien. Supprimez la ligne et relancez.

Sources officielles : Temperature (Claude Academy) · Migrating to API version 2026-10-21 (documentation Claude : paramètres d’échantillonnage retirés, aucun réglage de remplacement)

Points clés à retenir

• La température agit sur le tirage du token suivant : elle règle la constance, pas l’exactitude
• Le cours officiel la montre encore, avec Haiku 4.5 et un SDK 0.x ; le SDK actuel ne l’envoie plus
• Depuis Claude Opus 4.7, seule sa valeur par défaut est acceptée ; la version d’API 2026-10-21 la refuse totalement, comme top_p et top_k
• Aucun réglage ne la remplace : la constance s’obtient par des consignes précises et des sorties structurées, la variété en la demandant explicitement
• En évaluation, répétez les exécutions et mesurez la dispersion plutôt que de chercher un score unique reproductible