Au-delà de final-final : versions de manuscrit, sources faisant autorité et sauvegardes du Project

À 23 h, l’autrice d’une trilogie reçoit un message de sa maquettiste : « Pourquoi la modification validée manque-t-elle au chapitre douze du deuxième livre ? » Elle prépare la première mise en page de ce volume tout en intégrant les errata des lecteurs à une nouvelle édition du premier. Le dossier contient « final auteur », « relecture éditeur » et final-final ; le disque synchronisé a ajouté une copie conflictuelle. Tous les noms paraissent plausibles. Aucun n’indique quelle œuvre, quelle version et quels chapitres doivent maintenant entrer en production.

La maquettiste repère l’erreur avant que l’ancien brouillon n’entre dans la pagination et les épreuves du livre. L’autrice comprend que final-final devait remplir trois fonctions sans rapport entre elles : identifier le manuscrit actuellement choisi pour la publication, préserver les mots réels d’un moment antérieur et permettre de récupérer le Project entier après une panne de l’appareil ou une erreur humaine. Un nom de fichier ne peut pas porter ces trois responsabilités.

Identifiez précisément cette remise

Scroll utilise un dossier Project local ordinaire choisi par l’auteur. Un même Project peut enregistrer une ou plusieurs œuvres ; une nouvelle édition du premier livre et la première édition du deuxième conservent ainsi des limites distinctes au lieu de partager une source ambiguë intitulée « manuscrit actuel de la série ».

La modification d’un fait de la série ne signifie pas que les trois manuscrits ont été mis à jour. L’auteur détermine d’abord si un changement concerne la série, une œuvre ou une étape du manuscrit. Scroll ne propage pas automatiquement les données de Story entre des Projects distincts et ne décide pas qu’une édition antérieure doit adopter un fait ultérieur.

L’autrice sélectionne l’œuvre du deuxième livre, examine ses versions de manuscrit et sa source, puis crée une version de publication à laquelle elle associe la Version source prévue. Elle peut désormais indiquer à la maquettiste : « Utilisez cet ensemble de chapitres pour la première édition du deuxième livre ; la révision du premier est une œuvre distincte en cours. » La conversation devient la vérification d’une décision explicite, plutôt qu’une supposition tirée des noms de fichiers.

Il ne s’agit pas d’une charge administrative gratuite. Cette distinction permet de traiter simultanément les errata du premier livre et la révision du deuxième sans priver aucun manuscrit de son identité. Lorsqu’une décision commune à plusieurs livres se stabilise, l’auteur l’applique selon la convention de son Project.

Les noms de version préservent les décisions ; les copies réelles préservent le contenu

La source du manuscrit reste le Markdown que l’auteur ouvre, modifie et enregistre. Enregistrer une version de manuscrit ne copie ni ne fige ces fichiers et ne crée pas d’historique comparable à Git. Si la source continue de changer, le libellé de version ne devient pas un nouvel instantané. Avant une autre remise, examinez de nouveau le périmètre et l’ordre des chapitres ainsi que les repères non résolus.

Les jalons éditoriaux importants exigent donc de véritables copies : avant le retour de l’éditeur, après la révision structurelle ou avant les épreuves. La copie préserve les mots. L’enregistrement de version explique le rôle que ces mots ont joué dans l’œuvre.

Conservez une brève note à côté d’une copie importante : l’œuvre, l’étape de révision, l’état de la vérification factuelle et la raison pour laquelle une source ultérieure l’a remplacée. Cela compte lorsque deux fichiers sont tous deux valides, mais qu’un seul représente la décision actuelle. La date de modification ne permet pas, à elle seule, de déterminer l’autorité.

Une sauvegarde du Project entier protège plus que les chapitres

Une copie du dossier du manuscrit peut préserver le texte tout en omettant les tâches, les vues de Story enregistrées, les canevas, les réglages du Project et les enregistrements de remise. Une sauvegarde du Project entier préserve le dossier complet après la fermeture de Scroll, y compris les fichiers et dossiers masqués. Suivez la documentation actuelle sur la sécurité et la récupération des données pour connaître le processus pris en charge.

Le fonctionnement local-first signifie que l’auteur choisit l’emplacement et la stratégie de sauvegarde. Une copie complète du Project fermé peut être conservée sur un autre disque, un périphérique externe ou dans un emplacement cloud fiable destiné aux sauvegardes. Cela ne signifie pas que les fichiers locaux ne peuvent pas être perdus, et un indicateur de synchronisation réussie ne prouve pas que le service comprend le sens des versions du manuscrit.

Avant une révision structurelle, un changement d’appareil ou une remise formelle, effectuez un petit test de restauration. Copiez la sauvegarde dans un emplacement provisoire, ouvrez le Project et examinez le premier et le dernier chapitre, les tâches d’auteur et les informations de l’œuvre. L’objectif n’est pas seulement de récupérer le texte, mais de reprendre le travail avec son contexte actuel.

Pour une série menée sur la durée, associez quelques points de récupération à des étapes significatives : révision structurelle achevée, remise à l’éditeur, prêt à entrer dans Scribe. Le risque détermine la fréquence. Un petit nombre de points de récupération explicables et testés est plus utile qu’une multitude de copies dont personne ne se rappelle la fonction.

Les éditeurs externes et l’usage de plusieurs appareils peuvent encore créer des conflits. Conservez les deux versions avant de les comparer manuellement. Une copie conflictuelle est un véritable fichier qui demande une décision ; une date plus récente ne suffit pas à en faire la source de référence, et Scroll ne réconcilie pas automatiquement les choix créatifs des deux versions.

La production du livre exige encore une remise explicite

Lorsque le manuscrit se stabilise, Scribe prend en charge l’Apparence, la pagination, les PDF, les EPUB et les autres fichiers de publication pris en charge. Scroll enregistre l’œuvre, la version de manuscrit et la source prévues. L’auteur ouvre le même Project dans Scribe et vérifie l’œuvre et la version de publication reconnues, le Dossier source, le nombre et l’ordre des chapitres.

Il ne s’agit pas d’un téléversement et Scroll ne devient pas une application de mise en page. Le fait que le manuscrit soit déclaré prêt dans Scroll ne prouve ni que Scribe a reconnu la source prévue, ni que ses pages sont correctes. Après avoir contrôlé dans Scribe le Dossier source, le nombre et l’ordre des chapitres ainsi que la version de manuscrit, l’auteur peut commencer le travail sur les pages.

Une remise explicite limite les dommages concrets. L’entrée d’un ancien brouillon en production peut entraîner une nouvelle pagination, la répétition des corrections d’épreuves, la mise au rebut d’épreuves ou le report de la publication. Une source claire ne peut pas supprimer toutes les erreurs, mais elle empêche un nom de fichier ambigu de transmettre une même faute à tout le processus de production.

Consultez les cinq signes qu’un manuscrit est prêt pour Scribe pour le contrôle complet avant remise et le workflow de Scroll vers Scribe pour la répartition générale du travail. Si la révision structurelle n’est pas encore achevée, commencez par un workflow de révision structurelle après le premier jet. Les auteurs de séries peuvent comparer les approches dans les outils de gestion des Projects et des versions pour les séries.

Lorsque l’auteur peut répondre à « Que suis-je en train de modifier ? Quelle source fait foi maintenant ? Où puis-je récupérer le Project ? », final-final redevient un nom de fichier ordinaire plutôt qu’une preuve d’autorité. Revenez au workflow Scroll d’écriture au long cours ou découvrez comment Scroll organise les Projects locaux, les œuvres et les sources de publication sur la page produit de Scroll.