Pour des programmes ouvrables (plugins, hacks, hooks)

Afin de poursuivre notre étude de directions prospectives au sein des programmes numériques, nous évoquerons quelques techniques susceptibles de favoriser des développements non anticipables lors de la conception de l’objet. Plus exactement, il s’agit ici de penser, au sein de la conception des objets, « une certaine marge d’indétermination⁷⁶⁵ », de ménager une ouverture — sans présupposer ce qu’il pourra en advenir. Cette façon de designer des programmes n’est pas de l’ordre d’un objet « incomplet ». Le programme initial peut très bien fonctionner en tant que tel, mais permettre aussi de faire autre chose, ou plutôt de permettre à d’autres d’en faire autre chose. Ménager une disponibilité, rendre lisible un fonctionnement, permettre d’adopter un objet dans sa propre langue sont des démarches qui nous intéressent. Afin de comprendre en quoi consistent précisément les plugins et les hooks, nous étudierons ces deux façons de faire dans le contexte du « système de gestion de contenus » (cms) WordPress⁷⁶⁶, étant entendu que de plus en plus de programmes y ont recours.

Placé sous licence libre gpl, WordPress « équipe⁷⁶⁷ » en 2013 près de 16 % des sites web dans les monde, et est utilisé par un nouveau site sur quatre⁷⁶⁸ [ Fig. 248 ]. Fig. 248 Tout comme GitHub, il s’agit d’un projet hybride, avec une face faisant la promotion de la liberté dans les logiciels, et une autre à vocation commerciale (blogs payants hébergés sur WordPress.com). Notre analyse se concentrera sur le script open source (téléchargeable sur www.wordpress.org) à installer sur son serveur. WordPress nous intéresse ici comme objet d’étude parce qu’il permet de s’exercer avec le programme à différentes strates de compétences. Contrairement à des dispositifs comme Instagram⁷⁶⁹ qui n’ont qu’un seul stade d’apprentissage (tout est conçu pour anticiper les comportements), WordPress contient des modes d’accès pluralisés. Le niveau d’usage « basique » peut ainsi cohabiter, quand les compétences augmentent, avec des formes de pratiques plus singulières. La pertinence du design de WordPress permet ainsi à différents degrés d’expertise d’exister au sein d’un même objet. L’ergonomie de l’interface d’administration [ Fig. 249 ] Fig. 249 (back office) de WordPress permet de rendre lisible pour le plus grand monde les actions de base tournant autour de la publication d’articles. Le succès de WordPress est en grande partie explicable par cette attention portée aux non-spécialistes. La compréhension du fonctionnement interne de l’objet technique qu’est WordPress ne nécessite pas de changer de programme ; tout est potentiellement lisible pour qui s’exerce.

Le fait que WordPress (tout comme GitHub ou Processing⁷⁷⁰) soit utilisé dans des directions qui n’étaient pas celles prévues au départ s’explique par la rencontre d’une simplicité apparente et d’une grande modularité interne. C’est à la fois en faisant très bien ce pour quoi il étaient prévus (gérer des versions de fichier, publier des articles) et en incitant à des pratiques que ces deux programmes se sont progressivement imposés comme des standards. Cette pensée du logiciel comme standard va à l’encontre de la notion d’« accessibilité », qui consiste le plus souvent à fournir après coup des modes d’accès adaptés au plus grand nombre. Des programmes comme Firefox OS, GitHub ou WordPress nous font réfléchir à propos de ce que formulait Walter Gropius en 1958 dans son article intitulé « De l’unité dans la diversité ». Partant du constat de l’éclatement de la société moderne, il accuse la science « d’étudier ‹ tout › à dessein » :

En poussant la spécialisation à l’extrême, notre époque scientifique a voilé notre perception de l’entité complexe de notre existence. Déconcerté par la profusion des problèmes confrontés, le spécialiste essaye de se libérer des contraintes de la responsabilité collective […]. Cette attitude a provoqué une dissolution générale des rapports culturels, conduisant au démembrement et à l’appauvrissement de la vie⁷⁷¹.

