Prévoir une solution de rechange et les changements

Leçon 15
40 min
Module 5 : Prendre une décision et la maintenir

Leçon 15 sur 16 · Les LLM : comment ils fonctionnent et comment en choisir unPrévoir une solution de rechange et les changements

Aperçu du cours

1. Le modèle mental d'un modèle de langage

2. Capacités et limites

3. Comment les modèles sont fournis

4. Évaluer pour votre tâche

5. Prendre une décision et la maintenir

6. Études de cas

Ce que vous saurez faire

Le modèle que vous avez choisi ne restera pas le même. Son fournisseur peut subir une panne d’une heure. Le modèle peut être retiré, et son remplaçant peut rendre inutilisable une requête qui fonctionnait. Préparez-vous à chaque situation avant qu’elle arrive, et gardez la comparaison prête à être relancée.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 40 minutes

Ce que vous devez savoir

Les exigences essentielles et les pondérations de Larkfield, et pourquoi Haiku 5.5 arrivait premier, dans La sélection pondérée.
Les jetons de raisonnement caché, et pourquoi ils comptent dans la limite de sortie, dans Raisonnement et multimodalité.
La température, dans Prédire la suite.
Qui met à jour et retire un modèle hébergé, dans Modèle hébergé ou autohébergé.

Ce qu’il vous faut

Un navigateur. Il n’y a aucun code à exécuter dans cette leçon.

Les modèles hébergés changent souvent : vos propres résultats seront différents.

Le pneu de secours

Une voiture transporte un pneu de secours. Il est moins bon que le pneu normal : il est plus petit, et vous roulez lentement avec lui. Mais quand un pneu crève sur l’autoroute, il vous permet de rentrer. Deux choses le rendent utile. Il est prêt avant la crevaison, et il fonctionne : un pneu de secours dégonflé ne sert à rien. Les conducteurs prudents vérifient sa pression de temps en temps.

Une voiture change aussi lentement. Le garage vous prévient des mois à l’avance qu’une pièce ne sera plus fabriquée. Vous choisissez la pièce de remplacement avant que l’ancienne casse, et vous vérifiez qu’elle convient.

L’assistant de Larkfield a besoin des deux : une solution de secours pour une panne soudaine et un plan pour un changement annoncé.

Trois façons dont le modèle choisi peut changer

Grace a choisi Claude Haiku 5.5. Amira énumère ce qui peut arriver à ce choix après le lancement. Chaque cas est réel, avec une date.

1. Le fournisseur est en panne

Tous les services hébergés subissent des pannes. Pendant des minutes ou des heures, les requêtes renvoient des erreurs ou prennent trop de temps. Larkfield ne peut pas réparer le service du fournisseur. Pendant une panne, les billets de soutien continuent d’arriver : Larkfield en reçoit environ 45 par jour, soit 2 par heure en moyenne.

2. Le modèle est retiré

Un fournisseur retire un modèle quand il cesse de le fournir. La page d’Anthropic sur l’abandon des modèles le définit clairement : « Retiré : le modèle n’est plus disponible. Les requêtes envoyées aux modèles retirés échoueront. »

Voici un avis réel. « Le 30 septembre 2026, Anthropic a informé les développeurs utilisant Claude Sonnet 4.5 de son prochain retrait de l’API Claude. » La date de retrait est le 30 novembre 2026, et le remplaçant recommandé est claude-sonnet-5-5. La page promet aussi « un préavis d’au moins 60 jours avant le retrait des modèles accessibles au public ».

Les modèles en préversion sont différents. Google a publié Gemini 3 Pro preview le 18 novembre 2025 et l’a désactivé le 9 mars 2026. Il s’est écoulé 16 semaines entre les deux. C’est pourquoi les exigences essentielles de Larkfield, dans la dernière leçon, demandent un modèle stable.

Une chronologie de novembre 2025 à décembre 2026 avec trois barres : Gemini 3 Pro preview, Claude Opus 4.1 et Claude Sonnet 4.5. — Trois retraits réels de modèles, tirés des pages d'abandon des fournisseurs. Un modèle stable reçoit environ deux mois de préavis; un modèle en préversion peut disparaître en quelques mois.

Pour Claude Haiku 5.5, la même page indique « Pas avant le 7 octobre 2027 ». Ce n’est pas une promesse que le modèle restera disponible jusque-là. C’est la date la plus proche possible, et l’avis arrivera au moins 60 jours avant.

3. La même requête ne fonctionne plus sur un nouveau modèle

Le troisième changement est le plus surprenant. Vous passez au modèle de remplacement, avec la même requête et les mêmes paramètres, et elle ne fonctionne plus. Voici deux exemples réels de ce cours :

