# Modder Total War avec une IA : méthode, outils et exemples > Quatre jours de chantier pour faire entrer dans Warhammer III une carte de campagne entière de Warhammer I : elle se charge et se joue, et le rendu comme la stabilité se peaufinent encore. Une IA à l'exécution, un humain au jugement. Voici comment s'y prendre : quelle IA, comment démarrer, comment la brancher sur les outils du modding, comment organiser le travail pour qu'elle refasse le moins possible les mêmes erreurs, et des exemples à copier. Page : https://bretonia.dev/atelier/ia/ · Atlas de Bretonnie, atelier des moddeurs · mis à jour le 2026-09-25. Version en texte brut, pour les lecteurs et les IA ; les schémas y sont décrits en mots. Relu le 25 septembre 2026, mise à jour 9.0. Écrit contre ses sources, la documentation de Claude Code et de Codex, RPFM 5.0.6 ; ce que la 9.0 a changé sur notre chantier y est ajouté, le reste n'a pas été revérifié point par point. ## 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. **L'humain : le cerveau** - décide ; ses décisions s'écrivent « à ne pas rediscuter » - juge en jeu, face à une référence : est-ce beau, fidèle, amusant ? - valide le lore et ses sources : une IA peut inventer avec aplomb - voit l'écran : l'IA ne le voit que si vous le lui montrez - décide de ce qui se publie ; seul à supprimer **L'agent IA : l'exécution** - écrit les scripts (Python, Lua) et des milliers de lignes de tables - décortique les fichiers du jeu, lit les vidages de plantage - pilote RPFM par MCP, lance en ligne de commande les exports et les validations de CAIME (Campaign AI Map Editor), l'éditeur du Campaign Map Toolkit - tient la documentation, le journal des erreurs, les passations - mène les essais et rapporte les preuves Les mots du modding (pack, startpos, témoin…) sont expliqués dans [le guide des outils](https://bretonia.dev/atelier/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 > **La recommandation de Charles (23 septembre 2026)** : « Je recommande vraiment GPT-6 et Claude 5.5 […] via Codex ou via Claude Code, avec un gros abonnement. » 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. *Schéma : Fenêtre de discussion ou agent.* Dans le schéma : Fenêtre de discussion ou agent · Une fenêtre de discussion · Vous y collez le fichier · Vous recopiez sa réponse dans le fichier · Vous lancez l'outil, vous recopiez l'erreur · tout passe par vos mains · Un agent : Claude Code, Codex · Il lit le dossier du projet · Il lance l'outil et lit sa sortie · Il corrige, puis vous montre la preuve · vous jugez Dans une fenêtre de discussion, tout passe par vos mains ; un agent lit, lance et corrige lui-même, puis vous rapporte la preuve. Vous gardez le jugement. 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 : *Schéma : Premier pas, de zéro à la première preuve.* Dans le schéma : Premier pas · Faire une copie datée du dossier du mod · ou le mettre sous git : l'agent écrit dans vos fichiers, la copie permet de revenir en arrière. · Installer l'agent · Claude Code ou Codex, depuis leur page officielle ; tous deux existent aussi en application de bureau. · L'ouvrir dans le dossier du mod · dans un terminal ; pour Codex, codex au lieu de claude ; dans l'application de bureau, ouvrez ce même dossier. · `cd mon_mod` · `claude` · Écrire le point d'entrée · à la racine, sur le squelette plus bas ; pour Claude Code, un CLAUDE.md ; pour Codex, un AGENTS.md ; dans Claude Code, /init en propose un premier jet à corriger. · `CLAUDE.md` · `AGENTS.md` · Régler les autorisations · au début, qu'il vous demande avant chaque commande ; dans Claude Code : /permissions. · Le point d'entrée oriente l'agent, il ne verrouille rien : un interdit sûr se règle dans ses autorisations. · Brancher RPFM · lancer rpfm_server.exe ; l'ajouter à l'agent depuis un autre terminal ; rouvrir l'agent ; vérifier avec /mcp (détail plus bas). · Première consigne, en lecture seule · « Décris-moi mon pack sans rien modifier, et dis d'où tu tiens chaque information. » · Jugez la réponse avant toute écriture. Sept gestes avant la première vraie tâche : une copie pour revenir en arrière, l'agent dans le dossier du mod, un point d'entrée, des autorisations, RPFM branché, et une première consigne qui ne modifie rien. 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](https://code.claude.com/docs/en/setup) ou [Codex](https://learn.chatgpt.com/docs/codex/cli). 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.** *Schéma : Sans fenêtre d'abord.* Dans le schéma : Sans fenêtre d'abord · L'IA à l'écran · d'abord, se demander ce que l'écran apprendrait que le disque ne donne pas ; personne ne touche au PC ; après, vérifier le clavier. · seulement avec votre accord · Vous : à la main · Terry : peindre, poser les objets ; le jugement en jeu. · Vous : un clic · BOB : Start, ou Process with BOB dans Terry ; CAIME : importer une couche (Tools → Import → Layer data). · L'IA seule, sans fenêtre · fichiers, tables XML, rules.bob, couches .hex_layer écrits par script ; RPFM par MCP ; CAIME : process et validate. · à préférer · plus lent, plus risqué Plus on monte, plus c'est lent et risqué : ce qui peut se faire sans fenêtre ne se fait pas à l'écran. - **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](https://bretonia.dev/atelier/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](https://bretonia.dev/atelier/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 `\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](https://bretonia.dev/atelier/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](https://bretonia.dev/atelier/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](https://bretonia.dev/atelier/outils/)) > **Et prendre l'écran ?** : Certaines IA savent piloter la souris et le clavier. C'est lent, et risqué si vous vous servez du PC en même temps : une nuit, après une séance de pilotage, Windows croyait la touche AltGr enfoncée. Règle : l'IA demande avant de prendre l'écran, se demande d'abord ce que l'écran lui apprendrait que le disque ne donne pas, et vérifie l'état du clavier après. ### Brancher RPFM, pas à pas *Schéma : Brancher RPFM par MCP.* Dans le schéma : Brancher RPFM par MCP · Votre agent · Claude Code ou Codex · RPFM 5 · rpfm_server.exe · MCP · appel · réponse · MCP (Model Context Protocol) : la prise standard par laquelle un agent appelle les commandes d'un outil. RPFM les offre sur votre machine, à l'adresse 127.0.0.1:45127. · Lancer le serveur · sans argument ; il s'arrête avec la dernière session : relancez-le avant chaque séance. · `rpfm_server.exe` · L'ajouter à l'agent · dans un terminal, pas dans la conversation : Claude Code (une seule ligne) · `claude mcp add --transport http` · `rpfm http://127.0.0.1:45127/mcp` · Codex (une seule ligne) · `codex mcp add rpfm --url` · `http://127.0.0.1:45127/mcp` · Vérifier · rouvrez la session, tapez /mcp : rpfm doit être connecté, avec ses outils. · Avant le premier appel · « Lis d'abord la ressource Initialization guide du serveur : elle donne l'ordre des appels. » RPFM offre ses commandes sur votre machine ; l'agent les appelle par MCP. Quatre gestes : lancer, ajouter, vérifier, puis lire la ressource qui donne l'ordre des appels. Les commandes à recopier sont juste en dessous ; les pièges, dans le guide RPFM. 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. *Schéma : Une séance, cinq livres.* Dans le schéma : Début de séance : lire · l'agent · CLAUDE.md · chargé d'office · Journal · des erreurs · Le guide · Passations · lus parce que CLAUDE.md le demande · Journaux · datés · au besoin · Fin de séance : écrire · l'état du projet, quand il change · → CLAUDE.md · une erreur comprise, le jour même, avec sa règle · → Journal des erreurs · une découverte, avec sa preuve · → Le guide · où en est un chantier qui change de mains · → Passations · les preuves : sorties d'outils, mesures, captures · → Journaux datés · Ce qui n'est pas écrit est perdu à la séance suivante. Au début d'une séance, l'agent charge le point d'entrée, qui lui fait lire dans l'ordre les règles du journal des erreurs, le guide et la passation de son chantier ; les journaux datés au besoin. À la fin, chaque chose va dans son livre. | Fichier | Ce qu'il contient | |---|---| | `CLAUDE.md` (ou `AGENTS.md` pour Codex) | le point d'entrée, lu à chaque session : l'état du projet, **les décisions à ne pas rediscuter**, qui fait quoi, les recettes, les règles | | le journal des erreurs | chaque erreur : ce qui a été fait, le symptôme, la cause, la règle | | le guide technique | le savoir établi : formats, chaînes d'outils, pièges numérotés, avec leurs preuves | | les passations | quand un chantier change de mains : où on en est, ce qui reste, ce qu'il ne faut pas refaire | | les journaux datés | les preuves : sorties d'outils, mesures, captures | 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. *Schéma : Un texte, deux agents.* Dans le schéma : Un texte, deux agents · Codex · lit AGENTS.md avant tout travail · Claude Code · lit CLAUDE.md au début de chaque session · `CLAUDE.md` · `@AGENTS.md` · puis ce qui ne vaut que pour Claude · `AGENTS.md` · le texte commun : l'état, les décisions, qui fait quoi, les recettes, les règles · Le lit de lui-même · L'importe au démarrage · Sans CLAUDE.md, les versions récentes de Claude Code lisent AGENTS.md directement. · Une phrase n'est pas un import · `CLAUDE.md` · « Lis AGENTS.md. » · Claude Code n'ouvre alors AGENTS.md que s'il le décide. Un seul texte pour les deux agents : AGENTS.md, que Codex lit de lui-même, et que Claude Code importe par la ligne @AGENTS.md de son CLAUDE.md. Une phrase qui demande de le lire ne vaut pas un import. É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 *Schéma : Quatre sessions, un chantier.* Dans le schéma : Quatre sessions, un chantier · Les ressources communes · L'Assembly Kit : un préavis d'au moins 5 minutes ; l'heure est calculée par un script. · 14 h 00 · on annonce : « à 14 h 05 » · au moins 5 min · 14 h 05 · on écrit, pas avant · Le jeu, Terry, le startpos : on prévient les autres sessions. · Le pack : jamais reconstruit pendant un essai en jeu. · Les documents communs : un seul rédacteur ; les autres lui envoient leurs erreurs. · Un fichier neuf : vérifier d'abord que son nom est libre. · Pack et startpos · le pack, le startpos, les essais ; les documents communs · Données et scripts · les tables, les scripts, les textes · Rendu de la carte · rivières, lacs, ponts, montagnes, textures · Extension · la carte à venir, ce site · Ranger, jamais supprimer : seul l'humain supprime. Chaque session a son domaine et y écrit seule ; ce qu'elles partagent (le kit, le jeu, le pack, les documents communs) obéit à des règles écrites, que chacune relit au début de sa séance. - **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. 1. **Consigne** : le but, le critère, les interdits 2. **Travail** : scripts, tables, essais 3. **Preuve** : commande, sortie, capture 4. **Jugement** : en jeu, face à la référence 5. **Journal des erreurs** : l'erreur et sa règle Chaque erreur comprise laisse une règle écrite. La roue du chantier : on ne passe à la tâche suivante qu'avec une preuve et un jugement. ### Une bonne consigne Six lignes suffisent. Voici celle d'un essai de trente tours : *Schéma : Anatomie d'une consigne.* Dans le schéma : Consigne · But · la campagne tient 30 tours en mode · « l'IA joue tout ». · Critère · 0 plantage, 0 erreur dans le script_log. · Sources · le guide du projet, le bilan de l'essai d'hier. · Interdits · ne pas toucher au startpos ; prévenir avant de lancer le jeu. · Preuve · la commande exacte, le bilan des tours, un extrait du journal. · Témoin · le même essai sur la version d'hier, qui tenait 30 tours. Une consigne en six lignes : ce qu'on veut, comment on saura que c'est réussi, d'après quoi, ce qui est interdit, ce qu'on rapporte, et le témoin qui permet de conclure. - **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. > **Consigne floue, consigne nette** : « Répare le plantage » ne dit ni ce qui compte comme réparé, ni ce qu'il ne faut pas toucher, ni comment le prouver. La version nette tient en six lignes : c'est la figure ci-dessus. ## 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). *Schéma : D'une erreur à une règle.* Dans le schéma : Une erreur · quoi → symptôme → cause · Quelqu'un l'avait-il déjà écrite ? · oui · non · Évitable · la règle qui l'évite · Découverte · la preuve · Codée · un script qui refuse d'avancer · Le guide · le fait rejoint ses pièges : il devient évitable · si possible Chaque erreur comprise s'écrit : évitable, elle donne une règle, codée si possible dans un script qui refuse d'avancer ; découverte, elle donne une 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. *Schéma : Une règle, trois forces.* Dans le schéma : Une règle, trois forces · Verrouillée dans l'agent · ses autorisations (règles « ask », « deny ») ou un hook avant chaque commande : l'agent ne peut plus passer outre. · Claude Code : /permissions, ou .claude/settings.json ; Codex : voyez sa documentation · Codée dans un script · il refuse d'avancer : un fichier déclaré mais absent du pack, une erreur de syntaxe Lua, un startpos dont le compteur de sauvegarde ne vaut pas 1. · Écrite · dans le point d'entrée : l'agent la lit… et peut l'oublier. · « jamais de Python par heredoc » : écrite le 21 septembre, enfreinte plus de dix fois en trois jours · plus sûr Une règle écrite oriente l'agent ; codée dans un script qui refuse d'avancer, ou verrouillée dans ses autorisations, elle l'arrête vraiment. ### 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](https://bretonia.dev/blog/travailler-avec-une-ia-sur-un-gros-mod.html). ## 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é.) *Schéma : Une icône, trois versions : l'Humble Chapelle.* 1. **V1 : premier jet** : Une seule couleur, à 80 % d'opacité au plus : déjà juste, gardée. Mais un grain réparti sur toute la surface. 2. **V2 : le style** : Le trait de CA regardé au pixel : aplats pleins, bords tremblés, réserves claires continues. Le grain réparti disparaît. 3. **V3 : le lore** : « Despite the name, it's an ornate structure » (1d6chan, un wiki qui résume les livres) : deux tours, une rose, des statues, trois portails, le Graal au faîte. La forme vient d'une comparaison avec Notre-Dame ; le plan exact n'est pas décrit. L'Humble Chapelle, trois versions de nos icônes dessinées par script : la v2 corrige le style, la v3 le lore ; Charles juge chaque version. Agrandies en pixels nets (trois fois sur un grand écran), puis à leur taille réelle. 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](https://bretonia.dev/atelier/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. *Schéma : Qui décide.* Dans le schéma : Qui décide ? · L'IA le fait seule · Lire le disque, les journaux, les vidages · Écrire et corriger ses scripts, dans son domaine · Lancer ses essais sans fenêtre · Tenir les documents du projet · L'IA demande d'abord · Lancer le jeu : personne ne touche au PC pendant l'essai · Prendre l'écran, puis vérifier le clavier · Publier, poster, envoyer quoi que ce soit · Jamais à l'IA · Les mots de passe et les comptes · Supprimer : seul l'humain supprime · Le jugement final, en jeu, face à la référence · Un fait de lore sans source Trois familles de gestes : ce que l'IA fait seule, ce qu'elle demande d'abord, ce qui reste à l'humain. Dans le doute, elle demande. Au début (Premier pas, geste 5), tout passe par « demande d'abord » ; la bande verte s'élargit ensuite, dans les autorisations de l'agent. Ces règles s'écrivent dans le point d'entrée, et ce qui doit tenir à coup sûr, dans les autorisations : une règle écrite oriente, elle ne verrouille pas. ## 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](https://bretonia.dev/atelier/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](https://bretonia.dev/atelier/outils/), [CAIME](https://bretonia.dev/atelier/caime/), [RPFM](https://bretonia.dev/atelier/rpfm/), [Terry](https://bretonia.dev/atelier/terry/), [BOB](https://bretonia.dev/atelier/bob/). ## Sources et liens - Claude Code (documentation officielle) : [mémoire, CLAUDE.md et AGENTS.md](https://code.claude.com/docs/en/memory), [serveurs MCP](https://code.claude.com/docs/en/mcp), [autorisations](https://code.claude.com/docs/en/permissions), [installation](https://code.claude.com/docs/en/setup). - Codex (documentation officielle) : [AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md), [serveurs MCP](https://learn.chatgpt.com/docs/extend/mcp?surface=cli), [ligne de commande](https://learn.chatgpt.com/docs/codex/cli). - RPFM : [l'interface MCP du serveur](https://frodo45127.github.io/rpfm/manual/server/mcp.html) (manuel de RPFM). - Notre récit : [Travailler avec une IA sur un gros mod](https://bretonia.dev/blog/travailler-avec-une-ia-sur-un-gros-mod.html). - Nos autres guides : [les outils](https://bretonia.dev/atelier/outils/), [CAIME](https://bretonia.dev/atelier/caime/), [RPFM](https://bretonia.dev/atelier/rpfm/), [Terry](https://bretonia.dev/atelier/terry/), [BOB](https://bretonia.dev/atelier/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 ### Quelle IA utiliser pour modder Total War ? Charles recommande, le 23 septembre 2026, « GPT-6 et Claude 5.5 […] via Codex ou via Claude Code, avec un gros abonnement » : les sessions sont longues, et souvent plusieurs à la fois. ### Faut-il savoir programmer ? Pas pour commencer : l'agent écrit le code. Il faut en revanche savoir ouvrir un terminal et lire ce qu'une commande répond, juger en jeu, exiger des preuves et des sources, et tenir les documents du projet. ### Une IA peut-elle se servir de RPFM ? Oui : RPFM 5 a un serveur MCP (`rpfm_server.exe`, `http://127.0.0.1:45127/mcp`) par lequel une IA ouvre les packs, lit et écrit les tables, cherche et lance les diagnostics. Claude Code comme Codex s'y branchent. ### Plusieurs IA peuvent-elles travailler en même temps ? Oui, à quatre conditions : un domaine par session, un seul rédacteur par fichier, un préavis avant d'écrire dans le kit, et jamais le jeu lancé sans prévenir. ### Que mettre dans CLAUDE.md ou AGENTS.md ? L'état du projet, les décisions à ne pas rediscuter, qui fait quoi, les recettes et les règles. Le fichier est relu à chaque session ; gardez-le court (la documentation de Claude Code conseille moins de 200 lignes). Il oriente l'agent sans rien verrouiller : les interdits sûrs vont dans ses autorisations. ### L'IA peut-elle lancer le jeu et cliquer à ma place ? Oui. Exigez qu'elle vous le demande avant : écrivez-le dans le point d'entrée et, pour en être sûr, dans les autorisations de l'agent (Claude Code : une règle « ask » ou un hook) ; chez nous, la règle seulement écrite a déjà été enfreinte. Pendant l'essai, personne ne touche au PC. ### Comment vérifier ce qu'une IA affirme ? Demandez la commande, sa sortie et une capture ; faites rejouer un témoin à l'identique ; faites relire par un second agent. ### Une IA peut-elle dessiner des icônes dans le style de Creative Assembly ? Oui, par du code : des SVG dessinés par script, rendus puis retouchés au pixel, avec des critères mesurés sur les icônes du jeu, et un humain qui juge chaque version. ### Comment éviter qu'une IA répète ses erreurs ? Un journal des erreurs (fait, symptôme, cause, règle) relu à chaque session, les règles codées en garde-fous dans les scripts, et les interdits dans les autorisations de l'agent. ### Peut-on faire confiance à une IA sur le lore ? Seulement avec des sources : exigez-les, et marquez comme un choix tout ce qui n'en a pas.