C’est le rapport du spécialiste à l’unité de la société qui est ici posé. Si l’on essaye d’adopter cette attitude dans le champ (forcément anachronique) des programmes, on pourra alors penser qu’une fragmentation d’un logiciel en plusieurs entités entraînerait une perte de conscience de la responsabilité collective. Il nous faut tendre, même si cela est impossible dans le faits, vers des programmes qui nous font penser en commun. Comme l’indique Walter Gropius, le design est un « art social⁷⁷² » qui a directement à voir avec la constitution d’une démocratie toujours à venir dans sa forme authentique. Stratifier les degrés de compétence sans les délimiter permet de penser un monde habitable par tous :

[Nous savons que] c’est la diversité dans l’unité et non la conformité qui constitue la trame de la démocratie. Si nous ne parvenons pas à réconcilier la diversité et l’unité, nous finirons comme des robots. […] Ce n’est pas l’instrument mais notre intelligence qui est en défaut lorsque les choses nous échappent. La spécialisation outrancière a amorti notre faculté d’unifier notre existence complexe et ceci a conduit à la dissolution des relations culturelles. La vie, par conséquent, s’est appauvrie d’une façon incommensurable. […]⁷⁷³

Le corps enseignant et les étudiants [du Bauhaus] parvenaient à conférer à leurs travaux, une homogénéité basée, non sur des éléments stylistiques extérieurs, mais sur une démarche fondamentale du design, d’où découlaient des produits standardisés plutôt que des nouveautés⁷⁷⁴.

Alors que WordPress était à l’origine destiné à créer des blogs (journaux en ligne), il a rapidement évoluer pour pouvoir, depuis quelques années, héberger n’importe quels types de contenus : portfolios, annuaires, jeux, revues, etc. Si l’objet « standard », tel que le pensait Gropius, pouvait se prêter à de nombreuses configurations, sa base demeurait néanmoins stable. La pensée d’un logiciel (et de langages formels) « standards » s’écarte quelque peu de cette vision en proposant une base, certes durable, mais qui peut aussi changer. Les anciennes fonctions sont toujours présentes et compatibles avec ce qui peut s’y « ajouter », mais la base évolue pour accueillir en son sein d’autres possibilité d’extension. Il n’y a donc pas de contradiction entre l’approche du Bauhaus des « objets types » et les programmes numériques, mais plutôt une prise en compte des possibilités des matières numériques pour prolonger et étendre ce type de conception réunissant unité et diversité.

Pour reprendre l’exemple de WordPress, en plus des deux entrées de base que sont les articles et les pages, l’interface d’administration permet, depuis la version 3.0 (juin 2010) de créer des « custom post types » (« types de contenus personnalisés »). Il est par exemple possible de créer une entrée « livres », puis des sous-classements auteurs, titres, résumé, etc. L’administrateur de WordPress est ainsi en mesure de décider lui-même de la structuration (stockage des données et publication). Il n’est pas considéré comme un rédacteur, mais comme un éditeur. Ou plutôt : être « simplement » rédacteur n’empêche pas la possibilité d’être aussi éditeur.

Au-delà des fonctions de base qui sont déjà très souples, un mode d’ouverture de WordPress intéressant à étudier se situe dans ses quelques 20 000 « modules d’extension » (plugins). Le recours à un plugin pour ajouter des fonctions ou gérer le stockage des données permet d’assurer sur le long terme une comptabilité de son site avec n’importe quelle « thème » (l’apparence du site côté « consultation »). On appelle plugin un supplément de code qui vient se greffer à un programme existant⁷⁷⁵. Le plugin permet d’élargir les fonctions de base en proposant des types d’utilisations avancées, à la demande. On parle habituellement de « logique modulaire » pour désigner cette flexibilité d’usages. Bien que cette expression décrive correctement ce type de démarche du point de vue d’un concepteur, elle nous semble insuffisante pour comprendre ce qui se joue ici. Les plugins permettent de travailler la structure de base du programme (le « core »), sans que celui-ci ne soit irrémédiablement altéré. Le code source du programme principal peut toujours recevoir des « mises à jour ». Il arrive aussi que des plugins soient directement intégrés dans le cœur du programme, et deviennent dès lors communs à tous les utilisateurs. Par exemple, le système de gestion des menus de WordPress 3.0 fut directement repris du plugin WooNav⁷⁷⁶, développé par la société WooThemes. Les plugins « appareillent » un logiciel qui, sans eux, resterait limité par ce que les concepteurs ont prévu. Le fait de devoir chercher et d’ajouter soi-même ces modules est déjà, aussi simple que puisse paraître cette opération, une prise de conscience technique.

