Associé·es pour ce projet au Salon de l’édition alternative en 2017, Julie Blanc et Quentin Juhel ont produit l’édition Code X sous la forme d’un journal.
Code X présente différents protagonistes du salon ainsi que leurs projets et desi des extraits de réflexions sur les notions d’outils numériques et open source, ainsi que des outils libres.
Tous deux produisent avec une approche « libriste », initiée dès leurs études.
Au sein d’une équipe de développeurs·euses et de graphistes, Julie Blanc produit Paged.js, un outil permettant de produire des mises en pages avec les technologies du web.
Le projet Code X a été entièrement produit avec les technologies du web, expérimentales et présentant leurs limites tout comme l’agrégation des textes faite par le biais d’un gestionnaire de contenus.

FJ : À l’occasion du Salon de l’édition alternative à la Gaîté Lyrique en 2017, vous aviez produit ce catalogue avec ces différents projets qui utilisent des types de conception alternatifS et donc vous êtes partis sur des technologies web, quels étaient les avantages et inconvénients de cette pratique ?

JB : C’était la première fois que j’utilisais vraiment le web pour faire de l’imprimé, c’était un projet « test », c’est Emmanuel Cyriaque [directeur de la maison d’édition HYX] qui me l’avait proposé, j’avais alors proposé à Quentin de travailler dessus, nous devions le faire en une semaine.

Les avantages du web, il y en a plein, pour ce projet ce n’était pas tant les avantages mais de montrer que c’était possible.

Raphaël Bastide, qui avait organisé le salon, avait mis en place un CMS [gestionnaire de contenu] pour demander aux participants de mettre leurs projets et leurs présentations dessus. Cela nous a donc permis de récupérer le contenu directement depuis le CMS.

Les inconvénients c’est qu’à l’époque, j’avais utilisé un polyfill de CSS regions, et il rendait la page très longue à charger et c’était difficile à découper, parce que ça restait très instable.

QJ : Je vais revenir sur le terme « catalogue » : ce n’était pas vraiment un catalogue, c’était plutôt un objet manifeste. C’était le deuxième événement de PrePostPrint qui était marqué par la rencontre de différents acteurs : graphistes, développeurs, chercheurs, éditeurs, qui faisaient et qui font encore des publications imprimées avec les langages du web. Donc il s’agissait d’une réunion réelle, avec une réunion entre nous et avec le mini-festival, et cet ouvrage est à la fois un catalogue des gens présents, des potentialités du web2print ainsi que d’autres langages de programmation. Cela a été assez compliqué à mettre en place, notamment ces questions de polyfill. Tu vois ce que c’est qu’un polyfill ?

FJ : Non, justement, j’allais vous poser la question.

QJ : Ce sont des scripts qui vont permettre d’interpréter d’autres langages qui ne sont pas connus ou implémentés dans le navigateur de base. Par exemple le polyfill dont nous parlions, était des CSS regions : donc des spécifiés CSS écrites pour pouvoir faire de la mise en page assez dynamique, en ayant une vraie mise en page liquide. Il n’a pas été implémenté très longtemps dans le navigateur. Ainsi des personnes ont créé des scripts en JavaScript pour interpréter ces règles de styles CSS, pour faire en sorte de faire comme si l’on faisait du CSS regions dans le navigateur.

JB : La problématique du web, c’est que c’est un flux, mais lorsque nous mettons en page nous avons besoin de découper ce flux de textes, en bloc pour en faire des pages. Cette fonctionnalité n’existe pas dans le web, le CSS regions c’est une proposition pour faire ça. Mais comme l’indique Quentin, cela a seulement été implémenté pendant un laps de temps très court – peut-être moins de 3 ans sur Chrome, dans le moteur de rendu Webkit. Alors c’est assez rare, d’habitude tout ce qui est implémenté sur le web, n’est jamais détruit – pour le coup c’est vraiment un contre-exemple. Donc, quelqu’un a mis en ligne un script qui simule cette fonctionnalité.

