Élise Gay et Kévin Donnot forment un duo de graphistes spécialisé dans des projets éditoriaux aussi bien sur format papier que support écran. Dans le cadre des expositions du cycle « Mutation/Création », le centre Georges Pompidou leur a donné carte blanche, avec les éditions HYX, pour produire les catalogues de ses expositions. Leurs différents catalogues sont des objets-manifestes, mêlant design graphique et design programmatique.
Coder Le Monde reprend ces interrogations dans un projet expérimental reposant sur des technologies du web pour produire une édition.
La question de l’update ou de la mise à jour était pour nous à rapprocher du hic et nunc, car elle intègre la capacité de mise à jour rapide possible par le numérique, et l’emploi des technologies du web (intrinsèquement mises à jour) dans des processus imprimés.
Comme on le voit avec Coder Le Monde, l’usage de technologies mettant à jour automatiquement le contenu permet la production de formes uniquement possibles par ce biais, à l’instar du système d’hypertexte.

FJ : Dans le cadre de la création de ce catalogue d’exposition, quels ont été les éléments déclencheurs qui vous ont poussés dans votre pratique à utiliser ces technologies de web2print ?

KD : Le projet s’inscrit dans un cycle un peu plus large qui s’appelle Mutation / Création, sur la question numérique de ces enjeux. Il se trouve que dans ce cycle, nous avions déjà réalisé un catalogue, Imprimer le Monde (2017) qui était le premier catalogue sur la question de l’impression 3D. Nous avions trouvé des techniques de mise en page, et utilisé des méthodes génératives pour travailler sur ce catalogue et pour générer des formes typographiques. Il y avait un vrai rapport entre le fond et la forme, l’idée c’était d’expérimenter un peu plus loin [...] d’inventer de nouveaux process de production qui soient cohérents avec le sujet. [...]

EG : Nous avions une carte blanche de l’éditeur. C’est une série de catalogues où la question de la production, du process de travail est centrale. Il en existe quatre et le cinquième est en route. Pour Coder le Monde, le deuxième, comme pour les autres nous nous sommes basés sur la thématique de l’exposition, qui s’attachait principalement à des œuvres qui ont été programmées.

KD : Les notions centrales de Coder le monde, visent à chercher dans le champ de l’art et du design et de l’architecture comment la question du code en tant que langage, en tant que système d’encodage des données, peut être utilisée.

KD : L’idée de Coder le Monde était de travailler un principe où le code est à la fin comme un système et comme un langage. Il y a tout un tas de textes dans le catalogue qui parlent de cette question du langage : la différence entre langage formel et langage naturel, la différence entre code en tant qu’encodage de données ou en tant que programme.

Nous avons pris les éléments du contenu du catalogue et nous avons commencé par les baliser. Nous l’avions balisé suivant une norme standard : le TEI (Text encoding initiative), pour qu’il soit lisible par une machine et donc séparer les éléments [ici tu as « language html » ça permet de savoir que HTML est un langage] lorsque l’on travaille avec une machine on peut demander à un programme pour chaque langage : « tu fais ça ».

EG : Cela permet de donner à la machine des informations sur le contenu même, ce qui a été dégagé, spécifié, balisé, « Tim Berners-Lee » nous lui disons que c’est un nom [...] pour « HTML » : un langage, et pour « 1992 » nous lui disons que c’est une date.

KD : La première étape pour nous était d’utiliser le code comme un support d’encodage pour enrichir le contenu. Ce code est invisible, c’est-à-dire c’est un système qui a été utilisé pour automatiser le travail et pour pouvoir créer des mises en forme alternatives.

L’idée était d’utiliser le code comme un programme qui mette en forme. Nous n’utilisons pas InDesign pour faire de la mise en page sur ce projet, mais plutôt les spécifications des média print du langage CSS [...] Nous avons automatisé la mise en page. Nous avions repris un outil de OpenSource Publishing (OSP) qui s’appelle HTML2Print, qui permet de régir des marges, des fonds perdus et d’avoir un mode de visualisation et un mode d’impression.

