Programmer des programmes (Firefox OS et GitHub)

Nous avons vu que le concept d’appareillage consistait en un double mouvement : la possibilité d’intervenir sur le fonctionnement de l’objet technique, et la préservation de son altérité mécanique. Nous allons à présent étudier deux programmes numériques qui nous semblent aller dans ce sens : le « système d’exploitation » pour terminaux mobiles Firefox OS⁷⁴¹, et le site web contributif GitHub, dédié au développement collaboratif de programmes.

Les dispositifs clôturés des terminaux mobiles dominants ne permettent pas de développer des programmes pleinement ouvrables. Avec sa « plateforme » iOS, Apple limite considérablement le design des « applications⁷⁴² », ce changement de terme indiquant déjà qu’il y a ici une façon de faire du numérique qui est problématique. De la même manière, mais d’une façon plus ambiguë, ce que dit Richard Stallman du « système d’exploitation » Android de Google nous fait penser que, en dépit des apparences, il y a encore à faire pour pouvoir soutenir cette initiative. Afin de savoir si « Android est vraiment libre⁷⁴³ », Stallman consacre une partie de son argumentation au « micrologiciel » d’Android, qui gère l’accès au réseau. Stallman le compare avec un « circuit » pour montrer que ce programme n’en est justement pas un. Un circuit serait un programme qui ne ferait que « communiquer avec le réseau », sans possibilité d’intervention extérieure. Or, le « micrologiciel » préinstallé sur les terminaux Android n’est pas seulement un « circuit malveillant », mais bien un programme. Il est potentiellement néfaste en tant qu’il permet (sur certains modèles) d’exercer un contrôle total afin de transformer, par exemple, le terminal en dispositif d’écoute. Il peut aussi désinstaller n’importe quel programme ajouté par l’utilisateur ou accéder aux données en mémoire. Stallman conclut cette analyse par ces recommandations :

Pour résumer, on peut tolérer des versions non libres d’un micrologiciel gérant l’accès au réseau à la condition qu’il ne soit pas mis à jour, qu’il ne puisse pas prendre le contrôle de l’ordinateur principal, et qu’il puisse seulement communiquer quand et si le système d’exploitation libre le permet. En d’autres termes, il doit être l’équivalent d’un circuit, et ce circuit ne doit pas être malveillant. Il n’y a pas d’obstacle à construire un téléphone Android qui ait ces caractéristiques, mais nous n’en connaissons aucun⁷⁴⁴.

Ce programme sur lequel aucun contrôle n’est possible est « malveillant » car il peut faire l’objet de « mises à jour » automatiques. On pourra d’ailleurs se demander quelle est la pertinence de l’expression « mise à jour » quand l’installation d’une nouvelle version du programme se fait de façon masquée : où est-il fait jour ? La fin de l’article de Stallman poursuit ces interrogations en répondant à la question initiale :

Android représente une étape majeure vers un téléphone portable libre qui soit contrôlé par l’utilisateur, mais il y a encore beaucoup de chemin à parcourir. […] Même si les téléphones Android d’aujourd’hui sont considérablement moins mauvais que les smartphones d’Apple ou de Windows, on ne peut pas dire qu’ils respectent vos libertés⁷⁴⁵.

