Quand utiliser quel modèle

La démonstration de cette vidéo a été enregistrée en août 2026. Elle s'est déroulée sur Claude Haiku 4.5, Claude Sonnet 5 et Claude Opus 5. Les résultats différeront sur les modèles plus récents. La démonstration de chaque leçon correspond à une exécution d'évaluation distincte, de sorte que ses scores et ses coûts ne correspondront pas à ceux des autres leçons.

Lorsque vous choisissez un modèle Claude pour une tâche, vous vous fiez probablement à votre instinct, ou à l'avis d'un collègue. Les modèles de Claude diffèrent effectivement par leurs capacités, leur rapidité et leur coût, mais aucune comparaison publiée n'a jamais vu votre requête spécifique, si bien qu'aucune d'entre elles ne peut vous dire comment un modèle se comportera sur votre tâche. La bonne façon de choisir est de mesurer à quelle fréquence chaque modèle réussit votre tâche, et seulement ensuite de regarder ce que chacun coûte.

C'est un peu comme acheter une échelle pour atteindre le sommet d'un mur. Avant de regarder les prix, vous déterminez la hauteur du mur, car une échelle trop courte ne sert à rien, quel qu'en soit le prix. Deviner ne vous dira pas quelles échelles atteignent le sommet, vous les mesurez donc, et parmi celles qui l'atteignent, vous achetez la moins chère. Un mur plus haut nécessite une échelle plus longue, et c'est celle-là qu'il faut acheter, même si elle coûte plus cher.

Avec les modèles, cette mesure se fait au moyen d'une évaluation (eval), c'est-à-dire un ensemble de cas sur lesquels vous exécutez chaque modèle. Chaque cas correspond à une entrée que votre requête va recevoir et à la réponse que vous attendez en retour, et une personne rédige cette réponse à partir de l'entrée avant qu'aucun modèle ne s'exécute. Chaque exécution obtient ensuite un score correspondant au nombre de cas que le modèle a traités correctement.

Cette leçon suit Meridian. Chaque mois, l'entreprise reçoit 50 rapports de projet au format Markdown, et une requête extrait trois champs de chacun d'eux : l'identifiant du projet, le statut du calendrier et le risque principal. Ses cas sont les 50 rapports d'un mois, et ce qu'elle ne sait pas encore, c'est quel modèle doit exécuter cette requête.

Meridian procède en cinq étapes, que vous pouvez suivre avec votre propre requête :

1. Déterminer le niveau de précision requis pour un modèle
2. Évaluer chaque modèle sur les mêmes cas
3. Calculer le coût d'un appel
4. Comparer les modèles selon le coût de chaque tâche accomplie
5. Choisir le modèle offrant la précision requise au coût le plus bas

Déterminer le niveau de précision requis pour un modèle

C'est la hauteur du mur, et vous la déterminez avant de regarder le coût de quoi que ce soit. Votre seuil de précision est la part des cas qu'un modèle doit réussir avant que vous acceptiez de le déployer. Pour fixer ce seuil, déterminez ce que vous coûte une réponse erronée, car plus elle coûte cher, plus votre seuil doit être élevé.

Pour Meridian, une réponse erronée signifie que quelqu'un doit vérifier ce rapport à la main, ce qui prend environ 5 minutes. Ses ingénieurs peuvent absorber 5 de ces vérifications par mois, et comme 5 sur 50 représente 10 %, le seuil de Meridian est de 90 %.

Une tâche différente peut pousser le seuil beaucoup plus haut. Supposons qu'une réponse erronée coûte 1 000 $, peut-être parce qu'elle a été transmise à un client. Le seuil passe alors à 100 %, et ce que coûte le modèle n'a presque plus d'importance.

Évaluer chaque modèle sur les mêmes cas

Un seuil n'est qu'un chiffre tant que vous n'y mesurez pas les modèles. Exécutez chaque modèle sur les mêmes cas avec la même requête, de sorte que le modèle soit la seule variable qui change d'une exécution à l'autre. Meridian a soumis ses 50 rapports à une même requête sur trois modèles : Claude Haiku 4.5, Claude Sonnet 5 et Claude Opus 5.

Un script de Meridian vérifie chaque champ par rapport à la réponse attendue. L'identifiant du projet et le statut du calendrier doivent correspondre exactement, mais le risque principal est une phrase, donc le script la compare de façon plus souple et tolère de légères variations de formulation. Chaque cas correspond à une tâche, qui pour Meridian signifie un rapport dont il faut extraire trois champs. Un modèle accomplit la tâche uniquement lorsqu'il obtient les trois champs correctement.

Sur les 50 cas, 30 sont des rapports classiques, 10 couvrent plusieurs projets à la fois, et 10 n'ont pas de section sur les risques. Le tableau détaille le score de chaque modèle selon ces trois catégories.

Part des cas réussis par chaque modèle, par type de rapport, avec la même requête et un seuil de 90 %

Sonnet 5 et Opus 5 ont tous deux réussi les 50 cas. Haiku 4.5 en a réussi 42 sur 50, soit 84 %, ce qui signifie que, pour cette tâche et avec cette requête, il n'atteint pas le seuil.