Un polyfill c’est comme un pansement : on vient faire en sorte que quelque chose qui ne marche plus puisse quand même marcher.

QJ : L’enjeu était déjà que Julie et moi, n’avions jamais collaboré. J’avais déjà fait un peu de web2print notamment avec des workshops avec OSP [Open Source Publishing] puis avec un stage chez Sarah Garcin. Mais je n’avais pas travaillé dans un projet de cette petite envergure : avec un éditeur, des graphistes, etc… C’était un des premiers projets indépendants dans une première collaboration avant notre rencontre à l’ENSAD Lab. C’était intéressant et aussi un peu stressant !

JB : C’est pour cela que j’avais demandé à Quentin de faire le projet, parce qu’il venait d’arriver à l’ENSAD Lab, moi j’y étais. Je m’étais dit que c’était l’occasion, puis j’avais appris qu’il avait fait un stage avec Sarah Garcin qui organisait aussi PrePostPrint et qui m’avait demandé avec Raphaël Bastide de faire l’édition. C’est aussi un petit milieu. Emmanuel Cyriaque, qui était l’éditeur, nous a demandé de réaliser Code X deux semaines avant de le produire. C’est pour cela que c’était difficile : cela devait être fait rapidement sur des technologies instables ; c’était le challenge aussi, c’est pour cela que j’avais accepté. Et j’étais aussi dans l’organisation de ce PrePostPrint là, j’avais rencontré Sarah et Raphaël au premier qui avait eu lieu en avril 2017, et là c’était en octobre à la Gaîté Lyrique.

FJ : Qu’est-ce qui vous a poussé à ce qu’il prenne la forme d’un journal ?

JB : C’était imposé par l’éditeur, parce que c’était moins cher et que nous pouvions passer par des structures en ligne, pouvant livrer en deux jours.

QJ : C’est l’immédiateté du projet dans les délais. L'éditeur avait dans l’idée de faire plusieurs numéros. Il fallait créer très rapidement, l’imprimer très rapidement : ce qui nous offrait ces possibilités c’était le print on demand et de faire ensuite un journal papier.

JB : Il fallait que l’objet ne soit pas cher pour que les étudiants puissent l’acheter. C’était aussi une volonté de PrePostPrint.

Heureusement qu’il y avait un format imposé, compte tenu du peu de temps que nous avions pour produire l’objet.

FJ : L’agrégation des textes se faisait par le CMS ?

JB : Oui, c’est Raphaël qui avait fait ce CMS.

QJ : Il me semble que l’on a utilisé son CMS ADAAD, qui est son workflow qui lui permet de tout générer à partir de fichiers Markdown ou HTML. C’est un outil que l’on retrouve sur son gitlab, qu’il a fabriqué pour son workflow, pour son tunnel de production, où il peut récupérer des contenus, les traiter, avoir des exports différents et enfin pouvoir en faire des sites web, des epubs, des pdfs etc…

JB : Cela a permis d’éviter d’envoyer mille mails aux participants.

QJ : Julie pourra sans doute mieux l’expliquer, mais la force de l’usage des langages du web est de construire des tunnels.

Cela permet de tout centraliser pour ne pas se perdre dans des milliers de fichiers, de récupérer des contenus standardisés dans des langages avec une sémantisation du contenu comme dans le Markdown l’HTML ou ASCII-doc, puis d’avoir des scripts PHP qui permettent d’interpréter ces langages-là, pour avoir des outputs en HTML et de faire du CSS et du JavaScript pour générer des éditions ou des sites. C’est la force de faire de la conception avec ces langages, car cela permet de mélanger rapidement création graphique, rédaction, agrégation de contenus et correction des éditeurs etc…

Ce n’est pas encore fréquent dans les workflows, mais nous en voyons toute la potentialité.

