mise à jour de la version html

1 files changed, 106 insertions, 16 deletions

diff --git a/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html b/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html
index 497d271..e9e42cb 100644
--- a/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html
+++ b/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html
@@ -49,7 +49,7 @@
 <ul>
 <li><a href="#quest-ce-que-stylo" id="toc-quest-ce-que-stylo">Qu’est-ce que Stylo ?</a></li>
 <li><a href="#les-formats-pivots-de-stylo-en-détail" id="toc-les-formats-pivots-de-stylo-en-détail">Les formats pivots de Stylo en détail</a></li>
-<li><a href="#ce-que-stylo-permet-ou-non-de-faire" id="toc-ce-que-stylo-permet-ou-non-de-faire">Ce que Stylo permet ou non de faire</a></li>
+<li><a href="#écrire-avec-stylo" id="toc-écrire-avec-stylo">Écrire avec Stylo</a></li>
 </ul></li>
 <li><a href="#conclusion-1" id="toc-conclusion-1">Conclusion</a></li>
 </ul>
@@ -121,7 +121,7 @@
 <p>L’encodage et le décodage des caractères accompagne toute l’histoire de l’informatique (et du numérique). Au prémices de l’informatique, chaque matériel comportait ses propres programmes et tables d’encodage, rendant ainsi possible la transposition des données d’un matériel à un autre. Cependant, dans la plupart des cas, les données ne pouvaient pas circuler entre les différents modèles d’ordinateur, ou alors au moyen de transformations fastidieuses, rendant ainsi les traitements réalisés sur les données enfermés dans des silos. La norme ASCII (<em>American Standard Code for Information Interchange</em>) fait sont apparition dans les années 1960 pour résoudre les enjeux liés à l’encodage des données. Soumise à l’<em>American Standards Association</em> (d’abord ASA puis ANSI) en 1961 par l’un de ses inventeurs, Bob Bemer, puis approuvée en 1963, l’ASCII permet d’encoder 128 caractères sur 7 bits. Néanmoins, ce n’est pas parce qu’un encodage est reconnue en tant que norme que son usage est effectif à l’instant même de la reconnaissance. Il faut attendre 1968 que le président des États-Unis Johnson demande à ce que l’ASCII devienne la norme fédérale d’encodage des informations afin de réduire les incompatibilités au sein des réseaux de télécommunications pour qu’elle commence à se répandre. Dès 1969, tous les ordinateurs achetés par le gouvernement des États-Unis étaient compatibles avec la norme ASCII. Du côté des ordinateurs personnels, il faudra attendre le début des années 1980 pour que cette norme se répande grâce, entre autre, à son implémentation dans les ordinateurs construits par IBM. La norme X3.4:1986 en vigueur aujourd’hui, a été déposée auprès de l’ANSI en 1986. C’est à partir de cette norme que d’autres ont été développées et sont compatibles ASCII, comme c’est par exemple le cas pour la norme Unicode, publiée en 1991, qui est la plus répandue de nos jours, car c’est elle qui encode le plus de caractères. Si ASCII contient 128 points de code, le standard Unicode permet d’en encoder plus de 149 000 sur une vingtaine de bits par point de code dans sa version 15.1 (de 2023). Afin de préserver cette compatiblité entre les normes, il est d’usage d’encoder les 128 premiers caractères de façon identique à la norme ASCII.</p>
 <h4 id="fonctionnement-du-software-les-différentes-piles">Fonctionnement du software (les différentes piles)</h4>
 <p>Bios, OS, Logiciels, réseaux (protocoles HTTP, TCP/IP, IMAP, POP, REST, GrapHQL), communication entre les différentes couches et fonctionnement de l’inscription dans le disque dur (HDD et SSD).</p>
