Modder Total War avec une IA : méthode, outils et exemples

Le partage des rôles§

« Moi j'ai le cerveau, et toi tu es l'exécution » : c'est ainsi que Charles a résumé le travail. Une IA d'aujourd'hui, utilisée en agent (elle lit vos fichiers, lance des commandes, écrit du code et vérifie ce qu'il produit), abat le travail de fond d'un gros mod. Le jugement, lui, reste humain.

Les mots du modding (pack, startpos, témoin…) sont expliqués dans le guide des outils. Cinq mots de plus pour ce guide : une session, c'est une conversation d'agent, avec son domaine ; une passation, la note qui confie un chantier à une autre session ; un préavis, l'heure annoncée avant d'écrire dans une ressource commune ; MCP (Model Context Protocol), la prise standard par laquelle un agent se branche sur un outil ; un heredoc, un bloc de texte collé dans une commande du terminal.

Quelle IA choisir§

Concrètement : l'un de ces deux modèles, ou plus tard le plus capable pour le code (les noms changent vite), utilisé en agent (Codex pour GPT-6, Claude Code pour Claude), dans le terminal ou dans l'application de bureau, et non dans une simple fenêtre de discussion. L'agent lit le dossier du projet, lance les outils, relit ce qu'ils produisent et corrige ; une fenêtre de discussion vous fait tout recopier à la main.

Un gros abonnement, parce qu'un chantier de modding, ce sont des sessions longues, souvent plusieurs en parallèle : chez nous, jusqu'à quatre sessions à la fois (le 23 septembre), chacune sur son domaine.

Premier pas§

Vous n'avez jamais utilisé d'agent ? Sept gestes, dans l'ordre, avant la première vraie tâche :

Les commandes du geste 3, dans un terminal (remplacez mon_mod par le chemin du dossier de votre mod ; pour Codex, codex au lieu de claude) :

cd mon_mod
claude

Pour installer l'agent, suivez sa page officielle : Claude Code ou Codex. Tous deux existent aussi en application de bureau, si le terminal vous intimide. Dans Claude Code, les autorisations se règlent par /permissions : règles « ask » et « deny », ou un hook. Le détail du branchement de RPFM est plus bas, « Brancher RPFM, pas à pas ».

Brancher l'IA sur les outils§

Une IA ne vaut que par ce qu'elle peut toucher. La règle : tout ce qui peut se faire sans fenêtre doit se faire sans fenêtre.

• RPFM

  Sans fenêtre : MCP. Le serveur MCP de RPFM 5 : rpfm_server.exe, qui écoute sur http://127.0.0.1:45127/mcp. Pour le brancher, dans Claude Code comme dans Codex : plus bas, « Brancher RPFM, pas à pas ». Ensuite : packs, tables, recherche, diagnostics.

  Le détail dans le guide RPFM

• CAIME

  Sans fenêtre, sauf l'import des couches. La ligne de commande officielle ne fait que process (les exports) et validate ; les couches .hex_layer s'écrivent par script mais s'importent par la fenêtre (Tools → Import → Layer data).

  Le guide CAIME

• Dave

  Sans fenêtre : fichiers XML. L'éditeur de tables de l'Assembly Kit : l'IA s'en passe, elle écrit les tables XML de <Assembly Kit>\raw_data\db par script, après sauvegarde.

• BOB

  Un clic : Start. Des fichiers rules.bob écrits par script, puis le passage, d'un clic sur Start. BOB s'ouvre par le lanceur Steam de l'Assembly Kit (Exporter: BOB), par son exécutable bob.modder.x64.exe, ou depuis Terry (Process with BOB, Ctrl+P), qui lui passe le travail. En ligne de commande, on ne lui connaît que l'option -no_console, celle que passe le lanceur.

  Le guide BOB

