CivBench : on a fait jouer des IA à Civilization VI pendant 300 tours, et elles oublient de regarder le tableau des scores

Tour 280. Votre civilisation est prospère, vos villes bourdonnent, vos archers à cheval scythes ont nettoyé les barbares depuis longtemps. Vous rédigez consciencieusement votre plan pour les dix prochains tours. Et pendant ce temps, à l'autre bout de la carte, Babylone termine tranquillement son vaisseau spatial. La partie s'arrête. Vous n'aviez pas regardé l'écran de progression de victoire depuis soixante tours.

Ce scénario n'est pas celui d'un joueur distrait un dimanche soir. C'est celui, répété sept fois sur vingt défaites, d'agents propulsés par les meilleurs modèles de langage du marché, dans une étude publiée le 2 septembre 2026 sur arXiv. Le papier s'intitule CivBench: A Long-Horizon Benchmark for Tool-Mediated Agents in Civilization VI, signé par Austin Tudor David Andrews, Liam Wilkinson, Jamie Heagerty, Harry Coppock, Jakob Nicolaus Foerster et Rui Ponte Costa. Son constat tient en une phrase malicieuse : les agents ont accès à toute l'information, on leur a dit où regarder, et ils ne regardent pas.

Civilization VI comme salle d'examen

Pourquoi un jeu de stratégie de 2016 pour évaluer des IA de 2026 ? Parce que la plupart des benchmarks d'agents mesurent des capacités isolées : raisonner sur un problème, appeler un outil, rédiger un plan. Or, ce qui casse dans la vraie vie, ce n'est pas chaque brique prise séparément, c'est leur assemblage sur la durée. Les auteurs veulent un environnement où il faut simultanément gérer l'économie, la science, la culture, l'armée, la diplomatie, l'espace et le temps. Civilization VI coche toutes les cases : une partie dure plus de 300 tours, six conditions de victoire coexistent, et un rival peut vous éliminer sans jamais poser un pied sur votre territoire.

Le dispositif technique repose sur le Model Context Protocol (MCP), ce standard qui permet à un modèle de langage d'appeler des outils extérieurs comme on branche une prise. CivBench expose 76 outils au total : 27 pour interroger l'état du jeu, 10 pour bouger les unités, 9 pour gérer les villes, 7 pour la diplomatie, 10 pour la gouvernance, 5 pour la religion et la culture, et 8 pour le cycle de jeu lui-même. Le tout dialogue avec le moteur via FireTuner, le protocole de débogage interne du jeu, que les auteurs ont rétro-ingénié. Pas de reconnaissance d'image, pas de triche : l'agent lit l'état de la partie via les API natives du moteur.

Une couche de narration (narration layer) traduit ensuite l'état visuel en texte structuré. Voici à quoi ressemble ce que voit l'agent quand il demande une vue d'ensemble :

Turn 87/330 | Scythia | Score: 198 | Gold: 156 (+12/turn) | Science: 24.3
Cities: 4 | Population: 14 | Units: 9 | Explored: 34% of land
9 units: Saka Horse Archer... CAN ATTACK: Barbarian WARRIOR...

Un tour typique consomme entre 5 et 15 appels d'outils. Sur une partie complète, cela fait plusieurs milliers d'appels, pour un coût de 31 à 229 dollars d'API et une durée de deux à huit heures par partie. On est loin du quiz à choix multiples.

Le détail de conception qui change tout

Le choix le plus astucieux du papier tient en une contrainte : rien n'est donné, tout doit être demandé. Un joueur humain absorbe passivement la minimap, le ticker de score, les notifications diplomatiques qui clignotent dans le coin de l'écran. L'agent, lui, ne voit que ce qu'il interroge explicitement. Les auteurs appellent ça le sensorium, et le manuel fourni aux agents le dit en toutes lettres : « Vous ne savez que ce que vous demandez explicitement. Un joueur humain absorbe passivement la minimap, le score... vous n'avez rien de tout cela. »

Cette contrainte est ce qui rend le benchmark intéressant. Elle permet de distinguer deux situations que les benchmarks classiques confondent : l'information indisponible et l'information disponible mais jamais récupérée. Imaginez un pilote de ligne dont le tableau de bord serait remplacé par un assistant vocal qu'il faut interroger. « Altitude ? » « Carburant ? » « Trafic ? » Si l'avion tombe à court de kérosène, on saura exactement si la jauge était en panne ou si le pilote a simplement oublié de poser la question. CivBench est ce cockpit-là.

