---
title: "Contre le logiciel : pour des processus décomposés et ouverts"
chapitre: 5
section: 2
bibfile: "data/05.json"
_build:
  list: always
  publishResources: true
  render: never
---

Le logiciel pose plusieurs problèmes épistémologiques, son influence sur nos interactions numériques en général et sur les pratiques d'édition en particulier est importante, et nous mène à considérer la mise en place de processus qui ne font tout simplement pas appel au _logiciel_ — tel que défini dans la section précédente.
Plutôt que de poser la question d'une possibilité de travailler _sans_ le logiciel, nous interrogeons les conditions et les implications de ces choix, qui sont des choix techniques, politiques mais aussi éditoriaux.
Il s'agit donc d'une remise en cause du logiciel comme devant être central dans les pratiques d'édition.
Comment ont émergé des processus qui ne sont plus centrés sur les logiciels et leurs interfaces ?
Qu'est-ce qu'implique de ne plus recourir à des logiciels — propriétaires ou libres — dans des pratiques d'édition ?

De telles initiatives existent, nous identifions leur intervention à deux moments principaux de l'histoire de l'informatique, deux moments que nous souhaitons confronter pour comprendre les changements de paradigmes induits.
D'une part au moment de l'émergence de l'informatique personnelle et le rôle que les interfaces ont pu y jouer.
D'autre part dans des pratiques de design graphique (touchant à l'édition) qui se sont réinventées en délaissant volontairement le logiciel, après un passage par le logiciel _libre_.
Nous intégrons ici un domaine lié à l'édition mais dont le champ est plus large : le design graphique.
C'est un terrain pertinent pour observer des usages métiers dans l'édition, du fait de sa place décisive dans la chaîne de fabrication et de production, comme nous l'avons vu sur les questions de _forme_ du livre{{< renvoi chapitre="1" section="2" >}}, et parce que la technique y est régulièrement interrogée.

Notre réflexion nourrit l'idée selon laquelle une _fabrique d'édition_ est le lieu de recherches et d'expérimentations, et que cette double dimension est difficilement compatible avec le carcan imposé par les logiciels.
L'adaptation ou la modification des logiciels connaît une certaine limite, tant les compétences en développement doivent être importantes, alors que la mise en place de scripts ou de programmes est une voie plus atteignable dans certains langages de programmation comme JavaScript, PHP ou Python.
C'est donc _contre_ le logiciel que des pratiques se développent, _contre_ dans le sens d'une opposition, mais aussi d'un appui, le désir de prolonger des expérimentations au-delà du logiciel et du logiciel libre découle d'une forme de déconstruction.
Il s'agit de décomposer et d'ouvrir.
Conduire des instructions éditoriales en privilégiant le texte plutôt que des interactions via des interfaces graphiques — autrement dit des boutons —, peut par ailleurs être considéré comme un troisième niveau après le balisage sémantique et l'acte éditorial sémantique.
Il s'agit alors de construire un outil qui traduit lui-même un sens dans sa conception et son fonctionnement, en lien avec le balisage sémantique du texte et la modélisation de l'édition.


### 5.2.1. Une histoire des pratiques (presque) sans logiciel

Le logiciel, tel que décrit dans la section précédente{{< renvoi chapitre="5" section="1" >}}, est issu d'une évolution de l'informatique que nous devons approfondir en faisant un retour historique sur les premières initiatives autour de l'informatique personnelle, et en particulier sur l'expérience du dispositif Dynabook et du langage de programmation Smalltalk qui ont amené cette double idée d'une interface révélatrice des options offertes et d'un environnement _programmable_.
Cet exercice exploratoire est utile pour comprendre comment les logiciels et leurs interfaces ont pris un virage spécifique, tronquant des principes ouverts pourtant présents dès les années 1960 et limitant ainsi une maîtrise de l'informatique.
C'est l'objet des recherches du fameux centre de recherche de Xerox à Palo Alto (ou PARC pour _Palo Alto Research Center_) {{< cite "rheingold_tools_2000" >}}, et plus spécifiquement du projet du Learning Research Group dirigé par Alan Kay, figure pionnière de l'informatique.

Alan Kay, Adele Goldberg, et leur équipe, ont travaillé plusieurs années sur le développement d'un dispositif informatique permettant de gérer de l'information au sens large, et plus spécifiquement de créer des outils de création de contenu variés (texte, image, animation et son).
De 1967 à 1969, un dispositif matériel est imaginé, et un langage de programmation est développé, pour appliquer l'idée selon laquelle l'informatique pourrait être un _méta-médium_ de création par le biais de la simulation d'autres médiums.
Il s'agit donc d'une expérience épistémologique qu'un groupe de chercheurs et de chercheuses développe afin d'appliquer le principe de "métamédias"  :

