---
title: "Le Pressoir : une chaîne d'éditorialisation"
chapitre: 2
section: 5
bibfile: "data/02.json"
_build:
  list: always
  publishResources: true
  render: never
---

Comme nous l'avons vu avec l'étude de cas d'Abrüpt{{< renvoi chapitre="2" section="3" >}}, les conditions d'émergence d'artefacts éditoriaux originaux ne se limitent pas à l'adoption de nouveaux outils.
La constitution de chaînes d'édition permet aussi une dissémination et une réappropriation des textes ainsi édités.
Afin de comprendre comment s'opère cette diffusion numérique, cette forme d'_éditorialisation_, l'étude de la création d'une chaîne est désormais nécessaire.
Comment l'éditorialisation peut-elle être un outil méthodologique pour comprendre des pratiques contemporaines d'édition ?
Dans le cadre de ce concept d'éditorialisation, des travaux sur les plateformes ont été réalisés, étudiant les questions d'écriture, de participation, de propagation, etc.
Nous nous chargeons ici d'interroger la manière de fabriquer des objets éditoriaux, et plus spécifiquement des livres, dans un contexte numérique et donc avec l'éditorialisation.

Dans le chapitre précédent nous avons présenté et analysé un titre des Ateliers de \[sens public\]{{< renvoi chapitre="1" section="5" >}}, afin de montrer les spécificités d'un livre _contemporain_.
_Exigeons de meilleures bibliothèques_ de R David Lankes est un exemple emblématique d'un ouvrage publié en différents formats et en plusieurs versions.
Ce livre est également à l'origine d'un ensemble de méthodes, d'outils et de programmes qui ont été développés et mis en place pour fabriquer les livres des Ateliers{{< n >}}Les deux formes "Ateliers de \[sens public\]" et "Ateliers" sont utilisés indistinctement dans la suite du texte.{{< /n >}}.
Nous décrivons et critiquons désormais cette chaîne d'édition, nommée _Pressoir_.

Un double préambule est nécessaire à cette étude de cas.
Tout d'abord l'auteur de cette thèse a été impliqué dans la mise en place et l'utilisation de la chaîne d'édition des Ateliers, comme cela a été également le cas de Marcello Vitali-Rosati, l'un des chercheurs les plus actifs ces dernières années sur la question de l'éditorialisation.
Ensuite l'analyse du _Pressoir_ a fait l'objet d'un article pour la revue _Pop! Public. Open. Participatory_ {{< cite "fauchie_exploring_2023" >}}.
Le présent texte est issu d'une réécriture complète, toutefois une partie des contenus présents dans cet article peut recouper certains passages ici.


### 2.5.1. Une chaîne d'édition

Les Ateliers est une maison d'édition qui publie des essais dans le domaine des sciences humaines, et plus spécifiquement des sciences de l'information et de la littérature.
Les ouvrages publiés comportent un appareil critique (notes, références bibliographiques, bibliographies, index et glossaires) et suivent un parcours éditorial spécifique qu'est celui de l'édition académique (soumission, éditions, relectures, modifications, validation, etc.).
Les besoins en édition des Ateliers sont ceux de l'édition savante : des validations par les pairs ; un important travail sur le texte pour des questions de structure et de lisibilité ; des appareils critiques élaborés ; une fabrication qui permet des allers-retours entre les différentes personnes impliquées ; une pérennité des formats pour des modifications ultérieures ; la production d'artefacts qui facilitent une diffusion organisée ; etc.
Cette démarche comporte aussi une recherche de nouveaux modèles éditoriaux.
Il faut considérer les dimensions d'expérimentation, de prototype voir de bidouillages indispensables à cette recherche.
Si Abrüpt{{< renvoi chapitre="2" section="3" >}} ou les Ateliers font le choix inverse de la plupart des maisons d'édition, en construisant leurs dispositifs techniques loin des logiciels clés en main, c'est dans une volonté d'exploration épistémologique qui dépasse l'objectif de _produire_ des artefacts.

Pour réaliser ce projet, les personnes impliquées dans les Ateliers de \[sens public\] ont adopté des méthodes, mis en place un certain nombre d'outils et fait des choix éminemment politiques pour ainsi composer une chaîne d'édition.
L'étude de cette chaîne d'édition est intéressante autant pour comprendre les enjeux de l'éditorialisation que pour l'observation d'un phénomène double.
En effet la mise en place d'un dispositif d'édition a été réalisée ici pour la production d'un livre en particulier, _Exigeons de meilleures bibliothèques_ de David Lankes.
Ce dispositif n'a pas été seulement un moyen de produire un objet éditorial, il a aussi modifié l'objet lui-même.
Si la mise en place d'une chaîne d'édition permet de créer des artefacts, la production de cette chaîne est aussi une façon d'aboutir à de nouvelles expressions éditoriales — parfois inédites.
Nous observons donc ici une forme de réflexivité : la façon de faire influence la forme obtenue, et inversement.
Un modèle épistémologique émerge grâce à cette combinaison d'édition de texte et de programmation éditoriale.

