David Madore's WebLog: Pourquoi l'interface des smartphones est-elle à ce point plus merdique que celle des ordinateurs ?

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]

↓Entry #2802 [older| permalink|newer] / ↓Entrée #2802 [précédente| permalien|suivante] ↓

(samedi)

Pourquoi l'interface des smartphones est-elle à ce point plus merdique que celle des ordinateurs ?

Mon smartphone actuel (un Pixel 4a de Google, acheté en juillet 2021 suite à un brickage accidentel du OnePlus 6 que j'avais précédemment) est en train de mourir, c'est-à-dire que sa batterie s'est mise à gonfler, donc il va falloir[#] que j'en achète un nouveau. Autant dire que la perspective de passer des jours à sauvegarder les données de l'ancien téléphone et de reconfigurer le nouveau autant que je possible à l'identique de l'ancien ne m'enchante pas. Mais j'ai déjà écrit un billet (lors de la migration de mon téléphone N−2 à mon téléphone N−1) pour expliquer combien l'opération est pénible, je ne vais peut-être pas le refaire pour la migration de N à N+1 ni à chaque fois que je rachète un téléphone, même si ce n'est pas l'envie qui me démange, à chaque fois, de raconter mes malheurs.

[#] On me fait remarquer que je peux sans doute trouver un réparateur prêt à changer la batterie. Je vais sans doute faire ça ne serait-ce que pour avoir un téléphone de secours, mais d'une part le gonflement de la batterie a endommagé la coque arrière, ce qui n'est sans doute pas très bon pour la solidité de l'appareil, d'autre part je suppose que le risque que le « réparateur » casse tout en essayant de changer une batterie pas prévue pour être changée est assez élevé, donc de toute façon il faut au minimum que je m'occupe de faire une sauvegarde complète[#1b] du téléphone.

[#1b] Je fais de toute façon des sauvegardes hebdomadaires des choses que je peux facilement sauvegarder (comme /data/data/com.android.providers.telephony/databases/mmssms.db). Mais une sauvegarde beaucoup plus complète, c'est vraiment très fastidieux.

Pour résumer quand même rapidement ce billet passé : Android[#2] ne fournit aucun système sérieux de sauvegarde des données du téléphone, ni aucun moyen de les extraire. La réponse de Google à ce problème, c'est en gros sauvegardez tout chez nous dans le cloud (ils proposent un truc qui fait ça, et c'est probablement ce qu'utilise la majorité des utilisateurs), mais c'est inacceptable à mes yeux, ne serait-ce que sur le principe parce que je n'ai pas l'autorisation de mes amis pour envoyer leurs coordonnées à Google, et même comme ça, ça semble marcher assez mal et ne concerner qu'une petite partie de ce que j'ai envie de sauvegarder d'un téléphone à l'autre. La manière dont je m'y prends, moi, c'est d'aller chercher application par application la base de données interne dans laquelle elle stocke son état, la recopier sur le nouveau téléphone, et prier pour que ça marche, et sinon, essayer de bidouiller comme je peux pour réparer le problème. Tout ça est immensément fastidieux, et je suis abasourdi qu'après 15 ans d'existence d'Android on en soit toujours à ce point lamentable[#3][#4].

[#2] Avertissement important pour les fanboys d'Apple : Je passe ce billet à me plaindre d'Android, parce que parmi les deux OS de smartphones qui dominent complètement le marché, c'est le seul que je connaisse un peu sérieusement. Mais il faut que je précise clairement que le mal que je dis d'Android ne doit pas être compris comme impliquant que j'aime bien iOS ou les iPhones ou l'écosystème d'Apple : je suis obligé de dire ça parce qu'à chaque fois que je parle d'Android il y a des pénibles qui viennent la ramener en parlant d'Apple. Peut-être qu'iOS permet plus facilement qu'Android d'extraire et sauvegarder les données d'une application du téléphone, de les modifier dans le dos de l'application, ou ce genre de choses, je n'en sais rien. Je crois comprendre que, pour les backups précisément, iOS est en effet infiniment meilleur qu'Android. Mais je crois aussi comprendre que l'iPhone ne permet même pas de faire tourner les applications qu'on veut dessus (qu'on aurait écrit soi-même, je veux dire) sans l'accord d'Apple, et qu'il a même fallu que la commission européenne tape du poing sur la table pour que les utilisateurs obtiennent ne serait-ce que le droit de faire tourner un autre navigateur Web que celui prévu par Apple. Et je suis par ailleurs sûr d'une chose, c'est qu'iOS ne peut pas être installé sur un téléphone autre que ceux d'Apple : donc même si iOS est peut-être moins pénible qu'Apple sur certains aspects précis dont je parle dans ce billet, il est beaucoup verrouillé plus sur d'autres aspects qui me paraissent encore plus importants (et dont je ne parle pas précisément parce que je n'ai pas de problème avec). Proposer d'aller voir chez iOS parce que j'ai un problème avec Android, c'est comme me proposer d'aller vivre à Dubaï quand je me plains de la France : c'est lunaire.

[#3] Bon, il semble que Lineage OS (la version communautaire d'Android que j'utilise) propose un truc appelé Seedvault qui est censé permettre une sorte de backup du téléphone sans faire appel au cloud de Google. Je n'ai aucune idée de ce qu'elle vaut. Je vais peut-être essayer (voir par exemple ce commentaire Reddit). Mais je n'en attends pas des miracles.

[#4] Un point me laisse quand même profondément perplexe : les geeks sont peut-être dans la minorité, mais je ne suis quand même pas le seul à utiliser un téléphone Android, à être relativement compétent techniquement ou amateur de bidouille, à ne pas vouloir envoyer toutes mes données chez Google les yeux fermés (quand bien même ça marcherait parfaitement), et à quand même avoir besoin de changer de téléphone de temps en temps. (La simple existence de versions alternatives d'Android comme Lineage OS le prouve.) Alors que font les autres ? Et pourquoi est-ce que je n'arrive à trouver aucune information à ce sujet ? Les quelques copains geeks que j'ai essayé de presser sur la question ont hoché les épaules de façon évasive, ont botté en touche, ou ont carrément refusé de répondre (j'ai un ami qui m'a carrément dit qu'il considérait tout ça comme si traumatisant qu'il refusait d'en parler). Je m'étais déjà plaint lors de la migration de mon téléphone N−3 au N−2 de combien Android est hostile à la bidouille, mais ça ne cesse de m'étonner à quel point l'environnement qui l'entoure est toxique.

Mais je voudrais évoquer ici quelque chose d'un peu plus général : la manière dont les smartphones ont réussi à prendre quelque chose de pas très satisfaisant pour commencer, à savoir les systèmes d'exploitation et interfaces utilisateurs des ordinateurs, et à le transformer en quelque chose de bien pire, en cassant beaucoup d'abstractions qui fonctionnaient assez bien (la notion de fichier, la portabilité d'une machine à l'autre, le multitâche, etc.).

Conceptuellement, il n'y a rien qui distingue un smartphone et un ordinateur doté de périphériques comme un modem 5G et un appareil photo. Pour le grand public ce sont peut-être des catégories différentes (je ne sais pas vraiment comment les choses se catégorisent dans l'esprit de Madame Michu), et les revendeurs d'appareils essaient plus ou moins d'entretenir cette différence, mais fondamentalement il n'y en a pas, et bien sûr les smartphones actuels sont aussi puissants que les ordinateurs personnels d'il y a quelques années. Il n'y a aucune raison pour qu'on ne puisse pas poser son smartphone sur une station d'accueil pour lui brancher une alimentation, un clavier, une souris, un grand écran et éventuellement un disque dur, et s'en servir ainsi comme d'un ordinateur. Même le cœur du système d'exploitation Android, le noyau Linux, est une version à peine modifiée du même Linux qui sert dans beaucoup d'ordinateurs (il est vrai plutôt des serveurs). En outre, de toute façon, on s'en sert pour faire en gros la même chose : à savoir, faire tourner un navigateur Web.

Pourtant, les concepteurs de smartphone et de systèmes d'exploitation pour ceux-ci ont réussi à imposer une façon complètement différente d'interagir avec l'appareil, et je ne parle pas que de l'interface graphique mais aussi de la notion d'apps (et d'app store), de l'intégration logiciel-matériel, de l'intégration apps-données, etc., qui font que le smartphone se présente comme relevant d'une catégorie ontologiquement différente de l'ordinateur.

☞ Retour sur l'interface homme-machine des ordinateurs

Commençons par passer un peu en revue les éléments l'interface utilisée par l'ordinateur tel qu'il est utilisé par le grand public, dans essentiellement toutes ses saveurs (Windows, Mac ou différentes interfaces graphiques de Linux). Dans tous les cas il s'agit d'un système d'organisation qui hérite des anciens systèmes d'exploitation (des années ~1970) tels que Unix ou VMS qui fonctionnaient avant tout en ligne de commande (on tapait des commandes dans un terminal, voire dans un télétype, et on obtenait des réponses sous cette forme) : ce n'est que progressivement que les programmes interactifs, visuels puis graphiques, sont apparus, et cette filiation se sent encore. C'est notamment ces systèmes d'exploitation qui ont introduit le concept d'arborescence de fichiers qui reste encore valable.

Les données, donc, sont organisées autour de la notion centrale de fichier : le fichier est une abstraction pour une unité de données ayant un nom et un emplacement, et plus ou moins un type[#5] (tel que document texte, document PDF, image JPEG, etc.), il a un « utilisateur propriétaire » mais il n'a pas vraiment d'« application propriétaire ». Les fichiers sont organisés en arborescence de répertoires, une notion qui remonte essentiellement à Unix, et qui sert à la fois à l'organisation interne du système et à la présentation à l'utilisateur : l'arborescence de fichiers est donc essentiellement la même au niveau de l'interface ligne de commande que de l'interface graphique. Pour ne pas embrouiller l'utilisateur techniquement peu compétent, on ne lui présente simplement qu'un petit bout de l'arborescence, à savoir celle qui le concerne (son répertoire personnel, ou home dans la terminologie Unix), et on la présente sous forme graphique en montrant chaque fichier par une icône correspondant à son type, avec son nom en-dessous, et chaque répertoire, ou dossier comme une fenêtre qui peut s'ouvrir sur le bureau et qui montre les fichiers qu'il contient. Je simplifie un peu, mais c'est l'idée. Qui ne semble pas marcher si mal que ça.

[#5] Unix n'avait pas de notion de type de fichier, et il n'en a toujours pas vraiment : un fichier est juste une succession quelconque d'octets, et le système ne se soucie pas de ce qu'il représente. Pour la commodité des utilisateurs, la convention est née d'indiquer le type par une extension au nom du fichier (par exemple .txt pour un fichier texte brut ou .pdf pour un document PDF). Une notion de type un peu plus structurée a été introduite ultérieurement dans le cadre de l'infrastructure mail avec le type MIME, et les interfaces graphiques sur ordinateur tendent, de façon certes un peu aléatoire et incohérente, à attacher un type MIME à chaque fichier. Mais ce n'est pas vraiment imposé par le système.

Ça c'est pour l'organisation des données. Le code, c'est-à-dire les programmes, est présenté de façon un peu plus variée (les applications peuvent être montrées comme les fichiers d'un dossier applications, ou dans un rangement spécial), mais l'idée est toujours la même : chaque application permet d'accéder à l'ensemble des données stockées sur la machine sous forme de fichiers, et même s'il peut y avoir une association privilégiée (tel fichier s'ouvrira par défaut avec telle application), il n'y a pas vraiment de concept d'application propriétaire d'un fichier : si des données sont visibles avec une application, elles doivent l'être aussi avec une autre.

De même que les fichiers n'ont pas d'application propriétaire[#6], ils n'ont pas non plus d'ordinateur propriétaire : on peut les copier sur un stockage externe (comme une clé USB ou un disque externe), et ainsi les envoyer sur un autre ordinateur où ils pourront servir. On peut, bien sûr, les échanger par toutes sortes de protocoles Internet (par exemple en pièce jointe d'un mail).

[#6] En revanche ils peuvent avoir un utilisateur propriétaire, mais je n'en parle pas trop parce que l'usage des ordinateurs est de plus en plus personnel donc mono-utilisateur. À vrai dire, je ne sais pas si on sait encore faire un système d'exploitation véritablement multi-utilisateur, de nos jours (le fait que les serveurs utilisent tellement la « virtualisation » prouve que la séparation entre utilisateurs des OS qu'on fait tourner sur ces machines virtuelles est inadaptée — soit insuffisante soit au contraire trop rigide : une séparation bien faite permettrait, au niveau de l'OS de faire tout ce que la virtualisation permet). Mais ceci est une digression par rapport à mon sujet.

Au niveau interface graphique, chaque application se présente comme une fenêtre sur le bureau (qu'on va pouvoir mettre en plein écran si on veut se concentrer dessus). Il est vrai qu'il n'est pas toujours très clair si on peut lancer plusieurs instances d'une même application : alors que dans la ligne de commande Unix c'est une évidence qu'on peut normalement lancer plusieurs fois le même programme, dans une interface graphique ce n'est pas toujours évident, certains programmes vont simplement vous renvoyer vers l'instance déjà lancée ; mais au moins, si c'est le cas, ils vont vous permettre d'ouvrir plusieurs fenêtres du même programme, par exemple dans un traitement de texte pour éditer plusieurs documents, et cela apparaît donc visuellement comme si on avait lancé deux instances du même programme.

Les applications ont besoin de stocker des données d'état persistant : ceci correspond à une convention, apparue progressivement avec les interfaces graphiques, et dont on peut d'ailleurs contester le mérite, qui est que quand l'utilisateur change un paramètre dans une application (du genre, le format de papier, la langue par défaut, la police de caractère, que sais-je), quitte cette application et la relance, le réglage est dans l'état où il a été laissé en quittant l'application (plutôt que de redémarrer l'application à chaque fois dans un état vierge, ou de ne sauvegarder l'état des préférences que si l'utilisateur a choisi explicitement de le faire). La manière dont ces données d'état persistant sont stockées est plus épineuse parce que c'est une invention postérieure, et tous les systèmes d'exploitation ne se sont pas mis d'accord sur les mécanismes pour ça, ni toutes les applications sur la manière dont elles utiliseraient ces mécanismes. Un mécanisme possible pour stocker l'état des applications est celui du fichier de configuration : l'application va lire un fichier spécial lors de son démarrage, qui lui dit quoi appliquer comme réglages par défaut, et elle peut sauvegarder ce fichier lorsqu'elle quitte avec les changements faits par l'utilisateur. Le cas du système de configuration « mixte », c'est-à-dire qui peut être modifié manuellement par l'utilisateur (avec un éditeur de texte) ou automatiquement par l'application (lorsque l'utilisateur change un réglage) est un compromis peut-être un peu bâtard, et plus compliqué à gérer, entre ces deux possibilités, et on tend de plus en plus à utiliser des fichiers de configuration plus ou moins cachés, que l'utilisateur n'est pas censé éditer directement (si vous voulez changer les réglages, passez par l'application !), parce que c'est plus facile pour le novice ; certains fichiers de configuration sont même opaques, c'est-à-dire que leur format n'est pas documenté par l'application ; et certains systèmes d'exploitation fournissent d'autres mécanismes que le fichier pour stocker ce genre de préférences (comme des clés de paramétrages, ou bases de registre, ou ce genre de choses, qui vivent dans leur propre arborescence, distincte des fichiers). Bien entendu, les données d'état d'une application sont censées être la propriété de l'application qui les a créée.

La raison pour laquelle je raconte tout ça, c'est que les smartphones ont en gros pris ce modèle d'état persistant par application, et l'ont poussé à fond, au détriment du modèle de l'arborescence de fichiers.

☞ Disparition de la notion de fichier sur mobile

Il y a bien une notion d'arborescence de fichiers sous Android (puisque, sous le capot, c'est en fait un Linux, donc un Unix), mais elle est ⓐ presque complètement cachée à l'utilisateur (lequel n'a aucune idée, par exemple, que ses SMS sont stockés dans /data/data/com.android.providers.telephony/databases/mmssms.db et ne verra jamais ce nom de fichier apparaître nulle part), et ⓑ même pas vraiment familière aux utilisateurs d'Unix (par exemple il n'y a pas le /usr dont on a l'habitude). Cette arborescence de fichiers Android est un détail d'implémentation presque secret.

L'utilisateur d'un smartphone n'a pas face à lui des fichiers mais des applications, et ça change tout.

Autrement dit, dans le modèle d'interface des smartphones, au lieu d'avoir un espace commun, l'arborescence de fichiers, dans lequel on peut faire tourner différents programmes, on a plein de petits mondes cloisonnés, les applications (et même si les mots programme et application sont dans une large mesure interchangeable, le fait d'utiliser plutôt le second dans le cas des smartphones suggère une façon différente de les penser[#7]). Chaque application a son petit monde de données (les sauvegardes d'un jeu, les contacts du téléphone, les notes d'une application bloc-notes, les cartes d'une application de cartographie), mais par défaut ils sont hermétiquement séparés. Autrement dit, le monde des smartphones a pris la notion de données d'état d'une application qui existait dans le monde des ordinateurs et l'a poussé à son extrême : ce ne sont plus juste des réglages qui sont stockés de façon « interne » à l'application, c'est en gros l'ensemble de ses données.

[#7] Déjà, un aspect que je déteste avec les smartphones est que dès que vous avez un problème, même quand il s'agit de quelque chose d'extrêmement basique qui devrait faire partie des fonctions intégrées du système, on vous propose de résoudre ce problème en installant encore une app de plus, comme si c'était normal. Ceci donne naissance à un écosystème toxique où non seulement les apps sont essentiellement toutes propriétaires (et soit payantes soit infestées de pubs), mais nombre d'entre elles sont carrément malicieuses : en exploitant les lacunes du système d'exploitation à son niveau le plus basique, elles convainquent les utilisateurs de les installer pour remédier à ces lacunes, et en profitent pour lui soutirer des choses (le faire payer, lui faire regarder des pubs, lui voler ses données, ou carrément prendre le contrôle du téléphone). Il faudrait peut-être se demander pourquoi il y a tellement d'apps malicieuses sous Android et tellement peu sous Linux-sur-PC.

Du point de vue technique, sous Android, il s'agit de fichiers (souvent des bases de données SQLite) non seulement cachés à la vue de l'utilisateur mais auxquels il lui est même absolument interdit d'accéder : comme je l'ai dit plus haut, vos SMS sont stockés, si vous avez un Android, dans le fichier /data/data/com.android.providers.telephony/databases/mmssms.db — mais à moins que vous ayez « rooté » votre téléphone, vous ne pouvez pas lire ce fichier autrement qu'à travers une application Android dédiée (et encore, ce n'est pas le meilleur exemple, parce que là c'est quand même un type de données qui est prévu pour être partagé entre plusieurs applications). Vous n'avez pas accès aux données brutes. C'est considéré comme quelque chose d'interne et de privé.

Je trouve complètement hallucinant qu'on interdise au propriétaire du téléphone d'accéder à certaines données sur son propre appareil. (Non seulement je trouve ça hallucinant mais je trouve que ça devrait être légalement interdit : dès lors que vous avez acheté un appareil, aucune partie de cet appareil ne devrait vous être inaccessible ; je veux bien qu'on invalide la garantie si vous y touchez, mais on ne doit pas faire plus.)

Bon, il faut bien qu'il y ait des données qui puissent être partagées par plusieurs applications, ou exportées ailleurs que sur le téléphone : les gens qui prennent des photos avec leur smartphone veulent quand même pouvoir les recopier sur leur téléphone. Ceci nous sauve un peu. Donc il y a un bout de l'arborescence de fichiers d'Android (en gros[#8] le répertoire /sdcard — ainsi nommé parce qu'au début il était stocké sur une carte micro-SD avant que les fabricants de smartphone ne décident, sous un prétexte d'étanchéité à l'eau, que c'était mieux de nous empêcher de sortir quoi que ce soit du téléphone) qui se comporte un peu plus comme une arborescence de fichiers d'ordinateurs. Il y a là-dedans des (sous-)répertoires comme Pictures pour les photos ou Music pour la musique ou encore Download pour les fichiers qu'on a pu télécharger avec un navigateur. En gros n'importe quelle app a le droit de lire ou d'écrire là-dedans (enfin, ce n'est pas vrai non plus, il y a des permissions pour ça aussi, mais au moins l'utilisateur va pouvoir choisir de les donner, et il va lui-même pouvoir fouiller là-dedans) ; il y a des applications qui permettent d'examiner le contenu de ce bout-là du système de fichiers.

[#8] Enfin, comme d'habitude avec Android, tout est un labyrinthe de choses qui ont été dépréciées et remplacées par d'autres choses, elles-même remplacées par une autre, et ainsi de suite, parce qu'ils n'arrêtent pas de changer tout le temps d'avis sur tout et d'inventer de nouvelles façons de compliquer les choses. Sur mon Pixel 4a, /sdcard est un lien symbolique vers /storage/self/primary qui est lui-même un lien symbolique vers /storage/emulated/0 qui est un point de montage FUSE sauf les sous-répertoires /storage/emulated/0/Android/data et /storage/emulated/0/Android/obb qui sont des points de montage sdcardfs (un truc apparemment déjà déprécié) de /data/media — je n'ai aucune idée de ce à quoi tout ceci est censé servir, mais c'est visiblement massivement over-engineered.

Et même ce bout-là qui existe vraiment sous forme de fichiers accessibles à l'utilisateur, des efforts sont encore faits pour cacher l'arborescence à l'utilisateur. Lorsque l'utilisateur ouvre une application de galerie pour voir les photos disponibles sur l'appareil (ou est amené à choisir une photo dans une autre application, par exemple comme pièce jointe à un tweet), au lieu que les photos soient présentées à travers leur arborescence de fichiers (dans /sdcard) elles sont présentées chronologiquement. Et même s'il y a des apps qui permettent de voir l'arborescence, Android par défaut ne la présente pas, ne la montre pas, n'offre aucune vue dessus à l'utilisateur.

L'interface graphique n'est pas centrée autour de la notion de fichier (comme sur les ordinateurs) mais d'applications.

Ce sont des applications qui apparaissent sous forme graphique sur votre écran de smartphone, pas des fichiers.

Cette disparition de la notion de fichier au profit des applications n'est pas là que pour une raison d'interface (pour la commodité de Madame Michu dont on aime s'imaginer qu'elle est bête donc qu'elle aurait peut-être du mal à comprendre la notion de fichier), c'est aussi pour une question de contrôle des données. L'époque est révolue où les gens écoutaient de la musique en écoutant des fichiers MP3 stockés sur leur appareil : maintenant ils ont un abonnement à Spotify ou je ne sais quoi, ils font tourner une app sur leur smartphone, et les fichiers téléchargés par cette app ne leur sont jamais visibles (enfin, je suppose, je n'utilise pas de telle app), et l'app ne veut pas qu'ils le soient car ça permettrait de les copier ailleurs. (Bon, il y a peut-être aussi des DRM pour éviter ça, même si je pense que ça c'est plutôt pour la vidéo que pour la musique.)

De même, les apps ne veulent pas non plus que les utilisateurs puissent modifier leurs données parce que ça permettrait parfois d'avoir accès à des choses auxquelles vous ne devriez pas (selon elles) avoir accès : j'en ai vu plus d'une qui désactive les pubs si on change la certaine valeur d'une certaine clé dans la base de données de l'app (je suppose que c'est plus simple que de compiler deux versions différentes de l'app), donc on veut vous empêcher de pouvoir faire ça.

Pour résumer, le smartphone part du principe (voulu et assumé par Google et compagnie, même si ce n'est jamais complètement explicité) que ce n'est pas l'utilisateur qui est le maître et propriétaire des données sur son propre appareil (qui est pourtant censé lui appartenir), ce sont les apps qu'il a installées qui le sont, et le modèle de données où la notion de fichier est quasi-invisibilisée au profit de « données d'applications » reflète ce fait.

☞ Conséquence : les sauvegardes sont compliquées

Mais une autre conséquence, c'est que ça rend la réalisation d'une sauvegarde complète du téléphone quasi impossible.

Dans le modèle « système de fichiers » de l'ordinateur, sauvegarder toutes les données est facile, il suffit de sauvegarder tous les fichiers. Bon, ça ne marche pas toujours parfaitement, mais globalement ça fait l'affaire. Ça marche parce qu'il y a des outils capables de traiter un fichier quelconque (pour le copier, le déplacer, le sauvegarder, ce genre de choses) sans avoir à savoir ce qu'il y a dedans. Cette idée était d'ailleurs une des grandes clés du succès d'Unix.

Dans le modèle smartphone, on ne peut pas simplement vous laisser faire ça. Comme je l'ai dit, l'utilisateur n'a pas accès aux fichiers qui contiennent les données d'application. Même s'il y a accès (parce qu'il a « rooté » son téléphone), ce n'est tout simplement pas prévu qu'on les recopie bêtement d'un téléphone à l'autre (ils peuvent dépendre, par exemple, de la version d'Android ou de la version de l'app, ou de toutes sortes d'autres choses), donc parfois ça marche, parfois non. Et de toute façon, à un certain niveau, on ne veut pas que l'utilisateur puisse sauvegarder ses données, parce que ça lui permettrait de regarder dedans[#9], y compris les données d'applications qui ne veulent pas que vous puissiez faire ça (par exemple les musiques téléchargées). Tout est fait, en quelque sorte, pour que vous n'ayez pas de contrôle sur ce qui est censé vous appartenir.

[#9] Beaucoup de téléphones Android utilisent un outil système appelé fastboot qui permet, depuis un ordinateur (Linux, Windows ou Mac) de communiquer avec le bootloader du téléphone et de réinstaller ou modifier les données sur diverses partitions de la mémoire flash. Bizarrement (non), cet outil ne permet que d'écrire les partitions, pas de les lire, ce qui serait quand même bien pratique pour faire une sauvegarde complète et à bas niveau de l'état du téléphone qu'on pourrait toujours restaurer ultérieurement, au moins sur le même téléphone. La raison pour laquelle ce n'est pas autorisé est sans doute celle que je viens de dire : ça donnerait accès en lecture à des choses qu'on ne veut pas laisser le propriétaire du téléphone lire.

Android a donc réussi, et c'est quand même un exploit, de casser quelque chose d'aussi basique que la notion de copie de sauvegarde (backup), un truc qui existe en informatique depuis plus de 60 ans, et qui ne pose aucun problème théorique ni conceptuel !

Google camoufle le choix d'empêcher le propriétaire du téléphone de faire ce qu'il veut avec sous le prétexte de protéger l'intégrité des données. Je ne sais pas ce qu'ils pensent mettre derrière ce mot intégrité, mais ça veut dire, en gros : on considère que ce qui est à vous n'est pas à vous. Par exemple, la première chose qu'on doit faire pour installer une version communautaire d'Android (dans mon cas, Lineage OS) sur un téléphone Pixel de Google, c'est déverrouiller le bootloader (c'est-à-dire lui demander le droit d'installer des versions d'Android qui ne soient pas cryptographiquement signées par Google). Bon, au moins c'est possible : je suppose qu'un téléphone qui serait fait par Apple ou Microsoft serait du genre à interdire purement et simplement ce genre de choses ; mais la première chose que fait le bootloader quand on lui demande de se déverrouiller, c'est d'effacer toutes les données du téléphone ; et ensuite, à chaque démarrage, il affiche un avertissement ce téléphone est déverrouillé, l'intégrité des données ne peut pas être assurée[#10]. Très bien, mais si je décide a posteriori d'installer un Android communautaire, il n'y a aucune raison que ça m'oblige à effacer toutes mes données (qui, je dois le rappeler une fois de plus, sont censées m'appartenir à moi) : c'est scandaleux que Google rende cette phase obligatoire.

[#10] Et la conséquence pratique est que certaines applications vont refuser de s'installer. Là aussi, je pense que cela devrait être illégal de la part d'une banque de décréter que ses clients n'ont pas le droit d'installer la version d'Android qu'ils veulent sur leur téléphone lorsqu'ils utilisent l'application mobile de cette banque. Idem pour un service de streaming comme Netflix.

☞ Absence de portabilité d'un smartphone à l'autre

Mais ce n'est pas tout ce que le modèle smartphone a cassé. Ils ont aussi trouvé le moyen de casser l'indépendance entre logiciel et matériel.

Quand j'installe un système d'exploitation sur un ordinateur, que ce soit une variante de Linux ou de Windows, j'installe le même système d'exploitation, et il s'accommode du matériel qu'il trouve. Il y a éventuellement des pilotes matériels spécifiques à installer, mais il n'empêche que, pour installer Linux Ubuntu, disons, sur un PC, je mets une clé USB avec Ubuntu dans l'appareil, je lui dis de démarrer sur cette clé, Ubuntu fait le nécessaire, me pose quelques questions, et ensuite je peux démarrer dessus. C'est simple et ça marche. Et ça marche indépendamment du matériel (je ne prétends pas que tout fonctionne parfaitement, mais enfin, quand ça fonctionne, il n'y a rien de plus à faire : il n'y a pas à télécharger une version spécifique d'Ubuntu pour tel ou tel type de matériel).

Apple, visiblement, ne sait pas faire ça : Apple ne sait faire de système d'exploitation que pour du matériel Apple, que ce soit pour les ordinateurs ou pour les smartphones. (Ça devrait d'ailleurs être illégal parce que c'est une forme de distortion de concurrence, mais passons, ce n'est pas mon problème ici.)

Mais Android ? Android tourne effectivement sur plein de téléphones différents, sauf que… il y a une version différente d'Android pour chaque smartphone !

Je ne veux pas juste dire que chaque fabricant de smartphone modifie un peu Android à sa sauce (cf. ci-dessous). Mais même pour une version communautaire d'Android comme Lineage OS, il faut choisir soigneusement la version pour le téléphone qu'on a, il n'y a pas une clé USB d'installation commune pour tous les smartphones susceptibles de recevoir un Android.

C'est hallucinant. Je ne sais pas comment on peut arriver à un tel niveau d'incompétence. Il n'y a aucune justification technique légitime[#11] à ce que ça ne se passe pas exactement comme sur un ordinateur : pour installer une nouvelle version d'Android, la mettre sur une clé USB, connecter cette clé USB au téléphone, activer un petit bouton caché pour dire au téléphone de démarrer sur cette clé USB, et elle installerait ce qui est adapté pour ce téléphone ; en outre, ça éliminerait tout risque de bricker le téléphone, puisque celui-ci démarrerait sur la clé USB.

[#11] Bon, une partie de la justification n'est pas vraiment de la faute de Google ni d'Android : c'est que l'architecture ARM est incroyablement pourrie et ne sait pas faire de détection du matériel. Mais bon, il n'y a aucune raison de ne pas juste mettre la description du matériel dans une petite partition matériellement non flashable que le logiciel pourrait simplement lire pour connaître la configuration. Au lieu de ça, Android utilise un nombre faramineux de partitions flash signées par des mécanismes douteux, dont plein de partitions de firmware et de pilotes, et malgré ça, ils ne sont pas capables d'avoir une seule version de la partition système qui marche uniformément sur tous les téléphones. C'est phénoménal.

Mais là aussi, l'explication technique est une sorte de façade pour un enjeu plus politique : chaque fabricant de smartphone Android produit un Android à sa sauce, avec ses particularités et ses fonctionnalités additionnelles. Et il fait passer ces fonctionnalités additionnelles pour des fonctionnalités du téléphone.

Autrement dit, on compte sur le fait que Madame Michu ne comprendra pas la différence entre une fonctionnalité du Noksung Nebula 42 (comme la taille de son écran ou la qualité de l'optique de son appareil photo) et une fonctionnalité de la version d'Android installée sur le Noksung Nebula 42 (comme un programme qui retouche automatiquement les photos après). Ce qui évite qu'elle puisse se demander, par exemple, pourquoi on ne l'autorise pas à installer cette version d'Android sur un téléphone qui n'est pas celui-là.

Là aussi, je trouve que c'est une distortion de concurrence, et que cela devrait être illégal : qu'on vende des téléphones est une chose, qu'on vende des versions d'Android en est une autre, mais qu'on lie obligatoirement les deux est… de la vente liée, justement. Mais passons. Moi, en tout cas, je ne suis pas très content d'acheter, disons, un téléphone choisi pour son matériel et d'être obligé de payer pour toutes sortes de gimmicks logiciels que je vais m'empresser de virer pour mettre Lineage OS à la place : c'est exactement comme quand on oblige les gens à payer un Windows préinstallé sur leur PC alors qu'il vont le virer immédiatement pour installer Linux à la place.

☞ Le multitâche est aussi cassé

Encore une autre chose que les smartphones ont cassé, c'est le multitâche. Bon, là, ce n'est pas entièrement leur faute parce que comme je l'ai signalé plus haut les interface graphiques sur ordinateur avaient déjà commencé le travail, et aussi parce les contraintes (taille de l'écran, taille de la mémoire) peuvent l'imposer, au moins sur les petits smartphones. Toujours est-il que, sous Android, on ne peut pas lancer deux copies de la même application (imaginez par exemple que je sois en train de naviguer avec Google Maps et que je veux regarder un endroit différent sur Google Street View ; ou que je sois en train de rédiger un tweet et que je veux en regarder un autre ; bon, dans ces cas on peut plus ou moins s'en sortir avec le navigateur donc avec les versions Web de ces différentes application, mais ça n'en révèle pas moins une faute de conception du concept d'application mobile). Le navigateur est un cas spécial : il prévoit bien qu'on puisse ouvrir plusieurs onglets (encore heureux), mais sur ordinateur il y a deux niveaux de hiérarchisation, les fenêtres et les onglets, et sur mobile on pourrait vouloir une nouvelle collection d'onglets sous forme d'une copie différente de l'application (ou dans la terminologie Android, « activité ») navigateur comme sur ordinateur on peut ouvrir une nouvelle fenêtre avec son propre jeu d'onglets. (L'intérêt serait, entre autres, de pouvoir passer rapidement de l'une à l'autre avec le raccourci Android permettant de changer d'activité.)

Cette histoire de multitâche est un peu plus anecdotique à mes yeux, mais je la signale quand même parce qu'elle semble elle-aussi procéder de cette vision de l'interface smartphone complètement centrée autour de la notion d'applications qui se partagent le terrain (aussi bien les données que, s'agissant du multitâche, l'espace-temps de l'écran et du temps de calcul).

Et même en cas d'applications différentes, le multitâche semble un peu aléatoire. Ce n'est jamais très clair si, quand une application est en train de faire un calcul quelconque, on peut passer à une autre application sans interrompre le calcul (ce qui est, quand même, la base du multitâche) : il me semble que parfois ça marche et parfois pas, et je ne sais pas s'il y a une logique. En tout cas, Android semble parfois arrêter les applications pas visitées depuis longtemps, et l'utilisateur n'a aucun contrôle là-dessus (on peut forcer une activité à quitter, mais pas vraiment à ne pas quitter). Il n'y a pas, comme sur ordinateur, la notion vraiment claire de lancer et de quitter une application, est c'est assez insupportable.

☞ Conclusion (et un mot sur les navigateurs)

Pour résumer, dans l'ensemble, l'interface des systèmes d'exploitation mobiles a cassé un certain nombre d'abstractions qui fonctionnaient bien sur les ordinateurs, comme la notion d'arborescence de fichier, de programmes bien séparés, d'indépendance du logiciel par rapport au matériel, pour les remplacer par une sorte de féodalisme dont les acteurs principaux sont les « applications » entre lesquelles le système d'exploitation mobile a tout juste un rôle d'arbitre[#12]. Ces changements sont souvent présentés comme une simplification destinée à facilité l'usage par le grand public, mais même si c'est parfois l'intention (et je ne sais pas combien c'est réussi), il y a parfois d'autres enjeux derrière, comme le contrôle sur les données et actions de l'utilisateur.

[#12] Bon, reconnaissons quand même ceci aux systèmes d'exploitation pour smartphone : au niveau sécurité, ils ont réussi à fournir un minimum d'isolation des applications les unes des autres, et notamment de protection contre les applications malicieuses. Enfin, il y a des trous de sécurité tout le temps, mais au moins il y a une sorte de tentative pour y arriver. Alors que sur les ordinateurs, la protection est essentiellement zéro : quand vous lancez une application au nom d'un utilisateur, elle peut faire tout ce que peut faire cet utilisateur. Ceci vient du fait que le modèle de sécurité hérité d'Unix est prévu pour protéger des utilisateurs les uns des autres mais pas les programmes lancés par un utilisateur donné (lequel est censé savoir ce qu'il fait).

Je dois ajouter que les navigateurs Web sont en train de devenir un peu comme les systèmes d'exploitation mobiles (chose que Mozilla avait d'ailleurs bien comprise en essayant de créer Firefox OS, un système d'exploitation pour smartphone qui fusionnait entièrement l'interface avec le navigateur, et le concept d'application mobile avec celui de webapplication) : là aussi on se retrouve avec des profils de navigateur qui deviennent impossibles à disséquer ou à sauvegarder si bien que la seule réponse est « sauvegardez vos données dans le cloud » (avec des choses comme Firefox sync), et il devient extrêmement difficile de savoir sous quelle forme un site Web stocke ses données (cookies ? stockage local du navigateur ? autre chose ?), sans parler de les exporter ou de les consulter, parce que l'abstraction utile qu'est le fichier est plus ou moins neutralisée. Heureusement, les navigateurs Web sont un peu plus respectueux des intérêts de l'utilisateur que les systèmes d'exploitation pour mobile, comme en témoigne l'existence d'outils comme la fenêtre de navigation privée, ou l'inspecteur JavaScript : je voudrais bien voir les mêmes choses vis-à-vis des applications sur smartphone, moi. (Bon, je retombe ici sur ce que je racontais dans ce billet, notamment par là, donc je ne vais pas re-rentrer dedans.)

Pour ma part, comme le billet qui précède le montre clairement, je préfère très nettement l'interface « ordinateur » (même si elle est très loin d'être idéale), où la notion de fichier a encore un sens, et où on peut sauvegarder l'état de la machine simplement en recopiant ses fichiers plutôt qu'en étant obligé d'avoir recours à un quelconque cloud. Hélas, l'écosystème mobile a convergé vers un duopole où on a le choix entre exactement deux possibilités merdiques : iOS ou Android, et la première option n'est disponible que sur un tout petit ensemble de téléphones très chers ; et hélas aussi, on ne peut pas échapper à ce duopole, parce que les applications mobiles, c'est-à-dire en pratique soit iOS soit Android, sont devenues de plus en plus indispensables à toutes sortes de démarches de notre vie quotidienne.

↑Entry #2802 [older| permalink|newer] / ↑Entrée #2802 [précédente| permalien|suivante] ↑

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]