Peut-on comparer les modèles IA avec les données publiques ?

Non, le corpus public que nous avons audité ne permet pas encore une comparaison scientifique complète des modèles d'IA. Des résultats détaillés existent, parfois jusqu'à chaque action du modèle. Mais les mêmes modèles ne sont presque jamais testés sur les mêmes tâches, avec les mêmes outils et les mêmes réglages, par deux organismes indépendants.

La conséquence pour une entreprise est simple : un classement public aide à choisir les candidats à tester. Il ne suffit pas pour signer un contrat, remplacer un modèle en production ou promettre un gain de qualité.

“We will run your model on a random subset of SWE-bench and verify the results.” Autrement dit, l'équipe de SWE-bench décrit une vérification sur un échantillon aléatoire, pas une validation automatique de chaque dépôt de résultat.

La réponse en trente secondes

• Les données brutes existent. Nous avons pu lire des fichiers de configuration et des traces d'exécution publiques.
• Le croisement manque. Les mêmes modèles et les mêmes conditions ne se retrouvent pas assez souvent d'un banc d'essai à l'autre.
• Le nom affiché ne suffit pas. Deux résultats Qwen publics renvoient à une famille de modèle, tandis que leurs traces enregistrent un autre identifiant.
• Le mot « vérifié » ne couvre pas toutes les lignes. Dans notre relevé daté, 60 dépôts sur 182 portent le statut contrôlé par l'équipe.
• La décision utile reste locale. Une PME doit tester les deux ou trois candidats retenus sur ses propres dossiers avant de basculer.

Ce que nous avons réellement audité

Un benchmark, c'est-à-dire un banc d'essai commun, doit permettre de répondre à une question précise. Plusieurs benchmarks ne deviennent comparables que s'ils posent réellement la même question. Ici, nous ne cherchions pas le meilleur modèle. Nous avons cherché une situation publique où au moins deux organismes auraient évalué les mêmes modèles, sur une population de tâches comparable, avec des conditions assez proches pour mettre les résultats en commun.

Nous avons étudié trois collections publiques consacrées à la réparation de logiciels : SWE-bench Verified, SWE-bench Pro et SWE-bench Live. Elles ont un avantage rare. Elles publient non seulement des notes finales, mais aussi des métadonnées, des instructions de lancement et, pour certaines courses, les traces détaillées des actions. Cela permet de regarder derrière le podium.

Une trace d'exécution est simplement le journal de ce que le système a fait : modèle appelé, commandes lancées, outils utilisés, nombre maximal d'actions et résultat obtenu. C'est l'équivalent du carnet de laboratoire. Sans ce carnet, un score final ne dit pas pourquoi deux systèmes diffèrent.

Notre audit a suivi une règle stricte : ne jamais déduire une condition à partir du nom d'une ligne. Nous avons confronté le nom public, le fichier de présentation, le fichier de réglages et la trace quand elle était disponible. Nous n'avons exécuté aucun modèle et n'avons demandé aucune donnée privée. Origin compile ici les pièces publiques et documente leurs limites.

Apport Origin : ce travail apporte trois contrôles qui manquent aux podiums habituels. Le premier vérifie l'identité réelle du modèle. Le deuxième sépare les résultats contrôlés par l'équipe du banc d'essai des résultats seulement déposés. Le troisième compare les réglages qui peuvent changer la difficulté réelle : outils, limite d'actions et niveau d'aléa. Cette grille ne transforme pas des données incomplètes en certitude. Elle montre exactement où la certitude s'arrête.

Premier constat : les données existent, le croisement manque

Le problème n'est donc pas une absence générale de transparence. SWE-bench et les équipes qui déposent des résultats publient beaucoup. On peut parfois retrouver la version du logiciel de pilotage, la version de l'environnement d'exécution, la consigne complète et chaque réponse du modèle. Peu de classements commerciaux vont aussi loin.

Le problème apparaît au moment de comparer. Pour réunir plusieurs résultats, il faut retrouver le même modèle exact dans plusieurs bancs d'essai. Il faut ensuite vérifier que la tâche mesure la même capacité. Réparer un défaut dans un dépôt existant n'est pas la même chose que répondre à une question de programmation, reconstruire un programme ou résoudre un exercice isolé.