Avec HTML2Print, nous avons balisé tous les contenus dans un langage qui s’appelle Markdown et YAML, tout le livre est rangé dans des dossiers avec des petits fichiers textes et nous avons développé un backoffice, un CMS custom [...] Il y a un système de gestion de contenu en PHP comme sur un site web qui vient récupérer tous les contenus et qui les preprocess pour générer des pages HTML, qui sont ensuite interprétées avec une feuille de style CSS particulière pour l'imprimé.

EG : et donc faire une mise en page.

[...]

KD : C’est une façon pour nous d’organiser le contenu, de mettre à jour les textes quand ils arrivent parce que nous sommes quand même dans une chaîne de l’édition relativement rigide : relecture de textes, les images, la photogravure etc...

KD : Nous commençons toujours par faire des maquettes type, sur un site web ou sur livre c’est toujours pareil : nous réalisons des maquettes statiques pour réfléchir à l’aspect visuel de la chose. Quant aux sites web, nous faisons aussi des maquettes interactives.

À partir des maquettes sur InDesign [...], nous produisons des gabarits HTML et CSS, puis nous mettons ces gabarits dans HTML2Print. Ensuite, les contenus enrichis en Markdown et YAML sont interprétés par un système de gestion de contenu en PHP qui génère du HTML, qui à son tour est envoyé au système HTML2Print produisant ainsi la mise en forme.

Puis nous utilisons Safari pour faire un export PDF.

Nous avons converti les couleurs parce qu’il y a pas mal de soucis, entre la génération d’un PDF imprimable professionnelle, aux normes etc. et le fichier qui sort d’un navigateur, il y a un peu de marge. Donc on utilise Acrobat pour cela et InDesign nous sert à faire un PDF final pour être sûrs de ne pas avoir de soucis d’export.

EG : Dans la majorité de nos productions, nous utilisons des programmes, des logiciels différents. Nous ne nous cantonnons pas du tout exclusivement à InDesign : nous piochons dans des outils existants, et lorsqu’ils n’existent pas, nous les développons.

KD : C’est une logique d’agencement et de combinatoire. L’idée, c’est d’associer des petits outils qui effectuent des tâches minimales, ou de développer de tout petits outils, à l’instar de ce petit système de gestion de contenu. Puis de brancher les choses ensemble pour arriver à un résultat particulier. Pour Coder le Monde, le fait d’avoir balisé l’ensemble du contenu permet de faire des références entre toutes les différentes itérations, les différentes occurrences d’un même terme. Le livre s’ouvre donc sur 48 pages d’index qui viennent donner les récurrences des pages. Il y a un index des noms, un index des noms d’œuvres il y a un index des langages. Il nous paraissait intéressant à lire en tant que tel, c’est intéressant de rapprocher « Farah Atassi » de « Jean-Sébastien Bach » [...] cela créé une espèce de générique qui fait sens et en même temps avec les références de pages, cela produit une sorte de visualisation de données des nombres d’occurrences.

EG : La mise en page se fait automatiquement et les références de page aussi, c’est-à-dire que le programme sait à quelles pages il va retrouver « Vera Molnár » sur l’ensemble du catalogue, et ajoute les références de page automatiquement.

KD : La programmation permet donc dans ce projet, d’avoir des fonctionnements automatiques. Toute la spécificité du livre c’est qu’à l’intérieur des pages texte, à chaque occurrence d’un nom, d’un nom de projet ou d’un langage, un algorithme produit comme une espèce d’hypertexte, c’est-à-dire qu’à chaque occurrence, on retrouve les références des autres pages où l’occurrence est citée. [...] Cela permet de circuler de façon non-linéaire dans le texte et de rejouer un fonctionnement qui serait hypertextuel, un peu plus proche du web, non linéaire.

