---
title: "Le langage de balisage léger Markdown : entre interopérabilité et compromis"
chapitre: 4
section: 3
bibfile: "data/04.json"
_build:
  list: always
  publishResources: true
  render: never
---

Cette étude de cas a pour objectif d'illustrer le concept de _format_ dans le contexte de l'édition, et ainsi d'analyser comment les enjeux sémantiques se manifestent dans un format spécifique.
Nous avons souligné l'intérêt de l'analyse des formats dans la perspective d'une étude de l'édition (numérique) ; le format est une suite d'instructions permettant une modélisation du sens.
Pour concevoir cette modélisation, la syntaxe sémantique ne doit pas être occultée, elle doit être visible et compréhensible : le mode WYSIWYG des outils d'écriture et d'édition empêche d'avoir accès à la dimension sémantique d'un document ; et masquer la syntaxe dans un mode _auteur_, dans le cas de langages de balisage complexes, ne permet pas non plus une maîtrise de cette modélisation.
Comment exprimer une sémantique dans un environnement _textuel_ modélisable et compréhensible ?
L'analyse du format Markdown, langage de balisage léger largement adopté dans de multiples domaines d'édition ou de gestion de documents, permet d'envisager des pratiques d'édition numérique où les processus sont conçus conjointement aux opérations sur les textes.

Les projets éditoriaux qui adoptent le langage de balisage léger Markdown sont nombreux, ses usages et ses implémentations dans des chaînes d'édition sont divers et reflètent des actes éditoriaux multiples.
Que révèle le format Markdown dans les pratiques d'édition avec le format texte, et dans la constitution de _fabriques_ d'édition ?
Nous nous plaçons toujours dans une perspective d'ouverture des techniques d'édition, et nous débutons cette étude de cas par un panorama historique, en explicitant l'apparition de ce type de langage de balisage et sa filiation avec des systèmes sémiotiques antérieurs.
Les influences qui ont conduit à la création du format Markdown puis à son adhésion sont nombreuses.
Son succès s'explique en partie par la simplicité de sa syntaxe, décrite dans un deuxième temps.
Cette description est néanmoins une tâche complexe, tant les versions ou _saveurs_ de Markdown sont nombreuses, créées notamment pour augmenter la sémantique originelle ; elles reflètent des choix techniques et épistémologiques.
C'est ce que nous présentons dans un troisième temps en explicitant pourquoi Markdown ne dispose pas d'un standard.
Enfin il s'agit d'aborder l'enjeu de la conversion, ou comment transformer ce _format de travail_ vers des formats de sortie qui donneront lieu à des artefacts.
Le convertisseur Pandoc, l'un des plus plébiscités pour ces opérations de conversion, est historiquement et structurellement très fortement lié à Markdown.
Dans ce contexte de format texte, Pandoc explicite le principe de modélisation éditoriale dans l'acte d'édition par l'articulation entre des actions comme _parser_ et _écrire_, via une représentation abstraite de cette modélisation.
Pandoc formalise nombre d'enjeux techniques autour de cette idée qui paraît pourtant simple : comment faire de la sémantique à partir de quelques signes typographiques ?
Si le format texte peut se révéler une solution universelle pour l'édition, un travail important est nécessaire pour l'élaboration de processus qui l'intègrent.


### 4.3.1. Aux origines des langages de balisage léger

Qu'est-ce qui a présidé à l'émergence des langages de balisage léger dans un contexte d'édition ou de publication numérique ?
Avant de détailler l'histoire et le fonctionnement de Markdown, ainsi que ses implications épistémologiques, nous explorons le contexte d'apparition des langages de balisage léger et les besoins initiaux qui ont contribué à leur création.
Les différentes initiatives convergent vers une volonté de rendre visible l'acte sémantique.
Ainsi, s'intéresser aux langages de balisage léger revient à "être attentif au milieu de l'écriture" comme l'expriment Serge Bouchardon et Isabelle Cailleau :

{{< citation ref="bouchardon_milieu_2018" page="121" >}}
Être attentif au milieu de l’écriture, c’est comprendre qu’il n’y a pas de milieu technique qui ne soit aussi un milieu social (une communauté de savoirs et de pouvoirs).  
Dans cette perspective, il y a un fort enjeu à tenter de rendre « visible » et « lisible » notre milieu numérique dans ses différents aspects : théoriques (propriétés spécifiques du numérique), techniques (fonctions qui les matérialisent dans des outils d’écriture et de lecture) et sémiotiques (pratiques sociales incarnées).
{{< /citation >}}

Les langages de balisage léger participent ainsi à une entreprise de dévoilement des initiatives de sémantisation.
Ils répondent à un double objectif : permettre de réaliser des opérations d'écriture sémantique — _numérique_ — conviviales {{< cite "illich_convivialite_2014" >}}, et générer des instructions afin de permettre aux machines de calculer la structure du texte.
Setext, créé en 1992, est une réponse pratique à ce double enjeu.
Il s'agit d'un des premiers langages de balisage léger pour écrire et diffuser des documents via Internet.
L'idée est relativement simple : utiliser des caractères ASCII{{< n >}}L'_American Standard Code for Information Interchange_, ou Code américain normalisé pour l'échange d'information, est une norme de codage de caractères désormais remplacée par Unicode.{{< /n >}} pour donner toutes les indications relatives à la structuration d'un texte, tout en étant lisible facilement — c'est-à-dire sans besoin d'effectuer la tâche complexe d'analyser la structure sémantique de cette source, comme c'est le cas avec les langages de balisage hérités de SGML comme HTML.
Setext est un format _lisible_ et _interopérable_ : des programmes peuvent lire ce format et en donner une représentation graphique ; néanmoins si aucun programme n'est capable d'interpréter ce langage, il est compréhensible par des personnes humaines.
Setext signifie "structure-enhanced text" {{< cite "engst_tidbits_1992" >}} : un format texte qui dispose d'une structuration.

