Les modèles de Story ne sont pas des formules narratives

Un questionnaire de personnage procure une satisfaction particulière. Nom, âge, anniversaire, cicatrice, blessure d’enfance, plat préféré : cent réponses s’accumulent et la page blanche paraît enfin vaincue. Puis l’autrice revient au premier chapitre. Le personnage ignore toujours ce qu’il veut dans cette scène et n’a encore aucun choix à faire aujourd’hui.

Les modèles n’en deviennent pas inutiles. Ils facilitent le démarrage, rappellent ce qui a été oublié et maintiennent la cohérence des faits récurrents. La difficulté commence lorsque trois choses très différentes portent toutes le nom de « modèle » et qu’un même formulaire doit gérer des informations, structurer une intrigue et donner vie à un personnage.

Avant de choisir un modèle dans Scroll, séparez les questions : avez-vous besoin d’une formule narrative, d’un modèle de contenu ou d’un modèle de Project ?

Une formule narrative guide le développement ; un modèle de contenu guide la saisie

La structure en trois actes, le voyage du héros et les grilles de temps forts répondent à une question de développement : comment une Story pourrait-elle progresser ? Ces méthodes aident à réfléchir aux retournements, au conflit et au rythme. Pour certaines personnes, une méthode familière devient un langage créatif fiable. Les modèles de contenu de Scroll ne décident pas quelle structure narrative est correcte, et rien n’empêche une autrice ou un auteur de conserver une méthode rigoureuse qui lui convient.

Les modèles de personnages, lieux, organisations, événements et textes répondent à une autre question : lors de la création de ce type de contenu, quelles informations doivent avoir leur place dès le départ ? Une fiche de personnage peut nécessiter un objectif actuel et une position. Un événement peut demander des dates, des participants et des lieux. Un lieu peut exiger une hiérarchie ou des coordonnées. Ce sont des repères de saisie, pas des consignes pour le troisième acte.

Un modèle de Project va plus loin. Des propriétés, relations et structures visuelles réutilisables donnent au Project un vocabulaire stable pour les faits qui doivent être interrogés et comparés. Une série policière peut devoir distinguer régulièrement la pièce à conviction, sa possession et le moment de sa divulgation. Une série de fantasy peut avoir besoin de vérifier les lois, les coûts, les exceptions et les régions où une règle s’applique. Il ne s’agit plus d’un simple formulaire de création, mais d’une manière d’exprimer un sens récurrent dans le Project.

Une fois ces fonctions séparées, un modèle n’a plus à accomplir un travail qui le dépasse. Un personnage convainc par ses désirs, les obstacles qu’il rencontre, ses actes et sa voix. Un enregistrement structuré aide simplement l’autrice ou l’auteur à retrouver plus tard les faits qui doivent rester cohérents.

Commencez par le plus petit enregistrement utile

Utiliser les modèles intégrés avec retenue constitue souvent le meilleur point de départ pour un nouveau Project.

Pour un personnage, consignez d’abord l’objectif immédiat, la position et l’état actuel. Pour un lieu, commencez par la hiérarchie et l’atmosphère, puis ajoutez une position précise lorsque la Story l’exige. Pour un événement, saisissez les dates, les participants, le lieu et l’issue. Remplissez les champs que vous comptez rechercher, filtrer ou comparer, ou que vous devrez examiner au moyen de relations.

Tout le reste peut également exister. La cadence d’un personnage, la gêne physique d’une rencontre ou le caractère oppressant d’une ville peuvent rester dans des notes libres et dans le manuscrit. Transformer chaque impression en propriété ne la rend pas mieux structurée ; cela ajoute seulement un champ à entretenir.

Le test est simple : si une information doit surtout être lue, laissez-la dans la prose. Si elle doit être filtrée, triée, reliée ou comparée entre plusieurs fiches, une structure peut être utile.

L’espace accessible par Templates réunit les modèles d’entités, d’événements, de relations et d’écriture. Les modèles et fiches intégrés sont inclus avec Free, et la définition d’un modèle intégré ne peut pas être modifiée. Free et Plus permettent de créer des fichiers depuis un modèle personnalisé déjà présent dans le Project. La création ou la modification de définitions globales ou propres au Project pour les modèles, propriétés, relations et structures visuelles nécessite Pro.

Cette limite du produit rappelle aussi une règle créative utile : ne redessinez pas chaque structure par défaut avant que le premier véritable personnage ne l’ait traversée. Laissez quelques contenus réels révéler ce dont le Project a besoin.

Les fiches et la prose doivent rester accessibles l’une depuis l’autre sans se confondre

Les systèmes de connaissances pour textes longs deviennent lourds lorsque chaque connexion est censée avoir le même sens. En pratique, un Project peut contenir au moins trois types de connexion.

Le premier est une référence dans la prose. Le nom d’un personnage apparaît au chapitre trois, et un lien permet de revenir à sa fiche. Cela signifie que le texte mentionne ce personnage.

Le deuxième est une relation structurée. Un personnage appartient à une organisation, une personne détient une pièce à conviction ou un événement se déroule dans un lieu. Ces connexions ont un sens relativement stable et peuvent être vérifiées plus tard.

Le troisième est une connexion exploratoire. Sur Whiteboard, l’autrice place un personnage à côté d’une rumeur pour demander : « Et si ces éléments étaient liés ? » Un connecteur de canevas peut porter une hypothèse sans devenir un fait confirmé dans l’univers de la Story.

Imaginez une journaliste qui apparaît dans le manuscrit, entretient une relation professionnelle confirmée avec la mairie et dont la fiche a aussi été placée à côté de « faux témoignage » sur un canevas spéculatif. Ces trois traces représentent une présence dans le texte, une donnée Story établie et une possibilité créative. En maintenant leurs sens séparés, l’autrice peut explorer librement sans altérer les faits sur lesquels reposent les chapitres suivants.