EG : C’est quelque chose que nous ne pouvons pas du tout faire sans automatisation d’un programme, il y a plusieurs millions de liens et dès que nous ajoutons des références, un mot se retrouve d’une page à l’autre. Il faudrait revérifier sans arrêt les références. Ce qui nous intéresse c’est que la programmation, le code, nous serve à faire quelque chose que nous ne pouvons pas faire autrement.

KD : Nous ne générons pas de forme avec, nous générons de la circulation, de l’agencement dans le livre. C’est un élément de structure du livre.

Pour pouvoir faire les drapeaux de notre texte, nous avons été obligés de développer un petit module à HTML2Print permettant de faire des retours à la ligne de façon « soft ». Quand il y a un nom, la ligne devient beaucoup plus longue avec les annotations de pages. Tout cela implique une énorme complexité qu’on ne voit pas à la fin, parce que la mise en page s’inspire volontairement d’exemples historiques.

Nous avions choisi ce caractère qui s’appelle Cardinal édité par Production Type, car il est présenté comme une espèce d’androïd du Garamond, une typographie trop parfaite pour être dessinée par un humain, et cette ambiguïté nous plaisait bien.

FJ : Dans le cadre de la mise à jour, c’est par le back office que vous la régliez ?

KD : Oui, initialement nous savions qu’il allait avoir des corrections de textes. Il y a une nécessité de mettre à jour le contenu. Le processus de l’édition n’est jamais linéaire, il y a toujours des corrections sur maquettes.

EG : Toujours des allers-retours.

KD : Il fallait que ce soit flexible, pour effectuer des corrections pas dans l’idée de mettre le livre à jour dans un second temps : parce que la technique d’impression est en offset et est tiré à deux ou trois milles exemplaires, donc nous n’allons pas en faire une mise à jour.

[...]

Pour une collection qui s’appelle « Script », nous avions produit un outil de travail d’éditions en ligne qui permet de faire toute la préparation de copie en ligne puis d’exporter directement un format intermédiaire, interprétable automatiquement par InDesign. Ou d’exporter un pdf, du XML TEI ou du CAIRN qui est directement gérable par la plateforme de publication scientifique CAIRN. L’idée de cet outil est de centraliser l’ensemble des moments de l’édition.

Habituellement lorsque nous faisons de la publication multi-support, nous faisons le livre imprimé puis nous le déclinons sur une version numérique que nous devons refaire entièrement.

Tu ne peux pas passer d’InDesign – d’une maquette ou tu as les drapeaux – à une publication numérique, parce qu’il y a plein de choses qui sont spécifiques au style et à InDesign.

EG : Donc toutes les corrections qui ont été faite sur InDesign dans un dernier temps, en correction sur maquette, ne sont pas dans les documents Word envoyés à la base.

Le processus n’est pas du tout fluide, il faut refaire plusieurs fois le travail.

KD : Pour répondre à ce problème, nous avons développé un outil qui permet de baliser tout le contenu et de finir le contenu en ligne, qui sert à la préparation de copie avec un balisage : ainsi définir les titres, les sous-titre, le texte courant, les citations et placer toutes les espaces fines automatiquement. L’outil permet aussi d’inspecter le code de balisage puis d’exporter un format intermédiaire. L’outil est générique à tous les projets possibles, puis pour chaque projet nous avons une moulinette JavaScript qui coule le contenu exporté.

Nous l’utilisons déjà pour une collection de livres pour l’École d’architecture Paris-Malaquais.

EG : Nous en avions assez de faire le travail plusieurs fois dans la production d’éditions multi-support, à la fois print et web. Pour l’instant le process de travail n’est vraiment pas travaillé et pas pris en compte, Nous avons donc été obligé de le faire par d’autre moyen.

KD : L’intérieur est donc entièrement généré d’un coup à partir de la plateforme.

EG : Le contenu est traité en ligne et ensuite un programme met en page.

KD : La publication est aussi publiée sur CAIRN et donc sur le site de CAIRN il y a le même balisage, la même version ; toutes les notes sont automatisées. C’est très adapté pour des livres de textes.

