1.1 – De la linéarité à la modularité

7Les éléments qui forment les chaînes de publication des structures d’édition sont difficilement interchangeables. Remplacer un logiciel de publication assistée par ordinateur (PAO) par un autre est peu aisé. La gestion avancée des styles ou les fonctionnalités liées aux commentaires diffèrent sensiblement entre le logiciel de traitement de texte Microsoft Word et son équivalent ouvert et libre qu’est LibreOffice Writer. Cette non-interopérabilité des outils entretient une dépendance des utilisateurs et détermine une chaîne de publication séquentielle qui se décline comme suit : de Microsoft Word vers Adobe InDesign, conduisant à une sortie en PDF [5] ou en tout autre format destiné à l’impression. Chaque fichier est un ensemble fini qui appartient presque exclusivement à un seul logiciel (Dehut, 2018), celui-ci ayant la double fonction de visionneuse et de machine à écrire.

8Au contraire, pour l’écriture de notre livre technique, nous nous sommes inspirés du développement web. Tout d’abord, le contenu source est lisible avec n’importe quel éditeur de texte. Ensuite, le contenu source est historisé avec Git [6] (Chacon et Straub, 2018). Ce contenu est modifiable en ligne. Enfin, les fichiers HTML, PDF et EPUB [7] sont générés automatiquement, dès qu’un changement est enregistré.

9Toutes les personnes qui prennent part à un projet mené selon ces modalités voient le système dans son ensemble et ont la liberté d’agir à chaque étape du cycle. D’opérateur ou surveillant, l’auteur ou l’éditeur devient chef d’orchestre. À la suite de Gilbert Simondon, il s’agit de repenser les rapports entre humains et machines, entre humains et programmes : « [L’humain] est parmi les machines qui opèrent avec lui » (Simondon, 2012, p. 11). Se positionner plus justement consiste non pas à être dedans comme avec un logiciel qui fonctionne tel une boîte noire, mais au-dessous, dans la création et l’ajustement d’éléments et de briques techniques, et au-dessus, dans l’orchestration de l’ensemble technique que forme cette chaîne de publication.

1.2 – Revenir aux sources : l’exemple d’AsciiDoc

10Tenter d’amorcer la production d’un livre selon les modalités de publication d’un logiciel informatique a fait émerger la question des formats, une des caractéristiques fondamentales des affordances numériques. Quels formats alternatifs à ceux des logiciels de traitements de texte proposera une écriture aussi riche ? Quelles sont les incidences d’un tel choix ? Les développeurs et développeuses sont des adeptes de langages de balisage légers. Ces syntaxes placent le contenu et les règles de présentation au même niveau, sous forme textuelle, sans que cela n’entrave la lecture. Conçu pour simplifier l’écriture de fichiers HTML, Markdown [8] est un format populaire dans le domaine. Markdown ne posséde pas l’expressivité grammaticale d’un logiciel de traitement de texte, au contraire de AsciiDoc, un langage de balisage léger moins connu vers lequel nous nous sommes tournés. Cela nous a permis de reproduire en quelques heures la structure du document dans le gabarit fourni par l’éditeur du livre.

Fig. 1

Exemple de la syntaxe AsciiDoc et de son rendu HTML : sur la partie gauche le langage de balisage léger en texte brut qui structure les contenus, sur la partie droite l’interprétation du balisage avec une attribution de mise en forme en fonction de la structuration et avec une feuille de style standard

Exemple de la syntaxe AsciiDoc et de son rendu HTML : sur la partie gauche le langage de balisage léger en texte brut qui structure les contenus, sur la partie droite l’interprétation du balisage avec une attribution de mise en forme en fonction de la structuration et avec une feuille de style standard

11Le choix du format AsciiDoc pour structurer notre ouvrage a renforcé la portabilité et l’extensibilité de notre chaîne éditoriale. La brique logicielle qui comprend la syntaxe AsciiDoc peut être remplacée par une autre. Ainsi, le contenu des documents est préservé lorsque la chaîne de publication évolue. L’extensibilité est permise par l’outillage AsciiDoc qui accueille des fonctionnalités créées et partagées par d’autres développeurs.

