Une chaîne du livre libre

Depuis plusieurs mois désormais je travaille à la conception d'une chaîne de production du livre qui ne s'appuie que sur des outils libres. Mon but est de faciliter la production et le suivi technique des ouvrages pour de petites structures ou des auteurs indépendants. Bien évidement, je me sers de mes propres travaux comme terrain d'expérimentation. Cet article propose de faire une synthèse basée sur celle que j'ai faite pour un atelier au Capitole du Libre 2016.

Je ne prétends pas révolutionner les processus de production mais simplement étudier la faisabilité d'une chaîne du livre libre à l'heure actuelle. J'entends par là inclure tous les ouvrages dont la vocation est essentiellement textuelle, excluant donc les ouvrages d'art, de photographie ou ceux dont la mise en forme nécessite le recours à des logiciels de PAO adaptés.

Je me focalise essentiellement sur les besoins des écrivains de fiction, ainsi qu'à tous les processus qui permettent de produire des formats standards de qualité (pdf pour l'impression et epub pour la lecture numérique). J'aimerais aussi que cela offre l'opportunité future de créer des bases de ressources où des ouvrages rares du domaine public puissent être collectivement édités et proposés à la lecture.
Dans la mesure du possible, je tente de trouver des outils qui soient multi-plateforme, bien que je ne les teste que sur GNU/Linux, vu que c'est mon environnement de travail habituel.
Bien évidement, les solutions adoptées que je détaille ici ne valent que pour leur valeur d'exemple et d'adéquation au but recherché. Il est probable que cela ne saurait convenir à tous. Mais il me semble important de démontrer la faisabilité d'une forge du livre libre et d'en promouvoir l'usage.

Le cadre de travail que je préconise est le suivant :

• il faut travailler avec des fichiers texte simple qui puissent être ouverts aisément avec n'importe quel éditeur. Ceci dans l'idée d'en faciliter l'intégration dans d'autres chaînes, si besoin, pour en permettre le suivi par logiciel de type Git ou en faciliter le parsing par des scripts. Pour l'heure je me sers du format Markdown, avec le style pandoc et je pense que je m'appuierai sur le CommonMark dès que sa sortie sera officielle ;
• il faut que l'outil offre une base d'édition de texte de qualité, avec une fonction rechercher/remplacer puissante (avec des expressions régulières), une possibilité d'insertion aisée de signes typographiques précis (ponctuation à la française, espaces insécables) et une puissance d'affichage qui accepte les très longs textes (un roman de plus d'un demi-million de caractères étant un minimum).
• il faut pouvoir travailler sur un corpus de texte et pas un seul document. Ceci afin de gérer la cohérence des œuvres déclinées en plusieurs tomes par exemple ;
• l'outil doit être versatile et ne pas imposer un flux monolithique ou une interface non modulable. Il faut absolument que chaque écrivain puisse régler son outil selon ses habitudes et besoins. Une gestion puissante des plugins (comme le fait très bien Blender pour la 3D) et une IDE acceptant les modifications importantes de l'interface sont des critères importants ;
• même si des apprentissages sont nécessaires, il faudra viser à la plus grande intégration possible et minimiser l'apprentissage technique. Sans exclure, bien au contraire, la possibilité de travailler en ligne de commande, il faut inclure un fonctionnement par souris ou des raccourcis claviers pour toutes les opérations. Devoir apprendre une interface trop exotique pour le commun des utilisateurs est souvent répulsif (j'exclus donc Vim et Emacs) ;
• les formats générés en bout de chaîne doivent pouvoir être modulés pour offrir plusieurs déclinaisons, permettant de toucher le plus grand nombre de personnes, incluant les publics ayant des besoins particuliers. Je pense là tout particulièrement aux personnes souffrant de handicaps, qui ont parfois des matériels nécessitant des conformations techniques spéciales ou, au contraire, un respect le plus strict possible des standards.

Lorsque j'ai fait ma présentation en novembre 2016 à Toulouse, je n'avais pas découvert de logiciel libre spécifiquement dédié au travail littéraire. Depuis lors, on m'a indiqué Manuskript, en python, qui est fortement inspiré des logiciels de type Scrivener ou Ulysses. Je n'ai pas encore eu le temps de le tester de façon avancée, mais il semble très prometteur. Je vais donc prendre contact avec l'équipe de développement.