La température est rejetée. Pour un assistant de soutien, vous voulez que le même billet reçoive les mêmes étiquettes chaque fois. Le code plus ancien réglait donc souvent temperature (température) à 0. La température contrôle le caractère aléatoire du choix du prochain jeton. Avec les modèles Claude actuels, la même requête échoue. Amira en a envoyé une à Claude Sonnet 5.5. La réponse :

HTTP 400
{"type":"error","error":{"type":"invalid_request_error","message":"`temperature` is deprecated for this model."}}

La page d’abandon indique que temperature, top_p et top_k renvoient une erreur 400 avec Claude 4.7 et les modèles suivants. Un code qui fonctionnait avec un ancien modèle Claude échoue sur chaque billet après le changement. Pour cette raison, le programme d’exécution du cours omet temperature pour Claude.

Le raisonnement caché épuise la limite de sortie. Gemini 3.5 Flash est un modèle de raisonnement : il consomme des jetons de raisonnement caché avant de répondre. Amira l’a d’abord exécuté avec une limite de sortie de 600 jetons, largement suffisante pour une réponse de 150 jetons. Voici la réponse complète au billet S01 :

```json
{
  "language": "en",
  "category": "delivery",
  "needs

La réponse s’arrête au milieu d’un mot. Le raisonnement caché avait utilisé presque tous les 600 jetons. Lors de cette exécution, les 24 réponses ont été coupées et aucune n’était en JSON valide. Avec une limite de 8 000, le même modèle a utilisé une médiane de 974 jetons de raisonnement par billet. Il a répondu aux 24 billets. Un paramètre sûr pour un modèle empêche un autre de fonctionner.

Un nouveau modèle peut aussi changer le coût sans aucun changement de prix. La requête de Larkfield compte 796 jetons sur Claude et 560 sur Gemini. Chaque fournisseur découpe le texte en jetons à sa façon. La page des tarifs d’Anthropic indique que Claude 4.7 et les modèles suivants utilisent un outil de segmentation plus récent. Celui-ci « produit environ 30 % plus de jetons pour le même texte ». Les mêmes billets peuvent donc coûter plus cher après un changement.

L’idée : une solution de rechange et un plan de changement

Une solution de rechange est une deuxième façon de traiter une requête, préparée et testée à l’avance. L’application l’utilise quand la première échoue. Comme le pneu de secours, elle peut être un peu moins bonne. Elle doit être prête et fonctionner.

La première question à poser est : quel échec couvre-t-elle? Une solution qui subit le même échec n’est pas une solution de rechange pour cet échec.

Claude Sonnet 5.5 ou Opus 5.5 ont satisfait à toutes les exigences essentielles. Mais ils viennent du même fournisseur que Haiku 5.5. Si le service d’Anthropic est en panne, ils le sont aussi. Ils répondent bien au problème « les brouillons de Haiku ne sont pas assez bons », pas à « le fournisseur est en panne ».
Gemini 3.5 Flash a satisfait à toutes les exigences essentielles et vient d’un autre fournisseur. Son score selon la grille était de 9,95, avec 24 réponses prêtes sur 24 (Haiku : 9,84, 24 sur 24). Il couvre une panne du service d’Anthropic, à condition de l’appeler avec une limite de sortie de 8 000 jetons.
Aucun brouillon. Le billet va dans la file des agents, comme avant l’arrivée de l’assistant. Cette solution fonctionne toujours et ne coûte rien, puisqu’une personne vérifie de toute façon chaque réponse. C’est la dernière étape.

La solution de rechange de Larkfield comporte donc trois étapes, dans cet ordre :

Un billet va à Claude Haiku 5.5; en cas d'échec, à Gemini 3.5 Flash; si celui-ci échoue aussi, à la file des agents sans brouillon. — Le parcours de rechange de Larkfield. Chaque étape sert seulement quand la précédente échoue, et l'agent peut voir laquelle a produit le brouillon.

Petit exemple détaillé : une panne de trois heures

Supposons que le service d’Anthropic tombe en panne pendant 3 heures, un après-midi chargé. Environ 12 billets arrivent (4 par heure).

Plan	Billets avec un brouillon	Coût supplémentaire
Aucune solution de rechange : l’application affiche une erreur	0 sur 12	0 $ US
Solution de rechange limitée à la file des agents	0 sur 12, mais aucune erreur : l’ancienne façon de travailler	0 $ US
Gemini 3.5 Flash, puis la file	12 sur 12 si Gemini fonctionne	12 × 0,0109 $ US = 0,13 $ US

Gemini coûte 40 fois plus cher par billet que Haiku, mais seulement pendant la panne. Une solution de rechange hébergée ne coûte rien en attente, puisque vous payez par jeton. Vous payez seulement pour les billets qu’elle traite. Une solution sur votre propre matériel est différente : la machine coûte de l’argent chaque mois, utilisée ou non.

La solution de rechange entraîne aussi d’autres coûts. Larkfield a besoin d’un deuxième compte et d’un deuxième contrat dont les conditions d’utilisation des données ont été vérifiées. Il lui faut aussi du code qui prend en charge deux fournisseurs. Marquez chaque brouillon de rechange pour que Camille et les agents sachent qu’il vient d’un autre modèle.

Quand réexaminer le choix : comparer à nouveau

Les 24 billets, les exigences essentielles, les pondérations et les exécutions enregistrées constituent la comparaison. Gardez-les, car vous referez la comparaison. Sur Haiku 5.5, une exécution des 24 billets coûte environ 24 × 0,00027 $ US, soit moins d’un cent. Elle prend environ une minute. Une exécution sur les cinq modèles hébergés a coûté moins de 1 $ US.

Refaites-la quand l’un de ces déclencheurs survient :

Un avis de retrait du modèle choisi ou du modèle de rechange. Exécutez les 24 billets sur le remplaçant recommandé dans les deux premières semaines. Changez de modèle au moins deux semaines avant la date de retrait.
Un nouveau modèle ou une nouvelle version que vous pourriez utiliser. Ne changez jamais de modèle sur la seule parole du fournisseur.
Un changement de prix, ou de la façon de compter les jetons. Recalculez le score de coût.
De nouveaux types de billets. Si les agents constatent des échecs non couverts par les 24 billets, ajoutez d’abord des billets de ce type. Puis relancez la comparaison.
Une date fixe, par exemple tous les trois mois, même si rien d’autre n’est arrivé.

Avant tout changement, vérifiez la requête et les paramètres, pas seulement les scores :

Envoyez la requête avec les paramètres exacts de production : limite de sortie, température (ou aucune), et paramètre d’« effort » ou de raisonnement.
Vérifiez que les 24 réponses sont en JSON valide et qu’aucune n’a été arrêtée par la limite.
Vérifiez la langue des 12 billets en français ou en langues mixtes.
Recalculez le coût par billet avec les nombres de jetons propres au nouveau modèle.
Appliquez les mêmes exigences essentielles et pondérations. Écrivez le résultat à côté de l’ancien.

Quand l’utiliser et ce que cela coûte

Prévoyez une solution de rechange pour chaque assistant dont les gens dépendent pendant la journée. Prévoyez le processus de changement pour chaque modèle hébergé, car tous les modèles hébergés sont retirés un jour.

Gardez un plan proportionné. L’assistant de Larkfield rédige seulement des brouillons de réponses, et une personne vérifie chacun. Ainsi, « aucun brouillon » est une dernière étape acceptable, et un seul modèle de rechange suffit. Un assistant qui répond directement aux clients, sans intermédiaire humain, a besoin d’un plan plus strict. Pour lui, la file humaine n’est pas une dernière étape sans conséquence.

Les coûts comprennent un deuxième fournisseur à gérer, un peu de code et des tests occasionnels de la solution de rechange. Une solution de rechange jamais testée est comme un pneu de secours dégonflé.

Exercice guidé : répondre à l’avis réel

Supposons que Larkfield ait lancé son assistant pendant l’été avec Claude Sonnet 4.5. Le 30 septembre 2026, l’avis arrive.

Écrivez la date de retrait et le remplaçant recommandé dans l’avis.
Écrivez la date limite pour avoir exécuté les 24 billets sur le remplaçant.
Écrivez la date limite pour changer le modèle en production.
Énumérez les deux paramètres à vérifier en premier, à cause des exemples de cette leçon.
Écrivez ce qui arrive aux billets de Larkfield le 1er décembre 2026 si personne n’agit.

Exemple de réponse

Retrait le 30 novembre 2026; remplaçant claude-sonnet-5-5.
Le 14 octobre 2026 : deux semaines après l’avis.
Le 16 novembre 2026 : deux semaines avant le retrait, pour avoir le temps de corriger un problème.
La température : Sonnet 5.5 renvoie une erreur 400 quand elle est définie. La limite de sortie : le raisonnement compte dans les jetons de sortie, donc une petite limite peut couper la réponse.
Chaque requête envoyée à claude-sonnet-4-5-20250929 échoue. Avec le parcours de rechange, chaque billet va à Gemini 3.5 Flash. Le coût par billet est environ trois fois celui de Sonnet 5.5. Sans solution de rechange, aucun billet ne reçoit de brouillon.

À vous de jouer : la solution de rechange parfaite de Tomás

Tomás propose Claude Opus 5.5 comme seule solution de rechange. « Il a obtenu la note maximale sur les 24 billets, et il est deuxième au classement. »

Lesquels des trois changements de cette leçon Opus couvre-t-il, et lesquels ne couvre-t-il pas? Dans quel cas l’utiliseriez-vous?

Exemple de réponse

Opus ne couvre pas une panne du service d’Anthropic : il est en panne en même temps que Haiku. Il ne couvre pas non plus un paramètre incompatible si le même code appelle les deux modèles. Il couvre un autre événement : les brouillons de Haiku ne sont finalement pas assez bons, ou sa qualité baisse avec une nouvelle version. Pour cela, Opus est un bon deuxième choix testé : il satisfait à toutes les exigences essentielles et a obtenu la note maximale. Sa note maximale ne le rend pas meilleur que Haiku dans ce test, car leurs scores de qualité sont égaux. Et il coûte 35 fois plus cher par billet. Gardez donc Opus comme autre choix pour la qualité dans la note. Gardez Gemini 3.5 Flash et la file des agents comme solution de rechange en cas de panne.

Erreur courante

La solution de rechange n'a jamais été testée avec ses vrais paramètres

Symptôme : pendant une panne, l’application passe au modèle de rechange, et chaque brouillon échoue. Les journaux (logs) montrent des réponses qui s’arrêtent au milieu du JSON, comme "needs.

Cause : le modèle de rechange a été appelé avec les paramètres du modèle principal, par exemple une limite de sortie de 600 jetons. Le modèle de rechange est un modèle de raisonnement. Son raisonnement caché a épuisé la limite avant la rédaction de la réponse. C’est ce que Gemini 3.5 Flash a fait sur les 24 billets avec 600 jetons.

Correction : donnez au modèle de rechange ses propres paramètres (pour Gemini 3.5 Flash, une limite de 8 000 jetons). Exécutez les 24 billets sur ce modèle exactement comme en production. Répétez cette exécution à une date fixe et après chaque changement de la requête. Dans un vrai service, envoyez aussi une petite part du trafic normal au parcours de rechange de temps en temps. Vous saurez ainsi qu’il fonctionne avant d’en avoir besoin.

Vérifiez votre compréhension

Pourquoi Claude Sonnet 5.5 n'est-il pas une solution de rechange pour une panne de Claude Haiku 5.5, malgré sa conformité à toutes les exigences essentielles?

Afficher la réponse

Les deux modèles viennent du même fournisseur et du même service. Quand ce service est en panne, les deux le sont. Une solution de rechange pour une panne ne doit pas subir le même échec. Elle doit donc venir d’un autre fournisseur (Gemini 3.5 Flash) ou n’utiliser aucun modèle (la file des agents). Sonnet reste un autre choix possible pour d’autres raisons, par exemple si la qualité de Haiku baisse avec une nouvelle version.

Vérifiez votre compréhension

Prédisez : Amira passe d'un ancien modèle Claude à Claude Haiku 5.5. Son code règle la température à 0 et la limite de sortie à 600. Que se passe-t-il, et que doit-elle vérifier?

Afficher la réponse

Chaque requête échoue avec HTTP 400 : « temperature n’est plus pris en charge pour ce modèle. » Elle doit retirer temperature. Ensuite, elle doit vérifier la limite de sortie : Claude compte le raisonnement dans les jetons de sortie. Une petite limite peut donc couper les réponses. Puis elle exécute les 24 billets : toutes les réponses en JSON valide, aucune arrêtée par la limite, la bonne langue pour les 12 billets en français ou en langues mixtes, et le nouveau coût par billet.

Vérifiez votre compréhension

Nommez trois déclencheurs qui devraient amener Larkfield à refaire la comparaison des 24 billets.

Afficher la réponse

Trois éléments parmi ceux-ci : un avis de retrait du modèle choisi ou du modèle de rechange; un nouveau modèle ou une nouvelle version qui pourrait le remplacer; un changement de prix ou de la façon de compter les jetons; de nouveaux types de billets ou des échecs non couverts par les 24 billets; une date fixe, par exemple tous les trois mois.

Récapitulatif

Trois changements arriveront certainement : des pannes, des retraits et de nouveaux modèles qui rendent une ancienne requête inutilisable.
Un avis réel : Claude Sonnet 4.5, retrait annoncé le 30 septembre 2026, modèle retiré le 30 novembre 2026. Après le retrait, chaque requête échoue. Les modèles en préversion peuvent disparaître en quelques mois.
La même requête peut échouer sur un nouveau modèle : temperature renvoie une erreur 400 sur les modèles Claude actuels. Une limite de 600 jetons a coupé toutes les réponses de Gemini 3.5 Flash à cause du raisonnement caché.
Une solution de rechange ne doit pas subir le même échec. Le parcours de Larkfield : Haiku 5.5, puis Gemini 3.5 Flash avec ses propres paramètres, puis la file des agents.
Gardez les 24 billets, les règles et les exécutions. Relancez-les à chaque déclencheur, et vérifiez les paramètres avant de changer de modèle.

Leçon suivante : Communiquer la recommandation