Claude Opus 4.5 vs Claude Sonnet 4.5 : quand payer plus pour corriger des incidents de code, et quand cela ne change rien

La décision ne porte pas sur le modèle qui paraît le meilleur, mais sur celui qui résout l’incident au moindre coût total

Comparer Claude Opus 4.5 et Claude Sonnet 4.5 pour la maintenance logicielle impose de circonscrire la question. Le prix par token, une démonstration isolée ou un résultat de benchmark ne disent pas, à eux seuls, quelle option convient à une équipe. L’unité de décision doit être l’incident correctement résolu et accepté : une modification qui reproduit le contexte de la défaillance, réussit les tests ciblés et de régression, n’élargit pas indûment le périmètre et demande une revue humaine raisonnable.

Dans cette comparaison, une prime tarifaire pour Opus 4.5 ne serait justifiée que si elle se traduit par un résultat opérationnel mesurable. Il peut s’agir d’un taux supérieur de résolutions complètes, de moins de régressions, de moins d’itérations d’un ingénieur ou d’un délai réduit avant l’obtention d’un correctif acceptable. Si Sonnet 4.5 atteint les mêmes seuils d’acceptation à moindre coût, payer davantage n’apporte pas nécessairement de valeur pour ce type de tickets.

L’analyse doit distinguer le coût d’inférence du coût du travail. Un modèle bon marché qui génère des correctifs incomplets, oblige à déboguer son diagnostic ou produit des changements hors périmètre peut s’avérer plus coûteux après ajout des nouvelles tentatives, de l’exécution d’outils et de la revue. Inversement, un modèle au tarif plus élevé ne doit pas être crédité pour un correctif qui paraît plausible mais ne réussit pas une batterie de tests représentative.

Cet article ne désigne pas de vainqueur général. Il propose un test local permettant aux responsables d’ingénierie, aux équipes de plateforme IA et aux acheteurs de décider à partir de leurs propres éléments probants. Il est également compatible avec l’index des comparatifs, les fiches de Claude Opus 4.5 et de Claude Sonnet 4.5, ainsi qu’avec les informations d’Anthropic sur les modèles et leurs canaux d’accès.

Préparez un corpus gelé et reproductible avant d’exécuter les modèles

Le test commence par le corpus, non par le prompt. Chaque incident doit être associé à un dépôt, un commit de base immuable, un environnement d’exécution et une définition vérifiable de la défaillance. Conservez le ticket original, mais rédigez une version de la tâche qui retire les informations postérieures au moment que vous souhaitez simuler, telles qu’un lien vers le correctif déjà connu ou des commentaires révélant la solution.

Pour chaque cas, créez une reproduction minimale qui échoue sur le commit de base et une batterie permettant de vérifier la correction. L’évaluation doit distinguer une modification cosmétique d’un correctif fonctionnel. Une pratique robuste consiste à définir des tests qui devaient échouer avant la correction et des tests qui réussissaient déjà et doivent continuer à réussir. Cette approche rejoint la logique de validation employée pour distinguer résolution et régression dans SWE-bench Verified, sans que les résultats d’un corpus interne ne soient mélangés à ceux de ce benchmark.

SWE-bench est une référence méthodologique utile, et non un substitut au corpus local. Le travail d’origine décrit un ensemble d’incidents tirés de dépôts Python réels ; il aide donc à comprendre les exigences d’une tâche d’édition de dépôt. Toutefois, sa distribution de langages, de dépendances, d’ancienneté des incidents et de règles d’évaluation peut différer de celle de votre équipe. Un résultat interne doit être publié comme un résultat interne.

Excluez les tickets sans reproduction raisonnablement stable, les changements dépendant de services externes non contrôlés, les vulnérabilités exigeant une procédure de divulgation particulière et les tâches dont le critère d’acceptation est purement subjectif. Consigner ces exclusions évite que l’échantillon final ne paraisse plus représentatif qu’il ne l’est.

Maintenez des conditions équivalentes, sans présumer qu’équivalent signifie identique

Consignez l’identifiant exact de chaque modèle, la date et l’heure d’exécution, le canal d’accès, la région ou l’endpoint, le fournisseur d’infrastructure, la configuration de contexte et les outils accordés. Pour Opus 4.5, la documentation d’Anthropic identifie le modèle d’API claude-opus-4-5-20251101. La documentation sur le cycle de vie des modèles doit être consultée au début de chaque campagne afin de vérifier que les deux identifiants sont toujours actifs et d’anticiper les retraits.

L’annonce de Sonnet 4.5 documente son accès via API ainsi que son prix de lancement en entrée et en sortie. Cette information ne suffit pas à calculer un coût définitif : la facturation peut dépendre du canal, de l’usage du cache, de la région, des outils et des conditions commerciales en vigueur. Sur Amazon Bedrock, par exemple, la documentation du fournisseur décrit des différences entre endpoints globaux et régionaux, ainsi que des conditions particulières de disponibilité. Ne comparez pas une exécution régionale d’un modèle à une exécution globale de l’autre sans déclarer cette différence.

