---
title: "Le _Novendécaméron_ ou éditer avec et en numérique"
chapitre: 3
section: 5
bibfile: "data/03.json"
_build:
  list: always
  publishResources: true
  render: never
---

Si éditer _avec_ le numérique permet de prendre la mesure de l'usage du numérique dans les _lettres_, il nous reste à définir ce que signifie éditer _en_ numérique, dans cette dimension expérimentale et réflexive propre aux humanités numériques.
Loin de se réduire à un format de sortie, tels que les formats PDF, EPUB ou même HTML, éditer _en_ numérique signifie repenser les flux de production, les espaces d'édition ou encore l'architecture de la modélisation des textes et des artefacts.
L'étude de cas d'Ekdosis nous a permis de comprendre qu'est-ce qu'éditer _avec_ le numérique signifie, appliquant certaines potentialités à la fabrication d'un objet complexe comme une édition critique.
Cette fois c'est un projet littéraire que nous analysons, un recueil hétérogène de prose, de poésie ou d'essais.
Ce projet ne correspond pas à la représentation la plus courante des humanités numériques, plus souvent concentrées sur l'extraction et le traitement de grand corpus, néanmoins il est question ici de méthodes et d'approches qui y ont une grande part.
Si le projet revet une certaine forme de marginalité, c'est justement cette manière de faire, originale, qui nous intéresse plus particulièrement, ainsi que son appropriation par les personnes impliquées.

Nous décrivons cet objet et la chaîne d'édition qui a permis sa fabrication : l'origine du projet, ses objectifs intrinsèques, mais aussi la _pile technique_.
Enfin nous détaillons les questionnements qui ont surgi durant le processus d'édition et de conception de la chaîne d'édition.
L'auteur de cette thèse fait partie des quatre personnes qui ont animé et porté ce projet.


### 3.5.1. Un feuilleton numérique

Le _Novendécaméron_ {{< cite "vallee_novendecameron_2021" >}}{{< n >}}Les deux versions du _Novendécaméron_, web et imprimée, sont distinguées dans les références bibliographiques.{{< /n >}} est un feuilleton littéraire en temps de pandémie publié aux éditions Ramures, un projet éditorial collectif qui réunit des textes et les diffuse à l'ère numérique, _avec_ le numérique.
Au printemps 2020 Chantal Ringuet et Jean-François Vallée lancent un appel à textes, en plein confinement, au Québec et en France.
Quelques mois plus tard c'est une vingtaine de contributions textuelles et autant d'illustrations qui est rassemblée puis éditée.
L'objectif est de publier une version numérique (un livre numérique au format web) d'un recueil hétéroclite d'auteurs, d'autrices, de chercheurs, de chercheuses, de traducteurs et de traductrices, et d'artistes francophones d'Europe et du Canada, de façon successive dans le temps, à la manière des feuilletons du dix-huitième siècle.
C'est chose faite au printemps 2021, un an après les prémisses de cette aventure éditoriale, les vingt-deux œuvres sont publiées en ligne à raison de deux textes par semaine pendant plus de deux mois.
Il s'agit aussi d'une manière de créer des espaces numériques habitables — autre que les visioconférences avec Zoom — en période de pandémie.

{{< citation ref="vallee_novendecameron_2022" page="11-12" >}}
Comme l'annonce son titre, ce recueil numérique a été inspiré par le _Décaméron_ et _L_'_Heptaméron_, ces œuvres littéraires de la Renaissance qui mettent en scène des personnages en confinement se racontant tour à tour des histoires pendant l'épidémie de peste du 14<sup>e</sup> siècle en Italie dans le premier cas et des inondations dans le sud de la France au 16<sup>e</sup> siècle pour le second.
[…]
La fausse — mais opportune — étymologie de ce préfixe nous permet […] d'annoncer un _nouvel_ objet littéraire, créé en contexte pandémique et numérique, dans lequel il est permis d'explorer divers enjeux de cette catastrophe sanitaire qui a menacé nos santés physique et mentale, modifié notre rapport au travail et à nos relations, et peut-être ébranlé les modalités mêmes de notre présence au monde.
{{< /citation >}}

