# Notes sur le projet “ Digital Leigh Hunt ”

Yann Audin, Roch Delannay, Michael E. Sinatra, Giulia Ferretti, Dominic Forest

► To cite this version:

Yann Audin, Roch Delannay, Michael E. Sinatra, Giulia Ferretti, Dominic Forest. Notes sur le projet "Digital Leigh Hunt". Robert Alessi; Marcello Vitali-Rosati. Les éditions critiques numériques: entre tradition et changement de paradigme, Presses de l'Université de Montréal, 2023, Parcours numériques, 978-2-7606-4857-9. hal-04227199

HAL Id: hal-04227199

https://hal.science/hal-04227199v1

Submitted on 6 Oct 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
## CHAPITRE 9

# Notes sur le projet « Digital Leigh Hunt »

YANN AUDIN, ROCH DELANNAY, MICHAEL E. SINATRA, GIULIA FERRETTI ET DOMINIC FOREST

On présentera ici un aspect qui reste très souvent dans l'ombre des éditions numériques : leur phase projectuelle. Une édition numérique est toujours le fruit d'un projet particulier, lors duquel sont identifiés les méthodologies, le cadre théorique, les problématiques et les enjeux qui devront être pris en compte pendant le travail d'édition. Ce sont les facteurs qui détermineront ensuite les choix techniques et permettront de faire en sorte que l'artefact numérique final soit véritablement l'incarnation d'une pensée particulière. L'édition n'est jamais neutre et quand elle est encore à un stade projectuel, toutes les décisions et les prises de position, épistémologiques, méthodologiques, etc. doivent nécessairement être explicitées. C'est ce qui sera montré avec le cas d'étude du projet « Digital Leigh Hunt ».

La phase projectuelle d'une édition numérique implique une série de choix techniques et méthodologiques, qui sont à leur tour motivés par les conditions matérielles et culturelles dans
lesquelles s'inscrit le projet. Pour observer cette dynamique, nous nous intéressons à l'étude de cas de l'édition critique «Digital Leigh Hunt». Le projet prévoit un flux éditorial pour la production d'une édition critique sur papier et d'une édition numérique intégrée, rassemblant de manière exhaustive les écrits de Leigh Hunt. Le corpus choisi est donc qualitativement très vaste et doit être traité en respectant cette diversité. Outre les savoirs philologiques accumulés, un ensemble hétérogène de technologies sera utilisé, comme l'encodage en xml TEI et l'analyse textuelle à l'aide d'algorithmes d'exploration de données. Les résultats de ces actions seront également de nature multiforme et impliqueront la création de différents objets, des archives web aux résultats algorithmiques, en passant par des fichiers xml. Nous nous interrogerons alors sur la réalisation d'un modèle d'édition unifié et cohérent, étant donné l'hétérogénéité du corpus, des objets produits, et la dualité des œuvres éditoriales envisagées. Spécifiquement, nous faisons référence à la cohérence de la finalité intellectuelle et de la matérialité de la chaîne de publication. Nous commençons ainsi notre enquête en précisant le corpus du projet, les technologies impliquées, les objectifs généraux et les produits attendus. Ce seront les conditions préalables à la création de notre chaîne d'édition, tant au niveau de ses hypothèses théoriques que, plus tard, de sa structure pratique. Après ce schéma, nous détaillerons la stratégie éditoriale imaginée pour le projet, en souhaitant que cela constitue une piste de réflexion et un modèle possible pour d'autres projets éditoriaux d'une ampleur similaire.
## Présentation du projet