12Les prémisses de cette chaîne de publication ont des points communs avec le développement informatique moderne : écrits consignés dans des fichiers texte (AsciiDoc), versionnés (Git), puis distribués sur une plateforme collaborative (GitHub).

1.3 – Pourquoi versionner plutôt que numéroter ?

13Le logiciel de contrôle de versions Git (Demaree & Brown, 2017) a pour vocation première la gestion d’historique des modifications de fichiers texte. Plutôt que de numéroter chaque nouvelle version ou d’écraser les précédentes, chaque changement déclaré crée un nouveau point sur une ligne de temps. Son usage a été popularisé grâce à des plateformes collaboratives comme GitHub ou GitLab. Leur force est de rendre accessible l’historique sous forme de pages web qui sont plus simples d’accès que l’outil informatique complexe qu’est le terminal.

Fig. 2

Affichage d’une modification de fichier sur la plateforme GitHub accompagnée d’une interaction entre l’auteur et son éditrice

Affichage d’une modification de fichier sur la plateforme GitHub accompagnée d’une interaction entre l’auteur et son éditrice

14L’historique généré et distribué par Git se partage et se synchronise entre plusieurs ordinateurs. Si deux personnes modifient le même morceau d’un fichier, Git nous alerte alors de la présence d’un conflit et invite à choisir la version du contenu à privilégier sans perdre le travail déjà effectué.

15La conservation et l’organisation de versions parallèles est possible grâce à l’évolution de la ligne de temps de Git en arborescence. Cette fonctionnalité permet d’amorcer des brouillons, d’effectuer des corrections à la marge, ou encore d’expérimenter sans subir de répercussion sur la copie de travail principale. Les branches sont fusionnées dans leur intégralité ou en sélectionnant les changements les plus pertinents.

16L’historique collaboratif et interactif de Git respecte la variété des rythmes de travail d’une équipe, sans interrompre, ralentir ou altérer le travail. En choisissant d’appliquer les méthodes de développement web à l’écriture d’un ouvrage technique, nous avons retrouvé des habitudes acquises dans nos pratiques de développeurs et redécouvert la convivialité de cet outillage. Ce terme de convivialité est à entendre ici au sens développé par Ivan Illich qui met en tension d’une part la prise de pouvoir de l’outil sur les capacités de choix des humains qui les utilisent, et d’autre part leur puissance émancipatrice. En effet, comme l’affirme Ivan Illich :

17

« Pour autant que je maîtrise l’outil, je charge le monde de mon sens ; pour autant que l’outil me domine, sa structure me façonne et forme la représentation que j’ai de moi-même. L’outil convivial est celui qui me laisse la plus grande latitude et le plus grand pouvoir de modifier le monde au gré de mon intention. »

Fig. 3

Visualisation d’une ligne de temps d’un livre versionné avec Git : chaque point de fusion d’une version parallèle matérialise une boucle de rétroaction

Visualisation d’une ligne de temps d’un livre versionné avec Git : chaque point de fusion d’une version parallèle matérialise une boucle de rétroaction

18Nous éprouvons la puissance émancipatrice de l’outil en concevant, façonnant et utilisant un outil sur mesure – l’équivalent d’un traitement de texte, combinant AsciiDoc et Git, respectivement, pour le formatage des contenus et leur versionnement. Comment le mécanisme d’interprétation et de transformation de l’outillage AsciiDoc va-t-il permettre ou empêcher de se conformer au gabarit de l’éditeur ?

1.4 – Interpréter, transformer, automatiser

19L’outillage AsciiDoc repose sur un fichier plat qui est lu caractère par caractère afin de créer une représentation de la structure du document sous forme d’arbre sémantique. Celui-ci est ensuite transposé dans une autre structure, celle du format de destination.

20L’arbre sémantique d’Asciidoc se modifie grâce à un mécanisme d’extensions. Nous sommes en mesure de le parcourir pour vérifier l’orthographe, appliquer les règles de microtypographie française mais aussi ajouter de nouveaux formats d’exportation ou transformer des exemples de code en bacs à sable interactifs.

