Opus 4.7 est sorti hier 16 avril 2026. Les benchmarks officiels et communautaires commencent à remonter. Mais quels chiffres regarder et lesquels ignorer ? Tour d’horizon des benchmarks qui comptent pour un dev en 2026.
Les benchmarks classiques et leurs limites
SWE-bench. Benchmark qui mesure la capacité à résoudre des issues GitHub réelles. Utile, mais biaisé vers les patterns présents dans ses données. Un modèle qui excelle sur SWE-bench peut être moyen sur ta codebase.
HumanEval / MBPP. Génération de fonctions Python à partir de descriptions. Vieux, saturé, peu discriminant aujourd’hui.
MMLU. Connaissance générale. Pas pertinent pour du coding pur mais donne une idée de la solidité globale.
GPQA. Questions scientifiques. Intéressant pour valider le raisonnement mais éloigné du dev quotidien.
Lire ces benchmarks sans contexte conduit à des conclusions hâtives. Un modèle +2 % sur SWE-bench peut ne rien changer pour toi.
Les benchmarks plus pertinents pour le dev
LiveCodeBench. Questions de code régulièrement renouvelées pour éviter la contamination des données d’entraînement. Plus représentatif.
Aider polyglot. Mesure sur des tâches de développement dans plusieurs langages. Pertinent si ta stack est polyglotte.
Cursor eval suite. Benchmark que Cursor utilise en interne, parfois publié. Mesure sur des cas proches du quotidien.
Les évaluations par équipes. Plus fiable encore : mesurer sur ta codebase à toi, avec tes patterns à toi.
Les chiffres officiels sur 4.7
Les annonces d’Anthropic sur 4.7 :
Sur les benchmarks coding agentic, Opus 4.7 surpasse 4.6 de plusieurs points. Les chiffres exacts varient selon les tâches (SWE-bench, HumanEval+, Aider, autres).
La rétention de contexte sur des tests de “needle in a haystack” étendue montre une qualité préservée jusqu’à ~700k tokens, vs ~400k pour 4.6.
Le temps de raisonnement sur des tâches simples est inférieur avec l’adaptive thinking calibré, même si le compute total peut varier.
Ce que les chiffres ne disent pas
La qualité perçue. Un modèle qui score 62 % sur SWE-bench peut “sonner” mieux qu’un modèle qui score 65 %. Les benchmarks ratent la fluidité, le ton, la cohérence.
L’adaptation au contexte. Un modèle peut briller sur des tâches isolées et patiner dans une session longue. Les benchmarks testent rarement ça.
Le coût par tâche réussie. Un modèle qui résout 70 % des tâches à 0.5€ la tâche coûte moins qu’un modèle qui résout 75 % à 3€ la tâche. Le ratio coût/succès est absent de la plupart des benchmarks.
La résistance à l’adversarial. Un modèle peut bien répondre à une question simple et être déstabilisé par une formulation ambiguë ou malicieuse.
Comment benchmarker sur ta codebase
La méthode qui marche :
1. Constitue un dataset interne. 30 à 100 tâches représentatives de ton usage réel. Tâches catégorisées (refactor, debug, nouvelle feature, doc).
2. Annote les “bonnes” sorties. Soit tu écris toi-même ce que tu attendrais, soit tu récupères des sorties validées historiquement.
3. Lance chaque tâche sur le modèle à tester. Avec un prompt standard, sans tuning spécifique par tâche.
4. Évalue les sorties. Grille simple : correct / partiel / incorrect. Ajoute des métriques si utile (coût en tokens, temps d’exécution).
5. Compare. Même méthode pour 4.6 vs 4.7, ou pour Claude 4.7 vs GPT-5, etc.
En 2-3 jours de boulot, tu obtiens une évaluation qui représente ton cas réel. Beaucoup plus utile que les benchmarks publics.
Les benchmarks de coût
Coût par token en entrée/sortie. Publié officiellement par Anthropic. Stable sur la durée d’une release.
Coût par tâche complète. À mesurer : tâche + thinking + output. Moyenne sur ton dataset.
Coût par PR mergée. Métrique finale pour une équipe. Combine consommation et productivité.
Les deux premiers sont des chiffres bruts. Le dernier est la métrique qui compte vraiment pour un budget.
Les pièges du benchmarking
Overfitting sur le benchmark. Si tu testes toujours les mêmes 20 tâches, tu finis par tuner ton workflow pour ces 20 tâches. Change le dataset régulièrement.
Biais de sélection. Si tu choisis les tâches faciles, 4.7 brille. Si tu choisis les difficiles, tous les modèles ratent. Équilibre.
Sur-interprétation d’une métrique unique. Un chiffre ne dit pas tout. Regarde plusieurs métriques en parallèle.
Les benchmarks qui annoncent le futur
Anthropic et ses concurrents publient régulièrement des benchmarks spécifiques (agentic coding, reasoning sur gros contextes, résistance aux jailbreaks). Ces benchmarks évoluent vite.
Garder un œil dessus informe la stratégie produit, même si peu opérationnel au jour le jour.
FAQ
4.7 est-il mesurablement meilleur que 4.6 ? Oui, sur la majorité des benchmarks coding, avec des écarts qui varient de 2 à 8 points selon le benchmark.
Comment comparer 4.7 vs GPT-5 ? Tests sur ton use case. Les comparaisons publiques sont biaisées par les choix méthodologiques de chaque camp.
Faut-il refaire un benchmark interne à chaque release ? Au moins un benchmark léger (30 tâches, 2 heures) à chaque release majeure. Le complet tous les 6 mois.
Je dirige Linkuma, plateforme de netlinking low cost avec 40 000 sites au catalogue et 15 000 clients. On benche régulièrement nos outils IA sur notre use case SEO spécifique. Retours terrain sur linkuma.com, promos hebdo sur deals.linkuma.com.