Qu'est-ce qu'une _chaîne d'édition_ ?
Il s'agit, d'une façon générale, de l'ensemble des processus techniques nécessaires à la pratique de l'édition, et plus particulièrement des moyens disponibles pour produire un document tel qu'un livre.
Concrètement, les méthodes, les outils et les environnements constituent une _chaîne d'édition_, aussi appelée _chaîne éditoriale_ ou _chaîne de publication_.

{{< citation ref="arribe_conception_2014" page="206" >}}
Dans son acceptation la plus générique, une chaîne éditoriale numérique est un logiciel mobilisé pour couvrir l'ensemble des métiers d'une chaîne éditoriale classique (auteur, éditeur, imprimeur) sur un support numérique. Une chaîne éditoriale numérique permet donc d'assister des rédacteurs dans la production et la publication de leurs contenus.
{{< /citation >}}

Avec cette définition de Thibaut Arribe nous pouvons voir le lien entre _chaîne éditoriale_ et _chaîne du livre_, c'est-à-dire les connexions entre les différentes personnes et métiers qui participent à la création et à la production d'un livre.
Dans notre recherche nous nous concentrons sur la chaîne éditoriale en tant que processus au sein d'une structure d'édition, processus qui peut mobiliser d'autres intervenants et intervenantes.
Si l'auteur de la définition ci-dessus distingue _chaîne éditoriale_ et _chaîne éditoriale numérique_, nous actons le fait que les deux expressions sont désormais équivalentes si nous considérons le numérique comme l'utilisation de logiciels ou plus globalement de l'informatique — ce qui est en réalité plus complexe comme nous le voyons par la suite{{< renvoi chapitre="3" section="1" >}}.

Lorsque l'expression _chaîne éditoriale_ est utilisée, c'est bien souvent dans un contexte d'utilisation du format XML{{< renvoi chapitre="4" section="2" >}}, en raison des possibilités de modélisation éditoriale permise par ce format.

{{< citation ref="crozat_scenari_2007" >}}
Une chaîne éditoriale est un procédé technologique et méthodologique consistant à réaliser un modèle de document, à assister les tâches de création du contenu et à automatiser la mise en forme. Son atout premier est de réduire les coûts de production et de maintenance des contenus, et de mieux contrôler leur qualité.
{{< /citation >}}

Dans cette définition donnée par Stéphane Crozat plusieurs éléments sont notables : l'usage du terme _chaîne_, la modélisation, l'assistance et l'automatisation, et plus globalement l'objectif de facilitation.
L'argument principal en faveur de l'adoption des principes d'une _chaîne éditoriale_, selon l'auteur, est la réduction des "coûts de production et de maintenance", et le contrôle de la qualité.
Si cet argument semble correspondre à une injonction productiviste, il s'agit aussi d'une opportunité de gagner en indépendance vis-à-vis de certains logiciels ou infrastructures.
Retenons que l'enjeu est de faciliter l'écriture et l'édition par la mise en place d'une structuration des processus d'édition, cela se traduit donc par une définition claire des différentes étapes ou phases d'édition.
Dans cette définition la _modélisation_ des documents fait partie de l'activité d'édition.
L'auteur de _Scenari : la chaîne éditoriale libre_ illustre cette question ainsi : un document peut être divisé en fragments afin d'en faciliter l'écriture et l'édition, pour être recomposés au moment de la génération de la publication.
Ce sont des modèles de documents qui permettent cette gestion des contenus.
Nous rejoignons ici les considérations déjà évoquées à propos de l'éditorialisation.

{{< definition type="definition" intitule="Chaîne d'édition" id="chainededition" >}}
Une chaîne d'édition est l'ensemble des processus, des méthodes et des outils nécessaires à la réalisation d'une activité d'édition, et plus spécifiquement à la création, la fabrication, la production et la diffusion d'un livre.
Si l'objet de la chaîne d'édition est la génération d'un tel artefact, sa matière première est le texte sans s'y réduire.
Une chaîne d'édition est basée sur une modélisation éditoriale qui doit permettre une gestion sémantique des contenus en vue de la réalisation d'un ou de plusieurs artefacts tels qu'un livre imprimé, un livre numérique, un document structuré ou toute autre forme permettant de diffuser des contenus, des idées, et de faire sens.
Une chaîne d'édition est aussi, comme le terme de "chaîne" l'implique, une suite d'étapes linéaires, et à ce titre elle peut être critiquée et mise en regard d'autres dispositifs qui envisagent, de façon divergente, l'édition comme un entremêlement d'opérations en prenant en compte leurs relations et leurs apports mutuels.
{{< /definition >}}


### 2.5.2. Un projet intellectuel et politique

La chaîne d'édition des Ateliers est constituée des éléments qui lui permettent de produire des artefacts éditoriaux, de _faire_ de l'édition.
Cette chaîne d'édition révèle un modèle épistémologique, mais aussi un  mode politique.
Il s'agit de la réalisation technique d'un projet intellectuel qui s'exprime ainsi autant par les livres publiés que par la façon de travailler, collectivement.
Cela se traduit sur plusieurs plans : l'ouverture, le _libre_ et la pérennité.

