Aller au contenu principal

Identifiants de modèles : la convention sans date

Mis à jour le 27 juillet 2026

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. Prenons le temps de démêler 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 sa date de publication. Depuis la génération 4.6, la date a disparu :

# Generation 4.5 et antérieures
claude-sonnet-4-5-20250929
claude-opus-4-1-20250805

# Depuis la generation 4.6
claude-opus-5
claude-sonnet-5
claude-fable-5

Le changement paraît cosmétique. Il ne l’est pas, parce qu’il modifie la signification même 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 automatiquement vers la dernière version du modèle. Le raisonnement semble logique : plus de date, donc plus d’ancrage, donc l’identifiant « suit » les mises à jour. Et si c’était vrai, la prudence commanderait d’éviter ces identifiants en production, de peur qu’une mise à jour du modèle 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, les identifiants sans date restent des instantanés figés (pinned snapshots). Quand votre code cible claude-opus-5, il cible exactement la même version du modèle tant que vous ne le modifiez pas. La conséquence est rassurante : vos résultats restent reproductibles, et aucune mise à jour silencieuse ne viendra changer le comportement de votre application. Vous pouvez utiliser ces identifiants en production sans arrière-pensée.

Attention toutefois à ne pas généraliser cette règle vers le passé. Pour les modèles antérieurs à la génération 4.6, le fonctionnement est différent : là, l’identifiant sans date est bien un alias de commodité, qui pointe vers un identifiant daté. La règle d’interprétation dépend donc de la génération — c’est peu élégant, mais c’est ainsi.

Les identifiants diffèrent selon la plateforme

Deuxième source d’erreur, classique en environnement 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.

PlateformeIdentifiant d’Opus 5
API Claudeclaude-opus-5
Google Cloudclaude-opus-5
Amazon Bedrockanthropic.claude-opus-5
Claude Platform on AWSclaude-opus-5 (identique à l’API Claude)

Le cas de Claude Platform on AWS mérite qu’on s’y arrête, car il déjoue l’intuition « AWS, donc format Bedrock » : cette plateforme utilise les identifiants de l’API Claude, et non le format Bedrock. Son cycle de vie des modèles suit d’ailleurs les dépréciations d’Anthropic, pas celles de Bedrock. Si votre organisation opère sur plusieurs de ces environnements, la table de correspondance des identifiants a sa place dans votre configuration, pas dans la tête des développeurs.

Ne codez pas la liste en dur

Reste la question de la maintenance dans le temps. Une liste de modèles écrite en dur dans le code 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 elle-même, qui sait toujours mieux que votre code ce qui est disponible. La réponse contient max_input_tokens, max_tokens et un objet capabilities pour chaque modèle accessible à votre organisation — de quoi construire une détection entièrement dynamique.

import anthropic

client = anthropic.Anthropic()

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

Avec cette approche, votre application détecte automatiquement 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.

Source officielle : Model IDs and versioning

Points clés à retenir

  • Depuis la génération 4.6, plus de date dans l’identifiant : claude-opus-5
  • Un identifiant sans date reste figé sur une version : pas de mise à jour silencieuse
  • Les identifiants Bedrock diffèrent (anthropic. en préfixe), mais pas ceux de Claude Platform on AWS
  • Interrogez l’API des modèles plutôt que de coder une liste en dur