Skip to content

📖 Publier des livres avec un gĂ©nĂ©rateur de site statique

Note : Ceci est un article de Antoine Fauchié sous licence Creative Commons BY-SA publié initialement sur le site Jamstatic (communauté francophone des utilisateurs de générateurs de site statique).

Une version anglaise de l’article est Ă©galement disponible sur the New Dynamic.


 

Suite Ă  la parution du procĂ©dĂ© de publication numĂ©rique basĂ© sur Git et Middleman d’un Ă©diteur, Antoine FauchiĂ© est allĂ© poser quelques questions Ă  Eric Gardner, dĂ©veloppeur et designer au sein de l’équipe d’édition numĂ©rique de The Getty, un campus culturel et de recherche situĂ© Ă  Los Angeles.

 

Comment et pourquoi en ĂȘtes vous arrivĂ©s Ă  choisir un gĂ©nĂ©rateur de site statique comme clĂ© de voĂ»te de votre processus de publication aux Ă©ditions The Getty ? Pourquoi ne pas avoir optĂ© pour un dĂ©veloppement natif ?

Lorsque j’ai commencĂ© Ă  travailler chez The Getty, le programme de publication numĂ©rique Ă©tait assez rĂ©cent. Il y avait eu prĂ©cĂ©demment plusieurs expĂ©rimentations qui adoptaient toutes une approche CMS plus traditionnelle ainsi qu’une application mobile dĂ©veloppĂ©e par un prestataire externe, mais au bout de quelques annĂ©es ces projets sont devenus difficile Ă  maintenir.

Je voulais expĂ©rimenter une chaĂźne de production statique pour plusieurs raisons. PremiĂšrement, je voulais m’assurer que notre travail demeure accessible aussi longtemps que possible. Les Ă©volutions technologiques sont rapides, mais l’édition universitaire est un processus lent – particuliĂšrement dans les domaines comme l’histoire classique ou de l’histoire de l’art, oĂč la recherche peut se faire sur des dĂ©cennies. Personne ne voudrait publier chez nous s’ils avaient peur que leurs travaux disparaissent deux ans plus tard. Un logiciel complexe comme un CMS ou une application mobile nĂ©cessitent une maintenance constante pour rester viable ; vous ne pouvez pas continuer de publier de nouveaux livres si la contrainte de la maintenance augmente Ă  chaque projet. C’est vraiment de ça dont il est question avec un gĂ©nĂ©rateur de site statique, on espĂšre que le produit final fonctionne pendant longtemps. Et mĂȘme si ce n’est pas le cas, les contenus sous-jacents subsisteront pour toujours sous la forme de fichiers texte lisibles par des humains dans un dĂ©pĂŽt Git.

Notre deuxiĂšme prĂ©occupation Ă©tait la dĂ©pendance Ă  des logiciels propriĂ©taires. Des sociĂ©tĂ©s comme Adobe ou Apple ont crĂ©Ă© des outils trĂšs bien faits, mais qui possĂšde vraiment vos contenus Ă  la fin de la journĂ©e ? Si un produit cesse d’ĂȘtre maintenu, vous ne pouvez pas faire grand chose en tant qu’éditeur – vos travaux seront perdus. Une plate-forme open source semble ĂȘtre l’unique solution pour assurer Ă  vos auteurs et Ă  vos Ă©diteurs le contrĂŽle de leurs documents.

Enfin, comme toute personne ayant une formation en design, je me soucie beaucoup du design et de l’expĂ©rience que nous proposons Ă  nos utilisateurs. Les livres imprimĂ©s que The Getty publie sont vraiment beaux, et je veux faire perdurer autant que possible cette tradition sur le web. Cela tombe bien, un site “statique” n’a pas besoin d’ĂȘtre ennuyeux – les applications statiques HTML, CSS et JavaScript peuvent proposer tout un tas de fonctionnalitĂ©s interactives ainsi q’un design et une typographie de grande qualitĂ©.

 

Comment votre Ă©quipe s’est appropriĂ©e ce nouveau workflow ? L’appropriation a-t-elle Ă©tĂ© facile ?

Il est vrai que publier de cette façon signifie que pas mal de choses vont changer. Heureusement j’ai de super collĂšgues qui Ă©taient prĂȘts Ă  se familiariser avec le nouveau procĂ©dĂ©. Notre Ă©quipe en charge du numĂ©rique a bĂ©nĂ©ficiĂ© de quelques formations “DĂ©marrer avec GitHub” qui ont Ă©tĂ© bien reçues, et Ă©crire en Markdown n’est pas si diffĂ©rent qu’écrire dans n’importe quel autre traitement de texte. J’espĂšre cependant toujours que nous pourrons rendre le procĂ©dĂ© moins pĂ©nible – configurer l’environnement de dĂ©veloppement pour prĂ©visualiser son travail peut encore intimider. J’aimerais dĂ©velopper des outils pour aider Ă  simplifier ce procĂ©dĂ© pour les gens.

 

Est-ce que tu penses qu’un process Ă  base de technologies web peut remplacer le couple dĂ©moniaque Word et InDesign ? ParticuliĂšrement en ce qui concerne la facilitĂ© d’écriture et de structuration des contenus (WYSIWYG) ainsi que la mise en page (InDesign) ?

