Ce que les machines écrivent dans le texte

Introduction

L’environnement d’écriture, du hardware jusqu’au software, n’est pas un support neutre du processus d’écriture numérique. Bien au contraire il en est une composante fondamentale.

Cette présentation est l’occasion de vous montrer mes travaux de thèse. Je vais donc vous parler d’une recherche en cours sur la relation entre usager et ordinateur dans le processus d’écriture numérique en sachant que je me positionne plutôt du côté des machines – comme le titre l’indique – et pas sur la composante humaine de ce processus même si celle-ci en est majeure.

L’hypothèse que je défend est que l’environnement d’écriture, du hardware jusqu’au software, est loin d’être neutre dans cette écriture et que par conséquent cet environnement en est une composante fondamentale.

Lorsque l’on mobilise la notion d’écriture numérique, celle-ci englobe plus ou moins la totalité d’une chaîne éditoriale, de la saisie d’un texte jusqu’à l’obtention d’un objet final. Or vous parler aujourd’hui de toutes ces étapes serait beaucoup trop long et le risque serait d’être superficiel. Ma proposition est donc la suivante, nous allons échanger seulement autour de la première étape : la saisie d’un texte dans un ordinateur. Pour bien comprendre les enjeux de ce phénomène, je vais commencer par revenir sur certaines caractéristiques de l’écriture numérique et des ordinateurs avant de vous présenter un cas concret de saisie d’un texte dans l’environnement Stylo. Vous le savez certainement déjà, je suis impliqué dans l’équipe qui porte et développe cet éditeur de texte depuis un peu plus de deux ans, ce qui m’offre une place de choix pour l’étudier. Instant publicité : je suis disponible pour aider / former / débuguer Stylo pour celleux qui en ont besoin. Métopes et Lodel viennent de publier leur mise à jour, on a désormais une alternative au paradigme MS Word et LaTeX (comme le décrit Arthur Perret sur son blog) pour publier avec OpenEdition !

L’approche que j’ai décidé d’adopter pour étudier cet environnement est inspirée de celle de F. Kittler, un théoricien des médias des années 70’ et 80’ qui s’appuyait sur une description technique très rigoureuse des différents éléments en interaction pour comprendre les mécanismes à l’oeuvre dans un système d’écriture, d’abord avec la machine à écrire, puis avec les premières générations d’ordinateurs. En somme, la méthode qu’il propose est très matérialiste (au sens que McLuhan donne à ce terme) (Kittler, 2015, 2018).

1. Écriture numérique

1.1. Les 3 propriétés de l’écriture numérique

la variabilité
la calculabilité
la distinction entre geste de saisi et inscription dans le support

1.2 Entre matériel et logiciel

Hardware:
- alimentation
- microprocesseur
- une mémoire vive
- entrées et sorties

Software:
- BIOS
- Système d’exploitation
- Logiciels

Je ne vais pas rendre honneur à McLuhan et Kittler sur les routes de l’information numérique puisque j’aimerais attirer votre attention sur un seul point de cette architecture et non pas sur les différents aspects qui la caractérisent. Un ordinateur est souvent présenté par le couple matériel/logiciel. De cette manière nous avons tendance à présenter le logiciel comme une entité à part, complètement désolidarisée de son support. Pourtant, dans la structure d’un ordinateur, les logiciels ne sont pas du tout au même niveau que la partie matérielle, ils y sont installés à l’intérieur et servent de couche d’abstraction pour faire oublier le fonctionnement des composants nommés sur la diapositive.

Chaque logiciel dépend d’un environnement bien particulier pour fonctionner même si cette contrainte a été lissée ces dernières décennies (exemple : l’OS Windows 11 ne peut pas être installé sur tous les ordinateurs faute de compatibilité matérielle). Le logiciel, en tant que possibilité de donner des instructions de traitement des informations, s’ouvre comme une fenêtre (pour plagier Microsoft) pour dialoguer avec les composants du hardware.

On a donc d’un côté une liste de composants primordiaux pour le fonctionnement d’un ordinateur et de l’autre les couches d’abstraction matérielle en commençant par le BIOS puis l’OS. Les logiciels sont alors installés à l’intérieur de l’OS au même niveau que les documents créés par l’utilisateur.