{{< code type="code" legende="Exemple de quelques lignes balisées avec les marqueurs de Setext" >}}
Titre du document
=================

Paragraphe quelconque avec **un texte en emphase (gras)** ainsi qu'un autre ~fragment en emphase (italique)~.
{{< /code >}}

Comme nous pouvons le voir dans l'exemple ci-dessus, il s'agit d'une sémiotique qui sert la sémantique.
Les éléments signifiant consistent en un ou plusieurs caractères typographiques accessibles via tout clavier — occidental — des années 1990.
À la place des balises présentées précédemment{{< renvoi chapitre="4" section="2" >}}, du type `<em>englobante</em>`, qui ne sont pas créées pour être lues et qui sont ainsi jugées verbeuses pour qui les parcourt, ce ne sont que quelques _signes_ qui indiquent la valeur sémantique de tel ou tel fragment de texte.
Le changement de paradigme est fort, puisque d'un langage pour les machines — typiquement SGML et ses applications — nous passons à un langage pour les humains _et_ pour les programmes informatiques.

À la suite de cette initiative, plusieurs langages sont créés pour des besoins divers, se plaçant chacun dans des contextes spécifiques.
Nous observons alors un phénomène d'éclatement, puisque plusieurs d'entre eux réalisent des opérations parfois très similaires.
La filiation avec Setext n'est par ailleurs pas toujours avouée, pourtant les grammaires se ressemblent beaucoup.
Nous pouvons noter l'omniprésence de l'astérisque, dont l'héritage vient des comics américains comme le signale Matthew Gay {{< cite "guay_story_2020" >}} commenté par Arthur Perret {{< cite "perret_histoire_2020" >}}.
D'autres caractères typographiques reviennent fréquemment, inspirés par la programmation ou parce qu'il s'agit des caractères disponibles facilement, et qui n'introduisent pas d'ambiguïté dans la lecture.

Que ce soit atx — créé par Aaron Swartz en 2002 pour écrire des courriels — ou Textile — créé par Dean Allen aussi en 2002 pour faciliter l'écriture dans le CMS Textpattern — les similitudes sont nombreuses et oscillent entre un format trop simple avec le premier, et un balisage déjà complexe avec le second.
Textile propose en effet de nombreux _marqueurs_ pour indiquer des informations sémantiques avancées mais aussi des instructions de composition — comme l'alignement du texte.

{{< code type="code" legende="Exemple d'un texte balisé avec les marqueurs de Textile, extrait de la documentation de Textile" >}}
h2. Textile

p=.Features:

* is a _shorthand syntax_ used to generate valid HTML
* is *easy* to read and *easy* to write
* can generate complex pages, including: headings, quotes, lists, tables and figures

Textile integrations are available for "a wide range of platforms":/article/.
{{< /code >}}

{{< code type="code" legende="Conversion d'un texte balisé en Textile au format HTML, comportant des informations sémantiques et de mise en page" >}}
<h2>Textile</h2>

<p style="text-align:center;">Features:</p>

<ul>
	<li>is a <em>shorthand syntax</em> used to generate valid <span class="caps">HTML</span></li>
	<li>is <strong>easy</strong> to read and <strong>easy</strong> to write</li>
	<li>can generate complex pages, including: headings, quotes, lists, tables and figures</li>
</ul>

<p>Textile integrations are available for <a href="/article/">a wide range of platforms</a>.</p>
{{< /code >}}

Textile se positionne comme le moyen d'écrire du balisage HTML sans écrire de code HTML.
Le CMS Textpattern se charge de la conversion depuis Textile vers HTML, mais ce format est aussi utilisé dans d'autres environnements, et ainsi d'autres _parseurs_ sont développés.
Ces derniers appliquent une série de règles établies en fonction des spécifications du format, les règles peuvent toutefois varier d'un programme à l'autre et générer des ambiguïtés.

Markdown apparaît dans ce contexte où un balisage sémantique simple est recherché, pour écrire puis publier des documents dans un environnement numérique.
Textile répond à cet objectif, mais avec des options trop nombreuses.
C'est pourquoi John Gruber conçoit le langage de balisage Markdown en s'inspirant de Textile et de atx, cherchant ainsi un compromis pour la publication de pages web.
Il crée le format — donc ses spécifications — et un programme pour convertir des fichiers Markdown vers le format HTML, avec l'aide d'Aaron Swartz{{< n >}}Aaron Swartz était un militant et informaticien qui a notamment contribué à la mise en place d'un certain nombre de standards et à différents combats autour du droit d'auteur ou de l'accès à l'information.{{< /n >}}.
John Gruber explique de façon très explicite son intention :

{{< citation ref="gruber_markdown_2004" lang="en" >}}
A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters — including Setext, atx, Textile, reStructuredText, Grutatext, and EtText — the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.  
To this end, Markdown’s syntax is comprised entirely of punctuation characters, which punctuation characters have been carefully chosen so as to look like what they mean.
{{< /citation >}}

Il s'agit d'écrire des pages HTML sans devoir en utiliser les balises, ainsi que d'étendre cette pratique numérique à une écriture lisible en toute situation, qu'il y ait conversion du format ou non.
Si l'influence de la conception de ce _langage_ est en partie celle de la programmation, et donc des syntaxes qui y sont habituellement employées, Markdown se détache du système de balises héritées de SGML.
À partir de quelques marqueurs signifiés avec des caractères typographiques simples et non ambigus, en l'occurrence uniquement des signes de ponctuation, ce langage permet d'écrire facilement des documents structurés en HTML — jusqu'à une certaine limite, nous y reviendrons.
Comme l'explique Robin de Mourat, l'enjeu est en partie esthétique :

