Points clés
- Réalité de la fenêtre de contexte : 128K tokens sur le papier, 32K en pratique. La qualité d'attention se dégrade nettement après 32 000 tokens (~24 000 mots). Ne pas coller le manuscrit complet — utiliser la technique du document de session.
- La technique du document de session est la compétence fondamentale. Maintenir un fichier texte compressé : fiches de personnages actifs (150 mots par personnage), résumés de chapitres (100–200 mots par chapitre terminé) et configuration de la scène actuelle. Injecter au début de chaque session.
- Générer une scène à la fois. Demander au modèle d'écrire une scène (200–600 mots) plutôt que de continuer un document croissant. Une scène par session élimine la dérive de contexte.
- Beat-sheet-first pour les scénarios. Avant de générer des pages de script, générer un beat sheet par scène. Utiliser le beat sheet comme scaffold pour chaque génération de page.
- Llama 3.3 70B est le meilleur modèle pour le long format. Forte adhérence au contexte, meilleur suivi des instructions sur des générations longues, cohérence de voix sur plusieurs sessions.
- Ollama + un outil d'écriture texte brut est l'intégration la plus fiable. Scrivener, Obsidian et VS Code fonctionnent tous comme couche manuscrit ; Ollama sert le modèle via une API.
- Les modèles non censurés (Hermes 3) s'intègrent sans changements de configuration. Pour la fiction adulte, basculer le modèle Ollama vers Hermes 3 ; les techniques restent identiques.
Faits rapides
- Meilleur modèle pour la fiction longue : Llama 3.3 70B (meilleure adhérence au contexte et suivi des instructions).
- Limite pratique de la fenêtre de contexte : ~32 000 tokens (~24 000 mots) pour une qualité d'attention fiable ; 128K est le plafond technique.
- Taille du document de session : viser moins de 4 000 tokens (fiches personnages + résumés chapitres + configuration scène actuelle).
- Cible de génération de scène : 200–600 mots par appel de génération ; scènes plus longues via plusieurs prompts séquentiels.
- Format scénario : combiner Ollama avec des instructions de sortie au format Fountain pour du texte formaté screenplay.
- Outils d'écriture compatibles Ollama : Scrivener (via scripts API compagnons), Obsidian (via plugin local ou scripts), VS Code (via Continue.dev ou appels API directs), terminal brut.
- Option non censurée : Hermes 3 Llama 3.3 pour la fiction adulte ; même workflow, même technique du document de session.
Le problème de la fenêtre de contexte pour l'écriture longue
La limite pratique de contexte de la plupart des modèles locaux est de 32 000 tokens — pas les 128K annoncés. La qualité d'attention se dégrade après 32 000 tokens. À 128K tokens, beaucoup de modèles perdent la référence précise au contenu du premier quart de la fenêtre. Pour un roman, cela signifie qu'on ne peut pas simplement coller le manuscrit en cours et demander le chapitre suivant.
Kimi-K2.6 de Moonshot AI offre une véritable fenêtre de 1 million de tokens avec une meilleure préservation de la qualité d'attention. Exécuter Kimi-K2.6 localement est impraticable pour la plupart des auteurs — il requiert environ 480 Go de VRAM en quantisation Q4. Pour les auteurs ayant besoin de 1M de contexte, l'API hébergée de Moonshot est l'option pratique. Pour les modèles exécutables localement (Llama 3.3 70B, Qwen3 32B, Mistral Large), le plafond pratique de 32K est la contrainte pertinente.
📍 En une phrase
Le plafond pratique de qualité pour l'adhérence au contexte dans la plupart des LLM locaux est d'environ 32 000 tokens (~24 000 mots) — au-delà, les modèles perdent la référence précise au contenu antérieur, causant dérive de voix et incohérences de plot.
💬 En termes simples
On ne peut pas charger un roman de 90 000 mots dans une fenêtre de 128K et espérer que le modèle se souvienne de ce qui s'est passé au chapitre 3 en écrivant le chapitre 20. À la place : compresser ce que le modèle doit savoir — fiches personnages, résumés de chapitres, configuration de la scène actuelle — dans un document de session de moins de 4 000 tokens, et l'injecter au début de chaque session.
- Conversion token-mot : 1 token ≈ 0,75 mot en anglais. 32K tokens ≈ 24 000 mots. 128K tokens ≈ 96 000 mots (un roman complet).
- Dégradation de l'attention : les modèles perdent la référence fiable au contenu du début d'une longue fenêtre — erreurs de noms de personnages, points de plot oubliés, dérive de voix.
- L'asymétrie : les modèles traitent le mieux le début (system prompt) et la fin du contexte. Le contenu au milieu d'un long contexte est le moins fiablement traité.
- Document de session comme solution : compresser tout ce dont le modèle a besoin dans un court document structuré. Injecter au début. Générer la scène. Terminer la session. Réinitialiser. Recommencer avec le document mis à jour.
⚠️Warning: Ne pas coller le manuscrit complet dans le contexte. Au-delà de 10 000 mots, la dérive de contexte s'installe — le modèle oublie les détails de personnages, contredit les points de plot et régresse vers un registre générique. Utiliser la technique du document de session.
Technique du document de session
La technique du document de session présentée ici a été testée sur plusieurs projets longs (un roman littéraire de 90 000 mots, deux scénarios). La taille de 4 000 tokens, le rythme scène par scène et le timing des vérifications de continuité découlent de modes d'échec observés pendant ce travail.
Le document de session est un fichier texte brut maintenu à côté du manuscrit — l'état compressé du roman que le modèle doit connaître pour générer du contenu cohérent. Il comporte trois sections : fiches de personnages actifs, résumés de chapitres et configuration de la scène actuelle.
Modèle de document de session
“# SESSION DOCUMENT — [NOVEL TITLE] ## ACTIVE CHARACTERS **[Character Name]** Dominant trait: [one trait] Contradicting behaviour: [one behaviour] Speech register: [formal/casual/specific verbal tics] Relationship to [other character]: [brief] **[Character Name 2]** [same structure] ## CHAPTER SUMMARIES (completed) Chapter 1: [100–150 words — what happened, what changed, where it ended] Chapter 2: [100–150 words] [continue for all completed chapters] ## CURRENT SCENE SETUP Chapter: [N] Scene: [brief description of what this scene needs to accomplish] POV: [character name] Opening state: [where we are at the start of this scene — 1 sentence] Emotional beat to land on: [what the POV character feels at the end — do not state it directly in the scene] Word ceiling: [200–500 words]”
- Fiches de personnages — cible 150 mots par personnage actif. Inclure trait dominant, comportement contradictoire, registre de parole et relation clé aux autres personnages actifs.
- Résumés de chapitres — cible 100–150 mots par chapitre terminé. Focus sur : ce qui s'est passé, ce qui a changé dans les relations, ce que le lecteur sait maintenant, où le chapitre s'est terminé spatialement et émotionnellement.
- Configuration de la scène actuelle — spécifique et bref. Nommer le PDV, le but de la scène, le beat émotionnel à atteindre et le plafond de mots. C'est l'action que le modèle exécute.
- Taille du document — cible moins de 4 000 tokens (~3 000 mots). Un document dépassant cette taille empiète sur l'espace de contexte dédié à la génération. Compresser agressivement.
- Mettre à jour après chaque session. Ajouter 1–2 phrases au résumé du chapitre et mettre à jour les fiches modifiées. Le document de session est un fichier vivant.
💡Tip: Conserver le document de session dans un fichier texte brut à côté du manuscrit. Dans Ollama, créer un Modelfile avec le document dans le bloc SYSTEM et le rafraîchir avant chaque session. Dans SillyTavern, le coller dans le champ system prompt au début de chaque session.
Workflow d'écriture de roman
Le workflow d'écriture de roman avec un LLM local comporte quatre phases : outline, beat sheets de chapitres, génération de scènes et passes de révision. Chaque phase utilise une structure de prompt différente.
- Phase 1 — Outline : générer un outline au niveau des chapitres (10–30 chapitres, une phrase par chapitre). Prompt : « Genre : [genre]. Protagoniste : [Nom + blessure fondamentale]. Conflit central : [en une phrase]. Écrire un outline de 20 chapitres — une phrase par chapitre, chaque phrase nommant la scène et le changement. » Réviser l'outline avant de continuer.
- Phase 2 — Beat sheets : développer chaque entrée de chapitre en beat sheet de niveau scène (3–8 scènes par chapitre). Prompt par chapitre : « Résumé chapitre [N] : [coller l'entrée]. Développer en beat sheet : 4–6 scènes, chacune décrite en une phrase nommant lieu, participants et le seul changement de la scène. Pas de prose encore. »
- Phase 3 — Génération de scènes : utiliser le document de session + le beat de la scène actuelle pour générer une scène à la fois. Générer, réviser, coller dans le manuscrit, mettre à jour le document de session. Répéter.
- Phase 4 — Passes de révision : après avoir terminé un chapitre, appliquer des prompts de révision ciblés sur des scènes spécifiques. Voir Prompts LLM locaux pour les auteurs de fiction. Ne jamais demander au modèle de réviser plus d'une scène par appel.
💡Tip: Conserver l'outline et les beat sheets dans des fichiers séparés du manuscrit. Ils sont le squelette — le manuscrit est la chair. Des fichiers séparés permettent de régénérer n'importe quelle partie sans écraser l'autre.
Workflow scénario
L'écriture de scénarios avec un LLM local utilise les mêmes techniques de document de session et de beat sheet, avec deux ajouts : des instructions de format dans le system prompt et la génération des en-têtes de scène (slug lines) comme étape séparée de la génération de pages.
System prompt pour scénario
“You are a screenplay formatting assistant. All prose you generate is formatted in standard US screenplay format: - Scene headers: INT./EXT. LOCATION — DAY/NIGHT - Action lines: present tense, concrete, maximum 3 lines per block - Character names: ALL CAPS above dialogue - Dialogue: centred, no dialogue tags - Parentheticals: sparingly, only for delivery or action mid-dialogue Generate in Fountain-compatible plain text.”
Prompt beat de scène vers pages de script
“Beat: [paste the one-sentence scene beat from the beat sheet] POV character: [Name] Page target: [1–3 pages] Generate the script pages for this beat. Use standard screenplay format. Begin with the slug line. No narration — action lines and dialogue only.”
- Format dans le system prompt, pas dans le tour utilisateur. Placer les instructions de format dans le message système signifie que chaque génération de la session suit le format sans répéter l'instruction.
- Sortie compatible Fountain : Fountain est un format de balisage texte brut pour scénarios supporté par Final Draft, Highland, WriterDuet et d'autres. Demander « Fountain-compatible plain text » produit une sortie importable directement dans le logiciel de scénario.
- Slug lines d'abord : générer la slug line comme prompt d'une ligne avant de générer le contenu de la scène. Cela ancre le lieu physique avant que le modèle commence.
- Passes de dialogue : après les lignes d'action, faire une passe séparée : « Les lignes d'action sont définies. Écrire le dialogue pour [Personnage A] et [Personnage B]. Personnage A veut [X]. Personnage B veut [Y]. Pas de balises de dialogue. 5–8 échanges. »
- Gestion du nombre de pages : une page de scénario standard fait environ 55–60 mots d'action et dialogue combinés. Calibrer les plafonds de mots : 1 page ≈ 60 mots, 2 pages ≈ 120 mots, 3 pages ≈ 180 mots.
💡Tip: La discipline beat-sheet-first est plus importante pour les scénarios que pour les romans. Une scène de scénario a une fonction structurelle précise et un objectif de pages. Générer des pages sans beat sheet produit des scènes qui dérivent en longueur et perdent leur fonction. Toujours savoir ce qu'une scène doit accomplir avant de générer les pages.
Templates de génération de scènes pour le long format
La génération de scènes longues nécessite le document de session comme préfixe et un seul prompt de scène comme action. Les templates ci-dessous supposent que le document de session est déjà dans le message système ou le premier tour utilisateur.
📍 En une phrase
Pour la fiction longue, le schéma de génération le plus fiable est : document de session dans le system prompt → unique prompt de scène dans le tour utilisateur → réviser → mettre à jour le document de session → répéter, une scène par session.
💬 En termes simples
Le modèle doit savoir trois choses pour écrire la scène suivante de façon cohérente : qui sont ces personnages (fiches), ce qui s'est déjà passé (résumés de chapitres) et ce que cette scène doit accomplir (configuration). Donner exactement ces trois choses, rien de plus. Générer la scène, la coller dans le manuscrit, mettre à jour le document de session. Répéter.
Prompt de génération de scène de roman
“[SESSION DOCUMENT ALREADY IN SYSTEM PROMPT] Current scene: Chapter: [N] Beat: [one sentence from the beat sheet] POV: [character name] Opening: [one sentence — where we are, who is present] Emotional landing: [what the POV character feels at the end — show, don't state] Word ceiling: [300–500 words] Write this scene. No summarising. Every sentence renders a moment.”
Prompt de vérification de continuité
“Before writing the next scene, check for continuity. The session document says: - [Character A] is [trait/state] - The last scene ended with [brief description] The next scene opens with [brief description]. Does this transition make sense? If not, what needs to change in the transition? One paragraph answer only.”
💡Tip: Utiliser le prompt de vérification de continuité aux transitions de chapitres — pas à chaque scène. Les transitions de chapitres (où le lieu, le temps ou le personnage PDV change) sont l'endroit où les ruptures de continuité sont les plus fréquentes.
Intégrations d'outils pour les auteurs
Ollama expose une API compatible OpenAI sur localhost qu'un écosystème croissant d'outils orientés auteurs connecte. Les intégrations ci-dessous représentent les options les plus établies.
| Outil | Intégration | Idéal pour |
|---|---|---|
| Obsidian | Plugin Copilot ou Smart Connections → API Ollama. Voir Obsidian + Plugins LLM locaux pour le guide approfondi. | Auteurs utilisant déjà Obsidian pour les notes + manuscrit ; génération dans la même appli sans changer de contexte |
| Scrivener | Script externe via API Ollama → coller dans le document | Auteurs structurant leurs romans dans Scrivener ; brouillons IA collés dans la structure de projet existante |
| VS Code | Extension Continue.dev → backend Ollama | Auteurs techniques et concepteurs de narration de jeux à l'aise dans un éditeur de code |
| SillyTavern | API compatible OpenAI → Ollama | Fiction roleplay et rédaction guidée par fiches personnages ; mémoire de personnage persistante |
| Terminal brut | `ollama run [model]` ou curl vers l'API Ollama | Workflows scriptables ; contrôle maximal avec overhead d'interface minimal |
| LM Studio | Interface de chat intégrée + API serveur local | Auteurs souhaitant un gestionnaire de modèles GUI sans installer Ollama séparément |
| NovelCrafter | Intégration IA intégrée ; supporte les endpoints compatibles OpenAI (pointer vers Ollama) | Auteurs souhaitant une assistance IA au niveau chapitre dans une seule app dédiée au roman |
| Plottr | Workflow manuel : structurer les romans dans Plottr, coller scènes/beats dans Ollama en externe | Fiction de genre à plot dense (polar, thriller, fantasy) où la structure narrative est le cœur du workflow |
💡Tip: L'intégration la plus simple pour la plupart des auteurs : Obsidian + le plugin Copilot pointant vers Ollama. Le document de session, les chapitres du manuscrit et la génération dans la même appli sans changement de contexte. Voir Obsidian + Plugins LLM locaux pour le guide approfondi.
Recommandations de modèles pour le long format
Le long format a des exigences différentes de la fiction courte. L'adhérence au contexte, la cohérence du suivi des instructions sur des sessions longues et la capacité à maintenir la voix sur plusieurs appels de génération sont les facteurs décisifs. Pour le panorama complet des modèles, voir Meilleurs LLM locaux en 2026.
| Tâche | Modèle recommandé | Pourquoi |
|---|---|---|
| Rédaction de roman (principal) | Llama 3.3 70B | Meilleure adhérence au contexte et suivi des instructions pour le long format multi-sessions ; voix la plus cohérente |
| Écriture de scénarios | Llama 3.3 70B ou Mistral Large | Llama 3.3 pour les dynamiques de personnages complexes ; Mistral Large pour l'adhérence au format Fountain |
| Génération de beat sheet / outline | Qwen3 32B | Forte génération structurelle ; suit fiablement les prompts d'outline à contraintes multiples |
| Passes de dialogue | Command R+ 104B | Meilleur registre de parole naturel et différenciation des voix de personnages sur des échanges longs |
| Révision (structurelle) | Llama 3.3 70B | Meilleur pour suivre des contraintes structurelles nommées dans les instructions de réécriture |
| Fiction adulte / sombre | Hermes 3 Llama 3.3 70B | Même base que Llama 3.3 70B ; fine-tune non censuré ; adhérence au contexte identique pour le long format |
Erreurs fréquentes
- Coller le manuscrit complet dans le contexte. Même avec une fenêtre de 128K tokens, la qualité d'attention se dégrade significativement après 32 000 tokens. Utiliser la technique du document de session.
- Demander au modèle de « continuer » un document ouvert. « Continue le roman » produit de la dérive. « Écris la scène suivante : [configuration spécifique, PDV, plafond de mots] » produit une sortie bornée et cohérente.
- Pas de beat sheets pour les scénarios. Générer des pages sans beat sheet produit des scènes qui dérivent en longueur et perdent leur fonction structurelle. Générer le beat sheet en premier, toujours.
- Ignorer les mises à jour du document de session. Un document de session obsolète produit des incohérences en quelques sessions.
- Générer plus d'une scène par session. La génération multi-scènes dans une fenêtre produit la première scène correctement et chaque suivante avec moins de cohérence. Une scène par session ; réinitialiser et réinjecter.
Sources
- Benchmarks long contexte Llama 3.3 70B — Meta AI Research
- Rapport technique Qwen3 32B incluant benchmarks fenêtre de contexte — Alibaba Cloud / Qwen Team
- Lost in the Middle: How Language Models Use Long Contexts — Stanford NLP Research
- Spécification du format Fountain pour scénarios — Fountain.io
- Documentation API Ollama — Ollama
Questions fréquemment posées
Un LLM local peut-il écrire un roman complet ?
Un LLM local peut générer la prose d'un roman complet — mais l'intelligence structurelle et éditoriale doit venir de l'auteur. Le modèle génère des scènes quand on lui fournit des configurations spécifiques ; il ne planifie pas, n'évalue pas et ne prend pas de décisions thématiques de façon autonome. Les auteurs qui utilisent des LLM locaux comme outils de rédaction les décrivent comme « un générateur de premier brouillon très rapide pour des scènes que je sais déjà comment écrire ».
Quelle est la fenêtre de contexte maximale utilisable de façon fiable ?
En pratique, compter sur une qualité d'attention fiable jusqu'à environ 32 000 tokens (~24 000 mots) avec la plupart des modèles locaux. Au-delà, les modèles commencent à perdre la référence précise au contenu du début du contexte. La technique du document de session maintient le contexte de travail sous 4 000–6 000 tokens.
Comment empêcher le modèle de changer la voix de mon personnage en cours de roman ?
La dérive de voix a deux causes : un document de session obsolète et la dilution du contexte. Solution : placer la fiche de personnage dans le message système, la mettre à jour après chaque scène avec un moment d'arc significatif, et la garder concise.
Puis-je utiliser Scrivener avec un LLM local ?
Pas nativement — Scrivener n'a pas de système de plugin pour les appels API externes. Le workflow le plus courant : générer dans Ollama (via terminal ou script compagnon), copier la sortie, la coller dans le document Scrivener pertinent. Certains auteurs utilisent Obsidian comme couche de rédaction IA et importent les chapitres terminés dans Scrivener.
Qu'est-ce qui est mieux pour les scénarios : Ollama ou une IA cloud ?
Pour les scénaristes devant générer du contenu adulte (violence, psychologie sombre, personnages moralement complexes), Ollama local avec Llama 3.3 70B ou Hermes 3 est plus fiable — les modèles cloud refusent du contenu qui apparaît fréquemment dans les scripts dramatiques. Pour la cohérence du format, les deux sont équivalents avec des instructions de format dans le system prompt.
Comment générer du dialogue qui ressemble à un personnage spécifique ?
Approche en trois étapes : (1) Ajouter le registre de parole du personnage au document de session. (2) Générer 3–5 lignes de dialogue d'exemple comme étape de calibration en début de session. (3) Utiliser ces lignes d'exemple dans le prompt de dialogue : « Écrire du dialogue dans le même registre que ces exemples : [coller]. »
Ai-je besoin d'un GPU pour utiliser un LLM local pour la rédaction de roman ?
Un GPU accélère significativement mais n'est pas requis. Sur Apple Silicon (M3 ou ultérieur), même un MacBook Pro 16 Go peut faire tourner Qwen3 14B pour la rédaction — plus lent qu'un rig GPU 24 Go mais acceptable pour un workflow d'écriture. Un GPU NVIDIA dédié avec 24 Go de VRAM fait tourner les modèles 70B à des vitesses utilisables.
Puis-je utiliser des LLM locaux avec Final Draft ou d'autres logiciels de scénario professionnels ?
Pas directement. Final Draft n'a pas d'intégration API externe. Le workflow : générer les pages de script au format Fountain via Ollama, puis importer le fichier Fountain dans Final Draft via son importateur intégré (Fichier → Importer → Fountain). Highland, WriterDuet et Fade In supportent l'import Fountain nativement.
Puis-je utiliser Kimi-K2.6 localement pour la rédaction de roman ?
Kimi-K2.6 a une véritable fenêtre de 1 million de tokens — utile pour du travail en une seule passe sur la longueur d'un roman — mais est impraticable à exécuter localement pour la plupart des auteurs (~480 Go de VRAM en quantisation Q4). Pour les workflows entièrement locaux, la technique du document de session avec des modèles exécutables localement gère le travail de longueur roman.
Quelle est la position des éditeurs sur les manuscrits assistés par IA ?
Mitigée et en évolution. La plupart des grands éditeurs de fiction exigent une divulgation de l'usage substantiel de l'IA dans les manuscrits soumis ; certains l'interdisent totalement. Les plateformes d'auto-publication exigent une attestation pour le contenu généré par IA. Les auteurs utilisant des LLM locaux comme assistants de rédaction avec révision humaine substantielle décrivent l'IA comme un outil plutôt qu'un co-auteur. Vérifier la politique spécifique de l'éditeur avant soumission.
Dois-je respecter le RGPD en utilisant un LLM local pour écrire des romans ou des scénarios ?
Avec des modèles entièrement locaux (Ollama sur son propre matériel, pas d'API cloud), aucune donnée personnelle n'est transmise à des serveurs externes — les exigences du RGPD pour les transferts de données (Art. 28) ne s'appliquent pas. Si des données personnelles de personnes réelles entrent dans les prompts, les principes du RGPD (minimisation des données, limitation des finalités) peuvent s'appliquer. Pour la fiction fictive sans lien avec des personnes réelles, les workflows LLM entièrement locaux ne posent généralement pas de problème RGPD.
Quelles restrictions légales s'appliquent en France à l'écriture de contenus à caractère sexuel ou violent avec un LLM local ?
Pour la fiction adulte légale avec des scénarios consentis entre personnages adultes, il n'existe pas de restrictions spécifiques à l'IA en France. L'article 227-23 du Code pénal interdit les représentations de mineurs à caractère pornographique — cela s'applique indépendamment du fait qu'un humain ou un modèle IA génère le texte. Pour les contenus violents, le droit pénal général s'applique. La responsabilité juridique incombe à l'utilisateur.