Constatant que cette alternative à Apple iOS pose dans les faits de nombreux problèmes, la Fondation Mozilla a débuté en 2012 le développement de Firefox OS [ Fig. 240 ]. Fig. 240 Afin de ne pas chercher à imposer un énième « système d’exploitation », Mozilla a fait le choix de permettre l’installation de Firefox OS sur une instance utilisant le même « noyau » qu’Android (Linux, etc.). Il est donc possible d’avoir Android et Firefox OS au sein d’un même terminal mobile et de pouvoir basculer de l’un à l’autre. En ce sens, il est possible de considérer que l’OS de Mozilla « appareille » Android, bien qu’il ne soit pas dépendant de celui-ci. Ce qui nous intéresse plus particulièrement dans le fonctionnement de Firefox OS concerne la conception des « applications ». Au lieu de proposer une plateforme restrictive, Mozilla a choisi d’utiliser les langages standards du Web. Aussi, les « applications » de Firefox OS sont construites en html 5 et autres langages du « Web ouvert⁷⁴⁶ » [ Fig. 241 ]. Fig. 241 Cela permet aux développeurs de travailler sur des bases communes, et de proposer leurs programmes sur d’autres supports sans rien avoir à changer. Ils gardent un contrôle total sur les contenus et le développement de leurs objets. Alors que les terminaux mobiles proposent depuis plus de cinq ans des « app store », il est frappant de constater que le choix technique retenu par Mozilla soit ce qui était déjà là, sous nos yeux, depuis l’invention du Web par Tim Berner-Lee. La voie suivie par Firefox OS rejoue les vieilles querelles autour d’un Web fragmenté, celles qui opposaient Netscape et Internet Explorer, forçant les concepteurs de sites web à programmer deux versions pour obtenir à l’écran le même résultat. Plus encore, la structure même des plateformes d’applications type Apple iOS éloigne ces programmes « connectés » du Web, les fermant sur eux-mêmes dans des échanges non contrôlables par l’utilisateur. Ce que nous montre la Fondation Mozilla avec Firefox OS (et bien sûr avec le navigateur web Firefox), c’est que la liberté dans les programmes est fonction de langages communs. Une base potentiellement compréhensible de tous facilite les développements. La pertinence du design de ce programme s’appuie avant tout sur des choix techniques, et non pas sur l’apparence de l’interface. Avant de se poser des questions d’ergonomie, il convient donc de réfléchir à ce qui ne se voit pas immédiatement, mais qui oriente néanmoins ce qu’il sera possible de produire.

Comme pour l’exemple du Manifeste Mozilla⁷⁴⁷ étudié plus haut, nous pouvons nous interroger sur les choix lexicaux employés pour décrire les choix de conception. Parler de « plateforme ouverte », d’« écosystème », de « chaîne de valeur », de « clients », d’« applications » et d’« innovations » entraîne une confusion avec les produits non « libres ». Si la façon de faire du numérique diffère des modèles du « Web 2.0 », il faut aussi trouver de nouveaux mots, ou redonner aux termes existants des sens plus justes. Pourquoi ne pas affirmer que Firefox OS ne propose pas des applications⁷⁴⁸ mais des programmes basés sur les langages formels du Web ? Les logiciels libres se doivent d’inventer un langage qui correspond à leurs spécificités plutôt que de chercher à adhérer aux spécificités du marché. C’est ce que nous allons voir avec l’exemple de GitHub.

Lancé en 2008, ce site web est un bon exemple de programme qui développe son propre vocabulaire. GitHub propose « l’hébergement et la gestion du développement de logiciels utilisant le programme Git⁷⁴⁹ ». Créé en 2005⁷⁵⁰, Git était à la base un système de fichiers, c’est-à-dire une façon de stocker et d’organiser les informations sur différents supports. Git a ensuite évolué pour permettre de gérer l’évolution du contenu d’une arborescence de fichiers. Il enregistre automatiquement les modifications de chaque fichier pour les classer en « versions⁷⁵¹ ». La particularité de Git est de ne pas dépendre d’un système centralisé. Les programmeurs peuvent travailler séparément sur un même projet, sans risque d’écraser les fichiers. Une fois connecté au réseau, le programme est capable de rassembler les différentes versions, de les comparer et de les classer sans « écraser » deux versions différentes. Git est donc, si l’on simplifie, un gestionnaire de fichiers permettant d’identifier aisément les modifications des codes sources. Le site web GitHub permet de créer des comptes gratuits pour développer des logiciels libres, et des comptes payants qui permettent de travailler en privé. GitHub agit donc comme un système permettant de centraliser facilement les « dépôts » de fichiers. Il existe également un « logiciel client » Windows et Mac, ainsi qu’une version « hébergeable » sur son serveur pour décentraliser le stockage, et avoir ainsi un contrôle plus accru de ses données. Ce qui est intéressant avec GitHub, c’est qu’il facilite la compréhension de Git par une interface visuelle qui rend lisibles ses principales spécificités⁷⁵².

