NovelForge : des cartes validées par JSON Schema pour écrire un roman long

Le problème visé : un modèle qui survit à trois cents chapitres

Un LLM oublie. Sur un roman long, la difficulté n'est pas de produire une bonne phrase, c'est de produire une phrase compatible avec ce qui a été écrit deux cents pages plus tôt : la couleur des yeux d'un personnage secondaire, l'état d'une ville après un siège, le fait qu'un objet a déjà été donné. NovelForge part de ce constat et propose de déplacer la mémoire hors du contexte du modèle, dans des structures persistantes que l'on peut citer explicitement. Le projet s'adresse donc à des auteurs de fiction longue, plutôt à l'aise avec l'outillage logiciel, qui veulent garder la main sur ce qui entre dans le prompt à chaque génération. Le README résume la promesse en quatre notions : des cartes modulaires, un modèle de sortie personnalisable, une injection de contexte, et un graphe de connaissances pour la cohérence. C'est une architecture de base de données narrative plus qu'un éditeur de texte.

Cartes typées et remplissage champ par champ

Le mécanisme central tient en deux étages. D'abord, chaque type de carte (personnage, scène, organisation, objet, concept) peut recevoir un schéma. Quand vous demandez une génération, la réponse du modèle est validée contre ce schéma, ce qui élimine une classe de défaillances très concrète : le modèle invente un champ, en oublie un autre, ou renvoie une liste là où vous attendiez une chaîne. Ensuite, depuis la version 0.9.0, la génération n'est plus monolithique. Le README décrit le flux comme « entrée de la demande, remplissage en streaming au niveau du champ, puis confirmation ou retour pour poursuivre ». Vous voyez donc les champs se remplir un par un et vous pouvez corriger en cours de route au lieu de relancer une carte entière. La session de génération est liée à la carte courante : fermer la boîte de dialogue termine la session. C'est un choix explicite, et il a une conséquence : rien de ce qui a été généré là ne persiste tant que vous ne l'avez pas accepté. Les types de cartes sont décrits comme extensibles, mais le README ne détaille pas la procédure d'ajout d'un type personnalisé, seulement l'existence de schémas par type.

L'injection de contexte @DSL et le graphe de relations

Pour alimenter le modèle sans tout coller, NovelForge utilise une syntaxe de référence, appelée @DSL dans la documentation, qui permet de citer précisément des données du projet. Le graphe de relations complète le dispositif : à partir de la version 0.9.1, il peut être stocké dans SQLite, avec Neo4j toujours pris en charge comme alternative. Le stockage SQLite change la nature du déploiement, puisqu'il supprime la dépendance à un serveur de graphe séparé. La version 0.9.4 a étendu ce que le projet appelle la couche de mémoire à six familles d'entités : personnages, relations, scènes, organisations, objets et concepts. Le point intéressant est la procédure : l'extraction se fait depuis le texte du chapitre courant, affiche un aperçu, autorise des ajustements manuels, puis écrit dans les cartes ou le graphe après confirmation. Rien n'est injecté automatiquement. C'est plus sûr et plus lent, et le README prévient lui-même que ces capacités de mémoire sont à utiliser « selon les besoins, pas nécessairement toutes », pour éviter d'alourdir le contexte. Cette mise en garde est le signe d'un problème réel : plus vous activez de mémoire, plus chaque appel de génération coûte cher en tokens.

Mise en route : port, .env et détection des capacités du modèle

Le projet est en Python et le dépôt distingue un dossier backend et un dossier frontend. La version 0.9.7 documente un réglage précis : le port du service backend se configure via la clé APP_PORT dans backend/.env, avec 54321 comme valeur par défaut et une validation sur la plage 1-65535. Le projet fournit aussi un démarrage en une commande pour le frontend et le backend, mentionné dans les notes de la version 0.9.2. Avant de générer quoi que ce soit, passez par la page de configuration LLM : depuis la 0.9.6, elle peut déclencher un test de capacités et de compatibilité du modèle, qui porte sur le dialogue de base, le streaming, la sortie structurée et les appels d'outils. Ce test n'est pas décoratif. NovelForge repose sur la sortie structurée, et un modèle qui la gère mal produira des cartes invalides. Le README signale aussi que les modèles de type DeepSeek ou Qwen gagnent à être déclarés comme fournisseurs compatibles OpenAI, tandis que les modèles officiels OpenAI doivent rester sur leur propre configuration. Deux réserves documentées : le mode Responses n'est pas compatible avec l'assistant d'inspiration, et le mode ReAct, destiné aux modèles sans appels d'outils natifs, est décrit dans les notes de version comme une implémentation « assez grossière » qui peut contenir des bogues.

Les workflows en code : le pari assumé et son coût