Calculer le coût d'un appel

Maintenant que deux modèles ont franchi le seuil, le coût entre en jeu. Vous êtes facturé au jeton, une unité de texte que les modèles traitent, et chaque réponse de l'API Messages inclut un bloc usage qui contient le nombre exact de jetons pour lesquels vous êtes facturé. L'exemple ci-dessous est une illustration, un appel Sonnet 5 de la taille d'un des appels de Meridian, avec 780 jetons d'entrée et 41 jetons de sortie.

"usage": {
  "input_tokens": 780,
  "output_tokens": 41
}

Relevez ces chiffres dans usage pour chaque modèle plutôt que de les estimer à partir de votre texte. Le tokenizer d'un modèle est la partie qui découpe le texte en jetons, et tous les modèles n'utilisent pas le même. Ainsi, un même texte peut donner un nombre de jetons différent selon les modèles. Sonnet 5 et Opus 5 utilisent un tokenizer plus récent qui produit environ 30 % de jetons en plus pour le même texte, et Haiku 4.5 utilise le précédent.

Les jetons d'entrée et les jetons de sortie ont des tarifs distincts, chacun indiqué par million de jetons. Le tableau présente les tarifs des trois modèles tels qu'ils étaient listés en août 2026, c'est-à-dire au moment où Meridian a exécuté l'évaluation, et la page tarifaire de Claude indique les tarifs en vigueur aujourd'hui.

Tarif de chaque modèle par million de jetons d'entrée et de sortie, tel qu'indiqué en août 2026

Le coût d'un appel correspond à ses jetons d'entrée multipliés par le tarif d'entrée, plus ses jetons de sortie multipliés par le tarif de sortie. L'exemple est un appel Sonnet 5, il utilise donc les tarifs de Sonnet 5 indiqués dans ce tableau.

780 input tokens  × $2 per million  = $0.0016
 41 output tokens × $10 per million = $0.0004
                              total = $0.0020

Comparer les modèles selon le coût de chaque tâche accomplie

Additionnez le coût de chaque appel d'une exécution, et ce total est appelé le coût d'exécution. Divisez le coût d'exécution par le nombre de tâches accomplies par le modèle, vous obtenez alors le coût par tâche accomplie, qui est la valeur sur laquelle vous comparez les modèles.

Vous divisez par les tâches accomplies, et non par les appels. En effet, chaque appel est facturé, même celui qui échoue la tâche. Ainsi, les réponses erronées d'un modèle s'ajoutent au coût de chaque tâche que ce même modèle accomplit effectivement.

Coût d'exécution et coût par tâche accomplie pour les 50 cas, aux tarifs indiqués en août 2026

Choisir le modèle offrant la précision requise au coût le plus bas

Votre seuil détermine quels modèles sont candidats, et parmi ceux-ci, vous choisissez celui dont le coût par tâche accomplie est le plus bas. Sonnet 5 et Opus 5 ont tous deux réussi 50 tâches sur 50, pour respectivement 0,0020 $ et 0,0046 $ par tâche accomplie, donc pour cette tâche, Meridian choisit Sonnet 5. Le chiffre de 0,0009 $ d'Haiku 4.5 est le plus bas du tableau, mais ce modèle n'est pas candidat, car il n'atteint pas le seuil.

Sur une tâche plus difficile, le modèle le plus performant pourrait être le seul à franchir le seuil, et ce serait alors le bon choix. Chaque résultat est également lié à la requête et aux cas utilisés par l'évaluation. Si vous modifiez la requête ou les cas, le bon modèle peut changer lui aussi, exécutez donc à nouveau l'évaluation chaque fois que vous modifiez l'un ou l'autre.

Cette évaluation ne mesure pas la latence. Si vos utilisateurs attendent les réponses, chronométrez les réponses sur vos propres cas, de la même manière que vous les avez évaluées ici.

Réduire le coût d'exécution de l'évaluation

Ces cinq étapes vous permettent de déterminer un modèle, et il existe un moyen supplémentaire de réduire le coût de l'évaluation elle-même. Personne n'attend les réponses d'une évaluation, vous pouvez donc l'envoyer via la Batch API, qui traite les requêtes de façon asynchrone. La Batch API exécute les mêmes modèles à moitié prix sur les jetons d'entrée et de sortie.

Lorsque vous comparez des modèles, ne mélangez pas les tarifs batch et les tarifs standard dans une même comparaison. Calculez le coût de chaque modèle aux tarifs batch, ou le coût de chaque modèle aux tarifs standard.

En résumé

1. Fixez d'abord votre seuil de précision, en fonction de ce que vous coûterait une réponse erronée.
2. Soumettez chaque modèle aux mêmes cas, et écartez tout modèle qui n'atteint pas le seuil.
3. Relevez le coût de chaque appel dans son bloc usage, puis divisez le coût d'exécution par le nombre de tâches accomplies par le modèle.
4. Parmi les candidats qui atteignent le seuil, choisissez celui dont le coût par tâche accomplie est le plus bas.