HumanEval est mort : comprendre les benchmarks de code LLM en 2026

#Pourquoi HumanEval est mort

HumanEval est le benchmark de code le plus cité de l'histoire des LLM. Publié par OpenAI en 2021, il a servi de référence pendant quatre ans. Le problème : en 2026, il est saturé. Les meilleurs modèles open-weight de code y obtiennent 96 à 98 % de « pass@1 », c'est-à-dire qu'ils résolvent du premier coup près de tous les exercices. Quand tout le monde a 20/20, la note ne classe plus personne.

Un benchmark saturé ne mesure plus le progrès : il mesure surtout le bruit. Un écart de 96 % à 98 % entre deux modèles peut tenir à trois exercices sur cent, souvent ambigus ou mal formulés. Ce n'est pas une différence de compétence, c'est de la marge d'erreur. Continuer à choisir un LLM de code sur son score HumanEval en 2026, c'est comme départager deux coureurs de fond sur un sprint de dix mètres.

Ce n'est pas qu'HumanEval soit devenu mauvais. C'est que les modèles ont dépassé ce qu'il sait mesurer. Il reste utile comme test de non-régression — un modèle qui chute à 70 % a un vrai problème — mais il ne sert plus à départager le haut du panier.

#Ce que mesure vraiment HumanEval

Comprendre pourquoi HumanEval sature demande de voir ce qu'il teste concrètement. Le benchmark contient 164 petits problèmes de programmation Python. Chacun fournit une signature de fonction et une docstring décrivant le comportement attendu ; le modèle doit écrire le corps de la fonction, qui est ensuite validé par une batterie de tests unitaires cachés.

Format

164 fonctions Python autonomes à compléter, chacune avec sa docstring et ses tests unitaires.

Nature des tâches

Algorithmique élémentaire : manipuler des listes, des chaînes, un peu de maths. Chaque problème tient dans une seule fonction, sans dépendances externes.

Ce que ça teste

La capacité à traduire une spécification courte et sans ambiguïté en code correct. Un exercice d'école, pas une tâche de terrain.

Ce que ça ne teste PAS

Naviguer dans un dépôt existant, lire plusieurs fichiers, comprendre du code déjà écrit, corriger un bug réel, écrire des tests, gérer des dépendances. Autrement dit : le vrai métier.

L'écart est là. Écrire une fonction isolée à partir d'un énoncé clair est un exercice que les modèles de 2026 maîtrisent. Le travail réel d'un développeur — ou d'un assistant de code local branché sur votre éditeur — consiste à modifier un dépôt existant de plusieurs milliers de lignes. C'est ce que les nouveaux benchmarks cherchent à mesurer.

#SWE-bench Verified expliqué

SWE-bench est le benchmark qui a remplacé HumanEval comme référence sérieuse. L'idée est radicalement différente : au lieu d'exercices jouets, il part de vraies « issues » GitHub tirées de projets Python open source populaires (Django, scikit-learn, Flask, sympy...). Le modèle reçoit le dépôt complet et le texte du bug à corriger. Il doit produire un patch — un diff — qui résout réellement le problème.

La correction n'est pas jugée par un humain ni par un autre modèle : le patch est appliqué au dépôt, puis la suite de tests du projet est exécutée. Si les tests qui échouaient passent, et que ceux qui passaient ne cassent pas, le problème est résolu. C'est un critère objectif et proche du travail réel.

SWE-bench Verified

500 problèmes validés manuellement. Le standard actuel pour comparer des modèles sur la correction de bugs réels.

SWE-bench Lite

300 problèmes plus simples, moins coûteux à évaluer. Utile pour tester vite, mais moins discriminant.

SWE-bench full

Plus de 2000 problèmes, dont certains défectueux. Scores plus bas et bruités, à éviter pour comparer.

Les ordres de grandeur en disent long sur la difficulté. Là où HumanEval plafonne à 98 %, les meilleurs modèles agentiques atteignent 60 à 70 % sur SWE-bench Verified, et les bons modèles open-weight installables en local se situent plutôt entre 40 et 55 %. Il y a enfin de la place pour progresser — et donc pour départager.

#LiveCodeBench et la contamination

SWE-bench mesure la correction de bugs sur du vrai code. LiveCodeBench répond à un autre problème : la contamination. Son principe est dans le nom — « live ». Le benchmark collecte en continu de nouveaux problèmes de programmation compétitive (LeetCode, AtCoder, Codeforces) et les horodate. On peut ainsi n'évaluer un modèle que sur des problèmes publiés APRÈS sa date d'entraînement.

C'est fondamental. Si un problème existait sur internet avant l'entraînement d'un modèle, ce modèle a peut-être vu la solution pendant son apprentissage. Son score ne reflète alors pas un raisonnement, mais une mémorisation. En filtrant par date, LiveCodeBench garantit que le modèle résout des problèmes qu'il n'a jamais pu voir.

Nature

Problèmes de programmation compétitive, horodatés, renouvelés en continu.

Découpage temporel

On choisit une fenêtre de dates postérieure à l'entraînement du modèle testé. Pas de fuite possible.

Ce que ça mesure

Le raisonnement algorithmique pur sur des problèmes inédits — proche de l'esprit de HumanEval, mais sans la saturation ni la contamination.

Précaution de lecture

Toujours vérifier la fenêtre de dates annoncée. Un score LiveCodeBench sur une fenêtre antérieure au modèle ne vaut rien.