-<p>Pour le protocole HTTP, détailler un peu les différentes méthodes et la circulation des paquets</p>
+<p>Le protocole HTTP a été conçu pour permettre la communication entre un client et un serveur. Les méthode de communication les plus couramment utilisée sont <code>GET</code> et <code>POST</code>. Par convention, et afin de limiter d’éventuels effets de bord, la méthode <code>GET</code> permet de récupérer des informations sur le serveur et de les afficher sur la page web tandis que <code>POST</code> permet de les envoyer depuis le client sur le serveur, soit pour ajouter une nouvelle entrée, soit pour la modifier.</p>
 <p>[Aux machines distantes (Serveurs, fibre optique, ADSL … Histoire de l’Internet physique)]</p>
 <h4 id="conclusion">Conclusion</h4>
 <p>[Si j’écris la chaine de caractère “Hello world” elle passe par (décrire les éléments) jusqu’à cet encodage dans le disque dur, voir si l’écriture avec une autre architecture propose un encodage différent]</p>
@@ -259,21 +259,105 @@ L'affichage de l'écriture à l'écran respecte des conventions de lecture propr
 <h4 id="les-briques-logicielles">Les briques logicielles</h4>
 <p>Ces trois formats pivots, Markdown, YAML et BibTeX, sont insérés dans tout un écosystème logiciel pour en permettre leur utilisation.</p>
 <p>Cette architexture logicielle est scindée 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, 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 relationnelle développé en 2007 et s’appuyant sur des documents structurés en JSON. Dans Stylo, la structure …</p>