Les textes sont publiés en libre accès et sous licence Creative Commons, ce qui autorise une lecture et une diffusion sans limitation, et qui encadre une réutilisation des textes.
D'ailleurs la possibilité d'une réutilisation est une des pierres angulaires de l'éditorialisation : en permettant des copies, des modifications ou des fragmentations des contenus, d'autres formes et expressions peuvent émerger.
L'ouverture des usages des textes sont une des conditions des dynamiques "qui constituent l'espace numérique et qui permettent à partir de cette constitution l'émergence du sens" {{< cite "vitali-rosati_pour_2020" >}}.

Les logiciels et les programmes utilisés par les Ateliers pour produire leurs livres sont libres.
Le choix du _libre_ n'est pas anodin, l'enjeu est de disposer d'outils dont le fonctionnement peut être compris et analysé, des outils qui sont facilement accessibles, mais qui peuvent aussi être potentiellement modifiables et dont les modifications peuvent être partagées.
L'usage du logiciel libre est aussi une condition de la pérennité des sources, des contenus et des modèles d'édition.
Le fait que le code source des logiciels et des programmes soit mis à disposition publiquement facilite sa maintenance.
Ce code est souvent accompagné d'une documentation pour comprendre son fonctionnement et proposer des méthodes pour le mettre à jour, ainsi que des moyens pour extraire les données — et les disposer dans un autre système si nécessaire.
L'utilisation du logiciel libre ne se limite pas à ces éléments _fonctionnels_, l'enjeu principal est de constituer des chaînes d'édition en expérimentant autant que possible.
La limite est alors celle imposée par le fonctionnement même des programmes utilisés, et non par les licences qui y sont associées.
Enfin, avec le logiciel libre viennent des communautés, communautés qui peuvent apporter un soutien au projet concerné, et auxquelles un soutien peut être donné en retour.

La pérennité correspond à la capacité, pendant un temps long, de lire et de modifier les sources, de générer des versions mises à jour des artefacts, ou de lire les formats de sortie.
Le logiciel libre repose majoritairement sur des standards ou des protocoles qui sont partagés et documentés.
Cela permet d'échapper à l'enfermement contraint par un format de fichiers dépendant d'un logiciel en particulier.

Cette chaîne d'édition des Ateliers est l'expression de sa démarche éditoriale.
Il y a une forme de cohérence entre les _intentions_ éditoriales (quelle forme donner aux textes pour qu'ils circulent et qu'ils soient lus) et les processus permettant la réalisation de ces intentions.
De la même façon qu'une structure d'édition façonne un texte, elle peut aussi fabriquer ces outils de façonnage.


### 2.5.3. Des espaces d'écriture

Pour définir la chaîne d'édition des Ateliers nous pouvons faire un état des étapes d'édition, en présentant les outils associés à chacune d'elles.
Avant cela nous critiquons l'utilisation du terme de "chaîne" : ce terme implique un _enchaînement_ entre les différentes étapes nécessaires à la production d'un document, enchaînement qui suggère une succession ou une linéarité qui n'a pas systématiquement lieu dans les pratiques de cette structure d'édition.
L'usage du terme "chaîne" se fait ici par défaut, le terme de "système" ayant également été effectué et épuisé {{< cite "fauchie_vers_2018" >}} celui de _fabrique_ est préféré et explicité en détail par la suite{{< renvoi chapitre="5" section="4" >}}.
De l'écriture à la publication, voici donc ces différentes phases.

L'étape d'écriture des textes — textes structurés dès le début du projet en chapitres ou en parties — se déroule avec l'éditeur de texte sémantique _Stylo_ {{< cite "vitali-rosati_ecrire_2020" >}}.
Cet environnement d'écriture inclut une structuration sémantique via un langage de balisage léger (Markdown) pour le corps du texte, et un langage de sérialisation de données (YAML) pour les métadonnées liées au document.
Dans la pratique une partie des auteurs et des autrices convertissent leurs textes depuis un traitement de texte vers _Stylo_, il peut donc y avoir une étape d'écriture préalable dans un logiciel type Microsoft Word, souvent sans sémantique.
La raison de l'utilisation de _Stylo_ est double : structurer sémantiquement les textes et disposer d'un espace de conversation _autour_ des textes.
L'abandon du traitement de texte — majoritairement utilisé pour les pratiques d'écriture, d'autant plus en milieu académique ou savant — pour l'éditeur de texte _Stylo_ permet de faire de faire de l'édition numérique{{< renvoi chapitre="3" section="4" >}} et sémantique.
En effet, il s'agit de donner du sens au texte : celui-ci, pour être lu, a autant besoin d'un rendu graphique que d'un balisage pour sa diffusion sur les différents environnements numériques.
Il peut s'agir par exemple du format HTML, format qui représente l'information autant graphiquement que sémantiquement.

