Design, appareil, bidouillage

Le 9 mars 2015, Dave Burke, vice-président de l’ingénierie d’Android, le système d’exploitation installé sur la majorité des smartphones dans le monde, annonce sur le blog officiel du logiciel une nouvelle mise à jour portant le système d’exploitation à sa version 5.1. Cette mise à jour sera distribuée sur tous les appareils équipés de la version 5.0 du système d’exploitation de Google, version dénommée « Lollipop » — « Lemon Meringue Pie » avant sa première diffusion. La version 5.1 ajoute plusieurs fonctionnalités au système, dont la possibilité de gérer simultanément deux cartes SIM. Elle ajoute également un dispositif annoncé comme une protection des appareils concernés contre le vol : il ne sera désormais plus possible d’opérer un retour aux réglages d’usine, un « factory reset », sans au préalable se connecter au compte Google auquel était associé l’appareil avant l’opération. Autrement dit, si, lors de son utilisation, l’appareil a été associé une première fois à un compte Google, il n’y aura pas de possibilité de le réinitialiser sans passer par une connexion à ce compte. Le « factory reset » consiste en une procédure spécifique permettant de supprimer toutes les préférences et documents d’un utilisateur en vue de la réutilisation du téléphone : celui-ci revient à l’état dans lequel il était lors d’un premier achat, avec un système d’exploitation sans information relative à l’ancien utilisateur. Le « factory reset » nécessite donc une reconfiguration de l’appareil.

Le dispositif de blocage « Factory Reset Protection » ou « FRP », installé depuis la mise à jour 5.1 d’Android et toujours présent dans la version actuelle d’Android, la version 10 (qui ne porte plus de nom de friandise). Cette fonctionnalité, bien qu’elle consiste en un ajout au système d’exploitation d’un bout de logiciel supplémentaire implémenté au sein de celui-ci, a pour objectif d’empêcher une certaine utilisation de l’appareil, ce qui revient à retirer un usage possible : celui de le réinitialiser sans devoir, après réinitialisation, se reconnecter au compte Google préalablement associé. Donc, on le suppose, sans notifier Google de cette réinitialisation. Nous pourrions énumérer ici différentes circonstances dans lesquelles ce dispositif de protection contraint l’utilisateur·trice sans pour autant que celui·celle-ci puisse être suspecté·e d’avoir volé l’appareil. Nous noterons pour l’essentiel que le fait qu’un appareil puisse passer d’un·e utilisateur·trice à un·e autre au cours de son existence ne semble tout simplement pas concevable aux yeux de Google. Mais ce qui nous intéresse ici n’est pas tant d’émettre une critique du dispositif en soi et de la politique de « sécurité » de Google, que d’observer à travers cet exemple particulier les rapports de l’utilisateur·trice à son appareil et inversement. C’est à dire, ce qu’un tel dispositif peut produire sur le plan des usages et des relations.

Contourner

Concrètement, le FRP consiste en l’ajout d’un écran contenant un formulaire de connexion au compte Google au sein de l’assistant de configuration du téléphone. Cet assistant apparait lorsque l’appareil est allumé après avoir effectué un « factory reset ». Il comprend plusieurs étapes, dont le choix de la langue de l’interface d’Android, la connexion à un réseau wifi et la validation des conditions générales d’utilisation. Tant que l’utilisateur·trice ne se sera pas connecté·e au compte Google via le formulaire, il·elle ne pourra pas quitter l’assistant de configuration. Aucune application autre que cet assistant ne sera accessible, y compris l’application « Réglages » qui permettrait de désactiver la protection. Le téléphone devient « inutilisable » dans le sens où il ne permet de rien faire d’autre que de passer d’un écran de l’assistant de configuration à un autre. À la suite de l’implémentation du FRP, des dizaines de vidéos sont apparues sur la plateforme Youtube démontrant des méthodes de contournement du dispositif, pour la plupart fondées sur le même principe : accéder à l’application « Réglages » du téléphone en effectuant une série de manipulations à partir de l’assistant de configuration. Puisqu’il n’y a rien qui techniquement empêche l’application « Réglages » de s’ouvrir en dehors du fait qu’il n’y a pas de lien vers cette dernière accessible directement à partir de l’assistant de configuration, l’objectif est de trouver un chemin indirect, une suite d’opérations qui permettra de se déplacer dans différentes applications du téléphone jusqu’à accéder finalement à l’application « Réglages ». Cette méthode se retrouve, par exemple, sur la vidéo Youtube Bypass FRP Lock On Moto G3 (Google Account Lock) de l’utilisateur Vikas Chandwani, datée du 13 janvier 2016. La méthode proposée, de l’ouverture de l’assistant de configuration à l’accès à l’application « Réglages », peut s’écrire comme ci-dessous :