Le projet « Digital Leigh Hunt » est constitué de deux parties étroitement liées; d'abord, une base de données en ligne consacrée aux écrits critiques de James Henry Leigh Hunt, appelée la *Leigh Hunt Archive*, améliorera l'accessibilité et l'utilisation des œuvres de Hunt pour les études traditionnelles, mais surtout dans le cadre des humanités numériques. L'archive rendra disponible au public et aux communautés académiques l'intégralité des essais de Hunt dans un format approprié à leur pérennité et à la recherche numérique. Elle inclura également des outils de recherche spécialisés pour les humanistes qui seront intégrés à la plateforme elle-même. Ensuite, les résultats issus de plusieurs décennies de recherche selon les méthodes traditionnelles en littérature et les résultats provenant de méthodes computationnelles telles que l'utilisation d'algorithmes de fouille de textes sur l'archive seront publiés dans une monographie intitulée *Digital Leigh Hunt*. Ce livre présentera la vie de Hunt et son œuvre à la lumière des découvertes rendues possibles par la Leigh Hunt Archive. Le but premier de ce projet, qui s'étalera sur quatre ans, est d'étudier en profondeur, et à partir d'outils numériques, les interactions, influences et réseaux de l'auteur. Sa carrière a impliqué un certain nombre de cercles et de genres littéraires et politiques qui ont jusqu'à aujourd'hui surtout été traités de manière isolée; similairement, les études sur sa vie tendent à n'inclure qu'une partie limitée de cette dernière, sans jamais analyser l'ensemble de ses œuvres et de sa vie. Une nouvelle étude de l'éventail de ses travaux critiques au cours de sa carrière fournira des informations précieuses sur les
liens entre les mouvements romantique et victorien sur Hunt et sur sa vie pour mettre de l'avant son rôle clé en tant qu'éditeur, journaliste et poète durant la période romantique en Angleterre. Le projet permettra aussi de former des chercheurs, chercheuses, déjà établis en sciences humaines et des étudiants, étudiantes, qui seront impliqués dans la majorité des étapes, à l'utilisation d'outils numériques.

## Penser le projet

Afin d'identifier les éléments à prendre en compte dans la spécificité de notre projet d'édition, définissons d'abord les caractéristiques de la situation projectuelle dans son ensemble. En termes généraux, élaborer un projet signifie représenter un objet qui n'existe pas à un niveau accompli, empirique. N'ayant aucune correspondance dans le monde expérientiel, un tel objet ne peut être que prescrit et non décrit, il doit donc se fonder sur des choix théoriques et méthodologiques. Ces choix sont justifiés par le contexte, par exemple professionnel, académique, récréatif, dans lequel le projet lui-même est conçu. Le contexte est ainsi à la fois un champ théorique et un spectre d'alternatives pragmatiques. Il détermine un domaine de possibilités à partir duquel est définie la représentation projectuelle.

Conformément à ces considérations, dans le cas de «Digital Leigh Hunt», nous ne croyons pas à l'existence d'une seule solution projectuelle. Nous proposons cependant un modèle, inscrit dans son horizon et construit dans son champ de possibilités. Comme cela semble évident, la délimitation de cet horizon est une opération fondamentale, car c'est à partir de là que nous pourrons clarifier et justifier
nos choix méthodologiques. Il est donc nécessaire de définir
sa constitution. Notre paradigme est construit à partir de
certaines contraintes, que nous préciserons et définirons
plus tard. Déjà Ilya Prigogine et Isabelle Stengers, engagés
dans le travail de redéfinition épistémologique des sciences
après les découvertes anti-cosmologiques du siècle dernier,
ont noté le potentiel créatif des contraintes « culturelles,
politiques, économiques ». Ils écrivent comment celles-ci ne
doivent pas être comprises comme des externalités aux-
quelles on doit se soumettre, mais comme des entités « pro-
ductrices d'un sens que nous ne cessons de créer, et que nous
pouvons créer de telle sorte que ce ne soit pas contre elles,
mais avec elles que se construisent les voies nouvelles du
dialogue entre les hommes et avec le monde qu'ils habitent ».
En suivant la ligne tracée par les deux scientifiques, nous
pouvons affirmer que les contraintes qui caractérisent
« Digital Leigh Hunt » ne sont pas déjà entièrement données,
imposées de l'extérieur, mais elles ne sont pas non plus
créées de manière totalement arbitraire. Elles peuvent en
fait être le résultat de forces différentes, liées à la structure
matérielle, au contexte social et économique ou aux objec-
tifs culturels et intellectuels dans lesquels s'inscrit le projet.
Nous concevons donc l'idée de contrainte en cohérence avec
les principes de l'éditorialisation. Ici, le champ des possibles
tracé par les contraintes est aussi un plan de sens. Dans
notre cas, il s'agit du sens du projet, de sa portée.