Le protocole : un manuel de jeu et un journal de bord

Tous les agents reçoivent le même playbook, un manuel versionné qui décrit la boucle de tour, rappelle la contrainte du sensorium et impose des points de contrôle stratégiques : tous les 20 tours, interroger la diplomatie, la progression de victoire et la propagation religieuse. Ce manuel n'est pas un luxe. Avant son introduction, seulement 21 % des parties arrivaient à une conclusion naturelle. Sans garde-fou, les agents s'enlisaient.

À chaque tour, l'agent doit aussi remplir un journal structuré à cinq champs : tactique, stratégie, outillage, planification, hypothèse. Un exemple tiré du papier, après qu'un agent a repéré un barbare menaçant son colon :

Tactique : « Intercepté un guerrier barbare menaçant le colon. 47 dégâts à distance, je le termine au prochain tour. »
Stratégie : « Babylone mène de 47 points. Besoin d'une 3e ville rapidement, colon prêt au prochain tour. »
Planification : « T88 : finir le barbare, déplacer le colon vers l'est. T89 : fonder une ville en (15,25). »
Hypothèse : « Babylone va probablement déclarer une amitié, les modificateurs sont en hausse. »

Ce journal n'est pas qu'un outil pour l'agent. C'est surtout une trace exploitable pour les chercheurs, qui peuvent ensuite vérifier si ce qui a été écrit a été fait.

Trois scénarios ont été conçus. Ground Control (carte Pangaea standard, difficulté Prince) sert de test de base. Snowflake (carte à six bras, difficulté King) pousse vers le militaire. Cry Havoc (petite carte, difficulté Immortal) est un test de stress si sévère que les auteurs l'ont exclu des résultats. Au final, 23 parties sont jugées admissibles : 19 sur Ground Control, 4 sur Snowflake. Quatre familles de modèles ont joué entre le 2 et le 18 avril 2026 : Claude Opus 4.6 (8 parties), GPT-5.4 (7), Gemini 3.1 Pro (6) et Kimi-K2.5 (1 seule).

Premier résultat : le score ne dit rien

Avec 23 parties, on pourrait espérer un classement. Les auteurs coupent court : ce n'est pas un classement de modèles, et ils le répètent à chaque section. Trois victoires sur 23, toutes sur Ground Control et toutes par la technologie. Un test exact de Fisher sur les taux de victoire donne p = 0,488, autrement dit aucun modèle ne se distingue. Le score normalisé (score de l'agent divisé par celui du vainqueur) ne fait guère mieux. Et sur 13 métriques de résultat candidates, une seule discrimine réellement les modèles : le pourcentage de carte exploré au tour 100.

La raison est simple et un peu vexante : la variance au sein d'un même modèle écrase la variance entre modèles. Le même agent peut faire une partie brillante puis une partie catastrophique. Mesurer le résultat final, c'est comme juger un chef sur la note moyenne de trois dîners : on n'apprend rien sur sa façon de cuisiner. D'où l'idée centrale du papier : regarder non pas ce que l'agent obtient, mais comment il dépense son attention.

Deuxième résultat : les agents ne regardent pas le tableau des scores

La première métrique introduite s'appelle Proactive Monitoring Rate (PMR), le taux de surveillance proactive. Elle se calcule en divisant le nombre d'appels à des outils de surveillance stratégique (diplomatie, progression de victoire, religion) par le nombre total d'appels d'outils, hors infrastructure comme la fin de tour. C'est, en somme, la part du budget d'attention consacrée à lever la tête du guidon.

Les chiffres sont éloquents.

Mesure	Valeur observée
PMR global, selon le modèle	0,96 % à 2,13 % des appels
Part consacrée à la progression de victoire	0,05 % à 0,29 %
Appels à la progression de victoire par partie	3,7 à 10
Fréquence effective	un appel tous les 30 à 75 tours
Fréquence demandée par le manuel	un appel tous les 20 tours