JB : Sur les chaînes éditoriales, ce n’est pas fréquent pour des designers, mais dans les maisons d’édition, ils se posent ces question-là. Chez Hachette US, cela fait quinze ans qu’ils font des livres avec de l’HTML et du CSS, ce n’est pas très poussé graphiquement, mais ils le font quand même.

[…]

JB : Il y avait aussi des textes open source écrits dans cette édition ; puis la dernière page était sur les ressources. C’était aussi un manifeste par ces parties sur ces pratiques non conventionnelles.

QJ : Quand je disais manifeste, ce n’est pas tant par le discours mais plus par l’objet. Dans le monde de la production industrielle, c’est en fait assez lambda. Pour les graphistes venant des écoles d’art et de design, ce n’est pas vraiment connu ; aux Arts décoratif de Strasbourg – où j’ai suivi un cursus en graphisme – nous étudions ces techniques de production de livre, d’automatisation de mise en page par des algorithmes.

Nous en avions abordé quelques fonctions mais ce n’est pas ce qui se fait dans le monde industriel ou professionnel.

JB : Quentin dit qu’il n’aime pas le terme « auteur », moi non plus. Mais aussi je n’aime pas le mot « automatisation ». J’évite de le dire car souvent on me rétorque : « Tu fais un livre sans designer !? » ou « tu vas nous piquer notre boulot », alors qu’en réalité l’exécution est programmée, je donne des instructions, la mise en page est programmée mais pas automatisée. Les formes ne sont pas automatiques.

FJ : Question un peu bête : Il aurait été envisageable d’utiliser des techniques mixtes comme l’usage de script sur InDesign ?

JB : Non. Parce que PrePostPrint défend des approches libres ; donc nous n’allons pas aller dans un logiciel propriétaire, même s’il utilise du script. La base de PrePostPrint c’est de défendre le libre.

QJ : C’est l’une de nos positions avec PrePostPrint, de ne surtout pas parler de logiciel et de logique propriétaire. Les deux fondateurs sont des libristes convaincus. Les participants de PrePostPrint viennent pour beaucoup de ce milieu. Nous n’en voyons pas trop l’intérêt.

L’usage de script avec InDesign oblige à rentrer et s’enfermer dans une logique propriétaire. Les scripts utilisent une forme de JavaScript dédiée à une version précise d’InDesign.

Il n’y avait pas d’intérêt à le faire pour ce projet-là. Mais personnellement je ne vois pas trop l’intérêt du scripting InDesign, car maintenant nous savons que nous pouvons réaliser un livre avec un navigateur.

JB : C’est pas du tout le même point de vue. Nous sommes tellement libres avec ces navigateurs et les technologies web, dans le sens où nous pouvons brancher tant de choses ensemble. Alors qu’avec InDesign tu dois développer ton propre script, partir de zéro pour faire un projet.

Alors qu’avec InDesign je crois qu’il n’y a pas de sémantique, alors que c’est super important en HTML. Tu ne peux pas composer sans sémantique : avec <h1> pour les titres <p> pour les paragraphes etc… InDesign, tu as beau avoir des feuilles de style, tu dois sélectionner les éléments.

QJ : Sur InDesign tu peux quand même faire des imports XML

JB : Mais ce n’est pas obligatoire pour l’import…

QJ : Oui en effet, ce n’est pas forcément structuré, contrairement au web. Je n’utilise plus de logiciel propriétaire depuis 3 ans, dans l’enseignement ou dans ma pratique professionnelle.

FJ : Pour rebondir sur ce que tu viens de dire Quentin, et pareil Julie tu n’utilises plus de logiciel propriétaire ?

JB : Pour les livres, je compose avec mon outil page.js. Il y a quand même des choses que je n’arriverais pas à produire autrement que par WYSIWYG [What You See Is What You Get], par l’usage d’interface – je n’aime pas trop Inkscape, mais j’aime bien Affinity Designer mais qui n’a pas la même logique qu’Adobe. Je milite pour le libre aussi.