EG : il y a peu d’image, la seule chose que nous faisons sur InDesign : c’est l’intégration des images. Tout se fait automatiquement pour le texte et pour les images, nous voulons pouvoir les gérer.

KD : Après Coder le Monde, nous nous sommes rendu compte de la galère que nous nous étions mise : Le système produisait des pdfs depuis le navigateur web. Il était donc assez complexe d’effectuer des corrections sur le fichier.

Nous voulions plutôt un fichier InDesign utilisable pour pouvoir facilement le ré-agencer.

Après l’expérience de Coder le Monde, nous avons préféré l’usage de moulinette produisant des documents InDesign modifiables à partir desquelles nous générons des pdfs.

KD : C’est un outil pour nous en interne.

KD : Avec cette interface, nous pouvons faire des imports Word, le programme va automatiquement poser toutes les espaces fines, toutes les itales etc. ... L’interface permet aussi d’avoir un retour visuel permettant de voir où sont placés les espaces fines, où sont les titres, les sous-titres, avec des codes couleurs correspondants aux différents niveaux de paragraphe.
Par exemple le vert pour les notes, la bleu cyan les appels de figure...

EG : Et cela nous permet de vérifier le contenu, ce que nous appelons la préparation de copie : vérifier que tu as tous les sous titres, toutes les italiques...

KD : Puis après je peux exporter le contenu formaté en InDesign, en pdf, en e-pub en XML-TEI et en CAIRN. [...] L’export InDesign permet de récupérer un fichier XML qui est maison [customisé]. Il sert de format de fichier spécifique à notre plateforme et à notre moulinette d’interprétation des données, qui va l’interpréter en fonction de la maquette de la collection.

Nous faisons aussi un export pour les relecteurs en pdf.

Nous nous sommes mis plein de petits outils : le balisage, les titres les citations, pouvoir insérer des notes de pouvoir insérer des petits codes privés et des glyphes.

C’est un outil interne qui nous sert à nous pour l’édition de publication multi support simple, où il ne s’agit pas de faire des grands drapeaux, où il ne s’agit pas de gérer des rapports image---textes compliqués. L’outil sert cependant à publier un même texte sur plein de supports et de pouvoir le mettre à jour régulièrement.

EG : Pour une collection où la mise en page est toujours la même, où il y a beaucoup de texte, cet outil est idéal parce que la mise en page est assez facilement automatisable. Nous le paramétrons une fois. Puis les notes de bas de page se font automatiquement avec l’outil d’InDesign. C’est uniquement sur ce genre de contenu que l’outil fonctionne très bien.

On nous le demande assez souvent. Nous utilisons cet outil là pour plusieurs projets différents, il suffit que le JavaScript sorte une autre mise en page.

KD : Le format intermédiaire entre cet outil et InDesign, est ce format de fichier XML un peu spécial, générique et standard ainsi que le JavaScript interprétant la maquette qui est spécifique pour chaque projet. Cela nous permet d’aller très vite.

EG : La mise en page est très rapide, il faut juste poser les images et c’est assez précis.

KD : C’est plutôt de l’automatisation que j’appellerais technique, pour la mise à jour technique, pour le flux de travail de l’édition. Cela ne l’est pas du tout pour de la création. Dans Coder le Monde, l’édition générative était justement là pour apporter des systèmes de circulation non-linéaire et des systèmes de lecture alternative. Pour ACB et cet outil, c’est purement technique : pour faciliter le flux de travail autour d’un projet. Cela n’a pas d’impact sur la mise en forme, nous aurions très bien pu couler les textes de la même façon sur InDesign, mais nous nous serions coupés de cette possibilité de mise à jour et de publication multi support.

KD : L’outil a plein de technologie, c’est un gros mélange. Tu as des modules en PHP qui servent à interpréter les fichiers Word, des modules en PHP pour générer le PDF et le XML. Puis Il y a une interface utilisateur en Vue.js. Le design est très propre mais il ne se veut pas expressif, c’est un peu un design industriel, ultra-fonctionnel, ultra minimal.