Par conséquent, la méthode du projet s'inscrit d'emblée
dans le champ fixé par les contraintes du projet. Elle est
alors une stratégie de pensée, qui opère une synthèse des
contraintes énoncées et qui trouve leur cohérence. Cette
stratégie est aussi une pratique visant à la réalisation du
projet, à savoir de la représentation de l'objet conçu. Notre méthode doit, dès lors, être capable de répondre aux enjeux techniques et intellectuels du projet, de fournir un cadre pour satisfaire ses exigences matérielles et méthodologiques, de tenir compte de la diversité des savoirs impliqués et des résultats attendus. Une méthode qui doit être en fin de compte compréhensible pour les différents acteurs du travail d'édition, mais également opérable par une machine. Pour ces raisons, notre stratégie est inspirée par le paradigme de la programmation littéraire (Literate Programming). Donald Knuth théorise en effet la nécessité de considérer les programmes informatiques comme des « œuvres littéraires ». Cela implique la nécessité d'exprimer ces mêmes programmes dans un langage naturel et de les organiser de manière à ce qu'ils contiennent le code exécutable. Le programme est donc compris comme une superposition de couches d'abstraction. Logiquement, sa couche la plus générale doit pouvoir être traduite à la fois en documentation et en code informatique. Ainsi, la correspondance entre l'opération algorithmique et la documentation devient souvent sa description verbale. Outre la lisibilité, un deuxième critère fondamental du paradigme de Knuth est la modularité: la division du programme en sections indépendantes facilite son extensibilité et son adaptabilité.

Dans notre cas, le principe de modularité est utile pour décrire la multiplicité des actions techniques envisagées et pour préciser leurs différences, leurs logiques spécifiques et leurs objectifs. Parallèlement, l'intime complémentarité et la correspondance entre la documentation et le langage informatique nous semblent essentielles pour préciser la cohérence interne du projet, en définissant la manière dont ces
différentes actions s'intègrent dans leur participation à la
production des résultats souhaités. Enfin, le paradigme de la
programmation littéraire vise à faciliter la collaboration au fil
du temps entre la pluralité changeante des personnes impli-
quées dans la création, la maintenance et l'évolution du pro-
gramme. Compte tenu de la multiplicité des acteurs
nécessaires à la création des résultats que nous avons envi-
sagés, nous reconnaissons la centralité de ce point également
pour la réussite de notre projet de publication. Dans notre cas,
il est en fait utile que chaque personne qui contribue au projet
soit au courant de ses autres sections. Nous pouvons affirmer
cela à la fois en vue de l'intégration de différentes sections
pour la réalisation des résultats escomptés, et au bénéfice de
la cohérence entre les modules vis-à-vis des objectifs plus
généraux du projet. La modularité et la création d'une docu-
mentation entièrement conforme à la structure formelle des
opérations informatiques nous semblent être des choix
méthodologiques importants, utiles pour nos intentions
éditoriales et cohérents avec notre contexte matériel et tech-
nique. Cependant, dès ce stade précoce, nous constatons que
la méthode développée par Knuth ne peut être intégralement
adoptée dans notre projet. Les éditions papier et numérique
diffèrent non seulement par leur format, mais aussi par leur
contenu et leurs objectifs. Elles ne peuvent donc pas être
dérivées d'un code source unique, comme le prévoyait le
paradigme de la programmation littéraire. Pour élaborer la
méthode spécifique au projet, il convient de revenir sur les
contraintes qui en déterminent les possibilités de réalisation.
En les observant en détail, nous pourrons constater plus pré-
cisément comment la modularisation et la documentation
exhaustive servent nos objectifs.
## Les contraintes

Comme nous l'avons mentionné au début de ce chapitre, l'objectif du projet «Digital Leigh Hunt» est de composer au minimum deux documents distincts: un site web pour archiver les œuvres de Hunt encodées en xml TEI et une monographie critique basée sur cette archive et sur les résultats obtenus grâce aux outils d'analyse de texte appliqués à l'archive. Une fois produits, ces objets nous serviront de point de départ pour organiser le projet de l'édition critique. À la différence du cadre strictement numérique énoncé dans les chapitres précédents, nous sommes confrontés avec ce projet à deux objets spécifiques, l'un dans un format papier, et l'autre dans un format numérique. Chacun comporte son lot de contraintes en matière d'organisation et de réalisation. On pourrait donc supposer que les deux livrables suivraient un cheminement parallèle pour arriver jusqu'à l'étape de leur diffusion. La forme la plus évidente d'organisation serait de mener ainsi le projet: en divisant les flux de travail des livrables. Toutefois, est-ce réellement souhaitable? Dans le cadre de cette édition critique, les différentes informations devraient circuler d'un objet à un autre, depuis les œuvres numérisées de Hunt jusqu'à la monographie, en passant par les analyses textuelles. Dès lors, il devient nécessaire de penser à des dispositifs de communication entre les documents, donc de penser une chaîne projectuelle personnalisée pour cette édition critique et ses multiples enjeux.

