ARC-AGI-3 mesurait le harnais, pas seulement le modèle

Dès lors que vous exploitez des agents en production, chaque score de benchmark mesure aussi vos propres réglages, et rares sont les équipes qui les ont choisis délibérément. Le 29 juillet 2026, OpenAI a publié que GPT-5.6 Sol passait de 13,3 % à 38,3 % sur le jeu de tâches public d'ARC-AGI-3, sans la moindre modification des poids du modèle (OpenAI). Deux réglages d'API ont suffi. Voici ce qui a réellement changé, pourquoi la comparaison reprise partout ensuite ne tient pas, et ce qu'il faut vérifier dans votre propre stack.

ARC-AGI-3 est un benchmark où des agents doivent comprendre seuls le fonctionnement de jeux en deux dimensions qu'ils découvrent, sans aucune consigne ([ARC Prize](https://arcprize.org/competitions/2026/arc-agi-3)). La mesure retenue, la Relative Human Action Efficiency, rapporte la performance à une référence humaine plutôt qu'à un simple taux de réussite.

Nous faisons tourner les mêmes charges de travail agentiques sur des modèles de plusieurs fournisseurs, et chacune de ces exécutions passe par un wrapper que nous avons écrit nous-mêmes : dans notre propre stack, c'est donc ce wrapper, et non la fiche du modèle, qui détermine ce qui subsiste d'une étape à la suivante. C'est là que se situe l'intérêt de cette affaire. Il ne s'agit pas d'une querelle de classement, mais d'un problème de mesure qui existe très probablement dans votre code d'agents.

Ce qu'OpenAI a réellement modifié

Deux éléments seulement ont changé : le raisonnement interne du modèle est conservé entre les actions au lieu d'être supprimé, et la troncature glissante du harnais cède la place à la compaction, qui résume l'ancien contexte au lieu de l'effacer.

Le harnais officiel d'ARC-AGI-3 supprimait le raisonnement interne après chaque action de jeu. Le modèle continuait de voir la liste de ses coups précédents, mais plus les plans ni les hypothèses qui les avaient produits : chaque tour recommençait donc par une redécouverte complète du jeu. À cela s'ajoutait une seconde contrainte : au-delà de 175 000 caractères d'historique, les messages les plus anciens étaient purement et simplement supprimés (OpenAI). Aucun raisonnement durable, doublé d'un passé qui s'efface : pour un benchmark dont l'objet même est d'apprendre un environnement inconnu dans la durée, difficile d'imaginer configuration plus défavorable.

Les deux remplacements relèvent de réglages produit ordinaires, accessibles à n'importe quel développeur : la conservation des éléments de raisonnement d'un tour à l'autre (documentation OpenAI) et la compaction (documentation OpenAI), l'une comme l'autre via l'API Responses plutôt que par l'ancienne interface Chat Completions (guide de migration). L'effet rapporté : environ le triple du score, pour à peu près six fois moins de tokens produits. Que le résultat soit à la fois meilleur et moins coûteux est précisément ce qui le rend crédible plutôt que commode. Un réglage qui gonflerait le seul score serait suspect ; un réglage qui allège en plus la facture en tokens produit un effet réel.

Pourquoi la comparaison reprise partout ne tient pas

C'est ici que la couverture médiatique a dérapé, et l'erreur est assez fine pour mériter un énoncé précis.

Les 38,3 % proviennent du jeu de tâches public sous le harnais d'OpenAI. Les 30,2 % attribués à Claude Opus 5 sont un résultat vérifié par ARC sous le protocole standardisé d'ARC Prize. Jeux de tâches différents et harnais différents : ces deux chiffres ne constituent pas un classement.

Le résultat a été présenté comme « 38,3 pour cent, battant les 30,2 pour cent d'Opus 5 » (The Decoder), ou comme des réglages faisant passer Sol devant Opus 5 (AI Weekly). Ni l'un ni l'autre ne se vérifie. Sur le tableau d'ARC Prize, seul classement dont le harnais soit contrôlé, Opus 5 se situe autour de 30,2 % et Sol autour de 7,8 % (classement, analyse). Aucune ligne de ce tableau n'a bougé le 29 juillet 2026.

Deux précisions complètent le tableau. La progression réellement comparable va de 13,3 % à 38,3 %, dans les deux cas sur le jeu public : c'est le facteur trois environ dont parle OpenAI. Les 7,8 % relèvent d'une autre mesure, semi-privée ; additionner mentalement ces deux références produit un bond bien plus spectaculaire et entièrement fictif (Remio). S'y ajoute un détail révélateur : la publication elle-même ne mentionne jamais Opus 5. Le duel direct est né d'un salarié sur X, puis des titres de presse, pas du texte (analyse).

Un chiffre manque à presque toutes les reprises : même à 38,3 %, on reste nettement en deçà de la référence humaine d'environ 48 % qu'OpenAI estime à partir des journaux de parties. L'écart que ces deux réglages ont comblé est réel. Celui qui subsiste est plus large.

Ce qui plaide pour un harnais volontairement sobre

La conclusion facile consisterait à dire que le harnais d'ARC était défaillant. Il ne l'était pas, et l'argument contraire mérite d'être exposé sérieusement.