Pour pouvoir rendre ces textes et ces illustrations accessibles, des artefacts sont nécessaires et, en amont, des espaces permettant de travailler ces œuvres.
Le projet intègre ceux du Groupe de recherche sur les éditions critiques en contexte numérique{{< n >}}Aussi appelé GREN, ce groupe de recherche est dirigé par Michael Sinatra.{{< /n >}}, et c'est à ce titre que Louis-Olivier Brassard et Antoine Fauchié{{< n >}}L'auteur de cette thèse.{{< /n >}} rejoignent le projet pour accompagner sa mise en forme graphique et sa mise en place technique, en tant qu'étudiants auxiliaires de recherche.
Il est nécessaire de mettre en place un espace d'édition des textes, pour _in fine_ les rendre disponibles en ligne, c'est en effet le premier objectif : construire un site web qui accueille ces œuvres.
Les compétences techniques de Jean-François Vallée et de Chantal Ringuet sont très différentes de celles des deux étudiants, ces derniers sont en effet en capacité d'interagir avec du texte depuis un terminal, alors que l'éditeur et l'éditrice ont besoin d'une interface graphique — en apparence plus accessible et rapide à prendre en main.
L'idée est donc de mettre en place deux espaces d'édition et de publication, deux espaces qui peuvent cohabiter et qui permettent à chacune des personnes d'interagir de façon autonome et efficiente.
Ces actions d'édition consistent à modifier les contributions et à valider ces modifications en autonomie et de manière fluide{{< n >}}Nous revenons et nous critiquons par la suite ces qualificatifs, et principalement "efficient" ou "fluide".{{< /n >}}.
La prise en compte des besoins des différentes personnes impliquées a été une condition de faisabilité du projet.
L'autre condition forte est la question de la _soutenabilité_ du projet.

Commencer un projet en considérant sa fin est une pratique qui tend à se répandre au sein des humanités numériques, l'idée étant d'anticiper la façon dont le projet peut ou non être maintenu dans le temps dès son amorce.
Les financements accordés par le GREN pour ce projet éditorial sont limités{{< n >}}Entendons par là que le budget est arrêté et qu'il ne peut donc pas être reconduits plusieurs fois.{{< /n >}}, il faut donc anticiper comment les sources des textes peuvent rester lisibles et exploitables, comment des mises à jour peuvent être faites, ou à quel point certaines dépendances techniques peuvent générer une obsolescence par la suite.
Loin d'appliquer tous les principes proposés par "The Endings Project" {{< cite "carlin_endings_2018" >}}, il a toutefois été convenu de s'en inspirer pour permettre une durabilité de cette publication.
La chaîne d'édition mise en place pour l'occasion est documentée, un journal est mis en place (partagé entre les membres du projet) pour relever les questionnements et les difficultés rencontrés, une évaluation du travail nécessaire au maintien du projet sur les cinq prochaines années est réalisée, et certains choix techniques sont faits pour permettre une durabilité du projet.
Par exemple l'usage du générateur de site statique Hugo, composant logiciel chargé de convertir et d'organiser des documents balisés sémantiquement, facilite la gestion sur le long terme.
Hugo est en effet installable (ou compilable) depuis un fichier binaire, ce fichier embarquant toutes les dépendances nécessaires.
La version de Hugo utilisée pour produire l'artefact à un moment précis est ainsi conservée, dans le cas où les prochaines versions incluraient des ruptures avec les versions précédentes. 
Pouvoir facilement intervenir dans un environnement précis est une condition de réussite (et un défi) de tout projet informatique.

La diffusion, les espaces de travail et la soutenabilité de ce projet éditorial ont été pensés avec le numérique, c'est-à-dire avec les potentialités permises par un tel environnement, et il en est de même pour les versions du recueil ou des textes.
Si la question d'une version imprimée — ou imprimable — est soulevée dès les premiers échanges, il s'agit alors de la déclinaison individuelle de chaque texte dans une forme originale — choix graphiques, mise en page, format de papier.
Cette option imaginée au début est laissée en suspens au profit d'une version imprimée complète du recueil, en raison d'une partie du budget non utilisée permettant d'imprimer plusieurs exemplaires.
Cette publication devient multi-formats : d'un objectif premier de concevoir un site web — une forme de _livre web_ {{< cite "fauchie_livre_2017" >}} — nous envisageons dans un second temps la fabrication d'une version imprimable.
Les deux formats sont livrés dans deux temps distincts : une première période de diffusion progressive des œuvres étalée sur plusieurs semaines, et un deuxième moment pour mettre à disposition un livre imprimé rassemblant les multiples contributions — plus un avant-propos conséquent pour contextualiser le projet.
Deux formats qui ont nécessité la mise en place d'une même chaîne d'édition qui prend en compte ces spécificités.