Jusqu'à présent j'ai essayé de nombreux éditeurs de texte mais aucun ne me satisfaisait véritablement car ils sont généralement pensés pour du développement logiciel ou, au mieux, l'édition de notices annexes, voire de README.md. J'ai donc finalement retenu celui qui offrait le plus grand nombre d'outils que je recherchais, et en particulier plusieurs dédiés à l'édition de fichiers Markdown : Atom.

J'ai pu néanmoins noter de nombreuses carences et je dois subir une interface inadaptée. Les critères qui m'ont fait privilégier cet éditeur sont néanmoins les suivants :

• travail sur un ensemble de répertoires via des projets, usage d'onglets ;
• bon support du Markdown, avec possibilité de prévisualisation HTML ;
• intégration des outils Git ;
• rechercher/remplacer multi-fichier, usage des expressions régulières avec certains limites mais de qualité.

Ce qui me pose le plus de soucis avec cet outil concerne surtout :

• la difficulté d'adapter l'outil à mes besoins (le langage utilisé est le node.js, que je ne connais pas du tout) ;
• une interface parfois lourde et une navigation souvent peu intuitive par rapport à ma façon de travailler.

De façon générale, même s'il offre une plate-forme suffisante pour mes besoins essentiels, Atom n'est pas un outil pensé pour la rédaction de romans, on ne va donc pas lui reprocher de ne pas y exceller. C'est pour l'heure un pis-aller qui permet de travailler de façon correcte.

Il s'agit du point où le monde du logiciel libre est très performant car cela constitue pour lui une nécessité. J'ai finalement opté pour un suivi de version basé sur Git, en m'appuyant sur Gitlab (l'instance Framagit en l'occurrence) pour le travail en commun. Cela est rendu possible et pertinent par le fait que nous ne travaillons pas avec des fichiers binaires.

Un des intérêts de Git/Gitlab, c'est que l'on peut travailler en mode déconnecté, que la décentralisation est possible et la résilience forte. En travaillant au sein d'une équipe, il y a peu de chance de perdre le contenu collaboratif. On peut se servir du système d'Issues pour gérer le travail à faire, les branches permettent de cloisonner les interventions sur les fichiers, dans le cadre de leur finalisation ou passage vers des scripts

Un des principaux soucis vient de la mise au point des workflows de travail, mais c'est là un écueil qui se rencontre dans tous les projets libres. Leur définition aussi bien que leur respect par les différents acteurs de la chaîne constitue un des enjeux de la politique du projet.

La seule véritable difficulté dans cette étape concerne les collaborateurs. S'initier à la logique du versionnage et des outils de suivi en ligne constitue une étape complexe pour des personnes peu familières du monde informatique. Il faut donc rédiger des tutoriels précis et prévoir de la formation adaptée, faire œuvre de pédagogie.

J'en profite pour signaler qu'il existe Booktype, basé sur Django, qui permet de faire le travail d'édition collaborativement ainsi que la publication. Il serait intéressant de voir comment interfacer de la façon la plus pertinente un outil de création en local avec ce moteur sur un serveur distant.

Une fois les fichiers source finalisés, il faut en extraire différents formats de la façon la plus automatisée possible. Ceci dans l'idée de faciliter la correction de coquilles en amont ou la réédition. Même si cela peut-être nécessaire, la retouche manuelle doit être minimale et notée dans la chaîne de procédure du fichier pour éviter les erreurs et le travail futur une fois les opérations mises en place.

Pour l'heure, il faut pouvoir générer du pdf pour l'impression et de l'epub pour la lecture sur support électronique. Pour le premier, le choix de LaTeX est évident, mais demande pas mal d'ajustements pour obtenir exactement ce que l'on veut. Pour l'heure, c'est encore généré manuellement, mais il faudrait arriver à mettre en place des scripts qui lisent un fichier de configuration et appliquent donc les paramètres et ajustements souhaités. Cela reste à définir.

En ce qui concerne l'epub, je m'appuie sur le convertisseur pandoc, extrêmement puissant. Il offre la possibilité d'accepter en entrée des fichiers tiers, de métadonnées, de feuilles de styles, de polices de caractères ou de gabarit. J'ai réalisé des scripts python qui me permettent de générer les documents à l'aide de fichier de configuration standardisés. Cela ne fonctionne pour l'heure qu'en ligne de commande mais génère des fichiers de bonne facture. Il demeure malgré tout quelques ajustements pour parfaire l'accessibilité.

Mes anciens lecteurs auront d'ailleurs remarqué que je propose désormais deux formats epub dont le second utilise une feuille de style légèrement différente. L'utilisation de scripts me permet d'automatiser cela aisément, et donc de faire une version avec la police de caractère Opendyslexic qui doit rendre plus facile la lecture pour les personnes atteintes de dyslexie (en théorie). Le cas échéant, je peux facilement décliner d'autres versions (ou modifier le gabarit de celle-ci) et générer de nouveaux fichiers.