Cependant, avant d'entamer cette exploration d'une chaîne éditoriale, il convient de faire un pas en arrière afin d'observer les contraintes rattachées à nos livrables. Il ne
s'agit pas de dresser une typologie des contraintes et d'être
exhaustif en tout point, mais plutôt de se focaliser sur deux
enjeux pivots seulement. Le point d'entrée des contraintes
de nos deux objets se trouve dans leurs aspects matériels
complètement opposés, ce qui soulève en premier lieu la
problématique de l'interopérabilité des informations au
sein du projet. La matérialité de nos objets contient, notamment d'un point de vue culturel, des lignes directrices (*quiddelines*) relatives à la manière de les travailler. Ce que nous
considérons comme des contraintes (matérielles) sont initialement des caractéristiques propres à la matière, qui
agissent comme des repères indiquant un sens dans lequel
les matériaux peuvent être transformés ou convertis : c'est
là que nous trouvons nos lignes directrices. Dès qu'elles sont
situées dans un contexte, celles-ci deviennent des caractéristiques positives ou négatives en fonction des avantages ou
inconvénients qu'elles apportent: si elles sont négatives,
nous les appelons contraintes. Dans le contexte des chaînes
éditoriales, ces lignes directrices traitent de la constitution
et de la circulation de l'information, qu'il s'agisse des composantes humaines ou logicielles. Telle qu'elle est ainsi
présentée, la chaîne projectuelle commence à s'étendre pour
se transformer en une chaîne d'éditorialisation.

Dans un premier temps, nous décrivons les chaînes pro-
jectuelles traditionnelles de nos deux livrables afin de
mettre en exergue les maillons qui nous intéressent pour
construire notre flux de travail. À propos du premier
livrable, la chaîne éditoriale d'une monographie débute
généralement par l'écriture et le traitement du texte. Une
fois le texte achevé, il subit une série de relectures et de
corrections, puis une relecture officielle par les pairs, avant
d'arriver entre les mains de l'éditeur et d'être calibré selon
une mise en page conforme aux besoins de l'imprimeur. Le
livre sera ensuite imprimé selon le nombre d'exemplaires
prédéfini, puis diffusé sur les marchés ciblés. Concernant les
phases qui touchent à l'écriture, la plupart des textes en
sciences humaines sont tapés dans un logiciel de traitement
de texte du type Microsoft Word. Or, ce n'est pas l'environ-
nement idéal pour réaliser ce type d'écrits: les textes sont
bloqués dans un format propriétaire qui n'est pas du tout
operable, et les fonctionnalités nécessaires à l'écriture
savante sont absentes du logiciel. Il n'est pas possible (ou il
est difficile) de sémantiser le contenu, c'est-à-dire d'expli-
citer aux lecteurs – êtres humains et machines – le sens
donné aux mots. Dans la même dynamique, ce type de
fichier ne peut pas être réutilisé en l'état (c'est-à-dire selon
le format propriétaire) pour être transformé dans sa forme
livrable: un livre n'est jamais imprimé dans le format docx;
il faut ajouter une phase de PAO (Publication assistée par
ordinateur) et passer par des formats intermédiaires avant
l'impression. Exactement de la même manière, si on sou-
haite qu'un livre fasse l'objet d'une double édition – numé-
rique et papier –, il n'est pas possible d'utiliser directement
ce fichier dans les supports de lecture numérique, comme
un site web ou une liseuse. Nous venons à peine d'effleurer
cette question que nous rencontrons déjà des obstacles forts
qui perturbent le flux éditorial et bloquent un certain
nombre d'actions. Il existe cependant d'autres solutions à
cette chaîne, comme celle du présent livre, qui s'appuient
sur des formats libres (notamment Markdown, TEX, xml,
etc.) pour pallier les questions de sémantique et d'interopé-
rabilité. Nous détaillerons dans la prochaine partie le prin-
cipe de cette solution – le *single source publishing* – sur lequel Robert Alessi et Marcello Vitali-Rosati ont constitué la chaîne d'édition de cet ouvrage.

