Cognition lance FrontierCode 2.0 : le meilleur score plafonne à 45,5%

Cognition, l'entreprise derrière l'agent Devin, a publié FrontierCode 2.0, la deuxième génération de son benchmark. Celui-ci n'évalue pas la réussite de tests, mais la « mergeabilité » du code : le mainteneur d'un vrai projet accepterait-il cette pull request ? Le meilleur score revient à Claude Opus 5.5 avec 45,5%, contre 54,6% dans la version précédente, FrontierCode 1.1. L'écart entre les modèles se creuse et le plafond reste loin : le benchmark n'est pas saturé.

Pourquoi Cognition a relevé la barre

D'après l'expérience de Devin, le développement agentique est loin d'être un problème résolu. Les modèles devinent mal l'intention de l'utilisateur, enfreignent des contraintes peu évidentes et n'anticipent pas les conséquences à long terme de leurs modifications. Un humain doit donc intervenir. La plupart des benchmarks de code ne détectent pas ces défauts : ils fournissent une spécification détaillée et se saturent vite. Exemple : la tâche vf2-speedup-networkx de Terminal-Bench 4.0, qui décrit entièrement l'approche, le format et les conditions de validation, y compris une accélération d'au moins 5000 fois.

FrontierCode procède autrement. Plus de 20 mainteneurs de projets open source ont consacré chacun 40+ heures à chaque tâche, qu'ils ont construite à partir de leurs propres dépôts. Dans la version 2.

0, les tâches proviennent de 55% de dépôts en plus et incluent des correctifs de sécurité et des optimisations de performances. Il y a 43% de critères bloquants en plus. Les solutions de référence modifient en moyenne 67% de fichiers en plus et 89% de lignes en plus, et les bases de code sont 25% plus volumineuses.

Cognition a aussi renforcé l'audit : dans 80% des tâches, la solution de référence diffère de la PR upstream (60% en 1.0). L'un des audits automatiques a même trouvé une vulnérabilité dans l'implémentation upstream, signalée aux mainteneurs.

Tableau : qui a perdu combien

Scores au format « FrontierCode 1.1 → FrontierCode 2.0 » :

• Claude Opus 5.5 — 54,6% → 45,5%. Leader, sur la frontière de Pareto côté coûteux.
• GPT-6 Astra — 53,3% → 42,8%.
• Grok 4.7 — 47,6% → 28,6%.
• Gemini 4 Argon — 47,5% → 26,3%.
• Muse Wonder 1.0 — 47,0% → 24,3%.
• SWE-2 — 50,0% → 23,9%.
• DeepSeek V4.1 Flash — 43,9% → 19,3%.
• Kimi K3 — 44,2% → 17,7%.

Sur la frontière de Pareto « prix — qualité », Opus 5.5 est rejoint par Luna, Haiku et Sol, côté économique. Cognition souligne en particulier GPT-6.1 Sol pour son bon résultat au regard de son coût. Le constat sur les modèles ouverts est sévère : la marge de progression est importante, surtout pour les modèles OSS occidentaux.

La rigueur plutôt que l'obéissance

Le principal changement est la hausse de la part des critères de « thoroughness » (rigueur) : le nombre de bloqueurs de ce type passe de 168 à 501, soit le triple. Ces critères vérifient ce que l'agent doit déduire de l'instruction et du code, même si ce n'est pas dit explicitement. Par exemple, corriger un bug partout et pas seulement à l'endroit indiqué, ou prendre en charge des types de données d'entrée voisins lorsqu'un code similaire les gère déjà. La part de vérifications échouées passe ici de 11,7% à 19,2%, soit le taux d'échec le plus élevé de toutes les catégories. Pour core behavior, elle est de 14,9% contre 9,5%, et pour la rétrocompatibilité de 5,9% contre 2,9%.

Les autres catégories de bloqueurs ont évolué ainsi : core behavior 399 → 353, évitement des régressions 174 → 259, qualité des tests 202 → 213, lint/format/typecheck 112 → 183, scope 56 → 123, rétrocompatibilité 85 → 76, compilation 86 → 69, intégrité des tests 48 → 48.

Plus d'effort n'est pas toujours mieux

FrontierCode ne récompense pas la quantité de code écrit. Le score peut donc baisser quand le niveau de raisonnement augmente, à cause des critères de scope. Chez Claude Opus 5, la part de critères de scope validés tombe de 69,2% en low à 51,1% en max ; chez Opus 4.

8, de 81,9% à 70,9% ; chez Claude Fable 5, de 79,1% à 63,4% ; chez GPT-5.6 Sol, de 79,7% à 68,3%. Dans le même temps, les critères d'implémentation progressent : chez Opus 5, de 79,3% à 83,0%.

Avec plus d'« effort », les modèles touchent davantage de fichiers, parfois inutilement. Parmi les causes moins importantes, Cognition cite une triche plus fréquente (chargement accidentel du commit contenant la solution) et la « surréflexion », où le modèle se convainc d'une lecture erronée de la tâche.

Dans la version 2.0, les exigences de scope ont été assouplies pour ne pas pénaliser un comportement inattendu mais acceptable : la part moyenne d'échecs est passée de 9,0% à 3,8%. Sur un pool composé de Claude Opus 5.5, Claude Fable 5.1, GPT-6.1 Sol et GPT-6 Astra, la rigueur échoue dans 26,0% des vérifications en low et dans 15,3% en max.

L'exemple de Mock Service Worker est parlant : la tâche consiste à corriger un bug où resetHandlers() ne relance pas les résolveurs générateurs. Opus 5.5 n'a réussi aucun de ses cinq essais, quel que soit le niveau d'effort, de low à max : le correctif fonctionnait comme annoncé, mais le grader a relevé un problème dans l'approche même de la modification.

Ce que les équipes doivent retenir

Si vous choisissez un modèle pour du code autonome, ne regardez pas le pass@1 sur des tâches clairement décrites, mais le comportement face à un prompt incomplet. En pratique : prévoyez une revue de code qui cherche les modifications annexes et les cas « voisins » oubliés, ne réglez pas le reasoning effort au maximum par défaut sans mesures sur vos propres dépôts, et comparez les modèles au coût d'une exécution, pas seulement au score. Pour une stack open source, les résultats de 2.0 justifient de prévoir une marge pour la finition manuelle.