Utilisez le même prompt système, la même description de tâche, le même format de réponse, le même répertoire de travail, les mêmes permissions de lecture et d’écriture, les mêmes commandes autorisées, le même accès réseau et la même limite d’itérations. Si un modèle dispose d’une modalité ou d’une capacité que l’autre n’a pas sur le canal choisi, ne la présentez pas comme un test strictement équivalent. Vous pouvez la mesurer dans un scénario opérationnel séparé, mais elle doit être étiquetée comme telle.

La politique de nouvelles tentatives et les limites doivent également être fixées. Une nouvelle tentative après une erreur transitoire d’infrastructure peut être raisonnable ; des redémarrages répétés parce que le premier résultat était mauvais modifient l’intervention disponible. La règle doit s’appliquer aux deux modèles et comptabiliser toutes les tentatives facturables.

Séparez les tickets selon leur difficulté et leur mécanisme de défaillance

Une moyenne globale peut masquer l’information qui détermine réellement l’achat. Classez les cas avant d’exécuter les modèles. Un premier niveau peut réunir les corrections localisées : une validation incorrecte, un cas limite ou une transformation de données limitée à un ou quelques fichiers. Ce sont des tâches où un modèle plus économique peut atteindre rapidement le seuil d’acceptation.

Un deuxième niveau doit inclure les défaillances qui exigent de suivre des dépendances entre modules. Il peut s’agir, par exemple, d’une modification d’interface interne qui casse la sérialisation, la validation et des consommateurs distants, ou d’un défaut dont le symptôme apparaît dans une couche différente de sa cause. Il est raisonnable d’examiner ici si une capacité accrue de planification ou d’exploration réduit les itérations, mais le résultat doit être mesuré et non déduit de la catégorie du modèle.

Le troisième niveau correspond aux incidents ambigus ou difficiles à reproduire. Ils peuvent impliquer de la concurrence, un état partagé, des configurations particulières ou des exigences incomplètes. L’objectif n’est pas de récompenser une explication longue : il est de vérifier que le modèle formule des hypothèses vérifiables, obtient des éléments de preuve avec les outils autorisés et limite le changement à la cause la mieux étayée.

Étiquetez aussi le langage, la taille du dépôt, la surface modifiée, le type de test et l’existence de dépendances externes. Ces étiquettes permettent de savoir si une différence vient de la difficulté réelle ou d’une concentration accidentelle de tickets dans un langage ou un module.

Définissez la réussite complète avant de voir les résultats

Le critère de réussite doit combiner validation automatique et revue humaine. Ne classez comme réussite complète qu’un correctif qui réussit les tests ciblés, préserve les tests de régression pertinents et satisfait la grille de périmètre. Si le dépôt dispose de tests étendus réalisables dans le budget, exécutez-les ; sinon, indiquez quelle couverture est exclue et pourquoi.

La revue humaine doit être menée en aveugle par rapport au modèle. Donnez aux réviseurs le diff, le diagnostic produit, les résultats de tests et le ticket, mais ni le nom du modèle ni son coût. Demandez une décision définie : accepter, accepter avec modifications mineures, rejeter pour correction incomplète, rejeter pour régression, rejeter pour périmètre excessif, ou toute autre catégorie précisée à l’avance.

Il est utile de conserver la catégorie de réussite partielle, mais pas de l’utiliser pour gonfler le taux de résolution. Un correctif qui localise correctement le composant concerné mais échoue sur un cas limite peut servir à examiner la qualité du diagnostic. Il n’équivaut pas à un incident résolu. De même, un correctif exact qui modifie sans justification des fichiers sans rapport peut exiger assez d’intervention pour ne pas compter comme une réussite complète.

Les consignes de revue doivent interdire l’acceptation de changements qui désactivent des tests, réduisent des assertions ou introduisent des exceptions génériques dans le seul but de faire disparaître une erreur. Elles doivent également rappeler qu’un nouveau test ne démontre pas, à lui seul, que l’implémentation est correcte.

Mesurez les coûts, l’intervention et le délai de bout en bout

La métrique principale peut s’exprimer comme le coût total du lot divisé par le nombre de réussites complètes acceptées. Dans le numérateur, incluez l’entrée, la sortie, le cache et toute notion facturée applicable au canal. Ajoutez les nouvelles tentatives, les appels échoués, l’usage d’outils lorsqu’il a un coût, et le temps humain de revue ou de correction, si l’objectif est de décider du coût opérationnel et non du seul coût d’API.

Rapportez également le taux de réussite complète, le taux de réussite partielle, les régressions détectées, le nombre d’interventions humaines et la latence de bout en bout. La latence n’est pas nécessairement le temps du modèle : un agent peut attendre des outils, répéter des tests ou bloquer des ressources d’intégration continue. Consignez séparément le temps d’inférence, celui des outils et le temps humain lorsque c’est possible.

