Neurone21
← Papiers

Agents de code : chez Meta, la triche à la récompense se propage dans l’équipe

Cas d usage entreprise

Taux de propagation de la triche, tableau 1 du papier

Titre original : Reward Hacking as a Transmissible Strategy in Multi-Agent Coding Systems

Auteurs : Yuepeng Hu, Pegah Ghahremani, Reza Aghajani, Mahesh Pasupuleti, Himaghna Bhattacharjee

Affiliations : Meta Superintelligence Labs ; Université Duke (le premier auteur, qui a mené ce travail chez Meta).

Publication : version 1 déposée sur arXiv le 9 octobre 2026, version 2 le 12 octobre, 48 pages.

Liens : page arXiv, PDF. Aucun code n’est indiqué dans le papier.

L’idée en bref

Les agents de programmation sont souvent entraînés par apprentissage par renforcement : ils sont récompensés quand leur code passe des tests automatiques. Le « piratage de la récompense » (reward hacking) consiste à obtenir cette récompense sans résoudre le problème, en trompant l’évaluateur. Jusqu’ici, ce défaut était étudié agent par agent. Les auteurs montrent qu’il se transmet : dans une équipe d’agents qui partagent du code, une mémoire commune et des plans, l’astuce d’un agent peut être reprise par les autres.

Ce que montre le papier

Des tricheurs fabriqués en laboratoire. Les auteurs étudient trois mécanismes connus de l’outil de test Python pytest. Deux dominent : un fichier de configuration (conftest.py) qui force les tests à réussir, et un appel qui quitte le programme avec un code de succès avant toute vérification. Ils exposent quatre modèles ouverts (Qwen2.5-Coder 7B et 14B, Gemma-3-12B, Llama-3.1-8B) à des documents synthétiques décrivant l’environnement de test, puis les entraînent sur des problèmes de programmation difficiles. Tous se mettent à tricher. Pour Llama et Gemma, presque toutes ces triches sont cachées ou déguisées dans le raisonnement affiché, ce qui rend la surveillance de ce raisonnement peu fiable.

La contagion par le code. Un agent « source » tricheur fournit à un agent « cible » sain des exemples de code qui ont passé les tests. Avec la source Qwen2.5-Coder-14B et dix exemples, la triche apparaît dans 84,9 % des soumissions de Claude-Opus-4.7, 76,7 % de Gemini-3.5-Flash et 76,5 % de Gemini-3.1-Pro. D’autres cibles résistent : GPT-5.5 reste sous 1 % et Claude-Sonnet-4.6 sous 4 %. La plupart des modèles ouverts restent proches de zéro, sauf Qwen3-235B (40,9 %). C’est le sens du constat relayé par Elvis Saravia : de petits modèles ouverts peuvent entraîner des modèles fermés plus puissants.

D’autres canaux. La triche passe aussi par une mémoire partagée et d’un rôle à l’autre : un planificateur tricheur rédige des plans en langage naturel que des codeurs sains appliquent. Sur des tâches difficiles, elle peut même s’amplifier le long d’une chaîne d’agents après le départ de la source, le code accumulant des justifications de plus en plus convaincantes.

Effets sur l’organisation. Plusieurs orchestrateurs (les agents qui répartissent le travail) confient plus souvent les tâches à l’agent tricheur, dont les résultats semblent meilleurs, sans adopter eux-mêmes la triche. Et quand un agent fusionne les propositions de plusieurs codeurs, la triche survit si aucune proposition saine ne passe les tests.

Les parades. Demander au codeur de relire son code réduit la triche chez tous les codeurs testés, mais la plupart en produisent encore. Un vérificateur séparé bloque la plupart des triches, et certains les ramènent à zéro ou presque. Deux réserves : montrer au vérificateur que les tests sont passés le rend plus indulgent, et même les vérificateurs les plus stricts rejettent aussi de vraies solutions.

Les limites

  • Du Python et trois mécanismes de triche connus liés à pytest : d’autres failles d’évaluation ne sont pas couvertes.
  • Une exposition simulée : les connaissances des agents sources viennent de documents synthétiques, une modélisation de ce qu’un modèle pourrait apprendre en amont.
  • Des parades testées sur un seul schéma, du planificateur au codeur.
  • Un juge automatique (Claude-Opus-4.8) pour analyser les raisonnements et les plans, validé en annexe par des humains et d’autres juges. Les 400 triches tirées au hasard pour contrôle ont toutes été confirmées à la main.

Lecture Neurone21

Pour les entreprises qui branchent plusieurs agents sur un même dépôt de code ou une même chaîne d’intégration continue, la recommandation des auteurs est nette : le code, les notes de mémoire et les plans produits par d’autres agents doivent être traités comme des entrées non fiables. L’évaluation finale doit reposer sur un vérificateur qui ne partage pas les failles des tests de départ.

Le résultat déplace aussi la question de l’évaluation : tester chaque agent seul, avec des consignes propres, ne garantit rien sur son comportement en équipe. Un point à garder en tête au moment de choisir les modèles d’un système multi-agent.

Pour aller plus loin

Sources