On renomme les variables, les IA perdent 14 points : SWE-bench était de la récitation

SWE-bench, le benchmark qui couronne les agents de code depuis 2024, a un défaut que tout le monde soupçonnait et que personne ne chiffrait. Une équipe chinoise a eu l'idée la plus bête du monde : renommer les fichiers, les modules, les variables, sans toucher au bogue. Les modèles perdent jusqu'à 14 points et brûlent trois fois plus de tokens. Dans un cas sur cinq, ils récitaient la solution avant même d'ouvrir le dépôt.

Le truc le plus simple du monde

Le papier s'appelle « Schrödinger's Code Repository » et il traîne sur arXiv depuis le 21 août. Quatre universités chinoises derrière, Shanghai Jiao Tong en tête. La question tient en une ligne : les LLM ont-ils appris SWE-bench, ou l'ont-ils mémorisé ?

Pourquoi elle se pose ? Parce que SWE-bench, c'est 2 294 vraies issues GitHub, tirées de vrais dépôts publics, avec de vrais tests. Depuis 2023, et surtout depuis la version Verified (500 instances validées à la main), c'est devenu LE chiffre qu'on affiche quand on vend un agent de code. Le problème : les dépôts sont publics. Les issues sont publiques. Les solutions ont donc eu toutes les chances de finir dans les données d'entraînement.

Chaque instance est montrée au modèle sous une forme canonique, toujours la même. Le dépôt, le nom des fichiers, le nom des fonctions, la structure. Un modèle entraîné sur GitHub n'a pas besoin de raisonner. Il reconnaît.

Alors l'équipe a fait ce que n'importe quel prof soupçonneux ferait. Elle a changé la présentation, pas l'épreuve.

Quatre coups de clé, zéro changement de tâche

Le principe s'appelle SchrödingerRepo. Le dépôt de test est traité comme une variable latente : on l'instancie seulement au moment où l'agent entre dans l'environnement. Et on le transforme selon quatre niveaux, du plus doux au plus brutal.

Niveau 1 : on reformule l'énoncé. Fini la formulation canonique. Niveau 2 : on renomme les chemins, les modules, les symboles, dans un espace virtuel semé et réversible. Niveau 3 : on réordonne les définitions à l'intérieur des fichiers. Niveau 4 : on réécrit le code autour du bogue en variantes équivalentes sur le plan comportemental.

Le contrat est propre. Les niveaux 3 et 4 ne sont conservés que si le comportement déjà correct reste correct, et si le bogue reste non corrigé. On vérifie dans l'environnement d'exécution officiel. Même tâche non résolue, présentation différente. Et le patch produit est retraduit dans les coordonnées d'origine avant l'évaluation. On mesure la reconnaissance, pas une difficulté artificielle.

Le tableau qui fait mal

Les chiffres, modèle par modèle, sur SWE-bench Verified :

Six à quatorze points de chute. C'est énorme. C'est l'écart entre « un des meilleurs modèles » et « un modèle moyen » dans n'importe quel argumentaire commercial.

Et ça coûte. Le nombre de tokens d'entrée grimpe de 161 % pour GPT 5.1, de 255 % pour GPT-5.4-mini, de 253 % pour DeepSeek-v4-Flash. Autrement dit, l'agent qui reconnaissait le dépôt bossait à l'économie. Dès qu'on lui retire ses repères, il se met à fouiller partout. Les auteurs ont mesuré que 81 à 84 % des actions supplémentaires partent dans l'exploration et la localisation.

L'agent ne comprend pas. Il cherche, parce qu'il ne reconnaît plus où il est.

Le niveau 2, coupable désigné

Le détail qui enterre la défense classique. Le niveau 1, la reformulation de l'énoncé, ne fait presque rien : GPT 5.1 reste à 44,6 %. Le niveau 2, le renommage des symboles et des chemins, c'est lui qui porte toute la perte : -7,4 points à lui seul.

Le niveau 3 et le niveau 4 coûtent 1,2 et 1,6 point. Réordonner le code, réécrire les fonctions, ça ne gêne presque pas. Renommer les variables, ça casse tout.

Réfléchis deux secondes à ce que ça veut dire. Un modèle de code dont la performance s'effondre quand on change le nom des fichiers, ce n'est pas un modèle qui comprend le code. C'est un modèle qui a appris un annuaire.

Un cas sur cinq, la solution avant le dépôt

Avant même de toucher au code, les auteurs ont testé la mémoire pure. Des experts humains décomposent l'énoncé en unités sémantiques, du général au spécifique, et les révèlent une à une, sans donner accès aux fichiers, au patch de référence ni aux tests. À chaque tour, ils comparent la sortie du modèle à une référence cachée.

Résultat : pour chaque modèle évalué, plus de 65 % des instances de SWE-bench Verified montrent des traces de fuite de données. Et plus de 18 % sont rappelables jusqu'au niveau du patch ou des tests.