---
title: "Prototyper la Fabrique"
chapitre: 5
section: 5
bibfile: "data/05.json"
_build:
  list: always
  publishResources: true
  render: never
---

À la suite des différentes études de cas des quatre premiers chapitres, dont les objets peuvent constituer des _fabriques_, nous présentons deux prototypes en lien direct avec la recherche menée à travers cette thèse, comme deux preuves de concept qui prolongent l'analyse du phénomène de _fabrique d'édition_.
Il s'agit d'une part d'un dispositif d'écriture et de publication qui constitue un espace d'édition intermédiaire, entre l'outil d'écriture et le dispositif de publication ; et d'autre part de la chaîne d'édition mise en place pour écrire et produire les artefacts de cette thèse.
Dans les deux cas la question posée est la suivante : à quel point un phénomène de _fabrique d'édition_, à travers des choix techniques et leur imbrication avec des pratiques d'écriture et d'édition, révèle-t-il une vision du monde ?
Quelles sont les valeurs que la technique permet d'implémenter dans ce double mouvement de la _fabrique_ ?
C'est dans une démarche performative que nous entendons apporter une réponse à cette question.

Nous présentons et analysons tout d'abord une preuve de concept qui se situe entre l'espace de l'atelier de recherche et celui de la publication académique, il s'agit d'une chaîne de publication permettant de diffuser des textes ou des supports de façon temporaire.
Ensuite la question de la construction du sens est plus particulièrement abordée avec le cas de la thèse — occasion pour détailler certains fonctionnements qui ont conduit à des pratiques d'écriture ou de recherche bien spécifiques pour l'établissement de ce texte.
Enfin, nous détaillons plusieurs réflexions critiques déclenchées par ces deux expérimentations, et nous listons plusieurs des limites rencontrées avec ces approches et leurs implémentations.

Avant de présenter les deux objets numériques qui constituent cette étude de cas, nous revenons sur les éléments de la _fabrique_ qui peuvent être implémentés de diverses manières.
Quels sont les ingrédients de cette _fabrique d'édition_ ?
Tout en conservant un degré d'ouverture pour le concept de _fabrique_ et le phénomène de _fabrique d'édition_, voici les principes abordés dans la section précédente en lien avec les études de cas des différents chapitres : artefact, multi-formats, multimodalité et éditorialisation sont des résultats ou des fonctionnements attendus ; pour les atteindre plusieurs moyens sont possibles, comme les concepts de gabarits, de versionnement, de _single source publishing_ ou de modélisation éditoriale.
Cette double étude de cas est donc aussi un prétexte pour revenir sur ces différents éléments, avec, en creux, ce double phénomène d'édition d'un texte et de construction d'un processus qui permet de produire et de diffuser du sens.


### 5.5.1. Une preuve de concept multi-formats

Comment implémenter les principes du _single source publishing_ dans un prototype de processus d'écriture, tout en maîtrisant la modélisation éditoriale ?
Nous démontrons comment est constitué un acte d'édition sémantique multi-formats et multimodal en construisant un processus technique pour publier des textes _intermédiaires_ dans le champ académique.
L'objet de notre expérimentation est la publication multi-formats de textes ou de communications dans le cadre universitaire, afin d'obtenir différents artefacts facilement diffusables, et se situant _avant_ une publication scientifique.
Il s'agit donc de supports de conférences, d'ébauches d'articles ou de textes utiles pour des ateliers ou des cours, des documents communiqués mais non référencés, entre le carnet privé et la publication _publique_.
La place qu'occupe cette _fabrique_ aux côtés de l'atelier (privé), du carnet de recherche et de la thèse en fait son intérêt : il s'agit d'un dispositif de pré-publication qui nécessite néanmoins un travail d'édition.
Cette _fabrique_ de textes permet de générer trois formats et deux versions pour chacun des textes : une page web en flux, un support de présentation en diapositives, et un document paginé ; la page web et le document paginé sont homothétiques, le support de présentation réparti les informations dans des diapositives ou des contenus en notes cachées.
Plusieurs principes ont présidé au développement de ce projet, en lien avec le concept de _fabrique_, et notamment la limitation des dépendances informatiques afin de pouvoir facilement reproduire un environnement de travail, la _généricisation_ de la modélisation ou le fait de prévoir une duplication pour d'autres usages, ou encore la distinction nette entre les contenus et leurs modélisations.
Ces principes révèlent un positionnement fort par rapport aux outils habituels d'édition, nous privilégions en effet des technologies ouvertes et modulaires à des logiciels fermés et souvent monolithiques{{< n >}}Nous qualifions de "monolithiques" des logiciels conçus pour effectuer plusieurs tâches très diverses sans permettre de déconstruire et d'appréhender les fonctions qui permettent de réaliser ces tâches.{{< /n >}}.

Le projet, que nous intitulons fortuitement TXT, est une preuve de concept basée sur les outils du développement web.
Il consiste plus précisément en un balisage sémantique de textes, une conversion de ces fichiers vers d'autres langages de balisage, une organisation des fichiers convertis, et à la gestion d'un certain nombre de paramètres.
Tout cela dans la perspective éditoriale de produire des objets de plusieurs types : support de présentation, article ou support de cours.
Si plusieurs programmes sont nécessaires au fonctionnement de ce processus technique, il n'y a pas, au centre, de logiciel.
Le _programme_ Hugo, un générateur de site statique déjà présenté à la fois dans la section précédente{{< renvoi chapitre="5" section="4" h3="5" >}} et dans le chapitre 3{{< renvoi chapitre="3" section="5" >}}, est utilisé pour ces opérations.
Avant de les détailler nous présentons l'origine d'une telle initiative.

