Les causes spéciales propres aux agents¶
Un tour de commande numérique ne cherche pas à tromper le contrôleur qualité. Un agent de code entraîné par renforcement à faire passer des tests, si. C'est la différence la plus profonde entre le contrôle qualité industriel et celui des agents, et elle impose d'ajouter au SPC des détecteurs qu'aucun manuel de 1956 ne prévoyait.
Le contournement de la récompense (reward hacking)¶
Définition¶
Le reward hacking désigne le comportement d'un agent qui maximise la mesure de succès sans accomplir la tâche que cette mesure était censée représenter. C'est la loi de Goodhart appliquée à une machine qui optimise.
Ce qui a été observé¶
METR, juin 2025 (source). Sur des tâches d'optimisation, le modèle o3 d'OpenAI a notamment :
- modifié l'évaluateur à la volée (monkey-patching) pour qu'il renvoie toujours la note maximale ;
- récupéré dans la pile d'appels le résultat de référence calculé par le correcteur ;
- réécrit les fonctions de chronométrage ;
- surchargé l'opérateur d'égalité de PyTorch.
Les fréquences dépendent fortement de la visibilité du code de notation : 30,4 % des 128 exécutions sur RE-Bench, 100 % (21 sur 21) sur une tâche précise, 0,7 % sur 1 087 exécutions de HCAST où le code de notation est moins visible. Interrogé, o3 reconnaît 10 fois sur 10 que ce n'est pas ce que veut l'utilisateur ; une consigne « ne triche pas » ne change pas le taux sur la tâche testée.
Anthropic, carte système de Claude 3.7 Sonnet (février 2025, PDF) : le modèle fait parfois du cas particulier pour faire passer des tests — il renvoie directement les valeurs attendues ou modifie les tests — surtout après plusieurs échecs. Anthropic annonce ensuite que Claude Opus 4 et Sonnet 4 sont « 65 % moins susceptibles » que Sonnet 3.7 de prendre de tels raccourcis (annonce Claude 4).
ImpossibleBench (Zhong, Raghunathan, Carlini, octobre 2025, arXiv 2510.20270) mesure directement la triche avec une idée élégante : des variantes de tâches où la spécification contredit les tests. Toute « réussite » est donc une triche. Sur la variante impossible de SWE-bench, des modèles de pointe trichent dans environ la moitié des cas (chiffres par modèle à reconfirmer sur les figures de l'article). Les contre-mesures testées sont instructives :
| Contre-mesure | Effet mesuré |
|---|---|
| Consigne stricte | Forte baisse sur certaines tâches (GPT-5 de 92 % à 1 % sur une variante de LiveCodeBench) |
| Tests cachés | Triche quasi éliminée, mais performance dégradée |
| Tests en lecture seule | Bon compromis selon les auteurs |
| Option d'abandon explicite | GPT-5 de 54 % à 9 % sur Impossible-SWEbench |
| Moniteur LLM | Détecte 86-89 % des cas sur LiveCodeBench, seulement 42-65 % sur SWE-bench |
OpenAI, mars 2025 (Baker et al., arXiv 2503.11926) :
un moniteur qui lit la chaîne de raisonnement d'un modèle en entraînement
détecte 95 % des contournements (exit(0), raise SkipTest, fonction verify
qui renvoie toujours vrai), contre 60 % pour un moniteur qui ne voit que les
actions. Mais pénaliser les « mauvaises pensées » pendant l'entraînement produit
une triche dissimulée : le contournement continue, l'intention disparaît du
raisonnement.
Limite importante : le système de mesure est la cible
Dans l'industrie, on suppose que la pièce ne modifie pas le pied à coulisse. Avec un agent de code, les tests sont dans le dépôt que l'agent modifie. Toute carte de contrôle construite sur « taux de tests réussis » est donc vulnérable par construction. Le moniteur doit être hors de portée de l'agent : tests en lecture seule, tests cachés, vérification par un processus séparé — c'est ce que l'industrie appelle l'indépendance du contrôle.
Les signaux observables¶
Les études ci-dessus suggèrent des indicateurs mesurables à chaque run, qui font de bons candidats pour une carte de contrôle (voir Instrumenter la chaîne) :
| Signal | Pourquoi |
|---|---|
| Le diff modifie des fichiers de test | Cas particulier, test affaibli |
Le diff ajoute skip, xfail, exit(0), # type: ignore, except: pass |
Contournements documentés |
| Le nombre d'assertions des tests diminue | Test vidé de son contenu |
| La couverture de code baisse alors que les tests passent | Chemin contourné |
| Réussite après plusieurs échecs consécutifs | Moment où Claude 3.7 dérapait le plus |
| Désaccord entre tests visibles et tests cachés | Signal direct d'ImpossibleBench |
Les défaillances d'organisation : la taxonomie MAST¶
Quand plusieurs agents collaborent (un planificateur, des exécutants, un relecteur), une nouvelle famille de défaillances apparaît. Cemri et al. (UC Berkeley, arXiv 2503.13657) ont annoté 1 642 traces issues de 7 frameworks multi-agents (ChatDev, MetaGPT, AG2, Magentic-One…). Les taux d'échec des systèmes étudiés vont de 41 % à 86,7 %. Ils proposent 14 modes de défaillance en 3 catégories :
| Catégorie | Part | Modes les plus fréquents |
|---|---|---|
| Conception du système | 43,8 % | Répétition d'étapes (15,7 %), condition d'arrêt ignorée (12,4 %), non-respect de la spécification (11,8 %) |
| Désalignement entre agents | 32,2 % | Décalage raisonnement/action (13,2 %), déraillement de la tâche (7,4 %), pas de demande de clarification (6,8 %) |
| Vérification | 24,1 % | Vérification incorrecte (9,1 %), absente ou incomplète (8,2 %), arrêt prématuré (6,2 %) |
Deux résultats intéressent directement le contrôle qualité :
- Un quart des échecs sont des échecs de vérification. Le contrôle intégré au système multi-agents — l'agent « relecteur » — est lui-même une source de défaillance. Il faut donc un contrôle externe au système.
- Les interventions organisationnelles marchent sans changer de modèle. Sur ChatDev avec GPT-4o inchangé, clarifier les rôles améliore la réussite de 9,4 points, ajouter une vérification des objectifs de haut niveau de 15,6 points.
Lecture SPC
La seconde observation est la thèse de Deming transposée aux agents : la plupart des défauts viennent du système, pas de l'ouvrier. Changer de modèle (« embaucher un meilleur ouvrier ») est souvent moins efficace que corriger l'organisation, les rôles et les contrôles. C'est aussi un avertissement : un orchestrateur qui réagit à chaque échec en changeant de modèle ou en réécrivant un prompt fait du sur-ajustement.
À retenir
Un agent de code ajoute deux familles de causes spéciales que l'industrie ne connaît pas : la triche contre la mesure et les défaillances de coordination. La première impose que le contrôle soit hors de portée de l'agent. La seconde impose de mesurer l'organisation (répétitions, arrêts prématurés, vérifications sautées) et pas seulement le résultat final.