{{< citation ref="citton_angles_2023" page="276" >}}
La plupart des appareils numériques que nous utilisons quotidiennement fonctionnent comme des _media_, en ce sens qu'ils permettent de transmettre, d'enregistrer et/ou traiter de l'information. Il paraît toutefois plus judicieux de les identifier au sein d'une classe particulière d'appareils de médialité qu'Adele Goldberg et Alan Kay ont proposé d'appeler "métamédias". Ils caractérisaient de cette façon les _media_ numériques par leur capacité à simuler tous les autres types de _média_ préexistants. Ce sont des métamédias en ce sens que ce sont des _media_ qui incluent en eux les autres _medias_ et les re-médient de multiples façons.
{{< /citation >}}

Il faut replacer cette expérimentation dans son contexte.
La fin des années 1960 est le moment d'une forte émulation intellectuelle autour des médias, et du développement de l'informatique.
Cette période est particulièrement bien décrite par Fred Turner dans _Aux sources de l'utopie numérique_ {{< cite "turner_aux_2021" >}}, où plusieurs initiatives se croisent, se rencontrent ou s'entrechoquent.
Les réflexions de Marshall McLuhan ou Buckminster Fuller sur les médias influencent nombre de communautés, dont les recherches des informaticiens et des informaticiennes du centre de Palo Alto :

{{< citation ref="kay_user_1990" page="193" lang="en" >}}
I named the notebook-sized computer idea the Dynabook to capture McLuhan's metaphor in the silicon to come.
{{< /citation >}}

Dans _Personal Dynamic Media_ {{< cite "kay_personal_1977" >}}, Adele Goldberg et Alan Kay décrivent une expérience menée auprès d'enfants avec le Dynabook, un dispositif informatique portable, et avec Smalltalk, un langage de programmation orienté objet.
Leur idée centrale est de créer un environnement, basé sur l'informatique, suffisamment ouvert pour permettre tout type de pratiques _médiatiques_ ou artistiques, comprenant la création des outils par les utilisateurs et les utilisatrices elles-mêmes :

{{< citation ref="kay_personal_1977" page="41" lang="en" >}}
The burden of system design and specification is transferred to the user. This approach will only work if we do a very careful and comprehensive job of providing a general medium of communication which will allow ordinary users to casually and easily describe their desires for a specific tool.
{{< /citation >}}

Ce qui est développé à cette période rassemble tous les principes de l'informatique personnelle, telle que nous la connaissons encore aujourd'hui : interface graphique, souris avec un pointeur, supports de stockage, etc.
Toutefois les logiciels tels que pensés ici divergent de la définition que nous avons donnée précédemment, il s'agit d'une période intermédiaire où les premières interfaces sont développées tout en conservant des modes d'interaction via des commandes textuelles.

{{< citation ref="kay_personal_1977" page="35" lang="en" >}}
All of the systems [writing, editing, drawing, doing animation or music, programming] are equally controllable by hand or by program. Thus, drawing and painting can be done using a pointing device or in conjunction with programs which draw curves, fill in areas with tone, show perspectives of three-dimensional models […], and so on.
{{< /citation >}}

Les modalités d'interaction ne se limitent donc pas à une interface graphique qui, comme nous l'avons vu{{< renvoi chapitre="5" section="1" >}}, est opaque par défaut.
L'environnement logiciel du Dynabook, permis par Smalltalk, est pensé à la fois comme une facilitation des habituels modes d'interaction par la programmation, mais aussi comme un contrôle de la machine "par la main" — pour reprendre les mots d'Alan Kay et Adele Goldberg.
Certaines actions peuvent ainsi être à la fois réalisées par le biais du _pointeur_ en sélectionnant des éléments (tirer un trait pour dessiner par exemple) et des fonctions (via un menu déroulant), ou en écrivant quelques lignes d'instructions dans le langage Smalltalk.
Le fonctionnement de l'ordinateur, ou tout du moins une partie, reste accessible aux personnes qui souhaitent y recourir.

{{< citation ref="kay_personal_1977" page="37" lang="en" >}}
One young girl, who had never programmed before, decided that a pointing device ought to let her draw on the screen. She then built a sketching tool without ever seeing ours […]. She constantly embellished it with new features including a menu for brushes selected by pointing. She later wrote a program for building tangram designs.
{{< /citation >}}

Il ne s'agit pas que de laisser la possibilité d'interagir avec les logiciels disponibles via les modalités de programmation, mais de programmer aussi de nouveaux outils, ou de _programmer des pratiques_.
L'exemple donné ci-dessus par Adele Goldberg et Alan Kay est d'autant plus intéressant que cette jeune fille ne cherche même pas à voir quel outil existe pour dessiner avec un _pointeur_, elle en crée un elle-même.
Si cela requiert des compétences en programmation qui peuvent sembler difficiles d'accès, Alan Kay et Adele Goldberg précisent bien que les jeunes utilisateurs et utilisatrices qui utilisent Dynabook — ou plus précisément _interim Dynabook_ —, ont les capacités et l'envie de _programmer_, notamment du fait que cette expérience leur procure un "énorme sentiment d'accomplissement".
Cela fait partie des usages inattendus de cette expérience.

