Un Vault Obsidian peut grandir longtemps. Comment garder chaque roman familier ?
Obsidian transforme des Vaults Markdown locaux en réseaux de connaissances flexibles. Scroll donne à plusieurs univers séparés le même workflow d’auteur intégré, sans reconstruire plugins et configuration pour chaque Project.
Obsidian repose sur une idée remarquablement durable : la connaissance peut vivre dans des fichiers Markdown locaux et gagner du sens par Links, Backlinks, Graph et Canvas. Un Vault peut devenir une archive de recherche, un Zettelkasten ou un système complet de worldbuilding. Themes, Core Plugins et Community Plugins prolongent cette liberté pour les personnes qui aiment façonner leurs outils.
Cette adaptabilité donne sa force à Obsidian pour la connaissance de longue durée. Un Vault peut grandir dix ans sans abandonner son format ouvert. Des liens apparaissent avant même que leur usage définitif soit connu. L’auteur garde la maîtrise de l’architecture et des extensions.
Les romanciers n’entretiennent pourtant pas toujours une seule base qui s’agrandit. Ils possèdent plusieurs mondes nettement séparés : une trilogie fantasy, un polar historique et un essai, chacun avec ses personnages, règles et sources. Les fonctions doivent se ressembler ; les contenus ne doivent pas se mélanger. Obsidian conserve réglages, thèmes et plugins propres à chaque Vault dans le dossier de configuration .obsidian. On peut copier cette configuration, mais elle reste gérée pour chaque Vault. Plus le workflow dépend d’extensions, plus sa cohérence demande une attention consciente.
Scroll commence lui aussi en local, avec une autre priorité. Chaque Project représente un univers indépendant et reçoit les mêmes vues Story intégrées, l’éditeur long, References, Tasks, œuvres, versions et sauvegardes. L’auteur n’a pas à transformer d’abord un outil de connaissance généraliste en studio de roman.
Réseau de connaissances et workflow d’auteur ne posent pas les mêmes questions
Dans un réseau de connaissances, la question productive est souvent : quelles notes se relient ? Dans un Project de roman, d’autres autorités s’ajoutent : qu’est-ce qu’un événement de la Story et qu’est-ce qu’une tâche de révision ? Quels chapitres forment le manuscrit ? Quelle version entre en production ? Où se trouve un personnage à une date donnée ?
Obsidian peut modéliser ces systèmes par Properties, modèles, Canvases et plugins. Cette ouverture convient aux personnes qui aiment concevoir leur architecture. Scroll fournit d’emblée une sémantique d’auteur : personnages, lieux, organisations et événements peuvent être lus par plusieurs vues ; Tasks dispose de Board, List, Calendar et Schedule ; manuscrit et versions possèdent une place définie.
Cette intégration ne prétend pas dépasser un Vault spécialisé ou construit sur mesure dans chaque domaine. Elle réduit le travail d’installation et de maintenance lorsque plusieurs mondes séparés doivent partager le même processus. Un nouveau Project s’ouvre avec des capacités familières plutôt qu’avec une nouvelle rénovation.
Les plugins sont une force — et une responsabilité
Les Community Plugins étendent Obsidian très loin. Ils restent optionnels : de bonnes notes n’en dépendent pas nécessairement. Mais lorsqu’un workflow de roman repose sur certains plugins, l’auteur assume leur sélection, leurs permissions, leurs mises à jour, leur compatibilité et la cohérence entre Vaults.
Scroll regroupe les fonctions de son workflow d’auteur dans une seule application. Vues Story, éditeur, Tasks et versions ne sont pas réinstallés dans chaque Project. C’est utile aux personnes qui veulent plusieurs univers équipés de façon semblable, tout en consacrant leur temps aux personnages, aux lieux et au texte.
Le choix dépend aussi du plaisir pris à construire le système. Une personne qui aime concevoir son outil autant que sa base de connaissances trouvera dans Obsidian une grande liberté. Celle qui préfère ouvrir un environnement de roman prévisible peut accorder plus de valeur à la structure intégrée de Scroll.
Le Markdown local a toujours besoin d’une règle de sauvegarde
Les deux approches rendent les fichiers locaux contrôlables et transportables. Ce n’est pas une sauvegarde automatique. Vault ou Project peuvent participer à une synchronisation cloud adaptée, à une sauvegarde système ou à une copie externe ; conflits, exclusions et restauration doivent tout de même être compris et testés.
Scroll peut créer une sauvegarde complète du Project et distingue cette restauration des versions du seul manuscrit. Versions de manuscrit et sauvegardes du Project explique pourquoi une version de texte ne remplace pas la copie de Story data, Tasks et References.
Du worldbuilding au livre fabriqué
Un univers peut croître pendant des années ; un livre précis a toutefois besoin d’une version de référence. Scroll relie worldbuilding actif, manuscrit, œuvres et versions. Lorsque le texte est stable, Scribe prend en charge Appearance, pagination et sorties de publication.
Scroll ne crée pas directement le PDF final, l’EPUB ou la mise en page imprimée. La préparation ne signifie pas non plus que Scribe a déjà reçu le contenu correctement ; sélection, structure reconnue et pages restent à contrôler. Le workflow Scroll→Scribe montre cette frontière.
Choisir la bonne forme pour plusieurs univers
Obsidian excelle comme réseau de connaissances Markdown durable et malléable. Scroll est conçu pour plusieurs Projects Story locaux qui retrouvent, sans installation répétée, le même chemin de planification, d’écriture, de tâches et de production. Les deux respectent le travail local tout en mettant l’accent sur des besoins différents.
Demandez-vous si vous entretenez une grande base personnelle ou plusieurs univers de roman distincts avec la même boîte à outils. Poursuivez avec Un worldbuilding au service de la Story, revenez au guide comparatif de Scroll ou découvrez sur la page produit de Scroll comment un nouvel univers commence sous forme de Project complet.