Concernant le deuxième type de livrable, le site web, nous avons affaire à une chaîne éditoriale totalement différente. Depuis l'avènement des outils de gestion des contenus (CMS, pour *Content Management System*), la plupart des contenus publiés en ligne passent par une étape d'organisation des informations dans la page web. Les écrits ne sont plus figés dans le *html* de manière brute et sont traités au moyen d'un logiciel (WordPress, Omeka S, Spip, Prestashop, Magento, etc.) pour être indexés et affichés selon les modalités dynamiques qui caractérisent le Web. Dans cette chaîne éditoriale, le fond et la forme sont séparés: le modèle du Web incorpore un langage de gestion de la mise en page (*Cascade Style Sheets*) paramétrable en dehors des textes. Une fois le modèle de mise en page sauvegardé, il est appliqué automatiquement aux documents texte, qui seront indexés via le CMS. Par exemple, les titres de niveau 1 s'afficheront avec une police de caractères Helvetica, de taille 20, de couleur bleue et le corps de texte en police de caractères Times, de taille 14 et de couleur noire. Les CMS ne sont qu'une technologie parmi d'autres, nous pouvons aussi évoquer les générateurs de site statique arrivés sur le marché à la fin des années 2000 comme Hugo, 11ty, Svelte ou Astro. Leur principe de fonctionnement est complètement opposé au principe des CMS, puisque le générateur transforme des fichiers textes – dans des formats tels que *Markdown*, *reStructuredText* ou encore *EsciiDoc* – en *html*, oblétérant ainsi la base de données. Toutefois, nous retrouvons le même principe que précédemment: un modèle en CSS est appliqué au
l'organisation logique des tâches n'est pas permutable ou modifiable, la tâche B ne pouvant être exécutée avant la tâche A. Or, ce que nous dit Fauchié est que le passage au numérique ne remet pas cet ordonnancement des tâches en cause. Les techniques de travail changent – ainsi que la capacité de production –, mais pas la manière de l'aborder: l'édition est en constante évolution technique depuis ses débuts, ce n'est pas un fait nouveau et le numérique ne la révolutionne pas. Ainsi, des logiciels s'imposent sur le marché de l'édition: la suite Office de Microsoft pour le traitement de texte et la suite Adobe pour la mise en page. Le type de chaîne pensé avec ces outils est bien linéaire.

Pourtant, le potentiel du numérique permet de remettre en cause ce paradigme de la chaîne et de le faire évoluer dans une autre forme: celle du système modulaire, dans lequel le travail d'édition ne repose plus sur une seule dimension (linéaire), mais sur un ensemble complexe où chaque tâche se distingue des autres. Nous avons commencé à aborder ce sujet lors de la présentation du livrable au format web et du découpage des tâches de mise en page et d'écriture des contenus. Cependant, ce n'est pas un principe qui chamboule la totalité de la chaîne éditoriale: l'impression ne peut pas être réalisée au début du processus, certaines étapes charnières ne peuvent pas changer d'ordre d'exécution. Un système de publication modulaire se définit par le fait que «les étapes de la publication ne se suivent plus d'une manière irréversible». Les mouvements dans le flux de travail peuvent ainsi être exécutés dans plusieurs directions: des retours en arrière, la séparation des branches du projet en module, la jonction des différentes branches en un même nœud, etc. Dès lors, les modules sont définis comme indépendants à
l'intérieur du système à partir du moment où le principe d'interopérabilité n'est pas remis en cause. La condition de bon fonctionnement d'un système repose sur la communication entre les différentes briques qui le fondent. Un système au sein duquel ce mouvement n'est pas permis, ou qui se brise, redevient linéaire et perd en élasticité, et cela quelles que soient les technologies employées.

