diff options
Diffstat (limited to 'docs/posts')
| -rw-r--r-- | docs/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.html | 142 |
1 files changed, 73 insertions, 69 deletions
diff --git a/docs/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.html b/docs/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.html index 4f5b56e..a67148f 100644 --- a/docs/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.html +++ b/docs/posts/2024-05-06-la-saisie-du-texte-dans-un-nouveau-document.html @@ -129,8 +129,7 @@ Du fait de mon implication dans Stylo, le regard que je porte sur ce terrain n†<p>Le BIOS est donc l’interface entre l’utilisateur et la machine qui nous permet de manipuler les différentes entrées et sorties du système, donc de gérer les périphériques, fonction que le système d’exploitation peut également réaliser une fois que la phase d’amorçage est terminée. Le système d’exploitation (OS pour <em>Operating System</em>), est un niveau d’abstraction supplémentaire et se retrouve à l’interface entre les applications logicielles et la couche matérielle. Un OS est composé d’un ensemble de programmes permettant la bonne gestion des ressources de l’ordinateur : mémoires, calculs, périphériques, les registres, etc. Chaque OS a un fonctionnement qui lui est propre : l’architecture des informations – l’arborescence des dossiers, l’indexation des documents et des fichiers binaires change selon l’OS utilisé –, l’ordonnancement des tâches pour le processeur ou encore l’allocation de la mémoire, etc. Malgré le fait que ça n’ait pas toujours été le cas, les applications logicielles sont maintenant installées à l’intérieur des systèmes d’exploitation et prêtes à être exécutées. Le passage par un système d’exploitation permet aux logiciels de ne plus dépendre d’un modèle particulier du <em>hardware</em> et d’en faire justement abstraction, les rendant ainsi opérables sur différentes machines.</p> <p>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 sa mémoire, ni de pouvoir les consulter directement puisqu’elle lui est inaccessible à moins qu’un intermédiaire ne servent d’interface. La médiation entre une machine et un auteur se fait au moyen d’un langage compréhensible par les deux parties, que l’on assemble sous la forme d’instructions qui, une fois empaquetées, forment un logiciel. Pour symboliser la médiation du matériel par la mise en place du logiciel à l’interface de l’humain et de la machine, l’entreprise Microsoft emploie la métaphore de la fenêtre (<em>window(s)</em>) à travers laquelle l’usager voit le numérique, et donc l’ordinateur. Pourtant, il ne faut pas s’y méprendre, quelle que soit la fenêtre logicielle, elle ne permet d’accéder qu’à un certain nombre fini d’instructions. Alors qu’en tant qu’appareil programmable qui ne se souci pas de la signification du traitement des informations ni des résultats obtenus, l’ordinateur semble être un environnement beaucoup plus vaste que ce que cette fenêtre ne nous laisse croire <span class="citation" data-cites="turing_computable_1936">(Turing, 1936)</span>. Plutôt qu’une fenêtre comme ouverture ou passage vers le numérique, il serait plus juste de considérer cette fenêtre comme une vision du monde parmi d’autres. Cette vision du monde n’est pas seulement une vision particulière que l’humain a de la machine car dans ce cas nous serions dans un paradigme anthropocentré et utilitariste de la machine. En nous déplaçant de l’autre côté de la fenêtre, on se rend compte que la vision que porte la machine sur le monde est différente de la notre : la machine incarne une autre vision du monde sous forme de matrice, où chaque élément qu’elle perçoit l’est sous forme binaire. Le monde n’est alors plus que chiffres, calculs et distances, comme c’est le cas de la proposition de K. Hayles lorsqu’elle remplace Mère Nature par une Matrice <span class="citation" data-cites="hayles_my_2005">(Hayles, 2005)</span>.</p> <p>Un début de relation s’instaure entre l’humain et la machine grâce à l’entremise du logiciel. À travers cette interface, lorsque l’on touche une lettre du bout du doigt, la machine devient alors accessible et l’impulsion (électrique) que cette action génère se transforme en une lettre à l’écran. Pour autant, cette accessibilité est-elle synonyme de mise en visibilité ? Le fait que “ça marche” rendrait-il le document visible ? C’est le rôle de l’interface graphique et des métaphores qu’elle véhicule que de cacher le fonctionnement même de la machine <span class="citation" data-cites="jeanneret_y_2011">(Jeanneret, 2011)</span>. La déliaison convoquée par Bonaccorsi <span class="citation" data-cites="bonaccorsi_fantasmagories_2020">(Bonaccorsi, 2020)</span> prend place dès cet instant dans le processus d’écriture puisqu’il ne s’agit pas seulement de délier le geste de l’inscription mais également de faire abstraction de tout le processus d’écriture au-delà du geste. Ainsi, le logiciel aurait une double fonctionnalité : la première est une médiation qui ouvre le dialogue avec la machine tandis que la seconde en fait abstraction et la cache, ce qui a pour effet de rendre la machine quasiment invisible à l’utilisateur. Cependant, que découvrons-nous lorsque nous retirons ce voile devant la fenêtre ? Là se dévoile un vaste écosystème constitué de formats, des protocoles et leurs flux d’informations et de documents, parfois temporaires, voyageant d’une étape à une autre, prenant forme et se transformant pour suivre un cheminement prédéfini jusqu’à la création d’un document final que l’utilisateur récupère. Chacune de ces fenêtres offre finalement une vision particulière d’un document et un modèle épistémologique qui lui est propre <span class="citation" data-cites="vitali-rosati_editorialization_2018">(Vitali-Rosati, 2018)</span>.</p> -<p>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.</p> -<p>[détailler le prisme essentialiste en une phrase ou deux]</p> +<p>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<a href="#fn11" class="footnote-ref" id="fnref11" role="doc-noteref"><sup>11</sup></a>, 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.</p> <h2 id="une-médiation-par-lécrit">Une médiation par l’écrit</h2> <h3 id="le-logiciel-comme-architexte">Le logiciel comme architexte</h3> <p>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.</p> @@ -173,27 +172,27 @@ Du fait de mon implication dans Stylo, le regard que je porte sur ce terrain n†<p>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.</p> <p>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 <span class="citation" data-cites="bolter_remediation_1998">(Bolter & Grusin, 1998)</span> 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” <span class="citation" data-cites="herrenschmidt_trois_2023">(Herrenschmidt, 2023, p. 474)</span> , pour justement montrer à la fois l’opposition du logiciel avec l’aspect matériel (<em>hardware</em>) et marquer leur complémentarité : l’ordinateur (<em>hardware</em>) serait très peu accessible (voir inaccessible) sans logiciel, et le logiciel n’existe pas en dehors de l’ordinateur.</p> <p>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.</p> -<p>Un courant contemporain de la théorie des médias, l’intermédialité montréalaise<a href="#fn11" class="footnote-ref" id="fnref11" role="doc-noteref"><sup>11</sup></a> <span class="citation" data-cites="muller_lintermedialite_2000 tadier_tentative_2021 tadier__2021">(Müller, 2000; Tadier & Méchoulan, 2021;   Tadier, 2021)</span>, en tant qu’art pour penser les relations <span class="citation" data-cites="tadier__2021">(Tadier, 2021)</span>, 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.</p> -<p>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 <span class="citation" data-cites="bergin_origins_2006 kirschenbaum_track_2016 kittler_mode_2015">(Bergin, 2006a;   Kirschenbaum, 2016; F. A. Kittler, 2015)</span> 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 <em>progressive web apps</em> qui utilisent les technologies du web (HTML, CSS, JS) pour fonctionner et sont donc exécutables sur plus de supports puisqu’elles sont agnostiques<a href="#fn12" class="footnote-ref" id="fnref12" role="doc-noteref"><sup>12</sup></a> 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 <em>from scratch</em>, 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.</p> +<p>Un courant contemporain de la théorie des médias, l’intermédialité montréalaise<a href="#fn12" class="footnote-ref" id="fnref12" role="doc-noteref"><sup>12</sup></a> <span class="citation" data-cites="muller_lintermedialite_2000 tadier_tentative_2021 tadier__2021">(Müller, 2000; Tadier & Méchoulan, 2021;   Tadier, 2021)</span>, en tant qu’art pour penser les relations <span class="citation" data-cites="tadier__2021">(Tadier, 2021)</span>, peut être mobilisée pour mieux comprendre les liens entretenus par les agents de notre système, la machine avec elle-même, humain-machine, machine-machine.</p> +<p>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 <span class="citation" data-cites="bergin_origins_2006 kirschenbaum_track_2016 kittler_mode_2015">(Bergin, 2006a;   Kirschenbaum, 2016; F. A. Kittler, 2015)</span> 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 <em>progressive web apps</em> qui utilisent les technologies du web (HTML, CSS, JS) pour fonctionner et sont donc exécutables sur plus de supports puisqu’elles sont agnostiques<a href="#fn13" class="footnote-ref" id="fnref13" role="doc-noteref"><sup>13</sup></a> 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 <em>from scratch</em>, 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.</p> <p>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).</p> <p>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.</p> <p>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 <span class="citation" data-cites="mcluhan_pour_1977">(1977)</span>, l’on pourrait percevoir les logiciels comme des espaces construits – des architectures de l’information <span class="citation" data-cites="broudoux_larchitecture_2013">(Broudoux et al., 2013)</span> 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.</p> <p>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.</p> -<p>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.</p> +<p>En prenant le cas de Stylo, nous pouvons détailler ce que désigne cette appellation 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.</p> <p>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. Le Web fonctionne différemment d’un environnement local sur son ordinateur personnel.</p> -<p>[Faire l’historique du Web en deux phrases, citer les spec du W3C et de HTML jusqu’à HTML5]</p> +<p>Alain Mille en dresse l’histoire depuis les débuts d’Internet dans les années 1960 <span class="citation" data-cites="mille_internet_2014">(2014)</span> à partir du réseau filaire ARPAnet …</p> <p>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 <em>client</em> – ce qui est affiché dans le navigateur – et la partie <em>serveur</em>, soit la base de données. Dans notre cas, nous allons scinder l’ architecture logicielle de Stylo en trois parties.</p> <figure> <img src="https://s3.hedgedoc.org/demo/uploads/afdf01ec-bd0b-4b38-8394-752d6e2d1e4b.png" title="Les différents modules de Stylo" alt="Les différents modules de Stylo" /> <figcaption aria-hidden="true">Les différents modules de Stylo</figcaption> </figure> <p>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.</p> -<p>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<a href="#fn13" class="footnote-ref" id="fnref13" role="doc-noteref"><sup>13</sup></a> déployée sur un serveur et rendue accessible via une autre API<a href="#fn14" class="footnote-ref" id="fnref14" role="doc-noteref"><sup>14</sup></a> fabriquée à partir du framework FastAPI<a href="#fn15" class="footnote-ref" id="fnref15" role="doc-noteref"><sup>15</sup></a>. Le module d’export intégré à Stylo<a href="#fn16" class="footnote-ref" id="fnref16" role="doc-noteref"><sup>16</sup></a> 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é.</p> +<p>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<a href="#fn14" class="footnote-ref" id="fnref14" role="doc-noteref"><sup>14</sup></a> déployée sur un serveur et rendue accessible via une autre API<a href="#fn15" class="footnote-ref" id="fnref15" role="doc-noteref"><sup>15</sup></a> fabriquée à partir du framework FastAPI<a href="#fn16" class="footnote-ref" id="fnref16" role="doc-noteref"><sup>16</sup></a>. Le module d’export intégré à Stylo<a href="#fn17" class="footnote-ref" id="fnref17" role="doc-noteref"><sup>17</sup></a> 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é.</p> <p>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 <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 faire les différents composants de l’interface et intégrer de nombreuses librairies telle que <em>i18n</em> qui permet d’implémenter le multilinguisme dans l’interface et changer la langue affichée à l’écran en un seul clic.</p> -<p>L’éditeur de texte, pièce maîtresse de Stylo, s’appuie sur la technologie Monaco<a href="#fn17" class="footnote-ref" id="fnref17" role="doc-noteref"><sup>17</sup></a> développé par Microsoft et rendu disponible sous licence MIT.</p> -<p>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 (<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 Transfert Protocol</em>)<a href="#fn18" class="footnote-ref" id="fnref18" role="doc-noteref"><sup>18</sup></a>, 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 <em>open source</em> en 2015.</p> -<p>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 (<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="#fn19" class="footnote-ref" id="fnref19" role="doc-noteref"><sup>19</sup></a> 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, <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="#fn20" class="footnote-ref" id="fnref20" role="doc-noteref"><sup>20</sup></a> :</p> +<p>L’éditeur de texte, pièce maîtresse de Stylo, s’appuie sur la technologie Monaco<a href="#fn18" class="footnote-ref" id="fnref18" role="doc-noteref"><sup>18</sup></a> développé par Microsoft et rendu disponible sous licence MIT.</p> +<p>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 (<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 Transfert Protocol</em>)<a href="#fn19" class="footnote-ref" id="fnref19" role="doc-noteref"><sup>19</sup></a>, 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 <em>open source</em> en 2015.</p> +<p>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 (<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="#fn20" class="footnote-ref" id="fnref20" role="doc-noteref"><sup>20</sup></a> 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, <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="#fn21" class="footnote-ref" id="fnref21" role="doc-noteref"><sup>21</sup></a> :</p> <ul> <li>_id</li> <li>displayName</li> @@ -233,13 +232,13 @@ Du fait de mon implication dans Stylo, le regard que je porte sur ce terrain n†<span id="cb2-6"><a href="#cb2-6" aria-hidden="true" tabindex="-1"></a> }</span> <span id="cb2-7"><a href="#cb2-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 ce principe.</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. Le protocole HTTP comporte 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="#fn21" class="footnote-ref" id="fnref21" role="doc-noteref"><sup>21</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>, 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 <code>POST</code> 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.</p> -<p>Les spécificités du protocoles HTTP sont définies dans les <em>Request for Comments</em> (RFC) publiés par l’<em>Internet Engineering Task Force</em> (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 <code>POST</code> est le 9110<a href="#fn22" class="footnote-ref" id="fnref22" role="doc-noteref"><sup>22</sup></a> publié en juin 2022.</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. Le protocole HTTP comporte 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="#fn22" class="footnote-ref" id="fnref22" role="doc-noteref"><sup>22</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>, 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 <code>POST</code> 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.</p> +<p>Les spécificités du protocoles HTTP sont définies dans les <em>Request for Comments</em> (RFC) publiés par l’<em>Internet Engineering Task Force</em> (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 <code>POST</code> est le 9110<a href="#fn23" class="footnote-ref" id="fnref23" role="doc-noteref"><sup>23</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="#fn23" class="footnote-ref" id="fnref23" role="doc-noteref"><sup>23</sup></a></p> +<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="#fn24" class="footnote-ref" id="fnref24" role="doc-noteref"><sup>24</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 relatif à 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 contenus 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>À travers cette brève définition, l’on remarque que l’usage principal de la méthode <code>POST</code> est plutôt relatif à 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 contenus 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 idempotente<a href="#fn25" class="footnote-ref" id="fnref25" role="doc-noteref"><sup>25</sup></a>, 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. Au contraire, une méthode idempotente comme <code>PUT</code> ou <code>DELETE</code> aurait le même effet du côté du serveur et cela quel que soit le nombre de fois que cette requête lui aura été envoyée : une ressource supprimée ne le sera qu’une fois.</p> <p>Cependant, cette caractéristique tend à disparaître dans le cas de l’utilisation de <code>POST</code> 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, <code>POST</code> est donc soumis à l’architecture GraphQL, on peut donc 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. 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="cb3"><pre class="sourceCode json"><code class="sourceCode json"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="fu">{</span><span class="dt">"query"</span><span class="fu">:</span><span class="st">"query updateWorkingVersion(articleId: ID!, $content:</span></span> @@ -254,8 +253,8 @@ Du fait de mon implication dans Stylo, le regard que je porte sur ce terrain n†<span id="cb3-10"><a href="#cb3-10" aria-hidden="true" tabindex="-1"></a><span class="dt">"variables"</span><span class="fu">:{</span><span class="dt">"userId"</span><span class="fu">:</span><span class="st">"61d62....."</span><span class="fu">,</span></span> <span id="cb3-11"><a href="#cb3-11" aria-hidden="true" tabindex="-1"></a><span class="dt">"articleId"</span><span class="fu">:</span><span class="st">"65e0e38129637c0012ef7a"</span><span class="fu">,</span></span> <span id="cb3-12"><a href="#cb3-12" aria-hidden="true" tabindex="-1"></a><span class="dt">"content"</span><span class="fu">:{</span><span class="dt">"md"</span><span class="fu">:</span><span class="st">"Ajout du texte pour la requête HTTP 'POST'"</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 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.</p> -<p>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.</p> +<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 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. Cette préconstruction est la vision du document incarnée dans Stylo. Puisqu’il y a une pré-construction du document et du texte, nous pouvons à ce stade présupposer qu’il y a une pré-construction des traces des interactions avec l’utilisateur et de l’intimité qui en résulte et se matérialise dans des fragments comme celui présenté ci-dessus.</p> +<p>Cette 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.</p> <h3 id="les-formats-déterminent-la-sémantique-du-texte">Les formats déterminent la sémantique du texte</h3> <p>[Trouver quelques références sur les formats, ex la these de de Mourat sur le vacillement des formats]</p> <p>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.</p> @@ -281,18 +280,18 @@ Du fait de mon implication dans Stylo, le regard que je porte sur ce terrain n†<p>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é ?).</p> <p>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.</p> <p>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.</p> -<p>Mardown est un langage de balisage léger créé en 2004 par John Gruber<a href="#fn24" class="footnote-ref" id="fnref24" role="doc-noteref"><sup>24</sup></a>. 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 :</p> +<p>Mardown est un langage de balisage léger créé en 2004 par John Gruber<a href="#fn26" class="footnote-ref" id="fnref26" role="doc-noteref"><sup>26</sup></a>. 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 :</p> <ul> -<li>CommonMark<a href="#fn25" class="footnote-ref" id="fnref25" role="doc-noteref"><sup>25</sup></a></li> -<li>GitHub Flavored Markdown (GFM)<a href="#fn26" class="footnote-ref" id="fnref26" role="doc-noteref"><sup>26</sup></a></li> -<li>MultiMarkdown<a href="#fn27" class="footnote-ref" id="fnref27" role="doc-noteref"><sup>27</sup></a></li> -<li>Pandoc<a href="#fn28" class="footnote-ref" id="fnref28" role="doc-noteref"><sup>28</sup></a></li> -<li>Quarto<a href="#fn29" class="footnote-ref" id="fnref29" role="doc-noteref"><sup>29</sup></a></li> +<li>CommonMark<a href="#fn27" class="footnote-ref" id="fnref27" role="doc-noteref"><sup>27</sup></a></li> +<li>GitHub Flavored Markdown (GFM)<a href="#fn28" class="footnote-ref" id="fnref28" role="doc-noteref"><sup>28</sup></a></li> +<li>MultiMarkdown<a href="#fn29" class="footnote-ref" id="fnref29" role="doc-noteref"><sup>29</sup></a></li> +<li>Pandoc<a href="#fn30" class="footnote-ref" id="fnref30" role="doc-noteref"><sup>30</sup></a></li> +<li>Quarto<a href="#fn31" class="footnote-ref" id="fnref31" role="doc-noteref"><sup>31</sup></a></li> </ul> <p>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.</p> <p>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.</p> <div class="sourceCode" id="cb5"><pre class="sourceCode md"><code class="sourceCode markdown"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a>{{< video https://www.youtube.com/embed/wo9vZccmqwc >}}</span></code></pre></div> -<p>À 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<a href="#fn30" class="footnote-ref" id="fnref30" role="doc-noteref"><sup>30</sup></a>.</p> +<p>À 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<a href="#fn32" class="footnote-ref" id="fnref32" role="doc-noteref"><sup>32</sup></a>.</p> <p>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.</p> <p>La sérialisation des métadonnées est réalisée en YAML qui, dans sa version originale de 2004 est l’acronyme de <em>Yet Another Markup Language</em> puis se transforme à l’occasion de la publication de sa version 1.1 en <em>YAML Ain’t Markup Language</em>. 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 <code>clef: valeur</code>. Chaque utilisateur a la possibilité de créer de toute pièce son document YAML et de choisir les <code>clefs</code> et les <code>valeurs</code> qui leur sont associées. C’est ensuite l’application qui va parser le contenu en suivant l’architecture des informations. Dans Stylo, les <code>clefs</code> 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 <code>valeurs</code> qui seront associées aux différentes <code>clefs</code> – un mode permet d’accéder au contenu en YAML brut sans surcouche graphique.</p> <p>Si nous reprenons l’exemple de l’auteur mentionné précédemment, un auteur est déclaré comme suit dans Stylo :</p> @@ -308,22 +307,22 @@ Du fait de mon implication dans Stylo, le regard que je porte sur ce terrain n†<span id="cb6-10"><a href="#cb6-10" aria-hidden="true" tabindex="-1"></a><span class="at"> </span><span class="fu">viaf</span><span class="kw">:</span><span class="at"> </span><span class="st">''</span></span> <span id="cb6-11"><a href="#cb6-11" aria-hidden="true" tabindex="-1"></a><span class="at"> </span><span class="fu">wikidata</span><span class="kw">:</span><span class="at"> </span><span class="st">''</span></span></code></pre></div> <p>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 <code>affiliations</code> 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.</p> -<p>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 (<em>JavaScript Object Notation</em>) publié pour la première fois en 1999<a href="#fn31" class="footnote-ref" id="fnref31" role="doc-noteref"><sup>31</sup></a>, 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<a href="#fn32" class="footnote-ref" id="fnref32" role="doc-noteref"><sup>32</sup></a>, 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<a href="#fn33" class="footnote-ref" id="fnref33" role="doc-noteref"><sup>33</sup></a> où nous pouvons y lire :</p> +<p>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 (<em>JavaScript Object Notation</em>) publié pour la première fois en 1999<a href="#fn33" class="footnote-ref" id="fnref33" role="doc-noteref"><sup>33</sup></a>, 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<a href="#fn34" class="footnote-ref" id="fnref34" role="doc-noteref"><sup>34</sup></a>, 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<a href="#fn35" class="footnote-ref" id="fnref35" role="doc-noteref"><sup>35</sup></a> où nous pouvons y lire :</p> <blockquote> <p>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.</p> </blockquote> -<p>Le changement de version génère une modification de comportement des valeurs <code>y, yes, on</code> qui signifiaient le booléen <code>true</code> 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<a href="#fn34" class="footnote-ref" id="fnref34" role="doc-noteref"><sup>34</sup></a>, 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.</p> -<p>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<a href="#fn35" class="footnote-ref" id="fnref35" role="doc-noteref"><sup>35</sup></a> 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<a href="#fn36" class="footnote-ref" id="fnref36" role="doc-noteref"><sup>36</sup></a>.</p> -<p>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<a href="#fn37" class="footnote-ref" id="fnref37" role="doc-noteref"><sup>37</sup></a> ou eBib<a href="#fn38" class="footnote-ref" id="fnref38" role="doc-noteref"><sup>38</sup></a>.</p> -<p>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 <code>@misc</code> pour « tout autre type de document ». Il en va de même pour les informations rattachées à chaque type de données<a href="#fn39" class="footnote-ref" id="fnref39" role="doc-noteref"><sup>39</sup></a> : selon les disciplines ou 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 <code>Extra</code> pour ajouter une information supplémentaire sous la forme de chaîne de caractères sans avoir de structure explicite.</p> -<p>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 : <code>langid</code> et <code>language</code>. <code>langid</code> permet initialement d’identifier la langue à appliquer à l’entrée (comme traitement) et <code>language</code> 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 <code>language</code> et pas <code>langid</code>, <code>language</code> combinant les deux objets. En récupérant les références bibliographiques depuis Zotero, Stylo récupère seulement le paramètre <code>language</code> puisque le paramètre <code>langid</code> 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<a href="#fn40" class="footnote-ref" id="fnref40" role="doc-noteref"><sup>40</sup></a> 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<a href="#fn41" class="footnote-ref" id="fnref41" role="doc-noteref"><sup>41</sup></a> 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.</p> +<p>Le changement de version génère une modification de comportement des valeurs <code>y, yes, on</code> qui signifiaient le booléen <code>true</code> 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<a href="#fn36" class="footnote-ref" id="fnref36" role="doc-noteref"><sup>36</sup></a>, 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.</p> +<p>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<a href="#fn37" class="footnote-ref" id="fnref37" role="doc-noteref"><sup>37</sup></a> 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<a href="#fn38" class="footnote-ref" id="fnref38" role="doc-noteref"><sup>38</sup></a>.</p> +<p>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<a href="#fn39" class="footnote-ref" id="fnref39" role="doc-noteref"><sup>39</sup></a> ou eBib<a href="#fn40" class="footnote-ref" id="fnref40" role="doc-noteref"><sup>40</sup></a>.</p> +<p>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 <code>@misc</code> pour « tout autre type de document ». Il en va de même pour les informations rattachées à chaque type de données<a href="#fn41" class="footnote-ref" id="fnref41" role="doc-noteref"><sup>41</sup></a> : selon les disciplines ou 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 <code>Extra</code> pour ajouter une information supplémentaire sous la forme de chaîne de caractères sans avoir de structure explicite.</p> +<p>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 : <code>langid</code> et <code>language</code>. <code>langid</code> permet initialement d’identifier la langue à appliquer à l’entrée (comme traitement) et <code>language</code> 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 <code>language</code> et pas <code>langid</code>, <code>language</code> combinant les deux objets. En récupérant les références bibliographiques depuis Zotero, Stylo récupère seulement le paramètre <code>language</code> puisque le paramètre <code>langid</code> 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<a href="#fn42" class="footnote-ref" id="fnref42" role="doc-noteref"><sup>42</sup></a> 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<a href="#fn43" class="footnote-ref" id="fnref43" role="doc-noteref"><sup>43</sup></a> 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.</p> <p>Le choix des formats dans lesquels les utilisateurs peuvent saisir leurs textes et leurs données n’est pas anodin. Qu’il soit ancien, récent, verbeux ou léger, permissif ou rigide, le format d’écriture conditionne ce que l’on a le droit d’écrire ou non. En ce sens la décision de ce qui peut être saisi est déjà prise avant qu’un texte soit frappé sur le clavier. Par exemple, dans Stylo, le Markdown ne permet pas à un philologue de saisir explicitement un appareil critique. C’est une syntaxe qui n’existe pas alors que c’est le cas pour d’autre environnements comme LaTeX et le paquet <a href="http://www.ekdosis.org/"><code>ekdosis</code></a> développé et maintenu par Robert Alessi. Dans ce cas-ci, puisque l’appareil critique n’existe pas en Markdown, il ne peut pas exister dans Stylo sauf si l’utilisateur fait abstraction du format et qu’il change de paradigme pour celui de la page et de la représentation graphique. En faisant cela, l’utilisateur fait également abstraction de la machine et de ce qu’elle peut interpréter du contenu puis écrire dans le texte. Lorsque nous sommes dans un environnement mis à disposition comme Stylo, le risque est que celui-ci ne soit pas complètement adapté à des besoins ou à une intention. Il risque d’y avoir une friction entre les formats imposés par l’environnement et les besoins en écriture.</p> <h3 id="co-écriture-entre-les-agents">Co-écriture entre les agents</h3> <p>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).</p> <p>Si l’on s’arrête à la vision superficielle du texte, comme le propose J. Goody avec la raison graphique <span class="citation" data-cites="goody_raison_1979">(Goody, 1979)</span>, 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.</p> -<p>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 <span class="citation" data-cites="tufte_cognitive_2003">(2003)</span> 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. » <a href="#fn42" class="footnote-ref" id="fnref42" role="doc-noteref"><sup>42</sup></a> notamment parce qu’il « facilite activement la réalisation de présentation légère »<a href="#fn43" class="footnote-ref" id="fnref43" role="doc-noteref"><sup>43</sup></a>. À 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 <em>templates</em> 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 <span class="citation" data-cites="bachimont_intelligence_2000">(2000)</span>.</p> +<p>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 <span class="citation" data-cites="tufte_cognitive_2003">(2003)</span> 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. » <a href="#fn44" class="footnote-ref" id="fnref44" role="doc-noteref"><sup>44</sup></a> notamment parce qu’il « facilite activement la réalisation de présentation légère »<a href="#fn45" class="footnote-ref" id="fnref45" role="doc-noteref"><sup>45</sup></a>. À 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 <em>templates</em> 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 <span class="citation" data-cites="bachimont_intelligence_2000">(2000)</span>.</p> <p>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.</p> -<p>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 <code>WP</code> signifiaient WordPerfect<a href="#fn44" class="footnote-ref" id="fnref44" role="doc-noteref"><sup>44</sup></a>, et que la plupart des autres concurrents employaient également le mot <em>word</em> 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<a href="#fn45" class="footnote-ref" id="fnref45" role="doc-noteref"><sup>45</sup></a> mais compatible ne veut pas dire identique. En plus de n’être accessible que <strong>sous</strong> MacOS, cette page ne l’est également que <strong>sous</strong> Pages : cette formulation courante laisse entendre que l’utilisateur devient alors sujet de son environnement d’écriture, nous dit F. Kittler <span class="citation" data-cites="kittler_mode_2015">(2015)</span>.</p> +<p>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 <code>WP</code> signifiaient WordPerfect<a href="#fn46" class="footnote-ref" id="fnref46" role="doc-noteref"><sup>46</sup></a>, et que la plupart des autres concurrents employaient également le mot <em>word</em> 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<a href="#fn47" class="footnote-ref" id="fnref47" role="doc-noteref"><sup>47</sup></a> mais compatible ne veut pas dire identique. En plus de n’être accessible que <strong>sous</strong> MacOS, cette page ne l’est également que <strong>sous</strong> Pages : cette formulation courante laisse entendre que l’utilisateur devient alors sujet de son environnement d’écriture, nous dit F. Kittler <span class="citation" data-cites="kittler_mode_2015">(2015)</span>.</p> <p>Cette position kittlerienne, que l’on peut qualifier d’essentialiste, pose les fondations des travaux de K. Hayles <span class="citation" data-cites="hayles_my_2005">(Hayles, 2005)</span>, du posthumanisme, et du nouveau matérialisme, courants dans lesquels s’inscrivent en outre les travaux de K. Barad <span class="citation" data-cites="barad_meeting_2007 barad_frankenstein_2023">(2007, 2023)</span> et ceux de M. Vitali-Rosati <span class="citation" data-cites="vitali-rosati_pour_2021">(2021)</span>. 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 <em>avant</em> 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 <em>worldview</em> ches K. Hayles, où Mère Nature devient une Matrice (<em>My Mother was a Computer</em>), l’<em>intra-action</em> à la place d’interaction puisque les agents ne sont pas prédéterminés chez K. Barad et enfin l’<em>éditorialisation</em> 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 <span class="citation" data-cites="vitali-rosati_media_2019">(Vitali-Rosati & Larrue, 2019)</span>.</p> <p>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.</p> <p>Néanmoins, un trouble persiste dans cette relation entre ces agents. Il se manifeste entre ce que l’usager à l’intention d’écrire et le document que produit la machine, qui est structuré selon un certains nombre de normes, formats, etc., implémentés dans un logiciel. 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. En ce sens, nous examinons la possibilité que l’écriture numérique puisse être affublée d’une caractéristique supplémentaire : la cécité. Cette caractéristique nous semble présente dans le fait qu’il y ait plusieurs angles morts entre ces deux conceptions du texte qui ne permettent ni à l’utilisateur ni à la machine de voir le texte dans sa totalité. La piste de ce trouble nous mène également à comprendre l’enjeu de cette relation entre l’usager et son environnement puisque. En le dévoilant, nous mettrons à jour les indices de la rencontre entre un auteur et son environnement d’écriture.</p> @@ -351,7 +350,7 @@ Du fait de mon implication dans Stylo, le regard que je porte sur ce terrain n†<p>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.</p> <p>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.</p> <p>Parmi ces quatre documents produits pour écrire, un seul l’est par l’utilisateur tandis que les autres formes sont écrites par Stylo.</p> -<p>É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 <strong>déprise</strong> sur le texte, au sens que lui donnait Louise Merzeau <span class="citation" data-cites="sauret_revue_2020">(Sauret, 2020)</span><a href="#fn46" class="footnote-ref" id="fnref46" role="doc-noteref"><sup>46</sup></a>.</p> +<p>É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 <strong>déprise</strong> sur le texte, au sens que lui donnait Louise Merzeau <span class="citation" data-cites="sauret_revue_2020">(Sauret, 2020)</span><a href="#fn48" class="footnote-ref" id="fnref48" role="doc-noteref"><sup>48</sup></a>.</p> <blockquote> <p>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.</p> </blockquote> @@ -450,6 +449,9 @@ McLuhan, M. (1977). <em><span>Pour comprendre les m<span>é</span>dias</span></e <div id="ref-merzeau_editorialisation_2013" class="csl-entry" role="listitem"> Merzeau, L. (2013). <span>É</span>ditorialisation Collaborative d’un <span>É</span>v<span>é</span>nement. <em>Communication et organisation</em>, <em>43</em>, 105‑122. <a href="https://doi.org/10.4000/communicationorganisation.4158">https://doi.org/10.4000/communicationorganisation.4158</a> </div> +<div id="ref-mille_internet_2014" class="csl-entry" role="listitem"> +Mille, A. (2014). <span>D’Internet au web</span>. In <em><span>Pratiques de l’<span>é</span>dition num<span>é</span>rique</span></em>. Les Ateliers de [sens public]. +</div> <div id="ref-muller_lintermedialite_2000" class="csl-entry" role="listitem"> Müller, J. (2000). <span>L’interm<span>é</span>dialit<span>é</span>, une nouvelle approche interdisciplinaire : perspectives th<span>é</span>oriques et pratiques <span>à </span> l’exemple de la vision de la t<span>é</span>l<span>é</span>vision</span>. <em>Cin<span>é</span>mas : revue d’<span>é</span>tudes cin<span>é</span>matographiques / Cin<span>é</span>mas: Journal of Film Studies</em>, <em>10</em>(2-3), 105‑134. <a href="https://doi.org/10.7202/024818ar">https://doi.org/10.7202/024818ar</a> </div> @@ -515,42 +517,44 @@ Zacklad, M. (2019). <span>Le design de l’information : textualisation, documen <li id="fn8"><p>Voir le site web de Libreboot : https://libreboot.org/, consulté le 03 avril 2024.<a href="#fnref8" class="footnote-back" role="doc-backlink">↩︎</a></p></li> <li id="fn9"><p>Voir le site web de Coreboot : https://www.coreboot.org/, consulté le 03 avril 2024.<a href="#fnref9" class="footnote-back" role="doc-backlink">↩︎</a></p></li> <li id="fn10"><p>Des informations sur ce sujet sont disponibles à cette adresse sur le site web de libreboot : https://libreboot.org/faq.html#what-systems-are-compatible-with-libreboot ou dans la documentation des matériels d’Intel : https://www.intel.com/content/www/us/en/search.html?ws=idsa-default#q=boot%20guard&sort=relevancy&f:<span class="citation" data-cites="tabfilter">(<strong>tabfilter?</strong>)</span>=[Developers], consultés le 03 avril 2024.<a href="#fnref10" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn11"><p>Le chapitre 1 devra décrire l’intermédialité montréalaise, il faudra ajouter un renvoi ici<a href="#fnref11" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn12"><p>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é.<a href="#fnref12" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn13"><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="#fnref13" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn14"><p>La pandoc-api est accessible à cet <em>endpoint</em> : https://pandoc-api.stylo.huma-num.fr/<a href="#fnref14" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn15"><p>FastAPI est disponible à cette adresse : https://fastapi.tiangolo.com/, consulté le 24 février 2024.<a href="#fnref15" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn16"><p>On peut trouver le module d’export à cette URL : https://export.stylo.huma-num.fr/<a href="#fnref16" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn17"><p>Voir le site web dédié à l’éditeur Monaco : https://microsoft.github.io/monaco-editor/, consulté le 29 février 2024.<a href="#fnref17" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn18"><p>L’<em>endpoint</em> de l’API GraphQL de Stylo est accessible ici : https://stylo.huma-num.fr/graphql.<a href="#fnref18" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn19"><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 pallié par un deuxième appel ou plus au serveur pour compléter le besoin.<a href="#fnref19" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn20"><p>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<a href="#fnref20" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn21"><p>Voir https://graphql.or/learn/serving-over-http/, consulté le 24 février 2024.<a href="#fnref21" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn22"><p>Voir la page web https://www.rfc-editor.org/rfc/rfc9110#name-introduction, consultée le 24 février 2024.<a href="#fnref22" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn23"><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="#fnref23" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn24"><p>Voir son site web, consulté le 31 mars 2024 : https://daringfireball.net/projects/markdown/<a href="#fnref24" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn25"><p>Les spécificités de CommonMark sont disponibles sur le site web dédié à cette saveur : https://commonmark.org/, consulté le 31 mars 2024.<a href="#fnref25" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn26"><p>Celles de GFM sont disponibles sur cette page web : https://github.github.com/gfm/, consultée le 31 mars 2024.<a href="#fnref26" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn27"><p>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.<a href="#fnref27" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn28"><p>Celles de Pandoc sont disponibles sur cette page web : https://pandoc.org/MANUAL.html#pandocs-markdown, consultée le 31 mars 2024.<a href="#fnref28" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn29"><p>Celles de Quarto sont disponibles sur cette page web : https://quarto.org/docs/authoring/markdown-basics.html, consultée le 31 mars 2024.<a href="#fnref29" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn30"><p>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.<a href="#fnref30" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn31"><p>Voir le site web de JSON : https://www.json.org/json-en.html, consulté le 31 mars 2024.<a href="#fnref31" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn32"><p>Voir le blog de Ruud van Asseldonk : https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell, consulté le 31 mars 2024.<a href="#fnref32" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn33"><p>Voir la page des <em>releases</em> de Pandoc : https://pandoc.org/releases.html#pandoc-2.2.2-2018-07-16, consultée le 31 mars 2024.<a href="#fnref33" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn34"><p>Voir la page web de la librairie : https://pypi.org/project/PyYAML/, consultée le 31 mars 2024.<a href="#fnref34" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn35"><p>Voir le site web du langage TOML : https://toml.io/en/, consulté le 31 mars 2024.<a href="#fnref35" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn36"><p>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.<a href="#fnref36" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn37"><p>Zotero est un logiciel de gestion de références bibliographiques très connu, il est l’alternative libre et <em>open source</em> à Mendeley, voir le site web de Zotero : https://www.zotero.org/, consulté le 31 mars 2024.<a href="#fnref37" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn38"><p>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.<a href="#fnref38" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn39"><p>cf. le tableau des champs accolés aux types de documents en annexe.<a href="#fnref39" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn40"><p>Voir la discussion sur GitHub : https://github.com/EcrituresNumeriques/stylo/pull/991, consultée le 31 mars 2024.<a href="#fnref40" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn41"><p>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.<a href="#fnref41" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn42"><p>Traduction personnelle : […] routinely disrupts, dominates, and trivializes content.<a href="#fnref42" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn43"><p>Traduction personnelle : actively facilitates the making of lightweight presentations.<a href="#fnref43" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn44"><p>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.<a href="#fnref44" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn45"><p>Voir le site web, consulté le 21 mars 2024 : https://www.apple.com/pages/compatibility/<a href="#fnref45" class="footnote-back" role="doc-backlink">↩︎</a></p></li> -<li id="fn46"><p>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.<a href="#fnref46" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn11"><p>Cette dimension essentialiste propre à l’interaction est détaillée dans le chapitre 1 (ajouter lien)<a href="#fnref11" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn12"><p>Le chapitre 1 devra décrire l’intermédialité montréalaise, il faudra ajouter un renvoi ici<a href="#fnref12" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn13"><p>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é.<a href="#fnref13" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn14"><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="#fnref14" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn15"><p>La pandoc-api est accessible à cet <em>endpoint</em> : https://pandoc-api.stylo.huma-num.fr/<a href="#fnref15" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn16"><p>FastAPI est disponible à cette adresse : https://fastapi.tiangolo.com/, consulté le 24 février 2024.<a href="#fnref16" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn17"><p>On peut trouver le module d’export à cette URL : https://export.stylo.huma-num.fr/<a href="#fnref17" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn18"><p>Voir le site web dédié à l’éditeur Monaco : https://microsoft.github.io/monaco-editor/, consulté le 29 février 2024.<a href="#fnref18" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn19"><p>L’<em>endpoint</em> de l’API GraphQL de Stylo est accessible ici : https://stylo.huma-num.fr/graphql.<a href="#fnref19" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn20"><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 pallié par un deuxième appel ou plus au serveur pour compléter le besoin.<a href="#fnref20" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn21"><p>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<a href="#fnref21" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn22"><p>Voir https://graphql.or/learn/serving-over-http/, consulté le 24 février 2024.<a href="#fnref22" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn23"><p>Voir la page web https://www.rfc-editor.org/rfc/rfc9110#name-introduction, consultée le 24 février 2024.<a href="#fnref23" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn24"><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="#fnref24" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn25"><p>L’idempotence signifie qu’une opération a le même effet et cela quel que soit le nombre d’application.<a href="#fnref25" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn26"><p>Voir son site web, consulté le 31 mars 2024 : https://daringfireball.net/projects/markdown/<a href="#fnref26" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn27"><p>Les spécificités de CommonMark sont disponibles sur le site web dédié à cette saveur : https://commonmark.org/, consulté le 31 mars 2024.<a href="#fnref27" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn28"><p>Celles de GFM sont disponibles sur cette page web : https://github.github.com/gfm/, consultée le 31 mars 2024.<a href="#fnref28" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn29"><p>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.<a href="#fnref29" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn30"><p>Celles de Pandoc sont disponibles sur cette page web : https://pandoc.org/MANUAL.html#pandocs-markdown, consultée le 31 mars 2024.<a href="#fnref30" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn31"><p>Celles de Quarto sont disponibles sur cette page web : https://quarto.org/docs/authoring/markdown-basics.html, consultée le 31 mars 2024.<a href="#fnref31" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn32"><p>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.<a href="#fnref32" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn33"><p>Voir le site web de JSON : https://www.json.org/json-en.html, consulté le 31 mars 2024.<a href="#fnref33" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn34"><p>Voir le blog de Ruud van Asseldonk : https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell, consulté le 31 mars 2024.<a href="#fnref34" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn35"><p>Voir la page des <em>releases</em> de Pandoc : https://pandoc.org/releases.html#pandoc-2.2.2-2018-07-16, consultée le 31 mars 2024.<a href="#fnref35" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn36"><p>Voir la page web de la librairie : https://pypi.org/project/PyYAML/, consultée le 31 mars 2024.<a href="#fnref36" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn37"><p>Voir le site web du langage TOML : https://toml.io/en/, consulté le 31 mars 2024.<a href="#fnref37" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn38"><p>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.<a href="#fnref38" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn39"><p>Zotero est un logiciel de gestion de références bibliographiques très connu, il est l’alternative libre et <em>open source</em> à Mendeley, voir le site web de Zotero : https://www.zotero.org/, consulté le 31 mars 2024.<a href="#fnref39" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn40"><p>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.<a href="#fnref40" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn41"><p>cf. le tableau des champs accolés aux types de documents en annexe.<a href="#fnref41" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn42"><p>Voir la discussion sur GitHub : https://github.com/EcrituresNumeriques/stylo/pull/991, consultée le 31 mars 2024.<a href="#fnref42" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn43"><p>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.<a href="#fnref43" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn44"><p>Traduction personnelle : […] routinely disrupts, dominates, and trivializes content.<a href="#fnref44" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn45"><p>Traduction personnelle : actively facilitates the making of lightweight presentations.<a href="#fnref45" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn46"><p>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.<a href="#fnref46" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn47"><p>Voir le site web, consulté le 21 mars 2024 : https://www.apple.com/pages/compatibility/<a href="#fnref47" class="footnote-back" role="doc-backlink">↩︎</a></p></li> +<li id="fn48"><p>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.<a href="#fnref48" class="footnote-back" role="doc-backlink">↩︎</a></p></li> </ol> </section> </div> |