{{< figure type="figure" src="novendecameron-01.png" legende="Capture d'écran du texte de Nicole Brossard sur la version web du _Novendécaméron_ et les pages imprimées correspondantes" >}}


### 3.5.2. La pile technique du _Novendécaméron_

De la structuration des contenus aux versions web et imprimables, en passant par plusieurs espaces d'édition et de publication, comment est constituée la chaîne d'édition du _Novendécaméron_ ?
Les rouages techniques révèlent ici les modalités éditoriales, et l'inverse est aussi vrai : des choix techniques ont influencé les façons de penser les artefacts ou les modes de diffusion.
Une vue d'ensemble est tout d'abord nécessaire pour comprendre les différentes parties de la chaîne.

{{< figure type="figure" src="novendecameron-chaine-02.png" legende="Schéma représentant la chaîne d'édition du _Novendécaméron_, CC-BY-SA Louis-Olivier Brassard" >}}

Cette figure représente les différents composants de la chaîne d'édition mise en place pour éditer le _Novendécaméron_ : le balisage des contenus avec le langage Markdown ; la conversion et l'organisation de ces fichiers source avec le générateur de site statique Hugo ; le versionnement des contenus et du design avec Git ; l'édition avec une interface graphique via le service Forestry.io ; l'hébergement du code source ; le déploiement des artefacts et l'hébergement avec GitLab.com.

Le choix du balisage des textes est une première étape dans le processus de fabrication du _Novendécaméron_, il répond à deux contraintes : penser un objet éditorial en dehors des méthodes classiques (faisant habituellement appel à un traitement de texte), et permettre d'éditer _avec_ et _en_ numérique.
La première contrainte consiste principalement à envisager une séparation stricte entre le contenu et sa mise en forme.
La seconde contrainte réside dans le fait de pouvoir convertir une source en de multiple formats ou versions.
Une même source est éditée — cette précision est décisive — plutôt que de devoir mettre à jour autant de versions initiales que de versions finales.
Le langage de balisage léger Markdown a été choisi pour sa simplicité et son extensibilité possible avec certains convertisseurs.
Markdown est en effet conçu pour être converti dans un autre langage de balisage HTML — il est plus longuement analysé par la suite{{< renvoi chapitre="4" section="3" >}}.
Il s'agit donc de passer d'un système de balisage à un autre, le premier étant créé pour être lisible et utilisable par des personnes humaines, mais aussi des programmes, alors que le second est produit pour être interprété par des logiciels — en l'occurrence un navigateur web en premier lieu.
Markdown est un langage ambigu, il ne dispose pas d'une standardisation comme HTML, mais cette ambiguïté offre une certaine souplesse dans son usage.
Avec le générateur de site statique Hugo, il est possible d'utiliser un balisage plus riche : soit en intégrant directement du HTML dans un fichier Markdown, soit en ayant recours à des _shortcodes_ qui définissent une structure différente pour chaque format de sortie — nous détaillons ce comportement dans le dernier chapitre{{< renvoi chapitre="5" section="4" h3="5" >}}.

{{< code type="code" legende="Extrait du fichier source au format Markdown du texte \"C\'était aussi le printemps\" de Marie Céhère dans le recueil _Novendécaméron_" >}}

---
title: C'était aussi le printemps
auteur: Marie Céhère
auteur_id: marie-cehere
layout: oeuvres
description: 
date: 2021-04-13
image: images/feature-marie-cehere.png
credits_image: 
weight: "3"
commentaires: oui
publier: oui
---
{{</* epigraphe */>}}

Pour être le printemps, c'est bien le printemps.  
Il y a une clarté blonde dans le ciel,  
Des mottes brunes sous le ciel,  
Un parfum qui flotte autour des femmes  
Et des chatons gris sur les arbres<a class="appel-note" href="#fn:1" style="border-bottom: none; margin-left: .15em;" id="fnref:1"><sup>1</sup></a>.

{{</* /epigraphe */>}}

