Claude Haiku 4.5 vs Claude Opus 5 : quand un surcoût peut justifier un meilleur résultat

La décision ne consiste pas à déterminer quel modèle est le meilleur, mais quel résultat chaque flux achète

Claude Haiku 4.5 et Claude Opus 5 répondent à des besoins opérationnels différents au sein de l’offre d’Anthropic. Une comparaison utile pour les équipes produit, ingénierie et opérations ne peut pas se limiter à affirmer que l’un a davantage de capacités ou que l’autre coûte moins cher par token. L’unité de décision doit être la tâche acceptée : une sortie qui satisfait aux exigences fonctionnelles et de qualité sans correction humaine modifiant substantiellement son contenu.

Le prix par token reste pertinent, car il conditionne le coût marginal, mais il ne résume pas le coût de production. Une réponse peu coûteuse peut finalement être plus chère si elle impose de répéter des requêtes, de valider des formats, de corriger des omissions ou de faire remonter des cas à une équipe experte. De même, une réponse dont le coût initial est plus élevé peut être justifiée lorsqu’elle évite un échec de conformité, réduit de manière vérifiable les rejets ou résout une revue qui aurait autrement nécessité une intervention spécialisée.

Aucune exécution, aucun corpus, aucun journal de tokens, aucune mesure de latence ni aucune évaluation humaine de l’essai décrit n’ont été fournis. Cet article ne présente donc pas de classement empirique des gagnants et n’attribue pas de pourcentages de qualité aux deux modèles. Il présente une méthode pour produire ces éléments de preuve ainsi qu’une matrice de décision conditionnelle. Toute conclusion sur la supériorité dans une tâche donnée devra dépendre des résultats publiés selon cette méthode.

La documentation officielle disponible fait apparaître des différences matérielles qui affectent la conception de l’essai. Elles incluent notamment une fenêtre de contexte plus grande pour Opus 5 que pour Haiku 4.5, des capacités et configurations de raisonnement qui doivent être consignées, ainsi que des conditions tarifaires pouvant varier selon le canal, le mode d’accès et les mécanismes de cache. Ces différences font partie de la décision réelle, mais elles peuvent aussi transformer un test apparemment symétrique en test inéquitable si elles ne sont pas déclarées.

Ce qui doit rester constant et ce qui doit être consigné

La comparaison doit commencer par un protocole figé avant l’exécution des requêtes. Le corpus doit avoir une version identifiable, sans éléments ajoutés pendant l’évaluation. Le message système, l’instruction de tâche, les documents joints, les outils disponibles, le schéma de sortie, la limite de sortie et la politique de nouvelles tentatives doivent aussi rester constants, lorsqu’ils sont compatibles avec les deux modèles.

L’égalité littérale des paramètres ne correspond pas toujours à une égalité fonctionnelle. Si un modèle propose des options de raisonnement, d’effort ou de sortie structurée dont la sémantique diffère, le protocole doit décrire la configuration de chaque bras et expliquer pourquoi elle représente un usage de production raisonnable. Il n’est pas souhaitable de désactiver une capacité essentielle d’un modèle au seul motif d’obtenir une symétrie nominale ; il n’est pas davantage souhaitable d’activer des capacités dans un seul bras sans signaler leur effet sur la qualité, la latence et la facturation.

Pour chaque exécution, il faut conserver les identifiants exacts des modèles, la date et l’heure, la région ou la résidence des données applicable, le fournisseur ou canal d’API, les paramètres, l’identifiant du cas, la réponse complète, le motif de terminaison, les tokens facturés et la latence de bout en bout. Le statut actif d’un nom commercial ne suffit pas : les snapshots ou identifiants précis sont nécessaires, car les modèles peuvent être mis à jour ou retirés.

La fenêtre de contexte nécessite une règle explicite. Si tous les cas tiennent dans la limite de Haiku 4.5, les deux modèles peuvent traiter le même dossier sans troncature. Si certains cas dépassent cette limite tout en tenant dans celle d’Opus 5, deux évaluations distinctes mais valides sont nécessaires : une comparaison sur un sous-ensemble commun et une évaluation opérationnelle reconnaissant que Haiku requiert un découpage, une récupération documentaire ou un autre mécanisme auxiliaire. Masquer cette différence rendrait le résultat difficile à interpréter.

Test 1 : classification à règles et extraction structurée

