Anthropic supprime les paramètres d'échantillonnage de son API

Le 21 octobre 2026, Anthropic a publié la version 2026-10-21 de l'API Claude. Trois paramètres disparaissent : temperature, top_p et top_k. Une requête qui en envoie un seul, même à sa valeur par défaut, renvoie une erreur 400. Pour les équipes qui réglaient la variabilité d'un modèle afin de stabiliser une extraction ou un test, la conséquence est immédiate et ne dispose d'aucun substitut documenté.

Ce que change la version 2026-10-21

La nouvelle version de l'API Messages supprime trois paramètres de requête. Anthropic précise qu'une requête contenant temperature, top_p ou top_k renvoie une erreur 400, y compris lorsque la valeur envoyée est celle par défaut. La page d'historique des versions ajoute que le rejet s'applique à tous les modèles.

Une requête sans ces paramètres échantillonne avec leurs valeurs par défaut, dont une température de 1,0. Anthropic indique que les modèles qui n'acceptaient déjà que les valeurs par défaut, comme Claude 4.7 et les suivants, se comportent comme avant. Pour les modèles qui acceptaient d'autres valeurs, comme Claude Sonnet 4.6, l'effet d'une température abaissée disparaît, et aucun autre réglage ne le remplace.

La rupture ne s'arrête pas aux paramètres. Sept SDK et la CLI changent de version majeure le même jour : Python 2.0.0, TypeScript 1.0.0, C# 13.0.0, Go 2.0.0, Java 3.0.0, PHP 1.0.0, Ruby 2.0.0 et ant 2.0.0. Ces versions envoient 2026-10-21 par défaut et passent de la licence MIT à Apache 2.0.

Le guide de migration ne donne aucune justification technique à la suppression. Il documente le comportement et la marche à suivre, pas le raisonnement. Cette absence compte pour une équipe qui doit décider si elle peut encore reproduire un résultat obtenu en septembre.

Deux changements de format s'ajoutent. Un bloc de type document placé directement dans un message assistant renvoie une erreur 400. Un bloc texte avec un tableau de citations non vide dans un message utilisateur renvoie aussi une erreur 400. Sur Amazon Bedrock, la version n'est disponible que pour Claude 4.7 et les modèles ultérieurs ; les appels à des modèles plus anciens doivent rester sur la version actuelle.

Les autres ruptures de la migration

La version précédente, 2023-06-01, reste acceptée. Anthropic la qualifie toutefois de dépréciée et indique que les versions précédentes peuvent devenir indisponibles pour les nouveaux utilisateurs. Rester sur l'ancienne version est donc une position de repli, pas une stratégie durable.

Le changement de types est plus insidieux que le changement de paramètres. En Python, MessageParam devient une union de trois types, un par rôle. Construire un message avec MessageParam en appel de fonction lève désormais une TypeError ; il faut passer un dictionnaire. En TypeScript, l'interface devient une union, et le contenu d'un message système n'accepte plus de bloc image. Ces erreurs apparaissent à la compilation ou au premier appel, à condition que vos tests couvrent le chemin.

Les adaptateurs .NET illustrent un piège différent. La documentation indique que les adaptateurs IChatClient ignorent désormais Temperature, TopK et TopP. Un même changement de plateforme produit donc deux comportements opposés : une erreur 400 côté API, un paramètre silencieusement ignoré côté adaptateur. Si votre couche d'abstraction ne journalise pas les options réellement transmises, vous ne saurez pas dans quel cas vous êtes.

La migration touche enfin l'API d'administration. Les champs roles, group_id, name et group_type deviennent role_ids, rbac_group_id, display_name et group.type. Le champ workspace_id d'une clé API disparaît au profit de scope, dont la valeur diffère pour une clé liée à l'espace de travail par défaut. Un tableau de bord qui lisait l'ancien champ affichera une valeur vide, sans erreur.

La température basse ne garantissait pas la stabilité

Beaucoup d'équipes utilisaient une température proche de zéro comme contrat implicite : même entrée, même sortie. Ce contrat n'a jamais été garanti par l'API. Il reposait sur une convention de réglage, pas sur une propriété du système. La documentation d'Anthropic le formulait en termes d'usage, celui d'une sortie plus cohérente, et non de reproductibilité.

La suppression rend ce contrat explicite en le retirant. Pour Claude 4.7 et les suivants, le réglage n'existait déjà plus. Pour Sonnet 4.6, il existait encore et disparaît à la migration. Une équipe qui extrayait des montants de factures avec une température basse, par exemple 0,2, passe à 1,0 sans modifier une ligne de code métier, simplement en changeant de version d'API.