Ce sont les premiers vers d'un poème de Gyula Juhász que je lis en
avril, d'abord en français puis en hongrois, puis à nouveau en français.
Les mots commencent à résonner, d'un côté du miroir à l'autre. _"Tavasz
ez is, tavasz."_ dit la première phrase. Je m'attarde sur _"is"_, qui
signifie "aussi" dans la langue de Gyula Juhász: "c'est _aussi_ le
printemps, le printemps" écrit-il littéralement, à un siècle de moi, en
1920, à Budapest.

Le hongrois est une langue qui n'est parlée que par dix millions
d'habitants. Elle n'appartient pas à la famille indo-européenne. Elle ne
ressemble à rien de connu, n'offre aucun point d'appui, aucun repère. Sa
grammaire a été ma boussole, le dessin, et l'antidote à la fois, d'une
réalité désaxée.

{{</* petite-ellipse */>}}

{{< /code >}}

Les raisons du choix d'un générateur de site statique pour produire une édition numérique sont multiples.
La première est la légèreté de l'artefact obtenu, en effet le résultat est un ensemble de fichiers (principalement HTML et CSS), sans bases de données relationnelles : cela facilite l'hébergement, la migration et l'archivage d'un objet numérique comme un site web.
La deuxième est la maniabilité de la modélisation éditoriale, en effet à chaque page (et donc chaque œuvre du recueil) peut être attribué un gabarit différent, un _template_.
Ici ces gabarits sont élaborés avec l'aide de deux langages, il s'agit de HTML et de la bibliothèque de _templating_ propre au langage de programmation Go sur lequel Hugo est construit.
Les _templates_ sont une structuration des différentes données — qui peuvent être autant les textes, les métadonnées que des variables diverses —, et il est possible de _programmer_ avec une grande souplesse l'agencement des informations qui sont affichées sur les fichiers de sortie.
Le troisième intérêt d'un générateur de site statique, toujours dans le cas de la création d'une édition numérique, tient dans les qualités de l'environnement technique.
L'une de ces _qualités_ est la séparation entre les sources de l'édition — au format Markdown — et la modélisation des formats de sortie — grâce aux _templates_ déjà évoqués.
Toute la configuration repose sur des fichiers au format texte — format déjà évoqué dans un chapitre précédent{{< renvoi chapitre="2" section="3" >}} et présenté ensuite plus longuement{{< renvoi chapitre="4" section="2" >}} — ce qui permet de travailler dans n'importe quel environnement, et qui ouvre également la possibilité à l'utilisation du versionnement{{< renvoi chapitre="2" section="5" >}}.

Un générateur de site statique a la particularité de fonctionner de façon asynchrone, en deux étapes principales.
Tout d'abord la modification des contenus et la modélisation éditoriale, et ensuite la génération des formats de sortie.
Contrairement à un CMS{{< n >}}Un CMS, ou _Content Management System_, est un système de gestion de contenus, habituellement proposé sous la forme d'un logiciel avec une interface graphique.{{< /n >}} comme WordPress, un générateur de site statique sépare les étapes de modification des contenus, de production des formats de sortie et de publication (cette publication est hébergement dans le cas d'un site web).
Autre particularité importante : par défaut un générateur de site statique ne comporte pas d'interface graphique pour modifier les contenus ou les paramètres, tout passe par les fichiers textes qui sont les sources, et un terminal est nécessaire pour appeler le programme et ainsi générer l'artefact final.
Il est toutefois possible de _brancher_ un système sur Hugo pour proposer une interface graphique, il s'agit souvent de service tiers en ligne.
Hugo a par ailleurs des spécificités qui en font un bon candidat pour de l'édition numérique.

