# Agents IA et écriture assistée : repenser l’assistant littéraire au-delà du traitement de texte
Le marché des outils d’écriture assistée par IA pèse déjà plusieurs milliards de dollars et ne cesse de croître. Pourtant, un examen attentif révèle un trou béant : aucun outil existant ne combine mémoire persistante, orchestration multi-agent, automatisation des workflows, open source et absence de lock-in. Cet article explore ce que serait un assistant d’écriture repensé à partir d’une architecture d’agent orchestrateur — et pourquoi personne ne l’a encore construit.
Pour les antis, songez à ce sacrilège qu’a été l’invention de la gomme, cet objet du diable qui permet si facilement de cacher ses erreurs !
On parle souvent de l’IA et des systèmes agentiques comme de futurs remplaçants de l’humain — y compris dans le domaine de la création littéraire. Pour ma part, j’y vois plutôt des assistants, chargés des tâches que l’on pourrait qualifier de subalternes.
J’ai eu tout au long de ma vie des velléités d’écriture. J’ai « pondu » à plusieurs reprises quelques centaines de pages. Pourquoi ne suis-je pas allé plus loin ? Paresse, sentiment de ne pas être assez bon… Dès que j’en ai eu la possibilité, j’ai eu recours à des assistants — ne serait-ce qu’une machine à écrire ou un traitement de texte (y compris le tout premier Word, et même avant), jusqu’à des logiciels dédiés comme Scrivener.
Car écrire est un travail d’imagination, mais aussi un travail technique. Des personnages, des lieux, des temporalités à gérer et, surtout dans le domaine de la non-fiction, des sources. C’est surtout en cela que Scrivener, Manuskript et leurs semblables font le travail. Et c’est là aussi qu’un agent IA peut être capital : maintenir une cohérence temporelle, veiller à ce que la personnalité ou le physique d’un personnage reste cohérent, documenter un lieu visité, effectuer des recherches sur celui-ci ou sur un événement historique, retrouver des citations. Et tout ce qu’il reste à imaginer — ce que j’essaye de faire, un peu, ici.
Alors plutôt que de voir cette nouvelle technologie comme un concurrent, je choisis d’y voir un outil, un facilitateur.
1. Le paysage actuel : des outils nombreux, des promesses inégales
1.1 Les traitements de texte classiques et leurs extensions IA
Le traitement de texte est un logiciel vieux de plusieurs décennies. Word, LibreOffice, Google Docs, OnlyOffice — tous ont ajouté des fonctionnalités d’IA, mais en surface, comme une couche rapportée.
Microsoft 365 Copilot est l’exemple le plus abouti. Son architecture repose sur le Graph API de Microsoft : le prompt utilisateur est envoyé à un LLM (GPT-4) avec le contexte du document, et les suggestions sont injectées dans l’interface. Copilot peut générer, résumer, réécrire, et même créer un premier jet à partir de notes. Mais il reste limité à la session en cours — pas de mémoire persistante, pas de vérification de cohérence entre chapitres, pas de gestion d’univers fictionnel. Et il est prisonnier de l’écosystème Microsoft 365, avec un abonnement à $30/utilisateur/mois en sus de la licence Office.
Google Docs + Gemini suit la même logique : une IA intégrée qui peut « vous aider à écrire », réécrire des passages, générer des listes à puces. L’architecture est similaire : Apps Script côté Google, Gemini côté LLM. Mêmes limitations : pas de mémoire long terme, pas de vérification de cohérence, dépendance totale à l’écosystème Google.
LibreOffice n’a pas d’intégration IA officielle. Des projets communautaires existent (LocalAI, Ollama en script), mais rien de mature. Son avantage est d’être open source et extensible via l’API UNO (Universal Network Objects), qui permet un contrôle total du document en Python, Java ou C++. C’est le traitement de texte le plus « programmable » — mais personne n’a encore écrit l’extension IA qui exploite vraiment cette capacité.
OnlyOffice propose une API JavaScript pour ses plugins, similaire à Office.js. Un plugin IA pourrait y être développé, mais la communauté est trop petite pour qu’un projet mature émerge.
1.2 Les logiciels dédiés à l’écriture de fiction
Scrivener reste la référence pour les auteurs de romans, nouvelles et scénarios. Son corkboard, son outline, son système de snapshots, son compile multi-format en font un outil inégalé pour organiser un projet d’écriture long. Mais Scrivener n’a pas d’IA — et son format de fichier propriétaire (.scriv) le rend difficile à étendre.
Manuskript est l’alternative open source la plus connue. Écrit en Python/PyQt5, il offre une structure similaire à Scrivener : parties, chapitres, scènes, fiches personnages, intrigues, export multi-format. Son format de projet (.msk) est un JSON compressé, donc lisible et modifiable. Mais Manuskript n’a pas d’API plugin, pas de système d’extension, pas de hooks d’événements. Pour y ajouter une couche IA, les options sont :
1. Fork — copier le code, ajouter un système de plugins et une API HTTP. Effort élevé, maintenance lourde.
2. Pont externe — un watcher qui surveille les fichiers .msk et agit en parallèle. Fonctionnel, mais pas d’interaction en temps réel depuis l’UI.
3. Scripts utilisateur — Manuskript permet d’exécuter des commandes système. Solution pragmatique : un bouton → script → IA → retour.
novelWriter (par vkbo) est un autre logiciel open source, écrit en Python/PyQt6. Son format de projet en fichiers texte brut (.nw) est plus facile à manipuler qu’un JSON compressé. Mêmes limitations : pas d’API plugin.
Note : Il existe un projet distinct appelé NovelWriter (par EdwardAThomson) qui est spécifiquement conçu pour l’IA — interface Tkinter, génération de lore, d’intrigues, d’univers via LLM. C’est un signe que la demande existe, mais le projet est récent et peu mature.
1.3 Les AI writing tools SaaS
Le marché des outils d’écriture assistée par IA est dominé par des acteurs SaaS :
| Outil | Modèle | Prix | Architecture | Lock-in |
|---|---|---|---|---|
| Sudowrite | SaaS | $20-50/mois | Modèle propriétaire Muse (fine-tuné sur fiction) | Élevé — données sur leurs serveurs, format propriétaire |
| NovelCrafter | SaaS | $10-30/mois | BYOK (vos clés API) + couche d’orchestration | Moyen — données sur leurs serveurs mais BYOK |
| Lex (lex.page) | SaaS | Freemium | IA intégrée, éditeur minimaliste | Élevé — tout chez eux |
| Jasper | SaaS | $49-99/mois | Multi-modèle, orienté marketing | Élevé — pas fait pour la fiction longue |
| OpenWrite | Open source | Gratuit (auto-hébergé) | BYOK, pas d’abonnement | Aucun — vous contrôlez tout |
Sudowrite est le leader du marché de la fiction. Son modèle propriétaire Muse est fine-tuné exclusivement sur des romans et nouvelles, ce qui lui donne un style plus littéraire que les LLM généralistes. Ses fonctionnalités sont impressionnantes : génération de scènes, réécriture, développement sensoriel, brainstorming, beat sheet. Mais c’est une boîte noire : vos données sont sur leurs serveurs, votre manuscrit dans leur format, et vous ne pouvez pas changer de modèle sans tout réécrire.
NovelCrafter adopte une approche plus ouverte : vous apportez vos propres clés API (OpenAI, Claude, etc.). Leur valeur ajoutée est la couche d’orchestration : organisation du projet, gestion du contexte, prompts spécialisés. C’est plus flexible que Sudowrite, mais vos données transitent toujours par leurs serveurs, et la mémoire long terme reste limitée.
OpenWrite est le projet le plus prometteur du côté open source. Il se présente comme une alternative à Sudowrite et NovelCrafter, avec BYOK, auto-hébergement, et zéro abonnement. Son architecture est celle d’une web app (probablement React/Node.js + backend Python). Il prouve qu’il y a une demande pour une solution ouverte — mais il est récent et n’a pas encore la maturité des acteurs établis.
1.4 Les formats spécialisés
Fountain est un format de balisage pour scénarios, comparable à Markdown. Il permet d’écrire des scripts de film, pièces de théâtre, séries TV en texte brut, avec une syntaxe simple (INT./EXT., PERSONNAGE, dialogue, parenthèses). Fountain est lisible par des humains, convertible en formats professionnels (Final Draft, PDF), et parfaitement adapté à une manipulation par un agent IA. C’est un exemple de format ouvert qui facilite l’intégration — contrairement aux formats propriétaires des outils SaaS.
2. Les limites des approches actuelles
2.1 Pas de mémoire persistante
Tous les outils actuels fonctionnent en « prompt → réponse ». Le LLM reçoit le contexte immédiat (le paragraphe en cours, parfois le chapitre) et génère une réponse. Mais il n’a pas de mémoire de ce qui a été écrit 50 pages plus tôt. Résultat : des incohérences (couleur des yeux d’un personnage qui change, chronologie qui se contredit, nom d’un lieu qui varie).
Sudowrite et NovelCrafter tentent de pallier cela avec des « story bibles » ou des « character sheets » — des fichiers de référence que le LLM reçoit dans son contexte. Mais ces fichiers sont statiques, mis à jour manuellement, et limités par la taille du contexte du LLM (128k tokens pour Claude, 200k pour GPT-4 — insuffisant pour un roman de 100 000 mots).
2.2 Pas d’orchestration multi-agent
Chaque outil utilise un seul LLM (ou un seul appel à un LLM) par requête. Il n’y a pas de spécialisation : le même modèle qui génère un dialogue doit aussi vérifier la cohérence, compter les mots, chercher des informations, et formater le texte. C’est comme demander à un seul artisan de construire une maison entière — fondations, plomberie, électricité, toiture — sans équipe.
2.3 Pas d’automatisation
Les outils sont réactifs : l’utilisateur clique sur un bouton, l’IA répond. Rien n’est automatisé. Pas de relecture automatique après chaque sauvegarde, pas de vérification de cohérence programmée, pas de rapport de progression hebdomadaire, pas d’alerte en cas de contradiction détectée.
2.4 Lock-in et perte de contrôle
Sudowrite, NovelCrafter, Lex, Jasper — tous vous enferment dans leur écosystème. Vos données sont sur leurs serveurs. Votre manuscrit est dans leur format. Si vous voulez changer d’outil, vous devez exporter et réimporter — avec perte de métadonnées (fiches personnages, structure, notes). Si l’outil ferme ou augmente ses prix, vous êtes pieds et poings liés.
Même NovelCrafter, qui permet le BYOK, stocke vos données sur ses serveurs. Vous ne contrôlez pas où va votre texte.
2.5 Coût
Écrire un roman de 100 000 mots avec un LLM via API coûte entre $50 et $200 selon le modèle utilisé. Les abonnements SaaS ajoutent $10-100/mois par-dessus. Pour un auteur amateur ou un petit éditeur, c’est un budget significatif — d’autant que le résultat n’est pas garanti.
3. Ce que permettrait une architecture d’agent orchestrateur
3.1 Principe général
Un agent orchestrateur n’est pas un énième AI writing tool. C’est une architecture différente, qui sépare les responsabilités :
┌─────────────────────────────┐
│ Agent orchestrateur │
│ (planification, routage) │
└──────────┬──────────────────┘
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ LLM(s) │ │Mémoire │ │ Outils │
│(génér.)│ │(cohér.)│ │(rech., │
└────────┘ └────────┘ │ export)│
└────────┘L’orchestrateur reçoit une demande, consulte la mémoire, choisit le ou les LLMs appropriés, invoque les outils nécessaires, vérifie le résultat, et le restitue. Chaque composant est spécialisé et interchangeable.
3.2 Mémoire persistante du monde fictionnel
C’est la différence fondamentale. Au lieu d’un fichier statique « bible du roman », l’agent maintient une base de connaissance dynamique — un graphe de faits qui évolue avec l’écriture :
(personnage:JeanValjean, a_pour_trait, altruiste)
(personnage:JeanValjean, a_pour_yeux, gris)
(lieu:Sorède, est, village_catalan)
(chapitre:5, se_passe_à, Sorède)
(objet:pain, est, symbole_rédemptiontion)
(relation:JeanValjean, rencontre, Myriel, chapitre:1)
Chaque fait est horodaté, sourcé, et peut être interrogé. Quand l’agent écrit un nouveau passage, il peut vérifier en temps réel qu’il ne contredit pas la mémoire existante. Quand l’utilisateur ajoute une information, elle est immédiatement disponible pour tous les agents.
Cette mémoire peut être :
- Peuplée automatiquement — l’agent extrait les faits du texte au fur et à mesure
- Interrogée en langage naturel — « où est-ce que j’ai mentionné la couleur des yeux de Jean ? »
- Vérifiée — l’agent peut signaler les contradictions potentielles
- Partagée — entre plusieurs agents, entre plusieurs sessions, entre plusieurs utilisateurs
3.3 Orchestration multi-agent
Au lieu d’un seul LLM qui fait tout, l’orchestrateur déploie des agents spécialisés :
| Agent | Rôle | Modèle recommandé |
|---|---|---|
| Brouillon | Écrire le premier jet, ne pas s’arrêter pour peaufiner | LLM rapide, haute générativité |
| Relecteur | Corriger, reformuler, améliorer le style | LLM précis, bon en français |
| Cohérence | Vérifier les faits contre la mémoire | LLM + base de connaissance |
| Cartographe | Maintenir la bible de l’univers | Agent dédié, pas de LLM lourd |
| Chercheur | Aller chercher des sources externes | LLM + recherche web |
| Structure | Analyser le rythme, le pacing, l’arc narratif | LLM spécialisé en narratologie |
Chaque agent peut être invoqué indépendamment, en parallèle, ou en séquence. Le brouillon écrit un chapitre pendant que le cartographe met à jour la bible et que le chercheur vérifie un point historique.
3.4 Automatisation des workflows
L’agent peut être proactif, pas seulement réactif :
- Relecture automatique après chaque sauvegarde
- Vérification de cohérence programmée (tous les soirs à 20h)
- Rapport de progression hebdomadaire (nombre de mots, chapitres terminés, incohérences détectées)
- Suggestion de direction quand l’utilisateur n’a pas écrit depuis 48h
- Export automatique vers le format de publication (epub, docx, pdf)
- Sauvegarde versionnée dans un dépôt git
Ces workflows sont configurables, combinables, et peuvent être déclenchés par des événements (sauvegarde, seuil de mots, inactivité) ou par une planification (cron).
3.5 Absence de lock-in
L’architecture repose sur des formats ouverts et des composants interchangeables :
- Fichiers : Markdown (source de vérité), avec export vers .docx, .odt, .epub, .pdf via Pandoc
- Modèles : BYOK — vos clés API, ou LLM local (Ollama, llama.cpp)
- Mémoire : base de connaissance standard (SQLite, graphe), exportable, portable
- Agents : skills interchangeables, scripts personnalisables
- Interface : n’importe quel client (messagerie, web, terminal, plugin éditeur)
Vous pouvez changer de LLM, d’interface, d’hébergement — vos données et votre structure restent intactes.
4. Les architectures d’intégration possibles
4.1 Plugin dans le traitement de texte
[Traitement de texte] ←→ [Plugin/Add-in] ←HTTP→ [Agent IA]L’utilisateur reste dans son environnement familier (Word, LibreOffice, Google Docs). Un plugin ajoute un bouton, un panneau latéral, des commandes. L’agent reçoit le texte, consulte sa mémoire, retourne suggestions, corrections, générations.
Qui peut le faire :
- Word — Office.js (JavaScript, WebView embarqué). API complète : lecture/écriture du document, événements, panneaux latéraux, ruban personnalisé.
- LibreOffice — UNO API (Python, Java, C++). Contrôle total du document, écoute d’événements, menus, barres d’outils. Le plus puissant mais le plus verbeux.
- OnlyOffice — JavaScript API. Similaire à Office.js, open source, auto-hébergeable.
- Google Docs — Apps Script (JavaScript Google). Plus limité, pas d’écoute de frappe, quotas d’appels HTTP.
Avantage : L’utilisateur ne change pas ses habitudes.
Inconvénient : Dépend des capacités de l’API du traitement de texte (souvent limitées pour les interactions temps réel).
4.2 Application d’écriture dédiée
[Application d'écriture] ←→ [Moteur IA interne]L’utilisateur utilise une application conçue spécifiquement pour l’écriture assistée, avec l’IA intégrée nativement.
Candidats existants :
- OpenWrite — open source, web app, BYOK. Le plus proche de ce qu’il faudrait.
- Manuskript (fork) — ajouter un système de plugins et une API HTTP.
- novelWriter (fork) — même approche, format de fichier plus simple.
Avantage : Contrôle total de l’expérience utilisateur.
Inconvénient : L’utilisateur doit changer d’outil.
4.3 Agent autonome (watcher)
[Agent IA] ──watcher──► [Dossier de fichiers] ──lit/écrit──► [Projet d'écriture]L’agent surveille un dossier de fichiers (Markdown, .docx, .msk) et agit en arrière-plan. Zéro modification du logiciel d’écriture.
Avantage : Fonctionne avec n’importe quel éditeur. Aucune installation côté utilisateur.
Inconvénient : Pas de feedback en temps réel dans l’interface. L’utilisateur doit consulter l’agent séparément.
4.4 Client universel
[Utilisateur] ──message──► [Agent IA] ──lit/écrit──► [Projet d'écriture]L’utilisateur interagit avec l’agent via une messagerie (Telegram, Discord, SMS, email) ou une interface web. L’agent gère le projet d’écriture en coulisses.
Avantage : Accessible depuis n’importe quel appareil. Pas d’installation. Idéal pour dicter une scène dans les transports.
Inconvénient : Pas d’interface WYSIWYG. L’utilisateur écrit dans une messagerie.
5. Comparaison avec les approches existantes
| Critère | Sudowrite | NovelCrafter | OpenWrite | Microsoft Copilot | Agent orchestrateur |
|---|---|---|---|---|---|
| Mémoire persistante | ❌ Limitée | ❌ Limitée | ❌ | ❌ | ✅ Graphe de faits |
| Multi-agent | ❌ Un seul LLM | ⚠️ Orchestration basique | ❌ | ❌ | ✅ Agents spécialisés |
| Automatisation | ❌ Manuel | ❌ Manuel | ❌ | ❌ | ✅ Workflows programmables |
| Open source | ❌ | ❌ | ✅ | ❌ | ✅ |
| Auto-hébergement | ❌ | ❌ | ✅ | ❌ | ✅ |
| BYOK | ❌ | ✅ | ✅ | ❌ | ✅ |
| Format ouvert | ❌ Propriétaire | ❌ Propriétaire | ✅ Markdown | ❌ .docx | ✅ Markdown |
| Export multi-format | ⚠️ Basique | ⚠️ Basique | ✅ | ✅ | ✅ Pandoc |
| Interface WYSIWYG | ✅ Intégré | ✅ Intégré | ✅ Web | ✅ Word | ⚠️ Via plugin |
| Prix | $20-50/mois | $10-30/mois | Gratuit | $30/mois + M365 | Coût API seulement |
6. Le trou dans le marché
Il n’existe aucun outil aujourd’hui qui combine l’ensemble des critères suivants :
- ✅ Éditeur WYSIWYG complet (ou intégration avec un existant)
- ✅ Mémoire persistante du monde fictionnel
- ✅ Génération IA multi-modèle (BYOK ou local)
- ✅ Orchestration multi-agent
- ✅ Workflows automatisés
- ✅ Open source / auto-hébergé
- ✅ Absence de lock-in
Sudowrite a la génération, pas la mémoire ni l’auto-hébergement.
NovelCrafter a l’orchestration basique et le BYOK, pas la mémoire long terme.
OpenWrite a l’open source et le BYOK, pas la maturité ni la mémoire.
Microsoft Copilot a l’intégration Word, pas l’open source ni la mémoire fictionnelle.
Manuskript/novelWriter ont l’éditeur et l’organisation, pas l’IA.
Personne n’a tout. C’est le trou.
7. Prospective : scénarios d’évolution
7.1 Scénario 1 : L’extension universelle
Un protocole standardisé d’échange entre l’agent et les traitements de texte émerge — appelons-le le « Writing Agent Protocol » (WAP). Chaque éditeur (Word, LibreOffice, OnlyOffice, Google Docs) implémente un plugin qui parle ce protocole. L’agent est un service indépendant, interchangeable, que l’utilisateur choisit et configure.
L’utilisateur écrit dans Word, mais un panneau latéral affiche les suggestions de son agent. Il peut changer d’agent sans changer d’éditeur. Il peut changer d’éditeur sans perdre son agent.
7.2 Scénario 2 : L’application d’écriture nouvelle génération
Une application web open source, auto-hébergeable, combine :
- Un éditeur Markdown/WYSIWYG moderne
- Une mémoire fictionnelle intégrée (graphe de faits)
- Un orchestrateur d’agents (plusieurs LLMs, spécialisés)
- Des workflows automatisés (relecture, cohérence, export)
- Un système de plugins pour l’étendre
OpenWrite est un premier pas dans cette direction. Il manque la mémoire persistante et l’orchestration multi-agent.
7.3 Scénario 3 : L’agent comme unique interface
L’écriture se fait entièrement via l’agent, par messages vocaux ou textuels. L’utilisateur dicte, l’agent structure, écrit, vérifie, exporte. Le traitement de texte n’est plus qu’un outil de visualisation et de mise en page finale.
Ce scénario est le plus disruptif — et le plus éloigné des habitudes actuelles. Mais il est déjà partiellement réalisable avec les agents existants.
7.4 Scénario 4 : La plateforme collaborative
Plusieurs auteurs travaillent sur le même projet, chacun avec son propre agent, mais partageant la même mémoire fictionnelle. Les agents communiquent entre eux pour maintenir la cohérence. Un éditeur peut superviser le travail de plusieurs auteurs, avec des agents de vérification automatique.
Ce scénario est pertinent pour l’édition, les ateliers d’écriture, les projets collaboratifs.
8. Verdict
Le marché des outils d’écriture assistée par IA est en pleine expansion — estimé à $2,8 milliards en 2024, avec une croissance projetée à 9,4% par an jusqu’en 2031. Pourtant, il est structuré autour d’un paradigme unique : un LLM dans une interface. Les acteurs SaaS verrouillent leurs utilisateurs dans des écosystèmes propriétaires. Les logiciels open source (Manuskript, novelWriter) n’ont pas d’IA. Les traitements de texte (Word, LibreOffice) ont des intégrations superficielles.
Un agent orchestrateur — avec mémoire persistante, orchestration multi-agent, automatisation des workflows, formats ouverts et absence de lock-in — n’est pas un concurrent de plus sur ce marché. Il opère sur une couche d’abstraction supérieure. Là où Sudowrite est un marteau (un LLM spécialisé dans une interface), un agent orchestrateur est un atelier complet (plusieurs LLMs, mémoire, outils, workflows, automatisation).
Ce qui manque pour que ce soit mature :
1. Un protocole standardisé d’échange entre l’agent et les traitements de texte
2. Un format de mémoire fictionnelle structuré et interopérable
3. Des plugins de référence pour les 3-4 éditeurs principaux
4. Une UX qui ne nécessite pas de taper des commandes
5. Une validation par des auteurs réels sur des projets longs
Mais le potentiel est clair : aucun outil du marché ne combine mémoire persistante, orchestration multi-agent, automatisation, open source et absence de lock-in. C’est un espace vide — et il attend d’être rempli.
Sources
[^1]: Sudowrite — Best AI Writing Partner for Fiction. https://sudowrite.com/
[^2]: NovelCrafter — Your Novel Writing Software. https://www.novelcrafter.com/
[^3]: OpenWrite — Open-source AI-powered writing platform. https://github.com/ilrein/openwrite
[^4]: Microsoft — How does Microsoft 365 Copilot work? https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-architecture
[^5]: Google — Gemini in Google Docs. https://workspace.google.com/products/docs/ai/
[^6]: LibreOffice — Python Programming with UNO. https://help.libreoffice.org/latest/en-US/text/sbasic/python/python_programming.html
[^7]: OnlyOffice — Office JavaScript APIs. https://api.onlyoffice.com/
[^8]: Manuskript — Open Source Novel Organizer. https://github.com/olivierkes/manuskript
[^9]: novelWriter — Plain text editor for novels. https://novelwriter.io/
[^10]: Fountain — A simple markup syntax for screenplays. https://fountain.io/
[^11]: Microsoft — Office Add-ins at Build 2025. https://devblogs.microsoft.com/microsoft365dev/office-addins-at-build-2025/
[^12]: QY Research — Global AI Writing Tool Market Outlook 2025-2031. https://www.qyresearch.com/reports/5045461/ai-writing-tool
[^13]: Publishing State — What is the Market Size of the AI Writing Industry? https://publishingstate.com/what-is-the-market-size-of-the-ai-writing-industry/2025/
[^14]: Sudowrite vs NovelCrafter — Which AI Writing Assistant Wins in 2025? https://techdictionary.io/sudowrite-vs-novelcrafter/
[^15]: Battle AI Tools — Sudowrite vs NovelCrafter vs Jasper. https://www.battleaitools.com/by-profession/battles/sudowrite-vs-novelcrafter-vs-jasper/