Accéder au panneau de configuration du réseau wifi de l’assistant de configuration / Cliquer sur « ajouter un autre réseau » / Cliquer sur « options du clavier » / Cliquer sur « choisir un clavier » / Activer « Saisie Google en Japonais » / Revenir à l’écran précédent / Cliquer à nouveau sur « options du clavier » / Cliquer sur « Saisie en Japonais » / Cliquer et maintenir la touche du clavier en bas à gauche / Cliquer sur « Option de saisie Google en Japonais » / Sélectionner « Google privacy policy » / Une page d’erreur apparait. Sélectionner le message d’erreur : « ERR_NAME_NOT_RESOLVED » / Cliquer sur « partager » / Sélectionner « Messages » / Composer le numéro « 190 » / Cliquer sur « envoyer » / Après que le message d’erreur « Impossible d’envoyer » soit apparu, cliquer sur l’icône d’appel téléphonique / Effacer le numéro 190 et le remplacer par *#*#4636#*#* / L’écran « Testing » apparait. Cliquer sur « Informations de batterie » / Cliquer sur le bouton « retour » en haut à gauche de l’écran / L’applications « Réglages » s’ouvre.

Si cette procédure en particulier a pu fonctionner au moment de sa publication, les versions plus récentes d’Android contiennent un dispositif FRP modifié pour l’empêcher. Mais, à chaque mise à jour du dispositif, une ou plusieurs nouvelles procédures similaires apparaissent sur Youtube. Elles sont toutes composées de différentes actions successives ; cliquer, maintenir pendant un temps déterminé, faire glisser un élément d’interface pour sélectionner, copier, coller, partager, etc. Toutes proposent à l’utilisateur·trice de suivre ces étapes précisément, dans un certain ordre, c’est-à-dire d’exécuter un algorithme, (composé de variables, conditions, itérations) dont les différentes opérations sont des actions de manipulation de l’interface. Pour pouvoir écrire cet algorithme, il a fallu qu’un·e utilisateur·trice adopte une méthode de recherche qui consiste à intervenir à différents moments dans l’exécution de l’algorithme de l’appareil à l’aide de ces actions de manipulation. À mesure que l’appareil a réagi à ces actions, il a dévoilé son propre algorithme permettant à l’utilisateur·trice, à son tour, de réagir en adaptant le sien. Si l’on devait retranscrire la procédure complète, il faudrait ajouter aux actions de l’utilisateur·trice les actions qu’exécute l’appareil. La partition se joue à deux voix et ces deux voix sont interdépendantes.

Android est un système « open source » et cela semble, à priori, étrange que pour pouvoir faire avec l’appareil « autre chose » que ce qui a été prévu initialement, l’utilisateur·trice s’engage dans un processus de recherche où il·elle essaie de modifier le cours normal des opérations de l’appareil en tentant d’effectuer des actions perturbatrices. Qu’il·elle intervienne dans les processus qui s’exécutent, au moment où ils s’exécutent plutôt qu’il·elle tente d’installer une version du système qui ne contient pas, par exemple, ce dispositif FRP. Pourtant, d’une part, les compétences techniques nécessaires à la compréhension des différentes couches technologiques qui composent un système d’exploitation peuvent constituer de sérieux obstacles à toute tentative de modification et, d’autre part, modifier le code source d’Android, ou télécharger une version qui ne contient pas le FRP, ne suffit pas : il faut encore pouvoir installer le système d’exploitation modifié sur l’appareil. Or, l’installation d’un système modifié, comprendre un système autre que celui qui était installé au moment de l’achat, n’est pas possible sans de nouveau avoir à contourner une protection implémentée dans le système, le « Verified Boot » qui bloquera toute tentative d’installation d’un système Android différent si une version officielle et distribuée par Google est déjà présente. On voit ici que l’argument « open source » ne garantit en rien la possibilité offerte à l’utilisateur·trice de modifier effectivement ce code et d’ensuite l’utiliser, du moins pas sans désactiver au préalable une série de protections. Par conséquent, pour installer un système d’exploitation « non officiel », ce terme pouvant concerner une version d’Android moins récente que celle installée sur l’appareil ou une version modifiée, il faudra, pour commencer, débloquer le « bootloader » du système d’exploitation (ce qui oblige l’utilisateur·trice à effectuer aussi un « factory reset ») et démarrer le télé­phone en mode « chargement » en effectuant les opérations suivantes :

Ouvrir l’application « Réglages » / cliquer sur « À propos du téléphone » / cliquer 7 fois sur le numéro de version du logiciel installé / Revenir à l’écran précédent / Cliquer sur « Options de développeur » / Activer « Déverrouillage OEM » / Activer « Débogage USB » / Redémarrer le téléphone / Avant le démarrage, maintenir les boutons « Power » et « Volume Down » / Le téléphone démarre en mode « chargement ».

