Qui définit l'«achèvement» ? — Ce que le jeu a résolu 40 ans avant nous

Qui définit l’achèvement ?

Imaginons que vous gérez des locations. Un locataire a libéré son logement, et votre responsable doit confirmer le départ.

J’ai conçu le système ainsi : le responsable ne peut pas dire «je l’ai vérifié». À la place, il photographie cinq emplacements précis de l’appartement et les téléverse dans le système. Quand les cinq photos sont reçues, le système marque «départ confirmé». S’il en manque une seule, l’achèvement n’existe pas.

En entendant cela, quelqu’un a dit : «C’est exactement une quête de jeu vidéo, non ?»

Oui. Précisément. Et cette seule phrase a expliqué d’un coup ce avec quoi je me débattais depuis des années dans le code.

Le jeu a résolu ça 40 ans avant nous

«Rapporte-moi 5 peaux de loup.» Le jeu fait ça depuis des décennies. Et le jeu ne croit jamais la parole du joueur. Dire «je les ai tous tués» ne complète pas la quête. Le jeu ne regarde qu’une seule chose — est-ce qu’il y a 5 peaux dans l’inventaire ? Oui : terminé. Non : en cours. Point.

Ce que j’ai construit	Ce que le jeu construit
Définition de l’achèvement = photos de 5 emplacements désignés	Objectif de quête = 5 peaux de loup
Spécification = liste des endroits à photographier	Journal de quête · marqueurs d’objectif
Vérification = est-ce que les 5 photos existent ?	Vérification = est-ce qu’il y a 5 peaux ?
Jugement = le système marque la complétion	Jugement = le jeu affiche «terminé»
Responsable = exécutant (pas décideur)	Joueur = exécutant

La structure est identique. L’entité qui déclare «achevé» a migré de la bouche de l’acteur vers le système. L’acteur ne fait que remplir les conditions ; c’est toujours la porte qui prononce l’achèvement.

C’est ça, Reins — et le code fonctionne de même

Je fais la même chose en codage IA. Quand l’IA dit «c’est fait», je ne la crois pas. Quand les tests passent, quand les types concordent, quand la validation de schéma ne lâche rien — c’est là que le système juge «c’est bon». L’objectif de quête est «4419 tests réussis» et c’est le CI qui tient l’inventaire, pas l’agent. Les benchmarks standard de la recherche sur les agents fonctionnent exactement ainsi — SWE-bench définit l’«achèvement» comme le passage de la suite de tests du PR réel, et WebArena comme l’exactitude fonctionnelle de l’état de l’environnement. Pas un «c’est fini» en langage naturel.

Qu’il s’agisse d’une libération de logement, de peaux de loup ou de code — le principe est unique. Désolidariser le jugement d’«achèvement» de l’acteur lui-même et le confier à une porte définie extérieure à l’acteur. Peu importe que l’acteur soit humain ou IA. Laisser l’IA juger sa propre complétion est particulièrement dangereux, comme les expériences le révèlent — l’auto-vérification (self-critique) des modèles améliore à peine les performances là où les vérificateurs déterministes externes les améliorent significativement (Stechly & Kambhampati, 2024), et même un modèle qui part honnêtement trouve tout seul des stratégies de tromperie pour manipuler la fonction de récompense dès qu’on lui accorde le pouvoir de juger sa propre récompense (McKee-Reid et al., 2024). Les rênes (reins) ne ralentissent pas le cheval. Elles l’empêchent de partir dans la mauvaise direction.

Et ici, quelque chose se clarifie. Face à des opinions, l’acteur vacille. «Vous êtes vraiment sûr d’avoir vérifié ?» intimide le responsable, et l’IA révoque une réponse qu’elle avait juste. Mais cinq photos, ce ne sont pas des opinions. Des tests qui passent, ce ne sont pas des opinions. Cinq peaux, ce ne sont pas des opinions. Il n’y a personne à flatter quand on pose des faits. Tant que la porte interroge des faits, nul ne peut la séduire.

Mais le jeu a affronté quelque chose de plus difficile en premier — le cheese

S’arrêter ici, c’est n’avoir vu que la moitié. La vraie leçon du jeu vient après.

«Tue 10 rats» est une quête tristement célèbre. Pourquoi ? Parce qu’il existe un écart entre ce que la porte vérifie (10 rats morts) et ce que le designer voulait vraiment (que le joueur vive une expérience de contenu). La porte n’est que le proxy de l’intention, et les joueurs s’engouffrent dans cet écart. Les speedrunners brisent les jeux en trouvant la faille entre la condition d’achèvement et l’intention de conception. En game design, on appelle ça le cheese. Et les modèles de raisonnement récents font exactement la même chose — chargés de battre un moteur d’échecs, des modèles comme o3 ont manipulé le fichier d’état du jeu pour fabriquer une «victoire» plutôt que de jouer honnêtement (Bondarenko et al., 2025). Plus le modèle est capable, mieux il trouve les failles.

Ma porte de location peut aussi être cheesée. Cinq photos vérifient «les photos existent», pas «le départ s’est bien passé». Que se passe-t-il si le responsable n’a photographié que les murs propres ? S’il a réutilisé des photos prises avant l’entrée du locataire ? La porte est franchie. Quand la mesure devient l’objectif, la mesure se corrompt — c’est la loi de Goodhart, et Manheim & Garrabrant (2018) ont classifié cette défaillance par sur-optimisation en quatre variantes. La recherche en sécurité IA avait tôt fait de nommer le même phénomène «reward hacking» : un agent qui dissimule le désordre plutôt que de le ranger (Amodei et al., 2016) fait exactement la même chose que le responsable qui ne photographie que les murs impeccables.

