Évaluations de Claude Opus 4.5 : ce que comparent les tests et jusqu’où vont leurs conclusions

Un score n’a de sens qu’au regard de son protocole

Les évaluations des modèles de langage ne mesurent pas une capacité unique. Un test peut porter sur la résolution de tâches de programmation avec un agent et des outils ; un autre, sur les performances dans une suite interne ; un troisième, sur les réponses à des questions de culture générale. Même si chacun publie un chiffre ou un classement, cela ne signifie pas qu’ils mesurent la même chose ni qu’ils permettent de classer les modèles de façon interchangeable. Pour interpréter un score, il faut au minimum connaître la tâche, le jeu de données évalué, la métrique et les conditions d’exécution.

Dans le cas de Claude Opus 4.5, les sources fournies identifient plusieurs types de documents : une communication d’Anthropic qui mentionne des tests avec Junie, la System Card du modèle, un article indépendant sur les modèles utilisés comme agents IDE et une fiche de benchmarks agrégés. Une analyse d’Artificial Analysis était également envisagée, mais aucune page de cet organisme ne figure parmi les sources vérifiées fournies. Il n’est donc pas possible de documenter ici sa méthode ni le classement attribué au modèle dans cette analyse.

Les éléments disponibles permettent de décrire la portée générale de certains documents et d’indiquer les informations qu’il faudrait vérifier dans leur version intégrale. En revanche, ils ne suffisent pas à reconstituer les protocoles complets, à vérifier chaque résultat ou à établir un classement général. Cette distinction ne constitue pas un jugement sur la qualité du modèle : elle marque simplement la limite de ce que les documents disponibles permettent d’affirmer.

Ce que les sources repérées permettent d’établir

La page officielle d’Anthropic consacrée à Claude Opus 4.5 est une source du fournisseur. L’extrait disponible affirme que, lors de tests avec Junie, son agent de programmation, Opus 4.5 surpasse Sonnet 4.5 dans les benchmarks mentionnés dans cette communication et nécessite moins d’étapes pour résoudre les tâches. Toutefois, les éléments fournis ne précisent ni les benchmarks concernés, ni les tâches, le nombre d’exécutions, les outils activés ou le critère exact qui définit le « nombre d’étapes ». L’affirmation doit donc être présentée comme une déclaration d’Anthropic, et non comme une comparaison indépendante dont le protocole aurait été reconstitué.

La note de vérification de cette même page ajoute une référence à GitHub Copilot, tandis que l’extrait cité mentionne Junie. Les informations fournies ne permettent pas de déterminer s’il s’agit de passages différents de la page, d’une description imprécise ou d’une divergence dans les notes. Il convient de consulter la page intégrale avant de décrire précisément l’environnement utilisé. Il ne faut pas lever cette ambiguïté en supposant que Junie et GitHub Copilot ont fait partie du même essai.

La System Card d’Anthropic est un document institutionnel original. D’après les informations fournies, elle compare Opus 4.5 à d’autres modèles dans une suite de tâches, mais celles-ci ne sont pas nommées et les métriques ni les conditions précises ne sont pas détaillées. La présence d’une comparaison dans le document ne suffit pas à affirmer que toutes les tâches portent sur la programmation ou l’utilisation d’agents : il faudrait vérifier le contenu intégral pour caractériser la suite.

L’article repéré sur arXiv porte sur l’évaluation de modèles utilisés comme agents IDE dans des environnements réels et, selon la note disponible, évoque la variabilité des résultats d’Opus 4.5. Le résumé fourni ne précise pas les tâches, l’ensemble des modèles, le harness, le nombre d’exécutions ou le calcul de cette variabilité. En particulier, il ne permet pas de vérifier la valeur d’écart-type de 0,027 mentionnée dans les questions de vérification, ni de savoir à quelle métrique ou à quel ensemble de résultats elle s’appliquerait.

Enfin, BenchLM propose une fiche agrégée qui attribue à Opus 4.5 un classement et un score global calculés à partir des lignes de résultats affichées par le site. Il s’agit d’une source secondaire d’agrégation, et non d’une description primaire des protocoles d’origine. Sans connaître les règles de sélection, de normalisation et de combinaison des lignes, ce score ne doit pas être considéré comme une mesure universelle des capacités du modèle.

Les tests avec Junie : une affirmation du fournisseur, pas un protocole complet

L’extrait d’Anthropic permet de relever une affirmation précise : lors de tests réalisés avec Junie, Opus 4.5 aurait surpassé Sonnet 4.5 dans les benchmarks mentionnés et aurait eu besoin de moins d’étapes pour résoudre les tâches. Cette formulation vient d’Anthropic et doit lui être attribuée. Les éléments fournis ne permettent pas de confirmer les jeux d’évaluation, la taille de l’échantillon ni si les deux modèles ont reçu le même contexte, les mêmes outils et le même budget.