_Stylo_ permet également de prévisualiser le texte, cet aperçu est disponible sous la forme d'une page web qui peut être annotée via le service Hypothesis{{< n >}}[https://web.hypothes.is](https://web.hypothes.is){{< /n >}}.
Les annotations permettent d'engager un dialogue sur le texte : signalement de corrections ou de modifications, mais aussi espace d'échanges.
Ces commentaires incitent les auteurs et les autrices à échanger sur certains points ou à modifier directement leur texte.
Il faut préciser que _Stylo_ intègre un système de versionnement des textes, et qu'une prévisualisation est disponible pour chacune de ces versions, incluant la version courante (donc celle qui comporte les modifications les plus récentes).
Deuxième précision : les annotations sont publiques par défaut, mais il est possible de les intégrer dans un groupe privé accessible sur invitation.
Enfin, dans le cas des Ateliers les personnes qui annotent et commentent les textes ne sont pas anonymes, tout comme les textes ne sont pas anonymisés.
Il s'agit donc d'une évaluation ouverte, effectuée par le comité éditorial des Ateliers — composé de Servanne Monjour et de Nicolas Sauret, parfois accompagnés d'étudiant·e·s.

Après cette phase d'écriture et de révision, l'édition du texte commence.
Il s'agit de structurer et restructurer : découpage en chapitres, ajout de métadonnées, structuration sémantique des textes — y compris des contenus dits additionnels (médias, repérage des termes à indexer ou à ajouter au glossaire, ajout de références bibliographiques, etc.).
Une partie de cette édition du texte est réalisée dans _Stylo_, jusqu'au moment où il est nécessaire de disposer d'un environnement permettant de prévisualiser le _livre_ (et non plus seulement les _textes_) et surtout de pouvoir modifier le modèle éditorial librement.


### 2.5.4. Des espaces d'édition

_Stylo_ est utilisé pour l'écriture puis délaissé pour travailler le texte et sa structure tout en prévisualisant le livre dans son ensemble.
La structure du texte doit accueillir des données diverses, les Ateliers ont par exemple adopté un balisage spécifique pour structurer les termes et les expressions de l'index et du glossaire.
La structure globale de chaque livre comprend les différents chapitres, mais aussi les outils du livre tels que l'index et le glossaire.
À ce stade il importe de pouvoir constater que les artefacts sont bien fabriqués, et donc de les visualiser, et en particulier le site web.

Le modèle éditorial évolue d'un livre à l'autre, cette adaptation est possible avec cette chaîne d'édition dont les éléments constitutifs et les gabarits peuvent être modifiés facilement.
Contrairement à _Stylo_ qui est une application utilisée par d'autres personnes dans des contextes très divers, et qui nécessite donc un certain degré générique.
Nous assistons ici à une _conjoncture médiatrice_ {{< cite "vitali-rosati_fait_2021" >}} où les pratiques, les outils construits collectivement, et le collectif lui-même sont intriqués.
Il ne s'agit plus véritablement d'une _chaîne_ où les opérations et les éléments sont organisés hiérarchiquement, mais d'un atelier d'où la pensée émerge.

Avant de présenter l'outillage technologique permettant de générer les artefacts, nous présentons cet environnement de travail.
Nous avons précédemment mentionné le fait que _Stylo_ versionne les textes, afin d'identifier les modifications successives et de naviguer dans ces versions.
C'est la première chose qui est gérée en dehors de _Stylo_ avec le logiciel de gestion de versions Git et la plateforme GitLab.
Git est un système de contrôle de versions (aussi appelé logiciel de gestion de versions) {{< cite "chacon_pro_2018" >}} destiné à gérer du code informatique.
Les logiciels de contrôle ou de gestion de versions sont nombreux, leur histoire est riche, et Git y a pris une place prépondérante pour ne pas dire monopolistique.
Le fonctionnement de Git est puissant et facilite les interactions avec le code, à plusieurs, mais la plateforme GitHub a clairement contribué à populariser ce système de _versionnement_.

Git est aussi employé pour versionner du _texte_ dans des activités éditoriales diverses — majoritairement la fabrication de livres.
Quel est l'apport de Git pour gérer du texte ?
Les mêmes avantages que pour gérer du _code_ — le code étant un texte quelque peu particulier.
Le suivi des versions se fait via un système de _commits_ : un _commit_ est un enregistrement d'un état d'un projet, indiquant les modifications et accompagné d'un message plus ou moins long.
Un _commit_ dispose d'un identifiant unique, il est horodaté et il est attribué à une personne habituellement identifiée par un nom et une adresse électronique.
Git est pensé selon un système de branches : à tout moment il est possible de dupliquer le projet et de travailler sur une version identique sans perturber les ajouts dans la version principale, cet espace _parallèle_ est appelé _branche_.
Les branches sont _rebasées_ ou fusionnées avec la version principale pour intégrer leurs modifications.
Git est utilisé sur un ordinateur avec un système d'exploitation, mais les versions et les fichiers peuvent être stockés dans un _dépôt_ distant, cette disponibilité sur un serveur permet à plusieurs personnes d'y accéder ou de déposer leurs modifications.
Il existe des surcouches logicielles permettant de faciliter l'utilisation de Git via des interfaces graphiques ou des interfaces web.
Enfin Git est asynchrone, décentralisé et pensé pour être utilisé sans connexion internet.
Les modifications ne se font pas simultanément entre plusieurs personnes, c'est le _commit_ qui rythme les versions, celui-ci doit être explicitement envoyé (_push_) au dépôt distant pour qu'une autre personne puisse accéder (_fetch_ ou _pull_) à ces modifications.
Ainsi le _commit_ est créé sur l'ordinateur de la personne utilisatrice de Git, puis _poussé_ vers le dépôt distant.
Notons qu'il peut y avoir plusieurs dépôts distants, et que chaque contributeur ou contributrice d'un projet conserve une copie du projet avec tout son historique.
Contrairement à d'autres logiciels de gestion de versions populaires avant Git qui nécessitaient une connexion pour travailler, Git n'a besoin d'un accès à Internet que pour récupérer ou envoyer des modifications.
Dans la figure ci-dessous nous pouvons voir les interventions successives par des personnes différentes et sur plusieurs branches, avec Git.

