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.