Hugo est un générateur de site statique qui se distingue par sa rapidité pour convertir et organiser des fichiers, par son absence de dépendances externes, et par sa capacité à produire plusieurs formats de sortie à partir d'une même source {{< cite "fauchie_fabriques_2021" >}}.
Si cette première spécificité semble peu intéressante pour un projet d'édition numérique, il faut tout de même noter que le fait de pouvoir regénérer le recueil dans son entièreté en quelques millisecondes permet de travailler localement en ayant une mise à jour immédiate à chaque modification — modifications qui concernent les contenus ou les modèles.
L'absence de dépendances à des bibliothèques de code externes — entendons par là qui doivent être téléchargées via Internet — est un point important.
Hugo peut être installé depuis un seul fichier binaire, ou être compilé depuis son code source (hébergé sur la plateforme GitHub), y compris sur des anciennes versions qui pourraient être pertinentes selon le moment dans lequel le projet a été créé.
Le code source de Hugo peut être facilement conservé pour permettre une émulation du projet à un temps _t_, c'est-à-dire en réinstallant le programme.
Ce code source comporte par ailleurs une documentation complète, cette dernière étant elle aussi versionnée, il est ainsi possible de naviguer dans le dépôt du code source pour obtenir une version précise du programme et la documentation correspondante.
Enfin, Hugo est pensé pour générer plusieurs formats de sortie à partir d'une même source, ce qui n'est pas le cas de la plupart des générateurs de site statique.
Hugo permet, en théorie, de produire des formats comme HTML, JSON, XML ou Markdown, l'intérêt étant surtout de générer plusieurs fichiers HTML pour une même source au format Markdown, via des modèles préconçus.
Cette fonctionnalité est très intéressante dans l'optique de produire plusieurs artefacts, en appliquant les principes du _single source publishing_ — abordés plus loin{{< renvoi chapitre="4" section="3" >}}.
Hugo a plusieurs avantages indéniables pour réaliser des éditions numériques.

Les contenus, ainsi que les fichiers permettant de modéliser et de configurer les artefacts, sont versionnés, c'est l'un des intérêts du format texte.
Git est le logiciel de gestion de versions utilisé pour ce projet, associé ici à la plateforme GitLab.com.
L'usage qui en est fait est très similaire à ce qui a été décrit avec le Pressoir{{< renvoi chapitre="2" section="5" >}}.
Outre la facilité d'usage dans les phases de développement, Git permet de retrouver tous les états du projet et de pouvoir déceler des éventuelles erreurs d'édition, soit pour les corriger soit pour revenir à un état antérieur du projet.
La plateforme GitLab apporte plusieurs fonctionnalités, dont le déploiement continu ou une API sur laquelle des services externes peuvent venir se connecter.
C'est le cas de l'interface graphique d'édition qui a été utilisée.