Pour évaluer le diagnostic, utilisez une grille simple : identification des symptômes, hypothèse causale, éléments de preuve recueillis, explication de la modification et limites connues. Un diagnostic peut être utile même lors d’un échec, mais il doit être évalué sans confondre qualité narrative et correction. La notation doit comporter des exemples de référence et, s’il y a plusieurs réviseurs, une règle de résolution des désaccords.

Présentez les distributions et les résultats par niveau, pas seulement les moyennes. Un petit nombre d’incidents complexes peut dominer le coût moyen. Répétez par ailleurs une partie ou la totalité du lot : la variabilité entre exécutions peut modifier la conclusion lorsque l’écart entre les modèles est faible.

Interprétez la prime d’Opus 4.5 au moyen de seuils, et non du prestige du modèle

Opus 4.5 justifierait une prime sur un niveau donné si son gain de résolutions complètes compense ses coûts supplémentaires et la revue qu’il évite. Cela pourrait se produire pour des incidents impliquant des relations entre modules, des diagnostics ambigus ou des cycles de test coûteux, mais c’est une hypothèse que l’expérience doit confirmer. La comparaison doit montrer combien de cas supplémentaires sont acceptés à la revue et quel coût humain cesse d’être nécessaire.

Sonnet 4.5 atteint le seuil opérationnel lorsqu’il respecte le taux d’acceptation, la limite de régressions, le délai et le coût définis par l’équipe. Pour les corrections localisées, la décision peut lui être favorable même si Opus obtient un score moyen supérieur, si l’écart ne réduit pas un coût significatif. Pour les tâches plus difficiles, le résultat peut être mixte : Sonnet pour le triage et les correctifs circonscrits, Opus pour une file définie d’incidents dépassant un critère de complexité.

Ne transformez pas la segmentation en règle fondée uniquement sur l’intuition. Une politique initiale peut utiliser des signaux tels que le nombre de modules touchés, l’absence de reproduction claire ou la nécessité d’analyser des traces étendues. Elle doit ensuite être validée par rapport aux résultats. Si ces signaux ne prédisent pas un gain suffisant avec Opus, ils ajoutent de la complexité sans améliorer la décision.

Les annonces et fiches techniques du fournisseur peuvent apporter des informations sur la disponibilité, la configuration et les évaluations internes. Elles ne remplacent pas ce test, car les outils, les dépôts, les prompts, le budget et la définition de la réussite peuvent ne pas correspondre à ceux de votre équipe.

Appliquez une analyse de sensibilité et déclarez les limites

Répétez la comparaison avec des budgets d’itérations différents, des limites de contexte et des permissions d’outils restreintes. Un résultat qui dépend d’un budget très élevé peut ne pas s’appliquer à une opération soumise à des limites strictes. De même, un avantage observé avec un accès réseau ou un outil propriétaire ne doit pas être attribué au seul modèle.

N’agrégez pas les résultats de SWE-bench Verified, de Terminal-Bench ou d’autres évaluations au résultat interne. Il est légitime de les présenter comme contexte méthodologique si la différence de corpus et de harness est explicitée, mais pas comme des lignes comparables d’un même tableau. Modifier les tests, la politique d’outils ou la définition d’acceptation change la tâche mesurée.

Ce test ne démontre pas non plus la sécurité du code, l’autorisation de déployer, la capacité de maintenance continue ni les performances dans tous les langages. Un correctif accepté dans un environnement isolé peut introduire des risques non couverts par l’ensemble de tests. La décision de production doit conserver des contrôles de revue, d’intégration continue et de gestion des changements.

Enfin, documentez les cas perdus : tickets exclus, erreurs d’infrastructure, revues sans consensus et tests instables. Les masquer peut faire paraître la conclusion plus robuste qu’elle ne l’est réellement. La transparence est particulièrement importante si l’écart de coût ou d’acceptation entre les deux modèles est faible.

Modèle final pour prendre une décision répétable

Avant de choisir, formulez par écrit l’objectif : par exemple, réduire le coût par correction acceptée d’incidents de maintenance sans dépasser une limite de régressions ni de temps de revue. Exécutez ensuite les deux modèles sur le même lot gelé et publiez les paramètres suffisants pour répéter le calcul en interne.

La conclusion doit prendre une forme conditionnelle. Par exemple : Sonnet 4.5 est l’option par défaut pour le niveau localisé parce qu’il atteint le seuil d’acceptation avec un coût total inférieur ; Opus 4.5 est réservé au niveau intermodulaire si la répétition confirme une réduction suffisante des rejets ou de l’intervention humaine. Si la différence ne persiste pas après répétition du lot, la conclusion responsable est qu’il n’existe pas assez d’éléments pour payer une prime dans cet environnement.

Réexaminez la décision lorsque les identifiants de modèle, les prix applicables, le canal, les outils disponibles ou la composition de la file d’incidents changent. Une évaluation reproductible n’est pas un achat unique : c’est un contrôle périodique d’une décision qui dépend de systèmes et de conditions évolutifs.

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.