GitHub permet entre autres les fonctions suivantes :
– commenter/modifier le code d’un fichier (« code review »)  ;
– comparer deux versions d’une même fichier (« versioning »)  ;
– gérer les droits des différents membres d’une équipe (lecture/écriture, etc.) ;
– assigner des tâches (« tickets ») pour gérer la liste des actions à faire et des bugs à résoudre (« track issues »)  ;
– proposer des améliorations/soumissions (« pull requests ») qui pourront être validées par l’administrateur d’un projet ;
– supprimer, développer et fusionner tout ou partie des fichiers.

Ce qui nous intéresse le plus est le système de « branches », hérité de Git. Chaque projet possède un « tronc » (« tree ») principal. Pour faire des modifications (résoudre un bug, ajouter une fonction, etc.), il est possible de créer une « branche », qui correspond à une copie du tronc ou d’une partie de celui-ci. Pendant ce temps, le « tronc » principal peut faire l’objet de modifications indépendantes [ Fig. 242 ]. Fig. 242 Tant qu’on travaille « en local » (sur sa machine), les modifications sont appelées « commit » (validations). Une fois qu’on est satisfait de la modification effectuée sur sa « branche », on peut proposer de la répercuter sur un serveur distant (« remote server »), type GitHub. On fait alors une demande de fusion (« push request ») . Si la modification est acceptée, la fusion (« merge ») est réalisée, et le « tronc » de départ est mis à jour. L’ensemble des contributeurs peut évidemment être notifié de ces différentes actions. Celui qui administre le tronc voit de son côté des demandes qu’il peut « tirer » (« pull requests ») pour les valider. L’ensemble des modifications (les « commit » répercutées sur le serveur distant) sont ensuite visibles de tous ceux ayant accès au projet. On peut aussi créer une copie complète du tronc qui donnera naissance à un projet indépendant de sa base. On parle dans ce cas de « fork » (fourche). Des programmes comme WordPress ont démarré ainsi.

La façon de faire du numérique que propose GitHub nous intéresse car elle ne se base pas sur l’imitation d’anciens procédés techniques, mais fait paraître des concepts propres aux matières numériques. Les « branches » des projets GitHub, et tout le panel d’actions associées, proposent au designer d’autres façons de faire que celles qui sont habituellement utilisées dans le champ des produits « physiques » [ Fig. 244 ]. Fig. 244 Plus encore, GitHub en lui-même peut être considéré comme un geste de design. En proposant une interface plus « accessible » que les clients Git décentralisés, GitHub permet à un public plus large de s’initier au développement collaboratif de programmes. Nous pensons que les designers « non numériques » auraient à apprendre de l’étude de programmes comme GitHub afin de prendre du recul sur leurs conduites de projet. Qu’en est-il, par exemple, de textes scientifiques rédigés sur GitHub ? D’objets physiques pouvant faire l’objet de mutations et de fusions ? De commentaires et de contributions que l’on pourrait soumettre à des concepteurs d’objets ? D’individus évalués sur les contributions plutôt que sur leur formation ? Il nous semble que se jouent ici des enjeux importants à propos d’une société qui ferait le choix de la contribution face aux incitations à la consommation. Ce mouvement est peut-être déjà engagé ; citons pour exemple :

– Le cv de Karl Dubost : Prenant le contre-pied des cv traditionnels uniquement rédigés par leurs auteurs, Karl Dubost propose aux lecteurs de soumettre des questions ou de corriger des imprécisions⁷⁵³.

– « Mission ‹ Acte II de l’exception culturelle ›. Contribution aux politiques culturelles à l’ère numérique » : Ce projet fait suite à la mise en ligne en mai 2013 d’un rapport commandé à Pierre Lescure par le Ministère de la Culture. Constatant que le format de fichier pdf ne permet pas de discuter les propositions exposées, Karl Dubost met en ligne les 80 propositions du rapport Pierre Lescure sous forme d’« issues⁷⁵⁴ » (problèmes) sur GitHub. Les fonctions de GitHub permettent, selon Karl Dubost, d’« offrir un espace possible de discussions catégorisées⁷⁵⁵ ».