Bien que j'en plébiscite l'usage, j'ai noté quelques soucis avec pandoc, en particulier au niveau de la gestion de la typographie. Il ne semble pas tenir compte des espaces insécables indiqués dans le Markdown, à moins de les transformer sous une forme HTML (&nbspace;), ce que j'exclue de faire lors de la rédaction car cela gêne le flux de lecture, atout du format markdown. C'est donc réalisé par les scripts python d'export avant le passage vers pandoc. J'ai attiré l'attention des développeurs de pandoc sur ce problème mais il semblerait qu'ils excluent une responsabilité de leur système. Peut-être ai-je mal compris certaines options, cela demeure à étudier. Nous sommes en pleine discussion sur ce sujet.

Un autre aspect possible de la publication concerne la diffusion sur un site Internet. J'ai opté pour un moteur de CMS sans SQL, par fichiers .txt simples et qui possède en outre l'avantage de pouvoir être versionné par Git : Dokuwiki. En outre, son fonctionnement pensé pour le collaboratif offre tous les outils souhaités pour prendre place au sein d'un projet de groupe. Je génère donc également des pages pour le site, de façon automatique à l'aide, là encore, de pandoc et de python.

Dans le cadre de projets plus ambitieux, il me semble que des solutions plus robustes, basées par exemple sur Django (voir Booktype ci-dessus, par exemple), pourraient aisément être déployées, offrant la possibilité d'intégrer de façon continue le passage d'une étape à l'autre. L'usage d'un seul langage de programmation, python, d'ailleurs répandu dans le monde artistique des studios de jeu vidéo, me semble un aspect à privilégier. D'autant qu'il est souvent mis en avant pour sa courbe d'apprentissage aisée. J'en suis d'ailleurs un exemple.

Enfin, il se pose la question de la distribution/diffusion des ouvrages, en plus de la mise à disposition sur un site Internet. Là encore, je crois qu'il serait possible de faciliter et organiser les étapes via un outil modulable qui permette de transférer les métadonnées sans devoir les ressaisir, de préparer des fichiers ou des archives aux bons formats etc., avec l'aide de plugins spécifiques à chaque plateforme, chaque partenaire. La question se posera néanmoins à chacun selon ses propres nécessités.

Au final, il est dès aujourd'hui possible de travailler uniquement avec des outils libres pour produire des livres de qualité. C'est d'ailleurs ce qui se fait au sein de Framabook.Mais cela demande une gymnastique intellectuelle assez importante et le dévoiement d'outils pas vraiment conçus pour l'usage qu'on en fait.

L'étape éditoriale par exemple constitue encore une gageure, car elle inclut des membres parfois peu à l'aise avec l'outil informatique, et carrément épouvantés à l'idée de devoir se confronter à la ligne de commande. De la pédagogie demeure à faire, des procédures claires nécessiteront d'être définies, mais cela ne sera pas suffisant. Il s'agit là d'un public dont la formation est aux antipodes de la culture technique informatique et leur proposer des outils intégrés et conviviaux est une nécessité. Actuellement la montée en compétence technique est trop importante.

Le recours à un système intégré me semble préférable, mais il devra inclure une souplesse d'usage assez grande pour s'adapter à des idiosyncrasies très diverses. C'est une nécessité absolue si on veut que les différents types d'écrivains puissent s'approprier l'outil. Le cœur du système doit se focaliser sur la qualité des outils d'édition de texte pour la littérature, inclure les outils de gestion de la chaîne selon ses besoins et envies, et gérer le tout par des plugins aisément désactivables ou dont la programmation soit facilitée. Les fonctionnalités telles les notes, les fiches de personnages doivent être gérées de la même façon : activées par simple clic.

Il s'agit là d'un projet complexe et ambitieux, je n'en suis qu'aux prémices. À terme, en plus de l'usage que je souhaite en faire pour ma propre production littéraire, ou celle que pourraient en faire d'autres écrivains, j'aimerais que cela puisse servir à remettre en forme et à disposition des ouvrages rares du domaine public. Des regroupements d'intérêt pourraient s'organiser et proposer ainsi des publications récentes de qualité pour des textes anciens importants ou fondateurs dont les versions électroniques sont de pauvre qualité, les tirages papiers introuvables ou avec un prix prohibitif, voire le tout ensemble.