Des agents d'IA ont revérifié plus de 2 000 articles d'ICML 2026 et trouvé des erreurs échappées aux relecteurs

La relecture par les pairs dans les grandes conférences de ML repose en grande partie sur la confiance. Le relecteur reçoit plusieurs articles, dispose de quelques semaines et, en général, ne lancera pas le code d'autrui pour vérifier un seul tableau. À l'été 2026, on a décidé de tester cela de front, en faisant appel à des agents d'IA.

Ce qui s'est passé

Hugging Face, avec alphaXiv, un service de discussion de publications scientifiques, a organisé le hackathon ICML 2026 Open Reproductions. L'objectif : prendre les travaux acceptés à la conférence (plus de deux mille) et tenter de reproduire les résultats annoncés. Les participants l'ont fait avec des agents d'IA. Dans les articles, on a trouvé des erreurs que les relecteurs n'avaient pas remarquées.

ICML est l'une des principales conférences d'apprentissage automatique, et un article accepté est souvent perçu comme un gage de qualité. Mais le relecteur voit un PDF, et le code joint reste bien souvent inexécuté : ni le temps ni les incitations ne suffisent.

Il est important de noter ce que le message d'origine ne dit pas. On ne sait pas combien de travaux ont pu être entièrement reproduits, combien d'erreurs ont été trouvées ni quelle est leur gravité : une coquille dans une formule ou un résultat qui s'effondre. Sans ces chiffres, il est trop tôt pour dire que les agents ont « réfuté » une part de la science. Mais le format est en lui-même révélateur : revérifier deux mille articles se heurtait jusqu'ici au manque de personnes et de temps.

Comment cela fonctionne en pratique

Le schéma pour l'agent ressemble à ceci : lire l'article, trouver le dépôt ou reconstituer la méthode à partir de la description, exécuter le code, obtenir les chiffres et les comparer au tableau du texte. Chaque étape prise isolément est fastidieuse, mais c'est précisément à ces étapes que les résultats se brisent.

Supposons qu'un article annonce un gain de 3 points de pourcentage sur un benchmark. L'agent lance le code avec les réglages indiqués et obtient un gain d'un demi-point. Plusieurs cas de figure sont alors possibles : l'hyperparamètre du texte ne correspond pas à celui du code, les données de test se sont retrouvées dans l'entraînement, ou le modèle de référence utilisé pour la comparaison a été moins bien réglé que celui des auteurs. Un humain qui n'exécute pas le code ne le verra pas. L'agent ne se fatigue pas et peut mener des centaines de vérifications en parallèle.

Ce sont des causes typiques de divergences, et non la liste des découvertes du hackathon : les types précis d'erreurs ne sont pas dévoilés dans les données d'origine.

Que faire : conseils pour les développeurs et les product managers

Ne prenez pas le tableau d'un article pour une garantie. Si vous construisez un produit sur l'« état de l'art » d'un travail récent, ses chiffres restent une hypothèse. Prévoyez du temps pour votre propre reproduction et vérifiez d'abord que personne n'a déjà essayé avant vous.

Appliquez la même approche en interne. Un agent qui prend votre rapport interne d'expérience ou l'évaluation d'un modèle et tente de la refaire de zéro à partir de la description est un moyen peu coûteux de trouver l'écart entre ce qui est écrit et ce qui a réellement été exécuté. Pour les équipes qui publient des benchmarks et des comparaisons, c'est presque une étape de QA toute prête.

Regardez le marché. Pour les fondateurs, le hackathon met en lumière une niche : outils de vérification de la reproductibilité, vérificateurs de méthodologie, audit de recherche pour les investisseurs et les départements de R&D des entreprises.

Limites

Un agent qui n'a pas réussi à reproduire un résultat n'a pas encore prouvé l'erreur des auteurs. La cause peut être un manque de ressources de calcul, des données fermées, une description incomplète de la méthode ou une erreur de l'agent lui-même. Les découvertes doivent donc être confirmées par un humain. Le schéma réaliste est celui où l'agent rassemble les candidats à l'erreur et où l'expert rend le verdict.

Il existe aussi un risque inverse. Un flot de faux positifs submergerait les auteurs de réclamations à traiter à la main, et la confiance dans les vérifications automatiques chuterait vite.

Les relecteurs n'ont pas disparu, mais ils ont désormais un partenaire qui exécute vraiment le code. La reproductibilité cesse d'être un luxe et devient une procédure automatisable, une sorte de CI pour la science. Les équipes qui dépendent des recherches récentes feraient bien de s'y habituer avant les auteurs d'articles.