Quand on pense à publier son livre :
- On imagine d’abord le livre physique.
- Ensuite, on se rappelle des liseuses qui permettent de lire des livres numériques.
- Puis, pourquoi pas des sites de publication « communautaires » comme Wattpad, pour ne citer que celui-ci.
- Ou alors des blogs WordPress transformés en support de contenus littéraires, mais dont l’harmonisation des règles typographiques dans l’éditeur WYSIWYG sur les dizaines d’articles d’un roman est laborieuse.
- Enfin, une version Docx ou PDF, mais dont le défilement de centaines de pages sur son PC rend la pratique de lecture insupportable.
Cela fait pas mal de supports pour son livre. Mais il en est un qui, semble-t-il, est passé un peu à la trappe de nos jours : le bon vieux HTML, où la page et ses pages liées forment le livre.
Qui se souvient de l’ère où l’on fabriquait nos sites avec un bloc notes, voire Dreamweaver pour les plus fantaisistes d’entre nous ? Où est passée cette envie de manipuler les blocs pour en contrôler l’apparence au pixel près ? Bon, on pouvait aussi faire n’importe quoi, en posant un arrière-plan papier peint rose et jaune fluo et des GIFs épileptiques, mais ça, c’est un autre débat.
Avant, les pages étaient moches et contraints aux standards balbutiants de l’époque. Le HTML et le CSS étaient incomplets, on utilisait salement les tableaux et du JS pour combler le manque de fonctionnalités des navigateurs.
Maintenant, avec le HTML 5, on a la possibilité de faire de belles choses, incorporer des images, vidéos, pistes audio. Le web a été rendu accessible aux personnes avec des déficiences visuelles, ce qui est un avantage incroyable sur le livre physique ou les liseuses.
Mais voilà. À part ceux qui se sont exercé à la personnalisation d’un blog pour la lecture de romans, la plupart des auteurs utilisent maintenant des plateformes aux possibilités limitées, plateformes qui se permettent de poser des publicités sans vous reverser le moindre centime, qui vous noient parmi la masse à cause de leurs algorithmes, ou qui ne concentrent que des auteurs — je rappelle que le but, c’est d’être lu·e… et accessoirement de vivre de son écriture, mais c’est aussi un autre débat.
J’imagine que tout le monde ne peut se permettre de payer un hébergement web. Mais de toute façon, si vous écrivez, vous n’aurez pas le temps de regarder Netflix / Crunchyroll / Disney+ / <votre service de streaming préféré>, donc autant couper votre abonnement, et le problème est réglé… Revenez ! Je plaisantais ! Plus sérieusement, vous avez des solutions pas chères, à base de 2€/mois chez un grand hébergeur français + 7€/an pour un nom de domaine en .fr en cherchant un peu un registraire pas cher. 31€/an en tout, c’est quand même pas cher pour avoir son petit chez soi numérique, je trouve.
J’imagine qu’il y a des réticences, vis-à-vis du piratage. C’est facile, de partager un ou plusieurs fichiers HTML. Alors que pour un fichier Kindle ou Kobo, il suffit de mettre un DRM pour limiter sa propagation illégale. Mais bon, je pense être quelqu’un de pessimiste, donc j’aurais tendance à penser qu’un pirate arrivera toujours à ses fins quand on parle de DRM. Et puis, quelqu’un qui pirate n’aurait probablement pas acheté le livre en premier lieu.
J’imagine qu‘apprendre le HTML et le CSS pour quelqu’un qui ne travaille pas dans le milieu du web peut se révéler être un défi insurmontable. OK. Ça, c’est un problème.
Ce qui me fait demander la chose suivante : y a-t-il des gens qui ont conçu un logiciel pour créer des sites web pour publier des livres ?
Pour tenter de répondre à cette question, j’ai passé de nombreuses soirées en septembre 2022, à étudier les solutions existantes. Parmi les candidats les plus sérieux, j’ai vu Jupyter, Docbook, Google Docs, sans qu’aucun ne me donne satisfaction. Ils étaient trop compliqués, incomplets, difficilement extensibles, parfois avec un résultat loin d’être parfait.
Donc, comme on dit : on n’est jamais mieux servis que par soi-même.
Voici les fonctionnalités qui m’intéressaient :
- N’avoir à contribuer qu’une seule fois, parce que c’est une perte de temps de mettre en page X fois le même contenu pour chaque support de lecture désiré.
- Avoir un contrôle total sur le contenu : insertion d’images, de liens, de fichiers audio, de vidéos…
- Avoir un contrôle total sur l’apparence : police, couleur, taille, graisse, incises, notes de bas de page, alinéas, positionnements…
- Pour l’export HTML, lecture accessible aux personnes avec des déficiences visuelles, découpage des chapitres en pages distinctes, SEO, mode clair / sombre.
- Gestion automatisée des guillemets pour les dialogues.
- Une table des matières automatisée, et une création automatisée de liens entre les chapitres.
Pour gérer tout ça, j’ai trouvé Pollen. Pollen, c’est un langage qui offre la possibilité de mêler code et contenu. Je partage la vision de l’auteur principal sur ce sujet. C’est la voie à suivre pour se libérer des formats, pour que le contenu soit défini à un seul endroit et déployé sur autant de supports qu’il y a de codes de conversion.
Le code utilisé par Pollen est assez difficile à maîtriser. C’est du racket, un dialecte du Lisp, ce fameux langage bourré de parenthèses. Mais une fois que la base est faite, on n’y touche plus, et il ne reste qu’à baliser son contenu.
Concrètement, pour chaque format dont on veut un export, il faut créer un patron (un template), et faire les adaptateurs qui vont transformer le document source dans la syntaxe du format voulu.
Exemple
L’exemple porte sur le premier chapitre de TNBS. J’y montre :
- Le document source : c’est le fichier sur lequel la personne en charge de l’édition est censée travailler. Elle prend le travail de l’auteur, et pose des balises. Ces balises peuvent déclencher des fonctionnalités spécifiques. Par exemple, mes balises de citation ajoutent automatiquement des guillemets, dans le style français, avec des espaces insécables.
- Le document converti : c’est le fichier qu’on obtient après passage par le système de template et de conversion. J’ai créé le template HTML, ce qui permet donc d’avoir le fichier HTML correspondant au document source.
- Le rendu final, dans un navigateur.
Document source
Comme on peut le voir, c’est bien moins pratique qu’un éditeur wysiwyg. Je n’utiliserai pas ça pour écrire, mais pour éditer, surement.
Conversion en code HTML
Rendu final dans un navigateur
Conclusion
Je fais donc partie de ces gens qui ont conçu un logiciel pour publier des livres. Bon, je n’ai fait qu’utiliser à bon escient Pollen, faire le template, du CSS et un peu de JS, mais quand même.
À terme, j’ai prévu d’enrichir ce document Pollen en y ajoutant de la voix enregistrée à attribuer à chaque élément, de la musique, des illustrations… Tout autant de choses qu’il faudra ignorer ou gérer différemment selon le format cible. Mais toujours dans l’esprit : 1 contenu, pour X formats.
La question est maintenant la suivante : vais-je mettre à disposition mes scripts ? Et bien, on en reparle quand j’aurai plusieurs milliers de lecture. Oui, je boude, parce que personne ne me lit.
Bref. Vous avez pu voir la façon que j’ai choisie pour diffuser mes travaux en HTML. Elle ne nécessite aucun serveur PHP ou JS. C’est ce qu’on appelle des sites statiques dans le milieu du web.
Vous avez pu voir que cette méthode pourra servir à créer autre chose que du HTML, sans avoir à retoucher le contenu, car le contenu est transformé par du code, et que ce code est personnalisé.
Peut-être avez-vous une meilleure façon de faire, et en ce cas, n’hésitez pas à la partager.
J’espère en tous cas avoir instillé en vous cette idée qu’une page web bien faite peut être un support idéal pour diffuser un roman. Et surtout qu’on pourrait techniquement arrêter de s’embêter à faire plusieurs fois le travail d’édition sur le même contenu pour chaque support supplémentaire.
Laisser un commentaire