21Nous hébergeons sur les plateformes collaboratives GitHub ou GitLab à la fois les sources de notre texte, le gabarit de présentation et les scripts d’automatisation qui reproduisent la « recette » de transformation pour chaque changement. Le système est entièrement décrit avec des fichiers texte, comme posé à plat devant nos yeux, au même titre que les mouvements inhérents à son fonctionnement.

1.5 – Appréhender un changement

22S’il est plus facile pour un développeur ou une développeuse d’écrire un livre comme un logiciel informatique, qu’en est-il du chemin à parcourir pour les acteurs et actrices d’une chaîne de publication ? Nos expérimentations ont révélé qu’un des gains majeurs est le suivi en temps réel. L’augmentation de la qualité des échanges est corrélée à la diminution de leur volume. Les e-mails ont donc été réservés au partage d’idées et de questionnements, tandis que les notifications ont fluidifié les échanges techniques et que l’historique des versions pouvait être consulté en ligne. D’autre part, l’organisation des relectures en sessions a révélé, outre l’amélioration des contenus, un enthousiasme des lecteurs et lectrices vis-à-vis de la plateforme elle-même.

Fig. 4

Visualisation de l’arbre sémantique d’un document AsciiDoc : chaque ligne du texte source est contextualisée par un ensemble d’attributs qui vise à produire le résultat attendu, dans le format souhaité

Visualisation de l’arbre sémantique d’un document AsciiDoc : chaque ligne du texte source est contextualisée par un ensemble d’attributs qui vise à produire le résultat attendu, dans le format souhaité

23Du modèle d’organisation séquentielle vers celui de système dynamique, une mutation opère où travaille la notion d’objet concret telle que la développe Gilbert Simondon (2012, p. 41) : l’environnement réunissant des acteurs spécialisés mais isolés les uns des autres laisse place à l’écosystème modulaire dont les éléments rétroagissent entre eux. Ce mode d’organisation permet une souplesse d’adaptation face aux événements extérieurs et aux logiques financières. Ce n’est donc pas seulement d’un changement d’outils dont il est question, mais bel et bien d’un changement de culture.

2.1 – Réduction de la distance : publier vite, publier souvent

24L’un des apports déterminants du numérique pour la publication est la génération d’artéfacts en amont des étapes finales d’édition. Nous disposons de prévisualisations ou d’aperçus imprimables du livre dans différents formats (PDF, HTML, EPUB) à des étapes intermédiaires du processus. Les chaînes de publication classiques ne permettent qu’une version PDF précédant les traditionnelles épreuves. La distance entre l’auteur, les acteurs du projet et l’ouvrage final est donc singulièrement réduite.

25Dans le monde du développement informatique, le déploiement continu joue ce rôle. Un programme, une application ou un site web peuvent être testés et utilisés bien avant leur version finale – si tant est qu’il puisse y avoir une version dite « finale ». Le déploiement continu repose sur l’absence d’opération manuelle et sur le maintien de l’intégrité de la chaîne durant le processus. Il s’agit à la fois de gérer le flux des modifications proposées par les différentes personnes travaillant sur un même projet, puis de tester et de valider ces propositions sans mettre en péril l’existant.

Fig. 5

Génération automatisée d’épreuves Word, DocBook et HTML depuis une source AsciiDoc : visualisation des différentes phases de génération de formats spécifiques sur la plateforme GitLab

Génération automatisée d’épreuves Word, DocBook et HTML depuis une source AsciiDoc : visualisation des différentes phases de génération de formats spécifiques sur la plateforme GitLab

26La maxime empruntée au développement informatique Release Early, Release Often [9] (Raymond & Young, 2001) est un appel à privilégier des formes et des formats intermédiaires pour une meilleure compréhension du projet. Cette matérialisation de l’amélioration continue est transposable au design itératif appliqué aux contenus, au système de publication et au processus d’écriture.

2.2 – Charge cognitive et appropriation

27Dans les étapes d’écriture de notre ouvrage, nous constatons que la lourdeur imputable à l’étalement d’un projet dans le temps est amoindrie grâce au processus de publication en continu. Nous consultons le contenu dans sa mise en forme visuelle tout au long de l’écriture, au lieu de le découvrir seulement dans la dernière ligne droite du projet.

