ICML 2026 : 2 200 articles reproduits par des agents IA
Hugging Face rapporte les résultats d’un défi de reproduction à grande échelle sur les articles d’ICML 2026. Plus de 2 200 papiers ont été examinés, avec des résultats qui soulignent autant l’intérêt des agents que les limites d’une validation automatisée.
La recherche en IA produit désormais plus d’articles que les processus de relecture traditionnels ne peuvent en absorber. C’est le constat qui motive l’initiative ICML 2026 Open Reproductions, relatée par Hugging Face : pendant 19 jours, une communauté de plus de 1 200 personnes a tenté de reproduire, affirmation par affirmation, une partie des publications acceptées à ICML 2026 à l’aide d’agents de code.
Le résultat affiché est massif : 6 816 carnets de reproduction publiés pour 2 226 articles étudiés, soit environ un tiers de la conférence. Mais le chiffre le plus intéressant n’est pas le volume. C’est ce qu’il révèle : la reproductibilité ne se résume ni à un oui, ni à un non. Elle dépend des données accessibles, de la précision du papier, de l’horizon expérimental et de la capacité à confronter plusieurs implémentations.
Les agents peuvent industrialiser la vérification expérimentale, mais ils ne remplacent pas le jugement scientifique. Leur valeur apparaît surtout lorsqu’ils produisent des preuves inspectables, confrontées par plusieurs équipes et revues de manière contradictoire.
ICML 2026 face à un problème d’échelle
Selon Hugging Face, ICML 2026 a reçu 23 918 soumissions et accepté 6 352 articles. Le volume aurait approximativement doublé par rapport à l’année précédente. La source y voit, au moins en partie, l’effet d’outils d’IA qui accélèrent la conduite des expériences et la rédaction des travaux.
En face, la capacité de relecture ne progresse pas au même rythme. Les évaluateurs de conférences sont généralement des bénévoles et ne peuvent pas toujours vérifier intégralement les démonstrations, le code ou les résultats expérimentaux. La source cite ainsi le commentaire d’un évaluateur d’un article mis en avant à ICML : sa faible confiance venait du fait qu’il n’avait pas contrôlé toutes les preuves.
Le défi ne prétend donc pas remplacer le peer review. Il explore une autre couche de contrôle : demander à des agents capables de lire un article, d’écrire du code, de lancer des expériences et de documenter leurs résultats de vérifier un très grand nombre de revendications en parallèle.
Un protocole public, centré sur les affirmations vérifiables
Le challenge s’est déroulé du 15 juillet au 2 août 2026. Les organisateurs ont indexé 6 341 articles acceptés et en ont extrait les principales affirmations scientifiques. L’objectif était de fournir un point de départ concret aux participants, plutôt que de les laisser naviguer seuls dans des PDF parfois très longs.
Les participants pouvaient choisir leur environnement : Claude Code, Codex, Cursor, orx d’OpenResearch ou d’autres agents. Hugging Face leur attribuait 20 dollars de crédits de calcul pour utiliser HF Jobs. Au total, 2 962 tâches cloud ont été lancées.
Chaque tentative devait aboutir à un Trackio logbook, un carnet public hébergé sous forme de Space Hugging Face. Il pouvait contenir :
- le compte rendu de la reproduction ;
- le code exécuté ;
- les artefacts produits ;
- éventuellement, la trace complète de l’agent sous forme de dataset.
Ce choix est central : l’audit devait lui-même être auditable. Pour juger les carnets, un système automatisé reposant sur le modèle à poids ouverts GLM-5.2 relisait les éléments fournis et attribuait un verdict par affirmation : verified, falsified, toy pour une preuve à échelle réduite, ou inconclusive. La source précise que ce juge devait considérer l’auto-évaluation du participant comme non fiable par défaut.
51 % des articles examinés ont au moins une affirmation vérifiée
Les chiffres publiés doivent être lus avec précision : ils concernent les 2 226 articles effectivement examinés, et non l’ensemble d’ICML 2026. Parmi eux, 1 103 articles, soit 51 %, comportaient au moins une affirmation vérifiée indépendamment.
Dans ce groupe, 266 articles étaient intégralement reproduits au sens du protocole : toutes les affirmations extraites avaient été vérifiées. Pour 632 autres, une reproduction partielle n’avait identifié aucune affirmation falsifiée. La source comptabilise au total 3 978 affirmations confirmées par des expériences.
À l’inverse, 496 articles (23 % de l’échantillon) avaient au moins une affirmation contestée ou falsifiée. Ce total inclut 49 articles dont toutes les affirmations étaient jugées falsifiées sans qu’aucune ne soit vérifiée. Plus révélateur encore, 242 articles ont reçu des verdicts opposés de la part d’équipes indépendantes sur les mêmes affirmations.
Ce dernier chiffre interdit toute lecture simpliste. Des résultats contradictoires peuvent refléter des différences d’implémentation, de paramètres, de matériel, d’interprétation du protocole ou de durée d’exécution. La source ne permet pas d’attribuer une cause générale à ces désaccords. Elle montre en revanche qu’un unique essai de reproduction ne suffit pas toujours à trancher.
Les contre-exemples confirment la nécessité d’aller au-delà des tests courts
Hugging Face indique avoir réexaminé de façon contradictoire les 35 signalements formels de falsification : relecture du papier et du carnet, redérivation mathématique ou réimplémentation à partir du texte original. Quelques cas sont détaillés dans la source.
Pour l’article Towards Optimal Robustness in Learning-Augmented Paging, une reproduction aurait identifié une étape défaillante dans une preuve. L’algorithme revendiquait une robustesse de Hk + O(1), tandis que les mesures rapportées par le participant faisaient croître le terme additif comme 0,38 ln(k). La réimplémentation des organisateurs, étendue jusqu’à k = 1 024, aurait confirmé cette croissance. La source conclut que la robustesse effective est Hk + Θ(log k).
Un autre article, Attention’s forward pass and Frank-Wolfe, contenait une affirmation qui semblait tenir sur des horizons limités. Trois équipes ont toutefois trouvé des contre-exemples, avec des violations apparaissant après 224, environ 3 800 et 6 416 étapes selon les essais. La source indique que les auteurs ont confirmé le problème et travaillent à une correction.
La leçon pratique vaut aussi pour tes propres benchmarks : un test qui passe sur quelques itérations, une petite taille de données ou une seule graine aléatoire ne valide pas nécessairement une propriété générale. Les tests longs, les cas limites et les implémentations indépendantes restent nécessaires.
Ce que les équipes produit et recherche peuvent reprendre dès maintenant
Cette opération ne démontre pas que les verdicts automatisés sont définitifs. Une part importante des résultats reste intermédiaire : 502 articles n’avaient que des preuves à échelle réduite et 280 ne pouvaient pas être établis dans un sens ou dans l’autre, notamment à cause d’artefacts manquants. Les jeux de données propriétaires et les checkpoints non publiés limitaient aussi les reproductions complètes.
En revanche, le protocole fournit un modèle utile pour une équipe qui publie un benchmark, un modèle ou une brique open source :
- transforme chaque promesse en affirmation mesurable ;
- publie le code, les versions de dépendances, les paramètres et les données ou un substitut documenté ;
- conserve les artefacts d’exécution plutôt qu’un tableau final isolé ;
- fais rejouer les expériences par une autre personne, ou par un agent configuré indépendamment ;
- sépare clairement les résultats reproduits à pleine échelle des validations réduites.
Si tu utilises des agents pour accélérer la R&D, le bon réflexe n’est donc pas de leur déléguer un verdict final. Utilise-les pour multiplier les tentatives, automatiser la collecte de preuves et rendre les divergences visibles. La décision scientifique, elle, exige encore de relire les hypothèses, les preuves et les conditions de l’expérience.