• Terry

  À la main. Aucune commande pour le piloter (on peut seulement l'ouvrir) : ce qui peut se préparer hors de Terry (projet .terry en XML, rasters, calques) se prépare par script ; le reste se fait à la main.

  Le guide Terry

• Le jeu

  Le lancer : avec votre accord. %APPDATA%\The Creative Assembly\Warhammer3\scripts\user.script.txt, un pack d'essai avec un script Lua, les vidages de plantage et les journaux : %APPDATA%\The Creative Assembly\Warhammer3\crash_report\bad_mods_report.txt, %APPDATA%\The Creative Assembly\Warhammer3\logs\mp_log.txt, et le journal des scripts, qu'active un fichier script/enable_console_logging non vide dans un pack chargé.

  Le guide des outils

Brancher RPFM, pas à pas§

La commande du geste 2, à recopier telle quelle, sur une seule ligne, dans un terminal : la première pour Claude Code, la seconde pour Codex.

claude mcp add --transport http rpfm http://127.0.0.1:45127/mcp
codex mcp add rpfm --url http://127.0.0.1:45127/mcp

Organiser le projet pour une IA§

Chaque session repart d'une conversation vierge : l'agent ne sait que ce qu'il relit au démarrage (le point d'entrée et, chez Claude Code, une courte mémoire automatique). Tout ce qui compte doit donc être écrit, au bon endroit, et relu au début de chaque séance.

Un squelette de CLAUDE.md à copier :

# Mon mod — point d'entrée
## État (date) : ce qui marche, ce qui reste
## Décisions à ne pas rediscuter
## Qui fait quoi : session → domaine (seule à écrire)
## Recettes : commandes exactes
## Règles : sauvegarder avant d'écrire ; rien de publié sans accord

Posez-le à la racine du dossier du projet : l'agent le lit au début de chaque session. Gardez-le court (la documentation de Claude Code conseille moins de 200 lignes) et renvoyez au reste. Il oriente l'agent, il ne verrouille rien : ce qui doit être interdit à coup sûr (lancer le jeu, supprimer, publier) se règle dans les autorisations de l'agent (dans Claude Code, /permissions ; règles « ask » et « deny », ou un hook).

Pour que Codex et Claude Code lisent le même texte, écrivez-le dans AGENTS.md, que Codex lit de lui-même, et mettez dans CLAUDE.md la ligne @AGENTS.md : Claude Code importe alors le fichier au démarrage (sans CLAUDE.md, ses versions récentes lisent directement AGENTS.md). Une phrase « lis CLAUDE.md » ne vaut pas un import : l'agent n'ouvre le fichier que s'il le décide. Notre projet fait l'inverse, un court AGENTS.md qui renvoie à CLAUDE.md : cela marche tant que l'agent suit le renvoi.

Écrivez vos décisions avec « à ne pas rediscuter » : sinon, chaque nouvelle session repropose l'option que vous avez refusée. Chez nous : garder l'échelle de la carte de Warhammer I, pas de découpage de la carte des Empires Immortels.

Plusieurs sessions en parallèle§

• Un domaine par session, un seul rédacteur par fichier : une session pour le pack, le startpos et les essais, qui tient aussi les documents communs ; une pour les données de jeu, les scripts et les textes ; une pour le rendu de la carte (rivières, lacs, ponts, montagnes) ; une pour l'extension, dont ce site. Deux sessions sur les mêmes fichiers se marchent dessus : chez nous, dès le premier jour (une demi-heure de réconciliation) ; plus tard, une session a créé un outil sous le nom d'un script qu'une autre venait d'écrire, et l'a écrasé (restauré ensuite à l'octet près). D'où cette règle, et une autre : vérifier qu'un nom de fichier est libre avant de le créer.
• Un préavis avant d'écrire dans une ressource commune (l'Assembly Kit) : on annonce une heure, au moins cinq minutes plus tard, et l'on n'écrit qu'à cette heure-là, minuteur à l'appui. Sinon, une session qui construit le pack au même moment lirait une table à moitié écrite. Chez nous, plusieurs préavis ont été devancés « à l'œil » : l'heure est désormais calculée par un script.
• Jamais le jeu, Terry ou le startpos sans prévenir les autres ; jamais de pack reconstruit pendant un essai en jeu.
• Un seul rédacteur pour les documents communs : les autres sessions lui envoient leurs erreurs.
• Ranger, jamais supprimer : ce qui ne sert plus part aux archives ; seul l'humain supprime.

Ouvrir deux sessions, pas à pas§

