summaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorRochDLY <roch.delannay@gmail.com>2024-05-15 19:10:57 +0200
committerRochDLY <roch.delannay@gmail.com>2024-05-15 19:10:57 +0200
commit76c60d78d4603c0f12428b9def262f8bd5288c33 (patch)
tree1b175a89db94f2766015271390e54c8f06c4393a /src
parent5b2891a43eedab9683057b1ecb752f37d087e639 (diff)
downloadpandoc-site-76c60d78d4603c0f12428b9def262f8bd5288c33.tar.gz
pandoc-site-76c60d78d4603c0f12428b9def262f8bd5288c33.tar.bz2
pandoc-site-76c60d78d4603c0f12428b9def262f8bd5288c33.zip
update billet sur la saisie du texte dans une nouveau document
redistribution de l'étude de cas (Stylo) dans le chapitre et réalisation de quelques transitions entre les parties + les liens à la problématique. Il faut encore faire ce travail là pour la fin du chapitre et peut-être voir où remettre la déprise (peut-être la mettre en ccl). Attention il faudra faire une relecture globale car risque majeur de redondance. En ccl il faudra faire le rappel de toutes les mini-ccl intermédiaires pour bien répondre à la pb.
Diffstat (limited to 'src')
-rw-r--r--src/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.md1403
1 files changed, 1379 insertions, 24 deletions
diff --git a/src/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.md b/src/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.md
index 26d27fe..abe28e7 100644
--- a/src/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.md
+++ b/src/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.md
@@ -52,8 +52,8 @@ Ce trouble nait de la rencontre entre une représentation du texte structurée
graphiquement et une représentation du texte structurée par du texte, comme
c'est le cas pour une page web interprétée par un navigateur et son pendant au
format HTML.
-Notre intérêt se porte sur plus particulièrement sur le côté
-machine de cette interaction humain-machine et comment elle perçoit, reçoit
+Notre intérêt se porte plus particulièrement sur le côté
+machine de cette interaction humain-machine et comment elle reçoit
et traite les informations pour produire le document à travers un environnement
particulier.
@@ -115,8 +115,10 @@ bibliographiques BibTeX qui offrent la possibilité de produire plusieurs format
de sortie depuis une source unique.
Stylo suit donc le principe de _single source publishing_
[@fauchie_fabriquer_2024].
-Pandoc, le « couteau suisse de l'édition », génère les formats de sortie PDF
-(avec l'aide de LaTeX), HTML, XML-TEI ou encore DOCX.
+En s’appuyant sur Pandoc, un outil de conversion de documents désigné comme le
+« couteau suisse de l’édition », le module d’export de Stylo génère les formats
+de sortie PDF (avec l’aide de LaTeX), HTML, XML-TEI, DOCX ou encore XML
+compatible avec le schéma COMMONS commun à Métopes, Cairn et OpenEdition.
Le choix d'étudier Stylo comme terrain pour cette recherche découle de plusieurs
raisons.
@@ -244,7 +246,8 @@ Les premiers logiciels de traitement de texte comme Electric Pencil ne
permettent pas alors une gestion de la mise en page idéale ni ne fonctionne sur
tous les modèles d'ordinateurs présents sur le marché^[Un autre logiciel comme
`TeX` développé en 1984 par Donald Knuth tente de résoudre ce problème de la
-mise en page selon une approche WYSIWYM alors que la tendance est plutôt aux
+mise en page selon une approche WYSIWYM, que D. Knuth nomme
+_Literate programming_ [@knuth_literate_1984] alors que la tendance est plutôt aux
interfaces WYSIWYG].
Ainsi, écrire sur un support connecté paraît aujourd'hui être une évidence alors
qu'il a fallut déployer de lourds efforts à une époque ou cette évidence était
@@ -267,8 +270,39 @@ d'une écriture numérique dans un environnement informatique.
### Les particularités de l'écriture numérique
-L'écriture numérique diffère d'une écriture plus traditionnelle -- par exemple
-manuscrite -- et se distingue notamment par trois caractéristiques que sont la
+Avant d'entamer une réflexion sur l'écriture numérique, convenons d'une brève
+définition l'écriture, car celle-ci a fait couler beaucoup d'encre
+à son sujet, notamment depuis sa reconfiguration numérique au crépuscule du 20^e^ siècle.
+La définir tient généralement de l'anthropologie, des lettres, de la sémiotique
+ou encore des sciences de l'information et de la communication ou de l'étude des
+médias et cela pour ne mentionner que certaines disciplines de la sphère
+académique.
+Très largement, l'écriture est entendue comme « mode d'expression » et
+« fonction de communication » au sein d'une société [@christin_les_1999].
+Anne-Marie Christin distingue deux tendances principales de l'origine de
+l'écriture : l'écriture selon la trace, étant soit comprise comme le signe
+verbal transposé sur un support soit comme la marque laissée par un corps, ou
+l'écriture selon le signe dans son sens étymologique d'« événement inaugural
+[qui] participe
+d’une révélation » tant qu'il s'inscrit dans un « système » tel que la
+disposition des entrailles d'une bête sacrifiée lors d'une cérémonie
+[@christin_les_1999; @vitali-rosati_quest-ce_2020].
+À défaut de prendre parti pour l'un ou l'autre de ces paradigmes, nous pouvons
+retenir deux caractéristiques qui leur sont communes et que l'on retrouve dans
+tous types d'écriture, même numérique.
+Lorsque l'écriture est convoquée, elle fait appel à deux actions : l'inscription
+et l'interprétation.
+Qu'il s'agisse d'une trace ou d'un signe, retenons que l'écriture est toujours
+inscrite sur un support et que cette inscription fait l'objet d'une lecture
+et d'une interprétation.
+Cette association apparaît régulièrement dans les travaux qui traitent de
+l'environnement numérique, par exemple sous l'appellation de littératie
+numérique chez Milad Doueihi [-@doueihi_grande_2011] ou de lettrure chez
+Emmanuel Souchier [-@souchier__2012].
+
+Toutefois, l'écriture numérique diffère d'une écriture plus traditionnelle,
+telle que nous venons de la défnir, et se
+distingue notamment par trois caractéristiques que sont la
calculabilité [@crozat_ecrire_2016], la variabilité [@bouchardon_lecriture_2014]
et la rupture sémiotique entre le geste d'écriture et l'inscription sur le
support [@souchier_numerique_2019].
@@ -348,9 +382,29 @@ attendue, comme un éditeur de texte, la frappe d'une touche déclenchera un
événement et le logiciel pourra générer l'instruction correspondant à l'action
d'écrire.
-[ecrire une phrase ou deux de transition]
-
-### La machine, une entité formée du couple matériel/logiciel.
+Ces trois caractéristiques de l'écriture numérique ne sont pas uniquement des
+propriétés qui s'ajoutent à l'existant et, d'une certaine manière, rendrait
+l'écriture plus complexe.
+L'écriture, nous l'avons évoqué, peut être ramenée aux actions d'inscription
+dans la matière et de lecture.
+Or, la calculabilité, la variabilité et la déliaison entre geste et inscription
+perturbent notre définition de l'écriture puisque l'inscription et la lecture
+des signes et/ou traces sur le support numérique sont des actions réalisées par la
+machine et plus par l'être humain, comme le souligne F. Kittler [@kittler].
+F. Kittler poursuit sa réflexion plus loin jusqu'à soutenir, de manière
+provocatrice, que l'humain n'écrit plus et qu'à l'ère du numérique, c'est la
+machine qui écrit.
+À défaut de prendre cette provocation au pied de la lettre, elle ouvre la
+perspective d'une machine qui participe et contribue à l'écriture et, ce
+faisant, participerait à la production de l'intimité du chercheur.
+
+Seulement, lorsque l'on parle d'écriture numérique, on convoque la "machine" ou
+l'"ordinateur".
+Ces appellations sont toutefois un peu vagues et ne rendent pas très explicite les
+éléments qu'elles désignent, ni ceux qui sont impliqués dans cette action
+d'écriture.
+
+### La machine, une entité formée du couple matériel/logiciel
La représentation d'un ordinateur est souvent associée à un couple matériel /
logiciel.
@@ -527,10 +581,6 @@ Le passage par un système d'exploitation permet aux logiciels de ne plus
dépendre d'un modèle particulier du _hardware_ et d'en faire justement
abstraction, le rendant ainsi opérable sur différentes machines.
-[faire une phrase de transition]
-
-### Une ouverture sur la machine
-
Ce tour d'horizon des particularités de l'écriture numérique et de l'agencement
entre logiciel et matériel dans la machine nous montre que la
conception de la machine ne permet pas à un auteur d'y inscrire des signes dans
@@ -589,13 +639,12 @@ Chacune de ces fenêtres offre finalement une vision particulière d'un document
et un modèle épistémologique qui lui est propre
[@vitali-rosati_editorialization_2018].
-
Dans la partie suivante, nous étudions le logiciel Stylo à partir de l'écran comme
interface d'échange de signes entre les deux protagonistes, utilisateur et
-machine, puis, en dépassant cette surface, et en nous dégageant du prisme essentialiste, nous démontrerons
-que les différents agents d'un environnement -- principalement logiciels et humain
--- sont des dynamiques qui, lorsqu'elles sont agencées dans une configuration
-particulière, co-construisent l'écriture.
+machine, puis, en dépassant cette surface, et en nous dégageant du prisme
+essentialiste, nous démontrerons que les différents agents d'un environnement
+-- principalement logiciels et humain -- sont des dynamiques qui, lorsqu'elles sont
+agencées dans une configuration particulière, co-construisent l'écriture.
[détailler le prisme essentialiste en une phrase ou deux]
@@ -603,22 +652,1328 @@ particulière, co-construisent l'écriture.
### Le logiciel comme architexte
-[reunir peut etre ces deux sous-parties]
-
-### L'architexte derrière l'écran
+Sans l'intervention du logiciel entre l'être humain et la machine, il ne serait
+pas possible pour un auteur d'écrire sur le support de l'inscription numérique.
+Si l'on considère l'écriture comme le geste d'inscrire une trace ou un signe sur
+un support, alors l'écriture numérique n'est plus un fait humain mais un acte
+réalisé par l'ordinateur lui-même.
+
+L'interaction entre un humain et une machine consiste, comme nous l'avons vu, en
+une série d'instructions que donne l'utilisateur à la machine qui, ensuite, les
+exécute.
+Le mécanisme sous-jacent à ce que l'on considère communément comme l'écriture
+numérique -- frapper une touche du clavier et voir la lettre s'afficher à
+l'écran -- s'avère être plus complexe.
+Le moment de la frappe n'est plus le moment où le symbole que l'on voit figurer
+sur la touche du clavier est inscrit dans le disque dur, il s'agit plutôt du
+moment où une instruction est donnée à l'ordinateur qui ensuite se charge
+d'inscrire la lettre correspondante sur le disque dur.
+Si l'on se trouve dans le cas de figure de la saisie d'un texte dans un éditeur
+de texte, l'instruction suivante, selon les logiciels et les actions souhaitées,
+consiste à afficher à l'écran le symbole encodé dans la mémoire de l'ordinateur.
+
+Pour réaliser cette suite d'actions, Yves Jeanneret et Emmanuël Souchier partent
+de ce constat qu'il n'est pas possible d'écrire un texte numérique sans qu'un
+autre texte soit déjà présent pour réaliser cette action.
+Ce texte particulier qui pré-existe toute activité numérique est nommé
+architexte [@souchier_numerique_2019].
+
+L'architexte est un concept d'abord employé par Gérard Genette
+[-@genette_introduction_1979] et désigne « l'ensemble des catégories générales,
+ou transcendantes -- types de discours, modes d'énonciations, genre littéraires,
+etc. --, dont relève chaque texte singulier ».
+
+En 2019, dans leur ouvrage intitulé _Le numérique comme écriture_, G. Gomez
+Mejia, W. Candel et E. Souchier résument l'architexte numérique comme :
+
+> Initialement défini comme "écriture d'écriture" puis comme un "dispositif
+> d'écriture écrit", l'architexte s'avère être un point de passage obligé pour
+> toute activité numérique. Il n'y a effectivement pas d'écriture à l'écran sans
+> un architexte qui la rend possible, l'accompagne et la formate. Pour la
+> première fois de son histoire, l'homme a donc recours à des "dispositifs
+> d'écriture écrits" spécifiques pour pouvoir pratiquer une activité d'écriture
+> (E. Souchier, 1998, 2013). Or, précisément en ce qu'ils sont "eux-mêmes
+> écrits", les architextes "sont des textes lisibles et interprétables. Porteurs
+> et prescripteurs d'une écriture à venir, ils anticipent de ce fait une figure
+> de l'auteur" (É. Candel, G. Gomez Mejia, 2013) et relèvent donc de
+> "l'énonciation éditoriale" (E. Souchier, 1998).
+
+Globalement, l'architexte incarne le cadre dans lequel les agents peuvent
+écrire.
+Il permet de faire la distinction entre un gabarit, entendu comme l'espace
+proposé par les éditeurs de logiciels ou applications pour écrire, et le texte
+saisi par l'utilisateur, c'est-à-dire le texte qui remplit le gabarit.
+Cet architexte, ce cadre, est régit par des règles qui définissent comment l'on
+peut écrire sur un support numérique mais également comment les signes à
+inscrire doivent être formatés.
+
+Nous l'avons vu, l'architexte se positionne en tant que médiateur entre un
+auteur et la machine qu'il emploie pour écrire.
+Jusqu'à présent, la définition de l'architexte englobe largement tous les écrits
+qui permettent d'écrire à l'écran.
+En 2019, G. Gomez-Mejia, E. Souchier et E. Candel précisent ce que sont ces
+méta-écritures et en dressent une typologie composée de quatre « cadres d'écrits
+d'écran » :
+
+- le matériel
+- le système
+- le logiciel
+- le document
+
+Le premier cadre, matériel, désigne toute la composante physique de l'ordinateur
+et surtout l'écran sur lequel est affiché le texte.
+Le cadre système, quant à lui, est associé à la couche permettant de générer un
+environnement d'écriture numérique, initialisé par le BIOS, un _firmware_ flashé
+dans la mémoire morte de la carte mère de l'ordinateur permettant de réaliser un
+certain nombre d'instructions lors de la mise sous tension de l'oridnateur,
+comme par exemple le démarrage du système d'exploitation qui constitue le
+deuxième élément principal du système.
+Le cadre logiciel est relatif à l'ensemble des logiciels que l'on peut exécuter
+dans un système d'exploitation, par exemple un terminal, un navigateur ou un
+traitement de textes.
+Enfin, le dernier cadre est celui du document.
+Le document doit être compris comme un objet, ou une forme déterminée, à
+l'intérieur duquel des éléments sémiotiques sont organisés et structurés
+[@pedauque_document_2006; @zacklad_design_2019].
+
+Ces cadres sont un début de réponse au dépassement de l'écran.
+Néanmoins, plutôt que d'approfondir cette dimension invisible du texte, les
+auteurs de l'architexte reviennent sur la couche graphique en ajoutant qu'« à
+cet enchâssement de cadres, il faudrait encore ajouter ceux que composent, à
+l'intérieur même du document, les rubriques, encadrés, cartouches, "boîtes de
+dialogue" ou autres formes de cadres éditoriaux structurants pour le travail
+même du texte ».
+
+De plus, toujours selon les auteurs :
+
+> Le premier "cadre" [qui] définit les conditions de possibilités matérielles de
+> l'activité, est le seul inanimé. Les trois suivants, cadres système, logiciel
+> et document, relèvent de l'ingénierie textuelle et définissent les conditions
+> de réalisation de l'activité. On voit ainsi qu'une activité d'écriture
+> réalisée sur le "document" d'un logiciel de traitement de texte est mise en
+> abyme au sein de l'ensemble des autres "cadres" qui la rendent possible et la
+> déterminent techniquement et sémiotiquement.
+
+Ce premier cadre de « l'écrit d'écran » ne désigne en fin de compte, pour les
+auteurs, que l'écran.
+Or, il n'est pas nommé cadre écran mais cadre matériel et devrait renvoyer à
+toute la dimension physique d'un ordinateur et pas seulement à l'organe
+d'affichage qui, dans cette disposition, apparaît comme central dans le
+fonctionnement d'un ordinateur.
+
+Le dépassement de l'écran est un acte symbolique nécessaire pour se soustraire à
+une vision anthropocentrée des actions de lecture et d'écriture.
+Pour effectuer ce changement de perspective, nous devons d'abord nous débarasser
+d'un élément central à l'interface de l'humain et la machine : la page.
### La page est un doudou
+Le terme _page_ revient de manières récurrente dans nos usages de l'ordinateur :
+on le retrouve dans les logiciels de traitement de textes -- il y a même un
+logiciel du nom de _Pages_ disponible dans l'environnement Apple --, dans les
+livres numériques ou encore dans le Web où chaque URL est l'adresse d'une page.
+Matthew Kirschenbaum et Thomas Bergin nous détaillent dans leurs travaux
+l'arrivée de la page sur nos écrans durant les années 1970 et le début des
+années 1980 [@kirschenbaum_track_2016; @bergin_origins_2006;
+@bergin_proliferation_2006].
+
+Cet objet qu'est la page a été instauré dans l'ordinateur uniquement pour
+reproduire une « habitude » et créer un lien fictif entre les visions du monde
+de l'imprimerie et de l'informatique.
+Cet artefact produit une forme de réconfort auprès de l'utilisateur pour que le
+monde informatique lui semble plus tangible, qu'il ait quelque chose auquel se
+raccrocher, d'où sa déclinaison dans des espaces différents qui ne ressemblent
+plus du tout à des pages de livres ou de feuilles (comme par exemple A4 lettre
+US, ou le livre au format poche).
+La page affichée à l'écran n'existe qu'à cet endroit, il ne s'agit que d'un
+rendu graphique qui ne fait pas partie de l'écriture (au sens du texte saisi).
+
+Le pouvoir de la page sur l'utilisateur est considérable étant donnée la nature
+même de cet objet que l'on pourrait considérer comme l'un des seuls à être
+virtuel et presque sans matérialité du point de vue de l'informatique.
+Malgré tous les efforts effectués depuis son instauration à l'écran, la page
+affichée n'est jamais la page imprimée car, aussi précis que soient les détails
+typographiques que l'on peut y ajuster, elle ne reflétera jamais le grain,
+l'épaisseur, l'odeur ou tout autre caractéristique physique du papier.
+
+La critique énoncée à l'endroit de la page ne doit pas être réduite à une
+apologie d'un mode sans page.
+Elle consiste à montrer qu'à vouloir préserver une habitude pour _ne pas
+effrayer_ l'utilisateur, la page fait écran devant l'ordinateur, et cache la
+machine qui ne devient plus qu'un simple mécanisme au lieu d'être un agent de
+l'énonciation éditoriale (voir énonciation computationnelle Goyet).
+
+Cette peur de l'informatique pourrait relever essentiellement de l'angoise de
+l'arrachement d'une valeur qui définie l'être humain et devienne une
+caractéristique d'une autre entité, ne permettant plus de définir l'humain en
+regard de ce que lui seul est capable de faire (Vitali-Rosati).
+
+Kittler, à ce propos, nous rappelle qu'historiquement les caractéristiques qui
+définissent l'être humain sont souvent le symbole du pouvoir et désigne plutôt
+les hommes alors qu'à l'instant même où cette caractéristique est déchue de son
+statut de marqueur de puissance, ce sont les femmes qui en héritent.
+Dans le cas de l'écriture -- dactylographie et sténographie--, elles en
+deviennent les expertes dès 1881, au moment même où les ventes de la machine à
+écrire Remington II explosent alors que chute le pourcentage d'hommes dans ce
+domaine [@kittler_gramophone_2018, p.306].
+La Remington Model II de 1878 comporte une particularité, il s'agit de la
+première machine à écrire comportant une touche SHIFT pour avoir les hauts de
+casse et les bas de casse sur le même clavier, pourtant, malgré cette nouvelle
+fonctionnalité, les ventes ne se développèrent pas dès cette date.
+En 1881, l'entreprise modifie sa stratégie de vente et cible les femmes qui
+n'ont pas de travail.
+En parallèle, l'Association chrétienne de jeunes femmes de New York commence à
+former des jeunes femmes à la dactylographie, fait qui a été ensuite reproduit
+en Europe du à son succès [@kittler_gramophone_2018, p.322].
+Il y aurait donc une peur de perdre non seulement une caractéristique de
+l'humanité mais surtout une caractéristique de la masculinité.
+
+Néanmoins, avant d'en arriver à cette émotion forte qu'est la peur et qui
+traduit une incapacité à définir l'être humain, nous pouvons nous appuyer sur la
+pensée de Gunther Anders et convoquer une forme de honte
+[@anders_obsolescence_2002] que la page camoufle.
+
+Interagir avec une machine demande une certaine rigueur : qu'il s'agisse de
+structurer un document ou de lui donner une série d'instructions (du code), une
+machine ne peut interpréter l'ambiguité ou l'implicite culturel.
+Cela voudrait dire qu'aucun échange humain-ordinateur ne peut reposer sur des
+conventions culturelles de lecture et que l'instruction données n'a, en
+elle-même, aucun sens.
+Dès lors, comment pouvons-nous admettre que quelque chose qui n'a pas de sens
+puisse en générer ?
+
+La honte (prométhéenne) d'Anders est alors double : d'un côté il y a un mélange
+de fierté devant cette machine créée par l'être humain et de honte parce que
+l'individu isolé devant la machine sait que ce n'est pas lui qui l'a mise au
+point et, de l'autre, il y a cette honte à être face à un outil qui réalise une
+action mieux qu'on ne le ferait soi-même alors que cette dite machine n'a aucune
+conscience de ce qu'elle réalise.
+
+Le dépassement de la page et de l'écran est une proposition pour poser un autre
+regard non anthrocopentré sur cette question de l'écriture numérique et laisser
+de côté les modalités de définition de l'être humain.
+Elle signifie qu'il ne s'agit plus de poser la question de l'auteur de
+l'écriture, en admettant que c'est bien la machine qui écrit, mais de se
+demander comment comment cette nouvelle fonction (inter)agit entre les agents
+d'un système d'informations.
+Que se passe-t-il lorsque cet ordinateur devient un agent actif qui écrit et
+transmet des informations entre, d'une part, l'instructeur (la personne qui
+donne des instructions) et la ou les personnes qui lisent les productions issues
+du traitement de ces instructions (les productions écrites) ?
+Dans cette configuration s'opère alors un changement radical de l'état de
+l'ordinateur.
+D'abord à l'état de médiateur puis de support de l'écriture, l'ordinateur passe
+maintenant au statut d'entité agissante au sein d'un système d'informations.
+
### Le logiciel est une médiation
+Traverser la page pour atteindre les couches inférieures nous amène à faire escale
+sur la couche logicielle.
+Le logiciel a un statut intéressant : on le considère souvent comme un
+médiateur, un agent qui permet la communication et l'interaction humain-machine,
+pourtant ce n'est pas le cas de toutes les recherches.
+F. Kittler et sa très célèbre provocation « Es gibt keine Software », traduit
+par _Le logiciel n'existe pas_ [-@kittler_mode_2015], nous rappelle que ces
+écritures (qui nous permettent d'écrire), sont stockées et traitées par la
+machine exactement de la même façon que n'importe quelle écriture numérique.
+
+On retrouve tous ces textes numériques (logiciels et documents) au même niveau
+hiérarchique dans l'architecture du système d'exploitation et le traitement qui
+leur est appliqué par le processeur est identique.
+La nomination des logiciels en tant qu'« écrits qui permettent les écrits
+d'écran » par E. Souchier nous mène aussi à cette juxtaposition : finalement le
+logiciel est de même nature que le texte que nous y rédigeons à l'intérieur.
+
+Toutefois, une distinction persiste.
+Si le texte peut être remédié dans un autre format -- et être imprimé par
+exemple --, le logiciel quant à lui ne peut exister que dans son environnement
+numérique.
+Son code source peut lui aussi faire l'objet d'une remédiation
+[@bolter_remediation_1998] mais il sera dénaturé car sa fonction principale est
+l'organisation du traitement des informations dans un ordinateur.
+D'ailleurs, C. Herrenschmidt nous rappelle que le terme de logiciel a été forgé
+à partir de la contraction du mot "logique" avec le mot "matériel"
+[@herrenschmidt_les_2023, p.474] , pour justement montrer à la fois l'opposition
+du logiciel avec l'aspect matériel (_hardware_) et marquer leur
+complémentarité : l'ordinateur (_hardware_) serait très peu accessible (voir
+inaccessible) sans logiciel, et le logiciel n'existe pas en dehors de
+l'ordinateur.
+
+Lorsque l'on définit le logiciel en opposition au matériel, on les place tous
+les deux au même niveau -- ils sont des entités équivalentes -- et cela nous
+détache de ce que nous avons vu précédemment sur la place du logiciel aux côtés
+de n'importe quel document à l'intérieur de la mémoire de l'ordinateur.
+
+Un courant contemporain de la théorie des médias, l'intermédialité
+montréalaise^[Le chapitre 1 devra décrire l'intermédialité
+montréalaise, il faudra ajouter un renvoi ici] [@muller_lintermedialite_2000;
+@tadier_tentative_2021; @tadier__2021], en tant qu'art pour penser les relations
+[@tadier__2021], peut être mobilisée pour mieux comprendre les liens
+entretenues par les agents de notre système, la machine avec elle-même,
+humain-machine, machine-machine.
+
+Ce qui est intéressant dans cette relation -- et que certains systèmes
+d'exploitation cachent depuis plusieurs années -- est le fait que logiciel ne
+puisse exister que dans un environnement très particulier et fragile.
+Pour fonctionner, le logiciel doit être compatible avec plusieurs composants de
+l'ordinateur. Les premiers composants sont matériels : est-ce que l'ordinateur a
+une carte graphique, quel type de processeur ou la quantité de mémoire vive,
+etc.
+C'était un fait connu du temps des premiers logiciels comme WordPerfect
+[@bergin_origins_2006; @kirschenbaum_track_2016; @kittler_mode_2015] et que l'on
+voit de moins en moins aujourd'hui, notamment parce que 1) les logiciels à
+installer sont disponibles pour beaucoup de matériels -- exceptés pour certains
+jeux vidéos ou des programmes que l'on va préférer faire fonctionner sur des
+"machines plus puissantes" comme des réseaux de neurones -- et 2) parce que le
+développement des téléphones intelligents depuis une vingtaine d'années a donné
+naissance à un nouveau format d'application : les _progressive web apps_ qui
+utilisent les technologies du web (HTML, CSS, JS) pour fonctionner et sont donc
+exécutables sur plus de supports puisqu'elles sont agnostiques^[En informatique,
+le qualificatif agnostique désigne une ressource indépendante du système au sein
+duquel elle se trouve. Par exemple, un logiciel agnostique fonctionnerait de la
+même manière sous différents systèmes d’exploitation. Il en gagne ainsi la
+propriété d’interopérabilité.] vis-à-vis du système d'exploitation.
+L'environnement matériel est donc une première condition pour faire fonctionner
+un logiciel.
+La deuxième est le système d'exploitation.
+En fonction du système d'exploitation -- et de sa version -- un logiciel pourra
+y être installé à l'intérieur.
+Ce deuxième paramètre ne doit pas être sous-estimé car l'écosystème des
+logiciels fonctionne sur la base d'un système réticulaire : les programmes ne
+sont pas développées _from scratch_, ils s'appuient sur d'autres briques
+logicielles qui elles-mêmes s'appuient sur d'autres briques logicielles. Chacune
+d'entre elles dépend d'une version particulière de l'autre. Si une version
+venait a être mise à jour sans vérification préalable, alors le château de
+cartes pourrait s'effondrer et le logiciel ne plus fonctionner.
+
+D'ailleurs, une pratique courante en développement informatique consiste à créer
+un environnement virtuel -- une bulle -- à l'intérieur même de son ordinateur
+pour y installer des versions sélectionnées de dépendances logicielles afin
+qu'elles ne soient pas victime d'un effet de bord dû à une mise à jour d'un
+autre programme (et d'autre dépendances).
+
+Le logiciel est un langage de haut niveau qui permet de manipuler des données
+jusqu'au plus bas niveau de l'ordinateur, au niveau des entrées et des sorties.
+Toutes ces manipulations sont exécutées en appelant des instructions dans ce
+réseau de dépendances/logiciels pour que les données puissent descendre les
+couches et être transformées jusqu'à atteindre leur espace de stockage dans la
+mémoire morte.
+
+Le nom qui désigne un logiciel comme MS Word, Stylo ou LibreOffice désignent
+plus que les vagues notions que peuvent être leur fonctionnalité principale,
+dans ces cas-ci l'édition de texte, et peuvent être définis par la totalité des
+instructions mobilisées dans la manipulation des informations.
+À l'instar de McLuhan [-@mcluhan_pour_1977], l'on pourrait percevoir les
+logiciels comme des espaces construits -- des architectures de l'information
+[@broudoux_larchitecture_2013] soignées -- avec une topologie qui leur est
+propre et à travers laquelle chaque suite d'instructions forme une route que des
+unités sémiotiques empruntent pour y être transformées en unités calculables.
+
+Chaque environnement d'écriture incarne un modèle et une vision du traitement de
+l'information, que l'on peut englober sous le nom de cet environnement.
+Lors de l'interaction entre un usager et une machine, par le biais de cet
+environnement, les médiations à l'oeuvre sont des représentations de ce modèle
+dont les traces présentes dans les documents sont les indices.
+
+En prenant le cas de Stylo, nous pouvons détailler ce que nom désigne en
+fouillant l'architecture logicielle, puisque le code est en libre accès, afin de
+cibler les traces de cette relation entre l'auteur et son environnement.
+
+Tout d'abord, Stylo représente un espace sur le Web dans lequel nous pouvons
+écrire en suivant la syntaxe de trois formats de texte brut, le Markdown, le
+YAML et le BibTeX.
+Cet espace est à distinguer d'un environnement local puisqu'il s'agit du Web,
+un espace régit par ses propres règles.
+
+[Faire l'historique du Web en deux phrases, citer les spec du W3C et de HTML
+jusqu'à HTML5]
+
+Sur le Web, les données sont généralement séparées de l'espace d'affichage et
+sont stockées sur un serveur, dans une base de données.
+Il y aurait donc au moins deux modules différents, la partie _client_ -- ce qui
+est affiché dans le navigateur -- et la partie _serveur_, soit la base de données.
+Dans notre cas, nous allons scinder l' architecture logicielle de Stylo en trois
+parties.
+
+![Les différents modules de Stylo](https://s3.hedgedoc.org/demo/uploads/afdf01ec-bd0b-4b38-8394-752d6e2d1e4b.png "Les différents modules de Stylo")
+
+Tout d'abord, nous retrouvons la base de données où sont stockées toutes les
+informations et données de Stylo : les comptes utilisateurs, les articles, les
+espaces de travail, les corpus, etc.
+Cette base de données est réalisée avec MongoDB, un système de gestion de base
+de données non relationnelles développé en 2007 et s'appuyant sur des documents
+structurés en JSON.
+
+Le deuxième bloc de Stylo est le module d'export qui permet de transformer les
+informations saisies et visibles dans l'éditeur en de multiples documents.
+Tout ce module est développé et maintenu avec le langage de programmation Python
+par David Larlet.
+Cette brique technologique est articulée autour du logiciel de transformation et
+de conversion Pandoc^[Pandoc est un incontournable pour transformer des
+documents. Il a été développé et maintenu en Haskell par son créateur John
+MacFarlane depuis 2006.] déployée sur un serveur et rendue accessible via une
+autre API^[La pandoc-api est accessible à cet _endpoint_ :
+https://pandoc-api.stylo.huma-num.fr/] fabriquée à partir du framework
+FastAPI^[FastAPI est disponible à cette adresse : https://fastapi.tiangolo.com/,
+consulté le 24 février 2024.].
+Le module d'export intégré à Stylo^[On peut trouver le module d'export à cette
+URL : https://export.stylo.huma-num.fr/] permet de convertir et de transformer
+les textes sources en une multitude d'artefacts, selon les capacités de
+transformation et de conversion du logiciel Pandoc auquel il est rattaché.
+
+Le dernier bloc de Stylo concerne l'interface que les utilisateurs voient
+affichée sur leur écran.
+Étant donné que Stylo est accessible via un navigateur web, l'interface a été
+conçue avec les technologies de cet environnement.
+On retrouve des objets en HTML, en CSS et en Javascript.
+Le _framework_ React, une surcouche à Javascript _open source_ développée par
+Facebook (aujourd'hui Meta) en 2013, a été employé pour faire les différents
+composants de l'interface et intégrer de nombreuses librairies telle que _i18n_
+qui permet d'implémenter le multilinguisme dans l'interface et changer la langue
+affichée à l'écran en un seul clic.
+
+L'éditeur de texte, pièce maîtresse de Stylo, s'appuie sur la technologie
+Monaco^[Voir le site web dédié à l'éditeur Monaco :
+https://microsoft.github.io/monaco-editor/, consulté le 29 février 2024.]
+développé par Microsoft et rendu disponible sous licence MIT.
+
+Ces deux blocs, la base de données MongoDB et l'interface web, ne sont
+pas en communication directe.
+Les champs de texte dans la partie HTML ne permettent pas d'écrire directement
+dans la base de données.
+En conséquence, un canal de communication devait être établi entre ces deux
+objets pour que les données puissent être accessibles à la fois en lecture, pour
+l'affichage dans la page web, et en écriture pour ajouter, modifier ou supprimer
+des éléments.
+Pour mettre en oeuvre cette communication, une API (_Application Programming
+Interface_) utilisant le langage de requête GraphQL a été mise en place et
+rendue accessible via le protocole HTTP (_Hypertext Transfert
+Protocol_)^[L'_endpoint_ de l'API GraphQL de Stylo est accessible ici :
+https://stylo.huma-num.fr/graphql.], la surcouche du protocole internet utilisée
+pour le web.
+Le langage de requête et de manipulation des données GraphQL a également été
+développé par Facebook à partir de 2012 puis publié en _open source_ en 2015.
+
+L'une des particularités d'une API GraphQL, contrairement à une API REST par
+exemple, est quelle sert l'ensemble des données à une seule adresse (_endpoint_)
+alors que plus généralement, les données sont accessibles à des URL très
+précises, ce qui a pour effet de rendre explicite la structuration des données
+dans la base.
+En ne servant les données qu'à une seule adresse, l'API s'échappe de la
+contrainte de la structuration des données et contourne les problèmes récurrents
+d'_over-fetching_ ou d'_under-fetching_ que l'on peut rencontrer dans certaines
+applications^[Ces deux problèmes désignent soit une récupération trop importante
+de données et nécessite un tri après récupération des données sur le serveur,
+soit un manque de données pallié par un deuxième appel ou plus au serveur pour
+compléter le besoin.]
+L'API GraphQL est donc agnostique à l'égard de la forme de la base de données.
+Par contre, la définition de requêtes adressables à la base de données doit être
+déclarée pour que l'on puisse faire circuler les informations entre le serveur
+et le client.
+Pour effectuer cela, GraphQL à son propre langage de description de schéma (SDL,
+_Schema Definition Language_) et permet de déclarer explicitement les
+différentes façons d'écrire une requête.
+
+Par exemple dans Stylo, le champ `user` contient les informations suivantes^[La
+modélisation du schéma GraphQL de Stylo est accessible sur le dépôt Github à
+l'adresse
+suivante :https://github.com/EcrituresNumeriques/stylo/blob/master/graphql/models/user.js] :
+
+- _id
+- displayName
+- username
+- authType
+- email
+- firstName
+- lastName
+- institution
+- tags
+- permissions
+- acquintances
+- articles
+- workspaces
+- admin
+- yaml
+- zoteroToken
+- createdAt
+- updateAt
+- apiToken
+- addContact
+- removeContact
+- stats
+
+Une requête simple consisterait à vouloir récupérer l'adresse courriel liée à
+mon compte utilisateur: 
+
+```graphql
+query usermail {
+ user {
+ email
+ }
+}
+```
+
+et renverrait comme réponse :
+
+```graphql
+{
+ "data": {
+ "user": {
+ "email": "roch.delannay@umontreal.ca"
+ }
+ }
+}
+```
+
+Cet exemple montre qu'il y a une certaine économie de l'information implémentée
+dans le fonctionnement même de GraphQL pour n'aller chercher que les
+informations nécessaires pour une requête particulière, pour peu que la requête
+en elle-même soit bien rédigée.
+D'ailleurs, il s'agit là d'un des écueils potentiels de GraphQL : des requêtes
+mal formulées peuvent aller à l'encontre de ce principe.
+
+Dans Stylo, chaque fonctionnalité, chaque bouton (ou presque) qui réalise une
+action de lecture ou d'écriture est lié à une requête GraphQL.
+Le protocole HTTP comporte deux méthodes bien connues pour faire circuler des
+informations entre un client et un serveur : `GET` et `POST`.
+Un des arguments phares présenté par GraphQL est sa dimension agnostique par
+rapport au protocole de communication des informations employé, que ce soit HTTP
+ou des WebSockets ou autre.
+Pourtant, malgré la capacité de GraphQL à être utilisable avec toutes les
+méthodes d'HTTP^[Voir https://graphql.or/learn/serving-over-http/, consulté le
+24 février 2024.], une bonne pratique appliquée par la communauté GraphQL est
+l'emploi du protocole HTTP couplé à la méthode `POST` pour tous types de
+requêtes (que ce soit une `query`, une `mutation` ou encore une `subscription`).
+Lors de la transmission des informations par la méthode `GET`, toutes les
+informations sont insérées dans l'URL ce qui 1) les rend visibles (et
+vulnérables) et 2) impose une limite du nombre de caractères (aux alentours de
+2000 au maximum) au risque de déclencher une erreur 414 (URL trop longue).
+En conséquence, il est préférable d'utiliser la méthode `POST` pour envoyer ou
+récupérer des informations car elles ne seront ni visibles ni limitées en
+longueur.
+Malgré l'aspect agnostique de GraphQL, la forme textuelle des requêtes implique
+en elle-même un choix particulier de transmission des informations avec ce qu'il
+comporte comme avantages et inconvénients.
+
+Les spécificités du protocoles HTTP sont définies dans les _Request for
+Comments_ (RFC) publiés par l'_Internet Engineering Task Force_ (IETF) fondée en
+1986 et dont le siège se trouve aux États-Unis.
+Les documents et leurs contenus sont régulièrements mis à jour par la communauté
+qui participe à ces commentaires.
+Le numéro de la RFC en lien avec la méthode `POST` est le 9110^[Voir la page web
+https://www.rfc-editor.org/rfc/rfc9110#name-introduction, consultée le 24
+février 2024.] publié en juin 2022.
+
+La méthode `POST` est définie dans le paragraphe 9.3.3 comme :
+
+> The POST method requests that the target resource process the representation
+> enclosed in the request according to the resource's own specific semantics.
+> For example, POST is used for the following functions (among others) :
+> - Providing a block of data, such as the fields entered into an HTML form, to
+> a data-handling process;
+> - Posting a message to a bulletin board, newsgroup, mailing list, blog, or
+> similar group of articles;
+> - Creating a new resource that has yet to be identified by the origin server;
+> and
+> - Appending data to a resource's existing representation(s).^[Traduction
+> personnelle : La méthode POST demande à la ressource cible de traiter la
+> représentation incluse dans la demande selon sa propre sémantique. Par
+> exemple, la méthode POST est utilisée pour les usages suivants (parmi
+> d'autres) : Fournir les blocs de données, comme les champs d'un formulaire
+> HTML, à un traitement de données ; Publier un message sur un tableau
+> d'affichage, un groupe d'échange, une liste de diffusion, un blog ou un
+> groupe d'articles similaire ; Créer une nouvelle ressource qui n'a pas
+> encore été identifiée par le serveur d'origine ; et Ajouter des données à la
+> (aux) représentation(s) existante(s) d'une ressource.]
+
+À travers cette brève définition, l'on remarque que l'usage principal de la
+méthode `POST` est plutôt relatif à l'envoi d'informations, qu'elles soient
+nouvelles ou mises à jour.
+Le comportement de `POST` fait toutefois débat, notamment quant à son usage pour
+l'envoi de certaines informations puisque, comme cela est indiqué dans sa
+définition, `POST` laisse le soin au serveur (la ressource cible) de traiter les
+données contenus dans son message selon sa propre sémantique.
+En somme, contrairement à d'autres méthodes comme `PUT`, `POST` n'est pas
+indempotente, ce qui pourrait entraîner des différences de résultat lors de
+l'exécution d'une requête. Par exemple, la duplication d'une requête en cas de
+problème de connexion.
+
+Cependant, cette caractéristique tend à disparaître dans le cas de l'utilisation
+de `POST` avec une structure GraphQL puisque cette dernière ne dépend pas d'une
+architecture composée de multiples adresses (une pour chaque ressource) mais
+d'une seule adresse à laquelle on soumet des requêtes.
+Dans le cas de Stylo, `POST` est donc soumis à l'architecture GraphQL, on peut
+donc bien considérer GraphQL agnostique à l'égard de la méthode `POST` du
+protocole HTTP.
+
+Enfin, dans le cas d'une requête `POST`, le contenu à envoyer sur le serveur est
+formaté en JSON.
+Ci-dessous un exemple de requête `POST` envoyée depuis l'interface Web de Stylo
+vers le serveur :
+
+```JSON
+{"query":"query updateWorkingVersion(articleId: ID!, $content:
+WorkingVersionInput!)
+{\n
+article(article: $articleId) {\n
+updateWorkingVersion(content: $content) {\n
+updatedAT\n
+}\n
+}\n
+}",
+"variables":{"userId":"61d62.....",
+"articleId":"65e0e38129637c0012ef7a",
+"content":{"md":"Ajout du texte pour la requête HTTP 'POST'"}}}
+```
+
+Autrement dit, chaque fonctionnalité décrit de manière formelle la structuration
+des informations dans Stylo, donc ce que Stylo écrit dans la base données et
+dans les textes puisque ce sont les informations renseignées qui seront
+intégrées dans les documents exportés.
+En ce sens, Stylo et ses protocoles pré-construisent la totalité de ce qu'un
+utilisateur peut saisir dans l'interface et sera enregistré dans la base de
+données.
+Puisqu'il y a une pré-construction du document et du texte, nous pouvons à ce
+stade présupposé qu'il y a une pré-construction des traces des interactions avec
+l'utilisateur et de l'intimité qui en résulte.
+Cette préconstruction est la vision du document incarnée dans Stylo.
+
+Une description très générale des moyens de communication à l'oeuvre entre les
+différents modules de Stylo nous montre déjà que l'information saisie dans cet
+éditeur de texte est formatée par une architecture de données alors que nous
+n'avons pas encore abordé les conditions de l'écriture avec les trois formats
+pivots d'un document dans Stylo.
+
### Les formats déterminent la sémantique du texte
+Selon les formats d'écriture, et lorsque l'on sort du paradigme WYSIWYG pour
+celui du WYSIWYM, on s'émancipe de la surcouche de mise en page pour entrer
+directement dans la couche de la structuration des contenus, là où les formats
+remplacent la couche supprimée par une autre couche graphique et rendent leur
+structure visible.
+
+_What You See Is What You Get_, ou WYSIWYG, est l'acronyme généralement employé
+pour désigner les outils qui adoptent une surcouche graphique de gestion de la
+mise en page des contenus d'un document, au risque de ne pas structurer les
+informations qu'il contient avec finesse.
+Le paradigme opposé, _What You See Is What You Mean_ (WYSIWYM), distingue la
+mise en page graphique des éléments du texte de leur structuration.
+Les formats employés sont généralement du texte brut et permettent dans la
+plupart des cas de baliser le contenu pour définir la nature des éléments à
+décrire.
+C'est le cas, par exemple, de tous les langages de balisages hérités de SGML
+(_Standard Generalized Markup Language_) tels que HTML ou XML mais également les
+langages de balisage léger comme Markdown, AsciiDoc, reStructuredText, etc.
+
+À ce stade, l'agent humain ne dépend pas d'un logiciel particulier pour saisir
+son texte puisque la saisie d'un texte dans un format _plain text_ peut l'être dans
+n'importe quel environnement.
+Écrire en texte brut signifie également ouvrir les possibilités de structuration
+du texte : ce n'est plus un logiciel de traitement de texte, MSWord, GoogleDoc
+ou LibreOffice qui décide de l'organisation des connaissances à l'intérieur du
+document, suivant un phénomène de documentarisation [@zacklad_design_2019], mais
+le choix d'un format ou d'une saveur particulière d'un format : le
+positionnement de l'autorité est alors déplacé vers un niveau plus bas.
+
+L'encodage d'un texte en XML illustre bien ce propos.
+XML, pour _eXtensible Markup Language_, est à la fois un format de modélisation
+du texte et un métalangage qui définit ses propres règles.
+Plus souple que le HTML dont les balises sont figées, XML permet à chaque
+utilisateur de créer son propre système hiérarchique arborescent par
+l'élaboration de balises personnalisées.
+Postérieur d'une décennie au format HTML, la publication des recommandations de
+la première version (1.0) du métalangage XML voit le jour en 1998.
+
+La souplesse mentionnée précédemment n'empêche pas une rigueur extrême dans la
+structuration des contenus : chaque document formaté en XML doit, pour être
+valide, être conforme à un schéma dont la fonction est de définir des règles de
+structuration des informations documentées.
+Ce fonctionnement rend XML interopérable entre différents systèmes
+d'informations et chaque document XML devient transformable en un autre document
+XML.
+
+Que l'on soit sous système d'exploitation Linux, MacOS ou Windows, le XML peut
+être saisi et lu dans tous les éditeurs de texte.
+Chacun est en capacité de créer ses propres régles d'agencement des contenus en
+créant un schéma qui correspond aux besoins d'une chaîne éditoriale.
+
+Par exemple, lors de l'édition d'un article scientifique, comment pouvons-nous
+définir un auteur ?
+
+Si l'on écrit la chaîne de caractère "Rémi Dupont" à la fin du texte, nous
+pouvons, par convention de lecture, deviner que "Rémi" est le prénom de l'auteur
+et "Dupont" son nom.
+Or, pour l'ordinateur, cette chaîne de caractère n'est rien d'autre qu'une série
+de caractères qui n'a aucune valeur sémantique particulière, hormis peut-être
+qu'il s'agit d'un paragraphe.
+
+Si l'on saisit cette même chaîne de caractères en XML, on peut ajouter une
+baliser `<auteur>Rémi Dupont</auteur>` pour signifier explicitement qu'il s'agit
+de l'auteur du texte.
+
+Il est également possible de préciser encore plus cette notion d'auteur en y
+ajoutant par exemple des balises `<prénom>` et `<nom>` à l'intérieur de la
+balise `<auteur>`.
+La description de ce qu'est un auteur, pour l'écriture de cet exemple, devient
+formelle et explicite.
+Cependant, pour l'écriture savante, est-ce qu'un auteur est seulement un nom et
+un prénom ?
+En fonction des contextes de publication, il est possible qu'un autre agent, la
+revue, définisse également la notion d'auteur avec d'autres informations telles
+que l'affiliation académique, une adresse courriel et un identifiant unique
+comme l'ORCID.
+Rémi Dupont prendrait alors la forme suivante :
+
+```xml
+<auteur>
+ <nom>Dupont</nom>
+ <prenom>Rémi</prenom>
+ <courriel>remi.dupont@universite.fr</courriel>
+ <affiliation>Université X ou Y</affiliation>
+ <orcid>XXXXXXXXX</orcid>
+</auteur>
+```
+Le format XML est un exemple très explicite.
+La sémantique du texte y est structurée selon deux dimensions, à la fois en
+termes de structuration verticale des informations mais aussi dans la saisie des
+noms des balises qui, en général, renvoient à des éléments lisibles et
+compréhensibles, ce qui n'est pas le cas de tous les formats -- au prix d'un
+balisage dit plus verbeux et parfois lourds dans le texte.
+D'autres langages de balisage, notamment ceux qualifiés de légers comme le
+Markdown, emploient des symboles tels que `=` ou `#` pour structurer les
+informations à l'intérieur d'un document.
+Contrairement à ce que nous avons vu avec le XML, la signification des éléments
+structurants n'est pas forcément explicite pour une lecture humaine, même si
+l'on peut la deviner ou l'apprendre.
+
+Le terme format est avant tout un terme technique, il délimite les
+caractéristiques d'un objet.
+Ces caractéristiques sont formulées par un certain nombres de données,
+d'instructions, ou de règles.
+L'objectif est de disposer d'un consensus pour dialoguer autour d'un objet ou de
+faire communiquer des processus qui traîtent ou qui produisent des formats.
+
+Le format est une contrainte technique dans des environnements qui peuvent être
+très divers : formats d'objets physiques comme le papier, formats informatiques
+que nous connaissons par l'extension des fichiers sur nos ordinateurs, ou
+formats littéraires concernant l'agencement des mots et des phrases.
+Nous nous concentrons ici sur les formats informatiques.
+En fonction des nécessités d'un système d'exploitation, d'un programme
+informatique ou d'une plateforme en ligne, un format caractéristique sera
+requis.
+Un format qui n'est pas standard (ces caractéristiques doivent être décrites),
+qui n'est pas ouvert (il est possible de comprendre comment le format
+fonctionne) ou qui nécessite un environnement très spécifique pour être
+interprété ou transformé va générer beaucoup d'obstacles pour son utilisation.
+
+La contrainte du format est liée à d'autres contraintes comme la compatibilité
+(quel format peut être lu par quel programme ou logiciel ?), l'interopérabilité
+(est-ce que le format peut être utilisé de la même façon quel que soit
+l'environnement ?), la dépendance (de quoi un système a-t-il besoin pour traiter
+le format ?) et les droits associées (est-ce que le format peut être lu, modifié
+ou partagé ?).
+
+Si le but du format est de constituer une série d'informations compréhensibles,
+utilisables et communicables, il reste une contrainte forte pour les chaînes de
+publication.
+Que ce soit en tant que format d'entrée, format pivot de transformation ou
+format de publication -- nous reviendrons sur les transformations et les
+artefacts publiables dans le chapitre 4 --, il déterminera le
+fonctionnement de la chaîne.
+
+Comme nous l'avons déjà mentionné, il y a trois formats centraux dans l'éditeur
+de texte Stylo : le Markdown pour le corps du texte, le YAML pour les
+métadonnées et le BibTeX pour les références bibliographiques.
+Chacun de ces formats a sa propre histoire et ses propres spécifications.
+Afin de mieux comprendre la structuration des informations dans Stylo, nous
+allons passer en revue certaines des particularités de ces formats et de leur
+implémentation dans l'éditeur.
+
+Mardown est un langage de balisage léger créé en 2004 par John Gruber^[Voir son
+site web, consulté le 31 mars 2024 :
+https://daringfireball.net/projects/markdown/]. Sa syntaxe, beaucoup plus légère
+et moins verbeuse que le HTML dont il est issu, permet de structurer et de
+décrire sémantiquement le texte. Il a été pensé pour pouvoir être converti
+facilement vers d’autres formats comme HTML, LaTeX ou PDF. Markdown se distingue
+des autres langages de balisages légers car il est déclinable en différentes
+variantes (ou saveurs). Chacune d’entre elles ajoute une particularité dans la
+syntaxe Markdown. Parmi les plus populaires, on retrouve :
+
+- CommonMark^[Les spécificités de CommonMark sont disponibles sur le site web
+ dédié à cette saveur : https://commonmark.org/, consulté le 31 mars 2024.]
+- GitHub Flavored Markdown (GFM)^[Celles de GFM sont disponibles sur cette page
+ web : https://github.github.com/gfm/, consultée le 31 mars 2024.]
+- MultiMarkdown^[Celles de MultiMarkdown sont disponibles sur cette page web :
+ https://rawgit.com/fletcher/MultiMarkdown-6-Syntax-Guide/master/index.html,
+cinsultée le 31 mars 2024.]
+- Pandoc^[Celles de Pandoc sont disponibles sur cette page web :
+ https://pandoc.org/MANUAL.html#pandocs-markdown, consultée le 31 mars 2024.]
+- Quarto^[Celles de Quarto sont disponibles sur cette page web :
+ https://quarto.org/docs/authoring/markdown-basics.html, consultée le 31 mars
+2024.]
+
+Cette propriété à être déclinable et adaptable distingue fortement Markdown des
+autres langages de balisage.
+En effet, puisque chaque saveur contient des éléments personnalisés de
+structuration des contenus -- des balises --, il est important de connaître la
+saveur que l'on doit utiliser dans un environnement au risque de se retrouver
+avec des balises qui ne sont pas interprétées.
+
+Par exemple, la saveur Quarto Markdown utilise la structure ci-dessous pour
+insérer une vidéo dans un texte.
+Cependant, ce marquage ne sera interprété que lorsque Quarto transformera le
+document Markdown en un autre document, or dans Stylo cette ligne sera traitée
+comme un paragraphe et ne sera pas transformée parce que Stylo ne connaît pas
+cette structure puisque la saveur Quarto de Markdown n'y est pas prise en
+charge.
+
+```md
+{{< video https://www.youtube.com/embed/wo9vZccmqwc >}}
+```
+
+À ce propos, aucune saveur spécifique n'a été implémentée dans Stylo pour
+laisser le champ libre aux utilisateurs d'employer celle qui leur convient le
+mieux.
+Néanmoins, lorsque les sources sont transformées par le module d'export
+(l'export des sources n'est pas concerné), les utilisateurs doivent respecter
+les préconisations données par Pandoc puisque c'est ce dernier logiciel qui
+réalise les transformations et conversions. Les saveurs les plus couramment
+utilisées avec Pandoc sont CommonMark et GitHub Flavored Markdown^[Outre celle
+qui porte son nom, Pandoc prend en charge d'autres variantes de Markdown comme
+cela est indiqué dans la documentation à ce sujet :
+https://pandoc.org/MANUAL.html#markdown-variants.].
+
+Autrement dit, Stylo n'impose pas de variante de Markdown si l'on s'en sert
+comme éditeur de texte sans la nécessité d'utiliser le module d'export.
+Dès qu'une chaîne éditoriale s'appuie sur ce module, comme c'est le cas pour la
+chaîne Stylo, Métopes, OpenEdition, il devient essentiel d'employer les
+variantes que traitent Pandoc pour que les transformations et conversions se
+fassent sans erreur.
+Pour conclure sur le langage de balisage Markdown, sa possible déclinaison en
+diverses saveurs fait de ce langage un avantage et un inconvénient.
+C'est un avantage pour sa plasticité et son adaptibilité aux besoins d'une
+communauté ou d'un projet.
+Cependant, si les adaptations réalisées le sont dans une niche, soit parce que
+la communauté qui en définit les règles comporte trop de peu de membres, soit
+parce qu'il n'y a qu'un seul environnement qui traite cette saveur, le Markdown
+perd sa caractéristique interopérable et contraint les usagers à bricoler des
+équivalences entre les transformations pour préserver la structuration des
+contenus.
+
+La sérialisation des métadonnées est réalisée en YAML qui, dans sa version
+originale de 2004 est l’acronyme de _Yet Another Markup Language_ puis se
+transforme à l’occasion de la publication de sa version 1.1 en _YAML Ain’t
+Markup Language_. YAML est un langage de sérialisation de données pour tous les
+langage de programmation. Un usage récurrent qui en est fait consiste à utiliser
+YAML pour créer des fichiers de configuration. Dans le cas des outils liés à
+l’édition numérique, YAML sera utilisé pour enregistrer les métadonnées
+associées à un document.
+Le principe de YAML est très facile à assimiler puisqu'il repose sur le même
+fonctionnement qu'un dictionnaire avec la structure `clef: valeur`.
+Chaque utilisateur a la possibilité de créer de toute pièce son document YAML et
+de choisir les `clefs` et les `valeurs` qui leur sont associées.
+C'est ensuite l'application qui va parser le contenu en suivant l'architecture
+des informations.
+Dans Stylo, les `clefs` ont été prédéterminées lors des développements de
+l'interface et les utilisateurs n'ont plus qu'à remplir un formulaire pour
+déclarer les `valeurs` qui seront associées aux différentes `clefs` -- un mode
+permet d'accéder au contenu en YAML brut sans surcouche graphique.
+
+Si nous reprenons l'exemple de l'auteur mentionné précédemment, un auteur est
+déclaré comme suit dans Stylo :
+
+```yaml
+authors:
+ - affiliations: ''
+ biography: ''
+ email: ''
+ foaf: ''
+ forename: ''
+ isni: ''
+ orcid: ''
+ surname: ''
+ viaf: ''
+ wikidata: ''
+```
+
+Les métadonnées sélectionnées pour représenter l'auteur dans Stylo reflète
+principalement les besoins émis par les revues, par exemple Sens Public ou
+Humanités Numériques, ou les plateformes de diffusion telles qu'Érudit et
+OpenEdition.
+Dans Stylo, un auteur est donc représenté uniquement par ces informations.
+Néanmoins, il arrive que certains utilisateurs ou institutions requièrent
+d'autres informations pour décrire plus précisément un auteur et nécessite des
+adaptations.
+Par exemple, la clef YAML `affiliations` désigne sans distinction l'institution,
+le laboratoire ou encore le département de rattachement.
+Pourtant, selon les revues, il peut être important de faire formellement cette
+différence.
+
+Au-delà de Stylo, l'utilisation de YAML est toutefois controversée.
+Contrairement à d'autres langages de structuration de données dont le
+comportement est pérenne, comme le standard JSON (_JavaScript Object Notation_)
+publié pour la première fois en 1999^[Voir le site web de JSON :
+https://www.json.org/json-en.html, consulté le 31 mars 2024.], YAML 1.0 subit
+des modifications régulières depuis 2004 avec une version 1.1 en 2005 puis une
+version 1.2 en 2009 et une dernière mise à jour en 2021 avec la version 1.2.2.
+Là où une certaine stabilité que l'on trouve dans des formats tel que JSON
+apporte une forme de pérennité pour les applications, malgré une modification
+mineure en 2005 avec la suppression de la saisie de commentaires dans les
+documents au format JSON, YAML fait le choix d'évoluer et de s'adapter aux
+besoins des communautés.
+Cependant, comme le mentionne Ruud van Asseldonk sur son blog^[Voir le blog de
+Ruud van Asseldonk :
+https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell, consulté le
+31 mars 2024.], ces mises à jour peuvent générer des complications lorsque les
+fichiers YAML doivent passer d'un environnement à un autre alors que les
+versions de YAML utilisées sont différentes.
+Par exemple, Pandoc intègre en juillet 2018 la version 1.2 de YAML^[Voir la page
+des _releases_ de Pandoc :
+https://pandoc.org/releases.html#pandoc-2.2.2-2018-07-16, consultée le 31 mars
+2024.] où nous pouvons y lire :
+
+> Update manual for “true” YAML values. Now that we’re using HsYAML and YAML
+> 1.2, the valid true values are true, True, TRUE. NOTE! y, yes, on no longer
+> count as true values.
+
+Le changement de version génère une modification de comportement des valeurs `y,
+yes, on` qui signifiaient le booléen `true` dans la version 1.1 et ne sont plus
+que des chaînes de caractères à partir de la version 1.2.
+Or, tous les parseurs de YAML n'ont pas fait cette mise à jour. Par exemple, la
+très répandue librairie Python PyYaml, dont la dernière mise à jour remonte à
+juillet 2023^[Voir la page web de la librairie :
+https://pypi.org/project/PyYAML/, consultée le 31 mars 2024.], s'appuie toujours
+sur la version 1.1 de YAML.
+En somme, si un document doit passer d'un environnement utilisant la version 1.1
+ou la version 1.2, les informations structurées ne seront pas traitées de la
+même manière.
+
+Nous sommes en droit de nous demander pourquoi YAML reste aussi populaire ?
+Ruud van Asseldonk apporte plusieurs réponses à cette question.
+La première est que YAML fait partie des plus anciens langages de sérialisation
+de données et répondait alors à un besoin de toute une génération de
+développeurs, ensuite il permet l'écriture de commentaires à l'intérieur des
+documents, c'est-à-dire du texte qui ne sera pas traité par le parseur, alors
+que JSON ne le permet pas.
+Des alternatives comme le langage TOML^[Voir le site web du langage TOML :
+https://toml.io/en/, consulté le 31 mars 2024.] ont vu le jour dans les années
+2010 (2013 pour le TOML) pour tenter de pallier les problèmes sus-mentionnés.
+Le langage TOML est par exemple utilisée pour le fichier de configuration du
+paquet Python "Pressoir-CLI" afin de déclarer différents paramètres, par exemple
+de mise en page, parsés par le Pressoir et utilisés pour générer des livres au
+format HTML. Cet outil fera l'objet d'une analyse détaillée dans le prochain
+chapitre^[Le pressoir-cli est un paquet python développé par la CRCEN et
+disponible à cette page web : https://pypi.org/project/pressoir-cli/, consultée
+le 31 mars 2024.].
+
+Enfin, le dernier format pivot utilisé dans Stylo, le BibTeX, est utilisé pour
+structurer les références bibliographiques.
+BiBTeX est un format standard permettant de décrire des listes de références
+bibliographiques inventé par Oren Patashnik en 1985 pour l'écosystème LaTeX.
+Au-delà de LaTeX, c'est un format largement utilisé par les gestionnaire de
+références bibliographiques comme Zotero^[Zotero est un logiciel de gestion de
+références bibliographiques très connu, il est l'alternative libre et _open
+source_ à Mendeley, voir le site web de Zotero : https://www.zotero.org/,
+consulté le 31 mars 2024.] ou eBib^[EBib est un logiciel de gestion de
+références bibliographiques fonctionnant depuis l'éditeur de texte Emacs, voir
+le site du projet : https://joostkremers.github.io/ebib/, consultée le 31 mars
+2024.].
+
+Le choix d'intégrer BibTeX à Stylo provient de la possibilité d'utiliser l'API
+de Zotero dans l'éditeur de Stylo pour récupérer les informations des références
+bibliographiques.
+Ce fonctionnement entre Zotero et Stylo permet aux utilisateurs de ne passer que
+rarement par la forme brute du BibTeX, puis il permet de décentraliser la
+gestion et le nettoyage des informations de chaque références dans Zotero et
+limite les phases de nettoyage des informations à ce seul espace.
+Stylo est plutôt prévu pour récupérer des listes de références bibliographiques
+et procurer des fonctionnalités pour les intégrer dans un texte.
+L'utilisation du format BibTeX permet d'automatiser la saisie et la
+transformation des références bibliographiques selon les styles requis pour un
+document.
+Pourtant, ce choix pourrait être tout à fait discutable du fait des limites de
+Zotero et de BibTeX.
+Lors de la création d'un nouvel objet dans Zotero, le premier élément à saisir
+est le type d'objet à référencer. Le nombre de types est limité à 17. Cela
+couvre une bonne partie des besoins académiques mais pas les exceptions qui vont
+toutes rentrer dans le dernier type `@misc` pour « tout autre type de
+document ».
+Il en va de même pour les informations rattachées à chaque type de données^[cf.
+le tableau des champs accolés aux types de documents en annexe.] : selon les
+disciplines ou les pour certains documents très particuliers, les champs de
+Zotero peuvent être trop restrictifs alors qu'il serait nécessaire de pouvoir
+saisir de nouvelles entrées pour enrichir les données bibliographiques tout en
+préservant leur structuration. Actuellement, la seule possibilité serait
+d'utiliser le champ `Extra` pour ajouter une information supplémentaire sous la
+forme de chaîne de caractères sans avoir de structure explicite.
+
+D'autres problèmes peuvent surgir entre la représentation d'une référence
+bibliographique dans Zotero et dans Stylo/Pandoc.
+Lors de l'édition d'articles en anglais et en français, nous nous sommes aperçus
+d'une différence de comportement importante entre ce que prévoit le format
+BibTeX, son interprétation dans Zotero et celle que l'on en fait dans Stylo..
+Avec BibTeX il existe plusieurs paramètres de langues : `langid` et `language`.
+`langid` permet initialement d'identifier la langue à appliquer à l'entrée
+(comme traitement) et `language` sert à déclarer la langue employée dans le
+document.
+Stylo et Pandoc prennent les deux paramètres en charge, alors que dans Zotero il
+n'est possible de renseigner que `language` et pas `langid`, `language`
+combinant les deux objets.
+En récupérant les références bibliographiques depuis Zotero, Stylo récupère
+seulement le paramètre `language` puisque le paramètre `langid` n'existe pas
+dans Zotero.
+Lors du traitement des informations avec Pandoc, il n'est pas possible de
+déclarer le traitement à appliquer à la référence bibliographique.
+Par défaut, Stylo va appliquer la langue du contenu du texte dans Stylo à toutes
+les références bibliographiques. Dans un texte comme celui-ci, le paramètre par
+défaut est réglé sur le français.
+Les références en anglais seront alors transformées selon les règles
+orthotypographiques françaises et pas selon les normes anglaises.
+Pour une structure éditoriale telle qu'une revue, ce paramètre n'est pas
+opérationnel.
+De ceci découle une discussion entre les membres de l'équipe de développement de
+Stylo^[Voir la discussion sur GitHub :
+https://github.com/EcrituresNumeriques/stylo/pull/991, consultée le 31 mars
+2024.] sur la conduite à tenir pour informer les usagers de ce problème et
+trouver une solution pour le contourner.
+À ce jour, nous avons décidé de renseigner le problème dans la documentation de
+Stylo^[Voir la documentation de Stylo :
+http://stylo-doc.ecrituresnumeriques.ca/fr/bibliographie/#lettres-capitales-pour-les-titres-en-anglais,
+consultée le 31 mars 2024.] pour avertir les utilisateurs.
+Une modification du format ou du fonctionnement du gestionnaire de références
+bibliographiques serait beaucoup trop lourde en termes d'effets de bord dans
+Stylo, c'est pour cela qu'à ce stade nous en sommes restés à cette solution.
+
+[Faire une mini conclusion sur ce qu'apporte ces trois formats]
+
### Co-écriture entre les agents
-- mettre les différentes représentation du texte et les traces qu'elles laissent
+En régissant les procédés de saisi du textes, un rapport de force semble
+s'instaurer entre les instances éditrices des architextes (que ce soit des
+collectifs, des institutions ou des entreprises) et les usagers.
+Dans le cas d'un logiciel de traitement de texte lorsque, par exemple, Microsoft
+propose une modification de la police utilisée par défaut dans une version
+actualisée du logiciel MSWord, Microsoft change également les manières d'écrire
+de tous les individus à travers le monde qui utilisent ce logiciel (et qui ont
+installé la mise à jour).
+
+Si l'on s'arrête à la vision superficielle du texte, comme le propose J. Goody
+avec la raison graphique, on ne voit que les modifications d'affichage des
+éléments graphiques mais nous oublions ceux qui sont invisibles et cachés
+derrière la page.
+
+Certes, les interfaces d'écriture sont présentés sous la forme de gabarits que
+l'on doit remplir, comme on peut le faire avec des logiciels de création de
+diapositives dont chacune est découpée en sections contenant tour à tour des
+images, des titres ou du texte.
+Dans cet exemple-ci nous avons affaire à une construction visuelle du document :
+un emplacement pour le titre de la diapositive, un autre pour le texte, un autre
+pour une image ou pour un graphique, etc.
+À ce sujet, E. Tufte [-@tufte_cognitive_2003] a publié un article sur
+l'utilisation du logiciel PowerPoint et démontre à travers plusieurs cas d'étude
+les effets du logiciel sur la forme des présentations et des informations
+qu'elles contiennent.
+La thèse qu'il y défend est que ce logiciel, en 2003, « [...] perturbe, domine
+et banalise systématiquement le contenu. » ^[Traduction personnelle : \[...\]
+routinely disrupts, dominates, and trivializes content.] notamment parce qu'il
+« facilite activement la réalisation de présentation légère »^[Traduction
+personnelle : actively facilitates the making of lightweight presentations.].
+À travers son analyse des usages de PowerPoint, E. Tufte nous montre qu'il
+ne s'agit pas d'un manque de fonctionnalité pour enrichir des supports de
+présentation, que l'auteur qualifie de pauvres, mais que le logiciel lui-même
+induit ce type de présentation avec des _templates_ préfabriqués, des
+réalisations de graphiques automatisées ou d'autres fonctionnalités similaires
+qui appauvrissent les présentations parce que leur fonctionnement est calqué sur
+un modèle de présentation marketing qui n'est pas adapté aux sciences.
+Il ne s'agit plus seulement de remplir des gabarits préfabriqués mais également
+de penser les formes que peuvent prendre l'information, ce que Tufte nomme « The
+Cognitive Style of PowerPoint », qui n'est pas sans rappeler la raison
+computationnelle de Bruno Bachimont [-@bachimont_intelligence_2000].
+
+En changeant de paradigme, de la raison graphique pour celui de la raison
+computationnelle, l'assujetissement à ces architextes dépasse cette surcouche
+graphique et concerne également toutes les sous-couches (in)visibles de
+structuration textuelle du texte, mais aussi tout le processus d'inscription du
+document dans la mémoire, ainsi que les protocoles et méthodes qui permettent
+d'accéder à ces données.
+Comme nous l'avons vu précédemment, ce n'est pas l'image du texte affichée à
+l'écran qui est sauvegardée mais bien une suite de caractères binaires dont
+l'écriture intermédiaire est une suite de symboles, de chiffres et de lettres.
+
+Pourtant, on constate un paradoxe entre le nom d'un logiciel comme Pages, un
+traitement de texte disponible sous MacOS convoquant la métaphore de la page
+comme imaginaire en y enfermant les utilisateurs, et le rôle de guide qu'il doit
+remplir dans le traitement des informations.
+Dans ce cas-ci, le nom du logiciel ne réfère ni à son fonctionnement ni à son
+utilité.
+Alors que dans les années 1980, lors de la génèse des traitements de texte, les
+lettres `WP` signifiaient WordPerfect^[Cet acronyme correspondait à la commande
+pour exécuter le logiciel depuis un terminal, alors qu'aujourd'hui il réfère
+plutôt au logiciel WordPress.], et que la plupart des autres concurrents
+employaient également le mot _word_ dans le nom de leur logiciel, car c'est bien
+le mot et son traitement informatique qui était au centre des développements, la
+démarche d'Apple en 2005 nous montre un changement de perspective : on passe du
+mot à la page.
+L'attention est porté à un autre endroit, sur une page que génère Pages et qui
+n'existe pas dans d'autres environnements.
+Depuis vingt ans que cet outil est nativement disponible sur les ordinateurs de
+chez Apple, la compatibilité avec d'autres formats et/ou logiciels à fortement
+augmentée, en témoigne les arguments de communication mis en avant sur la page
+web du logiciel^[Voir le site web, consulté le 21 mars 2024 :
+https://www.apple.com/pages/compatibility/] mais compatible ne veut pas dire
+identique.
+En plus de n'être accessible que **sous** MacOS, cette page ne l'est également
+que **sous** Pages : cette formulation courante laisse entendre que
+l'utilisateur devient alors sujet de son environnement d'écriture, nous dit F.
+Kittler [-@kittler_mode_2015].
+
+Cette position kittlerienne, que l'on peut qualifier d'essentialiste, pose les
+fondations des travaux de K. Hayles [@hayles_my_2005], du posthumanisme, et du
+nouveau matérialisme, courants dans lesquels s'inscrivent en outre les travaux
+de K. Barad [-@barad_meeting_2007; -@barad_frankenstein_2023] et ceux de M.
+Vitali-Rosati [-@vitali-rosati_pour_2021].
+Pourtant, leur approche du rapport entre humain et machine est radicalement
+différente de celle de F. Kittler.
+Alors que F. Kittler identifie la machine et l'utilisateur par une série de
+propriétés ou définitions *avant* leur interaction, quasiment de manière
+décisive, les posthumanistes choisissent de ne pas déterminer les agents
+préalablement à l'environnement mais comme résultats de l'agencement de
+plusieurs dynamiques dans un espace donné.
+C'est en ce sens que sont mobilisées et développées les notions de _worldview_
+ches K. Hayles, où Mère Nature devient une Matrice (_My Mother was a Computer_),
+l'_intra-action_ à la place d'interaction puisque les agents ne sont pas
+prédéterminés chez K. Barad et enfin l'_éditorialisation_ chez M. Vitali-Rosati qui
+propose une ontologie de la médiation (métaontologie) selon laquelle le media
+n'existe pas, on y retrouve la provocation de Kittler, et que toutes ces
+dynamiques, ces intra-actions, sont des médiations dont la matérialité, dans un
+agencement donné, produit du sens [@vitali-rosati_media_2019].
+
+Ainsi, l'assujetissement de l'humain aux logiciels que nous avons mentionné, que
+F. Kittler critique vivement dans ses travaux, n'a plus de raison d'être dans
+cette perspective non-essentialiste offerte par l'éditorialisation puisque ces
+entités sont uniquement déterminées lorsqu'il y a intra-action.
+Les relations entre les agents ne peuvent plus être présupposées et leur
+détermination est réalisée depuis un référentiel quasiment unique si l'on
+considère que les paramètres de cet environnement sont variables et que la
+probabilité d'obtention de conditions strictement identiques est quasi nulle.
+Depuis cette perspective où l'on considère les différents agents comme des
+productions de leur agencement dans un écosystème, il devient intéressant
+d'observer leur relation tout au long de ce processus pour comprendre comment
+ils s'affectent les uns les autres.
+
+[Faire une transition vers les différents du texte, peut-être en mentionnant que
+finalement il y a une partie de l'écriture qui est aveugle.]
+
+[Reprendre le début de cette partie, revenir sur l'architecture logicielle et
+montrer qu'il y a un manque dans ce que nous avons décrit précédemment en terme
+d'interaction et que c'est le navigateur qui gère ça]
+
+La description préliminaire des différents composants nous amène aux mécanismes
+de l'écriture dans Stylo.
+
+Jusqu'à présent, nous savons que le texte est saisi par l'utilisateur en
+Markdown (YAML et BibTeX également), puis est envoyé sur le serveur au moyen
+d'une requête GraphQL au format JSON contenue dans une requête HTTP utilisant la
+méthode `POST` comme modalité de circulation de l'information.
+Entre ces étapes persiste une phase qui n'a pas encore été évoquée : la requête
+`POST` envoyée au serveur ne s'effectue pas en continu entre le client et le
+serveur, ce n'est pas un flux et l'on n'écrit pas directement dans la base de
+données.
+Une phase latente se glisse dans l'interface Web entre le moment où
+l'utilisateur frappe les touches de son clavier et le moment où la base de
+données est mise à jour.
+Cette phase est rendue visible par l'affichage du message au-dessus de l'éditeur
+de texte.
+Lorsque aucune touche du clavier n'est enfoncée pendant un certain laps de temps
+(quelques secondes), le message "_Last saved..._" est remplacé par "_saving_" :
+la copie de travail vient d'être enregistrée dans la base MongoDB grâce à la
+requête GraphQL `updateWorkingCopy()`.
+Dans ce laps de temps entre la frappe des mots au clavier et l'envoi de la
+requête au serveur, qu'advient-il du texte ?
+
+Comme cela est mentionné précédemment, l'espace d'écriture de Stylo est un
+espace web.
+Pour y accéder, nous avons besoin d'un logiciel particulier -- un navigateur ou
+un fureteur -- capable d'interpréter du HTML, du CSS et d'exécuter du
+Javascript.
+Lorsque l'on écrit dans Stylo -- et de surcroit dans Monaco --, le texte saisi
+doit être manipulable et interprétable par le navigateur pour pouvoir être
+envoyé sur le serveur.
+C'est le rôle de Monaco de traiter cette couche d'informations.
+À l'écran, l'utilisateur voit s'afficher du Markdown tel qu'il le frappe,
+pourtant cette information n'est inscrite sur aucun support en dehors du rendu
+visuel affiché à l'écran.
+Monaco travaille avec des *modèles* et ce sont avec eux que l'utilisateur
+interagit.
+Chaque modèle est rattaché à une URI (que l'on peut identifier avec
+l'identifiant des articles) et c'est de cette manière que Monaco peut manipuler
+le DOM (_Document Object Model_) du navigateur pour créer le texte et son rendu
+graphique dans un format de texte brut.
+
+Le DOM est une représentation abstraite d'un document HTML exécutée dans le
+navigateur.
+Tous les éléments structurés à l'intérieur de ce document deviennent des objets,
+des noeuds manipulables avec du Javascript.
+C'est grâce à ce procédé qu'une page web est rendue dynamique.
+Puisque la construction du DOM dépend du navigateur employé, nous pouvons en
+déduire que ce document sera différent selon le navigateur ou les différentes
+versions d'un même logiciel.
+Pour accéder à ce DOM il suffit d'ouvrir les outils de développements du
+navigateur et d'inspecter le contenu de la page HTML.
+
+Ci-dessous, une première image pour montrer le texte saisi à l'écran et une
+deuxième pour montrer ce qui est inscrit dans le DOM.
+
+![Exemple de texte saisi en Markdown dans Stylo](https://s3.hedgedoc.org/demo/uploads/fbed0e8c-2963-49a4-9ae4-76db68af4108.png "Exemple de texte saisi en Markdown dans Stylo")
+
+![Affichage du DOM pour le texte correspondant](https://s3.hedgedoc.org/demo/uploads/62292c15-8649-4e48-b1fd-d5ae242338b1.png "Affichage du DOM pour le texte correspondant")
+
+L'état du texte inscrit dans le DOM est différent de celui qui apparaît à
+l'écran.
+Le Markdown se retrouve encapsulé dans des balises attribuées par l'éditeur
+Monaco et la syntaxe Markdown se retrouve à l'état de chaîne de caractères : la
+balise de titre de niveau 2 (`##`) n'a plus de valeur sémantique.
+Le DOM interprète la structure HTML des informations contenues dans Monaco pour
+les afficher de façon à ce que l'utilisateur puisse avoir un rendu graphique du
+texte qu'il a saisi, comme la colorisation syntaxique des balises.
+Néanmoins, pour Stylo, le texte saisi n'a en lui-même aucun sens et il ne doit
+pas en avoir puisque c'est cette particularité qui rend l'écriture
+automatisable.
+
+Écrire dans un environnement comme Stylo ne consiste pas seulement en une simple
+saisie du texte à l'écran.
+Lorsque nous avons l'impression d'écrire en Markdown, Stylo écrit un texte bien
+différent.
+Le texte affiché dans Stylo passe en réalité, d'un point de vue matériel, par au
+moins 4 représentations différentes :
+
+- le texte saisi en Markdown (affichage à l'écran)
+- la représentation du texte dans le DOM réalisée dans le navigateur par
+ l'éditeur Monaco
+- la requête GraphQL envoyée au serveur au format JSON par HTTP
+- l'état de sauvegarde sur le serveur dans la base de données MongoDB
+
+Saisir du texte dans Stylo nécessite en réalité une multitude d'étapes
+intermédiaires invisibles -- on pourrait plutôt les qualifier d'automatisées --
+mais que pourtant Stylo rédige et inscrit dans la mémoire numérique.
+
+Chacun de ces états a une signification particulière.
+Le premier état est la projection d'une structure de l'information, tandis que
+le deuxième en permet l'interprétation et l'affichage par le navigateur, la
+troisième est une représentation formatée pour circuler entre un client et un
+serveur et enfin, la quatrième, est à l'état de stockage, prête à être appelée
+pour réaliser le chemin en sens inverse.
+
+Ces différents états du texte sont plus que de simples représentations. Ce sont
+des documents différents et chacun à une signification et un usage qui lui est
+propre.
+Par exemple, la forme en Markdown brut ne peut pas circuler en l'état avec le
+protocole HTTP, il lui manque toute une série d'informations et une
+transformation vers un autre format (le JSON) pour employer ce canal de
+communication : ce dont s'occupe Stylo.
+
+Parmi ces quatre documents produits pour écrire, un seul l'est par l'utilisateur
+tandis que les autres formes sont écrites par Stylo.
+
+[faire un mini conclusion sur la cécité de l'écriture num.]
### La déprise en main du texte
-- inclure les formats pivots de Stylo
+Écrire dans un environnement numérique dépasse l'encodage de signes dans un seul
+format d'écriture.
+Comme nous l'avons vu avec Stylo, ce sont différents protocoles qui sont
+mobilisés pour produire une suite de documents intermédiaires et, par ce
+cheminement, imprègnent l'écriture d'une matérialité.
+Lorsque Stylo promeut une reprise en main du texte par les utilisateurs, il ne
+faut pas comprendre un environnement moins complexe en termes d'interactions des
+différentes composantes dans cet écosystème, il faut y voir une chaîne de
+traitement transparente, libre et ouverte sur les transformations opérées dans
+le texte.
+Pourtant, plutôt qu'une reprise en main, nous lui préférons la notion de
+**déprise** sur le texte, au sens que lui donnait Louise Merzeau
+[@sauret_revue_2020]^[Louise Merzeau n'a jamais publié de document sur cette
+déprise, néanmoins Nicolas Sauret mentionne ce concept et son sens dans sa
+thèse.].
+
+> Cette formule est empruntée à Louise Merzeau qui l’employait pour parler des
+> […] utilisateurs des grandes plateformes du Web [et de] la perte de contrôle
+> de leurs usages, restreints et conditionnés par les algorithmes et par des
+> interfaces de plus en plus normalisées.
+
+Dans Stylo, les utilisateurs ne sont pas forcément conscients des formes
+d'écriture internes à cet environnement, ni de la circulation des informations
+entre les éléments qui le constituent.
+Cette part de Stylo cachée derrière l'écran relève de cette déprise.
+
+Si l'on suit les différentes métamorphoses du texte, on se rend compte que la
+forme brute n'est inscrite nulle part. On la retrouve soit sous sa forme
+interprétée par le navigateur (en réalité il s'agit d'un document HTML), soit
+lors de l'export c'est-à-dire lorsque les documents sortent de l'environnement
+Stylo.
+En dehors de cette situation, il n'existe aucun document dont l'extension serait
+`.md` et stipulerait que ledit document respecte les règles et normes de ce
+format.
+
+À la différence des systèmes analogiques et continus, la rupture opérée par
+l'écriture numérique réside entre autre dans cette discrétisation du texte en de
+multiples documents, où chacun se voit doté d'un paratexte différent pour
+circuler à travers les canaux de communication du système d'informations.
+
+Dans Stylo, les textes y sont écrits par l'ensemble des protocoles choisis lors
+de l'établissement de cet environnement.
+La déprise sur le texte survient lors du choix de l'environnement par
+l'utilisateur.
+Lorsqu'un utilisateur écrit dans Stylo, il accorde sa confiance dans les
+opérations que réalise Stylo sur le texte et dans la matérialité qu'il participe
+à lui conférer.
+
+Toutes ces dynamiques éditorialisent et constituent les premiers documents de
+l'intimité du chercheur.
+Autrement dit, écrire dans l'environnement Stylo produit quelque chose qui ne
+serait pas identique dans un autre environnement car les dynamiques observées
+seraient affectées par d'autres facteurs et produiraient ainsi une autre chose.
+Le choix de l'environnement d'écriture constitue en conséquence un choix
+politique puisque cet environnement agit et produit une matérialité singulière.
+
+## Conclusion
+
+À la question de la place de l'ordinateur dans le processus de saisi d'un texte
+numérique, nous avons émis l'hypothèse que ce dernier dépasse son statut
+utilitariste pour celui de dynamique constitutive du sens de ce texte.
+En nous appuyant d'abord sur le fonctionnement d'un ordinateur et sur les
+caractéristiques de l'écriture numérique, tant la partie matérielle que la
+partie logicielle, puis sur la notion d'éditorialisation, telle qu'elle
+s'inscrit dans le nouveau matérialisme et le posthumanisme, nous avons observé
+les intra-actions à l'oeuvre dans l'éditeur de texte Stylo.
+Pour réaliser cette étude, nous nous sommes appuyés sur une méthode empruntée au
+théoricien des médias Friedrich Kittler dont l'analyse repose sur la description
+technique du fonctionnement des éléments mobilisés.
+
+En appliquant cette méthode à divers cas de saisi de fragments de texte selon
+les formats pivots utilisés dans Stylo, le Markdown, le YAML et le BibTeX, nous
+nous sommes aperçus que ces fragments ne sont jamais inscrit directement selon
+les formats mentionnés mais qu'ils passent par quatre états différents : la
+saisie à l'écran, la manipulation par le DOM du navigateur dans l'éditeur
+Monaco, la requête GraphQL formatée en JSON pour être transporté par la méthode
+`POST` du protocole HTTP et le stockage dans la base de données MongoDB.
+Le texte est ainsi transformé en différents états pour qu'il puisse circuler
+dans Stylo entre l'espace où il est saisi, que l'on peut retrouver à une adresse
+unique (l'URL de l'article), et l'espace où il sera stocké dans le serveur de la
+TGIR Huma-num qui héberge l'application.
+De nouvelles informations sont alors inscrites dans le texte lors de ces
+métamorphoses : la structure du document varie à chaque étape.
+Ainsi, les signes qui constituent le document changent et en modifie
+profondément le sens.
+Parmi les quatre états mentionnés, seulement le premier est saisi par
+l'utilisateur et les autres sont écrits par Stylo.
+Néanmoins écrire avec Stylo ne nécessite pas de connaître ces différentes
+phases.
+Il y aurait donc une relation entre un auteur et Stylo qui prendrait naissance
+dans une forme de déprise où l'utilisateur accorde sa confiance dans les
+manipulations du texte que l'application réalise.
+En se référant à l'éditorialisation, nous pouvons affirmer que chacune de ces
+quatre phases contribue à la matérialité du texte saisi et qu'en ce sens il y a
+co-écriture entre l'utilisateur et Stylo.
## Bibliographie
+