KD : Dans Neurones, les intelligences simulées (2020), nous avons détourné une espèce de réseaux de neurones servant à la synthèse d’écriture manuscrite, nous l’avons recompilé à notre sauce.

Nous avons écrit des programmes pour injecter tous les titres du livre, en générer cinquante pour chaque titre, et ensuite nous avons pu les choisir pour les placer sur le livre.

Le programme peut servir à tous les étages du livre : il peut servir au moment où nous allons travailler sur un caractère génératif, comme dans Coder le monde, ou si nous voulons générer des tracés ou des couvertures comme dans La fabrique du vivant. Il n’y a pas de règle et c’est ça qui nous plait.

FJ : Par rapport au Neurones, les intelligences simulées, vous avez utilisé des techniques de Machine Learning, est-ce que cela a posé d’autres contrainte par rapport à des algorithmes « traditionnelles » ?

EG+KD: Oui, en effet.

KD : Oui, cela a posé de très grosse contrainte de temps de calcul, c’est-à-dire que concrètement nous avons dû faire apprendre à un réseau de neurones, depuis un modèle de réseau développé à l’université de Toronto, il y a 5-6 ans. Nous avions le jeu de données brutes mais nous n’avions pas le modèle appris. Pour faire apprendre le modèle, cela représentait un mois de calcul sur nos ordinateurs.

EG : Avec la machine qui crash, et où tu ne peux rien faire d’autres avec l’ordinateur.

KD : Nous avons essayé de récupérer un modèle pré-entrainé, mais nous n’en trouvions pas parce que le réseau était un peu vieux. Finalement nous l’avons fait apprendre sur des grosses machines de calculs chez mon père qui fait de la 3D [...] en le mettant chez lui, cela a pris 5 jours.

KD : Là il y avait des limites techniques. Une fois que le modèle est entraîné, c’est très facile de faire de l’inférence et de poser une question et que le modèle pré entraîné répond. Nous n’avions plus qu’à utiliser les programmes pour générer plein de formes différentes.

[...]

Tu peux lui demander de faire de l’inférence en initiant l’écriture manuscrite à partir des écritures du jeu de donné. Il y a 221 personnes qui ont écrit les mêmes choses, tu peux initialiser le modèle. Si je veux écrire suivant une des écritures d’une de ces 221 personnes : je lui fais écrire quelques phrases avant avec cette écriture, puis nous
lui demandons de continuer avec notre texte. Le réseau de neurones tient compte de la forme de l’écriture précédente, de la logique de tracé précédente pour poursuivre.

Nos programmes initient l’algorithme avec des phrases test pour chacune des 221 écritures, puis ils rédigent nos titres au sein desquelles nous allons sélectionner ceux qui nous intéressent.

Toutes les aberrations produites ont été calées en couverture, ces moments où l’algorithme dérape.

EG : Où il ne comprend plus, il ne sait plus quoi faire !

KD : C’est un peu difficile de savoir quand est-ce que ça se produit, mais nous sentons que les valeurs vrillent un petit peu.

EG : Parfois il produit des petits points ou un grand trait.

KD : Ce qui est intéressant par rapport à un autre algorithme, c’est que ce qui se passe de façon sous-jacente est assez mystérieuse. Entraîner le modèle consiste à entraîner des paramètres pour des milliards de propriétés et donc tout ça devient très intangible. Alors que des algorithmes très simples comme pour Coder le Monde, où ils produisent des opérations mathématiques basiques et il n’y en pas des milliards.

EG : Là nous lâchons un peu prise, nous ne savons pas ce que cela va donner, nous pouvons être surpris par le rendu. Il y a quand même une grosse part de flou auxquelles nous n’avons pas accès mais qu’il faut simplement assumer.