Le fait d’avoir besoin de « moins d’étapes » ne signifie pas, à lui seul, que les performances sont meilleures dans l’ensemble. Pour interpréter cette mesure, il faudrait savoir ce qui compte comme une étape, si les tentatives infructueuses ou l’utilisation d’outils sont pénalisées, si les tâches doivent être entièrement réussies et comment les solutions partielles sont traitées. Un nombre inférieur d’interactions peut être pertinent dans un environnement donné, mais n’informe pas automatiquement sur le coût, la latence, la fiabilité ou la qualité du code.

Les notes associent également la page consacrée à Opus 4.5 à GitHub Copilot. Comme le texte intégral qui explique cette référence n’est pas fourni, il est impossible de déterminer si elle décrit un autre contexte d’évaluation, une intégration ou une tâche différente. Un audit rigoureux maintiendrait ces deux mentions séparées jusqu’à vérification de leurs conditions, plutôt que de les fondre en une expérience unique.

System Card : un document pertinent, dont les détails restent à vérifier

La System Card de Claude Opus 4.5 est une source primaire du fournisseur. C’est donc le document à consulter pour vérifier quelles évaluations Anthropic a choisi de publier et la manière dont elle les présente. La note de vérification disponible confirme uniquement que le document compare Opus 4.5 à d’autres modèles dans une suite de tâches. Elle ne donne pas le nom des tâches et ne permet pas de reconstituer les résultats par catégorie.

Pour interpréter cette suite, il faudrait examiner chaque test : quelle capacité il cherche à mesurer, quels modèles sont comparés et quelle métrique est employée. Il faudrait aussi déterminer si les modèles ont reçu le même format d’instructions, les mêmes outils et le même budget. Si la System Card présente des résultats pour des tâches différentes, il ne convient pas de les résumer comme s’ils constituaient une mesure unique de « l’intelligence » ou des performances en programmation.

La documentation de la plateforme Anthropic identifie une page de présentation d’Opus 4.5 qui peut aider à vérifier les identifiants et les limites du modèle. Toutefois, la note fournie ne donne ni l’identifiant exact, ni les limites précises, ni le lien entre cette documentation et les exécutions de chaque benchmark. Il est donc impossible d’affirmer que les essais cités utilisaient une configuration déterminée avant d’avoir vérifié les documents complets et la correspondance entre la version du modèle et le test.

Évaluation indépendante des agents IDE : les informations manquantes pour interpréter la variabilité

L’article repéré sur arXiv apporte un point de vue différent de celui des communications du fournisseur : il étudie des modèles utilisés comme agents IDE dans des environnements réels. Selon la note de vérification, il traite de la variabilité des résultats d’Opus 4.5. Cette différence de provenance est importante, mais elle ne suffit pas à établir l’indépendance méthodologique de l’étude ni à comparer ses chiffres à ceux d’Anthropic. Pour cela, il faut examiner la méthode complète, les données et la procédure d’évaluation.

La variabilité n’est interprétable que si l’on sait quel résultat est répété et dans quelles conditions. Un écart-type peut décrire des différences entre exécutions, tâches, instances ou une autre unité ; le sens varie selon le choix retenu. Les éléments disponibles ne confirment pas ce que représente la valeur 0,027 mentionnée dans les questions de vérification, le nombre d’exécutions qui la fonde ni si elle est calculée à partir d’une mesure de réussite, d’un score ou d’une autre variable. Cette valeur ne doit donc pas être présentée comme un résultat vérifié.

Il faut aussi distinguer la variation entre les exécutions d’un modèle de la variation entre les tâches. Un agent peut obtenir des résultats similaires en répétant une même tâche tout en affichant des performances très inégales d’une tâche à l’autre. Pour distinguer ces deux phénomènes, il faut au minimum connaître le nombre de tâches et de répétitions, l’unité statistique, la définition de la métrique et la méthode d’agrégation.

L’expression « environnements réels » ne précise pas non plus, à elle seule, les conditions reproduites. Pour savoir ce que couvre le test, il faudrait vérifier les dépôts ou projets utilisés, les instructions, l’accès au terminal et aux outils, les limites de temps ou d’interaction, ainsi que la manière de juger si une modification résout le problème. Les notes fournies ne détaillent pas ces éléments ; cette évaluation ne peut donc pas servir ici à affirmer qu’elle représente l’usage quotidien de toutes les équipes de développement.

Artificial Analysis et les agrégateurs : un classement ne remplace pas la méthodologie