{{< code type="code" legende="Quelques _commits_ extraits du dépôt Git du _Pressoir_ avec leur date, le nom de leur auteur·rice, la description et l'affichage du graphe des branches" >}}
| | * Fri Mar 10 08:35:46 2023 -0500 - hbeauchef: ajout variable lanng dans les yaml de chapitre
| | * Thu Mar 9 16:03:22 2023 -0500 - hbeauchef: modif biblio fr/en retour Robert
| | * Thu Mar 9 15:41:21 2023 -0500 - hbeauchef: ajout corrections Estelle Debouy et Clara Auvray Assayas
| | * Thu Mar 9 15:19:07 2023 -0500 - antoinentl: edit: explication sur le déploiement
| | * Thu Mar 9 10:38:33 2023 -0500 - hbeauchef: ajout credits ca chap3
| | *   Thu Mar 9 10:33:35 2023 -0500 - hbeauchef: ajout corrections robert
| | |\
| | | * Wed Mar 8 09:30:42 2023 -0500 - antoinentl: edit: regénération des chapitres du livre
| | * | Thu Mar 9 10:32:31 2023 -0500 - hbeauchef: ajout corrections reobert
| | |/
| | * Tue Mar 7 19:35:01 2023 -0500 - hbeauchef: modif nb de pages
| | * Tue Mar 7 15:33:27 2023 -0500 - hbeauchef: ajout wikidata sur augustin chap5
| | * Tue Mar 7 11:28:04 2023 -0500 - David Larlet: Ajout des noms des auteurs
| | * Mon Mar 6 15:14:10 2023 -0500 - hbeauchef: images allégées
| | * Mon Mar 6 14:08:29 2023 -0500 - hbeauchef: avant envoi aux auteurs
| | * Sun Feb 26 22:57:44 2023 -0500 - David Larlet: Prise en compte de idreference
| | * Sun Feb 26 22:07:11 2023 -0500 - hbeauchef: complément link-archive vides
| | * Sun Feb 26 21:45:23 2023 -0500 - hbeauchef: remplacement idglossaire par idereference, nettoyage test sol, suppression tous balisages acronym
| | * Sun Feb 26 15:24:57 2023 -0500 - antoinentl: edit: déploiement
| | * Fri Feb 24 20:18:51 2023 -0500 - David Larlet: Meilleure position du picto `format`
| | * Fri Feb 24 17:17:49 2023 -0500 - David Larlet: Ajout d’un picto pour le terme enrichi `format`
| | * Fri Feb 24 16:59:49 2023 -0500 - David Larlet: Suite CSS pour ajouter un terme enrichi
| | * Fri Feb 24 14:59:50 2023 -0500 - hbeauchef: test avec organisme - modif builder settings .py
| | * Fri Feb 24 14:27:53 2023 -0500 - hbeauchef: modif custon.css + termeenrichi.js pour afficher les termes balisés format dans le corps du texte
| | * Fri Feb 24 14:03:45 2023 -0500 - hbeauchef: avant de tout casser en touchant aux css
| | * Fri Feb 24 09:55:03 2023 -0500 - hbeauchef: travail index, test sur SOL
| | * Fri Feb 24 09:17:00 2023 -0500 - hbeauchef: test format vs sigle
{{< /code >}}