1. Ouvrez chaque session dans le même dossier de projet (deux terminaux, ou deux sessions de l'application).
2. Premier message de chacune : son nom, son domaine, les fichiers où elle seule écrit, et ce qu'elle ne touche pas.
3. Reportez ce partage dans le tableau « Qui fait quoi » du point d'entrée : chaque session le relit en commençant.
4. Avant d'écrire dans une ressource commune, la session annonce une heure (au moins cinq minutes plus tard), attend son minuteur, puis écrit. Les annonces passent par vous, ou par un message d'une session à l'autre si votre outil le permet (c'est ce que nous faisons).
5. Une seule session tient les documents communs ; les autres lui envoient leurs erreurs.

La boucle de travail§

Chaque tâche fait un tour de roue. Le dernier cran compte autant que les autres : une erreur comprise s'écrit le jour même, avec la règle qui l'évite.

Une bonne consigne§

Six lignes suffisent. Voici celle d'un essai de trente tours :

• Le but : ce qu'on veut obtenir, pas seulement la tâche.
• Le critère : comment on saura que c'est réussi (« la campagne tient trente tours sans erreur de script », « l'icône se lit à 74 pixels comme celles de CA »).
• Les sources : « d'après les livres de GW cités », « comme CA le fait sur la carte des Empires ».
• Les interdits : ne pas toucher au startpos, ne rien publier, ne pas lancer le jeu sans prévenir.
• La preuve : la commande exacte, sa sortie, une capture. « C'est corrigé » n'est pas une preuve.
• Un témoin avant toute conclusion : un cas connu pour bon, rejoué à l'identique.

Pour un document de référence, ajoutez une relecture par un second agent : il trouve ce que le premier ne voit plus ; la première version de notre guide technique interne contenait neuf erreurs.

Le journal des erreurs, et les règles codées§

C'est l'outil qui a le plus rapporté. Chaque entrée tient en quatre temps : ce qui a été fait, le symptôme, la cause, la règle. Étiquette évitable si quelqu'un l'avait déjà écrit quelque part (l'entrée donne la règle qui l'évite) ; découverte sinon (l'entrée donne la preuve, et le fait rejoint le guide).

Une entrée du journal, à copier :

34. [évitable] Enchaîner la suite sans attendre la fin du jeu.
Symptôme : essai sans valeur. Cause : « Success » en 0 s = « jeu lancé ».
Règle (codée) : attendre que le processus du jeu apparaisse, puis disparaisse.

Une règle seulement écrite se ré-oublie. Chez nous, la règle « jamais de Python par heredoc » (un heredoc est un bloc de texte collé dans une commande du terminal) est écrite depuis le 21 septembre 2026 et a été enfreinte plus de dix fois dans les trois jours suivants, par plusieurs sessions, dont une fois avec dégâts : une barre oblique perdue a effacé la ponctuation de 102 textes français. Quand c'est possible, codez-la dans un script qui refuse d'avancer : chez nous, la construction du pack refuse un fichier déclaré dans une table et absent du pack, vérifie la syntaxe de chaque script Lua, et un contrôle exige que le compteur de sauvegarde du startpos vaille 1. Et ce qui doit tenir à coup sûr se verrouille dans les autorisations de l'agent (dans Claude Code, règles « ask » et « deny », ou un hook avant chaque commande) : c'est l'outil qui les applique, pas le modèle.

Les cinq règles qui coûtent le plus quand on les oublie§

1. Ne jamais jeter les messages d'un validateur : les regrouper et les compter.
2. Vérifier la donnée avant de crier au bug : un message qui cite une table se vérifie dans la table.
3. Faire relire un document de référence contre ses sources avant de le livrer.
4. Se demander ce que l'écran apprendrait que le disque ne donne pas, avant de piloter une fenêtre.
5. Ne jamais lancer un outil avec des options devinées.

Le récit de ces journées, avec les ratés, est dans le journal : Travailler avec une IA sur un gros mod.

Exemple : les icônes des monuments§

Dans Warhammer III, chaque monument a sa petite icône de 74 pixels, dans le style dessiné de CA. Il en fallait dix pour des monuments que le jeu n'a pas (Turris Vigilans, l'Humble Chapelle, le Tombeau du Duc écarlate…). Aucun générateur d'images : l'IA les a dessinées par du code, et Charles a jugé chaque version.