-<p>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 du web. On retrouve des objets en HTML, en CSS et en Javascript. Le <em>framework</em> React, une surcouche à Javascript <em>open source</em> développée par Facebook (aujourd’hui Meta) en 2013, a été employé pour réaliser les différents composants de l’interface et intégrer de nombreux modules tel que le module i18n qui permet d’implémenter le multilinguisme dans l’interface et changer la langue affichée à l’écran en un seul clic.</p>
-<p>La base de données MongoDB n’est pas stockée dans le même espace que l’interface web. En conséquence, un système de communication devait être établi entre ces deux objets pour que les informations puissent être accessibles, à la fois en écriture et en lecture. Pour mettre en oeuvre cette communication, une API (<em>Application Programming Interface</em>) utilisant le langage de requête GraphQL a été mise en place et rendue accessible via le protocole HTTP (<em>Hypertext Transfer Protocol</em>)<a href="#fn5" class="footnote-ref" id="fnref5" role="doc-noteref"><sup>5</sup></a>, la surcouche du protocole internet utilisée pour le web. Le langage de requête et de manipulation GrapHQL a également été développé par Facebook à partir de 2012 puis publié en <em>open source</em> en 2015.</p>
-<p>Le protocole HTTP a été conçu pour permettre la communication entre un client et un serveur. Les méthode de communication les plus couramment utilisée sont <code>GET</code> et <code>POST</code>. Par convention, et afin de limiter d’éventuels effets de bord, la méthode <code>GET</code> permet de récupérer des informations sur le serveur et de les afficher sur la page web tandis que <code>POST</code> permet de les envoyer depuis le client sur le serveur, soit pour ajouter une nouvelle entrée, soit pour la modifier.</p>
-<p>La particularité d’une API GraphQL, contrairement à une API REST par exemple, est qu’elle sert l’ensemble des données à une seule adresse (<em>endpoint</em>) alors que plus généralement, les données sont accessibles à des URL très précises.</p>
-<p>Plutôt que d’employer directement les méthodes <code>GET</code> et <code>POST</code> du protocole HTTP, deux types de requête sont utilisées avec la méthode <code>POST</code> pour effectuer les actions de lire et modifier le contenu de la base de données avec GraphQL. La requête de type <code>query</code> permet de récupérer les informations sur le serveur et celle de type <code>mutation</code> de les modifier.</p>
-<p>[Rappeler les propriétés de chacun des types dans GET et POST, et ce que ça apporte aux informations qui transitent]</p>
-<p>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. Tout ce module réalisé avec le langage de programmation Python est développé et maintenu par David Larlet. Cette brique technologique est articulée autour du logiciel de transformation et de conversion Pandoc<a href="#fn6" class="footnote-ref" id="fnref6" role="doc-noteref"><sup>6</sup></a> déployée sur un serveur et rendue accessible via une autre API<a href="#fn7" class="footnote-ref" id="fnref7" role="doc-noteref"><sup>7</sup></a> fabriquée à partir de <em>framework</em> FastAPI<a href="#fn8" class="footnote-ref" id="fnref8" role="doc-noteref"><sup>8</sup></a></p>
-<p>Le module d’export intégré à Stylo<a href="#fn9" class="footnote-ref" id="fnref9" role="doc-noteref"><sup>9</sup></a></p>
+<p>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 du web. On retrouve des objets en HTML, en CSS et en Javascript. Le <em>framework</em> React, une surcouche à Javascript <em>open source</em> développée par Facebook (aujourd’hui Meta) en 2013, a été employé pour réaliser les différents composants de l’interface et intégrer de nombreux modules tel que le module 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<a href="#fn5" class="footnote-ref" id="fnref5" role="doc-noteref"><sup>5</sup></a> développé par Microsoft et rendu disponible sous licence MIT.</p>
+<p>La base de données MongoDB n’est pas stockée dans le même espace que l’interface web. En conséquence, un système de communication devait être établi entre ces deux objets pour que les informations puissent être accessibles, à la fois en écriture et en lecture. Pour mettre en oeuvre cette communication, une API (<em>Application Programming Interface</em>) utilisant le langage de requête GraphQL a été mise en place et rendue accessible via le protocole HTTP (<em>Hypertext Transfer Protocol</em>)<a href="#fn6" class="footnote-ref" id="fnref6" role="doc-noteref"><sup>6</sup></a>, la surcouche du protocole internet utilisée pour le web. Le langage de requête et de manipulation GrapHQL a également été développé par Facebook à partir de 2012 puis publié en <em>open source</em> en 2015.</p>
+<p>L’une des particularités d’une API GraphQL, contrairement à une API REST par exemple, est qu’elle sert l’ensemble des données à une seule adresse (<em>endpoint</em>) 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’<em>over-fetching</em> ou d’<em>under-fetching</em> que l’on peut rencontrer dans certaines applications<a href="#fn7" class="footnote-ref" id="fnref7" role="doc-noteref"><sup>7</sup></a>. l’API GraphQL est agnostique vis-à-vis de la forme de la base de données. Par contre, la définition des requêtes adressables à la base de données doit être déclarée pour que l’on puisse faire circuler les informations. Pour cela, GraphQL à son propre langage de description de schéma (<em>SDL</em>, <em>Schema Definition Language</em>) et permet de déclarer explicitement les différentes façons d’écrire une requête.</p>
+<p>Par exemple dans Stylo, le champ <code>user</code> contient les informations suivantes<a href="#fn8" class="footnote-ref" id="fnref8" role="doc-noteref"><sup>8</sup></a> :</p>
+<ul>
+<li>_id</li>
+<li>displayName</li>
+<li>username</li>
+<li>authType</li>
+<li>email</li>
+<li>firstName</li>
+<li>lastName</li>
+<li>institution</li>
+<li>tags</li>
+<li>permissions</li>
+<li>acquintances</li>
+<li>articles</li>
+<li>workspaces</li>
+<li>admin</li>
+<li>yaml</li>
+<li>zoteroToken</li>
+<li>createdAt</li>
+<li>updatedAt</li>
+<li>apiToken</li>
+<li>addContact</li>
+<li>removeContact</li>
+<li>stats</li>
+</ul>
+<p>Une requête simple consisterait à vouloir directement récupérer l’adresse courriel lié à mon compte utilisateur :</p>
+<div class="sourceCode" id="cb2"><pre class="sourceCode graphql"><code class="sourceCode graphql"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="kw">query</span> user {</span>
+<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a>  user {</span>
+<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a>    email</span>
+<span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a>  }</span>
+<span id="cb2-5"><a href="#cb2-5" aria-hidden="true" tabindex="-1"></a>}</span></code></pre></div>
+<p>et renverrait comme réponse :</p>
+<div class="sourceCode" id="cb3"><pre class="sourceCode graphql"><code class="sourceCode graphql"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a>{</span>
+<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a>  <span class="st">&quot;data&quot;</span>: {</span>
+<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a>    <span class="st">&quot;user&quot;</span>: {</span>
+<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a>      <span class="st">&quot;email&quot;</span>: <span class="st">&quot;roch.delannay@umontreal.ca&quot;</span></span>
+<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a>    }</span>
+<span id="cb3-6"><a href="#cb3-6" aria-hidden="true" tabindex="-1"></a>  }</span>
+<span id="cb3-7"><a href="#cb3-7" aria-hidden="true" tabindex="-1"></a>}</span></code></pre></div>
+<p>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 cette économie.</p>
+<p>Dans Stylo, chaque fonctionnalité, chaque bouton (ou presque) qui réalise une action de lecture ou d’écriture est lié à une requête GraphQL. Précédemment nous avons vu que le protocole HTTP comportait deux méthodes bien connues pour faire circuler des informations entre un client et un serveur : <code>GET</code> et <code>POST</code>. 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<a href="#fn9" class="footnote-ref" id="fnref9" role="doc-noteref"><sup>9</sup></a>, une bonne pratique appliquée par la communauté GrapHQL est l’emploi du protocole HTTP couplé à la méthode <code>POST</code> pour tous types de requêtes (que ce soit une <code>query</code>, une <code>mutation</code> ou encore une <code>subscription</code>). Lors de la transmission des informations par la méthode <code>GET</code>, l’ensemble des informations sont insérées dans l’URL ce qui 1) les rend visibles (et vulnérable) et 2) impose une limite du nombre de caractères (au 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 <code>POST</code> pour récupérer des informations car elles ne seront ni visibles ni limitées en longueur, ce qui s’avère nécessaire pour des requêtes parfois trop longues. 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.</p>
+<p>Les spécificités du protocoles HTTP sont définies dans les <em>Request for Comments</em> publiés par L’<em>Internet Engineering Task Force</em> (IETF) fondée en 1986, dont le siège se trouve aux États-Unis. Les documents et leurs contenus sont régulièrement mis à jour par la communauté qui participe à ces commentaires. Le numéro de la RFC en lien avec la méthode <code>POST</code> est le 9110<a href="#fn10" class="footnote-ref" id="fnref10" role="doc-noteref"><sup>10</sup></a> publié en juin 2022.</p>
+<p>La méthode <code>POST</code> est définie dans le paragraphe 9.3.3 comme :</p>
+<blockquote>
+<p>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).<a href="#fn11" class="footnote-ref" id="fnref11" role="doc-noteref"><sup>11</sup></a></p>
+</blockquote>
+<p>À travers cette brève définition, l’on remarque que l’usage principal de la méthode <code>POST</code> est plutôt relative à l’envoi d’informations, qu’elles soient nouvelles ou mises à jour. Le comportement de <code>POST</code> fait toutefois débat, notamment quant à son usage pour l’envoi de certaines informations puisque, comme cela est indiqué dans sa définition, <code>POST</code> laisse le soin au serveur (la ressource cible) de traiter les données contenues dans son message selon sa propre sémantique. En somme, contrairement à d’autres méthodes comme <code>PUT</code>, <code>POST</code> 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).</p>
+<p>Cependant, cette caractéristique tend à disparaître dans le cas d’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, <code>POST</code> est donc soumis à l’architecture de GraphQL, on peut alors bien considérer GraphQL agnostique à l’égard de la méthode <code>POST</code> du protocole HTTP.</p>
+<p>Enfin, dans le cas d’une requête <code>POST</code>, le contenu à envoyer sur le serveur est formaté en JSON.</p>
+<p>Ci-dessous un exemple de requête <code>POST</code> envoyée depuis l’interface Web de Stylo vers le serveur :</p>
+<div class="sourceCode" id="cb4"><pre class="sourceCode json"><code class="sourceCode json"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="fu">{</span><span class="dt">&quot;query&quot;</span><span class="fu">:</span><span class="st">&quot;query updateWorkingVersion($articleId: ID!, $content: WorkingVersionInput!) {</span><span class="ch">\n</span></span>
+<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="st">article(article: $articleId) {</span><span class="ch">\n</span></span>
+<span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a><span class="st">updateWorkingVersion(content: $content) {</span><span class="ch">\n</span></span>
+<span id="cb4-4"><a href="#cb4-4" aria-hidden="true" tabindex="-1"></a><span class="st">updatedAt</span><span class="ch">\n</span></span>
+<span id="cb4-5"><a href="#cb4-5" aria-hidden="true" tabindex="-1"></a><span class="st">}</span><span class="ch">\n</span></span>
+<span id="cb4-6"><a href="#cb4-6" aria-hidden="true" tabindex="-1"></a><span class="st">}</span><span class="ch">\n</span></span>
+<span id="cb4-7"><a href="#cb4-7" aria-hidden="true" tabindex="-1"></a><span class="st">}&quot;</span><span class="fu">,</span></span>
+<span id="cb4-8"><a href="#cb4-8" aria-hidden="true" tabindex="-1"></a><span class="dt">&quot;variables&quot;</span><span class="fu">:{</span><span class="dt">&quot;userId&quot;</span><span class="fu">:</span><span class="st">&quot;61d62c4978651b001208b7aa&quot;</span><span class="fu">,</span></span>
+<span id="cb4-9"><a href="#cb4-9" aria-hidden="true" tabindex="-1"></a><span class="dt">&quot;articleId&quot;</span><span class="fu">:</span><span class="st">&quot;65e0e38129637c001274ef7a&quot;</span><span class="fu">,</span></span>
+<span id="cb4-10"><a href="#cb4-10" aria-hidden="true" tabindex="-1"></a><span class="dt">&quot;content&quot;</span><span class="fu">:{</span><span class="dt">&quot;md&quot;</span><span class="fu">:</span><span class="st">&quot;Ajout du texte pour la requête HTTP `POST`&quot;</span><span class="fu">}}}</span></span></code></pre></div>
+<p>Autrement dit, chaque fonctionnalité décrit de manière formelle la structuration des informations dans Stylo, donc ce que Stylo écrit dans la base de 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 les protocoles auxquels il est assujetti pré-construisent la totalité de ce qu’un utilisateur peut saisir dans l’interface et sera enregistré dans la base de données.</p>
+<p>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. Tout ce module réalisé avec le langage de programmation Python est développé et maintenu par David Larlet. Cette brique technologique est articulée autour du logiciel de transformation et de conversion Pandoc<a href="#fn12" class="footnote-ref" id="fnref12" role="doc-noteref"><sup>12</sup></a> déployée sur un serveur et rendue accessible via une autre API<a href="#fn13" class="footnote-ref" id="fnref13" role="doc-noteref"><sup>13</sup></a> fabriquée à partir de <em>framework</em> FastAPI<a href="#fn14" class="footnote-ref" id="fnref14" role="doc-noteref"><sup>14</sup></a>. Le module d’export intégré à Stylo<a href="#fn15" class="footnote-ref" id="fnref15" role="doc-noteref"><sup>15</sup></a> permet de convertir et transformer les textes sources en une multitude d’artefacts, selon les capacités de transformation et de conversion du logiciel Pandoc auquel il est soumis. Les développements autour des transformations des sources de Stylo seront traitées dans le prochain chapitre, nous les laissons donc de côté pour l’instant.</p>
 <p>[Faire un shéma de toute la pile techno de Stylo]</p>