GitLab est une surcouche logicielle, c'est un espace de stockage basé sur Git et une interface graphique sous forme de site web comportant des fonctionnalités en plus de celles de Git.
Comme GitHub, très populaire depuis le début des années 2010, GitLab est communément appelé _forge_ en informatique.
GitLab est un logiciel libre disponible sous forme de service (payant) à l'adresse gitlab.com mais aussi sous différentes distributions (avec plusieurs types de licences associées) qui peuvent être installées sur un serveur.
Ces installations indépendantes de gitlab.com sont appelées des _instances_.
Les Ateliers, après avoir utilisé l'instance de Framasoft{{< n >}}Framasoft est une association française dont l'objet principal est la promotion et la diffusion du logiciel libre, incluant la mise à disposition d'infrastructures utilisant de tels logiciels et respectueuses des données privées.{{< /n >}}, déposent désormais les versions de ses textes sur celle d'Huma-Num — pour le moment en accès restreints.
GitLab, en plus de stocker et d'afficher les versions (et donc les _commits_), propose des fonctionnalités qui ne sont pas comprises dans Git, fonctionnalités qui se retrouvent sur d'autres plateformes ou logiciels comme GitHub, Forgejo/Gitea, Codeberg, SourceHut ou Bitbucket (pour n'en citer que quelques-uns).
Parmi ces fonctionnalités nous pouvons mentionner l'affichage des fichiers et des commits dans un navigateur web, un affichage de l'historique des _commits_ sous forme de graphe, un éditeur de texte (et même parfois un environnement de développement intégré ou IDE en anglais), un gestionnaire de tickets, un gestionnaire de demandes de fusion (_merge requests_ ou _pull requests_) et un dispositif de déploiement/intégration continu.

Les pratiques d'édition des Ateliers se sont structurées autour des fonctionnalités de Git et de GitLab, nous en donnons ici quelques exemples.
Tout d'abord les _commits_ sont les traces qui permettent d'identifier les modifications successives du code.
Naviguer dans ces états du texte correspond à la possibilité de consulter les évolutions des modifications d'une version à l'autre.
Si certains outils d'écriture ou d'édition permettent d'accéder à un historique des versions, Git est bien plus puissant avec son système de branches.
Les _commits_ sont utilisés pour déclarer une série de modifications sur un ou plusieurs fichiers, telles que : corrections orthotypographiques, ajout d'identifiants sur des termes, ajout de contenus additionnels, phases de relectures, etc.

{{< figure type="figure" src="pressoir-litteratube-01.png" legende="Capture d'écran d'un _commit_ lors de l'édition du livre _LittéraTube_ sur la plateforme GitLab" >}}

Dans le _commit_ ci-dessus nous pouvons voir les modifications apportées sur un fichier en particulier — la visibilité des différentes est facilitée par la coloration syntaxique.
Ces informations sont enregistrées sur l'ordinateur des personnes qui ont _cloné_ le projet, mais aussi sur la plateforme GitLab.
Tous les _commits_ sont la plupart du temps conservés — s'il est possible de supprimer un _commit_ et les informations associées, c'est une opération rarement réalisée —, constituant ainsi une mémoire détaillée et rigoureuse du projet.

Les tickets (ou _issues_ en anglais) sont un moyen d'identifier des problèmes, de débuter une discussion ou de signaler des modifications à effectuer.
Un ticket est créé par une personne et peut être attribué à une ou plusieurs autres.
Chaque ticket comporte une description, il peut être commenté et il est possible de lier des tickets avec des _commits_ ou des branches.
Cette _banque_ de tickets permet de discuter de façon fluide et néanmoins asynchrone entre les personnes impliquées dans le projet — l'équipe des Ateliers, rarement les auteurs ou les autrices.
Plutôt que d'utiliser une messagerie quelconque, les questionnements et les remarques sont consignées dans cet espace, un ticket pouvant ensuite être fermé ou résolu via un _commit_.
Ces tickets forment eux aussi la mémoire du projet.

{{< figure type="figure" src="pressoir-litteratube-02.png" legende="Capture d'écran d'un ticket sur la plateforme GitLab lors de l'édition du livre _LittéraTube_" >}}

Dans le ticket (ou _issue_ en anglais) ci-dessus, nous pouvons voir qui l'a créé et à qui il a été attribué.
Le ticket est lui-même versionné, avec une date de création et la mention des modifications successives.

Le déploiement continu, dernière des fonctionnalités liée à GitLab et utilisée dans ce processus, est une façon de déclencher une action à chaque nouveau _commit_ sur une branche.
Dès qu'une modification est effectuée et déclarée, puis envoyée sur la plateforme GitLab, cette dernière est en mesure de faire débuter un certain nombre d'opérations, via des scripts, pour générer les artefacts.
Chaque livre des Ateliers est ainsi _déployé_ {{< cite "fauchie_deployer_2021" >}} sur différents environnements : une version de développement, en ligne, mais qui n'est pas rendue publique ; une version en production, publique, sur le site des Ateliers.
Pour mieux comprendre ce fonctionnement il faut préciser que les modifications peuvent porter sur les _sources_ (les textes) mais aussi sur les scripts ou les gabarits des différents artefacts générés.
Il y a une séparation nette entre les sources, les modèles des artefacts et les fichiers générés (qui forment les artefacts).
Ces artefacts sont produits avec le Pressoir décrit ci-après.


### 2.5.5. Le _Pressoir_

Le _Pressoir_ est un outil chargé de convertir, d'organiser, de construire et de publier.
Le _Pressoir_ est une série de scripts Python qui permettent la fabrication d'un livre sous forme de site web, ainsi que la préparation des fichiers pour la production des formats PDF et EPUB — nous n'abordons pas la production de ces deux types de fichiers dans cette section.
Pour convertir les fichiers sources aux formats Markdown (pour les contenus), YAML (pour les métadonnées et les contenus enrichis) et BibTeX (pour les références bibliographiques structurées), le Pressoir utilise le convertisseur Pandoc.
Plusieurs commandes Pandoc sont ainsi préconfigurées via les scripts Python ; ces commandes comportent de nombreux arguments qu'il est préférable d'indiquer dans des scripts plutôt que d'appeler via un terminal comme c'est d'usage avec Pandoc.
Il s'agit ensuite d'organiser convenablement les fichiers produits, y compris certains objets complexes comme les index et les glossaires.
Une fois organisées, ces pages web constituent une construction, un artefact lisible (ici par un navigateur web) qui peut ainsi être publié.

Le _Pressoir_ doit son nom à David Larlet, l'un des designers et développeurs qui a contribué au projet en tant que prestataire depuis 2019.
L'implication de David Larlet dans la formalisation d'une chaîne de publication est révélatrice des liens entre code et contenu.
Son implication dans le projet dépasse la programmation de fonctions, puisqu'il a travaillé de concert avec l'équipe des Ateliers pour penser un système basé uniquement sur Python et Pandoc.
Il faut préciser qu'avant la mise en place du _Pressoir_ Pandoc était déjà utilisé, mais avec une série de commandes Bash et des programmes tels que Sed, BaseX ou Yq.
L'objectif de la formalisation opérée avec Python est de réduire les dépendances extérieures, de pouvoir faire évoluer plus facilement la chaîne d'édition au fil des livres, et d'améliorer cet environnement d'expérimentation.
Il aurait été possible d'utiliser un autre langage de programmation pour développer le _Pressoir_, mais Python offre deux avantages dans ce contexte : il est relativement accessible à des personnes qui _codent_ sans que ce ne soit leur métier, et il est très utilisé dans la communauté des humanités numériques dont les Ateliers fait partie.
Plutôt que de faire reposer la chaîne sur plusieurs logiciels (ici Git, Bash, Pandoc, Sed, BaseX et Yq), la construction d'une chaîne autour de Python et de bibliothèques de code Python facilite la mise à jour, la portabilité et la duplicabilité d'un tel processus technique.
Il est désormais possible d'utiliser la chaîne avec Git (pour versionner les fichiers), Make (pour simplifier les commandes), Pandoc (pour la conversion des sources vers différents formats de sortie), Python (pour l'organisation, la construction et la publication).
Il s'agit d'un déplacement des dépendances pour atteindre une soutenabilité, et surtout la construction d'un espace pour expérimenter.

