Identifiants de modèles : la convention sans date

Voici un sujet qui ressemble à un détail de nommage et qui provoque pourtant de vraies erreurs en production : la façon dont Anthropic identifie ses modèles a changé, et l’interprétation spontanée de ce changement est fausse. Démêlons ce qui a changé, ce que cela garantit, et ce que cela ne garantit pas.

Avant et après

Jusqu’à la génération 4.5, chaque identifiant de modèle embarquait une date d’instantané. Depuis la génération 4.6, la date a disparu, selon le format claude-{nom}-{majeure}[-{mineure}] : les versions majeures comme Opus 5 ou Sonnet 5 n’ont pas de segment mineur.

# Génération 4.5 et antérieures
claude-sonnet-4-5-20250929
claude-haiku-4-5-20251001

# Depuis la génération 4.6
claude-opus-5
claude-opus-5-5
claude-sonnet-5-5
claude-haiku-5-5
claude-fable-5-1

Le changement paraît cosmétique. Il ne l’est pas, parce qu’il modifie la signification de l’identifiant, et c’est là que le contresens se glisse.

Le contresens à éviter

En voyant disparaître la date, on suppose spontanément que l’identifiant est devenu un alias mouvant, qui pointerait vers la dernière version du modèle. Si c’était vrai, la prudence commanderait d’éviter ces identifiants en production, de peur qu’une mise à jour ne change le comportement de votre application du jour au lendemain.

Ce n’est pas le cas. La documentation est formelle : à partir de la génération 4.6, l’identifiant sans date est l’instantané, figé. Anthropic ne modifie ni les poids ni la configuration d’un identifiant existant ; une version mise à jour sort sous un nouvel identifiant. Quand votre code cible claude-opus-5, il cible le même modèle tant que vous ne changez pas cette chaîne.

Une nuance honnête toutefois : ce qui est figé, ce sont les poids du modèle, pas toute l’infrastructure qui l’entoure. Le routage des requêtes, les classifieurs de sécurité ou la logique d’échantillonnage peuvent évoluer, et la documentation prévient qu’une telle mise à jour produit parfois de légères différences de comportement observable. Si un modèle stable se met à répondre un peu autrement, c’est la cause la plus probable : gardez des évaluations qui tournent régulièrement.

Attention aussi à ne pas généraliser la règle vers le passé. Pour les modèles antérieurs à la génération 4.6, l’API Claude accepte des alias de commodité sans date, comme claude-sonnet-4-5, qui pointent vers le dernier instantané daté de cette version : ce sont de vrais alias. Enfin, chaque identifiant, daté ou non, a son propre calendrier de dépréciation et de retrait (leçon 12).

Les identifiants diffèrent selon la plateforme

Deuxième source d’erreur, classique en multicloud : le même modèle ne porte pas le même identifiant partout. Une application qui fonctionne sur l’API Claude et qu’on redéploie sur Amazon Bedrock échouera si elle réutilise les identifiants tels quels.

Le cas de Claude Platform on AWS déjoue l’intuition « AWS, donc format Bedrock » : cette plateforme utilise les identifiants de l’API Claude, et son cycle de vie des modèles suit celui d’Anthropic. Sur Bedrock, le suffixe -v1 a disparu à partir de Sonnet 4.6 ; les anciens modèles gardent un format comme anthropic.claude-sonnet-4-5-20250929-v1:0, et Google Cloud sépare leur date par @ (claude-haiku-4-5@20251001). Si votre organisation opère sur plusieurs de ces environnements, la table de correspondance a sa place dans votre configuration, pas dans la tête des développeurs.

Ne codez pas la liste en dur

Une liste de modèles écrite en dur vieillit mal : elle ignore les nouveaux modèles et continue de proposer ceux qui disparaissent. Le réflexe le plus robuste consiste à interroger l’API Models, qui sait mieux que votre code ce qui est disponible pour votre organisation. Chaque modèle y décrit ses limites (max_input_tokens, max_tokens) et ses capacités, et l’API s’est enrichie en 2026 :

• line (depuis le 1er octobre) donne la famille du modèle, par exemple opus, sans avoir à analyser l’identifiant ;
• capabilities.thinking.types.disabled et capabilities.thinking.types.between_tools disent si le modèle accepte ces réglages de réflexion (leçon 5) ;
• capabilities.server_tools indique s’il accepte la recherche web et l’exécution de code.

import anthropic

client = anthropic.Anthropic()

for model in client.models.list():
    print(model.id, "-", model.display_name, "-", model.line)

Avec cette approche, votre application détecte les modèles disponibles au moment où elle tourne, et une dépréciation ne se traduit plus par une liste obsolète enfouie dans une constante.

À vous de jouer

Votre table de correspondance. Listez les modèles disponibles pour votre organisation avec l’API Models et notez, pour chacun, line, max_input_tokens et la valeur de capabilities.thinking.types.disabled. Si vous déployez aussi sur Bedrock ou Google Cloud, ajoutez une colonne avec l’identifiant de chaque plateforme, puis remplacez dans votre code toute liste de modèles écrite en dur par une lecture de cette configuration.

Sources officielles : Model IDs and versioning (documentation Claude : format, instantanés figés, infrastructure) · Models overview (identifiants par plateforme, API Models) · Claude Opus 5.5

Points clés à retenir

• Depuis la génération 4.6, plus de date dans l’identifiant : claude-opus-5-5, claude-opus-5
• Un identifiant sans date est un instantané figé : mêmes poids, mais l’infrastructure autour peut évoluer
• Avant la 4.6, les identifiants sans date de l’API Claude sont de vrais alias
• Bedrock préfixe par anthropic., Claude Platform on AWS garde les identifiants de l’API Claude
• Interrogez l’API Models (limites, line, capacités) plutôt que de coder une liste en dur