Quentin et moi, nous sommes aussi dans un milieu spécifique, dans l’enseignement et dans le milieu professionnel – en tant que graphiste, chercheuse et développeuse de Paged.js. J’ai moins la problématique de m’insérer dans un milieu professionnel. C’est aussi compliqué de s’insérer dans un milieu professionnel en étant que dans du « libre » même si on fait appel à nous pour cela.

QJ : Oui, c’est une discussion que nous avons beaucoup eu avec notamment Raphaël Bastide. Il y a des complexités à utiliser du libre. Elles font partie du projet, du cadre que nous nous fixons. Nous avons des positions assez privilégiées : notre situation (enseignant et enseignante-chercheuse) permet d’avoir une certaine sécurité et de faire de l’expérimentation.

Sans ces prérequis, l’usage de ces technologies dans un milieu professionnel semble complexe. À contrario, à l’école, c’est l’endroit où il faut essayer et expérimenter.

JB : Les clients n’ont pas forcément à savoir si nous utilisons du libre ou pas. Quand nous sommes à l’aise avec ces outils et logiciels, on ne voit pas forcément qu’ils sont « libres ». Avec OSP ou Figure Libre par exemple, leurs clients ne savent pas forcément qu’ils sont dans le logiciel libre ; quand il leurs disent, ils sont contents car en général ce sont des ONG, et ils sont dans ces idées-là. Ce que tu donnes à la fin c’est un pdf, peu importe les outils ; parfois cependant les clients demandent les fichiers source pour des raisons particulières.

J’ai dit, à propos d’InDesign, que je ne comprenais pas pourquoi l’utiliser avec des scripts mais ce n’est pas pour autant que l’il ne faut pas le faire.

Je suis pour dire aux étudiants, ce n’est pas grave si vous ne faites pas que du libre ; si vous vous y intéressez et que vous y allez petit à petit c’est le plus important. Moi personnellement, c’est ce qui m’avait freiné au départ.

FJ : Pour essayer de rebondir, Quentin, tu trouves des alternatives à chaque fois pour des logiciels propriétaires, ou c’est plus compliqué que ça ? Question très bête , est-ce qu’il y a un équivalent à photoshop, j’imagine que non, faut mixer différents logiciels ?

QJ : Tout dépend de ta pratique, et dans celle des gens que je côtoie (OSP, Figure libre, Bonjour Monde), ce n’est pas dans l’optique de trouver des alternatives ; c’est plus de trouver des outils qui vont nous déséquilibrer ; de trouver des formes graphiques, dans un cadre de recherche plutôt expérimentale. Ce n’est pas la recherche d’alternatives qui nous motive, ce sont plus les formes, la recherche de scripts etc…

Après il existe des alternatives, par exemple pour photoshop – dans le cadre du dessin en bitmap, il existe Gimp ou Krit qui n’ont pas la même UI que Photoshop ou Affinity photo – mais qui sont très intéressants, dans le traitement photographique Gimp est très fort.

Je passe plus de temps à produire des bouts de code, à récupérer des librairies, à tester des outils pas forcément conçus pour faire du graphisme, pour chercher des formes graphiques et trouver de nouvelle façon de faire. Plus dans l’expérimentation, même si je n’aime pas le terme « expérimentation » car il exclut une application professionnelle. Il y a un très beau texte d’OSP qui résume cette idée : qui s’appelle « la caravane » disponible sur f-u-t-u-r-e.

JB : Parler d’« alternative », c’est aussi penser en termes de logiciel, et avec le libre, c’est bien plus hybride. Nous pouvons utiliser des logiciels en ligne de commande (sans-interface), être donc plus dans une logique d’outils. Nous sommes plus adaptés au logiciel car l’apprentissage en graphisme passe par les logiciels. Par exemple pour changer le format d’une image, tu peux le faire sur Photoshop, mais en réalité tu peux le faire en ligne de commande, et l’effectuer sur tout un dossier.