Le manuel dit « tous les 20 tours ». Les agents font « tous les 30 à 75 tours ». Et le plus révélateur est dans le tableau des défaites. Sur les 20 parties perdues, les auteurs ont vérifié si un appel à la progression de victoire aurait révélé la menace au moins 20 tours avant la fin. Dans les 20 cas, oui. Or dans 7 de ces 20 cas, l'agent n'a jamais posé la question durant cette fenêtre d'alerte. Par modèle : 3 parties sur 6 pour Claude Opus 4.6, 4 sur 8 pour GPT-5.4, 1 sur 5 pour Gemini 3.1 Pro, 0 sur 1 pour Kimi-K2.5.

Autre détail qui pique : le PMR n'augmente pas en fin de partie, là où surveiller serait le plus utile. Les auteurs y voient une allocation d'attention persistante plutôt qu'un simple problème de fenêtre de contexte saturée. L'agent ne se dit pas « la fin approche, vérifions où en sont les autres ». Il continue à gérer ses villes comme au tour 50.

Troisième résultat : les promesses qu'on ne tient pas

La seconde métrique porte un acronyme que les habitués de la maison connaissent sous un autre sens. RAG@K, ici, signifie Reflection-Action Gap, l'écart entre réflexion et action, et n'a rien à voir avec la génération augmentée par récupération. L'idée : extraire du champ « planification » du journal les engagements concrets à court terme, puis vérifier dans les logs si l'agent les a exécutés dans les K tours suivants. Avec K fixé à 10, on obtient RAG@10.

Le score combine engagements pleinement exécutés (comptés pour 1) et partiellement exécutés (comptés pour 0,5), divisés par le total des engagements. L'extraction et l'étiquetage sont confiés à Claude Haiku 4.5 selon une grille fixe, puis validés sur 50 engagements par des annotateurs humains : 92 % d'accord, kappa de 0,879, ce qui est solide. Les auteurs notent honnêtement que leur étiqueteur partage sa famille avec l'un des agents évalués, mais observent que Claude Opus 4.6 obtient justement le score le plus bas des trois, ce qui écarte l'hypothèse d'un biais familial.

Résultat : RAG@10 s'étale de 48,2 % à 65,8 % selon les modèles, avec des intervalles de confiance qui se chevauchent. Autrement dit, entre un tiers et la moitié des engagements écrits noir sur blanc par l'agent lui-même ne sont pas honorés dans les dix tours. Les exemples cités sont d'une banalité désarmante : « construire des campus dans les nouvelles villes », « fonder une deuxième ville », et, comble de l'ironie, « vérifier la progression de victoire ».

L'image qui vient est celle des bonnes résolutions du Nouvel An. On les écrit avec sincérité, elles sont raisonnables, et pourtant elles s'évaporent parce que le quotidien reprend ses droits. Sauf qu'ici, le « quotidien », c'est l'archer barbare qui attire toute l'attention au tour suivant, et le plan à dix tours ne survit pas au prochain appel d'outil.

Pourquoi ce papier compte

Ce n'est pas un papier qui annonce une percée. C'est un papier qui rend mesurable quelque chose que tout le monde constatait à la louche. Quiconque a laissé tourner un agent de code plusieurs heures connaît ces deux syndromes : l'agent qui ne relance jamais les tests alors qu'il pourrait, et l'agent qui écrit un plan en cinq points puis en oublie trois. CivBench leur donne un nom, une formule et un intervalle de confiance.

Le renversement de perspective est salutaire. Là où la plupart des benchmarks cherchent à produire un tableau de classement, celui-ci affirme que le classement est prématuré à cette échelle et propose des métriques d'interface : elles ne mesurent pas ce que le modèle sait, mais comment il utilise ce qu'il a. Les auteurs insistent : ces échecs surviennent malgré l'accès aux outils et malgré une consigne explicite. Ils parlent de « déviations sous instruction », pas d'incapacité. La nuance est importante pour qui construit des agents : le problème n'est peut-être pas à régler par un meilleur modèle, mais par une meilleure architecture.

Le papier esquisse d'ailleurs trois pistes. D'abord, imposer mécaniquement la surveillance : un planning de requêtes forcé, ou une interface qui remonte d'elle-même les signaux critiques, quitte à trahir un peu le principe du sensorium. Ensuite, doter les agents d'une mémoire structurée des engagements, une file de tâches que le système relance plutôt qu'un simple champ texte que le modèle relit ou non. Enfin, traiter l'allocation d'attention comme un axe d'évaluation à part entière, distinct du raisonnement brut.

