Changer de modèle dans une application Claude peut sembler être une modification minime :
model = "new-model"
Pourtant, en production, ce changement peut modifier :
- la qualité des réponses ;
- le comportement des tools ;
- la latency ;
- le coût ;
- le respect des instructions ;
- les résultats des
evals.
Un modèle LLM fait partie du comportement du système.
Il doit donc être traité comme une dépendance de production versionnée.
Le principe central du module est simple :
Pin what ships.
Mais ce principe va plus loin que le seul model ID.
Une release Claude réellement reproductible doit permettre de retrouver :
model
+
prompt
+
tools
+
configuration
+
code
+
eval baseline
Pourquoi le model versioning est un problème de production
Prenons une application validée avec une version donnée de Claude.
L’équipe exécute :
- les unit tests ;
- les integration tests ;
- les evals ;
- le security review.
Le système passe toutes les gates.
Il est ensuite déployé.
Conceptuellement :
MODEL VERSION N
↓
PROMPT VERSION 12
↓
TOOLS VERSION 4
↓
EVAL
↓
PASS
↓
PRODUCTION
Le comportement observé en production correspond à cette combinaison précise.
Si le modèle change sans contrôle, cette relation est rompue.
Un nouveau modèle n’est pas simplement « le même en mieux »
C’est un point fondamental pour raisonner correctement sur les LLM.
Une nouvelle version peut améliorer les performances moyennes tout en provoquant des régressions sur votre workload particulier.
Par exemple :
Benchmark général
Version N+1 > Version N
ne garantit pas :
Votre application
Version N+1 > Version N
Votre système possède :
- ses prompts ;
- ses tools ;
- ses données ;
- ses edge cases ;
- ses contraintes métier.
La seule réponse fiable vient donc de vos propres evals.
Le problème des moving aliases
Historiquement, certaines références de modèles peuvent fonctionner comme des aliases pointant vers une version sous-jacente.
Conceptuellement :
alias
│
├── aujourd'hui → snapshot A
│
└── plus tard → snapshot B
Cela peut être pratique pour certains environnements.
Mais cela pose un problème lorsque la production exige une forte reproductibilité.
Le risque
Supposons que vous validiez :
application
+
model alias
↓
eval score = 94 %
Puis la cible de l’alias change.
Votre code n’a pas changé.
Votre prompt n’a pas changé.
Pourtant :
application
+
new underlying model
↓
eval score = ?
Vous ne pouvez plus supposer que le comportement validé précédemment est identique.
Pinned model ID
Le principe du pinning consiste à identifier précisément la version utilisée par la release.
Conceptuellement :
Release 1.4
│
└── model → VERSION A
et non :
Release 1.4
│
└── model → "whatever current version this alias resolves to"
Vous savez alors exactement ce qui a été :
- testé ;
- évalué ;
- approuvé ;
- déployé.
Attention : ne pas mémoriser « ID sans date = alias »
C’est un point où les conventions Anthropic ont évolué.
Pour les générations antérieures à Claude 4.6, les snapshots datés étaient courants.
Conceptuellement :
claude-{family}-{version}-{YYYYMMDD}
Mais pour Claude 4.6 et les générations suivantes, Anthropic utilise des model IDs sans date qui peuvent néanmoins identifier une version pinée.
Le principe à retenir n’est donc pas :
« Chercher obligatoirement une date dans le nom. »
Le principe est :
Utiliser un model ID dont la documentation garantit qu’il identifie la version souhaitée.
Ne pas confondre syntaxe et principe
Pour l’examen, le plus important est le raisonnement.
Les conventions de nommage peuvent évoluer.
Le principe architectural reste :
KNOWN MODEL VERSION
↓
EVAL
↓
APPROVAL
↓
DEPLOY
La syntaxe exacte du model ID dépend :
- de la génération Claude ;
- de la plateforme ;
- du provider.
Les model IDs dépendent également de la plateforme
Une même famille de modèles peut être référencée différemment selon la plateforme.
Conceptuellement :
Claude API
→ Anthropic model ID
Amazon Bedrock
→ Bedrock-specific model identifier
Google Cloud
→ Vertex-specific model identifier
Cela signifie qu’une migration de plateforme ne consiste pas simplement à copier une chaîne de caractères.
Il faut vérifier :
- le modèle réellement disponible ;
- son identifiant ;
- ses features ;
- son lifecycle sur la plateforme cible.
Pinning ne concerne pas uniquement le modèle
C’est probablement le point le plus important de cet article.
Imaginez :
model = pinned
prompt = modified manually
Le modèle est parfaitement versionné.
Mais le comportement du système peut tout de même changer.
Pourquoi ?
Parce qu’un système Claude est une combinaison de plusieurs composants.
Versionner le prompt
Prenons :
Prompt v17
Il a passé les evals avec :
Model A
Une personne modifie ensuite une instruction :
Prompt v18
Même avec exactement le même modèle :
Model A + Prompt v17
n’est pas nécessairement équivalent à :
Model A + Prompt v18
Le prompt doit donc faire partie de la release.
Versionner les tool schemas
Même raisonnement avec les tools.
Supposons :
{
"name": "search_customer",
"input_schema": {
"type": "object",
"properties": {
"customer_id": {
"type": "string"
}
}
}
}
Puis le schema change.
Ce changement peut modifier :
- la manière dont Claude sélectionne le tool ;
- les arguments produits ;
- les erreurs de validation ;
- le comportement global de l’agent.
Le tool schema fait donc partie de la version du système.
Versionner l’agent logic
Pour un système agentique :
Claude
↓
tool_use
↓
application executes
↓
tool_result
↓
Claude
la logique applicative entourant Claude est essentielle.
Par exemple :
- nombre maximum d’itérations ;
- retry policy ;
- validation des arguments ;
- gestion des erreurs ;
- autorisation des tools.
Modifier cette logique revient à modifier le système.
Versionner la configuration
Les valeurs configurables peuvent également changer le comportement.
Par exemple :
threshold = 0.80
devient :
threshold = 0.95
Le code peut être identique.
Le modèle peut être identique.
Le prompt peut être identique.
Mais le comportement métier a changé.
Une release Claude est une combinaison
On peut donc représenter une release ainsi :
RELEASE 3.2
│
├── Model ID
├── Prompt version
├── Tool schemas
├── Agent logic
├── Configuration
├── Application code
└── Eval baseline
Cette représentation est beaucoup plus robuste que :
"We're using Claude X."
Versionner l’asset complet
Le module recommande donc de versionner :
model + prompt/asset + code
Cela permet de répondre précisément à la question :
Quelle configuration exacte a produit ce comportement ?
Pourquoi les evals sont indispensables au versioning
Versionner permet de savoir ce qui a changé.
Mais cela ne dit pas si le changement est acceptable.
C’est le rôle des evals.
Supposons :
Production
Model N
Prompt 17
Eval score = 94 %
Vous souhaitez passer à :
Candidate
Model N+1
Prompt 17
La bonne procédure n’est pas :
newer model
→ deploy
mais :
newer model
→ run eval suite
→ compare results
→ decide
L’eval devient une deployment gate
Le processus peut être représenté ainsi :
CANDIDATE RELEASE
↓
RUN EVAL SUITE
↓
COMPARE TO BASELINE
↓
PASS?
↙ ↘
YES NO
↓ ↓
PROMOTE BLOCK
L’eval ne sert donc plus seulement à améliorer le prompt pendant le développement.
Elle protège la production.
Définir une baseline
Supposons que la version actuelle obtienne :
Task success rate = 94 %
Policy compliance = 99 %
Tool selection accuracy = 97 %
Ces résultats constituent une baseline.
Une candidate peut alors être comparée à cette référence.
Attention à la métrique unique
Une nouvelle version pourrait obtenir :
Task success
94 % → 97 %
mais :
Policy compliance
99 % → 91 %
Dire simplement :
« La nouvelle version est meilleure »
serait dangereux.
Les evals doivent refléter les dimensions réellement importantes du système.
Une gate peut être multidimensionnelle
Conceptuellement :
PROMOTE IF:
task_success >= threshold
AND
policy_compliance >= threshold
AND
tool_accuracy >= threshold
AND
critical_safety_failures == 0
L’objectif n’est pas nécessairement d’obtenir un score global maximal.
Il faut satisfaire les requirements.
Rollback : garder la version précédente
Le module insiste également sur un point simple :
Keep the prior version for rollback.
Supposons :
Production = Release 4.1
Candidate = Release 4.2
La version 4.2 passe les evals.
Elle est déployée.
Mais un problème non couvert par le dataset apparaît en production.
Si 4.1 est toujours disponible :
4.2
↓
incident
↓
rollback
↓
4.1
Le système peut revenir rapidement à un état connu.
Pourquoi les evals ne suppriment pas le besoin de rollback
Aucune eval suite n’est parfaite.
Le dataset représente :
known cases
+
known edge cases
+
known risks
La production peut révéler :
unknown cases
Le rollback reste donc nécessaire.
Eval + monitoring + rollback
Ces trois mécanismes sont complémentaires.
BEFORE DEPLOY
↓
EVAL
AFTER DEPLOY
↓
MONITOR
IF REGRESSION
↓
ROLLBACK
On retrouve ici trois phases du lifecycle :
Test
↓
Deploy
↓
Operate
Exemple complet de changement de modèle
Supposons une application de support utilisant :
Release 7
│
├── Model A
├── Prompt v22
├── Tools v5
└── Eval baseline v4
Une nouvelle version de Claude devient disponible.
Étape 1 — Créer une candidate
Release 8 candidate
│
├── Model B
├── Prompt v22
├── Tools v5
└── Eval baseline v4
Une seule variable importante change : le modèle.
C’est idéal pour comprendre l’impact.
Étape 2 — Exécuter les evals
Release 7
→ baseline
Release 8
→ candidate results
Comparer :
- task success ;
- policy compliance ;
- tool use ;
- edge cases ;
- latency ;
- coût si ces dimensions font partie des critères.
Étape 3 — Analyser les régressions
Supposons :
Task quality
+4 %
Tool accuracy
+2 %
Critical edge case
FAIL
Le fait que les moyennes augmentent ne suffit pas.
Si l’edge case correspond à un requirement critique :
DO NOT PROMOTE
Étape 4 — Corriger
Il peut être nécessaire de modifier :
- le prompt ;
- un tool schema ;
- une validation ;
- le workflow.
Cela crée une nouvelle candidate.
Release 8.1 candidate
│
├── Model B
├── Prompt v23
├── Tools v5
└── Eval baseline v4
Puis les evals sont réexécutées.
Étape 5 — Promouvoir
Lorsque les gates passent :
Release 8.1
↓
PROMOTE
↓
PRODUCTION
La release exacte est enregistrée.
Étape 6 — Observer
En production :
Monitor:
- errors
- latency
- cost
- guardrails
- quality signals
Étape 7 — Rollback si nécessaire
Si une régression critique apparaît :
Release 8.1
↓
incident
↓
rollback
↓
Release 7
La version précédente doit donc rester disponible suffisamment longtemps pour permettre ce retour.
Model lifecycle et retirement
Le versioning ne signifie pas qu’une version peut être conservée indéfiniment.
Les modèles possèdent un lifecycle.
Une version peut finir par être :
available
↓
deprecated
↓
retired
Cela impose une migration.
La migration doit être anticipée
La mauvaise approche :
Model retirement tomorrow
↓
Emergency migration
↓
Deploy new model
La bonne approche :
Deprecation announced
↓
Create candidate
↓
Run eval suite
↓
Fix regressions
↓
Deploy
↓
Monitor
Le versioning et les evals transforment ainsi une migration forcée en processus contrôlé.
Attention au provider
Le document fourni souligne également que le lifecycle d’un modèle peut dépendre de la plateforme.
Une même famille Claude peut être disponible via :
- Anthropic ;
- Amazon Bedrock ;
- Google Cloud.
Il ne faut pas supposer que :
same model family
=
same retirement lifecycle everywhere
Pour une migration réelle, le calendrier de la plateforme utilisée doit être vérifié.
Pinning et reproducibility
Pourquoi toute cette discipline ?
Parce qu’en cas d’incident vous devez pouvoir reconstruire :
Quelle version exacte tournait ?
Une réponse insuffisante serait :
"We were using Sonnet."
Une réponse exploitable ressemble davantage à :
Release 4.7
Model:[pinned model ID]
Prompt: commit abc123 Tool schemas: version 6 Agent code: commit def456 Configuration: production-config-v12 Eval suite: v8
Vous pouvez alors reproduire le comportement.
Pinning et debugging
Supposons qu’un incident apparaisse lundi.
Si tous les composants sont versionnés, vous pouvez comparer :
Sunday
Release 4.6
Monday
Release 4.7
Puis identifier :
Model unchanged
Prompt changed
Tool schema changed
La recherche de cause devient beaucoup plus précise.
Pinning et audit
Dans un environnement réglementé, la question peut venir d’un auditor :
Quelle version du système a produit cette décision ?
Le versioning permet de répondre.
Sans cela :
current code
≠ necessarily
historical production code
Le repository actuel ne suffit donc pas toujours à reconstruire l’état historique.
Versioning et accelerator
Cette discipline rejoint directement le début du module.
Un accelerator correctement packagé doit lui aussi savoir précisément quelles versions il contient ou supporte.
Sinon :
Team A
installs accelerator today
Team B
installs same accelerator later
peuvent obtenir des comportements différents sans comprendre pourquoi.
Le package doit donc identifier ses dépendances
Conceptuellement :
ACCELERATOR v3
│
├── supported model
├── prompt
├── tools
├── configuration schema
├── eval suite
└── documentation
La réutilisabilité et le versioning sont donc étroitement liés.
Ce qu’il faut retenir pour l’examen
Face à une question de production, utilisez ce raisonnement.
1. Nouvelle version de modèle disponible
Ne répondez pas automatiquement :
Upgrade immediately.
Réflexe :
candidate
→ eval
→ gate
→ promote
2. Production exige reproductibilité
Réflexe :
Pin what ships.
3. Nouvelle version obtient de meilleurs benchmarks
Cela ne suffit pas.
Réflexe :
Test against the workload-specific eval suite.
4. La nouvelle version passe les evals
Prévoir quand même :
rollback + production monitoring.
5. Le modèle est piné mais le prompt change librement
Le système n’est pas réellement reproductible.
Réflexe :
Version model + prompt/asset + code.
6. Un modèle est deprecated
Réflexe :
create migration candidate
→ eval
→ remediate
→ deploy
Pas :
wait until retirement
→ emergency migration
7. Une question demande dans quelle phase placer le pinning
Réponse :
Deploy
8. Une question demande dans quelle phase exécuter l’eval
Réponse :
Test
Mais :
gating promotion based on the eval result
appartient à :
Deploy
Piège d’examen : « le nouveau modèle est meilleur »
Cette formulation ne suffit jamais à justifier automatiquement une migration.
General benchmark
≠
Your production workload
La réponse la plus robuste est :
evaluate
→ compare
→ decide
Piège d’examen : « pinning = seulement model ID »
Faux.
Le model ID est nécessaire, mais le comportement dépend également de :
prompt
tools
agent logic
configuration
code
Il faut pouvoir identifier l’ensemble de la release.
Piège d’examen : « eval pass = aucun besoin de rollback »
Faux.
Les evals couvrent les cas connus.
La production peut révéler des cas non représentés.
La stratégie robuste combine :
EVAL
+
MONITORING
+
ROLLBACK
Piège d’examen : « toujours utiliser l’alias le plus récent »
Cela maximise éventuellement l’accès automatique aux mises à jour.
Mais cela réduit le contrôle lorsque la reproductibilité est importante.
Dans une production contrôlée :
préférez une version explicitement identifiée et faites passer les upgrades par vos evals.
Principe → Exemple → Erreur fréquente → Bonne pratique
Principe
Traiter le modèle Claude comme une dépendance versionnée du système.
Exemple
Release 5.3
│
├── pinned model
├── prompt v18
├── tools v7
├── code commit
└── eval suite v4
Erreur fréquente
Changer de modèle directement en production parce qu’une nouvelle version possède de meilleurs benchmarks généraux.
Bonne pratique
PIN
↓
EVAL
↓
GATE
↓
DEPLOY
↓
MONITOR
↓
ROLLBACK if needed
Fiche rapide
| Concept | À retenir | Exemple | Piège d’examen |
|---|---|---|---|
Pin what ships | Identifier exactement la version déployée | Pinned model ID | Référence mouvante |
| Model ID | Dépend génération/provider | ID documenté | Supposer qu’une date est toujours nécessaire |
| Prompt versioning | Le prompt fait partie du comportement | Prompt v18 | Versionner seulement le modèle |
| Tool schema versioning | Les tools influencent Claude | Tools v7 | Modifier schema silencieusement |
| Eval baseline | Référence de comparaison | Production vs candidate | Se fier aux benchmarks publics |
| Deployment gate | Bloquer les régressions | Eval → promote | Déployer puis tester |
| Prior version | Permet rollback | N+1 → N | Supprimer immédiatement N |
| Monitoring | Vérifier production réelle | latency/errors | Croire les evals exhaustives |
| Deprecation | Anticiper migration | candidate → eval | Attendre retirement |
| Reproducibility | Reconstruire l’état exact | release manifest | Dire seulement « Sonnet » |
Le modèle mental à mémoriser
Pour la certification, retenez cette chaîne :
PIN
↓
VERSION
↓
EVAL
↓
GATE
↓
DEPLOY
↓
MONITOR
↓
ROLLBACK
Et surtout :
Never promote a model change just because the model is newer. Promote the complete candidate release because your evals show that it satisfies the requirements.
À retenir en une phrase
Le model versioning en production consiste à pin précisément ce qui est déployé, versionner le modèle avec le prompt, les tools, la configuration et le code, comparer chaque candidate à une baseline via les evals, utiliser ces résultats comme deployment gate et conserver la version précédente pour permettre un rollback contrôlé.