Le risque n'est pas l'erreur visible. C'est la dérive silencieuse : le pipeline continue de tourner, le taux d'extraction correcte baisse, et personne ne relie la baisse au changement de version. Un test qui vérifie la forme du JSON ne détecte pas ce type de régression.

Ce qu'un bug corrigé en vingt-quatre heures enseigne

Le 27 juillet 2026, un rapport de bug est ouvert sur le dépôt Umbraco.AI. L'erreur renvoyée par Anthropic est explicite : temperature is deprecated for this model. La cause est documentée dans le rapport : les paramètres d'échantillonnage ont été retirés à partir de Claude Opus 4.7, et l'envoi de l'un d'eux est rejeté par une erreur 400 plutôt qu'ignoré. Umbraco.AI transmettait la température configurée dans un profil utilisateur, si bien que tout profil avec une température renseignée échouait sur un modèle récent.

Le rapport précise que le problème dépasse le chemin des agents : le service de chat principal envoyait déjà la température. Il note aussi qu'Anthropic n'est pas le seul fournisseur concerné, les modèles de raisonnement d'OpenAI restreignant les mêmes paramètres. La correction, livrée le 28 juillet, filtre les paramètres dans la couche fournisseur, avec une liste de familles de modèles qui les acceptent.

Deux décisions méritent d'être reprises. La première est de placer la connaissance des capacités au niveau du modèle, pas du fournisseur : un même éditeur expose des modèles qui n'acceptent pas les mêmes réglages. La seconde est de choisir explicitement entre échouer et ignorer. L'équipe a retenu d'ignorer un paramètre inconnu pour laisser passer la requête, ce qui est défendable pour un CMS et moins pour un pipeline facturier où la variation de sortie doit être tracée.

Le rapport signale enfin un facteur contributif utile : le curseur de température de l'interface affichait 1 lorsque la valeur était nulle, et le simple fait de le déplacer enregistrait une valeur que l'utilisateur n'avait pas choisie. Une valeur d'interface est devenue une charge utile d'API. Ce détail coûte plus cher que bien des erreurs d'architecture.

Mesurer à nouveau plutôt que espérer

Une migration qui change à la fois la version d'API et le modèle déplace deux variables. Si vous mesurez une baisse de qualité après coup, vous ne saurez pas laquelle est en cause. Séparez les étapes : corrigez d'abord le code sur la version actuelle, mesurez, puis changez de version, mesurez à nouveau.

Le protocole minimum tient en quatre points. Épinglez la version d'API et l'identifiant exact du modèle dans la configuration, pas dans le code. Exécutez chaque cas de test plusieurs fois et rapportez un taux de réussite avec un intervalle, pas une exécution unique. Validez la sortie par un schéma et par des règles métier, puisque la température ne contrôle plus rien. Conservez un jeu de cas figé, avec les mêmes entrées, pour comparer avant et après.

Pour les requêtes qui dépendent réellement d'une valeur non par défaut, Anthropic propose de rester sur 2023-06-01. Cette option a une date de péremption : la documentation indique que les versions précédentes sont dépréciées et peuvent être fermées aux nouveaux utilisateurs. Il faut donc la traiter comme une dette, avec une échéance inscrite, et non comme une solution.

Le coût de cette migration n'est pas le temps de suppression des trois paramètres. C'est le temps de revalidation des sorties qui comptaient sur eux : du temps d'ingénierie et une revue métier des cas limites, pas une tâche de configuration. La question à poser à votre équipe n'est donc pas combien de temps prend le correctif, mais quels résultats elle ne sait plus reproduire.

Un dernier point relève du contrat. Si un prestataire héberge le modèle pour votre compte, demandez-lui quelle version d'API il envoie et quel modèle exact il sert. La réponse figure rarement dans l'entente, alors qu'elle détermine le comportement de votre produit.

Ce qu'il faut retenir

• Inventoriez chaque appel qui envoie temperature, top_p ou top_k, y compris dans les traitements par lots et les proxys.
• Épinglez la version d'API et le modèle dans la configuration, et testez la migration sur une branche avant de changer la version par défaut des SDK.
• Remplacez la température basse par une validation de schéma et des règles métier explicites.
• Mesurez chaque cas plusieurs fois et comparez des taux, pas des sorties uniques.
• Vérifiez le comportement de votre couche d'abstraction : erreur 400 ou paramètre ignoré sont deux risques différents.
• Traitez le maintien sur 2023-06-01 comme une dette datée.