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
Ç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.