FrontierHarness mesure l’impact du harness sur un agent IA

Ce que FrontierHarness mesure réellement

Ce qui retient l’attention ici n’est pas un nouveau tableau de scores de modèles, mais la tentative de mesurer le harness agentique lui-même. Dans sa publication Introducing FrontierHarness Eval, Runta présente le principe central : un même modèle et un environnement identique ont été exécutés avec neuf harnesses de code en production, répartis sur 12 configurations. Cela a produit 360 évaluations sur 30 tâches.

Le jeu comprend 21 tâches Terminal-Bench et neuf tâches DeepSWE, avec un périmètre très précis : le développement logiciel et le travail en terminal. Le résultat est contrôlé par un vérificateur déterministe selon un schéma réussite/échec, et non par un modèle juge soumis à une variabilité inévitable. L’interprétation devient donc plus simple : la tâche passe la vérification ou elle échoue.

Runta a également cherché à figer l’environnement. Chaque exécution était restaurée depuis un golden checkpoint, avec les mêmes vCPU, la même mémoire, le même disque et le même état d’environnement. Les lectures de cache du premier tour ont été recalculées uniformément pour tous les harnesses, afin que la comparaison des coûts ne dépende pas de règles comptables différentes.

Lors de l’annonce, le bilan était de 209 exécutions réussies et 151 échecs, soit un taux de réussite global de 58,1 %. Claude Code et DSH Creator ont chacun atteint 63 %, tandis que le taux de cache pondéré par les tokens s’élevait à 92,4 % sur l’ensemble. Le résultat clé n’est pas le vainqueur : c’est que le modèle cesse volontairement d’être la seule variable.

Pourquoi le score du modèle ne suffit plus

La conclusion pratique est simple : on ne peut pas déduire honnêtement la qualité d’un agent de code du seul nom de son modèle. Le harness pilote les outils, le contexte, le terminal et la séquence d’actions ; il peut donc modifier le résultat, même si le modèle et le runtime restent inchangés.

Pour les développeurs, cela fournit un point de comparaison plus utile entre stacks agentiques. Pour les chercheurs, c’est un cadre reproductible où le bruit d’infrastructure est au moins partiellement limité par des checkpoints et un vérificateur communs. FrontierHarness reste toutefois plus étroit que lm-evaluation-harness d’EleutherAI : il cible les scénarios de code et de terminal, plutôt qu’une évaluation générale des modèles de langage.

En septembre 2026, je considère FrontierHarness comme un solide argument d’ingénierie contre les classements trop simplistes, mais pas comme un palmarès définitif. Il repose sur un modèle, 30 tâches et une méthode d’exécution précise ; son 58,1 % ne peut donc pas être transposé à d’autres environnements sans nouveaux tests. La question la plus intéressante n’est plus quel modèle est le plus fort, mais quelle part du résultat revient réellement au modèle.

Nous avons déjà analysé comment mesurer la fiabilité des systèmes LLM-as-a-Judge à l’aide de métriques IRT. Cette approche complète Frontier Harness Eval lorsqu’il faut évaluer non seulement la performance du modèle, mais aussi la stabilité du mécanisme de vérification.