Il faut enfin disposer d'une mesure compatible. Une réussite par tâche peut être comparée à une autre réussite par tâche. Une durée maximale de mission ne peut pas être additionnée à un pourcentage. Une note donnée par un autre modèle ne se mélange pas non plus automatiquement avec des tests exécutables qui acceptent ou refusent le correctif.

Sur le papier, la réparation de défauts semblait être la sous-capacité la plus favorable. Verified, Pro et Live partagent l'idée générale : fournir un dépôt et une demande de correction, puis vérifier le changement. Pourtant, le croisement public se réduit dès que l'on impose l'identité du modèle et des conditions. Les deux exemples les plus proches que nous avons trouvés échouent précisément sur ces points.

Le cas Qwen3 : un même nom public, un autre identifiant dans la trace

Le premier croisement concerne Qwen3-Coder. Dans SWE-bench Verified, le fichier public de la course affiche « Qwen3-Coder-480B-A35B-Instruct ». Il renvoie vers les poids téléchargeables du modèle et indique qu'il s'agit d'un modèle ouvert. La présentation de la course Live affiche la même famille, sous le nom plus court « Qwen3-Coder-480B-A35B ».

Les traces racontent autre chose. La trace publique côté Verified enregistre uniquement l'identifiant « Qwen3-Coder-Max-0721 ». La trace publique côté Live enregistre ce même identifiant différent.

Nous ne pouvons pas conclure, à partir de ces seuls fichiers, pourquoi les noms diffèrent. Il peut s'agir d'un alias de service, d'une erreur de présentation ou d'une autre route d'accès. Nous pouvons seulement établir que le modèle déclaré publiquement et l'identifiant enregistré pendant l'exécution ne correspondent pas. Le dépôt officiel de Qwen3-Coder confirme par ailleurs que « Qwen3-Coder-480B-A35B-Instruct » est bien le nom d'un modèle dont les poids sont téléchargeables.

Cette différence suffit à écarter le croisement. Une comparaison scientifique exige de savoir ce qui a réellement été appelé. Si deux traces utilisent « Qwen3-Coder-Max-0721 », elles renseignent peut-être le même service. Elles ne prouvent pas que ce service est identique au modèle ouvert affiché sur les pages.

La réserve est encore plus importante : la course Verified concernée porte checked: false. Ce champ signifie qu'elle n'a pas obtenu le statut de vérification décrit par l'équipe SWE-bench. Le meilleur croisement public trouvé repose donc sur une identité de modèle non résolue et sur un résultat non recontrôlé par l'équipe du banc d'essai.

Le cas Claude Sonnet 4 : même modèle, conditions différentes

Le deuxième croisement est plus discret. Claude Sonnet 4 apparaît dans SWE-bench Verified et SWE-bench Pro avec la même version de SWE-agent 1.1.0, le logiciel qui lui donne les instructions et les outils. À première vue, c'est exactement le cas recherché : même modèle, même agent, même famille de tâche.

Les fichiers de trace montrent pourtant trois différences matérielles. Dans la course Verified, l'environnement SWE-rex est en version 1.2.1. Dans la course Pro, il est en version 1.2.2. Le nombre maximal d'appels autorisés passe de 150 à 250. Enfin, le réglage de température passe de 0 à 1. La température règle la part d'aléa dans les réponses : 0 vise un comportement plus stable, 1 autorise davantage de variation.

Ces différences ne disent pas que l'une des équipes a mal travaillé. Elles disent que les deux scores répondent à des expériences différentes. Donner jusqu'à 250 actions au lieu de 150 peut permettre de terminer davantage de tâches, mais aussi consommer plus de temps. Changer l'aléa peut aider sur certains problèmes et nuire sur d'autres. Modifier l'environnement peut corriger des défauts techniques sans changer le modèle.

On ne peut donc pas attribuer un éventuel écart de score au seul niveau du modèle. La tâche, l'environnement et le budget d'action ont changé en même temps. Même si les deux résultats sont utiles séparément, leur addition donnerait une précision artificielle.

Le mot « Verified » demande lui aussi une lecture précise

SWE-bench Verified est le nom d'un jeu de tâches revu pour retirer les problèmes ambigus. Ce nom ne signifie pas que chaque résultat déposé dans son répertoire a été contrôlé par l'équipe du projet. Le statut de chaque course se trouve dans son fichier de métadonnées.