28Dans le domaine de l’édition technique, la relecture d’un premier chapitre peut commencer alors que l’écriture de la partie suivante a débuté. Les retours recueillis alimentent une logique d’amélioration continue. Les acteurs et actrices du projet s’ajustent au rythme de l’autre (Illich, 2014). La mise en page peut ainsi se préparer dès le deuxième chapitre, participer à la boucle de retours et influencer la phase d’écriture. La prise en compte et la compréhension des erreurs s’appréhendent rapidement et s’ajustent en cours d’écriture.

29Nous sommes conscients qu’un fonctionnement par itérations ne s’applique pas à tout projet éditorial et que cette écriture programmatique convient à des domaines spécifiques, parmi lesquels se trouvent les livres techniques. Si la structuration et la progression d’une réflexion ne se limitent pas à la succession de modifications dans un texte, cette dimension peut toutefois être bénéfique, y compris pour la rédaction d’ouvrages académiques. Aussi, une activité d’édition dépasse largement le cadre de production d’un livre et la dimension de flux (Tangaro, 2017) concerne la gestion d’un texte, non celle d’une pensée ou d’un mouvement.

2.3 – Réduire l’effort des acteurs d’un projet

30Nous avons évoqué le format de document AsciiDoc comme étant une syntaxe à balisage léger. Ce format a été conçu comme une représentation textuelle d’un autre format, DocBook [10]. Il s’agit d’une syntaxe XML inventée en 1991 pour mieux gérer la documentation technique des systèmes d’exploitation UNIX [11]. L’éditeur américain O’Reilly [12] a participé à l’élaboration du format DocBook, ce n’est donc pas un hasard si ce format, celui d’AsciiDoc et celui de Git sont les pierres angulaires de sa chaîne de publication automatisée Atlas [13]. Cette infrastructure leur procure la capacité de publier aussi vite et aussi souvent que nécessaire, tout en allégeant la charge de travail, faite de tâches ingrates et répétitives. Ce temps et cette énergie reconquises offrent l’opportunité de comprendre le système dans son ensemble, de gagner en autonomie et en qualité.

31L’effort nécessaire pour s’emparer d’un nouveau format d’export, ou pour le remplacement d’un élément de la chaîne de publication, se réduit peu à peu. Il est ainsi possible d’apprendre à façonner le contenu par itération en fonction de l’énergie collective au lieu de subir des bouleversements importants. C’est un point essentiel développé par Ivan Illich dans La convivialité, où il développe les termes de façonnage et d’énergie : « La ressource la mieux répartie dans le monde : l’énergie personnelle que contrôle la personne. » (Illich, 2014). Il s’agit de prendre en compte les humains qui travaillent sur une chaîne d’édition, leur vitalité individuelle et collective en tant qu’éléments du design du système de publication.

32Le principe d’amélioration continue tournée vers le sens du projet se retrouve dans les décisions concertées, priorisées et consenties des méthodes agiles. Cette réduction d’effort offre la perspective d’une création de nouvelles dispositions de distribution des ouvrages, centrées sur le contenu et dérivables à volonté sur une grande variété de supports. Le livre devient alors un des artéfacts de destination, au lieu d’être le passage obligé avant une adaptation web ou sous forme de livre numérique.

2.4 – La possibilité d’un changement de paradigme

33Utiliser les méthodes et les outils exposés ici est à la portée de toute personne ayant une culture et une pratique numérique : connaissance générale du Web et de son écosystème, notions en HTML, compréhension de la distinction structure et mise en forme. Notre expérience conforte l’hypothèse selon laquelle la difficulté d’appréhension d’un changement est culturelle avant d’être technique. Plus que des manques en compétence techniques, c’est vraisemblablement un ensemble d’habitudes et de culture qui freinerait une personne travaillant dans l’édition à adopter les principes présentés dans cet article : comment celle-ci pourrait-elle développer une appétence pour les langages de balisage léger, les systèmes de gestion de version ou le Web ? C’est-à-dire des modèles et outils répondant à un paradigme tout à fait différent de celui dont elle aurait suivi l’usage jusqu’alors. Deux préalables sont essentiels : le contexte et les interfaces.