{{< citation ref="mourat_design_2018" page="41" >}}
Le format Markdown implique un rapport paradoxal à la forme et à la « présentation » des textes, puisqu’il dénote un souci esthétique important pour la pratique de l’écriture – il est voulu élégant à lire et facile à écrire – tout en déléguant à d’autres dispositifs techniques les questions de mise en forme pour la lecture des écrits par le public.
{{< /citation >}}

Rappelons-le avec force, le but premier de cette syntaxe est d'être convertie, mais sa lecture est aussi possible sans opération(s) intermédiaire(s).
C'est l'une des trois _clés_ du succès comme l'exprime également Sean Leonard :

{{< citation ref="leonard_guidance_2016" lang="en" >}}
Since its introduction in 2004, Markdown has enjoyed remarkable success. Markdown works for users for three key reasons. First, the markup instructions (in text) look similar to the markup that they represent; therefore, the cognitive burden to learn the syntax is low.
{{< /citation >}}

L'apprentissage et la maîtrise de ce langage de balisage léger sont en effet rapides, les différentes _balises_ nécessaires pour structurer un document sont faciles à mémoriser.
Les deux autres raisons exprimées par Sean Leonard sont d'ordre technique et d'usage.
Tout d'abord, les éléments syntaxiques sont déterminés par l'outil de conversion du format Markdown vers un autre format, ce point est prolongé à la fin de cette étude de cas.
Ensuite, une importante communauté hétérogène s'est saisie du format, en adaptant, modifiant et étendant ce langage.
Le fonctionnement de Markdown mérite que nous nous attardions plus longuement sur ses mécanismes sémantiques.


### 4.3.2. Les principes de la syntaxe Markdown

Markdown place le sens au centre de l'écriture, dans un environnement que nous pouvons qualifier de _convivial_ pour reprendre un terme de Ivan Illich {{< cite "illich_convivialite_2014" >}}.
Cela se traduit par une simplicité et une certaine _élégance_ dans l'opération de sémantisation, mais aussi une appropriation du format dans ses multiples saveurs avec les convertisseurs qui les accompagnent.
La syntaxe du langage de balisage léger Markdown est une série de spécifications techniques, cette syntaxe repose sur une série de _signes_ typographiques et sur une opération de conversion pour obtenir une page HTML.
Cette syntaxe constitue aussi un nouveau rapport au texte, à la fois l'implémentation d'un moyen simple d'appliquer une sémantique, et la promesse d'obtenir un format diffusable et interopérable.

{{< citation ref="gruber_dive_2004" lang="en" >}}
When you write and read text that’s marked-up with HTML tags, it’s forcing you to concentrate on the _think of it_. It’s _the feel of it_ that I want Markdown-formatted text to convey.
{{< /citation >}}

La notion de _sensation_ est relativement floue ici.
Nous l'interprétons comme l'implémentation spécifique d'une écriture avec le format texte, où la maîtrise de la grammaire sémantique est suffisamment simple pour permettre une certaine fluidité de la rédaction.
Nous détaillons cela en analysant la syntaxe nécessaire à la rédaction d'un texte simple, en présentant les trois _versions_ successives d'un même contenu : la source au format Markdown, le même contenu converti au format HTML, et le rendu graphique correspondant — dans ce dernier cas la feuille de styles qui est appliquée est celle par défaut du navigateur web Firefox.

{{< code type="code" legende="Exemple d'un document structuré au format Markdown, avec différents niveaux sémantiques" >}}
# Les fabriques d'édition : un double mouvement éditorial

Antoine Fauchié

Les technologies de l'édition, et plus particulièrement de l'édition numérique, ont beaucoup évolué depuis le début des années 2000, avec l'apparition de chaînes de publication qui s'éloignent peu à peu des outils classiques d'édition. Fabriquer une publication, et plus spécifiquement un livre, est une opportunité pour certaines structures de construire leurs propres outils d'édition et de publication. Nous présentons plusieurs initiatives d'édition, basées sur ce que nous nommons des *fabriques d'édition*, afin d'observer et d'analyser ces nouvelles façons de faire, d'éditer, comme un nouveau mouvement éditorial.

## Définition de l'édition
L'édition est entendue comme un processus constitué de trois fonctions :

- la fonction **de choix et de production** ;
- la fonction **de légitimation** ;
- la fonction **de diffusion**.