Ce travail de formalisation peut être analysé avec les outils du concept d'éditorialisation, et notamment les trois aspects technologique, culturel et pratique définis par Marcello Vitali-Rosati {{< cite "vitali-rosati_editorialisation_2017" >}}.
Le premier aspect concerne la _pile technologique_ qui consiste en une série de logiciels, de programmes et de leur configuration et articulation.
C'est ce que nous venons de décrire avec la constitution du _Pressoir_ en tant que suite de scripts.
L'aspect culturel concerne l'usage de cette pile technique, avec certaines spécificités comme décrites dans l'utilisation de Git ou de la plateforme GitLab.
Enfin, l'aspect pratique permet d'envisager de nouvelles pistes de modélisation éditoriale via le recours à cette chaîne d'édition pour différents livres.
Dans le cadre des Ateliers les projets successifs _avec_ le _Pressoir_ ont permis par exemple d'imaginer de nouvelles fonctionnalités de lecture, chose impossible avec un dispositif d'édition plus classique.

Les principales opérations réalisées par le _Pressoir_ sont les suivantes.
La conversion : il s'agit de convertir des fichiers sources balisés (ici avec le langage de balisage léger Markdown) au format HTML.
Cette conversion consiste dans le passage d'un balisage _léger_ à un balisage plus verbeux (et standard), mais également dans la prise en charge des citations bibliographiques et des bibliographies.
Cette conversion est assurée avec Pandoc, convertisseur puissant très utilisé dans le monde académique{{< renvoi chapitre="4" section="3" >}}.
L'objectif ici est d'assurer le travail de conversion par un logiciel déjà créé et maintenu, par ailleurs puissant et reposant sur des standards.
L'organisation : ce qui est fabriqué ici est un livre, son organisation en différents chapitres — incluant une introduction et une conclusion, ainsi qu'un index et un glossaire — est relativement classique.
Le convertisseur Pandoc est d'abord pensé pour convertir un seul document à la fois, les options permettant de transformer une série de fichiers en un seul artefact avec Pandoc sont trop restreintes pour les besoins des Ateliers.
Le _Pressoir_ se charge ainsi de convertir plusieurs documents, listés dans un fichier de configuration, et de les placer dans les dossiers correspondants.
Les scripts chargés de ces opérations sont séparés afin de distinguer des sous-opérations dans cette organisation, par exemple : la répartition en chapitres, la gestion des notes marginales, le placement des fichiers HTML produits dans les bons répertoires, etc.
La construction : il s'agit de structurer les informations en appliquant une série de gabarits (ou _templates_ en anglais).
Cette _construction_ concerne autant chaque page web (correspondant par exemple à un chapitre) que les éléments de navigation tels qu'un fil d'Ariane, un menu ou des liens pour passer d'un chapitre à un autre.
La construction est aussi une opération d'indexation, avec le repérage de termes balisés et la création d'index, l'indication des occurrences et les liens hypertextes vers celles-ci.
La publication : cette dernière opération consiste en la mise à disposition du site web ainsi créé, soit localement soit _en ligne_ sur le Web.
Le Pressoir est utilisé comme une interface en ligne de commande, c'est-à-dire que les fonctions sont appelées avec des commandes dans un terminal.
Deux fonctions sont essentielles ici : générer l'artefact (donc convertir, organiser et construire) et servir cet objet (donc le publier de façon temporaire sur un ordinateur ou de façon plus large sur le Web).