Plusieurs facteurs concomitants ont déclenché le besoin de développer une telle chaîne d'écriture ou d'édition{{< n >}}Nous considérons cette double caractéristique comme pertinente, puisqu'il y a bien un travail de préparation de texte en vue de diffuser un contenu.{{< /n >}}, et ainsi d'expérimenter en parallèle d'autres projets de recherche.
Il s'agit tout d'abord d'une nécessité de disposer d'un espace semi-public, avec la possibilité de partager une page web ou d'afficher un contenu depuis cette même adresse.
Ce sont des contenus qui ne sont pas indexés dans un carnet de recherche ou un blog, et qui ne nécessitent pas le parcours de publication scientifique relativement long.
Un entre-deux dont le format de la source doit être proche de ce qui précède et de ce qui peut suivre, respectivement : l'atelier de thèse {{< cite "fauchie_atelier_2020" >}} et le carnet de recherche{{< n >}}[https://www.quaternum.net/phd/](https://www.quaternum.net/phd/){{< /n >}}.
TXT se situe donc après la recherche et la prise de notes, il s'agit d'un contenu suffisamment formalisé pour pouvoir être partagé, et qui peut ensuite être transformé en billet pour le carnet de recherche, ou en article pour une revue ou des actes.
Ensuite l'objectif a aussi été d'expérimenter en dehors de Pandoc, utilisé dans plusieurs expérimentations au sein de la Chaire de recherche du Canada sur les écritures numériques, comme le Pressoir déjà présenté{{< renvoi chapitre="2" section="5" >}}.
Modéliser des artefacts pluriels avec autre chose que le convertisseur Pandoc s'est avéré nécessaire pour implémenter la _fabrique_.
Ces expériences ont convergé vers la construction d'un processus évolutif et durable.
Ce prototype a aussi constitué une preuve de concept pour enseigner plusieurs notions dans le domaine de l'édition numérique, comme les principes de l'édition multi-formats à partir d'une source unique ou la modélisation contextuelle{{< appel identifiant="modelisation-contextuelle" >}}.
TXT a aussi été utilisé pour construire un point d'accès unique à des supports de cours dans plusieurs formats.

Pour réaliser à la fois les actions de conversion, de transformation et d'organisation pendant le processus d'édition, l'usage d'un générateur de site statique a été utilisé.
Cela permet de séparer les étapes d'écriture, d'édition et de publication, et de disposer d'un artefact web qui nécessite peu de ressources pour être diffusé — puisqu'il s'agit de fichiers HTML et CSS sans base de données.
Parmi les centaines de _générateurs de site statique_, Hugo présente plusieurs avantages et notamment le fait de pouvoir être installé à partir d'un seul fichier, ou encore de produire plusieurs formats à partir d'une même source.
La possibilité d'installer Hugo à partir d'un fichier ou d'un _magasin_ d'applications est particulièrement utile pour mettre en place facilement un espace d'édition et de publication quel que soit le dispositif informatique (ordinateurs et serveurs).
La chaîne d'édition peut donc être _émulée_, par exemple via les GitHub Actions ou les GitLab Pages, donnant la possibilité de constituer des environnements virtuels de travail sans besoin d'installer de programme.