KD : Il faut jouer avec, en même temps le rôle du designer se transforme et revient plutôt à choisir des formes que la machine à produire. Nous ne produisons pas nous même, nous faisons produire avec un certain nombre d’itérations, généralement grand, et nous venons après choisir déterminer voir retouché à certain moment, pour avoir la forme qui nous convient. Nous déléguons la partie de production, nous devenons des commissaires.

EG : Oui, nous aimons bien changer de place. Cela permet de faire du design un peu autrement.

FJ : Et pour ce projet, vous avez utilisez des algorithmes d’analyse sémantiques, par l’usage d’algorithme de word2vec ?

KD : Non, nous avons plutôt utilisé une série d’outils nommée Voyant, ils permettent d’avoir plein d’information sur un texte et de voir les récurrences de termes, les interconnexions entre les champs lexicaux.
Nous n’avions pas forcément besoin de développer dans ce projet une analyse sémantique particulière.

EG : L’outil s’attache sur l’occurrence des champs lexicaux sur une même double pages.

C’est un peu laborieux mais assez simple, nous avions copié-collé chaque double page dans l’outil. Puis il ressort les nombres d’occurrences. Nous avons exclu les petits termes (le, la, les etc..) et toute la syntaxe. Il met en exergue tous les mots interconnectés.

KD : En fonction de leur proximité dans le texte et en fonction d’un champs sémantique associé à chaque mot.

C’est l’usine à gaz à redévelopper parce qu’il faut renseigner tous les champs sémantiques. C’est un peu un travers que peuvent avoir les développeurs à faire de la sur-ingénierie, nous avons tendance à se dire qu’il y a des choses qui existent, nous allons les utiliser pour ce qu’elles savent faire.

Mais j’ai tendance à redévelopper des choses qui existent déjà alors que ce n’est pas forcément utile dans le projet. C’était bien plus rapide de faire des copier-coller de chaque double page, même si ça parait un peu aberrant et très facilement automatisable. Mais c’était dix fois plus rapide que de redévelopper un système d’analyse sémantique qui aurait pu avoir lu dans une boucle tout le texte.

EG : Ce qui nous intéresse c’est aussi de pouvoir piocher les différents outils qui existent, s’il y en a qui n’existe pas, nous les développons. L’analyse du langage est très complexe, nous ne voulions pas s’engager là-dedans !

FJ : Vous questionnez aussi beaucoup le rapport écran papier, notamment avec la revue Back Office, quelle ont été les choix formels pour la création de la forme de cette revue ?

KD : La partie graphique de Back Office, ce n’est pas ce qui nous intéresse le plus dans le projet. Elle fonctionne bien, la grille est très flexible. Mais, ce qui a été particulier dans le projet, pour nous, c’était plutôt l’expérience d’être éditeur, la relecture des textes et travailler avec des auteurs et des traducteurs, des lecteurs et des relecteurs, d’imaginer des sommaires, des contenus en fonction de thématiques.

EG : À partir du moment où c’était une revue thématique, il fallait qu’il y ait une mise en page qui puisse s’adapter à tous les sujets. Autant à l’inverse des projets dont nous venons de parler, où la mise en forme est vraiment liée à la thématique du projet. Il fallait qu’elles puissent accueillir des sujets différents et qu’elle soit relativement neutre, tout en permettant d’être flexible pour intégrer des contenus très variés.

KD : Il est clair que c’est contradictoire, mais en même temps cela répond à une économie : avec Back Office, rien que le travail sur les contenus nous prend un temps complètement fou, si nous devions repenser à chaque fois la maquette nous ne pourrions pas produire dans les temps.

Nous avions identifié ce problème assez tôt, nous voulions un truc qui ne soit pas spécifique, et c’est un peu contradictoire avec ce que nous disons. Mais en même temps c’est aussi une réalité pour sortir le numéro. Quand nous arrivons à le sortir en un an et demi, nous sommes déjà contents. S’il y avait à imaginer des mises en forme qui soit singulières à chaque fois... et en plus nous n’avons pas de recul : nous avons une casquette d’éditeur, une casquette de rédacteur en chef, de graphiste. C’est compliqué d’avoir du recul sur un numéro lorsque nous
nous occupons de tous les étages.