Au sein du navigateur libre Firefox⁷⁷⁷, les plugins jouent également un rôle de premier plan. Le plugin le plus populaire est AdBlock⁷⁷⁸, qui remplace tous les blocs publicitaires par du vide. On peut aussi citer Ghostery⁷⁷⁹, qui permet de visualiser et de bloquer les scripts de « traçage » (« tracking ») des données personnelles, ou encore Firebug⁷⁸⁰, un programme permettant de visualiser et de travailler en local le code source de n’importe quel site web. Un autre plugin Firefox intéressant est Stylish⁷⁸¹, qui permet de changer (uniquement sur sa machine) l’apparence de n’importe quel site web en superposant ses styles css à ceux existants. Ces quatre exemples nous semblent aller dans le sens de ce que défend Richard Stallman. Il ne sont pas seulement des programmes au code source ouvert, ils ouvrent des espaces de réflexion en rendant de la liberté à ceux qui en font l’expérience. Les plugins ne sont évidemment pas réservés aux logiciels libres. Certains programmes « propriétaires » peuvent ainsi être « appareillés » pour élargir ou déplacer leurs fonctions premières. Même si les logiciels Adobe peuvent être accusés d’orienter la « création » dans des directions difficiles à contourner, il est néanmoins possible de passer par des plugins pour « appareiller » son environnement de travail. Il existe par exemple des groupes de programmeurs qui travaillent autour du logiciel Adobe InDesign⁷⁸², utilisé pour rédiger cette thèse. On peut ainsi bénéficier de compteur de caractères très précis, d’index automatiques pour les noms propres⁷⁸³ et les images, de corrections typographiques automatisées, etc. On passe ainsi d’une logique de la page et de la sélection d’actions dans des menus (comme dans Microsoft Word) à la co-construction d’un environnement de rédaction sur mesure. Même si ce mode d’écriture reste en partie marqué par la culture de l’imprimé, grâce aux plugins il s’ouvre sur des logiques d’écriture davantage propres au numérique.

De la même manière, le plugin Scriptographer⁷⁸⁴, créé en 2004 par Jürg Lehni⁷⁸⁵, a permis d’étendre les possibilités du logiciel de création vectorielle Adobe Illustrator⁷⁸⁶. En donnant la possibilité aux utilisateurs d’écrire des commandes en langage JavaScript⁷⁸⁷, Scriptographer permet de s’émanciper des limitations logicielles entraînant des tendances et récurrences graphiques [ Fig. 250 ] : Fig. 250 « Scriptographer redonne le pouvoir à l’utilisateur et confronte l’approche d’un produit fermé avec la philosophie open source. »⁷⁸⁸ Comme le dit Jürg Lehni :

Scriptographer nous permet de récupérer la relation personnelle que nous avions avec nos outils, et de réintroduire de la tension et de l’artisanat dans notre logiciel hautement optimisé afin d’apprendre à créer des outils par nous-mêmes. Après tout, l’ordinateur avait été conçu comme un outil pour créer des outils⁷⁸⁹.