La version 0.9.0 a remplacé l'ancien éditeur de graphe acyclique par ce que le projet appelle des workflows en code, c'est-à-dire des instructions de style Python avec un DSL à marqueurs spéciaux. Le README donne des éléments concrets : Logic.Wait pour l'attente, async=true pour l'asynchrone, et un exécuteur qui planifie les instructions une par une. La justification avancée est double : les sémantiques d'exécution sont plus proches du déroulement réel, et une même fonctionnalité tient en quelques dizaines de lignes de code là où une configuration de graphe en demandait plusieurs centaines. Le revers est documenté par les mainteneurs eux-mêmes : moins intuitif qu'un graphe, et plus sensible au format des chaînes et du code, avec des erreurs de validation ou d'exécution qui viennent de la sérialisation des paramètres, du typage des champs de dictionnaire ou des références de variables. Un agent permet d'écrire ces workflows en langage naturel, avec un aperçu avant application. C'est un pari de maintenance : vous gagnez en lisibilité ce que vous perdez en tolérance aux erreurs de format.

Contrôle du nombre de mots et arbitrage sur les tokens

La continuation du corps de chapitre propose deux modes, et le compromis est clairement énoncé. Le mode « contrainte par prompt » se contente de demander une longueur au modèle : le texte est plus naturel et le coût plus faible. Le mode « contrôle » découpe l'objectif de mots en plusieurs tours avec un budget par tour : le résultat est plus stable sur un chapitre long, mais consomme davantage de tokens. Les notes de la version 0.9.3 précisent que ce mode utilise une stratégie de budget fixe sur plusieurs tours. Il n'existe donc pas de mode qui soit à la fois naturel et strictement contrôlé. Si vous écrivez des chapitres de 6000 mots avec une contrainte stricte, vous payez en tokens ; si vous acceptez une variation de quelques centaines de mots, vous payez moins. Ce n'est pas une limite cachée, c'est un réglage à choisir par projet, et le bon choix dépend de votre budget d'API plus que de vos préférences d'écriture.

Ce que le projet n'est pas, et ce qui existe à côté

NovelForge n'est pas un traitement de texte avec une assistance contextuelle. La version 0.8.0 a déplacé l'éditeur de chapitre d'une fenêtre séparée vers le panneau central, ce qui rapproche l'expérience d'un éditeur intégré, mais tout le reste (schémas, graphe, workflows, configuration du modèle) reste un travail de configuration. Si votre besoin se limite à « continuer ce paragraphe en gardant le ton », un éditeur avec autocomplétion branchée sur un modèle suffit et ne demande aucune base de données. L'alternative la plus proche en esprit est un pipeline que vous assemblez vous-même : un dossier de fichiers Markdown pour les fiches de personnages, un script Python qui sélectionne les fiches pertinentes, un appel à l'API avec sortie structurée, et une validation Pydantic. La différence n'est pas la qualité du texte produit, c'est la persistance. Dans un tel pipeline, la cohérence est reconstruite à chaque exécution par votre script ; dans NovelForge, elle vit dans une base SQLite, un graphe et des cartes typées que vous éditez à la main. Vous échangez du code à écrire contre une interface à apprendre et une base à sauvegarder.

Licence AGPL-3.0, mises à jour et coût de suivi

Le dépôt est publié sous AGPL-3.0. Cette licence impose des obligations dès que vous distribuez une version modifiée ou que vous exposez le logiciel modifié comme service en réseau : le code correspondant doit être mis à disposition dans les conditions de l'AGPL. Pour un auteur qui écrit son roman avec l'outil sur sa machine, la question ne se pose pratiquement pas. Pour quelqu'un qui voudrait héberger NovelForge modifié pour d'autres utilisateurs, elle se pose immédiatement. Ce paragraphe décrit la licence, il ne constitue pas un avis juridique. Sur le rythme de publication, les versions v0.9.5-1, v0.9.6 et v0.9.7 se succèdent entre mai et août 2026, avec des correctifs fréquents et des refontes de fonctionnalités existantes. Le vrai coût de maintenance est ailleurs : la version 0.9.0 a prévenu que les anciennes bases ne seraient probablement pas réutilisables directement, qu'un script de migration était fourni sans garantie de succès, et qu'il fallait sauvegarder le fichier de base avant de tenter quoi que ce soit. Une refonte de cette ampleur peut se reproduire. Si vous stockez un manuscrit de plusieurs centaines de milliers de mots dans ce format, prévoyez une procédure d'export et une sauvegarde indépendante de l'application, parce que le format de stockage fait partie de ce que le projet fait évoluer.

Conclusion éditoriale

NovelForge convient à un auteur technique qui accepte de tenir un dépôt Python, une base SQLite et des schémas JSON pour garder la cohérence d'un texte long. Il ne convient pas à quelqu'un qui veut écrire dans un traitement de texte avec une barre latérale d'assistance : la configuration des modèles, des schémas et des workflows fait partie du travail. Avant d'y mettre un manuscrit, vérifiez trois choses dans votre copie : que votre fournisseur LLM passe la détection de capacités de la page de configuration (dialogue, streaming, sortie structurée, appels d'outils), que la sauvegarde de votre base est faite, et que le format de vos cartes existantes survit à la migration. Le point de rupture est là, pas dans la qualité des prompts.

Sources officielles

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. RhythmicWave/NovelForge on GitHub