Si l'expérimentation présentée ici ne relève pas directement de pratiques d'édition, elle n'en demeure pas moins une initiative dans le champ de la gestion de l'information et de la création de contenus.
Le duo Dynabook et Smalltalk présente donc un intérêt substantiel qui vient confirmer l'idée selon laquelle le logiciel ne doit pas forcément être le mode d'interaction unique pour créer.
Mais que s'est-il ensuite passé pour que les principes de ce projet quelque peu utopique mais néanmoins concret n'aient pas perduré par la suite ?
Le développement des interfaces utilisateurs (graphiques) a pris un tournant que le même Alan Kay critique plus de dix plus tard, et c'est ce que nous analysons désormais.


### 5.2.2. Au centre l'interface

Si nous abordons la question des interfaces — champ d'études lié au logiciel —, c'est pour constater une évolution entre les débuts de l'informatique et la nécessité d'alors de programmer pour interagir avec la machine, et une omniprésence plus récente des logiciels et de leurs interfaces comme accès unique au numérique.
Notre argumentation ne porte pas sur un retour à la programmation pour n'importe quelle (inter)action numérique, mais sur un dévoilement des rouages informatiques et d'une possibilité de reconfiguration du médium informatique afin de disposer d'une maîtrise permettant l'émergence de nouveaux modèles épistémologiques via des pratiques éditoriales.
Dans ce cadre les logiciels et leurs interfaces utilisateur sont des éléments déterminants.
Avant d'explorer plusieurs initiatives éditoriales qui s'opposent au logiciel, et des pratiques créatives basées sur le code, nous exposons les critiques d'un des pionniers de l'ordinateur personnel et des interfaces, Alan Kay.

Plus de dix ans après son article co-écrit avec Adele Goldberg, Alan Kay propose un texte pour un ouvrage collectif sur les interfaces {{< cite "laurel_art_1990" >}}.
Cet article {{< cite "kay_user_1990" >}} est l'occasion pour lui de revenir sur les travaux qu'il a menés avec son équipe au Xerox PARC de Palo Alto autour du Dynabook, et les motivations sous-jacentes.
Il est ici question de considérer l'informatique — et l'ordinateur — non pas comme un _outil_ ou un _véhicule_ mais comme un _médium_.
La notion d'_agent_ est essentielle dans cette conception empreinte de la pensée de Marshall McLuhan.

La réflexion d'Alan Kay est aussi nourrie par des lectures en psychologie, prenant en compte des capacités d'apprentissage dans la définition des éléments d'interaction constituant des interfaces.
L'enjeu est délicat dans un contexte où la programmation _pure_ a encore une place importante, comme nous avons pu le voir avec des systèmes programmatiques de composition comme (La)TeX.

{{< citation ref="kay_user_1990" page="203" lang="en" >}}
The challenge would be to produce a language in which the act of programming produces within it an understandable explanation.
{{< /citation >}}

Le concept d'_agent_ intervient justement pour faire le lien entre la machine et les personnes qui y ont recours.
À travers cette conceptualisation Alan Kay critique en creux d'autres démarches{{< n >}}Au moment où Alan Kay rédige ce texte il travaille pour Apple, cela explique probablement une certaine retenue dans ses formulations que nous pouvons deviner comme très critiques.{{< /n >}} devenues à la fois complexes dans leurs finalités, et opaques dans leur adaptabilité.
Pour expliciter cela Silvio Lorusso paraphrase ainsi Alan Kay :

{{< citation ref="lorusso_liquider_2021" page="28" >}}
[…] les choses simples ne sont pas restées simples et les choses compliquées sont devenues moins possibles.
{{< /citation >}}

Sans faire ici un compte-rendu exhaustif sur ce texte foisonnant d'Alan Kay, nous retenons l'idée selon laquelle l'environnement ou le dispositif doit être appropriable, et cette appropriation passe d'une certaine façon par un acte de _programmation_ dont il fait mention à plusieurs reprises :

{{< citation ref="kay_user_1990" page="193" lang="en" >}}
While designing the FLEX machine I had believed that end users needed to be able to program before the computer could become truly theirs […].
{{< /citation >}}