LiveCodeBench et SWE-bench sont complémentaires, pas concurrents. Le premier mesure le raisonnement algorithmique sur des problèmes neufs ; le second, la capacité à intervenir sur un vrai dépôt. Un bon LLM de code doit tenir sur les deux — un modèle fort en algorithmique mais incapable de naviguer un projet fera un mauvais assistant au quotidien.

#Le problème de la contamination, en clair

La contamination est LA raison pour laquelle il faut se méfier des scores annoncés. Les LLM sont entraînés sur d'énormes portions du web, GitHub inclus. Si les problèmes d'un benchmark et leurs solutions traînent en ligne, ils finissent probablement dans les données d'entraînement. Le modèle ne résout plus le problème : il le récite.

Un signe qui doit alerter : un modèle qui écrase tout le monde sur un benchmark ancien et statique, mais rentre dans le rang sur un benchmark « live » ou fraîchement publié. L'écart entre les deux est une bonne mesure de la part de mémorisation dans le score. C'est exactement ce que LiveCodeBench a été conçu pour révéler.

#Lire les scores d'un modèle local

Quand vous regardez la carte d'un modèle open-weight (sur Hugging Face ou dans l'annonce de l'éditeur), les scores de code sont presque toujours mis en avant. Voici la grille de lecture pour ne pas se faire avoir.

1. 01
   Repérez la version exacte du benchmark

   « SWE-bench » seul ne veut rien dire. Cherchez « Verified ». Pour LiveCodeBench, cherchez la version (v5, v6...) ET la fenêtre de dates. Sans ces précisions, le chiffre n'est pas comparable à un autre.
2. 02
   Vérifiez le pass@k

   Un pass@1 et un pass@10 ne se comparent jamais. Les éditeurs affichent parfois le plus flatteur des deux. À défaut de précision, supposez le pire pour votre usage réel : ce qui compte au quotidien, c'est la première réponse.
3. 03
   Identifiez l'échafaudage pour SWE-bench

   Un score SWE-bench est indissociable de l'agent qui l'a produit. « 52 % avec OpenHands » n'est pas « 52 % avec Aider ». Si l'éditeur ne précise pas l'agent, le chiffre est peu exploitable.
4. 04
   Méfiez-vous des scores auto-publiés

   Les chiffres de la carte de modèle viennent de l'éditeur, qui a intérêt à bien paraître. Cherchez une reproduction indépendante (classement public, article tiers). Un score jamais reproduit reste une affirmation commerciale.
5. 05
   Croisez au moins deux benchmarks

   Un modèle fort partout est un bon signe ; un modèle qui brille sur un seul benchmark et disparaît sur les autres sent la spécialisation — ou la contamination.

#Lesquels regarder pour choisir son LLM de code

Selon ce que vous attendez de votre assistant local, les benchmarks pertinents changent. Voici comment les hiérarchiser en fonction de l'usage.

Assistant agentique (Aider, Cline, Continue)

SWE-bench Verified en priorité. C'est le benchmark le plus proche de « modifier mon dépôt tout seul ». C'est là que se joue l'utilité réelle d'un agent.

Autocomplétion et petites fonctions

LiveCodeBench et, à la marge, HumanEval comme garde-fou. Pour compléter du code au fil de la frappe, le raisonnement algorithmique compte plus que la navigation de projet.

Génération de code from scratch

LiveCodeBench (raisonnement neuf) croisé avec un benchmark multi-langages si vous ne codez pas qu'en Python — HumanEval et SWE-bench sont très centrés Python.

Revue de code et détection de bugs

Moins bien couvert par les benchmarks publics. SWE-bench reste le meilleur proxy, mais un test maison sur vos propres diffs est ici indispensable.

#Les pièges à éviter

Comparer des k différents

pass@1 contre pass@10 : l'erreur la plus fréquente. Le second gonfle mécaniquement le score. Toujours aligner le k avant de conclure.

Oublier la quantification

Les scores publiés sont mesurés en pleine précision (BF16/FP16). En local, vous ferez tourner du Q4_K_M ou du Q5_K_M, qui perd un peu de qualité. Un modèle à 50 % de SWE-bench en FP16 sera un cran en dessous une fois quantifié.

Prendre le benchmark pour la finalité

Un modèle optimisé POUR passer un benchmark (« benchmark hacking ») peut décevoir sur du code réel. Le score est un indice, pas une garantie.

Ignorer la date du benchmark

Un score LiveCodeBench sur une fenêtre antérieure à l'entraînement du modèle est probablement contaminé. Toujours vérifier que la fenêtre est postérieure.

Confondre modèle et agent

« Ce modèle fait 55 % à SWE-bench » cache souvent « ce modèle DANS cet agent précis ». Changez d'agent et le chiffre bouge.

#Pour aller plus loin

Une fois la grille de lecture des benchmarks en main, la suite logique est de choisir puis d'installer un modèle et de le tester sur votre propre code :

Meilleur LLM local pour coder en 2026

Notre comparatif des modèles de code auto-hébergeables (Devstral, Qwen3-Coder et alternatives), avec les scores, la VRAM nécessaire et lequel choisir selon votre GPU.

Choisir sa quantification (Q4, Q5, Q8, FP16)

Pour comprendre combien de qualité un modèle perd en passant en Q4_K_M — l'écart entre le score annoncé et ce que vous ferez réellement tourner.

Installer Ollama (Windows, macOS, Linux)

Le prérequis pour tester un modèle de code en local sur le port 11434 et le brancher à votre éditeur en quelques minutes.