# Benchmarks de codage IA : comparer résultats, coût et tests
> Ce que mesurent HumanEval et SWE-bench, et comment tenir compte de l’agent wrapper, des conditions, de la fraîcheur des tâches, de la variance et du coût lorsqu’on consulte des classements d’outils de programmation par IA.
Source: https://ailoot.ai/blog/fr/read-ai-coding-benchmarks/
Canonical: https://ailoot.ai/blog/fr/read-ai-coding-benchmarks/
Language: fr
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-125
Revision: sha256-acd1445441fff8003e756f92720b08654c5aef10b95797daeeec74696239950b
En bref : le chiffre « résout 76 pour cent des tâches » ne dit presque rien à lui seul. Ce qui compte, c’est le jeu de tâches qui a produit ce résultat, le modèle et l’agent wrapper évalués ensemble, le fait que les tâches soient récentes ou anciennes, et le coût. Sans ces conditions, le pourcentage est bon pour une bannière publicitaire, mais pas pour choisir un outil.
Je vais ensuite expliquer en termes simples ce que mesurent les deux principaux benchmarks de programmation, où se cache le piège dans les tableaux et comment vérifier n’importe quel classement en une minute avant de s’y fier. Les définitions historiques des benchmarks sont présentées ci-dessous, sans instantané de classement apparié en direct. Une comparaison actuelle de score ou coût exige son tableau lié, sa date et sa configuration.
Pour en savoir plus sur le travail avec les modèles, consultez la [documentation Ailoot](https://ailoot.ai/docs/).
## Que montre réellement le pourcentage d’un benchmark ?
À retenir
Le pourcentage d’un benchmark correspond à la part des tâches d’un jeu donné qu’un outil a accomplies avec un résultat fonctionnel, dans des conditions précises. Les tâches sont vérifiées à l’aide de tests automatisés : le code réussit le test ou échoue ; l’évaluation est objective, il n’y a pas de « plus ou moins ». Mais le jeu de tâches est toujours limité et connu à l’avance, et les conditions de mesure diffèrent d’un outil à l’autre. Le chiffre répond donc à la question : « Combien de ces tâches cet outil a-t-il résolues de cette manière ? » Il ne répond pas à la question : « Saura-t-il traiter mon travail ? »
Un benchmark fonctionne simplement. Il existe une liste toute prête de tâches de programmation. L’outil reçoit chaque tâche et renvoie du code ; le système exécute ensuite des tests automatisés pour vérifier si la solution fonctionne. La part des tâches réussies est le pourcentage affiché dans le tableau.
Son point fort est l’objectivité de l’évaluation. Un test est vert ou rouge ; personne ne donne une note « à vue d’œil ». À cet égard, les benchmarks sont plus honnêtes que les avis ou les témoignages.
Leur faiblesse est exactement la même. Le jeu de tâches est limité et connu à l’avance de tous, y compris des personnes qui entraînent les modèles. Chaque mesure a ses propres conditions. Et les tâches du jeu ne ressemblent presque certainement pas à ce que vous faites. C’est de là que viennent tous les pièges que j’aborde ci-dessous. Le pourcentage décrit le comportement d’un outil sur une liste fermée de tâches définie par quelqu’un d’autre ; il ne se transpose pas directement à votre projet.
## Que mesure HumanEval, et pourquoi ne peut-on plus le choisir comme critère ?
À retenir
HumanEval est un ancien jeu de 164 petites tâches Python : les modèles reçoivent une description de fonction, écrivent le code et des tests automatisés vérifient la tâche. À sa publication en 2021, le premier Codex résolvait 28,8 pour cent des tâches en une tentative. Aujourd’hui, les modèles performants en accomplissent presque toutes, si bien que HumanEval ne permet plus de les départager. De plus, ce sont des problèmes jouets : écrire une fonction à partir d’une description est très éloigné du travail sur un grand projet en production. Un score HumanEval élevé en 2026 ne signifie presque rien.
HumanEval a été créé chez OpenAI et publié en 2021 avec le modèle Codex. Il contient 164 petites tâches Python : les modèles reçoivent la description d’une fonction en langage naturel, en écrivent le corps, puis une série de tests automatisés vérifie qu’il fonctionne correctement.
À l’époque, c’était un bon critère pour départager les modèles. Dans leur propre article, les auteurs donnent ce chiffre : le premier Codex résolvait 28,8 pour cent des tâches en une tentative, tandis que le GPT-3 ordinaire n’en résolvait aucune.
Sur HumanEval, notre modèle résout 28,8 pour cent des problèmes, tandis que GPT-3 en résout 0 pour cent et GPT-J 11,4 pour cent.
— OpenAI, article « Evaluating Large Language Models Trained on Code »
Depuis, les modèles ont progressé et, aujourd’hui, les plus performants accomplissent presque tout HumanEval. Quand tout le monde obtient un score proche de 100 pour cent, le tableau ne permet plus de départager les outils : leurs écarts disparaissent. C’est ce qu’on appelle la saturation d’un benchmark, et HumanEval est dans cet état depuis longtemps.
Le deuxième défaut est plus grave. Les tâches sont minuscules : écrire une fonction à partir d’une description. Votre vrai travail est différent : il porte sur un grand projet avec un historique, où il faut comprendre le code de quelqu’un d’autre, trouver un défaut et éviter de casser le code voisin. Il y a un gouffre entre « écrire une fonction de zéro » et « corriger un bug dans un projet en production ». Un score HumanEval élevé n’est donc plus une raison de choisir un outil ; c’est plutôt le signe que « les bases sont acquises ».
## Que mesure SWE-bench, et en quoi se rapproche-t-il davantage du travail réel ?
À retenir
SWE-bench est constitué de défauts réels dans des projets GitHub populaires : 2 294 tâches issues de 12 dépôts Python. L’outil reçoit une description du problème et modifie le code ; le système exécute ensuite des tests qui échouaient avant la modification et devraient réussir après la correction. C’est bien plus proche du travail réel que HumanEval, d’où son utilisation pour comparer des outils sérieux. Son historique montre clairement sa difficulté : la première approche simple a résolu moins de deux pour cent des tâches.
SWE-bench est fondamentalement différent, et donc plus intéressant. Il a été créé à partir de véritables problèmes et pull requests de projets GitHub populaires. Selon ses auteurs, il comprend 2 294 tâches issues de 12 grands dépôts Python et a été publié en octobre 2023.
La logique d’évaluation est claire. On prend un état d’un projet où se trouvait un défaut réel, ainsi qu’un ensemble de tests qui échouaient alors. L’outil reçoit la description du problème et modifie le code. Les mêmes tests sont ensuite exécutés : s’ils passent, la tâche est effectivement résolue ; ici, personne ne se fie à des promesses verbales.
Nous avons recueilli 2 294 tâches en examinant les pull requests et les problèmes de 12 dépôts Python populaires. Chaque tâche repose sur une pull request liée à un problème et qui modifie au moins un fichier lié aux tests.
— SWE-bench, site officiel du benchmark
Les premiers chiffres montrent à quel point ces tâches sont plus difficiles que des problèmes jouets. La première approche de référence a obtenu tout juste 1,96 pour cent sur SWE-bench, et le premier agent a atteint 12,47 pour cent. Autrement dit, même se rapprocher du travail réel de programmation était difficile ; les pourcentages ont augmenté par la suite, mais ils sont partis de presque zéro.
Ainsi, lorsque vous voyez aujourd’hui de grands chiffres dans un classement d’agents de programmation par IA, ils proviennent le plus souvent de SWE-bench ou de son sous-ensemble vérifié par des humains, qui compte 500 tâches et s’appelle SWE-bench Verified. C’est un benchmark raisonnable. Mais il comporte lui aussi des conditions sans lesquelles le pourcentage est trompeur ; c’est ce que je vais aborder maintenant.
Même le benchmark le plus honnête d’un tableau ne donne pas encore un résultat sur votre projet. Le résultat dépend de votre façon de travailler avec l’outil, et la première ligne du classement ne dit pas grand-chose. Pour un travail fiable, c’est la combinaison qui compte : clone IA, Second Brain et ingénierie du contexte. Un contexte propre améliore votre taux de réussite personnel bien plus nettement que le choix d’un modèle dans un tableau.
## Pourquoi le même modèle affiche-t-il un pourcentage différent ?
À retenir
Parce que le résultat dépend de davantage que du modèle. Au moins trois éléments interviennent dans toute mesure : le modèle lui-même, l’agent wrapper qui l’entoure et le niveau de raisonnement activé. Changer le raisonnement peut créer des lignes distinctes pour le même modèle et harnais. Sans nom du harnais, révision, réglages et source datée, ces lignes ne permettent aucune comparaison chiffrée. Il faut donc comparer les combinaisons complètes ; la marque du modèle, à elle seule, ne détermine pas grand-chose.
C’est là que se cache l’erreur la plus courante dans la lecture des benchmarks. On lit un tableau comme un classement de modèles : ce modèle serait deux pour cent plus intelligent que celui-là. Pourtant, trois éléments influencent le pourcentage, et le modèle n’est que l’un d’eux.
D’abord, le modèle lui-même. Ensuite, l’agent wrapper qui l’entoure : un programme qui permet au modèle de parcourir des fichiers, d’exécuter des commandes, de lire les erreurs et de réécrire le code. Le même modèle donnera des résultats différents dans un wrapper performant et dans un wrapper simple, parce que le wrapper détermine la façon dont le modèle interagit avec le projet. Enfin, le niveau de raisonnement, c’est-à-dire la profondeur avec laquelle le modèle examine chaque étape. Plus il réfléchit longtemps, plus le pourcentage est généralement élevé, et plus le coût augmente.
Une comparaison reproductible conserve toute la configuration. Voici un modèle de compte rendu, pas un classement mesuré :
| Champ | Essai A | Essai B |
|----|----|----|
| Modèle et version exacte | Version testée | Même version pour une comparaison contrôlée |
| Harnais d’agent et révision | Dépôt et commit | Mêmes harnais et commit |
| Tâches et notation | Sous-ensemble et révision d’évaluation | Mêmes tâches et notation |
| Raisonnement | Réglage A | Réglage B |
| Résultat et preuves | Réussites, dénominateur, journaux, date | Réussites, dénominateur, journaux, date |
Cela permet d’identifier le changement et de vérifier si le raisonnement est isolé. L’ancien exemple chiffré sans source liée n’est pas traité comme un résultat mesuré.
Voici la règle : un bon classement précise toujours le modèle utilisé, le wrapper et le niveau de raisonnement. Si le tableau ne donne qu’un nom de modèle et un pourcentage, sans préciser le wrapper, il est difficile de lui faire confiance : on ne sait pas ce qui a réellement été mesuré. L’article sur le [classement des agents de programmation par IA](https://ailoot.ai/blog/fr/ai-coding-agent-rankings/) explique plus en détail ce qui compose la combinaison « modèle plus wrapper ».
Cela explique aussi pourquoi un outil ayant le meilleur score peut parfois vous poser des difficultés. Le benchmark mesure un modèle dans le wrapper peaufiné de quelqu’un d’autre, sur les tâches de quelqu’un d’autre. Votre wrapper, votre projet et le contexte que vous fournissez au modèle sont différents. Dans votre projet, le résultat dépend du contexte ; la ligne du tableau passe au second plan.
## Pourquoi les tâches « expirent-elles », et qu’est-ce qu’une fuite de données d’entraînement ?
À retenir
Les modèles sont entraînés sur d’immenses quantités de textes et de code provenant d’Internet, et les benchmarks populaires sont accessibles au public. Si les tâches et leurs solutions se sont retrouvées dans les données d’entraînement, le modèle peut les avoir mémorisées et simplement les restituer pendant l’évaluation au lieu de les résoudre. On appelle cela une fuite de tâches dans les données d’entraînement. Plus le jeu est ancien et connu, plus le risque est élevé : un vieux benchmark risque davantage de mesurer la mémoire du modèle que sa capacité de raisonnement. Les jeux de tâches récents et fermés sont plus fiables que les anciens jeux publics.
Voici le piège invisible dans le chiffre lui-même, mais qui le discrédite plus que tout le reste. Les modèles sont entraînés sur d’immenses quantités de textes et de code recueillis sur Internet. Et presque tous les benchmarks de programmation sont accessibles au public : les tâches, les tests et les solutions de référence.
Le mécanisme est simple. Si une tâche et sa solution correcte se sont retrouvées dans les données d’entraînement, le modèle peut les avoir mémorisées. Pendant l’évaluation, il ne résout alors pas vraiment la tâche, mais récupère une réponse familière dans sa mémoire. Cela ressemble à une solution, mais ce n’est qu’un souvenir. On appelle cela une fuite de données d’entraînement ou une contamination des données.
Plus le jeu de tâches est ancien et populaire, plus le risque est élevé. HumanEval est en ligne depuis 2021 ; il a été réécrit, analysé et intégré à d’innombrables jeux de données, et ce à de nombreuses reprises. Il serait étrange de s’attendre à ce qu’un modèle moderne ne l’ait jamais « vu ». Voilà pourquoi la fraîcheur des tâches est un indicateur de qualité distinct pour un benchmark. Un bon jeu est soit mis à jour régulièrement, soit conserve certaines tâches fermées pour qu’elles ne puissent pas être apprises à l’avance.
Que faire lorsqu’on lit un classement ? Vérifiez la date des tâches et si le jeu est mis à jour. Si un benchmark est constitué de défauts récents, datant des derniers mois, il mérite davantage confiance. S’il repose sur un jeu vieux de cinq ans, un pourcentage élevé en dit davantage sur la bonne mémoire du modèle que sur sa capacité à résoudre votre nouvelle tâche. L’article consacré au [benchmark FrontierCode récent](https://ailoot.ai/blog/fr/frontiercode-benchmark-mergeable-ai-code/), dont les tâches étaient volontairement nouvelles, illustre précisément cet effet avec un exemple concret.
## Pourquoi un écart de quelques points de pourcentage ne signifie-t-il souvent rien ?
À retenir
Les benchmarks présentent une variance : le même outil donne des résultats légèrement différents sur les mêmes tâches lors de plusieurs exécutions, car le modèle ne répond pas toujours de la même façon. C’est pourquoi un écart d’un ou deux points entre des lignes voisines d’un classement se perd souvent dans le bruit et n’indique pas une réelle supériorité. Vérifiez aussi le prix séparément : des pourcentages similaires peuvent coûter plusieurs fois plus cher. Comparez les coûts seulement si les deux configurations complètes, taux de réussite, hypothèses de facturation et dénominateurs sont donnés.
Autre raison pour laquelle la première place d’un tableau peut être trompeuse : un modèle ne répond pas toujours de la même manière. Pour le même prompt, il peut adopter un raisonnement légèrement différent. Si vous faites donc tourner plusieurs fois un outil sur le même jeu de tâches, son pourcentage varie un peu d’une exécution à l’autre ; cette variation s’appelle la variance.
La conclusion pratique est simple. Quand deux lignes d’un classement diffèrent d’un ou deux pour cent, cet écart peut facilement n’être que du bruit. Il est insensé de courir après un outil « deux pour cent meilleur » : les places peuvent facilement s’inverser à la prochaine exécution. Un écart mérite d’être considéré comme significatif s’il est notable et se maintient sur un grand jeu de tâches ; quelques points ne satisfont pas ce critère.
Et le dernier élément, presque toujours plus important que le pourcentage lui-même, est le prix. Des résultats similaires peuvent coûter des sommes très différentes. La comparaison exige les deux configurations modèle-harnais et la dépense totale sur les tâches évaluées, échecs compris. Divisez par les tâches tentées pour un coût par tentative ou par les tâches résolues pour un coût par résultat, en précisant le dénominateur. Cet article ne fournit aucune mesure appariée sourcée de coût. Lisez donc toujours une ligne de classement avec son prix, car le pourcentage seul a peu de sens. L’article sur le [coût d’une tâche résolue](https://ailoot.ai/blog/fr/ai-agent-cost-per-solved-task/) explique comment comparer équitablement les outils en fonction de leur coût.
## Comment lire n’importe quel tableau de benchmark en une minute ?
À retenir
Avant de vous fier à un classement, posez-vous sept questions : quel jeu de tâches ? Les tâches sont-elles récentes ou anciennes ? Quel modèle ? Quel agent wrapper ? Quel niveau de raisonnement ? Quel est le coût par tâche ? Quelle est l’ampleur de la variance ? Si le tableau ne répond pas à au moins la moitié de ces questions, vous ne pouvez pas lui faire confiance : il s’agit probablement d’une publicité. Vérifiez séparément si les tâches du jeu ressemblent à votre travail réel, car même un pourcentage honnête obtenu sur les tâches de quelqu’un d’autre ne se transpose pas à votre projet.
Résumons le tout sous la forme d’une courte liste de contrôle. Ouvrez n’importe quel tableau de classement et passez en revue ces sept points, dans l’ordre.
1. **Quel jeu de tâches ?** HumanEval est peu pertinent aujourd’hui ; SWE-bench se rapproche davantage du travail réel. Si le jeu n’est même pas nommé, inutile d’aller plus loin.
2. **Les tâches sont-elles récentes ou anciennes ?** Un jeu récent ou partiellement fermé est plus fiable qu’un ancien jeu public que le modèle a peut-être appris.
3. **Quel modèle a été évalué ?** Le nom exact et la version, pas un vague « IA » ni le nom d’une famille de modèles.
4. **Quel agent wrapper ?** Le pourcentage correspond à la combinaison « modèle plus wrapper ». Si le wrapper n’est pas précisé, vous ne savez pas ce qui a été mesuré.
5. **Quel niveau de raisonnement ?** Un même modèle donne des pourcentages différents à des niveaux différents, avec des coûts différents.
6. **Combien coûte une tâche ?** Des résultats similaires peuvent présenter des écarts de prix de plusieurs fois. Lisez le pourcentage avec le coût.
7. **Quelle est la variance ?** Un écart d’un ou deux points entre les lignes n’est souvent que du bruit.
Il y a une huitième question, qui vous concerne : **Les tâches du jeu ressemblent-elles à votre travail ?** Un benchmark de tâches Python en dit peu à quelqu’un qui crée un site Web ou un bot avec un autre ensemble d’outils. Même un chiffre honnête obtenu sur les tâches de quelqu’un d’autre ne garantit pas un résultat dans votre projet. Il n’existe qu’une seule façon fiable de le vérifier : faites exécuter au modèle quelques-unes de vos tâches habituelles et examinez vous-même le résultat. L’article sur [la vérification du code généré par l’IA](https://ailoot.ai/blog/fr/check-ai-generated-code/) explique comment déterminer si le code fonctionne quand on ne programme pas soi-même.
## Alors, à quoi faut-il finalement faire attention ?
À retenir
Regardez les conditions qui accompagnent la première ligne, pas seulement cette ligne : le jeu de tâches et sa fraîcheur, la combinaison « modèle plus wrapper », le niveau de raisonnement, le coût par tâche et l’ampleur de la variance. Un chiffre seul, sans ces conditions, ne prouve rien. Et rappelez-vous que même un pourcentage honnête obtenu sur les tâches de quelqu’un d’autre ne se transpose pas à votre projet : le dernier mot revient toujours aux essais sur vos propres tâches réelles, et votre résultat dépend davantage de votre façon de travailler avec l’outil que de sa place dans le classement.
L’idée principale de tout l’article est simple : une place dans le classement est une raison d’examiner un outil de plus près, mais il faudra creuser vous-même. Un chiffre élevé signifie seulement qu’un outil s’est plutôt bien débrouillé sur une liste fermée de tâches donnée, dans des conditions précises. Le pourcentage ne montre pas si ces conditions correspondent aux vôtres.
Lisez donc ce qui se trouve sous la ligne du classement : quelles tâches ont été utilisées, à quel point elles sont récentes, quelle combinaison modèle et wrapper a été employée, quel niveau de raisonnement était activé, combien cela coûte et si l’écart se perd dans le bruit. Un tableau qui ne répond pas à ces questions a sa place sur une bannière publicitaire. L’article [quel outil de programmation utiliser en 2026](https://ailoot.ai/blog/fr/ai-coding-tools/) explique quel outil choisir pour vos tâches au départ.
Et voici ce qui compte davantage que n’importe quel benchmark. Même le meilleur outil du classement a du mal avec un contexte désordonné et fonctionne bien avec un contexte clair. Votre taux de réussite personnel dépend de ce que vous donnez au modèle et de la façon dont vous formulez la tâche ; la ligne du tableau passe au second plan. Le classement aide à écarter les options manifestement faibles, mais c’est vous qui produisez le résultat.
### Sources
- [HumanEval - jeu de données openai/openai_humaneval (huggingface.co)](https://huggingface.co/datasets/openai/openai_humaneval) - jeu de 164 tâches Python, vérifiées à l’aide de tests automatisés
Une place dans le classement permet d’écarter les options faibles, mais les résultats dans votre projet dépendent de la méthode : clone IA plus Second Brain plus ingénierie du contexte.
Pour poursuivre votre travail, rendez-vous sur [Ailoot](https://ailoot.ai/).
## Questions fréquentes : Benchmarks de codage IA : comparer résultats, coût et tests
### Que relever avant de comparer deux lignes de benchmark ?
Modèle exact, harnais et révision, réglages de raisonnement, sous-ensemble de tâches, notation, date et source directe du résultat. Sans ces champs, un écart de score ne peut être attribué à un réglage unique.
### Le coût par tentative équivaut-il au coût par tâche résolue ?
Non. Divisez la dépense totale par toutes les tâches tentées pour le premier, ou par les tâches résolues pour le second. Incluez les dépenses des échecs et nommez le dénominateur avant comparaison.
## Ailoot · L’entreprise et son portefeuille de projets
Ailoot s’appuie sur une expérience opérationnelle éprouvée, une large clientèle, un service stable et un suivi continu des KPI.
L’entreprise et son portefeuille de projets : des millions de clients ; des ventes qui se chiffrent en milliards chaque mois.
Ailoot met cette expérience opérationnelle au service de l’accès API aux fonctions d’IA dans les produits des clients, leurs agents, applications et automatisations.