Le positionnement d'Alan Kay est en cela proche de celui de Friedrich Kittler, la différence se faisant sur l'application de ce principe d'_écriture_ utilisé par ce dernier.
Alan Kay articule des éléments d'interfaçage avec une pratique de la programmation, il s'agit de commencer par le concret pour ensuite passer à l'abstrait, ou de faire usage de moyens iconiques (icônes, fenêtres) pour permettre un passage au symbolique (langage de programmation orienté objet), aboutissant au slogan : "Doing with Images makes Symbols" {{< cite "kay_user_1990" "196" >}}.
Smalltalk est pensé justement comme un langage de programmation suffisamment accessible et modulaire pour permettre à des enfants de le maîtriser pour toute sorte d'applications.
Ce lien entre interface utilisateur et programmation se retrouve dans d'autres travaux de recherche et dans des expérimentations, comme le travail particulièrement novateur de Muriel Cooper au MIT sur les interfaces graphiques {{< cite "maudet_muriel_2017" >}}.

Comme l'a souligné Silvio Lorusso dans son article "Liquider l'utilisateur" {{< cite "lorusso_liquider_2021" >}}, les concepts développés par Alan Kay et son équipe sont loin d'avoir été appliqués dans les logiciels tels que nous les utilisons majoritairement aujourd'hui.
Pourtant d'autres pratiques, fortement liées à l'édition, émergent en réaction à cette hégémonie du logiciel et à une forme d'uniformisation des pratiques qui en est induite.
Après avoir exploré comment les logiciels et leurs interfaces sont apparus, et critiqués leur usage massif, nous questionnons la façon dont il est possible d'éditer et de composer sans logiciel.


### 5.2.3. Éditer et composer sans logiciel