La première charge de travail doit représenter des opérations où le volume et la cohérence sont essentiels : acheminer des tickets, étiqueter des documents, extraire des champs de formulaires ou déterminer si un cas respecte des conditions explicites. L’ensemble doit inclure des exemples ordinaires, des entrées incomplètes, des catégories limites, des contradictions internes et des cas qui doivent être rejetés faute de preuves suffisantes.

L’évaluation ne doit pas se réduire à vérifier que la réponse semble raisonnable. Elle doit mesurer l’exactitude champ par champ, la correspondance de la classification, la validité syntaxique de la sortie, la conformité au schéma et le rejet correct. En particulier, un JSON valide qui invente une valeur obligatoire ne doit pas être considéré comme un succès. Si le flux de production permet une réparation automatique après une erreur de schéma, cette réparation doit être enregistrée comme une nouvelle tentative et intégrée au coût.

Les recommandations de prompting fournies conseillent de préciser le format de sortie et d’employer des sorties structurées ou des outils utilisant des valeurs énumérées pour les tâches de classification. Cela favorise une conception dans laquelle le modèle n’a pas à deviner la forme de la réponse. Cela ne dispense toutefois pas de valider les valeurs au regard des sources propres à chaque cas.

Dans cette tâche, Haiku 4.5 sera un choix rationnel s’il conserve le taux d’acceptation convenu, si son coût par cas accepté est inférieur et si ses erreurs sont détectables de manière déterministe. Opus 5 sera justifié s’il réduit suffisamment les erreurs sémantiques non détectées par le validateur, les rejets incorrects ou le travail humain de débogage. Cette conclusion ne peut être tirée qu’à partir de données réelles ou représentatives.

Test 2 : synthèse fidèle de documentation avec éléments de preuve internes

La deuxième charge doit mesurer une capacité différente : transformer un ensemble documentaire en une synthèse qui préserve les exigences, conditions, exceptions et désaccords pertinents. L’objectif n’est pas de récompenser les textes les plus longs ni la formulation la plus persuasive, mais de vérifier que chaque affirmation importante peut être reliée à des passages du matériau fourni dans le dossier lui-même.

Le corpus doit associer des documents cohérents à des documents comportant des lacunes ou des divergences. Il doit inclure des exigences présentes dans des annexes, des définitions à portée limitée, des dates ou versions incompatibles et des demandes auxquelles les éléments disponibles ne permettent pas de répondre. Cela permet de mesurer la couverture, les omissions critiques, les attributions non étayées et le comportement face à l’incertitude.

Une grille pratique sépare quatre dimensions : la couverture des exigences, la fidélité des attributions, le traitement des conflits et l’utilité de la structure finale. Les évaluateurs doivent disposer d’une réponse de référence ou d’une liste de propositions vérifiables, mais la revue de qualité doit rester réalisée en aveugle quant au modèle. Lorsqu’une synthèse signale correctement une incertitude, elle ne doit pas être pénalisée parce qu’elle ne résout pas une ambiguïté présente dans les sources.

Le contexte plus étendu annoncé pour Opus 5 peut être pertinent lorsque le dossier complet ne tient pas dans la limite de Haiku 4.5. Il ne faut cependant pas supposer qu’une fenêtre de contexte plus grande équivaut automatiquement à une synthèse plus fidèle. Le test doit séparer les bénéfices liés au traitement d’une documentation plus abondante de ceux découlant du comportement du modèle. Il est donc utile de mesurer à la fois un sous-ensemble commun et les dossiers longs qui exigent une stratégie supplémentaire avec Haiku.

Test 3 : revue complexe avec instructions contradictoires

Le troisième test doit représenter des changements techniques, des dossiers de conformité, des revues de politiques ou des propositions opérationnelles dans lesquels les instructions portent des contraintes multiples et partiellement opposées. Le modèle doit détecter les conflits, prioriser les contraintes définies par le protocole et expliquer quelles informations manquent pour émettre une recommandation sûre.

Les cas doivent comporter des contraintes de plusieurs types : exigences fonctionnelles, compatibilité, sécurité, délais, limites de modification et conditions d’approbation. Il est important d’inclure des conflits délibérés, mais pas d’instructions malveillantes ni de données impossibles à évaluer de manière responsable. La réponse attendue ne doit pas nécessairement être une solution complète : dans certains cas, le bon résultat consistera à identifier un conflit, à s’abstenir de recommander une action ou à transmettre la décision à une personne responsable.