Cet acte de reprise en main de dispositifs plus ou moins économisés n’est pas de l’ordre de ce que soutient Giorgio Agamben à propos des « dispositifs » contrôlant qu’il faudrait « profaner⁷⁹⁰ » pour les rendre à « l’usage commun ». La prise de conscience technique et personnelle qui se dégage de ces plugins ainsi que leurs possibilités de réglage sont bien de l’ordre d’un « appareillage » des programmes. L’éditeur d’un programme acceptant des plugins doit donc mettre en place des fonctions permettant une perte de contrôle sur ce qui sera produit grâce à ces marges de création. Pour qu’on puisse parler de plugin, il faut que le cœur du programme reste inchangé. Les programmeurs doivent aussi pouvoir accéder à des documentations, pour savoir ce qu’il est possible de faire. C’est pourquoi, paradoxalement, il peut arriver qu’un logiciel propriétaire soit plus ouvrable que son homologue dit libre. Mais, même si le plugin du logiciel propriétaire est placé sous licence libre, il reste dépendant d’une base de travail qui peut disparaître ou muter sans préavis. Une mise à jour du logiciel peut ainsi rendre obsolète le travail fourni. Le développement de Scriptographer a ainsi été arrêté en 2012 suite aux limitations techniques de la « suite » propriétaire Adobe cs 6⁷⁹¹. Développée depuis 2011 par Jürg Lehni (le fondateur de Scriptographer) et Jonathan Puckey, la « librairie » open source Javascript Paper.js⁷⁹² facilite la manipulation de l’élément html 5 Canvas⁷⁹³. Émancipé du logiciel Adobe Illustrator, le programme Paper.js⁷⁹⁴ permet ainsi d’interagir avec des formes dynamiques directement dans un navigateur web [ Fig. 252 ]. Fig. 252 Cet exemple nous montre que s’appuyer uniquement sur une logique propriétaire ne permet pas de garantir dans le temps une liberté et une ouverture effectives.

Une autre possibilité d’ouverture des programmes réside dans les hooks (« accroches ») et hacks (« bricolages »), dont les logiques sont assez proches de ce que nous avons vu des plugins. Dans l’environnement WordPress, un hack désigne habituellement un fragment de code servant à rajouter ou modifier une fonction⁷⁹⁵. Suivant les cas, on insère ce code dans une page de son thème, dans un plugin créé sur mesure, ou dans le fichier « functions.php ». Le hack incite à « bricoler » son environnement de travail pour l’adapter à ses projets. L’existence du fichier « functions.php » est rendue possible par l’anticipation de ces ouvertures dans le cœur (core) de WordPress. Concrètement, cela signifie qu’il existe dans le code source principal des portes d’entrées où peuvent être chargées d’autres fonctions. On parle alors de hook pour désigner ces « accroches » ménagées dans le code source initial. Le hook consiste à anticiper la possibilité d’un appareillage dans la conception même du logiciel. Il permet à des plugins ou hacks d’intervenir sur le programme principal, qui pourra être mis à jour sans écraser les modifications de l’utilisateur. Si l’on reste dans l’exemple de WordPress, il est particulièrement important de réfléchir sous forme de plugins et de hacks car le système fait l’objet de changement réguliers plusieurs fois par an. De plus, séparer ses propres modifications du cœur du programme permet de les partager avec d’autres personnes, qui pourront à leur tour les travailler.

En agissant au niveau du fonctionnement de l’objet technique, plugins et hacks participent d’une « ouvrabilité » des programmes. Cette qualité dépasse l’opposition libre/propriétaire, comme nous l’avons vu avec l’exemple d’InDesign. Il y a donc des façons de faire du design qui, tout en livrant des objets techniques fonctionnels, permettent la constitution de savoirs communs. Cette faculté des programmes à s’hybrider, se grouper et à se singulariser rejoint ce que Gilbert Simondon défend à propos d’une technique jamais stabilisée et toujours en « devenir ». Designer des programmes ouvrables est donc prendre parti pour une technique vive, toujours susceptible d’« individuer » et de dépasser les individualités par lesquelles elle est activée. Cette « marge d’indétermination⁷⁹⁶ », aussi fine soit-elle, est essentielle à penser.