Je pense qu’on s’en rapproche (et je frĂ©mis Ă  l’idĂ©e d’essayer d’obtenir un texte propre Ă  partir d’un jeu de fichiers InDesign
). Mais nos outils ont encore du chemin Ă  parcourir ; j’ai Ă©cris un article lĂ  dessus sur le blog de The Getty il y a un petit moment. Les gens utilisent Word & InDesign parce qu’ils sont intuitifs et bien pensĂ©s, notre workflow est encore un peu rude en comparaison. Toutefois le monde du texte brut possĂšde des outils vraiment puissants lui aussi : une vĂ©ritable gestion des versions (bien mieux que le systĂšme de rĂ©visions), des Ă©diteurs Ă©tonnamment puissants comme Vim ou Emacs1, la possibilitĂ© de spĂ©cifier ce qu’on veut dire vraiment avec des langages de balisage simples comme Markdown ou Asciidoc, etc. Je pense que l’équivalence visuelle exacte n’est plus l’objectif Ă  atteindre ici. A contrario, des outils intuitifs et fiables, qui essaient avant tout d’aider les gens Ă  exprimer du sens et ce dans plus d’un contexte de prĂ©sentation, c’est plutĂŽt ça la voie Ă  suivre.

 

Est-ce que ce nouveau process augmente la qualité des publications de The Getty ?

Haha, j’ai l’impression que la barre est dĂ©jĂ  assez haute donc je veux dĂ©jĂ  produire un travail de qualitĂ© Ă©quivalente Ă  nos livres papier. Mais l’édition numĂ©rique peut vous permettre de faire des choses qui ne seraient pas possible dans l’édition papier et j’ai espoir que ces nouvelles affordances du mĂ©dium aideront Ă  faire progresser la recherche de façon singuliĂšre. Nous travaillons actuellement sur un livre numĂ©rique dans lequel figure par exemple beaucoup de partitions musicales, pouvoir avoir des annotations, des discussions ainsi que de la lecture audio et vidĂ©o dans un mĂȘme document, c’est quelque chose de vĂ©ritablement passionnant.

 

Est-ce que ce nouveau workflow vous fait gagner du temps et de l’argent ? Y’a-t-il une diffĂ©rence de prix de revient pour les livres, y compris pour les livres papier ?

Cela varie en fonction des maisons d’édition, mais globalement je dirais que non. Des publications de qualitĂ©, cela demande beaucoup de travail de la part de gens spĂ©cialisĂ©s et le format numĂ©rique ne change rien Ă  cela. Cependant il nous permet de rendre disponibles des choses qu’il ne serait autrement pas viable de publier. Depuis que je travaille chez The Getty, nous avons travaillĂ© sur plusieurs catalogues pour des collections d’Ɠuvres d’art. Ce sont principalement des outils de recherche pour une audience assez spĂ©cifique. En publiant d’abord un catalogue en ligne, dans diffĂ©rents formats, nous pouvons rendre cette information (y compris des images interactives de grand qualitĂ©) disponible pour les spĂ©cialistes. Et la possibilitĂ© de gĂ©nĂ©rer un fichier PDF Ă  partir de la version web signifie que les gens qui veulent une copie imprimĂ©e pourront toujours en acheter une, grĂące Ă  notre offre d’impression Ă  la demande. Donc dans ce genre de situation, je pense que la publication numĂ©rique peut aider Ă  certains projets Ă  devenir plus rentables.

 

Quelles sont les contraintes auxquelles vous vous heurtez encore aujourd’hui ? Quel serait votre workflow idĂ©al ?

Tout Ă  l’heure j’ai dit que le fait de configurer un environnement de dĂ©veloppement, de travailler avec les outils de programmation plus bas-niveau (comme Git) peut s’avĂ©rer ĂȘtre frustrant et dĂ©routant pour les non-programmeurs et que ces outils pourraient ĂȘtre amĂ©liorĂ©s. J’aimerais une application avec une interface simple qui facilite l’écriture en Markdown, branchĂ©e sur Git et qui permette de faire des choses comme choisir un modĂšle de livre, sans forcer l’utilisateur final Ă  se soucier de la gestion de dĂ©pendances ou de l’installation de librairies2.

Est-ce que tu penses que d’autres maisons d’édition vont adopter Ă  leur tour cette stratĂ©gie avec des gĂ©nĂ©rateurs de site statique (pas de WYSIWYG, un balisage lĂ©ger, pas de base de donnĂ©es, des mĂ©tadonnĂ©es YAML, versionnement avec Git, etc.) ? Est-ce qu’un courant pourrait se former autour de ce concept ?

Des collĂšgues qui travaillent pour d’autres musĂ©es m’ont fait part de leur intĂ©rĂȘt. Pour le moment, je ne pense pas que quelqu’un ait publiĂ© un livre Ă  l’aide de ce procĂ©dĂ©, mais j’espĂšre bien que ça changera bientĂŽt. Une fois que nous aurons un peu affinĂ© notre procĂ©dĂ©, je prĂ©vois de faire un peu plus dâ€™â€œĂ©vangĂ©lisation” 😉

English version published on the New Dynamic


  1. NdT: Des Ă©diteurs comme Sublime ou Atom sont aussi puissants et encore plus accessibles. ↩
  2. NdT: Le projet GitBook adopte cette dĂ©marche. ↩
Creative Commons License Attribution-ShareAlikeRepublish
Published indevLes Internets

Be First to Comment

Laisser un commentaire

×

đŸ‡ș🇾 🇬🇧 REPUBLISHING TERMS : You may republish this content online or in print under the Creative Commons license of original content.

đŸ‡ȘđŸ‡ș đŸ‡«đŸ‡·Â  CONDITIONS DE PARTAGE : Vous pouvez republier ce contenu en ligne ou sous forme imprimĂ©e est respectant la licence Creative Commons en vigueur.

 

License

Creative Commons License Attribution-ShareAlikeCreative Commons Attribution-ShareAlike
📖 Publier des livres avec un gĂ©nĂ©rateur de site statique