Nous avons compté les 182 dossiers présents dans le répertoire public evaluation/verified au commit du 3 septembre 2026. Soixante fichiers portent checked: true. Cent trois portent une valeur commençant par false, dont six recopient une phrase explicative à la place d'un simple booléen. Dix-neuf n'ont pas de statut exploitable : dix-huit valeurs nulles et un champ absent.

Le résultat important n'est pas que 103 courses seraient fausses. Ce serait une interprétation incorrecte. Leur score peut être exact. Le fichier dit seulement qu'elles ne portent pas le statut de vérification par l'équipe. La nuance change la qualité de preuve, pas nécessairement la performance.

La méthode publique précise le contrôle effectué pour obtenir ce statut : l'équipe relance le modèle sur un sous-ensemble aléatoire et vérifie les résultats. C'est utile, mais ce n'est ni une répétition complète de toutes les tâches ni une garantie générale attachée au nom du jeu.

Ce que cela change pour un dirigeant de PME

Le risque n'est pas seulement académique. Supposons qu'une entreprise veuille choisir un modèle pour corriger le code de son logiciel métier. Un classement place le modèle A devant le modèle B. Le dirigeant peut être tenté de migrer immédiatement, car le chiffre semble objectif.

Mais le score du modèle A a peut-être été obtenu avec davantage d'actions, une autre version de l'outil et plusieurs essais. Le modèle B a peut-être été mesuré avec une limite plus stricte. Le premier peut rester meilleur, mais le classement ne prouve pas la taille de l'avantage dans les conditions de l'entreprise.

Ce défaut touche aussi le budget. Cent actions autorisées de plus peuvent augmenter la facture et le délai. Plusieurs tentatives peuvent améliorer le taux de réussite tout en multipliant le coût. Une correction acceptée par les tests du banc public peut encore être refusée par les règles de sécurité, les conventions ou la revue humaine de l'entreprise.

Le bénéfice d'un audit de preuve est donc concret : éviter de changer de fournisseur sur une différence qui vient du protocole, c'est-à-dire de la manière de tester, plutôt que du modèle. La méthode Origin pour choisir un modèle selon le travail réel commence par cette séparation. Notre analyse des résultats Astra et de leurs contradictions montre le même problème à l'échelle d'indices plus larges.

Cas pratique : choisir un modèle pour maintenir un logiciel métier

Ce scénario est une construction pédagogique, pas un résultat client. Une PME édite un outil de planification. Elle veut confier à un assistant IA les défauts simples : erreur d'affichage, export incomplet, filtre qui oublie une catégorie. Deux modèles sortent d'une première sélection grâce aux classements publics.

La bonne décision tient en cinq étapes :

1. Geler vingt dossiers réels. Chaque dossier contient le rapport du défaut, le dépôt dans son état initial et le résultat attendu. Les cas sensibles sont remplacés par des exemples anonymisés.
2. Garder le même équipement. Les deux modèles reçoivent le même logiciel de pilotage, les mêmes outils, la même limite d'actions et le même délai.
3. Mesurer une réussite utile. La correction doit passer les tests automatiques, respecter les règles internes et être acceptée par un développeur. Un correctif qui passe un test mais crée une régression n'est pas réussi.
4. Conserver les échecs. On archive les commandes, les refus, les dépassements de délai et les interventions humaines. Un taux final sans les échecs empêche d'expliquer la différence.
5. Décider sur le dossier accepté. La PME compare la qualité, le coût total, le délai et le temps humain par correction validée. Elle ne choisit pas sur le prix unitaire ni sur un podium général.

Cette expérience locale n'a pas vocation à devenir une vérité mondiale. Elle répond mieux à la décision de la PME parce qu'elle fixe les variables que les classements publics laissent varier. Les résultats publics restent utiles en amont : ils réduisent la liste de candidats et révèlent les types de tâches où un modèle mérite d'être essayé.

La fiche simple à lire avant de croire un score

Voici la version destinée à l'utilisateur, sans calcul caché ni note de qualité arbitraire. Pour chaque résultat publié, cinq lignes suffisent :

• Ce qui a été demandé : la tâche réelle, en mots courants.
• Ce qui a été testé : le modèle exact et le logiciel qui l'accompagne.
• Dans quelles conditions : outils, nombre d'essais, temps et budget d'actions.
• Qui a contrôlé : fabricant, organisme extérieur ou vérification mécanique.
• Ce que le résultat ne prouve pas : domaine différent, réglages différents ou données manquantes.

