AetherJudge
Comment savoir si une nouvelle IA est vraiment meilleure que celle qui tourne déjà — avant de la déployer.
Six semaines passées à construire une méthode pour juger honnêtement des IA de combat dans un jeu vidéo dont le code est fermé. On a écrit notre propre version du jeu en parallèle pour pouvoir comparer les résultats — comme deux compilateurs qui produiraient le même programme. Soixante mini-expériences, chacune clôturée par un verdict écrit. Trois quarts ont été rejetés. Le titre académique du paper est en anglais ci-dessous, l'histoire qu'il raconte est ici, en clair. (titre original : « Slice-driven engine search with decompiled cross-check and independent-corpus discipline »)
Ce qui s'est passé
Une nouvelle IA a gagné 100% de ses duels contre l'IA qui tournait déjà — sur les combats qu'on lui avait préparés. On l'a quand même refusée. Pourquoi ? On l'a testée sur des combats qu'elle n'avait jamais vus, et on a découvert qu'elle coûtait 2,8 fois plus cher que prévu en calcul. Trop chère pour la prod. La règle qui nous a empêchés de la déployer est devenue une règle permanente du projet.
Ce qu'on en retient
Un signal qui ne survit pas à des données qu'on n'a pas choisies n'est pas un signal — c'est une propriété de ce qu'on a sélectionné. Pour transformer cette idée d'un vœu pieux en garde-fou réel, il faut écrire son verdict avant de promouvoir, en choisissant dans une liste fixe de 6 jugements possibles (verdict ladder).
Qui ça concerne
Toi, si tu déploies des décisions venant d'un système dont les résultats ne sont pas faciles à expliquer ou à reproduire « à l'aveugle » : des règles ajustées à la main, des modèles d'IA, des compilateurs sur mesure, des systèmes distribués sur plusieurs serveurs. La checklist complète est juste en dessous (section 00).
À qui s'adresse cette méthode
Elle force un résultat qui a l'air bon — un score parfait, un test gagné, 100% de victoires sur les exemples qu'on a choisis — à prouver qu'il tient encore sur des exemples qu'il n'a jamais vus, avant qu'on accepte de le déployer.
Sans cette règle, le candidat beam-rerank-v1 partait en prod sur ses 100% de victoires. Avec, on a découvert que son coût réel était 2,8× plus élevé qu'on ne pensait sur des données
fraîches — et il a été archivé (voir le détail §01 ci-dessous).
Trois conditions pour que la méthode te concerne. Si l'une te manque, tu n'en as pas besoin — tes tests classiques suffisent. Si les trois sont réunies, tu accumules silencieusement de la dette de fiabilité (Sculley-debt, 2015) tant que tu ne mets pas ce garde-fou en place.
Tes décisions sont difficiles à expliquer à quelqu'un d'autre
Si tu donnes les mêmes données et les mêmes règles à un collègue, il n'arrive pas tout seul au même verdict que toi — il lui manque le contexte que tu as en tête. Cas typiques : règles ajustées à la main, modèles d'IA, compilateurs sur mesure, systèmes répartis sur plusieurs serveurs. Si à l'inverse, ton collègue peut trancher mécaniquement comme toi, pas besoin de la méthode.
Tu peux construire un « témoin » indépendant qui tourne aussi
Pas une collection figée de bonnes réponses (ça détecte les régressions, pas les nouveaux problèmes). Un second système qui produit le résultat sur des cas qu'il n'a jamais vus : un programme désassemblé, une version plus simple écrite à la main, un modèle volontairement basique. Pour valider un compilateur, le seul juge crédible est un autre compilateur (méthodes Csmith, EMI).
Tu acceptes d'écrire ton verdict avant de déployer
Choisir dans une liste fixe de 6 jugements possibles, c'est plus lourd qu'un simple
« ça passe / ça passe pas ». Mais c'est exactement cette lourdeur qui a empêché beam-rerank-v1 de partir
en prod sur ses 100% de victoires, quand son coût réel était 2,8× sous-estimé sur des données fraîches.
Si tes tests peuvent être rejoués sur les mêmes données et donner le même verdict — du test classique sur une spécification stable — la mécanique décrite ici est inutilement lourde. Cette méthode est calibrée pour les systèmes où la spec est ce que le code fait, où la vérité n'est pas écrite quelque part avant, et où un verdict doit survivre à un re-test indépendant avant d'engager un déploiement.
Le moment de bascule
Un ingénieur raisonnable aurait promu.
La méthodologie l'a refusé.
§1 — Introduction
Le 29 avril 2026, l'expérience numéro 4 produit le signal le plus fort jamais enregistré
sur le projet : un nouveau candidat — beam-rerank-v1 — bat le moteur en production dans 100% des duels qu'on lui fait passer, sur 110 situations
de combat enregistrées. Voici ce qui s'est passé dans la journée. À chaque étape, on essaie
de découvrir ce qui se cache derrière le signal — c'est ce qu'on appelle une décomposition forensique (on démonte le résultat pièce par pièce, comme
une autopsie de la victoire).
Le signal
Un nouveau candidat — beam-rerank-v1 — gagne 100% des duels contre le moteur en production (paired trials) sur 110 situations de combat enregistrées. Sur les cas les plus délicats : 48 victoires, 0 défaite. Et il perd 7 combats de moins. Un ingénieur raisonnable aurait dit « banco, on déploie ».
On regarde sous le capot
On démonte les victoires une par une. 15% reposent sur une règle de secours qu'on savait déjà fragile (la 6ᵉ de notre liste de critères, scoreState). Le signal existe, mais il est en partie soutenu par une béquille — pas un vrai gain de fond.
On découvre qu'on n'a pas d'outil
On veut tester sur de nouvelles données, jamais vues par le candidat. Problème : on s'aperçoit qu'on n'a aucun moyen d'en récolter. Le jeu de données initial avait été constitué une seule fois, à la main, le 27 avril. Pas de second tirage possible.
On construit l'outil manquant
On code en urgence : un enregistreur de parties, un système de catalogage, 16 tests. Mais pour s'en servir, il faut un humain qui joue 1 à 2 heures sur Windows. L'IA assistante ne peut pas le faire toute seule. On attend.
Le verdict tombe
50 combats inédits, 209 situations. Le candidat gagne toujours, statistiquement quasi-certain (probabilité de hasard ≈ 2,6×10⁻²⁶, aucune défaite). MAIS : son coût de calcul réel n'est pas 4,76× plus cher que la prod comme on l'avait estimé — il est 13,26× plus cher. 2,8× plus que ce qu'on croyait. Non-viable en production. Archivé.
La règle qui nous a empêchés de déployer ce candidat est devenue une règle permanente du projet. Archiver ce candidat n'est pas un échec — c'est ce que la méthode est censée faire quand un signal séduisant ne survit pas à un second regard.
L'échelle des 6 verdicts
Chaque expérience se termine par un verdict écrit, choisi dans une liste fixe de 6 jugements possibles. Le verdict n'est pas une opinion — c'est un engagement clair qui décide si le candidat continue, dort sur l'étagère, ou disparaît du projet. On ne déploie jamais sans verdict. Voici les six.
Prêt à partir en prod
Le candidat peut remplacer ce qui tourne aujourd'hui. C'est le verdict le plus rare — il exige un signal fort, un coût raisonnable, et un test sur des données qu'il n'avait jamais vues.
Signal sérieux, mais à confirmer
Il se passe quelque chose de vrai, on le mesure — mais une condition manque (le coût, un second jeu de données, une décomposition fine). On l'arrête net jusqu'à ce que la pièce manquante arrive.
Le test n'a rien tranché
Pas assez de signal, ou biais dans les données choisies, ou outil manquant. On ne retente pas avec le même protocole — on change le protocole d'abord, sinon c'est juste plus de bruit.
Bloqué — il faut un humain
Le test ne peut pas continuer tant qu'une dépendance externe n'est pas livrée (un humain qui capture des données réelles, un accès machine, des fichiers absents). L'agent attend, il ne triche pas.
Hypothèse réfutée
On pensait qu'un truc marcherait, on l'a testé, ça ne marche pas. Trace écrite, candidat retiré. C'est le verdict le plus fréquent — et c'est ce qui rend la démarche fiable : on ne garde que ce qui survit.
Archivé — vivant mais hors-ligne
Le candidat ne tournera plus jamais en production. Mais son code est conservé comme témoin de référence, utile pour comparer plus tard. C'est un choix méthodologique, pas un échec.
Deux versions du jeu, comparées en direct
L'analogie n'est pas le jeu vidéo, c'est le test de compilateurs. Yang et al. (Csmith, 2011) et Le et al. (EMI, 2014) ont établi qu'on ne peut pas juger un compilateur tout seul — il faut un autre compilateur qui produit le même programme à partir du même code, et comparer. Si les deux sorties diffèrent, l'un des deux a un bug. Ici, on a fait pareil : on a réécrit notre propre version du jeu en TypeScript, et on la compare en permanence à ce que fait vraiment le vrai jeu. Chaque désaccord entre les deux désigne un bug d'un côté ou de l'autre.
Le simulateur TypeScript
- · 100 000 lignes de code, 652 commits
- · Le moteur de combat seul : 70 000 lignes
- · Le système de jugement (AetherJudge) : 70% de ce moteur
- · Plus de tests automatiques que de code utile (1,13×)
- · Écrit à la main, en binôme avec une IA assistante
Le binaire C# du jeu Steam
- · Unity 6 (le moteur derrière le jeu), code C# fermé
- · On s'injecte dedans avec un outil (BepInEx) qui patche le code à la volée (Harmony)
- · On rejoue les mêmes actions des deux côtés et on compare
- · ~95% des actions principales sont alignées entre les deux
- · 13 pièges techniques rencontrés et documentés pour les suivants
À notre connaissance, c'est le premier travail publié qui formalise explicitement la ré-écriture d'un moteur de jeu contre un binaire commercial désassemblé, comme on testerait un compilateur (méthode differential testing, style Csmith/EMI).
Le résultat négatif central
« Une approche style « AlphaGo allégé » (MCTS Gumbel-AlphaZero), sans son cerveau intuitif appris, n'arrive pas à dépasser une recherche bien plus simple (beam search) affinée à la main pendant six semaines. »
À nuancer — C'est cohérent avec la littérature : la version originale (Danihelka et al., 2022) suppose un réseau de neurones qui a appris à évaluer les positions. Ici, on l'a remplacé par une formule mathématique écrite à la main (tanh(scoreState)). Donc on ne réfute pas la méthode AlphaGo — on confirme qu'elle ne marche pas sans son ingrédient principal.
Ce qu'on en garde — La fameuse « leçon amère » de Sutton (bitter lesson) — « plus de calcul + plus d'apprentissage gagne toujours » — s'applique au couple recherche + apprentissage, pas à la recherche seule. Le beam search reste donc l'approche choisie. Les outils construits autour (oracle de référence, analyseur d'échecs, orchestrateur d'expériences) sont réutilisables sur d'autres projets, peu importe l'algorithme.
Le droit d'enfreindre une règle — proprement (la doctrine « path E »)
Deux scènes différentes, deux règles différentes
On distingue ce qui part en prod de ce qui sert à mesurer. L'auteur peut décider d'enfreindre une limite de coût pour ce qui part en prod — en l'écrivant, signé et tracé — sans jamais toucher à la même limite quand on mesure. Les chiffres de comparaison restent intacts.
Ce que la doctrine empêche
On a le droit de dire « cette règle ne s'applique pas ici, et voici pourquoi ». On n'a pas le droit de dire « cette règle n'existe pas ». La suspension est traçable, écrite, et limitée à un seul endroit. C'est la frontière qui sépare une décision honnête d'une rationalisation déguisée.
Une décision prise en cascade
Le moteur qui tourne en production — un beam search ajusté pendant six semaines — au combat. Concrètement, c'est une fonction qui regarde l'état du combat et applique 8 règles dans un ordre précis : la première qui correspond gagne, on prend sa décision, fin de l'histoire. 39 tests automatiques vérifient que chaque règle se comporte bien. À l'écran ci-dessous, on rejoue les mêmes actions dans notre simulateur, et on s'assure qu'il fait la même chose que le vrai jeu.
Aethermancer · Unity 6 · BepInEx instrumented session, mai 2026