C’est aussi l’utilité des modèles : non pas forcer chaque information à entrer dans une fiche, mais donner aux faits stables un emplacement prévisible tout en gardant la prose et la spéculation à portée de main.

Quand la création d’un modèle de Project personnalisé se justifie-t-elle ?

La personnalisation ne devrait pas commencer parce qu’un modèle par défaut semble manquer d’originalité. Elle devient pertinente lorsqu’un problème récurrent rend les vérifications coûteuses.

Prenons une série policière. Dans le premier livre, une simple fiche d’événement indique qu’une bague a été retrouvée. Dans l’affaire suivante, un registre passe entre plusieurs mains. Au troisième volume, l’autrice doit régulièrement répondre à trois questions : à quel moment cette pièce à conviction existait-elle ? Qui la détenait à chaque étape ? Quand a-t-elle été révélée, et à qui ?

Ce triplet — pièce à conviction, détenteur et moment de la divulgation — présente désormais trois qualités utiles : la structure revient, elle doit pouvoir être interrogée et son sens est stable. L’autrice peut dupliquer un modèle adapté, ajouter le minimum de propriétés ou de relations nécessaires et les tester sur quelques fiches. Spreadsheet, Relationship graph et les vues temporelles permettent ensuite de vérifier si le modèle facilite réellement la réponse. Si l’essai est concluant, il peut être utile de l’étendre à des contenus plus anciens.

Le worldbuilding de fantasy suit la même règle. Une « loi magique » ne nécessite pas un nouveau type simplement parce qu’elle paraît importante. Si chaque loi doit être comparée à un coût, une région et des exceptions, une structure peut aider. Si une règle n’apparaît que dans un seul rituel, un paragraphe précis reste peut-être le meilleur outil.

Avant toute modélisation en masse ou modification des métadonnées, sauvegardez le Project complet. Une rétrogradation ne supprime pas les champs personnalisés existants, mais peut limiter les opérations de modification et de migration qui ne sont plus incluses. Les limites actuelles des offres figurent dans Offres et fonctionnalités et devront être vérifiées à nouveau avant publication.

Quand faut-il attendre ?

Quatre signes indiquent qu’une personnalisation serait prématurée.

Premièrement, le besoin n’apparaît qu’une fois. Un détail cérémoniel unique ne mérite peut-être pas un type d’entité complet.

Deuxièmement, le sens du champ continue d’évoluer. Si « fiabilité » désigne aujourd’hui celle de la narration et demain celle d’une preuve, une propriété commune créera davantage de confusion que d’ordre.

Troisièmement, l’autrice ou l’auteur réagit surtout à la peur d’oublier quelque chose. L’inquiétude produit facilement cinquante champs vides. Or les champs vides ne sont ni une Story ni une preuve.

Quatrièmement, l’information ne sera ni recherchée, ni filtrée, ni reliée, ni comparée. Lorsqu’un détail doit seulement être relu de temps à autre, la prose coûte souvent moins cher à entretenir.

Le coût d’une modélisation excessive ne se limite pas à une interface plus chargée. Chaque modification de la Story oblige à se demander quels champs doivent aussi changer. L’échafaudage finit par devenir le bâtiment.

Testez une structure proposée sur quelques fiches réelles avant de l’étendre. Le résultat devrait être un modèle éprouvé par un véritable processus d’écriture, et non un système élaboré qui réclame de l’entretien avant d’avoir apporté quoi que ce soit.

Laissez la fiche de personnage évoluer avec les besoins de la Story

Revenons au questionnaire du début. Une voie plus légère peut commencer par le modèle de personnage intégré, l’objectif actuel de la protagoniste et son identité publique. L’autrice crée la mairie comme lieu et une audience publique comme événement. Pendant l’audience, la protagoniste ment. La question « Qui connaît ce secret, et depuis quand ? » se révèle alors déterminante pour de nombreux chapitres ultérieurs.

Au départ, cette information peut rester dans le contenu des fiches. À mesure que le cercle des personnes informées s’élargit, l’autrice confirme qu’une comparaison entre personnages devient nécessaire. Une petite propriété ou relation « état de connaissance » peut être testée sur quelques fiches : Spreadsheet peut-il filtrer les personnes informées ? Relationship graph montre-t-il les connexions prévues ? Une vue temporelle permet-elle de vérifier le moment de la divulgation ?

Le modèle se développe à partir de la Story, sans la précéder. La protagoniste reste vivante grâce au choix qu’elle fait pendant l’audience ; la structure empêche seulement le chapitre douze de confier le secret à une personne qui ne l’a jamais appris.

Posez trois questions avant de créer une structure personnalisée : l’information revient-elle ? Doit-elle pouvoir être interrogée ? Son sens est-il stable ? Si les trois réponses sont positives, elle peut intégrer le modèle. Si une seule l’est, laissez-la pour l’instant dans la prose.

Le guide de l’espace Templates présente les types de modèles publics, et Personnaliser le modèle d’un Project documente les limites des offres et des migrations. Si la difficulté porte plutôt sur l’examen des enregistrements, poursuivez avec Pourquoi une Story peut avoir besoin de onze vues. Vous pouvez aussi revenir au guide de l’écriture au long cours pour choisir une autre voie.

Un modèle utile apparaît lorsqu’il devient nécessaire et s’efface lorsqu’il ne l’est plus. Il laisse des faits sur lesquels l’autrice ou l’auteur peut compter, pas une solution toute faite à laquelle la Story doit obéir.