Si l'une des lignes manque, le résultat reste visible mais porte la mention « comparaison impossible ». L'absence de donnée ne devient jamais une égalité, une défaite ou une note moyenne. C'est la règle qui empêche un graphique séduisant de produire un faux gagnant.

La méthode de fond reste plus exigeante. Elle conserve la source exacte, sa date, la version du fichier, la population de tâches, les répétitions, les dépendances avec d'autres indices et les différences de réglage. Ces éléments servent à décider si plusieurs résultats peuvent réellement être réunis. Ils n'ont pas besoin d'encombrer la première lecture.

Cette séparation produit un parcours public beaucoup plus simple. Le lecteur voit d'abord le travail testé, le résultat brut et la limite qui change sa décision. Il peut ensuite ouvrir la fiche de preuve pour retrouver la source et les conditions. Enfin, s'il veut contrôler le calcul, il accède aux données structurées et à la règle d'inclusion. La complexité reste disponible sans devenir l'interface principale.

Elle protège aussi contre deux erreurs graphiques fréquentes. Une barre ne doit pas commencer à mi-hauteur pour rendre spectaculaire un écart minime. Un résultat nul ne doit pas recevoir un remplissage visible pour préserver la mise en page. Les longueurs doivent partir de zéro sur l'échelle publiée, et l'incertitude doit apparaître quand la source la donne. Si deux fourchettes se recouvrent, l'interface ne colore pas artificiellement un vainqueur net.

Pour l'utilisateur, le message tient alors en une phrase : « ces tests permettent une comparaison », « ces tests se contredisent » ou « les données ne suffisent pas ». La méthode complète sert à justifier cette phrase. Elle ne doit jamais la remplacer par un vocabulaire réservé aux statisticiens.

Pourquoi nous ne pondérons pas les sources avec une note maison

Il serait tentant d'attribuer une note à chaque organisme, puis de calculer une moyenne pondérée. Une source jugée sérieuse compterait davantage, une source commerciale moins. Cette approche donne pourtant à l'éditeur du classement un pouvoir dangereux : en changeant les poids, il peut changer le gagnant.

Ce risque n'est pas théorique. Dans une étude publiée dans le JAMA, Jüni et ses coauteurs ont appliqué 25 échelles de qualité aux mêmes 17 essais : l'interprétation changeait selon l'échelle retenue. Le manuel Cochrane actuel déconseille les notes globales de qualité, car elles mélangent des problèmes différents dans un seul chiffre. Nous reprenons ce principe sans prétendre qu'un benchmark IA est un essai médical.

Nous préférons trois décisions visibles. Les données suffisamment comparables entrent dans l'analyse principale. Les données utiles mais plus fragiles apparaissent dans une vérification de sensibilité, c'est-à-dire un second calcul qui montre si la conclusion change. Les résultats du fabricant ou les cas dont l'identité n'est pas établie restent affichés, mais ne participent pas au calcul.

La précision statistique peut ensuite déterminer le poids des résultats comparables. Une expérience comprenant davantage de tâches cohérentes apporte généralement une estimation plus précise qu'une expérience minuscule. Mais aucune formule ne répare une différence de modèle ou de protocole. Le filtre scientifique intervient avant le calcul.

Le NIST confirme pourquoi une moyenne seule ne suffit pas

Le rapport NIST AI 800-3, publié en février 2026, formalise un point central : une note globale peut cacher des écarts importants entre les tâches, les catégories ou les langues. Le rapport recommande d'indiquer clairement ce que l'évaluation cherche à mesurer, les hypothèses retenues et l'incertitude du résultat. Il privilégie aussi l'analyse des essais ou des tâches quand ces données existent.

Cela ne valide ni notre corpus ni une future note Origin. Le NIST propose une boîte à outils statistique, pas un label de conformité. Son apport est plus précis : il confirme qu'un score unique ne suffit pas quand les tâches diffèrent et que les hypothèses restent implicites. La présentation officielle du rapport par le NIST résume cette limite et date sa publication.

Ce que nous pouvons affirmer au 4 septembre 2026

