Changer de modèle dans un RAG ou un agent en production se décide sur un jeu de test, pas sur une date de sortie. On migre quand le nouveau modèle fait mieux sur vos vraies questions, ou fait aussi bien pour moins cher, ou quand l'éditeur annonce le retrait de l'ancien. Dans tous les autres cas, on laisse le modèle en place.
L'exemple du jour : Claude Fable 5.2 est sorti le 9 novembre 2026, à 8 $ par million de tokens en entrée et 40 $ en sortie, contre 10 $ et 50 $ pour Fable 5.1 (prix Anthropic). La baisse est réelle. Elle ne dit rien de ce que le modèle fera sur vos documents. La méthode ci-dessous vaut pour cette sortie comme pour la suivante.
Cet article s'adresse aux responsables techniques et aux dirigeants d'éditeurs de logiciel qui ont déjà un assistant en service. Pour juger le modèle lui-même, voir notre analyse de Claude Fable 5.2 pour l'entreprise et le comparatif avec Opus 5.5, GPT-6 Sol et Gemini 4 Argon.
Points clés à retenir
- On ne migre pas parce qu'un modèle sort : on migre quand le jeu de test le justifie, ou quand l'ancien modèle est retiré
- Trois raisons valables : qualité mesurée, coût ou latence à qualité égale, fin de vie annoncée
- Méthode : jeu de test figé, rejeu à l'identique, notation binaire, coût et latence, niveaux d'effort, déploiement par paliers, retour arrière
- Ce qui casse est rarement la qualité brute : historique, outils forcés, format des sorties, tours qui s'arrêtent trop tôt
- Changer le modèle de génération ne réindexe rien ; changer le modèle d'embeddings oblige à tout réindexer
Les trois raisons valables de changer de modèle
Il existe trois raisons valables de changer de modèle LLM en production : une qualité mesurée meilleure sur vos cas, un coût ou une latence plus bas à qualité égale, ou une fin de vie annoncée de l'ancien modèle. Tout le reste relève de l'effet d'annonce.
| Raison de changer | Valable ? | Ce qui le prouve |
|---|---|---|
| Qualité mesurée meilleure | Oui | Le pourcentage de réponses justes monte sur votre jeu de test, sans régression sur les questions sensibles |
| Coût ou latence en baisse | Oui, à qualité égale | Même pourcentage de réponses justes, coût par requête et temps de réponse mesurés plus bas |
| Fin de vie de l'ancien modèle annoncée | Oui, avec une date | L'éditeur publie une date de retrait : la migration devient un chantier planifié |
| Le modèle vient de sortir | Non | Aucune mesure sur vos données |
| Un classement public le place en tête | Non | Les benchmarks mesurent d'autres tâches que les vôtres |
| Un concurrent a communiqué dessus | Non | Aucun lien avec votre cas d'usage |
La troisième raison est la seule qui ne laisse pas le choix. Les éditeurs publient des dates de retrait pour leurs anciens modèles : vérifiez-les dans la documentation de l'éditeur, par exemple la page des nouveautés de Fable 5.2 sur platform.claude.com. Une migration subie dans l'urgence coûte toujours plus cher qu'une migration planifiée.
Les scores d'éditeur ne remplacent pas votre mesure
Anthropic publie des scores pour Fable 5.2, par exemple 69,9 % sur FrontierSWE v2 (code agentique) contre 56,3 % pour Fable 5.1, ou 51,4 % sur AutomationBench (processus métier). Ce sont des chiffres de l'éditeur, sur des tâches qui ne sont pas les vôtres. Ils justifient de tester, pas de migrer.
La méthode : sept étapes pour migrer sans surprise
La méthode repose sur un principe : le jeu de test décide. C'est la même logique que pour évaluer un RAG, détaillée dans notre article sur la notation binaire avec Ragas et Langfuse. Un changement de modèle est un cas particulier de test de régression.
| Étape | Ce qu'on fait | Ce qu'on obtient |
|---|---|---|
| 1. Figer le jeu de test | 20 à 50 questions réelles, avec la réponse attendue et le document source | Une référence qui ne bouge plus |
| 2. Rejouer à l'identique | Ancien et nouveau modèle, même prompt, même index, mêmes passages | Deux séries de réponses comparables |
| 3. Noter en binaire | Juste ou faux, juge LLM calibré, relecture humaine d'un échantillon | Un pourcentage de réponses justes par modèle |
| 4. Comparer coût et latence | Tokens consommés, prix au million de tokens, temps de réponse | Un coût par requête et un temps de réponse |
| 5. Balayer les niveaux d'effort | low, medium, high, selon le modèle | Le niveau le moins cher qui tient la qualité |
| 6. Déployer par paliers | Une part du trafic, puis davantage | Des retours réels avant la bascule complète |
| 7. Garder le retour arrière | Modèle en configuration, ancien identifiant actif | Une marche arrière en quelques minutes |
Figer un jeu de test tiré du réel
Le jeu de test reprend de vraies questions d'utilisateurs ou de vraies tâches, chacune avec sa réponse attendue et son document source. Sur nos projets, 20 à 50 questions suffisent pour démarrer, prêtes en 2 à 3 jours. Si vous n'avez pas de point de départ, le protocole détaillé sur ianas.fr, évaluer un RAG en production, décrit comment la construire.
Rejouer l'ancien et le nouveau modèle à l'identique
Un seul paramètre change : le modèle. Même prompt système, même index, mêmes passages récupérés, même température. Sinon, on ne sait plus ce qu'on mesure. On rejoue aussi l'ancien modèle le jour du test, car il peut avoir évolué depuis la dernière mesure.
Noter en binaire, relire un échantillon
Chaque réponse est notée juste ou fausse, par un juge LLM calibré sur des notes humaines. Un humain du métier relit un échantillon, et en priorité toutes les régressions : les questions justes avant, fausses après. Un pourcentage global stable peut cacher dix questions gagnées et dix perdues. Le principe est repris dans notre article sur la mesure de la performance d'un RAG.
Comparer coût par requête et latence
Le prix au million de tokens ne suffit pas. Un modèle moins cher au token peut consommer davantage de tokens de réflexion, un modèle plus cher peut finir en moins d'étapes. On mesure le coût par requête complète et le temps de réponse sur le jeu de test.
Sur Fable 5.2, Anthropic indique qu'en effort high le modèle égale le meilleur score d'Opus 5.5 sur FrontierCode 2.0 (45,3 % contre 45,5 %) pour environ la moitié du coût par tâche. C'est un chiffre de l'éditeur sur du code : à reproduire sur vos tâches avant d'en tirer quoi que ce soit.
Tester les niveaux d'effort
Fable 5.2 expose cinq niveaux d'effort (low, medium, high, xhigh, max), avec high par défaut côté API et medium dans les applications et Claude Code. Un assistant de questions-réponses simple tient souvent à un niveau plus bas, pour un coût et une latence réduits. On balaie les niveaux sur le jeu de test et on retient le moins cher qui garde le pourcentage de réponses justes.
Déployer par paliers, garder le retour arrière
On bascule d'abord une part du trafic, on surveille les retours et les traces, puis on étend. Le modèle doit être un paramètre de configuration, pas une constante dans le code, et l'ancien identifiant reste actif jusqu'à la fin de la période d'observation. Un retour arrière doit se faire en minutes.
Ce qui casse quand on change de modèle
Ce qui casse n'est pas toujours la qualité des réponses : ce sont souvent des détails d'intégration qui changent entre deux versions. Voici les points listés par Anthropic pour la migration de Fable 5.1 vers Fable 5.2, présentés comme symptôme, cause et vérification.
| Symptôme | Cause probable | Quoi vérifier |
|---|---|---|
| Erreur 400 sur une conversation en cours | L'historique a été modifié (résumé, message retiré) alors qu'il contient des blocs de réflexion : le contrôle de préfixe invalide l'ensemble | Ne plus modifier l'historique d'un tour déjà produit, ou réécrire la conversation en entier plutôt que par morceaux |
| Un agent perd le fil après quelques tours | Un routeur change de modèle en cours de conversation : les blocs de réflexion de Fable 5.2 ne sont lus que par Fable 5.2 et Mythos 5.2 | Garder le même modèle du début à la fin d'une conversation, ou assumer la perte du raisonnement au changement |
| Appel refusé sur un outil précis | L'usage forcé d'un outil (tool_choice de type any ou tool) n'est pas accepté | Laisser le modèle choisir l'outil et décrire dans le prompt quand l'appeler |
| Erreur sur l'outil de pilotage d'ordinateur | L'ancienne version de l'outil (computer_20251124) renvoie une erreur hors Bedrock | Passer à la version actuelle de l'outil, puis rejouer les scénarios d'interface |
| Le ton ou le format de réponse a changé | Les consignes de style sont suivies de plus près : une consigne ambiguë ou périmée est désormais appliquée | Relire le prompt système, supprimer les consignes qui ne servent plus, comparer des réponses côte à côte |
| Une tâche longue s'arrête avant la fin | Un tour peut se terminer avant l'achèvement complet du travail | Vérifier le motif d'arrêt de chaque tour et relancer ou boucler explicitement jusqu'à la fin de la tâche |
| Réponses plus lentes ou plus chères que prévu | Le niveau d'effort par défaut a changé, ou la délégation à des sous-agents pèse sur le coût | Mesurer le coût par session complète, balayer les niveaux d'effort, limiter les sous-agents |
| Une consigne « réponds sans réfléchir » ne change rien | À partir du niveau medium, cette consigne ne coupe pas la réflexion | Régler le niveau d'effort (low pour les réponses courtes) plutôt que la consigne |
L'historique de conversation et la réflexion
Les modèles récents produisent des blocs de réflexion, que l'API renvoie et attend de retrouver dans l'historique. Si votre application résume, tronque ou réécrit l'historique, le contrôle de préfixe le détecte et renvoie une erreur 400. Un routeur qui bascule de modèle au milieu d'une conversation pose un problème voisin : les blocs de réflexion de Fable 5.2 ne sont lus que par Fable 5.2 et Mythos 5.2, le raisonnement précédent est perdu.
Les consignes de style, mieux suivies
Quand un modèle suit les consignes de plus près, un prompt écrit pour l'ancien modèle produit un autre résultat : une consigne ambiguë est enfin appliquée, une vieille règle oubliée aussi. La bonne réaction est de relire le prompt, pas de le gonfler. Chaque phrase qui ne sert plus se retire.
Les garde-fous et les refus
Fable 5.2 bloque l'activité cyber à haut risque et la plupart des tâches de biologie de recherche, et traite la requête bloquée avec un autre modèle (Opus 4.8 pour le cyber, Opus 5 pour la biologie). Pour un assistant métier classique, c'est sans effet. Pour un RAG sur de la documentation de sécurité ou de recherche, rejouez ces questions en priorité.
Le cas du RAG : le modèle de génération change, pas l'index
Dans un RAG, changer le modèle qui rédige la réponse ne touche pas à l'index. Les documents, les découpages et les vecteurs restent en place. Le seul impact vient de ce que le modèle fait des passages qu'on lui envoie : ton, longueur, citation des sources, refus de répondre quand l'information manque.
Ne confondez pas avec le modèle d'embeddings. Celui-ci produit les vecteurs de l'index. Si vous le changez, les nouveaux vecteurs ne sont pas comparables aux anciens : il faut réindexer tout le corpus, puis rejouer le jeu de test. Mélanger deux modèles dans un même index casse la recherche. C'est d'ailleurs l'un des bugs rencontrés en audit : un modèle d'embeddings différent à l'indexation et à la recherche. Le sujet est traité côté exploitation dans notre article sur la maintenance d'un RAG en production.
Dans la pratique, on garde les deux changements séparés : d'abord le modèle de génération, mesure, bascule ; ensuite, si besoin, les embeddings, avec réindexation et nouvelle mesure. Deux changements à la fois, et vous ne saurez plus lequel a fait bouger le chiffre.
Le cas des agents : outils, sorties structurées, garde-fous, coût
Un agent est plus sensible au changement de modèle qu'un RAG, parce qu'il enchaîne des décisions : quel outil appeler, avec quels arguments, quand s'arrêter. Une petite différence de comportement se répercute sur toute la chaîne.
| RAG | Agent | |
|---|---|---|
| Ce qui change avec le modèle | La génération de la réponse, pas l'index | Choix des outils, enchaînement des actions, arrêt |
| Ce qui peut casser | Style de réponse, refus, citation des sources | Appels d'outils, sorties structurées, historique, boucle de tâche |
| Ce qu'on rejoue | Questions isolées avec réponse attendue | Scénarios complets, de la demande au résultat final |
| Risque de coût | Tokens des passages envoyés au modèle | Longues sessions, sous-agents, nombre d'étapes |
Appels d'outils et sorties structurées
Vérifiez que chaque outil est toujours appelé avec les bons arguments, et que les sorties au format JSON respectent votre schéma. Sur Fable 5.2, l'usage forcé d'un outil (tool_choice de type any ou tool) n'est pas accepté : il faut décrire dans le prompt quand appeler l'outil, et laisser le modèle décider. L'ancien outil de pilotage d'ordinateur renvoie aussi une erreur hors Bedrock.
Tours qui s'arrêtent et sessions qui coûtent
Un tour peut se terminer avant la fin d'une tâche longue : le code qui pilote la boucle doit vérifier le motif d'arrêt, pas supposer que la tâche est faite. Autre point : la délégation à des sous-agents peut peser lourd dans le coût d'une session. On mesure donc le coût d'une session complète, de la demande au résultat, pas celui d'un appel isolé.
Rejouer des scénarios, pas des questions
Le jeu de test d'un agent est une liste de scénarios, avec le résultat final attendu et la liste des outils qui devaient être appelés. Notation binaire aussi : la tâche est-elle accomplie, oui ou non. C'est plus long à construire que pour un RAG, et c'est ce qui évite de découvrir les régressions chez le client.
Combien de temps ça prend, et qui le fait
Les durées dépendent surtout de l'existence d'un jeu de test. S'il existe, un rejeu, l'analyse des écarts et les corrections se comptent en jours, jusqu'à une semaine pour un RAG, un peu plus pour un agent riche en outils. S'il n'existe pas, il faut d'abord le construire, ce qui prend 2 à 3 jours pour les premières questions sur nos projets, puis le déploiement par paliers s'étale sur quelques jours à quelques semaines selon le trafic.
Côté équipe, il faut un développeur qui connaît le pipeline, un expert du métier pour relire les verdicts, et quelqu'un qui décide, souvent le responsable produit ou technique. Si vous n'avez pas cette ressource en interne, c'est ce que fait notre audit RAG et agents IA : on rejoue vos vrais cas sur le nouveau modèle avant de migrer, et on vous rend la comparaison question par question. Sur devis selon le périmètre.
Ce qu'on en retient
À retenir
- Le jeu de test décide : pas de mesure, pas de migration.
- Rejouez l'ancien et le nouveau modèle à l'identique, notez en binaire, relisez toutes les régressions.
- Comparez le coût par requête complète et testez les niveaux d'effort.
- Vérifiez l'historique, les outils, les sorties structurées et la fin des tours avant de basculer.
- Séparez le changement de modèle de génération et celui des embeddings.
- Déployez par paliers et gardez le retour arrière.
Questions fréquentes sur le changement de modèle LLM en production
Un nouveau modèle vient de sortir et votre assistant est en production ?
On rejoue vos vrais cas sur le nouveau modèle avant de migrer : jeu de test, notation binaire, coût par requête, points de friction. Sur devis selon le périmètre.
Voir l'audit RAG et agents IAPour aller plus loin
- Claude Fable 5.2 pour l'entreprise
- Fable 5.2, Opus 5.5, GPT-6 Sol ou Gemini 4 Argon : lequel choisir
- Évaluer un RAG : Ragas, Langfuse ou notation binaire
- Sur ianas.fr : évaluer un RAG en production avec les métriques Ragas
Sources consultées le 10 novembre 2026 : annonce Claude Fable 5.2 et Mythos 5.2 (Anthropic) et nouveautés de Fable 5.2 (documentation Claude).
Formation
Pour que vos équipes appliquent ces usages sur leurs propres documents, voir notre formation RAG, construite sur vos cas.