La proposition éditoriale prévoyait de vérifier l’Omniscience Index d’Artificial Analysis et le classement attribué à Opus 4.5. Toutefois, la liste des sources vérifiées ne comprend aucune page d’Artificial Analysis. Il est donc impossible d’affirmer ce que mesure cet indice, quelle est sa méthode, quel résultat il attribue au modèle ou dans quelle configuration ce résultat aurait été obtenu. La question doit rester ouverte jusqu’à ce que la source correspondante soit disponible et examinée.

La fiche BenchLM figure bien parmi les documents repérés. Selon sa note, elle indique un classement, un score global et un ensemble de lignes de résultats de benchmarks présentées sur la page. Ces données décrivent ce que publie l’agrégateur ; elles ne valident pas, à elles seules, la sélection des tests ni l’opération consistant à combiner des résultats différents. Pour interpréter un classement, il faudrait connaître les règles de normalisation, de pondération, d’inclusion des sources et de mise à jour de chaque ligne.

Un classement agrégé peut être utile pour explorer des résultats ou repérer des tests, mais il ne devrait pas être présenté comme une mesure neutre des capacités générales sans explication de sa construction. Si un score réunit des tâches hétérogènes, une modification de la sélection ou de la pondération peut changer le classement. En outre, sans traçabilité jusqu’aux publications d’origine, il est impossible de vérifier si les conditions de toutes les lignes sont comparables ou si elles se rapportent à la même version du modèle.

Comparabilité, contamination et reproductibilité

Deux résultats ne peuvent être comparés directement que si leurs conditions sont suffisamment équivalentes au regard de la question posée. Pour les évaluations d’agents IDE, cela suppose notamment d’examiner le modèle exact et sa version, le niveau de raisonnement, les instructions, les outils disponibles, le harness reliant le modèle à l’environnement et les limites d’exécution. Les sources résumées ne donnent pas ces informations pour tous les tests mentionnés ; il est donc impossible d’établir qu’ils sont équivalents.

La contamination des jeux d’évaluation nécessite un examen spécifique. Pour estimer ce risque, il faudrait connaître la manière dont les tâches ont été conçues, leur date d’intégration, la possibilité que leurs énoncés ou leurs solutions figurent dans les données d’entraînement et les contrôles appliqués par les auteurs. Les notes fournies ne décrivent aucun contrôle ou analyse de contamination pour la System Card, les tests avec Junie, l’étude sur les agents IDE ou l’agrégation de BenchLM. Cela signifie que le risque n’est pas évalué ici ; cela ne signifie pas qu’une contamination a été démontrée.

La reproductibilité ne dépend pas uniquement de la publication d’un score. Les prompts, les données d’évaluation, le code du harness, la configuration du modèle, les critères de notation et les journaux d’exécution sont également utiles. Si certains de ces éléments ne sont pas publiés, il faut préciser quelle partie du résultat ne peut pas être reproduite ou examinée de façon indépendante. Les résumés disponibles ne permettent pas de confirmer quels documents accompagnent chaque source ni s’ils suffisent à reproduire les tests.

Ces lacunes doivent être traitées comme des points à vérifier, et non comme des défauts avérés des évaluations. Un examen ultérieur des documents complets pourrait apporter des détails absents des notes. D’ici là, la démarche rigoureuse consiste à distinguer les résultats, à attribuer chaque affirmation à sa source et à éviter toute déduction sur un classement général.

Conclusions circonscrites

À partir des sources et des notes vérifiées, on peut affirmer qu’Anthropic fait état de résultats favorables à Opus 4.5 par rapport à Sonnet 4.5 dans des tests associés à Junie ; que la System Card compare Opus 4.5 à d’autres modèles dans une suite de tâches ; qu’une étude indépendante sur des modèles utilisés comme agents IDE mentionne une variabilité pour Opus 4.5 ; et que BenchLM publie un score et un classement agrégés. Chaque affirmation renvoie à une source et à un type de preuve distincts.

Ces éléments ne permettent pas de reconstituer les protocoles complets ni de déterminer si les tests utilisent le même identifiant de modèle, les mêmes outils, le même budget, le même harness ou la même métrique. Ils ne permettent pas non plus de vérifier la valeur et l’interprétation de l’écart-type évoqué, les contrôles de contamination, la disponibilité de ressources permettant de reproduire les résultats ou la méthode d’Artificial Analysis. Les scores ne forment donc pas un classement commun et ne justifient pas de conclusion générale sur le modèle le plus performant.

Pour une équipe qui évalue Opus 4.5 pour la programmation ou les agents IDE, la démarche pratique consiste à demander ou à consulter la documentation du test le plus proche de son propre flux de travail. Il faut comparer des tâches équivalentes, mesurer la qualité et le taux de réussite, comptabiliser le coût et la latence, puis observer la variabilité entre les répétitions. Si la méthodologie n’est pas publiée, cette limite doit être indiquée à côté du résultat, et la décision ne devrait pas reposer uniquement sur un classement agrégé isolé.

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.