Pour produire simultanément les trois formats (web, présentation et paginé), une fonctionnalité incluse dans Hugo est utilisée, elle consiste à produire plusieurs formats d'un même contenu via des déclarations et des gabarits associés.
Hugo génère par défaut le format HTML, et supporte également plusieurs formats de balisage, tels que XML, JSON, TXT ou YAML.
Hugo n'est pas un convertisseur, et il propose donc bien moins de possibilités que Pandoc.
Son intérêt réside plutôt dans le fait de produire plusieurs versions HTML distinctes, en appliquant des gabarits différents via l'utilisation d'un langage de modélisation puissant.
Dans notre cas il s'agit de disposer de trois formats HTML : un format en flux (page web _classique_), un support de présentation en diapositives via l'utilisation de Reveal.js{{< n >}}[https://revealjs.com](https://revealjs.com){{< /n >}}, et un format web paginé via l'utilisation de Paged.js.

{{< code type="code" legende="Extrait d'une configuration au format TOML avec l'indication d'un format supplémentaire et les formats de sortie attendus selon les types d'objets produits" >}}
[outputs]
  home = ["HTML"]
  section = ["HTML"]
  page = ["HTML", "presentation", "impression"]

[outputFormats]
  [outputFormats.presentation]
    mediaType = "text/html"
    rel = "presentation"
    baseName = "presentation"
  [outputFormats.impression]
    mediaType = "text/html"
    rel = "impression"
    baseName = "impression"
{{< /code >}}

Dans la figure ci-dessus les deux paramètres "outputFormats" et "outputs" décrivent respectivement le ou les formats en plus de celui par défaut (HTML) et les types d'objets concernés par ce ou ces formats additionnels.
Le paramètre `rel = "impression"` précise que s'il existe un gabarit qui finit par `impression`, tel que `single.impression.html` pour le modèle d'une page, alors il est appliqué pour ce format spécifique.
Il en est de même pour les _shortcodes_, qui peuvent donc être déclinés en autant de formats de sortie.
Ce mécanisme relativement simple, liant la déclaration des formats et l'appel des gabarits appropriés (_shortcodes_ inclus), constitue en soi une modélisation éditoriale puissante.
Le travail d'édition réside alors dans la définition de ce comportement (quels formats ? quels intitulés ?) et dans la description et la réalisation des gabarits associés.

{{< figure type="figure" src="txt-flux.png" legende="Capture d'écran de la version web en flux d'une communication donnée lors du colloque du CRIHN en 2023" >}}

{{< figure type="figure" src="txt-diapositive.png" legende="Capture d'écran de la version web en diapositives d'une communication donnée lors du colloque du CRIHN en 2023" >}}

{{< figure type="figure" src="txt-pages.png" legende="Capture d'écran de la version web en diapositives d'une communication donnée lors du colloque du CRIHN en 2023" >}}

Cette expérimentation se concentre sur la gestion des formats de sortie, et n'explore que très peu les possibilités de balisage sémantique fin des contenus — ce que fait le dispositif mis en place pour la thèse et présenté juste après.
Outre cet espace de publication semi-public, TXT a aussi été utilisé pour rassembler les supports et les ressources pour des cours donnés à l'Université de Montréal, ainsi que pour construire les premières versions du site web{{< n >}}[https://debogue.ecrituresnumeriques.ca/archives/](https://debogue.ecrituresnumeriques.ca/archives/){{< /n >}} de "Déb\/u\/o\/gue tes humanités", un cycle de formations données par la Chaire de recherche du Canada sur les écritures numériques — dont l'auteur a l'un des initiateurs des premiers cycles.

Ce prototype a réellement ce statut d'un _premier exemplaire_, il fait office de preuve de concept dans les dimensions multimodale et de multi-formats d'une _fabrique d'édition_, portant des valeurs et constituant une posture vis-à-vis de l'usage de la technique dans une pratique d'écriture et d'édition.
Plusieurs des fonctionnalités proposées ici sont des détournements de ce pour quoi ce générateur de site statique a été conçu, ce caractère non conventionnel génère des résultats non prévus — tels que l'utilisation des _shortcodes_ pour modéliser des artefacts — ou des compromis — comme le langage de modélisation relativement strict de Hugo.
Cette chaîne d'édition ou de publication est un _travail en cours_, utile pour relever les limites dans un possible passage à un niveau collectif — et non plus seulement individuel — et les modifications qui seraient nécessaires.
Les principes appliqués auraient pu l'être avec d'autres choix techniques, nous retenons toutefois trois dimensions épistémologiques permises par Hugo.
La limitation des dépendances, avec le fait de pouvoir installer Hugo sans autre programme ou logiciel, permet une installation ou une émulation dans des environnements informatiques très divers, sans la nécessité d'installer de nombreux programmes ou logiciels — ces derniers ayant parfois eux-mêmes des dépendances.
Avec son langage de gabarit assez simple et bien documenté, Hugo est un bon moyen de prototyper des processus de publication.
Enfin, la génération de formats multiples, et l'organisation des gabarits et des _shortcodes_ qui va avec, permet d'envisager immédiatement la production simultanée de plusieurs formats (formes _et_ versions).
À la suite de cette expérimentation nous avons mis en place une _fabrique_ qui prolonge plusieurs de ces aspects.


### 5.5.2. Modéliser le sens dans une thèse

Cette thèse est performative, elle expérimente les concepts présentés et les principes avancés, l'artefact que vous parcourez ou lisez est en soi une preuve de concept de l'hypothèse défendue, principalement autour de la _fabrique_ {{< appel identifiant="fabrique" >}} et de la _fabrique d'édition_ {{< appel identifiant="fabriquededition" >}}.
À la suite des différents projets éditoriaux présentés dans les études de cas qui ponctuent les quatre premiers chapitres, nous expérimentons une nouvelle chaîne d'édition, une _fabrique_, cette fois pour un objet textuel complexe qu'est une thèse de doctorat.
Cela fait suite à la _fabrique_ précédente, tant en termes d'expérimentation que de flux éditorial : il s'agit d'une part de prolonger cette idée d'une génération simultanée de plusieurs formats à partir d'une source unique, ainsi que de mettre en place un balisage suffisamment avancé permettant d'identifier les concepts et définitions ; et d'autre part de faire suite à cet espace intermédiaire de publication pour cristalliser le sens.
L'objectif est donc autant de produire plusieurs artefacts que d'attribuer une valeur sémantique à des segments de texte pour les identifier et les manipuler.
Avec cette _fabrique d'édition_ nous répondons à la question suivante : comment modéliser le sens dans une thèse ?

La thèse est un travail d'édition — en termes d'opérations sur le texte et non de diffusion —, et pas seulement d'écriture.
S'il ne s'agit pas d'un processus pour aboutir à une monographie éditée par une structure d'édition, plusieurs étapes sont toutefois communes : révision et structuration du texte, respect de contraintes éditoriales, mise en forme selon des règles précises, validation par un comité, parcours bibliographique lors de l'enregistrement, stratégie de diffusion, etc.
Dans le cas de cette thèse, la publication en est une partie intégrante, avec le travail sur la forme des artefacts — et notamment les formats web et imprimé — mais aussi la mise à disposition des sources et des versions{{< n >}}[https://src.quaternum.net/t](https://src.quaternum.net/t){{< /n >}}.
La mise en place d'un processus spécifique d'écriture et d'édition répond à une exigence en termes de construction d'une pensée, pensée qui est constituée autant par le texte, les artefacts qui le contiennent, la forme de ces artefacts, ou les gabarits nécessaires à leur production.
Afin de détailler les implémentations techniques, nous explicitons comment l'écriture, l'édition et la mise en place des briques techniques sont articulées.

Après la phase de recherche qui s'est déroulée de septembre 2019 à juillet 2022, l'écriture de la thèse s'est enclenchée comme une _fabrique_, où le dispositif d'écriture et d'édition a été mis en place de façon totalement imbriquée avec l'écriture des textes.
Dans notre cas, et au-delà de la dimension performative, il n'aurait pas été possible de construire une pensée sans également concevoir cette chaîne.
Prenons quelques exemples de cette articulation entre l'écriture du texte et l'écriture du code.
Avant cela notons que le modèle adopté ici est très similaire à d'autres déjà présentés : le texte est _balisé_ avant d'être converti et transformé pour constituer plusieurs formes et versions d'artefacts.
Ce n'est toutefois pas parce que ce modèle se répète qu'il est le seul à pouvoir être envisagé.

Tout d'abord la structure même des fichiers a évolué, elle a suivi un déroulement sémantique consistant à identifier plus facilement chaque texte et ses particularités.
Le découpage a d'abord été réalisé afin que pour chaque chapitre corresponde un seul fichier.
Une division plus fine, c'est-à-dire un fichier par _section_, a ensuite permis une meilleure segmentation, chaque section ayant ses propres objectifs à l'intérieur d'un même chapitre — approche conceptuelle, critique, étude de cas illustrative, proposition conceptuelle et critique de cette proposition dans une deuxième étude de cas.
De cinq fichiers nous aboutissons à vingt-cinq éléments correspondant à chaque section, plus un fichier (`_index.md`) pour l'introduction de chaque chapitre :

{{< code type="code" legende="Structure de la thèse, en dossiers et fichiers, sans l'introduction et la conclusion" >}}
.
├── 01
│   ├── 01-01.md
│   ├── 01-02.md
│   ├── 01-03.md
│   ├── 01-04.md
│   ├── 01-05.md
│   └── _index.md
├── 02
│   ├── 02-01.md
│   ├── 02-02.md
│   ├── 02-03.md
│   ├── 02-04.md
│   ├── 02-05.md
│   └── _index.md
├── 03
│   ├── 03-01.md
│   ├── 03-02.md
│   ├── 03-03.md
│   ├── 03-04.md
│   ├── 03-05.md
│   └── _index.md
├── 04
│   ├── 04-01.md
│   ├── 04-02.md
│   ├── 04-03.md
│   ├── 04-04.md
│   ├── 04-05.md
│   └── _index.md
└── 05
    ├── 05-01.md
    ├── 05-02.md
    ├── 05-03.md
    ├── 05-04.md
    ├── 05-05.md
    └── _index.md
{{< /code >}}

Ce qui peut s'avérer un _détail_ est en fait essentiel dans la construction de la pensée, chaque élément étant identifiable, facilitant le versionnement (quelles modifications à quelle étape), les renvois (lien vers une étude de cas ou une proposition conceptuelle) et les relectures (découpage plus fin).
Ainsi chaque section correspond à un objet particulier et peut faire l'objet d'un traitement spécifique : les sections 1, 2 et 4 sont des parties théoriques où des concepts sont présentés ou construits avec de nombreuses références bibliographiques, alors que les sections 3 et 5 sont respectivement une étude de cas d'un objet éditorial puis une étude de cas d'un objet sur lequel nous avons travaillé.

La conversion des fichiers source, au format Markdown pour les textes, a été possible avec Pandoc puis avec Hugo, reflétant l'évolution des pratiques d'écriture au cours de l'avancement de la rédaction.
Le texte a d'abord été peu balisé, le traitement sémantique plus fin est intervenu notamment lors de l'identification des définitions.
Pandoc, en tant que convertisseur et saveur Markdown, permet d'attribuer des classes personnalisées sur des éléments de ligne ou de bloc, lors d'un export au format HTML ces classes concordent avec des règles de mise en forme via le langage CSS.
L'objectif pendant l'écriture et l'édition est de pouvoir facilement intervenir sur la structure HTML et non uniquement sur l'attribution d'une mise en forme.
Hugo permet justement d'appliquer une structure spécifique via l'usage des _shortcodes_ comme nous l'avons déjà expliqué{{< renvoi chapitre="5" section="4" h3="5" >}}.
Pour la thèse nous avons mis en place un mécanisme afin d'identifier les définitions, les figures, les extraits de code, les citations longues ou les renvois.

{{< code type="code" legende="_Shortcode_ `renvoi.html` utilisé dans cette thèse pour construire les renvois vers d'autres chapitres et sections, dans la version web" >}}
{{- $p := .Get "chapitre" | int -}}
{{- $chapitre := where .Site.Pages "Params.chapitre" $p -}}
{{- $sp := .Get "section" | int -}}
{{- $section := where .Site.Pages "Params.section" $sp -}}
{{- $source := $chapitre | intersect $section -}}
{{- range $source -}}
	<span class="renvoi">Voir <a href="/chapitre-0{{ .Params.chapitre }}/{{ if eq .Params.section 0 }}{{ else }}#{{ .Params.chapitre }}-{{ .Params.section }}{{ end }}">{{ .Params.chapitre }}.{{ if eq .Params.section 0 }}{{ else }}{{ .Params.section }}.{{ end }} {{ .Title | markdownify }}</a></span>
{{- end -}}
{{- "" -}}
{{< /code >}}

En plus de ces courts balisages personnalisés (et _contextualisés_), Hugo intègre la possibilité de paramétrer le rendu de plusieurs éléments sémantiques comme les niveaux de titre, les liens ou les images{{< n >}}[https://gohugo.io/templates/render-hooks/](https://gohugo.io/templates/render-hooks/){{< /n >}}.
Cela signifie, pour les titres _dans_ les textes, qu'il est possible d'ajouter des paramètres dans le HTML comme une ancre (pour pointer un lien vers cet élément) ou un identifiant (utile pour identifier un élément par exemple pour la construction d'une version paginée).
Le fait de pouvoir jouer avec les éléments de structure et non uniquement de mise en forme apporte beaucoup dans la construction du sens même, permettant d'identifier syntaxiquement un mot, une phrase ou un bloc de texte pour ensuite lui attribuer une valeur sémantique en HTML.

Dans cette perspective sémantique, les textes ont été rédigés en même temps que les différents gabarits permettant de modéliser les artefacts — dans deux formats principaux que sont le format web en flux et le format PDF paginé.
Le principal gabarit a ainsi été celui des chapitres, agrégeant les différentes sections représentées chacune par un fichier.
Les informations présentes dans l'entête de chacun de ces fichiers a permis de préciser la place de la section dans le chapitre et le type de section (conceptualisation, étude de cas, etc.).

{{< code type="code" legende="Extrait du gabarit de pages des chapitres pour la version web" >}}
<article>
  <section>
  {{ partial "content.html" .Content }}
  </section>
  {{- range .Paginator.Pages.ByParam "section" }}
  <section id="{{ .Params.chapitre }}-{{ .Params.section }}">
    <div class="cacher"></div>
    <span class="navigation">{{ .Params.section }}.</span>
    <h2 id="{{ .Params.chapitre }}{{ .Params.section }}-{{ .Title | anchorize }}"><span class="section-type">{{ .Params.type }}</span><a href="#{{ .Params.chapitre }}{{ .Params.section }}-{{ .Title | anchorize }}" class="anchor">#</a>{{ .Params.chapitre }}.{{ .Params.section }}. {{ .Title | markdownify }}</h2>
  {{ partial "content.html" .Content }}
  </section>
  {{- end -}}
</article>
{{< /code >}}

Les quelques lignes de code ci-dessus récupèrent le contenu du fichier `_index.md`, soit l'introduction du chapitre, pour ensuite rassembler les sections (dans l'ordre) et ajouter des éléments syntaxiques tels que les titres et des identifiants, ainsi que des éléments de mise en forme en attribuant des classes spécifiques.
Le langage de modélisation utilisé par Hugo est, pour cette opération, relativement simple à utiliser.
La rigueur intrinsèque de cette grammaire n'empêche pas, toujours dans cette situation, de pouvoir personnaliser la structure via l'attribution de données dans l'entête des différents fichiers — par exemple `.Params.section` qui est déclarée dans chacun des fichiers des sections.

Le croisement de l'écriture du code (qui permet le fonctionnement de la chaîne d'édition) et de l'écriture des textes (qui forment les chapitres de la thèse) est aussi visible dans le développement de certaines fonctionnalités comme l'appel des définitions.
Il s'agit de pouvoir indiquer qu'un terme ou une expression a déjà été définie, et de renvoyer soit vers le contexte de cette définition, c'est-à-dire vers un chapitre spécifique, soit vers la liste de toutes les définitions.
Un mécanisme de mémorisation des informations balisées dans le texte est donc nécessaire.
Le développement d'un tel fonctionnement a par exemple été réalisé en même temps que la rédaction de la définition du concept de _fabrique_ et du phénomène de _fabrique d'édition_.

{{< code type="code" legende="_Shortcode_ `definition.html` pour identifier et enregistrer les définitions conceptuelles de la thèse, pour la version web" >}}
{{ $leid := .Get "id" }}
{{ $lintitule := .Get "intitule" }}
{{ with $captureName := .Get "type" }}
  {{ with $.Inner }}
    {{ $id := printf "%d" $.Ordinal }}
    {{ $gent := dict "intitule" $lintitule "id" $leid "contenu" (string .) }}
    {{ $.Page.Store.SetInMap $captureName $id $gent }}
  {{ else }}
    {{ errorf "The %s shortcode requires 'Inner' content. See %s" $.Name $.Position }}
  {{ end }}
{{ else }}
  {{ errorf "The %s shortcode requires a single positional parameter. See %s" $.Name $.Position }}
{{ end }}
<section>
  <p class="definition" id="{{ .Get "id" }}"><span class="libelle">Définition&nbsp;</span><span class="intitule">{{ .Get "intitule" }}</span></p>
<p>{{ .Inner | markdownify }}</p>
</section>
{{< /code >}}

Ces quelques lignes de code décrivent la façon dont les informations issues d'un balisage spécifique peuvent être enregistrées, ici avec la fonction `Store` de Hugo.
Voici le balisage dans le texte qui permet d'identifier une définition :

{{< code type="code" legende="Exemple d'un bloc de texte balisé avec le _shortcode_ présenté précédemment" >}}
{{</* definition type="definition" intitule="Fabrique d'édition" id="fabriqueedition" */>}}
L'idée principale de la fabrique d'édition est l'imbrication et la réflexivité du travail sur le texte et de la constitution d'un processus technique permettant ce travail.
Le choix, l'agencement voir le développement des outils d'édition sont réalisés en même temps que le texte est sélectionné, structuré, corrigé, mis en forme et publié.
Il ne s'agit pas de deux calques qui se superposent mais d'un entremêlement de micro-actions qui donnent lieu à l'acte éditorial.
La forme de l'artefact éditorial est façonné par le processus technique, et ce dernier est mis en place en fonction du projet d'édition.
{{</* /definition */>}}
{{< /code >}}

Ce _shortcode_ permet d'appliquer un balisage HTML spécifique, il y a ici autant le principe de balisage de plusieurs lignes de texte que l'ajout de paramètres pour identifier cette définition.
Le paramètre _intitulé_ (`intitule`) est utilisé pour afficher un titre, et le paramètre _identifiant_ (`id`) permet de générer une ancre pour pointer directement vers la définition dans la version web ou pour calculer le numéro de page concernée dans la version imprimée.
Une définition conceptuelle est donc élaborée dans le texte de la thèse sur deux plans : un sens est explicité avec des mots et une syntaxe _calculable_ est donnée avec un balisage sémantique.
Cette portion de texte est rendue lisible pour les humains et pour les machines, l'un ne fonctionnant pas sans l'autre dans les choix techniques qui ont été faits ici.
L'écriture et l'édition de la thèse dépendent de ces deux plans.
La recherche théorique et la recherche technique sont entremêlées, elles se répondent sur leurs potentialités syntaxiques et sémantiques respectives.

Enfin, un travail de mise en forme des artefacts est réalisé conjointement avec les phases de relecture, en utilisant le langage CSS pour les versions web et imprimée.
Les relectures individuelles puis collectives sont des moments importants pour composer les formes auxquelles les personnes (dont l'auteur de cette thèse) ont accès.
Le soin apporté aux artefacts est décisif pour faciliter la lecture, par exemple pour que les paragraphes puissent être identifiés avec un numéro unique (par chapitre) ou que le texte et les citations soient suffisamment lisibles.

{{< figure type="figure" src="these-paragraphe-citation.png" legende="Capture d'écran d'une citation longue suivie d'un paragraphe dans la version web de la thèse" >}}

L'usage de CSS ne se limite pas à l'application d'un rendu graphique, mais aussi à la génération d'éléments comme c'est le cas avec la numérotation des paragraphes.
L'élaboration des feuilles de styles CSS participe donc également à la fabrication du sens.

Pour clore la présentation de cette fabrique d'édition et avant d'apporter un double regard critique à ces deux expérimentations, TXT et la thèse, notons quelques points importants.
La chaîne d'édition de cette thèse a d'abord bénéficié du travail engagé sur TXT, notamment les mécanismes de modélisation des artefacts, même si ici tout a été déconstruit et recréé de zéro.
Nous retrouvons également ce lien ténu entre la constitution d'une chaîne d'édition ou de publication, l'écriture de textes scientifiques, et la formalisation d'artefacts divers.
Loin d'être un modèle reproductible, il s'agit surtout d'une entreprise de construction du sens, et de dévoilement de l'écriture et de l'édition, suscitant un certain nombre de réflexions critiques que nous allons désormais explorer.


### 5.5.3. Réflexions critiques sur des prototypes de _fabriques d'édition_

Ces deux expérimentations soulèvent plusieurs réflexions critiques, directement liées au concept de _fabrique_ et au phénomène de _fabrique d'édition_, telles que l'usage d'un outil comme Hugo, l'apport de la modélisation contextuelle, la possible illusion du _single source publishing_, la reproductibilité d'un tel modèle, la place du chercheur dans la production d'un programme et non d'une solution, et enfin le positionnement humaniste dans un contexte numérique.

La place importante qu'occupe Hugo est à la fois déterminante dans les possibilités de modélisation et de multi-formats, et conjoncturelle en cela que ce programme peut être substitué par un autre.
En effet il est possible d'imaginer une implémentation similaire avec d'autres programmes ou logiciels, et notamment avec le convertisseur Pandoc.
Certains détails dans cette mise en place seraient forcément différents, et l'utilisation de programmes tiers tels que Make {{< cite "mecklenburg_managing_2005" >}} serait par ailleurs nécessaire pour orchestrer les transformations, mais une modélisation équivalente est envisageable.
Pourquoi alors utiliser Hugo plutôt que Pandoc qui est sans conteste un programme créé par et pour des universitaires ?
Pour deux raisons.
D'une part Hugo comprend des fonctionnalités tels que la génération simultanée de plusieurs formats et la modélisation contextuelle avec les _shortcodes_ ; d'autre part Hugo est un programme pensé pour publier des documents numériques et plus spécifiquement des sites web, dont l'application dans le champ académique relève d'un usage non conventionnel.
C'est ce pas de côté qui génèrent plusieurs frictions et compromis que nous considérons comme essentiels pour penser et critiquer des modèles éditoriaux.
En allant chercher des initiatives techniques dans d'autres champs éditoriaux (ici le Web), il est possible d'envisager des usages nouveaux, de repenser certains acquis et ainsi d'enrichir les possibles lorsque nous considérons les modèles éditoriaux.
Par ailleurs, comme nous l'avons vu dans plusieurs études de cas précédentes, Pandoc est déjà largement utilisé, il est essentiel d'explorer d'autres voies pour ne pas enfermer nos pratiques, quitte à revenir à Pandoc ensuite.
Pandoc, comme tout programme ou logiciel, implique un modèle de pensée spécifique.
Si ce modèle s'avère particulièrement ouvert et riche avec Pandoc, comme nous l'avons déjà vu{{< renvoi chapitre="4" section="3" h3="5" >}}, son implémentation technique conduit toutefois à certains choix.
Nous retrouvons ici un point soulevé par Vilèm Flusser sur les questions d'apprentissage et de créativité, nécessaires pour retrouver un équilibre avec les machines.

La modélisation contextuelle utilisée ici permet d'envisager des scénarios liés entre eux, et donc de construire un acte éditorial qui se déploie selon plusieurs modalités correspondant à plusieurs formats ou formes.
Le fonctionnement des _shortcodes_ de Hugo, ajouté à la dimension multi-formats, est une occasion de formaliser clairement le comportement sémantique de textes et de sous-éléments de ces textes.
Un même texte peut être rédigé et structuré en envisageant plusieurs artefacts différents, l'écriture s'incarne dans ces modélisations.
Ce fonctionnement permet en outre de déterminer une structure personnalisée et néanmoins standard dans un environnement HTML, tout en conservant un balisage lisible dans la source.
Enfin, la modélisation contextuelle peut s'appliquer de plusieurs manières ; il est possible de convertir le balisage agrémenté des _shortcodes_ en une autre syntaxe, comme le _processing models_ de la TEI que nous avons déjà mentionné{{< renvoi chapitre="5" section="4" h3="5" >}}.
L'usage de Hugo et de ses _shortcodes_ est donc une occasion de réaliser une preuve de concept du principe de la modélisation contextuelle.

L'application des principes du _single source publishing_ — ou édition multi-formats à partir d'une source unique{{< appel identifiant="singlesourcepublishing" >}} — comme tentative d'une modélisation abstraite idéale est un leurre, et peut représenter un enfermement théorique.
Il faut plutôt considérer ces principes comme une occasion de formaliser des pratiques d'édition.
Dit autrement, mettre en place une chaîne d'édition qui intègre la génération de plusieurs formes et formats tout en conservant une source unique est une invitation à examiner des _façons de faire_ plutôt qu'un modèle idéal.
Nicolas Taffin précise les limites d'une vision fonctionnaliste :

{{< citation ref="taffin_typotherapie_2023" page="161" >}}
Le paradoxe, ou plutôt la tension, reste celle-ci : comment d'un côté construire un balisage sémantique du texte, un modèle abstrait de toute forme, qui pourrait s'incarner dans n'importe laquelle d'une part, et de l'autre porter l'attention nécessaire à la composition de chaque "page" qui doit permettre de prendre le contrôle sur le moindre détail, un paragraphe, une ligne, un mot, une césure pour en manifester visuellement la structure.
{{< /citation >}}

L'enjeu des expérimentations présentées ici est non pas de proposer des modèles duplicables mais de représenter des terrains d'expérimentation.
Il s'agit donc non pas de considérer le _single source publishing_ comme un objectif à atteindre _absolument_, dans une perspective d'automatisation plus grande, mais plutôt d'observer les modifications dans les méthodes de travail ou dans l'organisation du flux éditorial qui adopte ces principes.
Nous parlons ainsi plus volontiers de l'opportunité de questionner des pratiques existantes et futures.

Ces deux expérimentations n'ont pas été construites comme des modèles à dupliquer telles quelles, et ne peuvent en constituer.
L'effort de lisibilité dans la publication des sources de TXT{{< n >}}[https://src.quaternum.net/txt.quaternum.net](https://src.quaternum.net/txt.quaternum.net){{< /n >}} et de la _fabrique_ de cette thèse — qui consiste essentiellement en des modélisations et en une série de paramétrages avec Hugo — réside uniquement dans la volonté de permettre une compréhension de ces objets processuels, par exemple pour pouvoir envisager d'autres implémentations de principes similaires.
La _généricisation_ est un objectif impossible à atteindre, comme nous l'avons vu avec l'étude de cas du _Novendécaméron_ qui présente trop de cas particuliers{{< renvoi chapitre="3" section="5" h3="3" >}}.
S'agit-il de parvenir à un "modèle abstrait de toute forme" comme le dit plus haut Nicolas Taffin ?
Il n'est ni souhaitable ni possible de mettre en place un modèle qui conviendrait pour nombre d'usages, le projet TEI le prouve avec suffisamment d'acuité : la complexité est telle que l'effort consenti pour son usage empêche toute modification de cette architecture aussi puissante que complexe.
L'intérêt de l'exposition de notre modélisation est de démontrer comment la thèse est, dans notre cas, une édition de textes et la construction d'un processus technique, ou la construction d'un processus technique et une édition de textes.

Fabriquer une édition, éditer une fabrique : ce double mouvement nous amène à la position du chercheur dans la constitution d'un modèle éditorial expérimental, il convient en effet d'éviter de verser dans la production d'une solution voire d'un produit, et de conserver la dimension exploratrice d'un tel projet _scientifique_.
La reproductibilité d'une modélisation est attendue, mais elle ne doit pas être confondue avec la mise à disposition d'un _produit_, d'autant plus au niveau individuel comme le nôtre{{< n >}}Même si des collaborations ou des interventions extérieures ont pu permettre de résoudre un certain nombre de problèmes ou de relever plusieurs défis.{{< /n >}}, quand bien même une certaine injonction existe à mettre à disposition des solutions prêtes à l'emploi.
Nous adoptons la position selon laquelle la constitution de ces deux chaînes d'édition, et les modélisations correspondantes, ont comme fonction de nourrir des réflexions théoriques et pratiques.
Ces dernières conduisent à l'élaboration d'objets éditoriaux finalisés, via l'exposition d'un certain nombre de mécanismes dont nous pouvons ainsi prévoir une reproductibilité — ce qui diffère du fait de vouloir réutiliser ces processus techniques sans les adapter ou les modifier en profondeur.
Notons que si ces prototypes sont fortement améliorables, ils constituent tout de même des processus ou des objets fonctionnels.

Enfin il s'agit de constater l'apport en termes d'apprentissage : en effet les compétences développées durant le processus de conception et de développement de TXT et de la _fabrique_ de la thèse font partie intégrante du déroulement.
Ce qui nous amène aux enjeux relatifs à la connaissance ou la maîtrise de la programmation.
Les chercheurs et les chercheuses en humanités numériques doivent savoir coder, dans le sens où il est nécessaire de décomposer les outils que nous utilisons comme l'explique Quinn Dombrowski {{< cite "dombrowski_does_2022" >}}.
Nous considérons en outre que l'approche du _creative coding_, comme nous l'avons abordé à propos des designers dans le champ du graphisme{{< renvoi chapitre="5" section="2" h3="4" >}}, est pertinente aussi dans des pratiques de recherche.
Il faut s'approprier des langages, par exemple ici le langage de _templating_ de Hugo hérité de celui du langage de programmation Go, sans pour autant devoir maîtriser la programmation elle-même.
Cela signifie identifier une communauté et des personnes ressources, pour pouvoir solliciter des compétences et ensuite agréger des façons de faire sans reproduire aveuglément des fragments de code.
Il faut alors être en mesure de formuler un problème, notamment pour recourir à de l'aide lorsque cela est nécessaire.
Cela signifie aussi en retour apporter un soutien aux personnes de cette communauté, quand cela est possible.
Dans notre cas le travail de prototypage s'est construit en apportant un regard critique continu, notamment via l'espace d'échanges de la Chaire de recherche du Canada sur les écritures numériques et des membres qui la constituent, et via la publication d'articles dans des revues ou en présentant des résultats intermédiaires lors de communications.
La réflexivité inhérente à l'approche des humanités numériques est un apport capital pour conserver un regard critique.

Les questions de choix des outils, de scénarisation des modélisations éditoriales, de limites de principes techniques, de reproductibilité, des résultats produits et de réflexivité critique participent toutes de cette _fabrique_.
Ces questions constituent des points d'ancrage d'une réflexion sur la manière dont le sens est produit dans une activité d'édition.
Nous abordons désormais plusieurs interrogations comme ouverture à la suite de cette double étude de cas.


### 5.5.4. Ouverture et limites

Quel est le degré d'_ouverture_ d'une _fabrique d'édition_ ?
Si jusqu'ici nous avons mis en avant plusieurs caractéristiques positives de ce phénomène de _fabrique d'édition_, il est pourtant nécessaire de relever plusieurs limites intrinsèques, comme l'inclusivité permise ou non par ces processus, les ressources nécessaires pour leur fonctionnement, et enfin la participation ou non de la _fabrique_ à une certaine course technologique — et technophile.

Les outils, programmes ou logiciels utilisés ici sont majoritairement créés et développés par des hommes occidentaux — comme l'auteur de cette thèse.
Nous sommes dans la position où nous recommandons des approches qui sont mises en place dans un cadre très spécifique, que nous pouvons qualifier de privilégié.
Quand bien même ces approches sont _ouvertes_, nous devons prendre en considération les conditions de leur émergence, ainsi que les nombreux biais qu'elles comportent — par exemple un accès continu à l'électricité ou à Internet, la compréhension de la langue anglaise majoritairement utilisée dans les documentations, ou encore disposer d'ordinateurs récents ou de serveurs.
Si la reprise de TXT dans d'autres circonstances — avec _Débugue tes humanités_ {{< renvoi chapitre="5" section="5" h3="2" >}}— est un pas engageant vers l'utilisabilité ou l'appropriation d'un tel processus, ces usages demeurent circonscrits à certaines situations et ne peuvent être généralisées.

L'utilisation de Hugo, mais aussi de Pandoc, nécessite une puissance de calcul qui n'est pas négligeable.
Si la rapidité du générateur de site statique se vérifie sur des ordinateurs récents, il faut prendre en considération que le temps de génération — et l'énergie qui l'alimente — peut être plus important sur des machines plus anciennes.
C'est ce que souligne l'équipe de _Low-Tech Magazine_ lors du changement de _workflow_ :

{{< citation ref="decker_reconstruire_2023" >}}
En passant à Hugo, nous avons réussi à réduire le temps de génération sur le serveur de plus d’une heure à environ douze minutes. Sur un ordinateur portable moderne, la différence se situe entre plusieurs minutes et plusieurs secondes de génération. Cette différence de temps signifie également une différence dans la consommation d’énergie sur le serveur.
{{< /citation >}}

C'est également une réflexion suscitée par les principes du _minimal computing_ — que nous avons présentés précédemment{{< renvoi chapitre="3" section="4" h3="4" >}} — qui consistent à considérer les ressources disponibles dans un contexte donné pour conduire des choix technologiques, et non faire usage de technologies sans prendre en compte les contraintes _locales_.
Tout choix technique ne convient pas à toutes les situations.
Dans notre cas, Hugo, malgré son grand avantage de ne disposer d'aucune dépendance, requiert tout de même des machines relativement récentes.

Enfin, ces deux prototypes participent-ils à une certaine course technologique ?
Probablement oui, indirectement, dans la mesure où Hugo (et Go) se placent tout de même dans une démarche d'amélioration continue qui vise plus à augmenter les performances qu'à réduire l'impact de leur usage.
Le concept de _permacomputing_ apporte un éclairage pertinent sur cette double question de cette constante progression technique et de la consommation de matériel et d'énergie :

{{< citation ref="mansoux_permacomputing_2023" >}}
At a time when computational culture seems to be increasingly characterised by electronic and energy waste, permacomputing instead encourages a more sustainable approach by maximising the life of hardware, minimising energy consumption and focusing on the use of already available computing devices and components.
{{< /citation >}}

Cette remise en question technique et profonde peut permettre de fonder une nouvelle culture numérique ainsi que de découvrir de nouvelles esthétiques {{< cite "noauthor_permacomputing_2023" >}}.
Dans une situation climatique catastrophique ce questionnement peut constituer une perspective positive.
C'est ce que nous avons tenté de faire, à une moindre échelle, avec ces deux prototypes.

En prenant en compte ces trois questions, à la fois comme des critiques, des limites et des perspectives, nous nous positionnons dans une situation de prototypage.
Une des suites possibles de cette double expérimentation serait l'adoption de choix radicaux, par exemple en abandonnant des langages incompatibles avec des machines informatiques de plus de vingt ans, ou en remettant en cause l'absence de construction incrémentale — actuellement l'ensemble des artefacts sont regénérés même si un seul fichier source est modifié.
Les résultats obtenus, en l'occurrence l'implémentation de plusieurs principes permettant de construire des _fabriques_, sont désormais utiles pour envisager de nouvelles implémentations.