{{< code type="code" legende="Quelques lignes de la documentation du Pressoir (dont le texte est balisé en Markdown) présentant quelques commandes utilisées" >}}
## Construction

Pré-requis : le dépôt des contenus doit être cloné au même niveau que celui-ci dans votre arborescence (à côté).

Le lancement de la commande de construction va générer le contenu final dans le dossier `./dist/` :

    # À chaque mise à jour des sources ou des fichiers statiques.
    make build


## Vérification

Lancer un serveur web local pour visualiser le dossier `./dist/`, par exemple :

    # À chaque fois que vous avez besoin de visualiser le résultat.
    make serve
{{< /code >}}

Cette description des opérations réalisées par le _Pressoir_ permet de comprendre quelles sont les étapes ou les phases de cette pratique d'édition.
Ce qui avait déjà été entrepris avec le script Bash avant le _Pressoir_ comportait cette intention de structurer l'édition des livres des Ateliers.
Il y a ici un effort singulier de formalisation des étapes, en considérant que des scripts doivent permettre de réaliser un certain nombre d'actions sur les textes.
Il s'agit d'automatiser ce qui peut l'être sans pour autant perdre la maîtrise des opérations, pour paraphraser Silvio Lorusso {{< cite "lorusso_liquider_2021" >}}.
Et l'enjeu est aussi de pouvoir adapter certains fonctionnements en fonction des projets éditoriaux et de leurs particularités.

L'usage du _Pressoir_ se fait dans un contexte où la version numérique — et en l'occurrence un _livre web_ {{< cite "fauchie_livre_2017" >}} — est celle qui prévaut sur les autres.
C'est-à-dire que cet artefact est le plus à même de présenter l'ensemble des contenus (additionnels y compris) alors que les autres formats sont des versions en quelque sorte réduites (sans les contenus additionnels et parfois sans index). 
Ce positionnement qui consiste à penser l'"édition augmentée" avant des formats tels que la version imprimée ou le fichier EPUB, est une expression d'une pratique d'édition contemporaine.
Le concept ou la théorie de l'éditorialisation nous permet de faire surgir ce point plus fortement.
Prévoir un format qui autorise la diffusion de contenus sur plusieurs plateformes, avec à disposition une licence de réutilisation, correspond à ces "dynamiques" qui "sont le résultat de forces et d’actions différentes qui déterminent après coup l’apparition et l’identification d’objets particuliers (personnes, communautés, algorithmes, plateformes…)" {{< cite "vitali-rosati_pour_2020" >}}.
En effet chaque livre web des Ateliers peut être lu en ligne par des humains, grâce à une structuration graphique de l'information et des outils de lecture et de navigation, mais aussi par des programmes informatiques qui parcourent et enregistrent le Web — ici par le biais de l'exposition de nombreuses données structurées et riches.
Ces contenus rendus ainsi accessibles, il est possible de les citer, de les lier, voire de les réutiliser.
L'édition, et ici plus spécifiquement _numérique_, n'est pas une duplication de l'imprimé sur le Web, mais bien la création d'artefacts nouveaux avec des processus d'édition singuliers — ce sur quoi nous revenons dans le chapitre suivant{{< renvoi chapitre="3" section="2" >}}.
Avoir la possibilité de modéliser des livres, c'est exercer un effort de formalisation d'une pensée, il s'agit d'un acte éditorial.

Le _Pressoir_ évolue à chaque nouveau livre, certaines fonctionnalités sont ajoutées en fonction des besoins propres à chaque nouveau projet éditorial.
Le _Pressoir_ est aussi développé dans l'objectif de pouvoir être utilisé dans d'autres contextes d'édition — même si pour le moment le manque de documentation ne permet pas une mise à disposition publique.
Le _Pressoir_ nécessite une certaine littératie ou plutôt une littératie certaine, tels que l'usage d'un terminal et de la ligne de commande, la compréhension de langages de balisage tels que Markdown ou HTML, la maîtrise d'un éditeur de texte ou encore la connaissance de Git (via le terminal ou une interface graphique).
Des connaissances et des pratiques qui ne sont pas forcément celles entendues lorsque l'on parle de _numérique_, et qui sont pourtant nécessaires pour envisager un usage et une reproductibilité de ce type de chaîne ou de _modèle_ d'édition.
Ces prérequis sont la condition de la création d'un modèle épistémologique propre à cette structure d'édition.
Cette littératie en puissance, mal définie lorsque le terme _numérique_ n'est pas précisé, correspond ici à un usage relativement avancé d'un ordinateur par rapport aux pratiques qui sont celles d'un traitement de texte, d'un logiciel de publication assistée par ordinateur ou d'un système de gestion de contenu (CMS).
C'est l'objet du chapitre suivant de définir et de critiquer la notion de _numérique_, à la fois en prenant appui sur les recherches effectuées jusqu'ici — donc sur le livre et l'édition — et dans la perspective de les prolonger vers les notions de _format_ et de _fabrique_.