Sans entrer plus dans ces détails, je vous propose d’observer une fenêtre particulière : l’éditeur de texte Stylo.

2. Stylo : étude de cet environnement d’écriture

Capture d’écran - Éditeur de texte Stylo

2.1 Les briques logicielles de Stylo

Les différents modules de Stylo

Derrière cette interface web se cache toute une architecture logicielle et c’est elle qui nous intéresse. Afin d’être raccord avec la méthode énoncée en introduction, nous avons besoin de nous affranchir de la partie graphique et de plonger à l’intérieur des mécanismes de ce système d’informations. Aussi, nous allons discuter de la version 3 de Stylo. Le code a bien évolué depuis sa version 0 et il est susceptible de changer encore dans les prochains mois / années. Nous pouvons scinder cette architecture en trois parties.

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, 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 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 développée par Microsoft et rendue disponible sous licence MIT.

Enfin, le dernier bloc de Stylo est le module d’export qui permet de transformer les informations saisies et visibles dans l’éditeur en de multiples documents grâce au logiciel de conversion Pandoc.

2.2 La circulation des informations dans Stylo

API GraphQL
protocole HTTP
- méthode POST

Ces deux premiers blocs, la base de données MongoDB et l’interface web, ne sont pas en communication directe. Les champs de texte dans Monaco 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), 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. 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.

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¹, 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.

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).

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 publié en juin 2022.

Ce que l’on doit en retenir est que, 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 :

{"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'"}}}

2.3 Les différentes représentations du texte

Jusqu’à présent nous avons vu 3 formes différentes d’un même texte saisi dans l’interface :

le texte saisi en Markdown
la requête GraphQL (JSON)
la forme archivée dans MongoDB (JSON)

Exemple de texte saisi en Markdown dans Stylo

Affichage du DOM pour le texte correspondant

Monaco est un composant Web. Pour afficher des informations et les rendre dynamiques, il doit manipuler des éléments qui appartiennent à cet écosystème, soit du HTML, du CSS et du JS. Le Markdown (le YAML et le BibTeX) n’en font pas partie.

Pour pouvoir manipuler le texte brut, Monaco joue avec le DOM du navigateur. Le DOM est un document généré par le navigateur, il n’existe que lorsque celui-ci est exécuté. Pour afficher une la structuration du DOM il suffit d’ouvrir les outils de développement du navigateur. Ce DOM manipule des noeuds (des balises et leur imbrication les unes dans les autres) et leurs contenus.

Monaco crée de cette manière ces propres noeuds dans un espace délimité. Ainsi, il va créer et manipuler des balises HTML span à l’intérieure desquelles se trouve le texte saisi par l’utilisateur.

L’affichage graphique réalisé par Monaco camoufle ce que l’utilisateur saisit pour correspondre à ce qu’il s’attend à voir, c’est-à-dire ce qu’il a frappé sur son clavier.

Ensuite, Monaco se charge d’envoyer le texte brut à un service en JS qui génère la requête GraphQL à envoyer au serveur.

Conclusion

À travers cette étude de cas, nous avons vu que le texte est 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 le constituent changent et en modifient profondément le sens. Parmi les quatre états du texte mentionnés, seulement le premier est saisi par l’utilisateur et les autres sont écrits par Stylo.

Alors vous pourriez me rétorquer que les 3 états rédigés par la machine le sont automatiquement, et je serais d’accord avec vous. C’est justement une caractéristique de l’écriture numérique, d’ailleurs elle était déjà pensée par Turing dans son article de 1936 et c’est ce qui permet à un environnement tel que Stylo de pouvoir traiter les informations que l’on y insère.

Pourtant, si l’on revient à mon petit pitch sur le fonctionnement des ordinateurs on voit bien qu’il y a un ensemble de médiations à l’oeuvre, que ce soit des matériels ou des logiciels, qui permettent d’écrire de cette manière là et pas d’une autre dans Stylo, en plus de ce que les formats de texte permettent ou non.

Tous ces protocoles sont implémentés dans des matériels spécifiques, dans ce cas-ci des serveurs DELL R630 à Lyon, dans une machine virtuelle de 48Go, etc. Les conditions d’existence de Stylo sont fragiles et ne peuvent exister en l’état que dans cet environnement.

Toutefois, je vous rassure, é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.

Voilà ce que les machines écrivent dans le texte.