Une tyrannie de la forme ?

Le débat en question date de mars dernier sur Mastodon. Il portait sur nos expériences et attentes en matière de lecture numérique, à partir d’un billet de Christophe Masutti, « Pour un Web désencombré ».

Dans son billet, Masutti défend l’idée que le « désencombrement » du Web doit passer notamment par un plus grand contrôle des lecteurs sur leur expérience. Pour lui, la mise en forme ne constitue qu’une proposition dont le lecteur devrait pouvoir se passer ou refaire à sa guise. Il prend l’exemple de Gemini, un protocole alternatif pour lequel des navigateurs spécialisés existent et proposent un contrôle accru sur l’expérience de lecture.

Ce billet m’a fait réagir, car je pense que la forme n’est pas une simple proposition dispensable. Je partage le diagnostic sur l’« encombrement » du Web mais je vois dans l’exemple de Gemini une mauvaise solution. En effet, il ne s’agit pas seulement de donner du contrôle au lecteur au moment de la réception : Gemini bride fortement les possibilités d’expression au niveau de la conception. C’est une réponse radicale, au sens où elle tente de revenir à la racine : redéfinir ce que constitue l’essence du partage d’idées via Internet. Mais c’est aussi une réponse réactionnaire, qui rejette l’héritage de l’imprimé et notamment du livre avec un mélange d’ignorance et d’hostilité. En refusant d’affronter le problème comme une question de négociation entre acteurs (auteurs, éditeurs, designers…), Gemini montre que l’univers du libre n’est pas exempt de techno-solutionnisme.

Durant la discussion, Masutti a pris mon site comme exemple pour illustrer son propos. Le placement des notes dans la marge est un aspect central de l’identité visuelle de mon site, un hommage direct à la tradition livresque. Mais il est bricolé d’une manière qui ne fonctionne pas dans certaines interfaces : mode lecteur du navigateur, lecteur de flux web, navigateur en ligne de commande… Dans ces interfaces, parce que mes styles CSS ne sont plus appliqués, les notes apparaissent en plein milieu des phrases, éventrant les paragraphes et gênant la lecture. En pratique, cela impose au lecteur de consulter mon site via un navigateur web (et sans pouvoir utiliser éventuellement le mode lecteur). Pour Masutti, c’est un exemple d’expérience négative auxquelles se heurtent parfois les lecteurs sur le Web – une sorte de tyrannie de la forme.

Cette discussion m’a fait réfléchir. Je suis évidemment embêté d’imposer aux autres ce que je n’aimerais pas qu’on m’impose à moi. En effet, quand je lis des publications web, je passe très souvent par une interface type « lecteur » – soit le mode lecteur du navigateur, soit mon lecteur de flux web. Je trouve la plupart des sites web désagréables à consulter, parce qu’ils sont mis en forme sans aucune considération pour la culture de l’imprimé qui structure mon rapport au texte (et je ne pense pas être le seul). Et j’avoue que même lorsque le site est magnifique, je ne quitte pas forcément mon lecteur de flux pour autant. Je suis donc sensible à la possibilité de laisser du choix au lecteur.

Problème : je n’ai pas envie de sacrifier mes notes de marge, ce n’est pas une coquetterie mais un choix parfaitement réfléchiJ’en parle dans la Note à l’attention du lecteur au début de ma thèse.
 ; mais revoir leur mise en œuvre est complètement hors de ma portée pour le moment, car c’est un problème de programmation qui n’a rien de trivialVoir l’état de l’art de Gwern Branwen sur le sujet.
. Alors j’ai cherché une idée alternative. Et j’ai fini par trouver un petit compromis qui passe justement par le flux.

Le flux comme mode d’accès alternatif

Dans un billet précédent, j’explique que pas mal de choses sur mon site ne sont pas créées automatiquement. Les listes sur la page d’accueil par exemple sont faites à la main. Je n’utilise pas un générateur de site tout prêt mais un script maisonSi vous voulez en savoir plus, vous pouvez lire mon billet « Dr Pandoc & Mr Make ».
, donc si je veux automatiser quelque chose, je ne peux pas juste activer une fonctionnalité, je dois apprendre comment la fabriquer. Souvent, je voudrais automatiser quelque chose mais je n’ai pas assez de connaissances en programmation, ni assez de temps pour en acquérir. Alors je le fais à la main. Or si certaines choses sont rapides à faire, d’autres sont beaucoup trop chronophages. Le flux tombe dans la deuxième catégorie. C’est pour ça que j’avais fini par le réduire au minimum fonctionnel.

Récemment, j’ai enfin trouvé un moyen d’automatiser en partie la création de ce flux. Et par ricochet, cela va me permettre de donner accès à mes publications par un canal plus standardisé.

La solution que j’ai trouvée est à ma portée, c’est-à-dire qu’elle utilise des outils que je connais bien : c’est une commande Pandoc, dans un script shell, dans une Action rapide Automator (le logiciel d’automatisation de macOS). Voilà comment ça marche.

D’abord, j’utilise Pandoc pour générer une entrée de flux Atom à partir d’un texte en Markdown. Il y a un petit jeu sur les formats : une entrée de flux Atom, c’est un fragment de XML, avec des balises correspondant aux métadonnées de la publication (notamment son URL) ; mais il y a aussi et surtout la balise content, qui peut contenir du HTML, dans lequel on met typiquement le texte de la publication. Donc ici, j’utilise Pandoc pour générer du HTML (à partir de Markdown) et l’insérer dans un fragment de XML.