EG : C’est aussi une collection : c’est-à-dire qu’il était important, au-delà de la fluidité de travail, d’avoir une identité [...] Il y a une identité dans Mutation Création mais qui est beaucoup moins forte.

KD : Il est clair que c’est un périodique, ce n’est pas comme un ensemble de livre. Il faut que ce soit lisible comme un ensemble aussi.

EG : La version numérique de Back Office, c’était une des premières fois nous avons vraiment pu penser à la lecture sur écran sur du texte long. Cela pose beaucoup de contrainte, nous avons essayé de retrouver des astuces qui aide à la lisibilité, avec le compteur de lignes, pour réussir à se situer dans un texte, c’est quelque chose qui est complètement évident avec un ouvrage papier qui un objet est très sensible, avec la lecture en ligne c’est complément perdu. Il était important pour nous de le rendre sensible au maximum ; c’est pour cela qu’il y a un pourcentage de lecture sur le sommaire.

KD : Et il y a aussi des échos à la version imprimée : les notes de bas de page et l’iconographie arrivent de façon synchrone dans Back Office, les notes sont sur les mêmes doubles pages et placées de façon un peu éclatées en fonction du contenu et de la grille. Sur la version en ligne elles arrivent de façon synchrone à la hauteur de l’appel de note. Il y a pas mal d’écho que nous avons essayé de faire. Nous nous sommes posés plein de questions sur cette version numérique : si nous faisions du epub, si nous publions sur CAIRN ou si nous faisions une application ... Nous avons heureusement été assez justes en ne faisant pas d’application, aujourd’hui toutes les applications que nous avons faites ne sont pas maintenables. ...

EG : Sur la version numérique, par rapport aux images, il faudrait que nous la retravaillions car elle est trop contraignante par rapport à la version imprimé ; faudrait que nous trouvions un autre système.

KD : Les premiers numéros de Back Office étaient un peu moins illustrés et donc on a trouvé que ça manquait au fur et à mesure, à partir du Back Office 3 on a commencé à mettre beaucoup plus d’illustration pour qu’il soit plus visuel, et la maquette écran a du mal à accueillir plus grande quantité d’images.

EG : Il fonctionnait bien avec peu d’images, maintenant que nous en mettons plus sur la version imprimée, nous n’arrivons pas à en mettre autant sur la version numérique. Il faut que nous retravaillions cette partie-là.

KD : Le prochain numéro il s’appelle « suivre le mouvement » ; Il y aura donc beaucoup de chose à montrer en animation et pour l’instant nous ne pouvons mettre que du GIF.

EG : Au fur et à mesure, nous mettons à jour la plateforme. La version imprimée ne bouge pas, afin d’avoir une cohérence.

KD : La version imprimée, même s’il y a la même grille, elle évolue progressivement.

EG : Pour ce numéro nous sommes à plus de 500 images ; ce qui est peut-être 5 fois plus que d’habitude pour le même nombre de pages, et le même nombre de signes. Donc elle est plus dense, elle évolue lentement.

KD : La question de la mise à jour en édition est compliquée : soit nous nous situons en édition imprimée, dans ce cas la mise à jour est assez figée par les techniques de production, ou alors nous imprimons en numérique et faisons de l’impression à la demande. Soit c’est en ligne, et la question n’est pas de savoir si ça se met à jour, mais comment
nous conservons les mises jours : tout change tout le temps et donc comment est-ce que nous nous arrêtons ? Comment est-ce que nous gardons en mémoire un état ?

C’est tout l’enjeux difficile de la publication multi-support : il y a deux fonctionnements qui sont relativement opposés, en tous cas dans les schémas traditionnels, et c’est difficile de les faire converger. Il faut trouver des méthodes qui soient propres à chaque projet.