Il y a différents outils, en fonction de ce que nous voulons faire, soit dans des logiques logicielles ou alors des outils en ligne de commande ou des outils scripts passant par un navigateur web. Il existe pleins de solutions, pas forcément dans une logique logicielle.

JB : Puis nous ne sommes pas obligés de réapprendre à chaque fois, lorsque nous avons trouvé ses outils nous pouvons construire nos propres « tunnels » et être beaucoup plus efficace.

Code X est dans la même logique qu’un fanzine, où nous créons une publication rappelant et communiquant sur nos pratiques avec nos moyens – avec une petite maison d’édition qui veut parler aux étudiants.

PrePostPrint est dans cet héritage du fanzine, dans ce rapport à l’édition.

Je n’aurais jamais fait ce projet si j’avais été payé ; car tu ne peux pas vraiment essayer de nouveau trucs expérimentaux dans un rapport marchand, sauf si la commande le demande bien-sûr.

Quand je présente mon parcours, je dis que ce sont surtout des rencontres.

FJ : Julie, est-ce que tu pourrais me reparler un petit peu de Paged.js, c’est une librarie que tu développes avec d’autres personnes ?

JB : Oui en effet, à ce salon, j’ai rencontré Julien Taquet, qui travaille à Coko. Ils ont produit un outil éditorial qui permet de modifier la chaîne éditoriale par le fait que tous les acteurs écrivent au même endroit. L’outil produisait de bons exports mais ils leur manquaient une « brique » pour l’export imprimé.

Cela fait longtemps que l’on parle à différents endroits de la production imprimée avec les technologies du web. Quentin te parlait d’OSP, ils avaient produit leur propre outil, qui avait certaines contraintes, notamment l’usage d’un ancien navigateur pour la gestion du CSS Regions. Il existait plein de petits outils pas très stables ou inversement des gros outils propriétaires – comme Prince ou easy Print.

Chez COKO, Ils voulaient donc construire, sous l’impulsion Adam Hyde le fondateur, un outil pour la production imprimée.

Le CSS est construit sur des spécifications données par le W3C – un organisme qui structure les implémentations des langages du web, il publie le document de travail, car le CSS évolue tout le temps. Le document présente les spécifications des médias CSS print ou CSS pour médias paginés, qui ne sont pas encore implémentées dans les navigateurs web. L’idée de Page js est de produire un polyfill, pour ces spécifications de CSS print. Paged.js a donc pour but de pallier les manques des navigateurs, ainsi au fur et à mesure que les navigateurs implémenteront ces spécifications CSS print, Paged.js disparaîtra.

Julien Taquet était à Prepostprint pour recruter quelqu’un pour travailler sur cet outil avec lui et un développeur à Los Angeles. Dans le projet nous codons mais nous avons aussi une expertise de designer extrêmement importante : nous voulons que Paged.js soit utilisé par des designers et non uniquement par des ingénieurs.

Code X n’a pas du tout été fait avec Paged.js, aujourd’hui, cela serait beaucoup plus simple !

Quand tu es sur Paged.js et que tu parles à plusieurs communautés en même temps faut faire attention, cela peut être repris par PrePostPrint ou Quentin qui expérimente avec et qui pousse le graphisme plus loin. Mais cela peut aussi être repris par des gens qui l’utilisent juste pour ne pas payer un graphiste, et automatiser le design.

Nous sommes quand même 2 designers sur les 3 développeurs de Paged.js, ainsi nous avons quand même cette position de dire que nous sommes concepteurs. Ainsi lorsque que nous « programmons » des livres, ce n’est pas de l’automatisation ; composer, c’est un métier.

QJ : Quand on rentre dans ce genre de pratique, cela va au-delà de question de la forme, on se pose des questions du technique, à l’éthique : c’est pour cela qu’on déborde à chaque fois. Au-delà des projets, nous concevons autres choses que des formes : des façons de travailler, de travailler collaborativement, de travailler avec d’autres outils.

[…]