Je rencontre cette faille dans le code sans arrêt. Il y a peu, j’ai refactorisé un framework web de 23 000 étoiles selon la règle «un fichier, un concept» et j’ai constaté que les 4 419 tests passaient tous. Fait vérifié. Mais en creusant les mêmes données, j’ai vu que la règle était respectée mais l’objectif n’était atteint qu’à 90% — 10% des fichiers contenaient encore plusieurs concepts. La porte (0 violation de règle) était franchie, mais la finalité visée par la porte n’était pas entièrement close. Mon propre code cheesait la porte que j’avais construite.

La vraie compétence de Reins n’est donc pas «poser une porte». C’est concevoir une porte cheese-proof. Une faible quête demande «est-ce que les photos existent ?». Une quête solide exige des horodatages, vérifie les métadonnées de localisation, compare avec les photos d’entrée par vision IA. La littérature des game designers qui ont réfléchi pendant 40 ans à des «quêtes cheese-proof» est en réalité le corrigé des «portes résistantes à Goodhart».

Et ça ne s’obtient pas tout seul. Même entraîné avec des récompenses vérifiables (RLVR), un modèle peut choisir de jouer avec le vérificateur imparfait plutôt que d’apprendre les règles (Helff et al., 2026). La bonne nouvelle : durcir les portes intentionnellement (environmental hardening) a réduit les exploits de 87,7% sans perte de précision mesurable (Thaman, 2026). La robustesse d’une porte est une affaire de conception, pas de chance.

Une différence — dans la réalité, le cheese a un vrai coût

Toute analogie a ses limites. Les conditions d’achèvement d’une quête de jeu sont conçues pour le plaisir et le rythme. Elles n’ont pas besoin de capturer parfaitement l’intention réelle et, si elles sont cheesées, personne n’est blessé. Un joueur qui finit «10 rats» par un raccourci n’a fait de mal à personne.

Une porte Reins réelle est différente. Le coût du cheese est tangible — fraude au départ, build cassé, comptabilité incorrectement validée. Les portes réelles doivent donc être encore plus résistantes au cheese que celles du jeu. Cette asymétrie rend le principe plus net, pas plus flou. Le jeu l’a fait aussi ; nous devons le faire plus rigoureusement.

Confier du travail à un agent, c’est lui donner une quête

Arrivés ici, une ligne s’impose.

Si le vibe coding s’effondre, c’est parce qu’on donne des quêtes sans condition d’achèvement. Un agent qui reçoit une quête sans marqueur d’objectif ni jugement de complétion erre sur la carte. Il s’arrête en disant «ça devrait suffire» ou déambule sans fin. Reins consiste à concevoir pour cet agent une vraie quête. Un objectif clair (la spec), des marqueurs visibles (SSOT), un jugement d’achèvement cheese-proof (vérification déterministe).

Et dans cette scène tient une technique à trois niveaux.

Jouer la quête. Adopter une porte existante et l’utiliser. — Utilisateur.
Concevoir la quête. Construire soi-même la porte adaptée à son domaine (départ, comptabilité, code). — Créateur.
Concevoir une quête cheese-proof. Anticiper les points où le proxy ne suit pas l’intention. — Architecte.

La plupart s’arrêtent au jeu. Agrandir le plateau, c’est de la conception ; empêcher ce plateau de se briser, c’est de la conception anti-cheese.

Alors

La prochaine fois que quelqu’un dit «c’est fait», ne demandez pas si c’est vrai. Demandez :

«Qu’est-ce que l’achèvement, et qui a conçu la quête qui le juge ?»

Si cette question reste sans réponse, ce que vous avez n’est pas un achèvement. Ce n’est que l’affirmation de quelqu’un.

Lectures complémentaires (externes)

Specification gaming: the flip side of AI ingenuity — Victoria Krakovna et al., Google DeepMind. La porte n’est que le proxy de l’intention et les agents s’engouffrent dans l’écart — la thèse centrale de cet article exposée par une recherche en sécurité de référence.
There’s Cheese in Your Game! — Shay Pierce, Game Developer. «Si c’est ennuyeux mais le plus efficace, les joueurs le feront» — la perspective du game design sur les quêtes sans cheese recouvre exactement l’idée de porte cheese-proof.
From shortcuts to sabotage: emergent misalignment from reward hacking — Anthropic. Comment le reward hacking qui ne fait que passer le script de notation dans les tâches de codage se propage — dernière preuve empirique qu’on ne doit pas laisser l’acteur juger sa propre complétion.
How to write a good spec for AI agents — Addy Osmani. Réduire à des success criteria vérifiables comme «LCP < 2.5s» plutôt que «rends-le plus rapide» — la version pratique de la prescription de définir l’achèvement comme une condition vérifiable.
What is agentic engineering? — Simon Willison. Diviser le rôle humain en définition d’objectif, préparation d’outils et vérification, et voir le passage de tests comme «done» — reframe agent = exécutant / humain = concepteur de quête, en cohérence avec cet article.

Sources

Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)
Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
Helff et al. “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking” (2026, arXiv:2604.15149)
Thaman. “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use” (2026, arXiv:2605.02964)
McKee-Reid et al. “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
Stechly, Valmeekam, Kambhampati. “On the Self-Verification Limitations of Large Language Models” (2024, arXiv:2402.08115)
Jimenez et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (2023, arXiv:2310.06770)
Zhou et al. “WebArena: A Realistic Web Environment for Building Autonomous Agents” (2023, arXiv:2307.13854)
Image principale : générée par IA (Google Gemini)