L'édition est un domaine avec des pratiques logicielles globalement uniformes, pour la structuration et la composition.
Pourtant, le design graphique est plus spécifiquement un domaine où des pratiques sans logiciel se développent.
C'est ce que nous analysons ici avec la question de l'appropriation du code par des designers (et non des éditeurs) pour développer des pratiques (nouvelles ?) de création et de production (dont de l'édition).

Le numéro de la revue _Graphisme en France_ de 2012 est un panorama de pratiques de designers que nous pouvons qualifier de _non conventionnelles_, en raison du choix ou de la constitution des outils de ces designers en dehors des pratiques majoritaires.
Dans l'article "Code = design", Kévin Donnot arrive au même constat que le nôtre, une majorité de praticiens et de praticiennes utilisent les mêmes logiciels, et ceux-ci ont une influence sur leur démarche de création et sur les artefacts produits.
Pourtant les pratiques artistiques sont historiquement habituées à ce que l'outil ait une place importante dans l'œuvre qui en résulte.

{{< citation ref="donnot_code_2012" page="7" >}}
Pourquoi ne pas assumer cette influence et choisir un outil en fonction de son empreinte ? Ne faudrait-il pas s’interroger sur l’outil qu’il serait juste d’employer avant de se tourner machinalement vers son logiciel habituel ?
{{< /citation >}}

C'est encore une fois la question de la relation avec la technique qui intervient ici, le fait de modeler ses propres outils ou au moins de remettre en cause ceux qui sont imposés.

{{< citation ref="donnot_code_2012" page="10" >}}
On peut alors envisager le design logiciel non plus comme une technique au sens réducteur du terme, mais comme partie intégrante du processus de design graphique.
{{< /citation >}}

Si les exemples donnés dans ce numéro de _Graphisme en France_ relèvent majoritairement du design graphique et de la visualisation de données — notamment avec les possibilités du design génératif —, les questionnements soulevés par Kévin Donnot mais aussi par Annick Lantenois concernent plus globalement les modes de création et de production d'artefacts tels que le livre.

{{< citation ref="lantenois_ouvrir_2012" page="19" >}}
[…] ces textes de programmation sont de la pensée qui dicte – impose – les formes, les syntaxes, les structures et, globalement, l’environnement sensible de lecture et d’écriture. […] De la maîtrise de ce qui s’écrit dans ces programmes dépend donc la liberté de ceux (les designers graphiques) qui utilisent les logiciels, de ceux (les lecteurs, les utilisateurs) à qui sont destinés les « objets », les dispositifs conçus avec ces logiciels, et de tous ceux qui suivront après nous. Les logiciels propriétaires d’écriture, de lecture, de mise en pages, de traitement d’images et de sons, traduisent, par conséquent, la pensée des firmes éditrices.
{{< /citation >}}

Les logiciels propriétaires, et les logiciels tout court, peuvent être oubliés au profit de démarches plus ouvertes, considérant la programmation comme partie intégrante d'une démarche de design.
C'est ce que confirment Julie Blanc et Nolwenn Maudet dix ans plus tard dans la même revue, avec une analyse des pratiques de programmation en design graphique.
Il s'agit plus spécifiquement de recherches et de travaux autour de la composition de pages, et de l'influence d'une culture du Web sur la production d'artefacts imprimés.
Ce Web est une occasion incroyable de repenser les modes de création et de production en design graphique.

{{< citation ref="blanc_code_2022" page="30" >}}
Ainsi les designers graphiques codent-ils pour être au plus près des supports de lecture et de communication avec lesquels ils travaillent. […] Ces pratiques du code contribuent en même temps à dépasser les approches issues des logiciels à interfaces graphiques qui avaient poussé les designers graphiques à adopter l’informatique comme principal outil au début des années 1990.
{{< /citation >}}

Le collectif Open Source Publishing (OSP){{< n >}}[http://osp.kitchen](http://osp.kitchen){{< /n >}}, cité à plusieurs reprises dans les deux textes, illustre cette démarche.
OSP développe d'abord des pratiques autour du logiciel libre, puis crée ses propres outils via la programmation.
Ce collectif a une place pionnière dans le mouvement dit du _CSS print_, qui émerge notamment en Belgique {{< cite "visscher_du_2019" >}} et qui consiste à _imprimer_ une page web pour produire des artefacts tels que des livres{{< n >}}Plusieurs expressions définissent cette pratique, nous préférons _CSS print_ à _web to print_ (trop ambigüe) ou _HTML to print_ (pas assez précise), puisqu'il s'agit d'utiliser le langage de mise en forme CSS pour concevoir et produire des documents paginés et des fichiers imprimables.{{< /n >}}.
Autrement dit à utiliser les technologies du Web — HTML, CSS et JavaScript — pour mettre en forme des artefacts imprimés et générer les fichiers pour l'imprimeur.
Les différentes personnes qui composent le collectif OSP créent des outils et mettent en place plusieurs processus de publication, utilisant certaines fonctionnalités bien précises du langage CSS et des navigateurs web{{< n >}}Il s'agit plus spécifiquement des modules CSS "CSS Paged Media Module Level 3" et "CSS Generated Content for Paged Media Module", standards développés depuis 1999 : [https://www.w3.org/TR/css-page-3/](https://www.w3.org/TR/css-page-3/) et [https://www.w3.org/TR/css-gcpm-3/](https://www.w3.org/TR/css-gcpm-3/).{{< /n >}} pour produire des documents paginés (posters, brochures, livres, etc.).
Il s'agit autant d'une démarche d'émancipation des logiciels en général et des logiciels dits propriétaires en particulier, qu'une volonté de construire leurs propres outils et de les rendre disponibles à tous.

Nous retenons trois éléments primordiaux dans ce dialogue entre ces deux textes et ses pratiques, qui s'étalent sur plus de dix ans dans le champ du design graphique : la marque de l'outil dans les créations, la démarche adaptative, et la perspective positive de ces initiatives.
Ces façons de faire non conventionnelles donnent tout d'abord un souffle nouveau aux identités graphiques elles-mêmes.
En plus d'être une occasion de créer des outils sur mesure, les artefacts générés peuvent conserver une empreinte graphique et visible de procédés génératifs, de programmes ou de polices typographiques non finalisées, ou de filtres inédits.
Ensuite ces démarches sont nécessairement adaptatives, il ne s'agit pas de créer de nouveaux instruments de zéro, mais de trouver des moyens d'adapter certains logiciels ou composants existants pour la pratique du design graphique — et notamment la composition de _pages_.
C'est également ce que décrit Nolwenn Maudet lorsqu'elle constate une "inadéquation" entre des designers et leurs outils, et qu'une piste de résolution pertinente est la programmation {{< cite "maudet_reinventing_2018" >}}.
Enfin, les différents entretiens ou témoignages de designers _programmeurs_ et _programmeuses_ ont en commun de révéler un rapport positif avec la technique dans la création ou l'adaptation d'outils.
Il s'agit d'une disposition constructive intégrée à la pratique du design graphique en général.

{{< citation ref="berends_html2print_2023" lang="en" >}}
[…] for me it’s more like a collection of practices and the tools that support these practices. [Alexandre Leray]
{{< /citation >}}

À l'injonction productiviste qui vient s'infiltrer jusque dans des pratiques liées à la fois à l'édition et au logiciel libre, se manifestant par la production d'outils _prêts à servir_, il y a une forme de désolidarisation des personnes qui pratiquent.
Nous prolongeons l'analyse de l'usage des technologies du Web pour _imprimer_ initié notamment par le collectif OSP.


### 5.2.4. Imprimer dans le navigateur, les expérimentations pionnières d'Open Source Publishing

Parmi les expériences d'adaptation ou de création d'outils, celles d'Open Source Publishing{{< n >}}Précisons ici que l'auteur de cette thèse a eu l'occasion de travailler avec une membre d'OSP, Amélie Dumont, sur un projet éditorial commandité par l'Université Lyon 3, de septembre 2022 à octobre 2023.{{< /n >}} touchent plus spécifiquement à l'édition avec la mise en page de documents de type livre — ou paginés —, proposant des modalités éditoriales qui dépassent le design graphique, et qui révèlent un besoin et une envie de créer des outils et des environnements.
À travers le mouvement dit du _CSS print_, et plus globalement du _creative coding_, nous analysons à quel point des pratiques d'édition se mêlent à la création d'outils _non conventionnels_.
Dit autrement, comment des pratiques de design s'accompagnent-elles d'une démarche conjointe de développement d'outils ?
Sans faire ici une étude de cas élaborée, nous relevons plusieurs éléments remarquables dans quelques projets et outils d'OSP.

Les expérimentations d'OSP autour de l'impression via un navigateur web commencent avec la production de livrets pour le Théâtre de la Balsamine en 2011.
La collaboration entre ce commanditaire et OSP prend la forme d'une recherche d'identité graphique, de la production de documents paginés — un programme — et l'expérimentation d'outils non conventionnels d'édition et de publication.
Dès les débuts de ce projet, qui se répète annuellement jusqu'en 2022, l'idée n'est pas que de proposer une nouvelle grammaire graphique pour la communication d'une structure culturelle, mais de repenser la façon d'éditer un document bien particulier qu'est un programme de théâtre.
Les outils alors utilisés varient, passant du logiciel de PAO libre Scribus à des expérimentations avec les navigateurs web.
À partir de 2013 OSP travaille avec les spécifications CSS Regions pour pouvoir mettre en pages des contenus d'habitude sous forme de flux, c'est le début du mouvement dit _CSS print_ et la mise en place d'un workflow nommé "HTML2print".
L'idée est d'utiliser le langage HTML en tant que structuration sémantique, et le format CSS comme instructions de mise en forme, sans recourir à des logiciels autres que le navigateur pour aboutir à un document au format PDF.
Si la collaboration avec le Théâtre de la Balsamine est l'occasion de tester de multiples approches, cette chaîne de traitement graphique et de production de documents paginés et imprimables "HTML2print" est ensuite par exemple systématiquement utilisée pour le magazine _Médor_ à partir de 2015{{< n >}}[https://medor.coop](https://medor.coop/){{< /n >}}.

OSP s'implique ensuite dans plusieurs projets éditoriaux, dont un livre co-signé avec Catherine Lenoble aux éditions HYX, _Anna K_.
Stéphanie Vilayphiou et Alexandre Leray, membres d'OSP, construisent avec Catherine Lenoble deux objets éditoriaux : un site web et un livre imprimé.
L'implication des deux graphistes dans cette aventure éditoriale dépasse la composition ou la production d'un artefact, il s'agit aussi de produire des formes narratives graphiques faites de lignes de code ou de graphes, ce qui explique que le livre soit signé Catherine Lenoble et OSP.
Tout est réalisé avec les technologies du Web, le logiciel est ici relégué au second plan, la majeure partie du travail éditorial passant par la modification du _code_ — HTML, CSS et Python pour certaines manipulations.

{{< figure type="figure" src="osp-anna-k-01.png" legende="Deux pages intérieures extraites du livre imprimé _Anna K_ de Catherine Lenoble et OSP" >}}

Cet ouvrage est un exemple typique de publication multimodale telle que nous l'avons déjà évoquée{{< renvoi chapitre="4" section="4" >}}, les deux objets étant néanmoins distincts pour leur production.
Ce projet éditorial est également une occasion pour OSP d'affiner les outils développés pour produire des objets éditoriaux divers, ici l'usage de la spécification CSS Regions déjà évoquée.
Point important, tous les projets d'OSP sont accompagnés d'une documentation, dans l'optique de pouvoir réutiliser les outils au sein du collectif mais aussi plus largement — les licences qui accompagnent ces bouts de code sont très permissifs.
Aussi, un blog documente d'un point de vue plus général les expérimentations diverses{{< n >}}[http://blog.osp.kitchen/](http://blog.osp.kitchen/){{< /n >}}.

Le collectif PrePostPrint{{< n >}}[https://prepostprint.org](https://prepostprint.org){{< /n >}} se constitue en 2017 à l'initiative de Raphaël Bastide et Sarah Garcin, faisant suite aux pratiques initiées par OSP.
En effet, ces pratiques se répandent dans la communauté composite du design graphique, dans les studios et les écoles (principalement en Europe), comme une revendication forte d'adopter d'autres moyens que cette vision unique du _logiciel_ telles que le décrivent Julie Blanc et Nolwenn Maudet dans leur article déjà cité {{< cite "blanc_code_2022" >}}.
Durant l'automne 2021 plusieurs présentations autour de l'usage des technologies du Web pour concevoir et produire des documents paginés et imprimés ont lieu dans le cadre de l'événement "Open Publishing Fest" organisé par Adam Hyde et Julien Taquet et soutenu par la Collaborative Knowledge Fondation (Coko){{< n >}}[https://openpublishingfest.org](https://openpublishingfest.org){{< /n >}}.
La "bibliothèque _web to print_", coordonné par Lucile Haute avec Quentin Juhel et Antoine Lefebvre{{< n >}}[http://2print.org](http://2print.org){{< /n >}} s'inscrit également dans ce mouvement, recensant les multiples productions éditoriales paginées qui reposent sur les technologies du Web et une pratique du code.
Un trait commun transparaît à travers ces initiatives : l'assemblage ou la création d'outils qui reposent sur le logiciel libre afin de prendre en compte des besoins formulés par celles et ceux qui pratiquent le design graphique, et non des contraintes imposées par des entreprises privées.

Une dernière question doit être posée ici : s'agit-il vraiment de créer des outils réutilisables ?
Les efforts d'OSP, que ce soit pour les projets évoqués ci-dessus ou pour d'autres, se concentrent surtout sur les artefacts.
Il arrive ainsi que certaines documentations soient incomplètes, ou que l'organisation des dépôts de code ne facilite pas la réutilisation de certains programmes ou micrologiciels.
Comme l'a dit plus haut Alexandre Leray, il s'agit de documenter les pratiques et les outils qui les accompagnent, plus que de proposer des _logiciels_ prêts à l'emploi.
Cette démarche reflète une inscription dans la culture _hacker_, fondamentalement anticapitaliste, qui préfère ainsi mettre à disposition des productions sous des conditions qui permettent leur réutilisation, leur adaptation et souvent aussi leur finalisation, plutôt que formater des instruments éditoriaux.
Cet usage créatif de la programmation, tournée vers la pratique plus que vers des _solutions_ ou des _produits_, fait l'objet du développement qui suit.


### 5.2.5. Se passer de logiciel, entre bricolage et pratiques collectives et collaboratives

La place de la programmation dans les pratiques de design graphique est un terrain particulièrement stimulant pour nos recherches, tant les corps de métier et les personnes qui les incarnent les font évoluer et révèlent de nouvelles modalités d'édition, des perspectives d'émancipation _avec_ le numérique ou l'informatique.
Après les deux numéros de _Graphisme en France_ en 2012 et 2022, l'ouvrage _Graphic Design in the Post-Digital Age: A Survey of Practices Fueled by Creative Coding_ {{< cite "conrad_graphic_2021" >}} questionne la relation du design graphique avec des pratiques de programmation.
Ce travail de recherche, initié par la Haute école d'art et de design de Genève, regroupe deux essais et une série d'entretiens avec des designers dans le domaine du graphisme — le livre a été édité une première fois par Onomatopee en 2021 puis _réédité_ par Set Margins' en 2023 {{< cite "conrad_graphic_2023" >}}.
Si l'édition n'est pas au centre de cet ouvrage, c'est un sujet qui revient pourtant régulièrement, le livre ayant encore une place importante dans les pratiques du design graphique.

L'objet de _Graphic Design in the Post_Digital Age_ est de récolter des témoignages de pratiques de programmation créative — ou _creative coding_ — et d'apporter un regard critique sur ces initiatives.
Si le graphisme était originellement artisanal et artistique, est-ce que la programmation pourrait devenir l'outil d'un nouveau type d'artisanat ?
C'est la question que pose Demian Conrad dans l'introduction {{< cite "conrad_graphic_2021-1" >}}.
L'ère du logiciel, désormais en grande partie dominée par les produits d'Adobe dans le champ du design graphique, pourrait ainsi voir advenir une communauté hétérogène qui construit elle-même ses outils.
Demian Conrad précise plusieurs postulats nécessaires pour comprendre une situation contemporaine, et notamment l'arrivée d'outils permettant de générer des formes graphiques comme Processing, ou encore la période _post-digital_ comme point de départ d'hybridations entre imprimé et numérique.

Dans l'essai qui suit cette introduction, Silvio Lorusso apporte un regard critique bienvenu, distinguant deux postures antagonistes : apprendre à programmer ou programmer pour apprendre.
Il y a une certaine pression économique, les compétences en programmation étant attendues par une société qui a besoin d'ouvriers du code plutôt que de bricoleurs créatifs.
Silvio Lorusso insiste à juste titre sur la tension entre la programmation vue comme un gain de temps pour des opérations d'habitude longues, et la programmation comme processus d'apprentissage nécessairement lent :

{{< citation ref="lorusso_learn_2021" page="32" lang="en" >}}
This is the paradox of creative coding: the coding part is supposed to make things faster, the creative part requires that things go slowly.
{{< /citation >}}

La programmation, dans le cas du design graphique, est donc une pratique qui permet de repenser l'usage de l'informatique plutôt que d'automatiser toute sorte de tâches.
Nous retrouvons là un motif déjà abordé avec l'approche des humanités numériques{{< renvoi chapitre="3" section="4" >}}.
Construire un environnement sans logiciels, ou en tout cas sans les outils dont la profession est assujettie, demande du temps.
Ce cheminement est valorisé par des studios ou des collectifs qui, en plus d'apporter une identité graphique spécifique comme nous l'avons mentionné plus haut, amène aussi un nouveau cadre épistémologique à leurs commanditaires.
C'est notamment ce qui ressort des entretiens qui suivent ces deux textes.

Nous notons plusieurs éléments récurrents dans les témoignages des vingt-deux designers ou collectifs, marquant à la fois les possibilités mais aussi les limites des outils ainsi créés.
Le premier apport de la programmation, dans le design graphique en général, tient dans des outils créés sur mesure, et cela _pendant_ la création.
Dans le cas de l'édition il s'agit surtout d'avoir recours au _CSS print_, pour construire de nouvelles interfaces de travail : le navigateur web est à la fois le _logiciel_ qui produit une version imprimée d'un site web — certes bien spécifique —, mais aussi le moyen de prévisualiser ce travail.
Aussi, certaines des personnes interrogées signalent que les outils développés le sont également pour les commanditaires, toutefois ces derniers n'utilisent pas toujours ces instruments qui sortent quelque peu de l'ordinaire par rapport aux logiciels traditionnels, comme le rapporte notamment le collectif Luuse {{< cite "conrad_graphic_2021" "291" >}}.
La question ici pourrait être de savoir si, dans ce cas, les personnes qui éditent ne doivent pas adopter la même démarche pour être en mesure d'utiliser elles-mêmes les outils ainsi créés.
Enfin, parmi les multiples réflexions dont témoignent ces pratiques hétérogènes, une distinction est faite entre différents types de codes.
De la même façon que Silvio Lorusso pointait la différence entre une profession (développeur) et une main-d'œuvre (codeur), Marianne Plano signale que le soin apporté au code diffère selon l'artefact créé.
Dans le cas d'un artefact imprimé, le code pour parvenir à ce résultat peut rester incomplet, ce qui ne peut pas être possible pour un artefact qui est lui-même numérique.

{{< citation ref="conrad_graphic_2021" page="294" lang="en" >}}
If you use programming to create a poster and your code is a bit messy, it does not matter as long as the outcome is compelling, but if you are creating a website, the code has to work properly. [Marianne Plano, collectif Luuse]
{{< /citation >}}

Programmer sans être développeur ou développeuse de métier est possible pour constituer de nouveaux modèles éditoriaux et épistémologiques.
Les outils créés ne sont ni vendus ni mis à disposition pour être réutilisés sans un effort de compréhension et d'adaptation, ce qui explique aussi que les éditeurs de logiciels commerciaux ne s'inquiètent probablement pas pour le moment de telles initiatives.
Cet effort de décomposition et d'ouverture, initié pour fabriquer des processus hétérogènes, aboutit à des pratiques _sans_ le logiciel.
Dans le cas de l'édition, et plus spécifiquement du mouvement dit du _CSS print_, une bibliothèque de code est régulièrement citée dans les entretiens, il s'agit de Paged.js{{< n >}}[https://pagedjs.org/](https://pagedjs.org/){{< /n >}}.
Les origines et le fonctionnement de Paged.js, décrits dans la section suivante{{< renvoi chapitre="5" section="3" >}} à travers l'étude de cas de C&F Éditions, révèlent une intention collective pour permettre l'émergence d'un nouveau paradigme pour la composition et la mise en page de documents paginés autour de standards.
Le développement de cette bibliothèque de code marque la nécessité de réunir des efforts divers autour du _CSS print_, de permettre de _bricoler_ mais aussi de penser des environnements stables et durables, de rassembler les énergies dans le prolongement du logiciel libre.
Loin d'être une uniformisation des pratiques comme nous avons pu l'observer avec certains logiciels dans l'édition, Paged.js est une occasion de réunir des initiatives plurielles, de faire converger les différentes expérimentations présentées dans cette section tout en laissant le champ des possibles — graphiques et processuels — ouverts.
Il convient désormais d'interroger la cristallisation de ces pratiques dans le domaine de l'édition, et plus spécifiquement du côté d'une structure d'édition.
Au-delà de la commande en design graphique, comment une maison d'édition est-elle en mesure de faire des livres sans logiciels ?
C'est l'objet de la prochaine section sous la forme d'une étude de cas de C&F Éditions.