L’évaluation doit apprécier le respect des contraintes, la détection des incompatibilités, la précision des recommandations et la nécessité d’une escalade humaine. L’utilité ne signifie pas accepter sans réserve une proposition. Une recommandation qui paraît décisive mais ignore une interdiction explicite est pire qu’une réponse qui délimite son incertitude et demande l’autorisation nécessaire.

Cette charge est celle où un surcroît de capacité pourrait produire le plus de valeur, car le coût d’une erreur peut être élevé et la validation automatique est souvent incomplète. On ne peut néanmoins pas en déduire qu’Opus 5 doit toujours être utilisé. Si les cas sont décomposés en vérifications indépendantes, si les règles sont codifiées et si une revue humaine est déjà obligatoire, un modèle plus économique peut suffire en première couche. L’essai doit mesurer l’association du modèle, des validateurs et de la revue, et non le modèle isolé dans le vide.

Comment calculer le coût par tâche correctement accomplie

L’indicateur central est le coût effectif par résultat accepté. Son numérateur additionne le montant des requêtes nécessaires pour traiter l’ensemble des cas : tokens d’entrée et de sortie, usage du cache lorsqu’il s’applique, tokens associés au raisonnement lorsqu’ils sont facturables, nouvelles tentatives automatiques et appels auxiliaires indispensables. Si le flux comprend une revue humaine, le coût défini pour cette revue doit être ajouté, avec un tarif et une règle temporelle déclarés.

Le dénominateur n’est ni le nombre total de requêtes ni le nombre de réponses qui renvoient du texte. C’est le nombre de cas acceptés selon la grille. Lorsqu’une édition humaine mineure est autorisée, le protocole doit préciser ce que signifie « mineure ». Par exemple, une correction de ponctuation peut continuer de compter comme acceptée avec édition ; ajouter une exigence omise ou retirer une affirmation non étayée doit compter comme une modification substantielle.

Il faut également publier la médiane et un percentile élevé de latence de bout en bout, et non la seule moyenne. Les moyennes peuvent masquer des files d’attente en queue qui affectent les interfaces interactives ou les accords de niveau de service. La latence doit être mesurée entre l’envoi de la requête par le client et la réception puis la validation de la sortie, tout en précisant si elle inclut les nouvelles tentatives et les outils.

Les tarifs officiels et les modificateurs de prix exigent une capture datée du canal utilisé. Une comparaison par un tiers peut servir de contexte méthodologique, mais elle ne remplace pas le journal de facturation de l’essai : elle peut porter sur des configurations de raisonnement ou d’effort différentes de celles retenues ici. Les conclusions économiques doivent se limiter au mode d’accès effectivement mesuré.

Matrice de décision et limites des éléments de preuve

Le choix final devrait s’effectuer par flux, et non pour l’organisation entière. Les classifications à grand volume et faible impact, avec des schémas stricts et des validateurs robustes, sont candidates à Haiku 4.5 si le test confirme un taux d’acceptation suffisant. Les synthèses de dossiers tenant dans le contexte commun peuvent elles aussi commencer avec Haiku lorsque les omissions sont détectables grâce à une revue proportionnée. Dans les deux cas, l’économie n’est réelle que si elle ne réapparaît pas sous forme de nouvelles tentatives ou de revue humaine.

Opus 5 mérite une évaluation prioritaire pour les dossiers nécessitant une fenêtre de contexte supérieure, les revues comportant des contraintes interdépendantes ou les tâches où une erreur sémantique serait coûteuse et difficile à détecter automatiquement. Même dans ces situations, la décision doit dépendre de l’écart observé d’acceptation et de coût total, et non du nom du modèle ou d’un benchmark utilisant un autre corpus.

Les résultats auront des limites de transférabilité. Un corpus interne, un modèle de prompt particulier, une langue, une région, un canal d’accès et une politique de nouvelles tentatives peuvent modifier le résultat. Les exécutions doivent être répétées après des changements de snapshot, de prix, de limites ou de mécanismes produit. La documentation relative aux retraits de modèles est particulièrement pertinente pour éviter de maintenir des conclusions reposant sur des identifiants retirés.

L’incertitude principale de cette comparaison est empirique : les sources fournies décrivent des capacités, des prix et des conditions de plateforme, mais elles ne contiennent pas le résultat des trois tests proposés. Tant qu’un ensemble de mesures reproductibles n’est pas publié, la recommandation appropriée consiste à mettre en œuvre un test limité, à définir des seuils d’acceptation et à déployer selon les niveaux de risque.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.