Un exemple de système modulaire de publication est celui du single source publishing. Le principe organisationnel consiste à utiliser une source unique (elle peut être composée de plusieurs documents comme nous le verrons plus loin) et à opérer des transformations ou conversions des fichiers jusqu'à obtention des objets souhaités (dans divers formats de sortie: papier, web, ebook, etc.) et ce en limitant la perte sémantique. Le déploiement d'un tel système requiert de s'émanciper des formats propriétaires et d'utiliser des standards ouverts, comme le xml. D'autres formats de balisage plus légers peuvent être envisagés, tels que Markdown ou AsciiDoc: l'idée de marquage sémantique du texte permet de lui attribuer une caractéristique opératoire significative. La sémantisation explicite des contenus n'est pas uniquement adressée au lectorat humain, mais également au lectorat des machines. Un titre balisé permet de rendre explicite à la lecture qu'il s'agit d'un titre, mais également d'indiquer son niveau dans la hiérarchie des informations. Il devient alors possible de traiter automatiquement cet objet pour le transformer, par exemple en lui appliquant un gabarit pour modifier son affichage. L'application d'un tel modèle passe par l'apprentissage des caractéristiques et des possibilités des différents formats intégrés dans le système. Des données en JSON ne peuvent pas être encodées selon les mêmes procédés
que dans les formats XML ou CSV. Chaque format est contraint
par un certain nombre de règles ou de lignes directrices qui
délimitent les possibles réalisations applicables à un format.
L'enjeu de cet assemblage modulaire consiste à penser les
mécanismes de passage d'un format à un autre en respectant
les lignes directrices sans perdre d'information au cours de
l'opération. Par exemple, des données primaires stockées
verticalement (par niveaux hiérarchiques) peuvent être
converties dans une forme horizontale: mais on perd alors
des informations capitales, c'est-à-dire la hiérarchie de l'infor-
mation. Une des possibilités pour contourner cette contrainte
serait d'implémenter la technologie de l'hyperlien pour ren-
voyer les données horizontales vers des sous-ensembles de
données (toujours horizontaux) de manière à exprimer les
liens hiérarchiques à l'intérieur du système de données. Une
des principales contraintes de ce type de système, contraire-
ment au type linéaire, est la difficulté technique à maintenir
cet ensemble fonctionnel: si chaque brique est indépendante
des autres, il faut néanmoins s'assurer qu'elles continuent à
fonctionner ensemble. L'obsolescence qui caractérise le
numérique s'avère également une contrainte pour un sys-
tème éditorial, puisqu'elle exige une infrastructure solide en
termes de savoirs et parfois de matériels. Un exemple concret
basé sur le principe du *single source publishing* est l'éditeur de
texte sémantique pour les sciences humaines Stylo, déve-
loppé par la Chaire de recherche du Canada sur les écritures
numériques. Stylo fonctionne à partir de trois fichiers
sources: un fichier au format *BIBTEx* pour la bibliographie, un
fichier au format *YAML*, pour la gestion des métadonnées et
un fichier en *Markdown*, pour le texte. Ce fonctionnement est
un peu invisibilisé pour les instances utilisatrices qui agissent
dans l'interface du logiciel mais qui, selon un usage plus avancé, peuvent éditer les données brutes de chaque fichier. Stylo permet donc de prévisualiser le document en html et de les exporter dans différents formats: TEX, PDF, ePub, docx et html notamment.

Comme nous l'avons mentionné précédemment, un autre exemple est celui du système éditorial déployé pour cet ouvrage. Robert Alessi et Marcello Vitali-Rosati ont décidé de mettre en place une chaîne basée sur le principe de single source publishing pour pouvoir décliner ce livre en plusieurs objets, une version imprimée traditionnelle et une version numérique augmentée. Les technologies utilisées pour les documents sources sont LATEX (le format TeX) pour les documents textes et le format BibTeX pour la gestion bibliographique. La technologie LATEX permet de dissocer les contenus selon l'organisation du projet: un fichier principal appelle les sous-fichiers (dans lesquels se trouve le contenu textuel) selon une organisation et une hiérarchie précises. Le fichier ainsi généré peut ensuite subir une série d'opérations (transformation et/ou conversion) pour produire soit du HTML pour la version numérique soit du PDF pour la version imprimée.

Nous voyons bien que le principe de single source publishing permet, à partir d'une source, d'obtenir une multitude d'objets produits contenant les mêmes informations. Or, ce n'est pas tout à fait l'objectif du projet d'édition critique « Digital Leigh Hunt », puisque nous souhaitons générer des objets dont les contenus different.
## La toile de Knuth