Ensuite, j’enchâsse cette commande Pandoc dans un script shell, qui sert notamment à récupérer le nom du fichier et son chemin complet, afin de générer l’URL ; l’information est passée à Pandoc qui l’insère au bon endroit dans le modèle que j’ai rédigé.

Enfin, le script shell est lui-même enchâssé dans une Action rapide Automator, qui crée un bouton cliquable dans mon explorateur de fichiers. Pour déclencher le script, je sélectionne un fichier et je clique sur le bouton, ce qui insère le résultat dans mon presse-papiers.

Voici le script, légèrement simplifié au niveau des chemins (voir la capture d’écran d’Automator plus bas pour le script exact) :

pbcopy < /dev/null
for f in "$@"
do
    filename=$(basename "$f")
    fname="${filename%.*}"
    /opt/homebrew/bin/pandoc "$f" \
        -t html5 \
        --template=flux-blog-complet.txt \
        --wrap=none \
        -V chemin="$fname" \
        --citeproc \
        --bibliography=references.json \
        --csl=iso690-author-date-fr-no-abstract.csl
done

Voici le modèle flux-blog-complet.txt qui est appelé dans la commande ci-dessus. Les mots entre dollars $ sont des variablesPour plus d’informations sur le système de templating de Pandoc, consultez la section Templates dans le manuel utilisateur.
. La plupart sont définies dans l’en-tête YAML du fichier Markdown que je souhaite convertir mais il y a aussi la variable chemin, définie directement dans la commande Pandoc via l’option -V, et dont la valeur a été obtenue grâce au script shell.

<entry>
<title>[Blog] $title$</title>
<link href="https://www.arthurperret.fr/blog/$chemin$.html" rel="alternate" type="text/html" title="$title$" />
<updated>$date$T09:00:00+02:00</updated>
<id>https://www.arthurperret.fr/blog/$chemin$.html</id>
<author><name>Arthur Perret</name></author>
<content type="html">
$body$
</content>
</entry>

Et voici quelques captures d’écran de l’Action rapide qui permet de déclencher tout ça :

Reste une partie manuelle : je colle le fragment de XML dans mon fichier de flux, puis je transforme la partie textuelle de l’entrée – c’est-à-dire le contenu HTML de la balise content – de manière à respecter le standard Atom. Il faut en effet remplacer les caractères spéciaux comme < et > par des entités HTML. Pour cette dernière étape, j’utilise mon éditeur de texte fétiche, BBEdit.

On pourrait sûrement faire mieux, mais le plus facile pour moi c’est de bricoler une base de travail avec des outils familiers, pour ensuite essayer de l’améliorer progressivement, parfois jusqu’à remplacer tous les éléments d’origine. L’essentiel, c’est que ça marche.

Le Web multi-formats

Ce système me permet de répondre en partie aux critiques de Christophe Masutti. Je ne peux pas facilement transformer mon site mais je peux au moins fournir un mode de consultation alternatif plus accessible. Maintenant que c’est en place, je peux revenir périodiquement dessus pour améliorer les choses, notamment la commande Pandoc qui crée les entrées de flux, pour traiter un à un les différents éléments qui posent problème (comme les notes de marge). Ceci me permet de maintenir mes choix de design sans fermer la porte à certains lecteurs soucieux de maîtriser leur expérience de lecture.

À plus long terme, on pourrait imaginer un autre développement : publier carrément une version alternative du site, genre text.arthurperret.fr, à l’image de la version texte du site de la NPR américaine. Ce serait là aussi une version optimisée pour des modes lecteur ou des interfaces textuelles, mais avec l’entièreté du site plutôt que juste un flux chronologique.

Cette dernière idée m’a fait penser à quelque chose. Ces derniers mois, j’ai parlé plusieurs fois de publication multi-formats à partir d’une source unique (single-source publishing). J’étais resté globalement dans la perspective de ma thèse, c’est-à-dire que je pensais à « multi-formats » comme « formats de fichiers différents ». Mais en écrivant ce billet, je réalise qu’on peut très bien appliquer cette logique lorsqu’on fabrique des exports qui ont le même format de fichier mais qui sont structurés et présentés différemmentEn fait, j’y avais déjà consacré un billet, « Enseignement et automatisation avec Pandoc ». Je prenais comme exemple une liste d’exercices, avec une version PDF sans solutions et une autre avec solutions. Ça m’était sorti de la tête et là c’est revenu d’un coup.
. Faire du multi-formats, ça peut aussi être le fait de documentariser ou d’éditorialiser l’information de différentes manières.

Le Web est déjà multi-formats : on peut y publier toutes sortes de fichiers, pas juste des pages web. Mais du coup j’imagine une approche multi-formats du Web qui serait une sorte de « HTML Zen Garden » (en référence au CSS Zen Garden) : on visite une page, on clique sur un bouton et on arrive sur une version alternative, issue de la même source mais structurée différemment. Dans le cas de mon site, on pourrait avoir un bouton qui permet de visiter une version plus standardisée (au niveau HTML). Mais ça pourrait aussi être une version sans images (remplacées par du texte alternatif), pour économiser de la bande passante ; ou une version dans laquelle les citations sont au format auteur-date plutôt que note.

Bref, cette petite expérience m’a donné à réfléchir et conduira peut-être à d’autres bricolages dans le futur.