Déjouer

Nous avons examiné deux procédures différentes auxquelles nous pouvons attacher deux objectifs distincts : contourner le FRP pour réinitialiser l’appareil pour la première, contourner la vérification du système de fichiers pour pouvoir installer un autre système d’exploitation pour la seconde. Nous pouvons aisément imaginer les limitations qui motivent ces objectifs : impossibilité d’avoir accès aux informations de connexion Google de l’ancien utilisateur·trice de l’appareil, d’une part, et impossibilité d’utiliser d’autres fonctionnalités que celles prévues dans le système par défaut, d’autre part. Supposons qu’une frustration provoquée par ces limites puisse jouer un rôle moteur dans l’engagement des utilisateur·trice·s à élaborer ces procédures. Cette frustration pourrait provenir du fait que les limites en question ne sont pas propres à l’appareil en tant que tel, mais sont le fait de décisions de design. L’appareil a bien des limitations techniques propres : il ne peut, par exemple, réaliser des photos plus grandes qu’une certaine résolution, il ne peut contenir plus d’une certaine quantité de données, il ne peut réaliser plus d’un certain nombre d’opérations dans un temps donné. Mais les limites dont il est question ici sont d’un autre ordre : elles sont implémentées à dessein, « by design », par un ajout logiciel, dans l’appareil, pour empêcher l’utilisateur·trice d’effectuer certaines opérations avec lui. Il s’agit de « design centré utilisateur·trice » dont l’objectif est d’influer son comportement en lui permettant de et en l’encourageant à réaliser certaines actions tout en réduisant les possibilités d’en réaliser d’autres (et si cela ne suffit pas, la menace de la rupture de la garantie de l’appareil ajoute une ultime barrière à leur réalisation). Il est important de noter que dans cette dynamique, le point de vue du design se retrouve déplacé de l’objet à l’utilisateur·trice et ce faisant c’est la relation de l’utilisateur·trice à l’objet qui se retrouve dérobée par le design.

Cependant, nous formulons l’hypothèse que c’est précisément la frustration produite par le design qui devient le moteur de la reconquête par l’utilisateur·trice de sa relation avec l’appareil. Ce qui relève d’une volonté de bloquer l’utilisateur·trice dans ses actions alimente/motive/provoque son implication dans la recherche de moyens pour pouvoir les réaliser malgré tout. Et, ce faisant, c’est toute une logique propre à l’appareil qui se révèle à ses yeux. Par la recherche de la solution pour détourner le FRP, l’utilisateur·trice comprend que l’assistant d’installation est une application comme une autre installée dans son téléphone et que, comme toute application, elle ne peut bloquer les autres applications de l’appareil. Tout ce qu’elle peut faire pour assurer au FRP son efficacité est d’empêcher l’utilisateur·trice d’accéder aux autres applications en interceptant certaines interactions de l’utilisateur·trice. Par exemple, en attachant à certains boutons ou liens qui, habituellement, permettraient à l’utilisateur·trice d’accéder au menu de l’appareil, la fonction de revenir au début de l’assistant de configuration. Par conséquent, les boutons de l’appareil produisent des actions qui sont définies par les différentes applications qui les utilisent et, donc, il est techniquement possible d’attacher à ces boutons d’autres fonctions qui seraient choisies par l’utilisateur·trice. Les perspectives utilitaires ouvertes par cette découverte risquent très probablement de prolonger la recherche de l’utilisateur·trice. Une fois une limite contournée, c’est tout un monde de limites à contourner qui se révèle à lui·elle. Mais cet exemple précis dévoile aussi, par la notion d’«interception » des actions de l’utilisateur·trice, un fonctionnement propre aux appareils numériques interactifs, une réalité technique particulière : l’interaction consistant à appuyer sur un bouton pour produire quelque chose n’est possible, pour l’appareil, que s’il y a au sein de celui-ci un processus tournant en boucle qui, à chaque tour, vérifie l’état du bouton. En fonction de l’état « appuyé » ou « relâché », ce processus lancera (ou ne lancera pas) tel ou tel autre processus. C’est ce qui permet d’attacher ou de détacher des fonctions aux boutons. Percevoir ceci, c’est comprendre que nous sommes, en tant qu’utilisateur·trice·s, face à des machines qui « tournent » et que nos interactions sont des interventions à l’intérieur de ce mouvement. Par nos interactions, par nos mouvements, ce sont les mouvements de nos appareils qui sont modifiés.