– Dans le même esprit, les gouvernements anglais et américains publient des textes de lois « amendables » par les citoyens⁷⁵⁶.

– Les notes de préparation de la conférence « Esthétique et pratique du Web qui rouille⁷⁵⁷ » de Olivier Threaux et Karl Dubost pour la manifestation Paris Web 2013. Dans ce contexte, l’utilisation de GitHub permet d’initier des discussions avant et après l’événement, et de rendre accessibles les concepts présentés.

– Le fabriquant de robots sous-marins OpenRov met à disposition sur GitHub ses programmes, circuits imprimés et plans de montage⁷⁵⁸. Cela permet d’identifier tous les problèmes en cours, et de profiter des améliorations de tierces personnes.

Nous avons ici des exemples d’activation de GitHub qui dépassent le cadre de la conception de programmes numériques : aide à la connaissance de soi, levier politique [ Fig. 247 ], Fig. 247 discussions de concepts, accès à des sources documentaires, résolution de problèmes matériels, etc. En janvier 2013, GitHub comptait 30 millions de membres. En permettant un accès facilité à la gestion de projet Git⁷⁵⁹, GitHub s’est rapidement imposé comme le plus important système de développement de programmes. GitHub amène de la centralisation là où Git est décentralisé. Git ne possède pas de serveur central, toutes les modifications sont partagées. Si l’une des machines se déconnecte, les autres peuvent toujours travailler. On peut donc considérer GitHub comme une « surcouche » de Git, avec des fonctions supplémentaires comme la dimensions « sociale » (flux de modifications, pages de profils, messagerie, etc.). Son aspect centralisateur (sans que rien n’y soit enfermé) permet de comparer différents projets et joue comme une source de références chez les programmeurs, qui peuvent faire facilement mention de leurs principaux projets « hébergés » sur GitHub.

Si l’on résume GitHub, on peut donc dire qu’il s’agit d’un système favorisant le développement des programmes. Hérité en grande partie de Git, la majorité du vocabulaire utilisé sur le site web GitHub est d’ordre biologique, ce qui va de pair avec les notions de culture et de croissance que nous avons vues plus haut. GitHub, est davantage marqué par la pensée de l’open source que par celle des logiciels libres. L’accent est mis sur l’efficacité et l’entraide, la liberté est plus une conséquence qu’un point de départ. Tout est fait pour favoriser les discussions et contributions, avec l’idée forte qu’il est plus intéressant de commencer à construire des programmes « à plusieurs⁷⁶⁰ ». Comme le montrent les quelques exemples ci-dessus, il est plus question de collaborations que de programmes. N’importe quel projet est à terme susceptible de pouvoir être hébergé sur GitHub :

GitHub simplifie et accélère [la conception des programmes] parce que c’est une plateforme qui rend possible les collaborations et, plus encore, parce qu’elle encourage les gens à voir le monde d’une façon collaborative. C’est vraiment pour cette raison que GitHub est important au-delà des programmes : cette éthique et cette attitude sont transposables dans des domaines comme le droit, le design produit, l’usinage, la biologie, la danse, la musique, les livres, la cuisine⁷⁶¹…