+<p>Une description très générale des moyens de communication entre les différents modules qui composent Stylo nous montre déjà que l’information qui va être 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 mêmes de l’écriture à savoir les trois formats pivots d’un texte dans Stylo.</p>
 <h3 id="les-formats-pivots-de-stylo-en-détail">Les formats pivots de Stylo en détail</h3>
 <h4 id="la-sérialisation-des-métadonnées-en-yaml">La sérialisation des métadonnées en YAML</h4>
 <h4 id="lécriture-en-markdown">L’écriture en Markdown</h4>
 <h4 id="la-saisie-des-références-bibliographiques-en-bibtex">La saisie des références bibliographiques en BibTeX</h4>
-<h3 id="ce-que-stylo-permet-ou-non-de-faire">Ce que Stylo permet ou non de faire</h3>
+<h3 id="écrire-avec-stylo">Écrire avec Stylo</h3>
 <p>(Qu’est-ce que Stylo en tant qu’agent qui écrit ?) Dépassement du simple rapport de force énoncé précédemment (grâce à une transparence dans les actions de la machine et l’augmentation de la littératie numérique)</p>
+<p>Finalement, après la description de certains des mécanismes à l’oeuvre dans Stylo, nous sommes en droit de nous demander comment se déroule le geste d’écriture dans cet environnement ?</p>
+<p>Jusqu’à présent, nous savons que le texte est saisi par l’utilisateur en Markdown (YAML et BibTeX), 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 <code>POST</code> comme mode de communication. Entre ces étapes persiste une phase que nous n’avons pas encore évoqué : la requête <code>POST</code> envoyé au serveur ne s’effectue pas en continu entre le client et le serveur (ce n’est pas un flux). 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. Dans ce laps de temps, qu’advient-il du texte ?</p>
+<p>Comme cela est mentionné précédemment, l’espace d’écriture est un espace web. Pour y accéder il nous faut un logiciel particulier – un navigateur ou un fureteur – capable d’intpréter du HTML, du CSS et d’exécuter du Javascript. Lorsque l’on écrit dans Stylo (et 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’information. À 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é sur cet écran. Monaco travaille avec des modèles et ce sont avec ces modèles que l’utilisateur interagit. Chaque modèle est rattaché à une URI et c’est de cette manière que Monaco peut manipuler le DOM (<em>Document Object Model</em>) du navigateur pour créer le texte et son rendu graphique en texte brut.</p>
+<p>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 le DOM dépend du navigateur, nous pouvons en déduire que ce document sera différent selon le navigateur et la version du logiciel utilisée.</p>
+<p>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.</p>
+<p>Ci-dessous, une première pour montrer le texte saisi à l’écran et une deuxième pour montrer ce qui est écrit dans le DOM :</p>
+<figure>
+<img src="images/markdown-stylo.png" alt="Exemple de texte saisi en Markdown dans Stylo" />
+<figcaption aria-hidden="true">Exemple de texte saisi en Markdown dans Stylo</figcaption>
+</figure>
+<figure>
+<img src="images/html-dom.png" alt="DOM du texte saisi dans Stylo" />
+<figcaption aria-hidden="true">DOM du texte saisi dans Stylo</figcaption>
+</figure>
+<p>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 texte brut : la balise de titre de niveau 2 (##) n’a plus de valeur sémantique.</p>
+<p>Écrire dans un environnement comme Stylo ne consiste pas seulement en une simple saisie du texte à l’écran. Lorsque j’ai l’impression d’écrire au format Markdown, nous écrivons avec Stylo 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 :</p>
+<ul>
+<li>le texte saisi en Markdown</li>
+<li>la représentation du texte dans le DOM réalisé dans le navigateur par le biais de Monaco</li>
+<li>la requête GraphQL envoyée au serveur au format JSON</li>
+<li>l’état de sauvegarde sur le serveur dans la base de données MongoDB</li>
+</ul>
+<p>La seule saisie du texte dans Stylo nécessite en réalité une multitude d’étape intermédiaire cachée aux yeux de l’utilisateur mais que pourtant Stylo rédige et inscrit dans la mémoire numérique.</p>
+<p>Chacun de ces états à une signification particulière. Le premier 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 faire le chemin en sens inverse.</p>
+<p>Ces différents états du texte sont plus que de simples représentations, ce sont des documents différents et chacun a bien une signification qui lui est propre. Par exemple, la forme en Markdown brut ne peut pas circuler en l’état par le protocole HTTP, il lui manque toute une série d’informations : ce que Stylo écrit dans le texte.</p>
+<p>Parmi ces quatre document produits pour écrire, seulement une l’est par l’utilisateur, les autres formes sont écrites par Stylo.</p>
 <h2 id="conclusion-1">Conclusion</h2>
 <p>Dans ce chapitre, nous avons vu que …</p>
 <p>Nous avons vu que l’architexte n’est pas une entité à part, détachée de l’ordinateur, mais qu’il est l’ordinateur même et qu’il s’exprime/écrit sur son support à travers l’architexte, soit à travers un texte qui lui donne une série d’instructions sur comment lire et écrire.</p>
@@ -284,11 +368,17 @@ L'affichage de l'écriture à l'écran respecte des conventions de lecture propr
 <li id="fn2"><p>Cette machine a été conçue par Mario Bellini pour Olivetti en 1987, site consulté le 21 février 2024 https://www.moma.org/collection/works/3641<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
 <li id="fn3"><p>La première loi de Moore est relative à l’évolution des processeurs dans le temps et stipule que le nombre de transistors présent dans les processeurs doublera tous les ans pour un coût constant<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
 <li id="fn4"><p>Voir la page web correspondante sur le site d’Intel, consulté le 16 février 2024 : https://www.intel.fr/content/www/fr/fr/history/museum-story-of-intel-4004.html<a href="#fnref4" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn5"><p>L’<em>endpoint</em> de l’API GraphQl de Stylo est accessible ici : https://stylo.huma-num.fr/graphql<a href="#fnref5" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn6"><p>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.<a href="#fnref6" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn7"><p>La pandoc-api est accessible à cet <em>endpoint</em>: https://pandoc-api.stylo.huma-num.fr/<a href="#fnref7" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn8"><p>FastAPI est disponible à cette adresse: https://fastapi.tiangolo.com/<a href="#fnref8" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn9"><p>On peut trouver le module d’export à cette URL : https://export.stylo.huma-num.fr/<a href="#fnref9" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn5"><p>Voir le site web https://microsoft.github.io/monaco-editor/, consulté lw 29 février 2024.<a href="#fnref5" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn6"><p>L’<em>endpoint</em> de l’API GraphQl de Stylo est accessible ici : https://stylo.huma-num.fr/graphql<a href="#fnref6" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn7"><p>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 pour lequel il faut faire appel une deuxième fois ou plus au serveur pour en récupérer les données)<a href="#fnref7" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn8"><p>Le modélisation du schéma GraphQL est accessible sur le dépôt GitHub de Stylo à l’adresse suivante : https://github.com/EcrituresNumeriques/stylo/blob/master/graphql/models/user.js<a href="#fnref8" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn9"><p>Voir https://graphql.org/learn/serving-over-http/<a href="#fnref9" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn10"><p>Voir https://www.rfc-editor.org/rfc/rfc9110#name-introduction<a href="#fnref10" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn11"><p>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.<a href="#fnref11" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn12"><p>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.<a href="#fnref12" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn13"><p>La pandoc-api est accessible à cet <em>endpoint</em>: https://pandoc-api.stylo.huma-num.fr/<a href="#fnref13" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn14"><p>FastAPI est disponible à cette adresse: https://fastapi.tiangolo.com/<a href="#fnref14" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn15"><p>On peut trouver le module d’export à cette URL : https://export.stylo.huma-num.fr/<a href="#fnref15" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
 </ol>
 </section>
             </div>