Le système basé sur le principe de *single source publishing* n'est qu'un exemple parmi d'autres. Il illustre cependant très bien les capacités modulaires qui peuvent être attribuées à un projet. Cela étant dit, il nous faut encore établir un projetocole adapté à nos objets. Pour rappel, nous souhaitons produire une monographie et un site web dont les contenus different, mais avec une base commune : l'œuvre de Leigh Hunt. Pour comprendre précisément les besoins du projet, il est nécessaire de repérer les échanges d'informations entre nos documents : comment sont-ils reliés ? Quelles données et informations vont transiter entre les documents et dans quel sens ? Dans la présentation du projet, au début de ce chapitre, il est spécifié que les archives de Hunt, ainsi que les analyses qui en seront tirées à la suite de l'application d'algorithmes de fouille de texte, permettront d'écrire la monographie. Inversement, des segments de la monographie pourront, *a posteriori*, enrichir la Leigh Hunt Archive, non pas comme source primaire (puisqu'il ne s'agit pas d'une œuvre de Hunt), mais plutôt comme des objets périphériques. Nos premières contraintes concernant la construction d'une chaîne éditoriale étaient les livrables, que nous avons définis plus clairement en décrivant les échanges d'informations à l'intérieur du système de travail. Maintenant, comment pouvons-nous mettre sur pied une chaîne fonctionnelle qui correspond aux enjeux susmentionnés ? Pour y répondre, nous allons faire un saut temporel en l'an 1984, non pas dans le monde de Winston Smith, mais dans celui du paradigme de la programmation littéraire de Donald Knuth. Ce concept, établi par l'inventeur du langage
TEX, s'adresse principalement au champ de l'architecture logicielle. Il consiste à générer le programme et sa documentation à partir d'une source unique, comme nous l'avons vu. Le paradigme de la programmation littéraire est un protocole incarné sous la forme d'un «document». En tant que tel, le «document» devient alors une pièce centrale dans l'établissement du système modulaire de publication de Knuth, qui d'ailleurs est très proche du principe de *single source publishing*. Dans le cas de la «Digital Leigh Hunt», ce n'est pas son application directe que nous recherchons, mais le principe qui la constitue à partir duquel nous allons penser notre système de publication. Dans sa méthode, Knuth centralise les échanges dans un document source par l'utilisation d'un double langage, du texte brut et un langage de programmation de bas niveau, pour produire ses objets finaux. La source contient l'ensemble des informations permettant de produire des objets totalement différents en fonction des modèles qui lui sont appliqués (*weaver et tanger*). Ainsi le protocole permettant de créer le document source est un protocole de distribution des informations. À partir de ce modèle, nous déplaçons le curseur du paradigme de la programmation littéraire vers la conceptualisation d'une chaîne adaptée à l'édition critique que nous nommons «la toile de Knuth».

L'adaptation de la toile de Knuth à notre projet commence par la composition de la documentation sur laquelle seront accolées les technologies de conversion et de transformation des fichiers sources vers les formats de destination. La documentation n'est pas un document unique à proprement parler: elle est composée d'un document-racine qui détaille le projet, des modalités de communica-
tions et d'échanges d'informations entre les modules, mais aussi d'autant de modules qu'il y a de livrables et d'autant de sous-modules qu'il y a de types de documents. Par exemple, un des modules serait dédié au site web et à l'archivage des œuvres de Hunt en xml TEI, et les sous-modules seraient les schémas xml choisis pour chaque type d'œuvre: un poème, un roman, une lettre, etc. Le sous-module devient la documentation permettant à la personne qui traite l'œuvre de comprendre le schéma d'encodage en xml TEI, mais est également la documentation computable qui permet de vérifier le bon respect du schéma. S'il s'agit de faire transiter une information entre les sous-modules d'un module, c'est au sein de ce dernier que seront gérés les échanges d'informations. Dans la même veine, le déplacement des informations d'un module à un autre passera toujours par la documentation, mais au niveau du document-racine. Nous pourrions centraliser totalement la documentation dans un même fichier, mais nous serions face à deux risques: premièrement, il y aurait beaucoup d'informations au même endroit et les utilisateurs, utilisatrices pourraient être noyés dans un tel flot; deuxièmement, les modules ne seraient plus indépendants. Si nous regardons attentive-ment, l'architecture de la documentation est déjà sous la forme d'une toile sur laquelle viendront s'agréger les livrables tout au bout de chacune des branches. La communication entre modules passe forcément par le centre, qui relie toutes les branches entre elles. Dès lors, il nous semble clair que dans notre système, la documentation ne se limite pas à enregistrer les opérations qui ont lieu dans tous les modules, mais elle prescrit également la procédure par laquelle ces modules doivent être intégrés pour constituer
le projet. Et c'est cette valeur prescriptive qui fonde le projet, en tant que cohérence théorique et matérielle. Plus précisément, c'est le document-racine qui établit l'intégrité du projet. Si, par la suite, d'autres actions, méthodes ou produits sont ajoutés au système, ceux-ci seront automatisquement inscrits dans le document-racine, donc dans la dynamique de communication entre les sections déjà décrite. Ce document est ainsi le garant non seulement de l'interopérabilité de notre système, mais aussi de son caractère circulaire et autorégulateur, caractéristiques essentielles de tout protocole. Ce document définit par conséquent notre système en tant que protocole.

Pour conclure sur la toile de Knuth, nous avons souhaité préserver les conditions qui nous semblaient nécessaires au bon fonctionnement d'un projet d'édition critique numérique multiformat, en positionnant au centre de notre protocole la modularité, donc la capacité pour chaque module d'être indépendant vis-à-vis du reste de la chaîne, et l'interopérabilité à l'intérieur de la chaîne de publication.

## Conclusion

La solution présentée part du défi posé par l'extrême hétérogénéité des compétences, des acteurs, des technologies et des produits impliqués dans le projet d'édition critique «Digital Leigh Hunt». Nous avons imaginé une méthode unifiée et cohérente pour l'ensemble du projet, en le structurant d'un point de vue opérationnel et théorique. Elle est généralisable et adaptable à d'autres projets : c'est une façon de penser au concept de l'édition numérique. Nous avons commencé par exposer les contraintes liées à la nature
multiforme du projet, qui nous interpellent et jouent un rôle central dans la délimitation du champ de recherche relatif à la construction du projet lui-même. Il nous semble que les contraintes, à leur tour, se structurent à partir des produits imaginés et qu'ensemble, elles se définissent au fur et à mesure que les produits eux-mêmes se déterminent. De manière quasi autonome, notre méthode naît, d'une part, de l'analyse de la structure des contraintes et des produits et, d'autre part, de l'effort d'harmonisation entre ces deux éléments. Nous avons choisi les concepts de modularité et d'interopérabilité théorisés par Donald Knuth, car ils sont particulièrement utiles pour notre réflexion et notre synthèse. La méthode « Digital Leigh Hunt » est composée de ces deux principes, réinterprétés et adaptés à partir des contraintes, des produits et des acteurs de notre étude de cas. Le projet imaginé devient sa méthode, un système qui régule de manière autonome ses actions, donc un protocole.

Bien entendu, nous notons les limites d'une telle structure protocolaire. Celles-ci sont principalement liées à la centralisation presque complète de notre système, pourtant pensé comme modulaire. L'operability entre les modules dépend en fait uniquement du document-racine. Cela augmente la vulnérabilité de la structure. Nous notons cependant que la computabilité des modules isolés ne serait pas compromise par la disparition du document-racine. Les formats et normes utilisés dans le système sont en fait complètement indépendants de celui-ci, operables – orientés vers l'extérieur du système –, ouverts, et largement usités au sein de différentes communautés. Dans ce cas de figure, l'unité du projet prendrait fin. Afin de maximiser l'ouverture vers l'extérieur du système, nous devrions alors
imaginer un protocole moins centralisé, dans lequel les informations envisagées pour constituer le document-racine seraient indexées directement dans les modules.

Il est certain que d'autres solutions au problème qui a animé notre étude sont possibles. Néanmoins, nous pensons qu'il est indispensable de repenser la portée des contraintes contextuelles et conceptuelles afin de donner un arrière-plan stratégique au projet et, plus précisément, de mieux comprendre la nature et l'objectif d'une telle publication à multiples facettes.