À la reconquête de la relation avec l’objet s’ajoute également ce qui ressemble à une inversion du processus de design. Là où le « design centré utilisateur·trice » a pour objectif d’influencer le comportement de l’utilisateur·trice via l’objet, l’utilisateur·trice, en s’engageant dans cette recherche, oblige, toujours via l’objet, le·la concepteur·rice à reconsidérer son design en fonction de ce que l’utilisateur·trice fait. Et il ne s’agit pas d’un dialogue bienveillant ; il s’agit plutôt d’une lutte continue entre, d’une part, le·la concepteur·rice cherchant à empêcher et, d’autre part ‚l’utilisateur·trice cherchant à faire. Cette lutte, on la retrouve, par exemple, dans le piratage de logiciels : à mesure que les éditeurs de logiciels élaborent des mesures pour empêcher leur piratage, en implémentant des verrous de différentes sortes (clés d’utilisation, abonnements en ligne, désactivation de fonctionnalités), les utilisateur·trice·s développent des stratégies de contournement (générateurs de clés, patchs qui suppriment des parties de logiciels ou qui empêchent la communication avec des serveurs en ligne, etc.). L’appareil est ici à la fois le médiateur et le centre de cette lutte, il est l’endroit où elle se joue. Nous pouvons identifier toute la portée politique que cela implique ; l’appareil n’est plus seulement un outil mais un lieu de confrontation entre différentes parties ayant des intérêts différents. Faire croire que ces intérêts coïncident, que, par exemple, un dispositif tel que le FRP est implémenté au sein de l’appareil dans l’intérêt des utilisateur·trice·s, ou, pour prendre un autre exemple, que les publicités ciblées basées sur du profilage sur les réseaux sociaux sont présentes pour ne montrer que ce qui est susceptible d’intéresser l’utilisateur·trice (et ne pas le·la déranger avec le reste) relève d’un discours marketing cherchant à masquer cette lutte. Or, l’identification de cette dernière permet l’émergence de réseaux d’échanges entre les utilisateur·trice·s. Des communautés sont créées, les utilisateur·trice·s s’échangent des informations, des recettes, des tentatives de détournement. C’est tout une dynamique d’échanges entre utilisateur·trice·s qui est produite et le centre de cette dynamique est, encore une fois, l’appareil.

Bidouiller

Nous voudrions proposer que toute tentative de « design centré utilisateur·trice » produit dans une certaine mesure et, peut-être, de manière marginale l’effet inverse de ce qu’elle vise. Chaque limite implémentée dans un artéfact technologique génère la nécessité de la contourner. Cette nécessité produit une dynamique entre l’appareil et l’utilisateur·trice qui le·la mène à modifier sa relation à l’objet, à opérer une inversion dans le processus de design et à produire des communautés d’utilisateur·trice·s réuni·e·s autour d’une lutte identifiée. À la conception de l’utilisateur·trice-client·e défendue par les grandes firmes technologiques, nous pouvons alors opposer la figure de l’utilisateur·trice-bidouilleur·euse, d’autant plus difficile à cerner par lesdites firmes que ses actions ne sont pas déterminées par des objectifs quantifiables. L’utilisateur·trice-bidouilleur·euse n’est pas un·e Maker ; il·elle ne cherche pas à produire quoi que ce soit. Il·elle cherche essentiellement à s’affranchir du cadre d’utilisation imposé. Le caractère absurde de sa démarche provient précisément de son manque d’objectif utilitaire. Mais ses actions ne sont pas aléatoires pour autant ; elles sont entièrement engagées dans une relation avec l’appareil. Sa position rentre en confrontation directe avec le slogan « users first » transmis telle une promesse par certaines grandes firmes technologiques, comme Google.

En se connectant au site web officiel d’Android à la date d’écriture de cet article, nous pouvons observer des éléments de langage tels que « The OS that gets to what’s important », « Go straight to the stuff that matters most » et « Android is optimized for how you use your phone ». La question de savoir précisément ce qui est important dans l’usage du système ne semble pas se poser du côté de l’utilisateur·trice puisque les équipes qui l’ont mis au point l’ont posée et y ont répondu. Autrement dit, si l’utilisateur·trice n’a pas saisi ce qui importe, Android l’a fait pour lui·elle. Android prétend répondre aux besoins de l’utilisateur·trice et ce faisant modélise son·sa propre utilisateur·trice, individu abstrait ayant des besoins et usages définis. Dans cette conception, l’utilisateur·trice lui-même est un produit de design et, pour que cela fonctionne, l’appareil doit devenir transparent ; il n’est qu’un moyen pour réaliser « ce qui importe ». En plaçant l’appareil au centre de ses préoccupations, l’utilisateur·trice-bidouilleur·euse invalide cette image, cet utilisateur selon Google.

Lionel Maes

Auteur

Article(s) de l'auteur