34Getty Publications, la structure d’édition du musée d’art The Getty, est un cas original dans le domaine de l’édition. Constatant une nécessité, l’équipe du département numérique a initié une transformation culturelle et technique (Gardner, 2017). La transition a démarré avec une petite équipe qui partageait cette culture pour ensuite être diffusée dans l’ensemble de la maison d’édition (Evan, 2016).

35Ce changement repose sur une étape d’acceptation conduisant à transformer les processus, les habitudes et les outils. L’usage d’un logiciel comme InDesign n’est pas un passage obligé. Il repose également sur un changement de perception du statut du livre, considéré dès lors comme un des artéfacts de publication plutôt qu’une finalité absolue. Il repose enfin sur une mutation des modalités de publication qui devient incrémentale sur le Web ou en e-book avant d’être promue à des publications papier.

2.5 – Le design responsif du livre

36Au cours des années 2010, le responsive design a révolutionné la façon de produire des sites web (Marcotte & Keith, 2017) en favorisant l’émergence d’interfaces adaptatives plutôt que les interface statiques, en usage jusqu’alors. Le livre connaît un bouleversement similaire avec le format EPUB [14] : le texte peut être redimensionné, les paramètres typographiques se modifient en cours de lecture, l’éditeur perd la maîtrise absolue du rendu graphique.

37Plutôt que de viser la parfaite correspondance entre conception graphique et matérialisation imprimée, dont le format PDF était l’intermédiaire, la priorité du format EPUB est la résilience : le texte reste lisible et reconfigurable quelle que soit la situation. Le contexte de lecture n’est plus seulement un objet aux contraintes fixes, il devient multiple – un flux qui s’adapte aux dispositifs de lecture (Tangaro, 2017).

38Parmi les outils disponibles pour produire ces objets numériques, les premières solutions artisanales ont mis à mal les logiciels classiques. Un temps d’adaptation a été nécessaire pour comprendre les bouleversements, les nouvelles pratiques, les nouvelles attentes. Les enjeux se sont cristallisés sur un aspect spécifique du processus, à savoir la génération d’un fichier PDF imprimable possédant une puissance fonctionnelle comparable à celle du logiciel InDesign alors majoritairement utilisé. Actuellement, cette fonction est assurée par des solutions propriétaires et fermées comme PrinceXML (Cramer, 2017), mais une communauté se constitue afin d’apporter la richesse et l’ouverture des technologies et méthodes du Web à cette étape de mise en forme.

2.6 – Mettre à jour un livre, maintenir une chaîne

39Travailler avec une même source pour l’ensemble du processus d’écriture, d’édition et de mise en forme graphique apporte une grande fluidité pour chacune de ces étapes. Mais que se passe-t-il si un des outils n’est plus mis à jour ? Quel sera l’impact sur la chaîne ? L’intérêt de la modularité est de pouvoir changer un élément et non la chaîne entière. L’écosystème à accès ouvert (open source) GNU/Linux repose sur ce principe (Stallman, 1985).

40L’ouverture du code source des outils permet, au-delà d’une simple utilisation, de les forger [15] et de contribuer à leur développement. Ces interactions sont vectrices de transferts de compétences. Les étapes de développement, d’adaptation et d’implémentation sont motivées et mises en œuvre pour des projets concrets, permettant à chacun de constater en temps réel les résultats de son effort. L’auteur, l’éditeur, le relecteur, le designer graphique et les autres acteurs du projet éditorial ne sont plus seulement des consommateurs d’outils mais les acteurs d’un système qu’ils modèlent.

41Les questions de compétences et de dépendances se déplacent vers la mise à disposition d’interfaces intermédiaires pour faciliter la compréhension et la manipulation du système de publication. La chaîne ne repose plus sur un logiciel spécifique, mais sur un assemblage de programmes, qui demeurent remplaçables tout en étant soumis aux compétences des administrateurs du système.

42Les formats des fichiers et les logiciels sont ouverts, au même titre que les processus d’interaction – consulter, interroger, proposer, réaliser, faire réaliser, valider, etc. Dans ces conditions, il est difficile d’anticiper les mutations à venir de la chaîne d’édition. Mais quelle heureuse perspective que celle de pouvoir voir évoluer et façonner les outils qui permettent de concevoir et de produire des livres, quelle que soit leur forme.