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.
[Lire la suite…]
![[Mona Lisa]](../images/mona_lisa.webp)
![[arobase]](../images/commercial_at.png){kind=small}
![[point]](../images/full_stop.png){kind=small}
![[Schéma illustrant la théorie de la négociation de Nash]](../images/threatfigure1.svg)
![[Schéma]](../images/threatfigure2.svg)
![[Page de maths manuscrites]](../images/20241218-reduction-formula.jpg "Un exemple de réflexion mathématique")
![[Divers stylos Pilot]](../images/20241218-stylos-pilot.jpg "Ma collection actuelle")
![[Page du livre incriminé]](../images/20241126-page-livre-arnaque.jpg "Ceci n'est pas un livre")
_-_map.png){kind=link}