1. Mesurer le style de CA

   Une seule couleur, une opacité maximale de 0,8, des aplats pleins ; le « fait main » est au bord (contour rongé, brosse sèche) et dans les traits clairs, jamais en grain réparti. Mesuré par script sur les icônes du jeu.

2. Chercher le lore

   Turris Vigilans est un temple de Verena qui sert de phare ; l'Humble Chapelle, malgré son nom, est un édifice orné. Ce qui n'est décrit nulle part reste générique, et marqué comme un choix. Un nom se vérifie dans les textes français du jeu avant de s'imposer : Verena, pas « Vérène ».

3. Dessiner par script

   Du SVG en trois couches (lavis pâle, masses à l'encre, détails par-dessus), des contours tremblés, des coups de pinceau à largeur variable ; une graine fixe par icône, pour que le script redonne toujours la même image.

4. Rendre, puis retoucher au pixel

   Un rendu à huit fois la taille, réduit à 74 pixels, puis une passe automatique qui fait ce que fait un graphiste : aplats pleins, bords durcis d'un pixel, traits clairs continus, pixels isolés retirés.

5. Comparer, juger, recommencer

   Une planche met chaque icône à côté d'une icône de CA de même famille, agrandie et à taille réelle, sur parchemin et sur fond sombre. Charles juge ; trois versions ont suffi.

   ↺ Retour à « Dessiner par script » tant que Charles n'a pas validé.

Ce qui a compté : des critères mesurables tirés du jeu, une boucle courte (script, planche, jugement), et une source pour chaque détail.

D'autres exemples du chantier§

• Transposer une carte entière : les couches de la carte de Warhammer I lues, recalées par nom (les index changent d'un jeu à l'autre), les emplacements de villes agrandis de 7 à 19 hex (16 + 3 pour un port), écrites en .hex_layer et importées dans CAIME.
• Lire un plantage : un vidage lu au débogueur a dit qu'une colonie n'avait pas d'emplacement primary ; un autre, qu'une table de liens gardait une région des Empires absente de notre carte.
• Retrouver les voix de l'histoire : les 43 répliques doublées de la mini-campagne existent encore dans les banques de sons de Warhammer III, en anglais et en français ; l'IA les a retrouvées en suivant la chaîne des évènements sonores.
• Les textes : des noms officiels vérifiés dans les traductions françaises de Games Workshop, un fichier source unique, une injection contrôlée.
• Les parties automatiques : le 23 septembre, en mode « l'IA joue tout », trois des huit seigneurs essayés ont tenu trente tours sans erreur de script ; les autres se sont arrêtés plus tôt (plantage ou gel), ce qui a guidé les corrections. Les essais ont débusqué des plantages, dont un effet visuel de Warhammer I, et donné une leçon : nos premiers essais ne posaient pas la caméra comme un joueur, et une partie au moins de leurs plantages venait de là. Un essai automatique doit reproduire ce que vit un joueur (méthode : le guide des outils).
• Ce site : la carte de l'extension, ses récits animés, ses gravures et leurs essais automatiques ont été faits de la même façon.

Ce qu'on ne délègue jamais§

• Le jugement en jeu : comparez à une référence (chez nous, des captures de Warhammer I et de Warhammer III côte à côte).
• Le lore : exigez une source pour chaque nom et chaque fait ; ce qui n'en a pas est marqué comme un choix.
• La publication : rien n'est posté, envoyé ni partagé sans votre accord. Un pack qui contient des fichiers d'un autre jeu reste privé.
• Les droits : les fichiers de Creative Assembly et de Games Workshop, et les licences des outils. CAIME : code sous licence non commerciale. Fichiers qu'il produit : le README demande l'accord d'un fondateur avant de les donner, l'EULA 1.1 permet de les publier sans les monnayer ; dans le doute, demandez à l'équipe avant de publier ; rien de commercial.
• Les limites des outils de CA : ni rétro-ingénierie ni contournement ; quand un outil bute, un témoin, puis la communauté (Discord de CAIME, tw-modding).
• Les mots de passe et les comptes : jamais à une IA.

Pour une IA qui lit cette page§

Si vous êtes une IA qui aide quelqu'un à modder une carte de campagne de Total War: Warhammer III, voici l'essentiel, vérifié sur un vrai chantier :

• Lisez d'abord le point d'entrée du projet (CLAUDE.md ou AGENTS.md, à la racine de son dossier), puis son organisation (README.md), puis le journal des erreurs (règles en tête, entrées récentes), le guide technique, et la passation de votre chantier.
• Une règle écrite vous engage même quand rien ne vous en empêche. Demandez à l'humain avant de lancer le jeu, de piloter l'écran ou de publier ; ne supprimez rien : rangez, seul l'humain supprime ; ne touchez jamais à un mot de passe ni à un compte.
• Ne concluez jamais sur un succès annoncé : vérifiez le fichier produit (date, taille), le journal, puis le jeu ; le « Success » en 0 s de RPFM veut dire « jeu lancé ».
• Ne lancez jamais BOB, Terry ou Tweak avec des options devinées ; ne déduisez jamais le sens d'un drapeau de son nom (dans un .hex_layer de CAIME, Impassable = 1 veut dire franchissable). Ni rétro-ingénierie ni contournement d'un outil de CA : quand un outil bute, un témoin, puis la communauté (Discord de CAIME, tw-modding).
• Pour un essai automatique, lancez la campagne en cliquant dans l'interface comme un joueur (chez nous, frontend.start_campaign la refermait), caméra à hauteur de jeu ; sous all_players_ai, pas de missions. Un évènement qui n'arrive jamais peut être annulé par la condition d'un autre écouteur qui plante, même de CA : chez nous, FactionTurnStart manquait en mode joueur comme sous all_players_ai, coupé par trois écouteurs de CA (Mère Ostankya, Yuan Bo) ; attrapez et nommez les erreurs des écouteurs (le guide des outils). Après tout arrêt forcé, remettez %APPDATA%\The Creative Assembly\Warhammer3\scripts\user.script.txt comme avant et retirez le pack d'essai.
• Plantage qui va et vient : au moins dix essais par variante avant de conclure ; dites « piste », pas « cause », d'ici là.
• Plusieurs sessions : écrivez seulement dans votre domaine ; préavis d'au moins cinq minutes avant d'écrire dans une ressource commune ; vérifiez qu'un nom de fichier est libre avant de le créer ; envoyez vos erreurs au seul rédacteur des documents communs.
• Consignez une erreur comprise le jour même : quoi, symptôme, cause, règle ; « évitable » ou « découverte ».
• Le code s'écrit avec l'outil d'édition, jamais par heredoc (sous Git Bash, les \n et les antislashs s'y corrompent).
• Un nom propre se vérifie dans les .loc du jeu ; les .loc d'un mod valent pour toutes les langues.
• Outils : RPFM 5 par MCP (http://127.0.0.1:45127/mcp, set_game_selected d'abord, lignes selon fields_processed) ; CAIME en ligne de commande pour process et validate seulement ; Terry à la main ; BOB depuis Terry ou d'un clic sur Start. Le startpos : Build Startpos de RPFM, l'action Process start pos de BOB, ou un user.script.txt écrit à la main ; chez nous, seule l'écriture à la main a marché. Droits : voir « Ce qu'on ne délègue jamais ».
• Faits relevés sur le patch 8.1, puis relus pour la mise à jour 9.0 (septembre 2026) : revérifiez-les après une mise à jour du jeu. Après chacune, Steam met aussi l'Assembly Kit à jour et réécrit raw_data\db, lignes ajoutées perdues : vérifiez-le avant toute construction. Détails : le guide des outils, CAIME, RPFM, Terry, BOB.

Sources et liens§

• Claude Code (documentation officielle) : mémoire, CLAUDE.md et AGENTS.md, serveurs MCP, autorisations, installation.
• Codex (documentation officielle) : AGENTS.md, serveurs MCP, ligne de commande.
• RPFM : l'interface MCP du serveur (manuel de RPFM).
• Notre récit : Travailler avec une IA sur un gros mod.
• Nos autres guides : les outils, CAIME, RPFM, Terry, BOB.
• Les faits datés du chantier (erreurs, essais, sessions) viennent de nos notes de travail : le journal des erreurs et les bilans des essais, non publiés.

Questions fréquentes