Cette hégémonie créé bien sûr des problèmes. On peut considérer que GitHub « recentre » le Web, là où Git était intéressant de par son aspect décentré. On peut aussi considérer que de très nombreux projets n’auraient pas pu voir le jour sans cette « surcouche » simplificatrice, qui aurait ainsi avéré une puissance qui restait à découvrir. L’espace de discussion qu’ouvre GitHub permet de comprendre le fonctionnement des programmes, rejoignant en cela ce que formule Simondon dans sa critique radicale des objets clôturés. La logique modulaire des programmes avérée par GitHub laisse le champ libre à des connexions, groupements et jeux de montage⁷⁶². Mais on peut aussi redouter que « l’éthique et l’attitude » de GitHub deviennent des façons de faire « par défaut », inhibant d’autres méthodes et conduites. Si cette logique collaborative est indéniablement intéressante, qu’en sera t-il quand GitHub aura « dévoré⁷⁶³ » tout le spectre des programmes ? Derrière cette relative centralisation⁷⁶⁴ de la conception des codes sources se cache peut-être un risque de contrôle, du moins d’appauvrissement des façons de faire. Les « attitudes » développées par GitHub pourraient ainsi devenir des méthodologies réplicables sans prise de recul critique. On pourrait aussi dire que GitHub se situe entre les systèmes centralisés que sont Wikipedia et Facebook. Tandis que la recherche d’une efficacité et d’une utilité risque de rabattre GitHub sous l’angle de la pure recherche d’une rentabilité, il sera intéressant d’étudier si cette « culture technique » pourra (encore) œuvrer au développement de situations imprévues. Ce que pose GitHub comme question au designer est donc de savoir jusqu’où la poussée de logiques issues des « logiciels libres » ne provoque t-elle pas des effets inverses à l’éthique dont elle se réclame initialement. C’est, finalement, la même question qu’adressait Richard Stallman à Android.

Le fait que GitHub soit (à la base) un programme pour faire des programmes rejoint l’intention de Firefox OS de proposer une « plateforme ouverte » reposant sur les standards du Web. Comme nous l’avons vu, là où Firefox OS met l’accent sur la liberté de l’utilisateur et sur le contrôle de ses données, GitHub insiste davantage sur l’efficacité et l’utilité. Pourtant, c’est bien dans GitHub que l’on trouve des formulation de concepts plus spécifiques aux développement des matières numériques. GitHub n’a pas cherché à recouvrir les concepts spécifiques à Git d’un vocabulaire transposé du monde économisé du « Web 2.0 ». Il y a bien sûr une différence de public. Firefox OS vise à s’installer dans le « marché » déjà très saturé des terminaux mobiles, là où GitHub s’adresse avant tout à un public professionnel, familier de ces concepts. Est-il dit que, pour se faire comprendre, le design des programmes doive adhérer au vocabulaire dominant dicté par des raisons économiques ? Il n’est pas souhaitable que cela soit le cas. Un langage recouvert limite de fait les possibilités de développement activables en son sein. Mettre à jour les spécificités des matières numériques est une condition nécessaire d’un appareillage des programmes.

Au début de cette analyse, nous nous demandions si Firefox OS ou GitHub pouvaient être considérés comme des « appareillages de programmes », en tant qu’ils travaillent à partir de systèmes existants : Android pour Firefox OS, et Git pour GitHub. Ces deux objets techniques mettent en place des procédures de réglage et de contrôle des productions qui apportent une lecture facilitée de l’environnement technique. Les possibilités ouvertes par ces programmes de programmes sont intéressantes à étudier car elles indiquent des pistes de recherches contemporaines et prospectives : l’imitation d’un discours économique par des techniques allant dans des directions inverses (Firefox OS) et la centralisation efficace d’une technique décentralisée (GitHub).

Ces deux façons de faire du design, pleines d’ambiguïtés, sont davantage que des objets d’étude. Nous pensons qu’elles contribuent à modifier les pratiques du designer. La notion de modularité et les logiques d’ouverture et de fermeture sont (et seront) de plus en plus présentes au sein d’objets qui semblent, pour le moment, hétérogènes au champ des programmes. D’une part, il est presque impossible d’envisager une production de design sans recourir à un ou plusieurs logiciels, ce qui rend nécessaire une réflexion sur l’éthique de ces espaces intermédiaires. D’autre part, de plus en plus d’objets « contiennent » des programmes et sont amenés à se « connecter » à des réseaux, ce qui fait qu’une approche uniquement basée sur les matériaux sera insuffisante. Enfin, comme nous l’avons vu, les méthodes de production des programmes numériques peuvent inspirer, à rebours du « tout économique », des pratiques de design orientées autour de la notion de « développement ». Dès lors, deux voies possibles s’ouvrent au designer : ignorer ces mutations et se laisser conduire par elles, ou prendre part à ces développements et avérer ces poussées techniques dans des directions qui lui sembleront éthiquement soutenables.