Les modèles Claude

Objectifs

• Connaître les différents modèles Claude disponibles
• Comparer leur vitesse et leurs capacités

La famille de modèles Claude

Le paramètre model que vous avez recopié sans y penser dans les leçons précédentes est en réalité l’une des décisions les plus structurantes de votre application. Le SDK Python donne accès à plusieurs modèles, et changer cette seule chaîne de caractères peut diviser votre facture par dix ou doubler votre temps de réponse, sans toucher une ligne du reste de votre code.

Trois facteurs guident ce choix, et ils tirent malheureusement dans des directions opposées. La latence décrit la vitesse à laquelle le modèle répond, ce qui détermine si votre interface reste agréable à utiliser. Les capacités décrivent sa performance sur les tâches difficiles : raisonnement, code, nuance. Le coût décrit ce que chaque appel vous facture, donnée qui paraît anecdotique en prototype et devient centrale dès les premiers milliers d’utilisateurs. Aucun modèle n’est premier sur les trois axes ; votre travail consiste à choisir lequel sacrifier. Consultez la table de comparaison officielle pour un aperçu détaillé des caractéristiques de chacun.

Comparer les vitesses

L’écart de latence entre les modèles se mesure très simplement : envoyez la même requête à chacun d’eux et chronométrez. Les modèles plus légers, comme Haiku, sont nettement plus rapides que les modèles plus puissants, comme Opus. Voici l’ordre de grandeur que vous observerez pour une même requête.

L’enseignement pratique de cette mesure est contre-intuitif. Avec un prompt simple — reformuler une phrase, extraire une date, classer un message dans une catégorie — tous les modèles produisent une réponse satisfaisante. Dans ce cas, le modèle le plus rapide et le moins cher est souvent le meilleur choix : payer davantage n’achète aucune qualité supplémentaire sur une tâche que le plus petit modèle réussit déjà.

Comparer les capacités

Si Haiku est le plus rapide, pourquoi utiliser les autres ? Parce que la vitesse se paie en qualité dès que la tâche se complique. C’est un compromis entre vitesse, coût et qualité : Haiku est rapide mais ses sorties peuvent être moins abouties que celles de Sonnet ou d’Opus sur des tâches complexes, celles qui demandent de tenir plusieurs contraintes à la fois ou de raisonner sur plusieurs étapes.

Claude Sonnet est recommandé sur cinq familles d’usages qui illustrent bien ce seuil de complexité. En code, il écrit, édite et exécute du code, ce qui suppose de comprendre une intention et de produire une sortie syntaxiquement exacte. En support client, il comprend le contexte d’un échange et orchestre des workflows, donc enchaîne des actions dépendantes les unes des autres. En data science, il navigue dans des données non structurées et génère des analyses. En traitement visuel, il interprète des graphiques, des images et des tableaux. En rédaction enfin, il saisit les nuances, l’humour et produit du contenu authentique — précisément ce qu’un modèle plus léger rend de façon plus plate.

Choisir un modèle

Approche recommandée : commencer par Haiku

Haiku est un excellent point de départ pour prototyper. Sa rapidité et son faible coût vous permettent d’itérer vite, de multiplier les essais de prompt sans surveiller la facture, et de découvrir la vraie difficulté de votre tâche. Si les résultats ne sont pas satisfaisants, il suffit de passer à Sonnet ou à Opus : une chaîne de caractères à modifier. La démarche inverse — démarrer sur le modèle le plus puissant — vous prive de cette information et vous installe durablement dans un coût que vous n’avez jamais justifié.

Évaluer et monter en gamme

Cette montée en gamme ne doit pas reposer sur une impression. Mettez en place des évaluations spécifiques à votre cas d’usage : une vingtaine d’exemples représentatifs, avec pour chacun la réponse que vous jugez correcte. Ces benchmarks personnalisés vous permettront de comparer objectivement les modèles et de choisir celui qui convient le mieux, plutôt que de trancher sur trois essais manuels de bonne foi.

Vous ramènerez alors la décision aux trois questions du début. Le modèle peut-il gérer les tâches de votre application ? Son temps de réponse est-il acceptable pour vos utilisateurs ? Reste-t-il viable financièrement à l’échelle que vous visez ? Le bon modèle est le moins coûteux de ceux qui répondent oui aux trois.