Disposer d'espaces d'édition qui correspondent aux capacités des différentes personnes impliquées dans le projet est important.
Ces _capacités_ sont toutefois délicates à définir, l'objectif n'étant pas non plus de proposer les mêmes outils — et les mêmes pratiques associées — tels qu'un traitement de texte.
Nous pouvons toutefois signaler qu'il s'agit de modifier du texte, avec comme nécessité une compréhension du langage de balisage léger Markdown, et comme condition une interface qui permet de guider le balisage et de gérer les documents — enregistrer ou modifier le statut (brouillon/publier).
L'objectif est de faire cohabiter un espace d'édition du texte sans devoir installer de logiciel — avec l'apprentissage qui l'accompagne souvent — avec un espace de développement où le format texte et les interfaces textuelles prédominent.
Nous l'avons dit, il est possible de _brancher_ un service tiers qui fait office d'interface graphique.
Pendant toute la durée du projet (du printemps 2021 à l'hiver 2023), le service Forestry.io{{< n >}}Le service a été supprimé en avril 2023, et remplacé en partie par Tina.io ([https://tina.io](https://tina.io)).{{< /n >}} a été utilisé, offrant un accès aux contenus via une interface graphique.

{{< figure type="figure" src="novendecameron-forestry-03.png" legende="Capture d'écran de Forestry.io pour le texte \"Vivre à deux\" de Hélène Rioux" >}}

Forestry.io est un éditeur de texte en ligne, c'est une application qui permet de gérer des paramètres liés à la gestion d'un générateur de site statique et à la prévisualisation des artefacts.
Le fonctionnement de Forestry.io est relativement simple, il dispose d'un éditeur de texte pour créer et modifier les différents fichiers (au format texte) via une interface graphique, rendant par exemple plus lisible la gestion des paramètres dans l'entête des fichiers Markdown des œuvres.
Louis-Olivier Brassard et Antoine Fauchié ont principalement eu recours au terminal ou à des éditeurs de texte pour interagir avec les contenus, la configuration ou le design du projet.
Ces deux espaces d'_édition_ ont permis aux différentes personnes d'interagir de façon autonome.
Ils sont par ailleurs accompagnés d'espaces de _publication_, créant ainsi des sas intermédiaires avant la mise en ligne finale.

Publier ne consiste pas seulement à rendre publique une édition — ici numérique —, mais aussi à produire des formes intermédiaires pour un public restreint, permettant de relire, tester et vérifier un artefact.
En partant du versionnement des contenus et de la modélisation du recueil — avec Git —, un système de déploiement continu a été mis en place.
Il s'agit de déclencher une action à chaque modification déclarée, en l'occurrence cette action est la génération, avec Hugo, de tout le site web ou de la version imprimable, puis d'héberger les fichiers générés pour les rendre disponibles.
Déployer un livre {{< cite "fauchie_deployer_2021" >}} est un acte à la fois original et logique.
Original, car il s'inspire de pratiques issues du développement logiciel — qui partage avec l'édition des processus de publication —, et logique puisque ce déploiement _numérique_ est une transcription de certaines modalités de l'édition — y compris imprimée.
Loin d'être une _homothétisation_, comme nous l'avons évoqué précédemment{{< renvoi chapitre="3" section="2" >}}, le processus à l'œuvre profite des possibilités de l'informatique.

{{< figure type="figure" src="deployer-schema-complet.jpg" legende="Schéma du déploiement continu pour le cas d'un livre numérique, extrait de l'article \"Déployer le livre\" précédemment cité" >}}

Pour l'éditrice et l'éditeur, disposer d'un site web _de développement_ pour relire le livre est d'une grande aide, autant au début du projet que lors des ultimes corrections après la mise en ligne publique.
Pour les concepteurs, c'est un moyen de contrôler le rendu final avant de le rendre disponible pour toutes et tous.

Cette chaîne d'édition, complète et complexe, est l'implémentation de plusieurs principes d'édition numérique, comme le _single source publishing_, la multimodalité ou encore la modularité.
La mise en place de ce processus technique n'est toutefois pas isolée, elle s'est faite en éditant les œuvres, en prenant en compte les particularités de chacune des contributions, et en maintenant une conversation continue avec l'éditrice et l'éditeur.


### 3.5.3. Des questionnements éditoriaux

L'édition — web et imprimée — du _Novendécaméron_ est un processus qui a soulevé plusieurs questionnements, depuis les rôles des personnes impliquées dans le projet jusqu'aux limites de la chaîne d'édition en termes de modélisation éditoriale, en passant par la gestion des erreurs d'édition.
Ces interrogations sont bien souvent liées à des obstacles techniques, que ce soit la gestion du texte ou l'application des principes du _single source publishing_, pour prendre deux exemples différents.
Ces questionnements ont été partagés entre les différents membres du projet pendant tout le processus, ils ont été consignés dans le journal évoqué précédemment.
Ils ont fait l'objet de discussions qui ont permis d'alimenter une réflexion plus globale sur l'édition, s'inscrivant pleinement dans les activités du GREN, et plus généralement dans les humanités numériques.
Cela a été l'occasion de remettre en cause certains des principes de l'édition _classique_, ainsi que de porter un regard critique sur la mise en place de nouvelles _façons de faire_.
Plusieurs des remarques qui suivent ont fait l'objet d'une communication en 2022 lors du colloque Humanistica à Montréal {{< cite "vallee_novendecameron_2022-1" >}}.

Si des espaces d'édition et de publication sont bien définis, les rôles, dans ce type d'organisation qui se veut horizontale, obligent néanmoins à la question suivante : qui valide quoi ?
La direction éditoriale repose sur Chantal Ringuet et Jean-François Vallée, alors que Louis-Olivier Brassard et Antoine Fauchié ont la responsabilité de l'implémentation technique des choix collectifs et de la continuité du fonctionnement du site web.
La direction éditoriale ne dispose pas de la possibilité de valider des modifications pour qu'elles soient visibles publiquement, seule la version de développement est automatiquement déployée, les concepteurs doivent intervenir pour déclencher la version de production.
Pourquoi ?
En cas d'erreur de balisage (dans les textes ou dans certains fichiers de configuration) il y a deux possibilités : soit le déploiement ne peut pas aboutir, et alors c'est la version précédente qui reste en ligne ; soit une partie du site est mal construite et le site dans son ensemble est rendu dysfonctionnel.
C'est donc pour prévenir des éventuelles erreurs _en production_ que des vérifications manuelles sont effectuées, erreurs qui par ailleurs requièrent souvent des connaissances approfondies dans le fonctionnement de Hugo — ce qui n'est pas le cas de Chantal et de Jean-François.
Des tests auraient pu être intégrés au déploiement, pour ainsi stopper toute mise à jour qui poserait problème, mais leur rédaction et leur implémentation auraient été trop longues.

L'édition se limite-t-elle à une intervention sur les œuvres elles-mêmes (textes, enregistrements sonores, photographies et illustrations) ?
Dans le premier chapitre dédié au livre{{< renvoi chapitre="1" section="2" >}} nous avons fait le constat que le travail sur la forme des artefacts éditoriaux fait partie intégrante de l'acte d'édition.
Ici le design du livre web et du livre imprimé consiste en des choix graphiques, mais aussi en la modélisation des formats, donc dans l'écriture des modèles ou _templates_.
Créer et adapter ces modèles n'est pas une tâche _parallèle_ au travail d'édition, elle en est constitutive.

{{< code type="code" legende="Modélisation de l'entête des œuvres dans la version imprimée du _Novendécaméron_" >}}

<header class="EnTeteOeuvre {{</* if .Params.cacher_titre */>}} -masquer{{</* end */>}}">
  <h1 class="EnTeteOeuvre__titre" id="{{</*.File.BaseFileName */>}}">{{</* .Title */>}}</h1>

  {{</*- with .Params.subtitle */>}}
  <div class="EnTeteOeuvre__sous-titre">
    {{</*- . | markdownify -*/>}}
  </div>
  {{</* end -*/>}}


  {{</*- $auteurs := .Params.auteur */>}}
    {{</*- if not (reflect.IsSlice $auteurs) */>}}
  {{</*- $auteurs = (slice .Params.auteur) */>}}
  {{</*- end -*/>}}

  <div class="EnTeteOeuvre__liste-auteurs">

    {{</*- range $index, $auteur := $auteurs */>}}
    {{</*- if $index */>}}, {{</* end -*/>}}{{</* séparateur */>}}
      <span class="EnTeteOeuvre__auteur">
        {{</*- $auteur -*/>}}
      </span>
    {{</* end -*/>}}{{</*/* range */*/>}}

    {{</*- if or .Page.Params.traductrice .Page.Params.traducteur */>}}
    <div class="EnTeteOeuvre__collaborateur">
      <span class="EnTeteOeuvre__auteur">
        {{</* .Page.Params.traductrice | default .Page.Params.traducteur */>}}
      </span>
    </div>
    {{</* end -*/>}}{{</* if */>}}
  </div>
</header>
{{< /code >}}

Dans le _template_ Hugo ci-dessus nous pouvons voir ce qui s'apparente à de la programmation : des fonctions permettent d'extraire des données dans les fichiers source grâce à des variables.
Il s'agit d'afficher, sur la première page des œuvres, le titre de l'ouvrage, le nom de l'auteur ou de l'autrice, et éventuellement le nom de la personne qui a traduit le texte.
Certaines conditions s'appliquent, et complexifient quelque peu ce modèle, notamment pour vérifier la présence d'un sous-titre ou pour prendre en compte des cas particuliers.
Des balises HTML structurent sémantiquement ce bloc de contenu, et des classes CSS sont utilisées pour réaliser une mise en forme graphique, voire pour gérer l'affichage de certains textes — c'est le cas de la classe `masquer` par exemple.
Sans faire une revue de code de ces quelques lignes, nous pouvons noter qu'il s'agit de traduire des instructions structurelles et graphiques via quelques lignes de programmation.
Si ces modélisations font partie de l'acte d'édition, il est toutefois difficile pour une personne ne faisant pas de programmation d'intervenir sur ce type de fichier.
Plusieurs options peuvent être imaginées pour inclure d'autres profils dans l'écriture de ces modèles, comme une documentation détaillée (pour expliquer chaque fonction, boucle ou variable) et une formation introductive.

Comme nous pouvons le voir ci-dessus, un effort important a été réalisé pour modéliser autant que possible la chaîne d'édition, et pour disposer de toutes les informations structurées afin de produire plusieurs artefacts à partir d'une même source.
Une information est inscrite une seule fois dans les fichiers de contenu ou dans les fichiers de configuration du recueil.
L'objectif est de ne pas avoir à indiquer à plusieurs reprises la même donnée — ce qui peut conduire à des actions répétées et fastidieuses ou à des erreurs dans le cas où cette donnée change.
Cela signifie par exemple que les tables des matières — sur les versions web et imprimée — sont générées à partir des titres renseignés dans chaque fichier d'œuvre.
Chaque fois qu'un titre est modifié, les tables des matières se mettent à jour _automatiquement_.
Cette modélisation permet aussi de prévoir plusieurs formats de sortie à partir d'une même source, c'est le principe du _single source publishing_ — abordé plus longuement par la suite{{< renvoi chapitre="4" section="4" >}}.
Nous avons toutefois rencontré plusieurs limites avec ce fonctionnement, soit dans la capacité à programmer certains modèles — plus par manque de temps — soit dans la possibilité de structurer les informations suffisamment précisément.
Avec l'expérience du _Novendécaméron_, les limites ont été principalement temporelles ; certains compromis pratiques nous ont éloigné de certains principes théoriques, tout en nous permettant de finaliser le projet.

L'absence de standardisation du langage de balisage léger Markdown engendre un certain nombre d'obstacles, d'autant plus lorsque plusieurs composants doivent interpréter ou convertir ce format.
Les erreurs apparaissent le plus souvent pendant le processus de fabrication des artefacts, leur gestion est grandement facilitée par un système de gestion de versions.
Les erreurs sont _versionnées_.
Si un problème survient et empêche la génération des différents formats, il suffit d'identifier le _commit_ à l'origine pour repérer l'erreur et la corriger.
Cela a permis notamment de découvrir un problème récurrent de balisage, problème que l'interface Forestry.io introduit lorsqu'il y a des appels de note.
Ces appels sont balisés en Markdown de cette façon : `du texte avec un appel de note ici[^appel]`.
Nous l'avons dit, Markdown est un langage non standardisé et permissif, et Forestry.io n'implémente pas Markdown de la même façon que Hugo, ainsi le balisage `[^appel]` n'est pas interprété et les crochets sont _échappés_ par Forestry.io pour éviter tout autre problème.
À chaque enregistrement d'un document qui comporte des appels de notes, Forestry.io transforme le balisage `[^appel]` en `\[^appel\]` annulant la signification et son interprétation par Hugo.
Quand bien même le versionnement nous permet de trouver ce problème et de le corriger, l'ambiguïté de Markdown est une source de contraintes qui pourraient être levées en maîtrisant mieux chacun des composants — éditeur, convertisseur, déploiement, etc.

Pour clore ces questionnements survenus pendant l'édition du _Novendécaméron_, une réflexion a servi de fil rouge tout au long de la préparation des versions web et imprimée du recueil, partagée avec les quatre membres de cette aventure.
À quel point le projet peut-il devenir une base générique pour de futures publications ?
Est-ce qu'il est possible, envisageable, ou même souhaitable de modéliser ce livre afin de pouvoir le dupliquer pour de futures publications au sein de la structure Ramures ou par d'autres initiatives extérieures ?
Si toute la chaîne d'édition a été pensée pour pouvoir être utilisée dans d'autres projets, plusieurs limites ont été rencontrées.
Certains développements ont été envisagés, notamment sur la création de modèles de pages ou de blocs de contenu, mais laissés de côté parce que trop chronophages.
Ensuite le livre présente trop de cas particuliers, il est ainsi très difficile d'isoler chacun de ces cas pour les modéliser, les documenter et rendre reproductible ces structurations.
Ce recueil est hétérogène de par ses œuvres diverses, qui vont de la prose à l'essai en passant par la poésie, l'illustration ou le journal.
Toutefois certains principes, dont la manière dont est construite la chaîne d'édition ou l'architecture des contenus, peuvent être repris pour d'autres projets.
Plutôt que de parvenir à modéliser totalement ce projet éditorial, nous avons partagé plusieurs aspects du projet pour permettre à d'autres de les réutiliser, par exemple le fait de fabriquer un fichier PDF à partir des technologies du Web, ou l'usage de l'impression à la demande pour produire les exemplaires imprimés — ici via la plateforme Lulu.com.

Le _Novendécaméron_ est un objet éditorial fabriqué avec une chaîne d'édition élaborée au fur et à mesure du processus d'édition.
C'est la principale spécificité de cette expérience éditoriale, au-delà de la dimension multimodale du projet ou des questions sous-jacentes qui ont émergé pendant les phases de fabrication.
Cette réflexivité est commune aux humanités numériques.
Cette chaîne d'édition, la modélisation des œuvres, et la définition de scénarios pour l'édition multimodale constituent des formats qui fondent et organisent le travail éditorial.
Nous devons désormais analyser ces questions de _format_, en tant qu'origine d'une démarche de modélisation du texte.