Et puis il y a le geste d'ouverture : environnement, scénarios, logs, métriques et pipeline d'analyse sont publiés sur GitHub, et les figures se régénèrent en moins de cinq minutes sur un ordinateur portable. Il faut certes posséder Civilization VI avec l'extension Gathering Storm, mais le reste est à portée de main.

Les bémols, et ils sont nombreux

Le premier est celui de la taille. Vingt-trois parties, dont une seule pour Kimi-K2.5, c'est un pilote, et les auteurs ne prétendent rien d'autre. L'étude n'est « alimentée que pour les grands effets », et les différences entre modèles restent descriptives. Le lecteur qui repartirait avec « Gemini surveille mieux que Claude » aurait mal lu.

Le deuxième est le confondant du manuel. Puisque le playbook impose des points de contrôle et un journal, ce qu'on mesure est un mélange de raisonnement du modèle, de maîtrise des outils et de suivi de consignes. RAG@10 mesure l'exécution de plans sollicités, pas de plans spontanés. Un agent sans manuel planifierait peut-être moins mais tiendrait davantage ses rares engagements. On ne le saura pas, car sans manuel, quatre parties sur cinq ne se terminaient même pas.

Le troisième est l'absence de ligne de base. Aucun agent aléatoire ni scripté n'a joué. On ne sait donc pas ce que vaut un PMR de 2 % en absolu, ni si un simple script « interroge la victoire tous les 20 tours » ferait mieux que les modèles à plusieurs centaines de dollars la partie. Les auteurs le reconnaissent comme direction future.

Viennent ensuite les contraintes pratiques : licence commerciale, dépendance à une version précise du jeu, FireTuner qui n'accepte qu'une seule connexion à la fois, ce qui exclut les configurations multi-agents. Et la question de la contamination : les stratégies de Civilization VI abondent sur le web et donc dans les données d'entraînement. Les auteurs répondent que chaque partie exige une adaptation en direct sous observabilité partielle, ce qui est vrai, mais ne règle pas entièrement la question.

Enfin, les métriques elles-mêmes dépendent de choix arbitraires : quels outils comptent comme « surveillance », comment on interprète un texte de planification. Les auteurs le disent avec une modestie rare : les résultats sont des mesures « sous le protocole CivBench », pas une caractérisation exhaustive de la capacité des agents.

Ce qu'on va surveiller

Le mérite de CivBench n'est pas de dire que les agents jouent mal à Civilization. C'est de montrer qu'un environnement grand public, avec un bon protocole d'observation, peut isoler des défaillances que les benchmarks de raisonnement ne voient pas. Le sensorium et l'écart réflexion-action sont deux concepts qui vont probablement essaimer bien au-delà des jeux : dans les agents de code qui tournent la nuit, dans les assistants de recherche qui enchaînent des centaines d'appels, dans tout système censé tenir un cap pendant des heures.

Trois choses à guetter dans les mois qui viennent. Une version du benchmark avec ligne de base scriptée, qui donnerait enfin un plancher. Des architectures d'agents qui intègrent une file d'engagements et un planificateur de surveillance, et qu'on pourra tester sur les mêmes métriques. Et, plus largement, l'adoption de PMR et RAG@K par d'autres environnements, car si ces deux chiffres se révèlent stables d'un domaine à l'autre, on tiendra un vrai thermomètre de l'autonomie longue durée.

En attendant, la prochaine fois que votre agent préféré vous jure qu'il va « vérifier les tests après ce refactoring », vous saurez qu'il y a environ une chance sur deux qu'il le fasse dans les dix prochains tours. Ce n'est pas de la mauvaise foi. C'est juste qu'un barbare est passé par là.

Référence : Austin Tudor David Andrews, Liam Wilkinson, Jamie Heagerty, Harry Coppock, Jakob Nicolaus Foerster, Rui Ponte Costa, « CivBench: A Long-Horizon Benchmark for Tool-Mediated Agents in Civilization VI », arXiv:2609.02459, déposé le 2 septembre 2026. https://arxiv.org/abs/2609.02459. Code et données : https://github.com/lmwilki/civ6-mcp.