FrontierCS 2 teste 12 agents IA sur des tâches de R&D : le meilleur en réussit 58%

Le benchmark FrontierCS 2 pose une question que l'industrie évite généralement : un agent LLM peut-il, au lieu de résoudre un exercice scolaire, produire une contribution digne d'un article scientifique ? Le jeu se compose de 48 tâches ouvertes réparties dans 13 domaines. Sur les 12 agents testés, le meilleur, Claude Opus 5.5, réussit 58% de ses exécutions. Sur 16 tâches, aucune exécution n'a abouti : le résultat est donc nul sur un tiers du jeu.

Comment transformer un article en examen

Le principe est simple et plutôt exigeant. Les auteurs prennent un article scientifique et le code que ses auteurs ont publié en accès libre, puis suppriment du dépôt précisément le code qui implémente la contribution du travail. La partie retirée devient la référence humaine : la barre n'est pas un seuil abstrait, mais ce que des chercheurs ont réellement conçu.

L'agent reçoit un dépôt fonctionnel privé de sa partie clé et doit la reconstituer ou la surpasser. Les tâches couvrent 13 domaines : systèmes de machine learning, calcul haute performance, bases de données, sécurité, robotique et d'autres. En plus des 48 tâches publiées, FrontierCS 2 dispose d'un jeu fermé de plus de 100 tâches, qui sera annoncé plus tard. Il sert de protection contre le surapprentissage du benchmark public : ce que l'agent n'a jamais vu, il ne peut pas l'optimiser à l'avance.

Un environnement de recherche plutôt qu'un seul essai

Les précédents benchmarks ouverts donnaient généralement à l'agent l'énoncé d'un problème et évaluaient un unique programme à la fin de l'exécution. FrontierCS 2 change de format : l'agent travaille dans un environnement de recherche et peut soumettre un patch à tout moment. Pour chaque patch, le juge renvoie une note sur le jeu de développement, un signal qui permet d'améliorer la solution par itérations, comme le ferait un humain.

L'évaluateur lui-même, le jeu de tests final mis de côté et la solution de référence restent en revanche fermés. La soumission finale est vérifiée sur un jeu caché et comparée à la référence. L'agent peut ajuster sa solution à la métrique visible, mais elle sera testée sur des données qu'il n'a pas observées.

Un score élevé ne vaut pas validation

Le plus intéressant dans les résultats n'est pas le chiffre de 58%, mais l'écart entre le score et la validation. La plupart des exécutions qui ont dépassé la référence sur le score final cumulé ont tout de même échoué : elles ont calé sur une métrique précise ou sur une charge de travail précise. C'est une situation typique du travail sur les systèmes. Une optimisation de base de données ou de noyau HPC qui accélère un scénario et en casse un autre est inutile en production, et le benchmark en tient compte.

Les auteurs ont aussi construit une échelle de capacités commune aux agents et aux tâches. La tâche médiane s'est révélée d'une difficulté à peu près équivalente à ce que le plus fort des agents peut résoudre. Le jeu n'est pas trop facile, sinon les résultats auraient atteint un plafond, et il n'est pas non plus hors de portée d'emblée. Il laisse une marge pour mesurer les progrès des prochains modèles.

Paramètres clés

• 48 tâches ouvertes dans 13 domaines, plus un jeu fermé de plus de 100 tâches
• 12 agents testés
• Meilleur résultat : Claude Opus 5.5, 58% d'exécutions réussies
• 16 tâches sur lesquelles aucune exécution n'a abouti
• L'agent peut soumettre des patchs à tout moment et reçoit une note sur le jeu de développement
• L'évaluateur, le jeu de tests final et la référence sont cachés à l'agent

Ce que les équipes qui construisent des agents doivent retenir

Pour ceux qui développent des agents de code et des pipelines de recherche, le benchmark offre trois enseignements pratiques. Premièrement, il faut évaluer sur un ensemble de métriques et de charges de travail, et non sur un seul chiffre agrégé : un gain moyen masque des régressions. Deuxièmement, la capacité à itérer à partir du retour du jeu de développement tout en tenant sur le jeu caché mérite un test à part, car c'est là qu'un agent se distingue d'un simple générateur de code.

Troisièmement, l'échec sur 16 tâches montre où se situe le plafond. Ces tâches exigent non seulement des compétences en programmation, mais aussi une intuition de recherche, et le jeu fermé permettra de voir si cette intuition progresse chez les prochaines générations de modèles.