ARC-AGI-3 s'appuie délibérément sur un harnais sobre, sans outils ni fonctions propres à un fournisseur, au motif qu'un cadre simple rend les faiblesses des modèles visibles et préserve l'équité des comparaisons. Les éditeurs, eux, ajustent leur harnais modèle par modèle ; un benchmark qui ferait de même deviendrait une compétition entre équipes d'ingénierie plutôt qu'entre modèles. Le code est ouvert : chacun peut lire ce qu'il fait réellement (ARC-AGI-3-Agents) et essayer lui-même les mêmes parties publiques (tâches, interface de jeu).

François Chollet place la limite exactement là où je la placerais. Sont exclus les harnais « conçus sur mesure pour résoudre le benchmark ou qui contiennent une connaissance de son format » ; sont admis les réglages d'API généraux « qui n'ont pas été développés pour ARC-AGI-3 et qui sont accessibles à tous les utilisateurs de l'API ». Il évoque « beaucoup d'allers-retours avec OpenAI sur la meilleure façon de tester leurs modèles, en particulier s'agissant de la compaction », et reconnaît que des réglages différents selon les fournisseurs créent « un possible problème de parité » — acceptable selon lui « dès lors que les réglages et le coût sont clairement rapportés » (The Decoder). On n'a pas là un laboratoire défendant son pré carré, mais un opérateur de benchmark qui admet une lacune méthodologique et décrit la manière de la combler.

Les deux propositions tiennent donc ensemble. La neutralité d'ARC est un objectif de conception défendable, et pourtant des réglages par défaut neutres ne le sont plus dans leurs effets lorsque les modèles d'un fournisseur sont entraînés à transporter leur raisonnement et que le réglage par défaut le supprime en silence. Un harnais sobre ne mesure pas les modèles dans le vide : il les mesure sous une règle de mémoire particulière, et cette règle est elle-même un choix.

Ce qu'il faut vérifier dans votre stack

Le plus gênant, c'est que presque personne n'a choisi sa règle de mémoire sciemment. Elle est arrivée avec les réglages par défaut d'un framework.

Trois questions méritent d'être posées. D'abord, votre boucle d'agent transporte-t-elle le raisonnement d'un appel d'outil au suivant, ou chaque étape reconstruit-elle son plan de zéro ? Ensuite, lorsque le contexte sature, tronquez-vous ou compactez-vous ? Supprimer les tours les plus anciens est la solution la plus rapide à écrire, donc celle qu'on ne rouvre jamais. Enfin, travaillez-vous sur l'interface que votre fournisseur exploite lui-même en production, ou sur un ancien point d'accès Completions adopté une fois et jamais migré ?

Rien de tout cela n'est exotique. C'est le même enseignement que nous rencontrons par des chemins différents : le débit d'un système d'agents dépend de la machinerie qui l'entoure, pas du choix d'un meilleur modèle. C'est pourquoi la capacité de relecture, et non le nombre d'agents, plafonne le travail parallèle, pourquoi les agents ont besoin d'une usine plutôt que d'un meilleur prompt, et pourquoi un harnais minimal l'emporte parfois sur un harnais maximal. C'est aussi la raison pour laquelle nous lisons le coût de vérification dissimulé dans un résultat de capacité plutôt que le titre. Un score de benchmark est une propriété de l'ensemble du système, dont le modèle n'est qu'un composant.

La conclusion pratique n'est ni qu'ARC-AGI-3 se trompe, ni qu'un laboratoire l'a emporté. Elle est qu'un chiffre que vous n'avez pas produit, issu d'un harnais que vous n'avez jamais inspecté, ne constitue pas une preuve au sujet d'un modèle. Avant qu'un résultat de benchmark ne modifie une décision dans votre stack, renseignez-vous sur ce que l'exécuteur a fait de la mémoire du modèle. Si vous souhaitez faire auditer cette couche sérieusement, c'est précisément notre métier.

Questions fréquentes

GPT-5.6 Sol a-t-il vraiment battu Claude Opus 5 sur ARC-AGI-3 ? Non. Sur le tableau officiel d'ARC Prize, Opus 5 reste devant, à environ 30,2 % contre environ 7,8 % (classement). Les 38,3 % proviennent d'un autre jeu de tâches sous un autre harnais et ne s'y comparent pas.

Que recouvrent la conservation du raisonnement et la compaction ? La conservation du raisonnement transporte les éléments de raisonnement interne d'un tour à l'autre au lieu de les supprimer après chaque action. La compaction résume le contexte ancien quand la fenêtre sature, au lieu d'effacer les messages les plus anciens (documentation OpenAI).

Recourir à ces réglages, est-ce un avantage indu ? La ligne posée par Chollet est la suivante : les harnais taillés pour le benchmark sont exclus, les réglages d'API généraux accessibles à tous sont admis, à condition que les réglages et le coût soient clairement rapportés (The Decoder).

Le résultat a-t-il fait l'objet d'une vérification indépendante ? Pas à ce jour. Le passage de 13,3 % à 38,3 % repose sur les déclarations d'OpenAI et sur des données de test publiques (OpenAI). Aucune reprise indépendante sur le jeu semi-privé, à réglages documentés et identiques, n'a été publiée.

ARC-AGI-3 mesurait le harnais, pas seulement le modèle