Nous pouvons affirmer que les collections publiques étudiées contiennent des pièces riches et auditables. Nous pouvons établir les différences de noms Qwen3 présentes dans les pages et dans les deux traces citées. Nous pouvons établir les réglages différents des deux courses Claude Sonnet 4. Nous pouvons aussi reproduire le comptage des statuts dans le répertoire SWE-bench Verified au commit indiqué.

Nous ne pouvons pas affirmer qu'aucun organisme privé possède les données nécessaires. Nous ne pouvons pas généraliser cet audit à tous les bancs d'essai imaginables. Nous ne pouvons pas expliquer la cause de l'identifiant Qwen différent. Enfin, nous ne pouvons pas conclure qu'une course non contrôlée est fausse.

La conclusion est plus étroite et plus utile : dans le corpus public vérifié pour cet article, aucun croisement ne réunit les conditions nécessaires à une comparaison scientifique complète entre modèles. Publier une moyenne maintenant masquerait les différences que les sources permettent justement de voir.

Le jour où deux ou trois organismes publieront les mêmes modèles exacts, sur la même sous-capacité, avec leurs résultats par tâche et leurs réglages complets, le calcul deviendra légitime. Jusque-là, le produit honnête n'est pas un podium universel. C'est une carte claire des preuves disponibles, des contradictions et des cases encore vides.

FAQ

Un classement public ne sert donc à rien ?

Il sert à repérer des candidats et à comprendre le type de travail testé. Il ne suffit pas pour décider seul d'un changement en production, car les modèles, les outils et les budgets d'action peuvent différer.

Pourquoi ne pas simplement moyenner tous les scores ?

Parce que les scores ne mesurent pas toujours la même chose. Un pourcentage de défauts réparés, une durée de mission et une note donnée par un juge automatique n'ont pas la même unité. Les moyenner créerait un nombre sans signification stable.

Une course marquée non contrôlée est-elle fausse ?

Non. Cela signifie seulement que le fichier public ne porte pas le statut de vérification par l'équipe du banc d'essai. Le score reste une donnée, avec une preuve moins forte.

Que doit demander une PME à son fournisseur ?

Le nom exact du modèle, la version des outils, le nombre d'essais, les limites d'action, le coût par tâche acceptée et les échecs. Ces informations rendent deux propositions réellement comparables.

Quand une comparaison scientifique deviendra-t-elle possible ?

Quand plusieurs organismes publieront les mêmes modèles exacts sur des tâches comparables, avec des réglages documentés et des résultats assez détaillés pour mesurer l'incertitude. Le calendrier dépend des prochaines publications, pas d'une date fixée par Origin.

Sources

• SWE-bench Experiments, répertoire Verified et règle de vérification, commit 40f164d5b8f1d249bf95a6df8b74b577fd8e519d, consulté le 4 septembre 2026. Les fichiers de métadonnées et les traces citées documentent le statut des courses, les identifiants Qwen3 et les réglages Claude.
• SWE-bench Live, soumission Qwen3-Coder, commit 0506be0e9476f0d888ce49bf97d5c1cc62c90645, consulté le 4 septembre 2026. Le dossier contient la présentation et la trace d'exécution utilisées dans le croisement.
• SWE-bench Pro, dépôt public, commit ca10a60a5fcae51e6948ffe1485d4153d421e6c5, consulté le 4 septembre 2026. La trace publique Claude Sonnet 4 associée documente les versions et réglages comparés.
• Qwen3-Coder, dépôt officiel, commit 33bc6aabd7791ad7b32f7e92104f11f2359ba890, consulté le 4 septembre 2026. Le dépôt confirme le nom et la disponibilité des poids de Qwen3-Coder-480B-A35B-Instruct.
• NIST AI 800-3, A Statistical Framework for AI Evaluation, publié le 19 février 2026 et consulté le 4 septembre 2026. Le rapport distingue la note d'un benchmark de la performance visée et demande d'expliciter les hypothèses et l'incertitude.
• Jüni et al., The Hazards of Scoring the Quality of Clinical Trials, JAMA, 1999, consulté le 4 septembre 2026. L'étude montre que le choix d'une échelle de qualité peut changer l'interprétation d'une même synthèse.
• Cochrane Handbook, chapitre 7, consulté le 4 septembre 2026. Le manuel recommande une évaluation par domaines plutôt qu'une note globale de qualité.