> L’édition peut être comprise comme un processus de médiation qui permet à un contenu d’exister et d’être accessible. On peut distinguer trois étapes de ce processus qui correspondent à trois fonctions différentes de l’édition : une fonction de choix et de production, une fonction de légitimation et une fonction de diffusion.  
> [Source : Benoît Epron et Marcello Vitali-Rosati, _L'édition à l'ère numérique_](https://papyrus.bib.umontreal.ca/xmlui/handle/1866/20642)
{{< /code >}}

{{< code type="code" legende="Version HTML d'un document initialement balisé avec le langage de balisage léger Markdown" >}}
<h1>Les fabriques d’édition : un double mouvement éditorial</h1>
<p>Antoine Fauchié</p>
<p>Les technologies de l’édition, et plus particulièrement de l’édition numérique, ont beaucoup évolué depuis le début des années 2000, avec l’apparition de chaînes de publication qui s’éloignent peu à peu des outils classiques d’édition. Fabriquer une publication, et plus spécifiquement un livre, est une opportunité pour certaines structures de construire leurs propres outils d’édition et de publication. Nous présentons plusieurs initiatives d’édition, basées sur ce que nous nommons des <em>fabriques d’édition</em>, afin d’observer et d’analyser ces nouvelles façons de faire, d’éditer, comme un nouveau mouvement éditorial.</p>
<h2>Définition de l’édition</h2>
<p>L’édition est entendue comme un processus constitué de trois fonctions :</p>
<ul>
<li>la fonction <strong>de choix et de production</strong> ;</li>
<li>la fonction <strong>de légitimation</strong> ;</li>
<li>la fonction <strong>de diffusion</strong>.</li>
</ul>
<blockquote>
<p>L’édition peut être comprise comme un processus de médiation qui permet à un contenu d’exister et d’être accessible. On peut distinguer trois étapes de ce processus qui correspondent à trois fonctions différentes de l’édition : une fonction de choix et de production, une fonction de légitimation et une fonction de diffusion.<br />
<a href="https://papyrus.bib.umontreal.ca/xmlui/handle/1866/20642">Source : Benoît Epron et Marcello Vitali-Rosati, <em>L’édition à l’ère numérique</em></a></p>
</blockquote>
{{< /code >}}

{{< figure type="figure" src="markdown-exemple-rendu.png" legende="Rendu graphique d'un document originellement structuré au format Markdown et converti en HTML" >}}

Avant de détailler les exemples ci-dessus nous devons rappeler une distinction fondamentale entre deux _niveaux_ sémantiques d'un texte : les éléments de bloc et les éléments de texte, tels que présentés dans la section précédente{{< renvoi chapitre="4" section="2" >}}, et ce pour chacune des syntaxes qui suivent.
Les signes typographiques utilisés pour baliser le texte sont donc les suivants : le saut de paragraphe (saut de ligne suivi d'un second saut de ligne) pour indiquer le début puis la fin d'un paragraphe (élément de bloc) ; des croisillons (ou carrés), `#`, autant que nécessaire et suivi d'un espace pour indiquer les niveaux de titre croissants jusqu'à six (élément de bloc) ; un ou deux astérisques englobant une suite caractères, `*`, sans espace le suivant et le précédant, pour signifier un texte en emphase (un astérisque) ou qualifié de fort (deux astérisques) (élément de texte dans les deux cas) ; un chevron (fermant), `>`, suivi d'un espace pour signaler une citation longue (élément de bloc) ; une suite de tirets, `-`, suivi d'un espace pour représenter une liste non ordonnée (élément de bloc) ; des crochets, `[]`, englobant une suite de caractères sans espace après et avant, suivi de parenthèses, `()`, englobant une seconde suite de caractères, et qualifiant respectivement un texte considéré comme un lien hypertexte et la cible du lien en question (élément de texte) ; etc.
La documentation initiale complète ces quelques éléments, auxquels il faut ajouter la liste ordonnée, l'insertion d'une image, le saut de ligne, le code, ainsi que des variantes ou des fonctionnements spécifiques pour tous ces types de _balisage_ {{< cite "gruber_markdown_2004" >}}.

La simplicité du langage — il s'agissait initialement de pouvoir baliser dix éléments sémantiques distincts — a contribué à son adoption rapide.
Comme nous l'avons dit, ce langage a été fortement influencé par d'autres initiatives antérieures qui utilisent certains de ces signes — `#` est emprunté à atx et `>` à un usage plus informel dans les courriels, par exemple —, ce qui explique l'adhésion de personnes déjà habituées à écrire au format texte.
Cette adhésion s'est traduite d'une part par une intégration dans différents outils d'écriture — CMS, plateformes d'échange ou de forums, etc. —, et d'autre part par la création d'extensions de ce langage.
Textile avait déjà démontré l'intérêt d'un langage de balisage léger intégré à des systèmes de publication existants, Markdown a confirmé cette tendance d'utiliser des alternatives au mode WYSIWYG.
Les éditeurs de texte enrichis intégrés à des logiciels comme DreamWeaver ou à des CMS comme WordPress ont longtemps été critiqués pour leur manque de respect du standard HTML ou pour leur balisage excessif, Markdown s'est imposé comme une forme de standard _de fait_.

L'objet de Markdown est le texte numérique, ce qui induit quelques lacunes pour qui voudrait structurer des notes de bas de page, des tableaux, voir des citations bibliographiques.
C'est ce qui explique la création de _saveurs_ alternatives à celle originelle de John Gruber, elles s'inscrivent dans des pratiques bien particulières, ou répondent à des contraintes techniques tierces que nous analysons par la suite.


### 4.3.3. Les _saveurs_ de Markdown

L'essor du langage de balisage léger Markdown est accompagné par différentes initiatives qui visent à l'étendre ou à l'adapter à des usages particuliers.
Ce phénomène peut s'expliquer pour deux raisons principales : augmenter le champ des possibles sémantiques, permettre une intégration dans des outils d'écriture déjà existants.
John Gruber spécifie immédiatement que l'objectif de Markdown, tel que prévu initialement, n'est pas de donner une équivalence à la majorité des éléments (balises) HTML.
Pourtant, certaines opérations sémantiques, volontairement écartées par le créateur de Markdown, deviennent des prérogatives pour d'autres personnes ou d'autres démarches.
Trois exemples d'éléments sémantiques permettent de comprendre les enjeux autour des velléités d'extension de Markdown : la note de bas de page, le tableau et les métadonnées.

La note de bas de page peut être transposée dans le langage HTML par un système simple de liens internes : l'appel de note est un lien hypertexte qui renvoie vers une autre partie du document grâce à une ancre placée dans la note, et un second lien permet de retrouver l'appel associé à la note.
Cette transposition est verbeuse et peu agréable à écrire avec des balises HTML, c'est pourquoi les saveurs MultiMarkdown ou Markdown Extra{{< n >}}Nous ne faisons pas la liste de toutes les saveurs existantes de Markdown.{{< /n >}} prévoient un balisage spécifique — toujours basé sur des caractères de ponctuation.
Markdown peut ainsi être utilisé pour rédiger des textes avec une richesse sémantique plus importante, et ouvre la perspective d'usages dans le domaine des _lettres_ où la note est une nécessité.

Le deuxième exemple est le tableau, particulièrement verbeux en HTML en raison de la complexité de cet objet, et dont une transposition plus simple — au détriment de toutes les options existantes en HTML — est faite avec Markdown Extra ou GitHub Flavored Markdown.
Cet usage des tableaux, fondateur des premières initiatives de mise en forme avancée du début du Web, est principalement présentationnel.
Du point de vue du sens il s'agit de faire correspondre mais aussi de _croiser_ toute une série d'informations.

Enfin les métadonnées représentent un pan important des recherches liées à la mise en sémantique des textes avec l'informatique.
Décrire des métadonnées avec Markdown prend deux orientations, la première étant d'intégrer ces métadonnées au document initial, et la seconde consistant à laisser le choix entre une intégration ou une séparation.
La saveur MultiMarkdown fait le premier choix, en établissant un format de sérialisation de données _à l'intérieur_ de Markdown via l'usage d'un entête sous la forme de balises déterminées.
La deuxième option est implémentée via divers formats de balisage, et notamment YAML — pour _YAML Ain't Markup Language_ — un langage de sérialisation de données qui, couplé à certains convertisseurs comme Pandoc, permet de renseigner des métadonnées qui peuvent ensuite être transcrites en HTML dans les éléments `metadata` placés dans l'entête.
Il s'agit d'une volonté d'enrichissement des documents au-delà de leur structuration de contenu, ainsi que d'une tentative de tout faire dans un même format.

Qu'est-ce qui explique ces saveurs multiples ?
Un premier élément de réponse est de considérer chacune d'elles comme répondant à des usages particuliers dans des contextes différents, soulignant ainsi que tout format ne peut se réduire à une seule implémentation d'une série de principes théoriques.
Une réponse moins consensuelle consiste à accepter que la spécification originale engendre de nombreuses ambiguïtés, listées en détail via le projet Babelmark{{< n >}}[https://babelmark.github.io/faq/](https://babelmark.github.io/faq/){{< /n >}} — initialement lancé par John MacFarlane —, et que certaines saveurs entendent résoudre.
Notons que ces pratiques foisonnantes autour de Markdown reflètent également des intégrations dans des environnements de programmation différents, comme Markdown Extra dont le convertisseur est écrit en PHP comparé à Pandoc qui est écrit en Haskell.
Le langage se développe en même temps que des chaînes d'édition sont constituées _autour_ ou _avec_ lui — ces chaînes étant elles-mêmes en lien avec des projets éditoriaux variés.
Cette situation illustre en partie la difficulté d'atteindre un standard, c'est-à-dire l'établissement d'une suite de règles univoques sous la forme de spécifications précises, censées permettre le développement d'applications autour de Markdown.
Cette absence de standardisation fait elle-même l'objet d'une tentative de standardisation, ou tout du moins d'une publication à titre d'information sous la forme d'une RFC qui recense et documente certaines des _saveurs_ de Markdown {{< cite "leonard_guidance_2016" >}}.
Une initiative communautaire émerge toutefois, tentant de résoudre les principaux problèmes de Markdown tout en étendant cette syntaxe : CommonMark.


### 4.3.4. L'impossibilité d'une standardisation

Si le format Markdown s'impose comme une norme _de fait_ {{< cite "fauchie_markdown_2018" >}}, tant les usages sont nombreux, nous devons comprendre les raisons d'une absence de standardisation.
Aucune spécification commune n'existe, sur laquelle une communauté suffisamment large peut s'accorder, et ce qui permettrait de disposer d'une _saveur_ de référence de Markdown.
Le succès de Markdown — en termes d'adoption dans les pratiques d'écriture numérique et d'intégration dans diverses applications — est lié à ses spécifications ouvertes, qui engendrent toutefois des obstacles pour son interprétation.
L'enjeu ici concerne la conversion du format, principalement vers HTML, opération rendue complexe si des ambiguïtés persistent dans le balisage.
Par exemple le texte suivant `***bold** in ital*` peut être traduit en HTML de diverses manières, c'est ce que démontre l'initiative Babelmark déjà évoquée.
Le fait qu'un même texte balisé avec Markdown puisse être interprété de différentes manières selon les outils ou les environnements est un problème, une lacune en termes d'interopérabilité.
Un standard permet diverses implémentations, à la fois respectueuses du format et interopérables.

Établir un standard est une tâche longue et complexe, l'objectif est de donner toutes les informations utiles à sa compréhension pour des humains qui l'écrivent et pour les machines qui le traitent.
SGML ou HTML ont par exemple nécessité plusieurs années d'un travail collectif pour déterminer tous les éléments syntaxiques, que ce soient leur définition, leur signification, le rendu escompté ou leur imbrication.
Dans le cas de HTML, c'est d'ailleurs un exercice continu dont le W3C a la charge.
Une initiative collective de standardisation pour un autre langage de balisage léger, AsciiDoc, est en cours depuis 2020{{< n >}}[https://groups.google.com/g/asciidoc/c/EKx-Hfx-nMM](https://groups.google.com/g/asciidoc/c/EKx-Hfx-nMM){{< /n >}}, et démontre une volonté de disposer d'une base commune pour construire des outils de sémantisation.
Plus qu'un simple travail de définition, un certain nombre de choix et de compromis sont réalisés, nécessitant un arbitrage par rapport au dessein initial comme les exemples ci-dessus le démontrent.
Précisons enfin que ces efforts de standardisation sont toujours accompagnés du développement de programmes ou d'outils qui sont capables d'analyser, de convertir ou d'écrire ces formats.
C'est le cas de HTML qui est interprété puis transformé en un rendu graphique via des navigateurs web.
Markdown, en tant que langage de balisage, a été conçu avec un _parser_ écrit en Perl, c'est également le cas avec AsciiDoc et le développement d'Asciidoctor{{< n >}}[https://asciidoctor.org](https://asciidoctor.org){{< /n >}}.

Une tentative majeure de standardisation de Markdown a commencé en 2012 — soit 8 ans après la création originelle de John Gruber — sous le nom de CommonMark{{< n >}}[https://commonmark.org](https://commonmark.org){{< /n >}}.
Ce projet rassemble plusieurs acteurs industriels ou académiques, et vise à établir le fonctionnement précis de cette syntaxe, et ainsi lever toute ambiguïté.
Il s'agit de définir de façon univoque le balisage sémantique, et donc le choix des caractères de ponctuation et leur comportement pour marquer le sens du texte.
CommonMark a une histoire complexe, faite de nombreux échanges entre les instigateurs de ce projet — John MacFarlane, David Greenspan, Vicent Marti, Neil Williams, Benjamin Dumke-von der Ehe, et Jeff Atwood —, mais aussi avec le créateur de Markdown, John Gruber.
Les frictions, probablement nécessaires pour parvenir à un consensus, ne peuvent être détaillées précisément ici, mais concernent justement le degré d'ouverture que peut conserver ou non ce langage de balisage léger.

{{< citation ref="mpondo-dicka_markdown_2020" >}}
Le langage créé par John Gruber change de fonction et de statut au fur et à mesure de son évolution : en tant que code, il est le lieu même du dialogue humain-machine, passant d’idiolecte à standard, perdant en souplesse ce qu’il gagne en interopérabilité, en individuation ce qu’il gagne en cohérence.
{{< /citation >}}

Il est ainsi compréhensible que John Gruber n'ait pas souhaité participer à ce travail de _fixation_ de son beau mais néanmoins utopique projet.
Markdown s'est à ce point répandu dans les usages qu'il est même devenu une action plus qu'un format, tant il est synonyme d'une écriture qui se veut simple, compréhensible et sémantique.

Entre 2014 et 2021 ce sont trente versions des spécifications de CommonMark qui sont publiées successivement, proposant de nombreuses solutions pour une implémentation complète de ce langage, clarifications après clarifications.
La longue liste des changements entre ces différentes versions {{< cite "macfarlane_commonmark_2021" >}} révèle un travail titanesque{{< n >}}Toutefois incomparable par rapport aux standard TEI ou HTML.{{< /n >}} pour un langage pourtant qualifié de _léger_.
Tous ces efforts convergent pour permettre aux différents convertisseurs, logiciels ou applications en ligne d'interpréter convenablement Markdown.
Depuis 2021 ces spécifications se sont pourtant arrêtées.
Il paraît en effet impossible de résoudre les ambiguïtés liées aux choix de balises de départ, c'est ce que relève John MacFarlane dans un essai où il liste les six fonctionnalités de Markdown qui présentent le plus de difficultés {{< cite "macfarlane_beyond_2018" >}}.

À la suite de ce texte important pour le format Markdown et la communauté investie dans cette recherche de standardisation, John MacFarlane crée un nouveau format, Djot{{< n >}}[https://djot.net](https://djot.net){{< /n >}}.
Largement inspiré de la _saveur_ CommonMark, Djot résout les ambiguïtés inhérentes à Markdown en repensant un certain nombre d'éléments de balisage, et intègre également plusieurs nouvelles fonctionnalités en plus des tableaux ou des notes de bas de page.
Au-delà de la conception remarquable et de la consistance du format lui-même, il faut observer à quel point il bénéficie du travail conjoint de développement du convertisseur Pandoc.

Nous pouvons observer qu'il y a une tension entre un format ouvert aux spécifications imprécises et un besoin de disposer d'un standard commun et partagé.
Le format Djot créé par John MacFarlane ne suscite pas une adhésion large, malgré un succès d'estime.
Le format Markdown trouve son intérêt dans ce que nous considérons un _interstice sémantique_, il s'agit d'un flou qui peut être exploité dans des actes éditoriaux.
Il est par exemple possible d'inventer une balise, et d'ajouter un morceau de programme à un convertisseur pour prendre en compte ce nouvel élément syntaxique.
Avec des formats standardisés comme XML-TEI, cela est possible mais au prix d'un effort beaucoup plus important.
Markdown permet de construire des _fabriques d'édition_, où l'expérimentation a une grande place.

Avant de détailler le fonctionnement de Pandoc, notons que ce désir de disposer de langages de balisage léger ne s'arrête pas à Markdown. 
Nous pouvons citer la création de Gemini en 2019 {{< cite "bortzmeyer_protocole_2020" >}}, il s'agit à la fois d'un protocole de communication et d'un langage de balisage.
En tant que format sémantique, Gemini est une adaptation minimale de Markdown, qui délègue totalement la représentation ou la conversion de sa syntaxe — constituée de sept éléments sémantiques.
La création de ce format est donc liée à des outils qui permettent de le manipuler et de le visualiser — le caractère minimal des spécifications du format étant ici censé faciliter son implémentation dans différents environnements.
Un format, quelles que soient ses spécifications, est toujours développé avec une modélisation qui permet de le représenter.


### 4.3.5. Un format à convertir

Comme tout langage de balisage léger, Markdown est fait pour être converti.
C'est pourquoi John Gruber a publié conjointement les spécifications du format et le programme qui transforme chaque élément sémantique en balise HTML correspondante — programme écrit en Perl.
Un langage de balisage ne se suffit pas à lui-même, ses spécifications dépendent donc du fonctionnement d'un ensemble d'éléments : un _analyseur_ (_parser_ en anglais), une modélisation abstraite, un convertisseur et un module d'écriture.
Dit autrement par Sean Leonard ci-dessous, c'est cet ensemble qui détermine précisément le fonctionnement de la syntaxe :

{{< citation ref="leonard_guidance_2016" lang="en" >}}
Second, the primary arbiter of the syntax's success is *running code*. The tool that converts the Markdown to a presentable format, and not a series of formal pronouncements by a standards body, is the basis for whether syntactic elements matter.
{{< /citation >}}

Un analyseur syntaxique, ou _parser_, est un programme qui est capable de construire, à partir de données, une structure syntaxique qui se traduit par une modélisation abstraite, permettant ensuite des manipulations de ces données — dont des conversions.
L'objectif, dans le cas de Markdown, est donc de reconnaître chaque balise pour représenter le texte selon un arbre syntaxique abstrait.
Le DOM — pour _Document Object Model_ — est un moyen programmatique, syntaxique et sémantique de représenter cet arbre syntaxique abstrait.
Prenons un exemple : un document qui contient un titre, un paragraphe et une citation longue peut être représenté ainsi : un document qui est composé de deux éléments que sont un entête et un corps, le corps étant lui-même composé de deux sous-ensembles que sont un paragraphe et une citation longue, etc.
La modélisation abstraite permet de définir les besoins sémantiques, et le DOM permet de le représenter pour manipuler les données et les _convertir_ dans d'autres formats.
La conversion d'un fichier au format Markdown vers HTML passe donc d'abord par ces étapes d'identification syntaxique, de représentation abstraite et de manipulation de données. 

Les variantes de Markdown sont accompagnées de (presque) autant de façons de le convertir vers d'autres formats{{< n >}}Le projet Babelmark répertorie une trentaine de _parsers_ différents : [https://github.com/babelmark/babelmark-registry/blob/master/registry.json](https://github.com/babelmark/babelmark-registry/blob/master/registry.json){{< /n >}}, et en premier lieu HTML.
Parmi ces convertisseurs, Pandoc fait figure d'exception en raison des multiples formats d'export disponibles — comme c'est indiqué sur la page d'accueil du site web dédié{{< n >}}[https://pandoc.org](https://pandoc.org){{< /n >}}, "pandoc is your swiss-army knife" —, et de la volonté d'en faire un outil orienté vers les standards.
C'est ce qui explique que son créateur et principal mainteneur, John MacFarlane, professeur de philosophie à l'Université de Californie, s'est fortement impliqué dans la tentative de standardisation de Markdown avec CommonMark.

Un aparté est ici nécessaire à propos de cette séparation entre format source et rendu final, qui est aussi une distinction entre le format d'écriture — celui qui est utilisé au moment où le texte est _tapé_ —, et le format qui circule — a priori le format _converti_.
Les langages de balisage, qu'ils soient légers ou non, ont cette particularité d'être à la fois des "formats d'échange" et des "formats de travail" pour reprendre les expressions utilisées par Bruno Bachimont :

{{< citation ref="bachimont_ingenierie_2007" page="237-238" >}}
Les formats de travail sont internes à l’application et ne prétendent à aucune universalité. C’est une solution locale formulée à travers un format déclaratif. Le format d’échange prétend à une certaine universalité, dans la mesure où l’on doit pouvoir tout dire et se faire lire par tout le monde. Comme ces deux objectifs sont contradictoires, il faut bien transiger, et chaque format se définit par le type de compromis qu’il a adopté. Par conséquent, vouloir choisir le format d’échange pour mener les traitements internes de l’application est souvent un choix maladroit et introduit des contraintes et difficultés inutiles à l’élaboration du projet, alors qu’il suffit d’avoir un moyen de traduire les structures du format interne dans le format d’échange pour exploiter de manière large les informations manipulées et produites par l’application.
{{< /citation >}}

Avec Markdown l'_universalité_ (pour reprendre le terme de Bruno Bachimont) est aussi du côté de l'outil.
C'est d'ailleurs le mot qu'utilise Pandoc pour se définir{{< n >}}L'expression exacte est "convertisseur de documents universel" (_universal document converter_).{{< /n >}}, "universel".

Mis en place dès 2006 — soit deux ans après la création de Markdown — Pandoc réalise une série d'opérations pour passer d'un format de balisage à un autre, et plus spécifiquement d'_un_ langage de balisage à _plusieurs_ formats de sortie.

{{< citation ref="dominici_overview_2014" page="44" lang="en" >}}
Pandoc shows its real utility, in my opinion, when what is needed is to obtain several output formats from a single source, as in the case of a document distributed online (HTML), in print form (PDF via LATEX) and for viewing on tablets or ebook readers (EPUB). In such cases one may find that writing the document in a rich format (e.g. LATEX) and converting later to other markup languages often poses significant problems because of the different ‘philosophies’ that underlie each language.
{{< /citation >}}

Ce qui semble simple, typiquement remplacer `**ce texte**` par `<strong>ce texte</strong>`, peut se révéler bien plus complexe dans certains cas, et plus encore lorsqu'il s'agit de conjuguer des résultats comme un format sémantique (comme HTML) et un format de composition (comme LaTeX).
Pandoc consiste en une suite d'opérations pour permettre une forme de correspondance entre deux formats de balisage.
Il s'agit donc de réaliser une analyse syntaxique du format d'entrée pour disposer d'une représentation du document, le DOM, qui est ensuite manipulé pour créer un nouveau fichier dans un autre langage de balisage.
Pandoc adopte une organisation modulaire et transforme ainsi tout texte en un arbre de données manipulables.
Le format JSON est une manifestation du DOM, parmi d'autres, qui permet de prendre la mesure de la richesse de cette modélisation abstraite, sans pour autant en être une représentation complète.
La simple phrase au format Markdown `Des *fabriques d'édition*.` peut avoir comme manifestation le document suivant au format JSON :

{{< code type="code" legende="Exemple d'une conversion au format JSON d'une phrase écrite au format Markdown et contenant de l'emphase" >}}
{"pandoc-api-version":[1,22,2],"meta":{},"blocks":[{"t":"Para","c":[{"t":"Str","c":"Des"},{"t":"Space"},{"t":"Emph","c":[{"t":"Str","c":"fabriques"},{"t":"Space"},{"t":"Str","c":"d’édition"}]},{"t":"Str","c":"."}]}]}
{{< /code >}}

À partir de ces opérations — analyse syntaxique, représentation abstraite, manipulation des données —, Pandoc est capable de produire plus de cinquante formats.
Il peut s'agir de formats de balisage léger (Markdown, Textile), des formats HTML ou XML (selon plusieurs schémas), de formats utilisés dans des systèmes de wiki, ou encore des formats de données comme CSV.
Il est même possible de créer son propre outil d'analyse et de manipulation de données, via le langage de programmation Lua.
Le rôle éminemment épistémologique de Pandoc est de considérer chaque format comme une expression syntaxique et sémantique qui peut être représentée de diverses manières, avec ou sans perte d'informations.
Le point de départ privilégié est Markdown, probablement pour ses caractéristiques légères et extensibles par rapport à d'autres formats {{< cite "dominici_overview_2014" "50" >}}.

Une des particularités de Pandoc est son utilisation via un terminal, il ne s'agit pas d'un logiciel avec une interface graphique.
Cela a probablement été une des raisons de son adoption d'abord par une communauté de techniciens et de techniciennes, notamment dans les domaines du développement informatique ou de certains champs académiques (mathématiques et physique par exemple).
Comme tout programme en ligne de commande, Pandoc prend plusieurs paramètres en compte, voici deux exemples de commande commentées :

{{< code type="code" legende="Trois exemples de commandes Pandoc permettant de convertir des fichiers Markdown vers le format HTML avec différents paramètres" >}}

pandoc fichier-source.md
# cette commande transforme le fichier source en donnant le résultat directement dans le terminal

pandoc -f markdown -t html fichier-source.md -o fichier-exporte.html
# cette commande spécifie le format en entrée et le format en sortie, ainsi que le nom du fichier exporté

pandoc -f markdown -t html fichier-source.md -o fichier-exporte.html --citeproc --standalone --wraps=none --template=modele.html
# cette commande ajoute la fonction de gestion bibliographique, la précision que le fichier HTML produit doit comporter aussi un entête, l'option que les lignes ne doivent pas être sautées tous les 80 caractères, et le modèle ou template qui doit être appliqué

{{< /code >}}

Dans la dernière commande de l'exemple ci-dessus, Pandoc applique un modèle (_template_ en anglais) vers une disposition de données exprimée via un langage particulier — et basée sur des conditions et des boucles.
Cela en fait un puissant outil de conversion où la structure d'un document peut être rédigée distinctement du contenu et de sa mise en forme.

Un programme, des options et des arguments, le fonctionnement de Pandoc est au premier abord assez classique, en informatique il s'agit d'un _tube_ (_pipe_ en anglais) qui traite une information en entrée et donne un résultat en sortie.
Mais une autre de ses particularités est de pouvoir être étendu, via le recours à des _filtres_, qui sont des scripts qui appliquent des transformations contextuelles.
Ces filtres sont une condition de l'appropriabilité de Pandoc, puisqu'il est relativement simple de créer de nouvelles règles de conversion, sans pour autant devoir modifier le code de Pandoc.
Un exemple parmi d'autres est un filtre chargé de gérer les spécificités typographiques du français, comme les espaces insécables avant certains signes de ponctuation.
Le filtre pandoc-filter-fr-nbsp{{< n >}}[https://inseefrlab.github.io/pandoc-filter-fr-nbsp/](https://inseefrlab.github.io/pandoc-filter-fr-nbsp/){{< /n >}} prend par exemple en charge la gestion microtypographique pour les spécificités de la langue française (espaces insécables avant certains signes de ponctuation notamment).

Le point de départ de Pandoc est la transformation du langage de balisage léger Markdown vers des formats de sortie comme HTML ou LaTeX (pour ensuite viser le format PDF), mais par son mode de fonctionnement ce convertisseur est un double apport : la multimodalité et l'acte éditorial sémantique.
Pandoc est capable d'exporter un même format dans plusieurs formats de sortie, autrement dit il peut convertir une même source en différentes formes éditoriales.
Il permet d'appliquer les principes du _single source publishing_, ou publication multimodale à partir d'une source unique, explicitée dans la section qui suit.
Plus qu'une simple prouesse technique, il s'agit d'une nouvelle dimension qui complète le concept de format tel que définit dans le contexte de l'édition.
L'acte éditorial sémantique est l'introduction de pratiques de sémantisation dans le processus même d'édition, et plus uniquement dans la structuration d'un texte et d'un fichier.