---
title: "Un Pixel 3a français sous Linux : ce que Google a abandonné en 2022 tourne aujourd'hui sur un noyau de 2026"
subtitle: "Une heure perdue sur quatre fausses pistes, une ligne dans /sys qui donne la réponse, et un téléphone à l'écran fissuré qui devient une machine de développement"
description: "Un Pixel 3a G020F européen, dernière mise à jour Google en mai 2022, réinitialisé et fissuré. En une soirée : postmarketOS avec un noyau Linux mainline 7.1.3, Phosh, accès SSH par le câble USB. Le récit complet — pourquoi le noyau mainline plutôt qu'Ubuntu Touch, le déverrouillage du bootloader, et l'heure passée à croire que le câble était mort alors que le coupable était l'autosuspend USB du noyau relayé par TLP. Et pourquoi ce n'est pas qu'un passe-temps : Chat Control, la vérification d'âge, et la pièce d'identité que Google exigera bientôt des développeurs pour qu'on puisse installer leurs applications."
date: 2026-09-07
image: images/pixel3a/og-pixel3a.jpg
tags: [pixel 3a, postmarketos, linux mainline, sdm670, obsolescence, fastboot, usb autosuspend, tlp, libcamera, phosh, logiciel libre, droit à la réparation, chat control, vérification d'âge, souveraineté numérique, grapheneos, vie privée]
slug: pixel-3a-postmarketos-linux-mainline
lang: fr
---
# Un Pixel 3a français sous Linux : ce que Google a abandonné en 2022 tourne aujourd'hui sur un noyau de 2026
## Une heure perdue sur quatre fausses pistes, une ligne dans /sys qui donne la réponse, et un téléphone à l'écran fissuré qui devient une machine de développement
**En deux minutes**
- **Le point de départ** : un Pixel 3a de 2019, modèle européen G020F, dernière mise à jour de sécurité le 5 mai 2022, écran fissuré, réinitialisé aux réglages d'usine. Officiellement : un déchet.
- **Le point d'arrivée**, quelques heures plus tard : **postmarketOS** avec un **noyau Linux 7.1.3 mainline** — pas un noyau Android rafistolé, le vrai —, l'environnement Phosh, les deux caméras détectées, et un accès `ssh` par le simple câble USB.
- **Le choix qui compte** : Ubuntu Touch fait tout fonctionner mieux, mais repose sur des pilotes Android figés. postmarketOS fait fonctionner moins de choses, sur du code que l'on peut corriger et renvoyer en amont. Pour qui veut contribuer, c'est le seul choix.
- **L'heure perdue** : `fastboot` se figeait sans le moindre message. J'ai successivement accusé les permissions, le câble, le port USB et la version du binaire. Les quatre étaient faux. Le coupable : **le noyau endort l'interface USB après deux secondes**, le bootloader du Pixel ne sait pas se réveiller — et **TLP** repassait derrière ma correction.
- **Ce que ça révèle** : ce piège n'est documenté nulle part. Quelqu'un qui le rencontre conclut que son câble est mort et renonce. Un correctif de deux lignes le règle, pour tous les Pixel.
- **La suite** : `cam -l` reproduit un bogue connu de libcamera dès le premier démarrage — et en révèle un second, plus facile à corriger, que personne n'avait signalé.
- **Et votre téléphone ?** postmarketOS gère 39 appareils en `community` (dont quatorze téléphones) et 149 en `testing` ; Ubuntu Touch en annonce 111. Le tableau complet est [plus bas](#et-votre-telephone-a-vous).
*Ce billet se veut lisible sans rien connaître à Android ni à Linux : chaque terme technique est expliqué à sa première apparition. Les encarts « Pour aller au fond » se déplient pour ceux qui veulent les commandes exactes.*
*Le dos de l'appareil. « Model G020F » — la variante européenne. À côté, le marquage CE et la poubelle barrée, ce pictogramme qui signifie « ne pas jeter avec les ordures ménagères ». Il aura fallu attendre sept ans pour que ce symbole cesse d'être une formalité et devienne le sujet.*
## Ce que veut dire « fin de support »
Le Pixel 3a est sorti en mai 2019. C'était le bon élève de sa génération : un appareil photo remarquable pour 400 €, une prise casque que les modèles haut de gamme avaient déjà supprimée, un processeur Snapdragon 670 sans prétention. Google l'a mis à jour jusqu'au **5 mai 2022**. La dernière version installée sur celui-ci porte le numéro `SP2A.220505.008` — Android 12, correctif de sécurité de mai 2022.
Depuis, plus rien. Pas parce que le matériel a lâché : il fonctionne parfaitement. Parce qu'une entreprise a décidé qu'une durée était écoulée.
C'est une phrase qu'on lit sans y penser, « l'appareil n'est plus supporté ». Traduisons-la. Le processeur, l'écran, les caméras, le modem, la batterie — tout cela marche encore. Ce qui s'arrête, c'est un service : quelqu'un, quelque part, cesse de compiler du logiciel pour cette combinaison de puces. Le téléphone ne devient pas défectueux, il devient **orphelin**. Et comme le logiciel qu'il exécute n'est pas modifiable par son propriétaire, orphelin veut dire condamné.
Sauf que celui-ci était un Pixel. Et les Pixel ont une propriété rare : Google, contrairement à presque tous ses concurrents, autorise le propriétaire à **déverrouiller le chargeur d'amorçage** — le petit programme qui décide quel système d'exploitation a le droit de démarrer. Cette autorisation, sur laquelle je vais revenir, est ce qui sépare un appareil récupérable d'une brique.
Pour aller au fond : ce qu'un « bootloader » verrouille exactement
Quand un téléphone s'allume, un tout petit programme gravé dans la puce démarre en premier, vérifie une signature cryptographique sur le système qui vient ensuite, et refuse de continuer si elle ne correspond pas. C'est le *démarrage vérifié* (**verified boot**), et c'est une bonne chose : il empêche qu'un logiciel malveillant remplace votre système à votre insu.
Le problème n'est pas le mécanisme, c'est **qui détient la clé**. Sur un appareil verrouillé, seul le fabricant peut signer un système. Le jour où il cesse d'en produire, la serrure reste, mais plus personne n'a la clé. La sécurité devient une condamnation.
Google laisse le propriétaire désactiver ce contrôle, avec un avertissement bien visible et un effacement complet des données au passage — ce qui est la bonne façon de faire, puisqu'un voleur ne peut pas déverrouiller sans tout détruire. Les variantes vendues par certains opérateurs américains, elles, sont scellées définitivement. La différence n'est pas technique : elle est commerciale. Sur le dos du mien, « G020F » signifie *Rest of World*, la version européenne. Vendue sans opérateur, donc déverrouillable.
## Trois façons de mettre Linux sur un téléphone, et une seule qui compte ici
Un téléphone Android exécute déjà un noyau Linux. Mais un noyau Android, c'est une version ancienne du noyau officiel, à laquelle le fabricant de la puce a ajouté des milliers de modifications qu'il ne publie jamais en amont. Ce code ne vit que le temps du produit. C'est là toute la différence entre les trois options qui s'offraient :
| | postmarketOS | Ubuntu Touch | Droidian |
|---|---|---|---|
| Base | **noyau Linux mainline** | pilotes Android figés (Halium) | pilotes Android figés |
| Sur le Pixel 3a | catégorie *community* | version stable, très aboutie | fonctionnel |
| Appels, caméra, empreinte | partiels | **tout fonctionne** | partiels |
| Espérance de vie | celle du noyau Linux | celle des pilotes de 2019 | idem |
| Corrigeable en amont | **oui** | non | non |
Ubuntu Touch est objectivement le meilleur choix pour *utiliser* ce téléphone : les appels, les SMS, la 4G, le Bluetooth, le NFC, les deux caméras, le lecteur d'empreinte — tout marche. Mais il y parvient en réutilisant les pilotes binaires d'Android 9. C'est-à-dire en embaumant 2019. Rien de ce qu'on y corrige ne profite à personne d'autre, et le jour où cette base pourrira, il n'y aura rien à faire.
postmarketOS prend le chemin inverse : faire tourner le **noyau Linux officiel**, celui que tout le monde utilise, sur cette puce. C'est plus dur, il manque des choses, et c'est précisément l'intérêt — ce qui est écrit là remonte dans le noyau que le monde entier utilisera dans dix ans. Un groupe de développeurs s'y consacre spécifiquement pour ce processeur, sous le nom **sdm670-mainline**.
Le choix était donc simple, à condition d'assumer ce qu'il implique : ce téléphone ne sera pas mon téléphone. C'est un banc d'essai.
## Le déverrouillage, et le piège du téléphone réinitialisé
L'appareil arrivait réinitialisé, ce qui semblait simplificateur. Ça ne l'était pas.
Pour déverrouiller le chargeur d'amorçage, il faut activer une option nommée **Déverrouillage OEM** dans les réglages Android. Or cette option reste grisée tant que le téléphone n'a pas joint le réseau au moins une fois : Google vérifie que l'appareil n'est pas signalé volé. Il faut donc rallumer le téléphone, traverser l'assistant de mise en route, connecter le Wi-Fi — puis seulement activer l'option. Sur un appareil qu'on s'apprête entièrement à effacer, c'est un détour absurde mais obligatoire.
Second piège, plus vicieux : la combinaison de touches pour entrer en mode *fastboot* — le mode de maintenance du bootloader — est **Volume Bas + Power**, mais **uniquement depuis un téléphone complètement éteint**. Sur un appareil allumé, cette même combinaison prend une capture d'écran. On appuie, il ne se passe rien d'attendu, on recommence, on doute de son matériel. Il faut éteindre, attendre deux secondes, maintenir Volume Bas *d'abord*, puis appuyer sur Power.
Le reste tient en une commande, et un avertissement rouge sur l'écran qu'il faut confirmer avec les touches physiques :
```
fastboot flashing unlock
```
*L'écran de fastboot après l'opération. « Device state: unlocked » en rouge : le téléphone accepte désormais de démarrer un système qui n'est pas signé par Google. Notez « sargo MP1.0 (ROW) » — sargo est le nom de code du Pixel 3a, ROW confirme la variante internationale.*
Le téléphone efface tout et redémarre. À partir de là, il n'appartient plus vraiment à Google.
## Préparer le système : une demi-heure de questions
Côté ordinateur, postmarketOS se construit avec un outil nommé `pmbootstrap`, disponible dans les dépôts de la plupart des distributions. Il ne télécharge pas une image toute faite : il assemble le système pour votre appareil précis, dans un environnement isolé, en vous posant une vingtaine de questions.
La plupart appellent une réponse par défaut. Trois méritent réflexion, et j'ai tranché les trois selon le même principe : **coller à ce que les mainteneurs testent.**
C'est un principe qui mérite d'être explicité, parce qu'il est contre-intuitif. Quand on installe un système pour soi, on choisit ce qu'on préfère. Quand on l'installe pour contribuer, chaque écart au choix majoritaire est une variable supplémentaire qui rendra vos rapports de bogue inexploitables. Si je remonte un problème audio sur une pile que personne d'autre n'utilise, le mainteneur ne peut ni le reproduire, ni le comparer. Mon rapport devient du bruit.
J'ai donc pris `pulseaudio` plutôt que le plus moderne `pipewire`, `wpa_supplicant` plutôt qu'`iwd`, l'interface **Phosh** plutôt que la très tentante `sxmo`, et — à contrecœur — systemd. Sur ce dernier point, postmarketOS est un des rares endroits où OpenRC reste un citoyen de première classe ; mon réflexe n'avait rien de marginal. Mais quatre des quinze bogues ouverts pour cet appareil sont rapportés sous Phosh avec systemd, et `journalctl` reste l'outil le plus commode pour extraire une trace propre.
Deux réponses valent un avertissement.
**Ne pas activer le chiffrement du disque.** L'option est là, elle est tentante, et sur ce téléphone elle rend l'appareil non démarrable : un bogue ouvert décrit un système qui ne détecte pas la saisie du mot de passe au démarrage. On se retrouve avec une machine qui demande une phrase secrète impossible à taper.
**Garder la locale en anglais.** Contre-intuitif pour un billet en français, mais les messages d'erreur et les journaux sortiront en anglais, donc directement collables dans un rapport et comparables à ceux des autres. Ça n'empêche nullement d'avoir un clavier AZERTY.
Pour aller au fond : les réponses exactes, et les paquets à embarquer
```
Channel edge # là où les bogues sont rapportés et les correctifs atterrissent
Vendor google
Device sargo
UI phosh
Audio backend pulseaudio # défaut
WiFi backend wpa_supplicant # défaut
usb-moded developer # réseau USB TOUJOURS actif — le cordon de sécurité
Service manager default # systemd pour Phosh
Locale en_US
```
Le choix `usb-moded: developer` mérite d'être souligné : il maintient une interface réseau active sur le câble USB en permanence. Quand l'écran ne répondra plus — et ça arrivera —, `ssh` par le câble sera le seul moyen d'entrer récupérer les journaux. L'autre option, `charging`, exigerait d'activer le réseau à la main depuis un téléphone potentiellement inutilisable.
Pour les paquets supplémentaires, j'ai embarqué de quoi travailler dès le premier démarrage :
```
libcamera-tools,v4l-utils,evtest,tmux,vim,strace,usbutils
```
`libcamera-tools` fournit la commande `cam`, qui est précisément l'outil cité dans le bogue caméra que je voulais reproduire. `v4l-utils` fournit `v4l2-ctl`, l'instrument de mesure du correctif visé. `evtest` sert aux bogues tactiles. `tmux` permet à une session SSH de survivre au débranchement du câble.
Une remarque de méthode : **ne devinez pas les noms de paquets.** Alpine, la distribution sur laquelle repose postmarketOS, ne les nomme pas toujours comme votre distribution habituelle. Un nom erroné fait échouer l'installation après plusieurs minutes. L'index est public et se vérifie en dix secondes :
```bash
curl -s -o idx.tar.gz \
"https://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz"
tar xzf idx.tar.gz -O APKINDEX | grep '^P:' | sed 's/^P://' > paquets.txt
grep -qx "libcamera-tools" paquets.txt && echo présent
```
C'est comme ça que j'ai découvert que `device-tree-compiler` s'appelle `dtc` chez Alpine.
*Oui. `dtc`. J'ai relu deux fois avant de taper la commande.*
Une trentaine de minutes plus tard, le système était construit. Restait à l'écrire dans le téléphone. C'est là que la soirée a dérapé.
## Une heure à accuser le mauvais coupable
Le téléphone était en mode fastboot, branché, reconnu. La commande d'écriture partait — et se figeait. Indéfiniment. **Sans le moindre message d'erreur**, ni sur la sortie standard, ni sur la sortie d'erreur. Un processus endormi, à l'infini.
Ce qui rendait la chose déroutante, c'est que l'appareil semblait parfaitement présent :
```
$ fastboot devices
058AY1WZGT fastboot
```
Il répondait. Il était là. Et pourtant toute écriture se bloquait.
J'ai formulé quatre hypothèses. Les quatre étaient fausses, et les écarter m'a pris une heure. Elles valent d'être listées, parce que ce sont exactement celles que n'importe qui formulerait.
**Un problème de permissions.** L'hypothèse classique : le nœud USB appartient à `root`, l'utilisateur n'a pas le droit d'écrire dessus. Vérification faite, le fichier portait une liste de contrôle d'accès accordant explicitement l'accès à mon compte. Écarté par la mesure, pas par la supposition.
**Un câble ou un port défectueux.** C'est le réflexe suivant, et le plus répandu sur les forums. Sauf que les journaux du noyau étaient d'une propreté irréprochable : énumération en haute vitesse, aucune erreur, aucune réinitialisation, aucune déconnexion intempestive. Un câble abîmé laisse des traces ; il n'y en avait aucune.
**Un problème de contrôleur USB.** Piste sérieuse : les Pixel n'ont qu'de l'USB 2.0, et les contrôleurs modernes sont réputés capricieux avec certains chargeurs d'amorçage. Le conseil habituel est « branchez sur un port USB 2.0 ». Deux mesures l'ont écarté : le téléphone négociait déjà en 480 mégabits, donc bien en USB 2.0, et la carte mère de la machine (une Raptor Lake d'Intel) n'a plus de contrôleur d'ancienne génération — tout passe par le même bloc. « Changer pour un port USB 2.0 » n'avait pas de sens.
**Une régression dans le logiciel.** `pmbootstrap` exécute sa propre copie de `fastboot`, en version 37, tandis que mon système en avait une version 35. J'ai donc contourné l'outil pour flasher directement avec la version du système. **Elle s'est figée exactement pareil.** Hypothèse morte.
Quatre pistes, quatre impasses. Et un détail qui aurait dû m'alerter bien plus tôt : à chaque nouvelle entrée en mode fastboot, **la première commande passait** — en treize millisecondes — et toutes les suivantes se figeaient.
J'avais ce fait sous les yeux depuis le début. J'ai mis une heure à l'écouter, parce que je continuais à interroger l'appareil au lieu d'interroger le système.
## La réponse tenait dans un fichier
Le mode fastboot est un dialogue : l'ordinateur pose des questions, le bootloader répond. J'ai fini par regarder non pas ce que répondait le téléphone, mais **ce que le noyau Linux pensait de lui**. Ces informations vivent dans `/sys`, un système de fichiers virtuel où le noyau expose son état interne sous forme de fichiers lisibles.
```
$ cat /sys/bus/usb/devices/1-9/power/control
auto
$ cat /sys/bus/usb/devices/1-9/power/autosuspend_delay_ms
2000
$ cat /sys/bus/usb/devices/1-9/power/runtime_status
suspended
```
**Endormi.**
Pour économiser l'énergie, le noyau met les périphériques USB en veille après un délai d'inactivité — ici, deux secondes. C'est un comportement normal et souhaitable pour la plupart des appareils, qui savent se réveiller quand on leur reparle. **Le chargeur d'amorçage du Pixel ne sait pas.** Une fois endormi, il ne répond plus jamais.
Tout s'explique d'un coup :
| Ce que j'observais | Ce qui se passait |
|---|---|
| La première commande passe, les suivantes se figent | Le téléphone s'endort dans l'intervalle |
| `fastboot devices` liste l'appareil quand même | L'énumération est en cache, elle ne demande aucun échange |
| Le déverrouillage avait fonctionné | C'était la première commande après une entrée en fastboot |
| Ressortir et rentrer en fastboot « réparait » | Une nouvelle énumération réveille l'appareil, pour une commande |
| Les deux versions de `fastboot` échouaient pareil | Le binaire n'y était pour rien |
| Les journaux du noyau restaient propres | La mise en veille n'est pas une erreur, c'est le fonctionnement normal |
La correction est une règle de trois lignes, qui demande au noyau de ne jamais endormir les appareils Google :
```
# /etc/udev/rules.d/52-fastboot-no-autosuspend.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", \
TEST=="power/control", ATTR{power/control}="on"
```
Sauf que ça n'a rien changé. Et la raison de cet échec est la partie la plus intéressante de l'histoire.
## Le second coupable, tapi derrière le premier
Ma règle était pourtant correcte — l'outil de diagnostic d'udev confirmait qu'elle était bien évaluée et bien appliquée. Mais après le branchement, le réglage retombait à `auto`.
Quelqu'un repassait derrière moi. Ce quelqu'un s'appelait **TLP**, un gestionnaire d'énergie très répandu sur les ordinateurs portables Linux, qui applique ses propres réglages d'autosuspend USB *après* udev, et écrase donc silencieusement les vôtres. Beaucoup de gens l'installent une fois pour gagner de l'autonomie, puis l'oublient complètement.
TLP a précisément une option prévue pour ce cas :
```
# /etc/tlp.conf
USB_EXCLUDE_PHONE=1
USB_DENYLIST="18d1:4ee0 18d1:4ee1 18d1:4ee2 18d1:4ee3 18d1:4ee7"
```
Cette fois le réglage a tenu. Un détail à connaître : **poser la correction ne débloque pas un appareil déjà endormi.** L'état USB du bootloader ne se répare qu'à la ré-énumération. Il faut donc corriger, *puis* ressortir et rentrer en mode fastboot.
Et pour maximiser les chances, j'ai groupé les trois écritures en une seule invocation, plutôt que trois processus successifs :
```bash
fastboot flash vbmeta vbmeta.img \
flash boot boot.img \
flash userdata google-sargo.img
```
```
Sending 'vbmeta_b' (4 KB) OKAY [ 0.120s]
Writing 'vbmeta_b' OKAY [ 0.071s]
Sending 'boot_b' (28008 KB) OKAY [ 0.747s]
Writing 'boot_b' OKAY [ 0.194s]
Sending sparse 'userdata' 1/9 (258751 KB) OKAY [ 6.306s]
...
Finished. Total time: 94.883s
```
Quatre-vingt-quinze secondes. Après une heure de blocage.
Pour aller au fond : diagnostiquer un fastboot qui se fige
Trois réflexes, dans cet ordre :
**1. Vérifier que l'appareil est réellement là avant d'interpréter quoi que ce soit.** Un `< waiting for any device >` signifie souvent que le téléphone a simplement quitté le mode fastboot, pas qu'il y a un problème d'accès. J'ai failli conclure à un problème de droits inversé sur un test dont l'appareil était en réalité absent.
```bash
lsusb | grep 18d1
```
**2. Regarder l'état du noyau, pas seulement la sortie de la commande.**
```bash
cat /sys/bus/usb/devices//power/runtime_status
```
**3. Inspecter le processus figé.** Il dit s'il a ouvert le périphérique — auquel cas il attend une réponse qui ne viendra pas — et dans quel environnement il tourne :
```bash
sudo readlink /proc//root # tourne-t-il dans un chroot ?
sudo ls -l /proc//fd | grep usb # a-t-il ouvert le périphérique ?
```
Deux pièges de coquille rencontrés en chemin, qui m'ont coûté du temps :
- `rc=$?` après un tube capture le code du **dernier maillon**, jamais celui de `timeout`. Ma sonde de diagnostic affichait donc « OK » sur des commandes qui se figeaient. Rediriger vers des fichiers et tester directement, ou utiliser `set -o pipefail`.
- `pkill -f 'un motif'` tue le shell appelant quand le motif figure dans sa propre ligne de commande. Préférer une boucle sur `pgrep -x`.
## Ce qui a démarré
Vingt secondes après le redémarrage, la machine a vu apparaître une interface réseau. Le téléphone distribuait lui-même les adresses.
```
$ ssh sam@172.16.42.1
$ uname -r
7.1.3-sdm670
$ df -h /
/dev/loop0p2 47.9G 2.2G 43.2G 5% /
```
**Noyau 7.1.3.** Sur un téléphone dont le fabricant a cessé de s'occuper en mai 2022, avec un noyau Android figé en 4.9. Le système de fichiers s'était agrandi tout seul au premier démarrage pour occuper les 48 gigaoctets disponibles.
*Premier démarrage. L'écran est fissuré depuis longtemps ; l'appareil, lui, vient de rajeunir de quatre ans.*
*Le panneau de réglages rapides. Wi-Fi, Bluetooth, batterie à 94 %. Et dans les notifications, le sélecteur « USB Developer mode » — exactement le profil choisi à l'installation, celui qui garde le réseau USB actif en permanence. L'horloge affiche « jeudi 1er janvier, 4 h 12 » : l'horloge matérielle n'a pas encore été mise à l'heure, personne ne lui a encore dit quel jour on était.*
## La caméra, ou comment un outil bien écrit vous tend le travail
Restait à vérifier ce que je venais chercher. Sur postmarketOS, la gestion des caméras passe par **libcamera**, une bibliothèque libre qui remplace la pile propriétaire d'Android. Un bogue connu signale que le pilote du capteur avant de ce téléphone est incomplet, et que la commande `cam -l` — qui liste les caméras — s'en plaint.
Elle s'en est plainte, en effet. Mais bien mieux que je ne l'espérais :
```
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 2 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 1 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 0 on pad 0/0
WARN 'imx355 4-001a': Failed to retrieve the sensor crop rectangle
WARN 'imx355 4-001a': The sensor kernel driver needs to be fixed
WARN See Documentation/sensor_driver_requirements.rst
```
Il y a quelque chose de réjouissant dans un logiciel qui vous dit littéralement « le pilote noyau du capteur a besoin d'être corrigé » et vous donne la référence du document qui explique comment. C'est l'opposé exact d'[une erreur 4202 sur un aspirateur](erreur-4202-neato-obsolescence.html).
Concrètement : le pilote ne sait pas répondre quand on lui demande les dimensions réelles de sa matrice de pixels. libcamera invente alors des valeurs par défaut, et travaille sur une géométrie approximative.
Mais la sortie révélait aussi ceci, que je n'attendais pas :
```
WARN 'imx363': No static properties available — Please consider updating the database
WARN 'imx355': No static properties available
WARN IPASoft: Failed to create camera sensor helper for imx355 / imx363
```
Ce second problème n'est pas dans le noyau. Ce sont deux tables de données, dans libcamera elle-même, où les capteurs du Pixel 3a manquent à l'appel — alors que des dizaines d'autres y figurent déjà et fournissent un modèle à recopier. Des données pures, aucune algorithmique.
**Mise à jour, quelques heures plus tard.** En allant écrire ce correctif, j'ai découvert que la moitié venait d'être faite : le capteur avant, l'**imx355**, a été ajouté en amont *après* la version 0.7.2 qu'exécute ce téléphone. L'avertissement ci-dessus est donc un artefact de version, pas un manque — une mise à jour suffira. Le capteur arrière, l'**imx363**, reste absent de tout le dépôt, et son pilote n'est même pas dans le noyau officiel : il a été écrit chez Intel, jamais remonté en amont, et postmarketOS le charge en module.
Et en comparant l'entrée neuve de l'imx355 avec ce que le pilote expose réellement sur l'appareil, un détail cloche : elle associe « barres de couleur » à la valeur 1 et « couleur unie » à la valeur 2, quand le pilote fait exactement l'inverse. Deux autres capteurs au menu identique, l'imx258 et l'imx471, sont correctement décrits juste à côté. Ça fait donc deux correctifs au lieu d'un — et le plus simple est celui que personne n'attendait.
Autrement dit : le premier correctif à écrire n'est pas celui que je visais en arrivant. Il a fallu allumer le vrai matériel pour s'en apercevoir. C'est une leçon assez générale — on peut lire des rapports de bogue pendant des jours sans voir ce qu'une machine allumée vous dit en trois secondes.
## Pourquoi ce n'est pas seulement un passe-temps
Le matin même où ce téléphone a démarré, le compte `balade.nomade` publiait [un reel](https://www.instagram.com/reel/Dc-vV23MGIi/) ([copie locale de la légende et du fil de commentaires](../assets/pixel3a/refs/balade-nomade-reel-2026-09-07.md)) qui résume ce qui se joue en ce moment à Bruxelles. Il se termine par une question que je trouve bien posée :
> Es-tu prêt à scanner ta carte d'identité pour utiliser Instagram ?
Le ton est militant, alors j'ai vérifié les trois points. Deux tiennent solidement, le troisième mérite une nuance — et le fil de commentaires en a ajouté un quatrième, plus pertinent que les trois autres pour ce billet.
**Chat Control.** Exact. Le règlement européen dit CSAR reste bloqué en trilogue, et les négociations reprennent fin septembre 2026 sous présidence irlandaise du Conseil. Le 9 juillet 2026, le Parlement européen a voté à 314 voix contre 276 le retrait du dispositif — sans atteindre le seuil de 360 voix nécessaire pour bloquer la position du Conseil. La dérogation autorisant le scan « volontaire » des messages a donc été prolongée jusqu'en 2028. L'analyse côté client a été retirée de la dernière version du texte, mais le service juridique du Conseil lui-même, dans un avis du 10 juin 2026, estime que ce scan volontaire demeure une recherche généralisée dans les communications, incompatible avec l'article 7 de la Charte des droits fondamentaux.
**La fin de l'anonymat.** Exact, avec une actualité que le reel ne mentionne pas : la loi française du 21 juillet 2026 interdisant les réseaux sociaux aux moins de quinze ans a été **censurée le 14 août par le Conseil constitutionnel** (décision n° 2026-911 DC), pour atteinte disproportionnée à la liberté d'expression et à la vie privée. Elle n'entrera donc pas en vigueur en l'état. Mais le mouvement de fond continue ailleurs : la Commission européenne a annoncé le 15 avril 2026 que sa solution de vérification d'âge était prête au déploiement, et le portefeuille d'identité numérique européen doit arriver dans les États membres d'ici la fin de l'année.
**Les métadonnées.** Là je nuance. L'EDPB a bien adopté le 7 juillet 2026 de nouvelles lignes directrices sur l'anonymisation, en consultation jusqu'au 30 octobre, qui remplacent l'avis de référence de 2014. Mais c'est un travail de clarification technique, pas un coup de poing sur la table. Et la jurisprudence récente va plutôt dans l'autre sens : la Cour de justice de l'Union européenne, en septembre 2025, a retenu une approche *relative* — une même donnée pseudonymisée peut être anonyme pour qui n'a aucun moyen de réidentifier, et personnelle pour un autre.
### Le quatrième point, celui qui parle vraiment de ce billet
Dans les commentaires, quelqu'un signale que Google change sa politique d'installation d'applications et s'inquiète que cela « mette en péril GrapheneOS ». La réponse de l'auteur corrige à juste titre la crainte, et les faits lui donnent raison.
Depuis août 2025, Google impose que **toute application installée sur un appareil Android certifié provienne d'un développeur vérifié** — y compris quand on installe un fichier APK à la main, en dehors de toute boutique. Les premières restrictions visibles arrivent le **30 septembre 2026** au Brésil, en Indonésie, à Singapour et en Thaïlande, avant une extension mondiale en 2027. Installer l'application d'un développeur non vérifié passera par un parcours détourné avec un **délai d'attente obligatoire de vingt-quatre heures**. Et pour être vérifié, un développeur doit ouvrir un compte, payer vingt-cinq dollars et fournir une **pièce d'identité officielle**.
Relisez la question du reel, et remplacez l'utilisateur par le développeur. C'est le même geste : une pièce d'identité comme condition d'accès. D'un côté pour lire, de l'autre pour écrire.
Le commentateur se trompait pourtant sur un point, et c'est celui qui compte. La contrainte porte sur les appareils **certifiés** — ceux qui embarquent les services Google sous licence. GrapheneOS ne les embarque pas : il est hors du périmètre. La restriction ne met donc pas en péril les systèmes dégooglisés, **elle rend leur existence plus nécessaire**.
### Installer son propre logiciel, ce combat
C'est ce qui m'exaspère le plus, et c'est antérieur à toute cette actualité. Sur Android comme sur iOS, installer un logiciel qu'on a compilé soi-même, ou récupéré sur un dépôt Git, est un parcours d'obstacles.
Sur Android, il faut autoriser une source inconnue, passer trois avertissements, et bientôt fouiller les options développeur puis patienter vingt-quatre heures. Sur iOS c'est pire : une application que vous compilez et signez avec un compte Apple gratuit **cesse de fonctionner au bout de sept jours** et doit être réinstallée depuis un ordinateur. Pour qu'elle survive, il faut payer quatre-vingt-dix-neuf euros par an. Le règlement européen sur les marchés numériques a entrouvert la porte en 2024 — boutiques alternatives, distribution depuis son propre site — mais uniquement dans l'Union, et sous conditions d'Apple.
La justification est toujours la même : la sécurité. Elle mérite d'être prise au sérieux, donc examinée.
Si l'ouverture causait l'insécurité, ça se verrait. Linux laisse installer n'importe quoi depuis n'importe où — un dépôt, une archive, du code compilé à la main — et ce n'est pas un désastre sécuritaire : c'est le système qui fait tourner l'essentiel des serveurs de la planète, sous attaque permanente. Windows, à l'inverse, a longtemps eu le modèle le plus permissif **et** la pire réputation. Si la théorie était bonne, Android et iOS seraient les systèmes les plus sûrs jamais conçus. On observe à peu près l'inverse de ce qu'elle prédit.
Ce qui protège n'est donc pas la fermeture, c'est **une chaîne de confiance vérifiable** : des dépôts signés, des mainteneurs identifiés, du code source que n'importe qui peut relire, des constructions reproductibles. La sécurité vient de la transparence, pas de la permission. Et cette chaîne existe déjà sur Android : F-Droid distribue depuis des années des applications libres compilées à partir de sources publiques, sans péage ni pièce d'identité.
Pendant ce temps, la boutique officielle laisse passer. En 2026, une famille de logiciels malveillants baptisée NoVoice a été trouvée dans plus de cinquante applications du Play Store, cumulant au moins 2,3 millions de téléchargements — avec accès root et survie à une réinitialisation d'usine. L'année précédente, la campagne SlopAds : 224 applications, 38 millions de téléchargements. Et Google a banni **80 000 comptes développeurs en 2025**, sous un régime qui exige déjà une vérification d'identité pour publier sur le Play Store.
C'est ce chiffre qui règle la discussion. La vérification des développeurs existe déjà là où elle est censée protéger, et il faut quand même bannir quatre-vingt mille comptes par an. L'étendre à l'installation manuelle n'arrêtera pas les campagnes industrielles — elles passent par la grande porte, et c'est documenté. Ça arrêtera le développeur isolé qui publie son code sur un dépôt Git.
Le risque, lui, est réel : quelqu'un qui installe un fichier reçu par SMS se fait effectivement piéger. Mais ça plaide pour un avertissement clair, pas pour un droit d'entrée. On protège quelqu'un en lui disant ce qu'il est en train de faire ; on ne le protège pas en faisant payer celui qui écrit.
Et il y a un critère qui tranche la question. Pour opérer une boutique alternative dans l'Union européenne, Apple exige, à compter du **1er octobre 2026**, d'être coté en bourse, ou financé par du capital-risque, ou d'avoir passé un audit financier, ou de totaliser un million d'installations annuelles. Aucun de ces critères ne mesure la sécurité de quoi que ce soit. Ce sont des critères de **taille**.
Je veux bien croire à la bonne foi sur le principe. J'ai plus de mal quand la même entreprise verrouille la porte et tient la caisse.
### Ce que ça change pour un vieux téléphone
Le point commun de tout ça est technique, et c'est lui qui relie cette actualité à un Pixel de 2019.
L'analyse côté client, c'est inspecter les messages **sur l'appareil, avant chiffrement**. Un tel dispositif ne s'implémente pas dans une application : il s'implémente dans le système. C'est le déplacement décisif. Tant que la garantie reposait sur le protocole, on pouvait l'auditer de l'extérieur. Dès qu'elle repose sur l'appareil, la seule question qui compte devient : *qui décide de ce que fait cet appareil ?*
Sur un téléphone dont le système ne peut pas être remplacé, la réponse est : le fabricant. Et à travers lui, quiconque légifère sur le fabricant. Ce n'est pas un scandale, c'est une chaîne de décision parfaitement ordinaire — mais elle ne passe à aucun moment par le propriétaire.
Les deux échappatoires existantes — GrapheneOS, postmarketOS — reposent sur exactement la même chose : **un bootloader qu'on a le droit de déverrouiller**. La même case à cocher dans les options développeur qui a ouvert cette soirée. Toute la voie de sortie pratique, pour Android, a tenu jusqu'ici à la bonne volonté d'un seul fabricant sur un seul réglage. GrapheneOS n'est disponible que sur Pixel ; il faudra attendre les Motorola haut de gamme de 2027 pour que ce ne soit plus vrai.
Et il faut dire ce que ce billet ne démontre pas. **postmarketOS sur un Pixel 3a n'est pas une solution de vie privée.** Le modem reste une boîte noire, un processeur autonome exécutant du logiciel propriétaire auquel le système n'a pas accès. Cet appareil-ci n'est pas utilisable au quotidien, je l'ai dit dès le départ. Pour un usage réel, la réponse sérieuse est celle que le reel met en mot-clé : GrapheneOS.
Ce que démontre ce billet est plus modeste, et suffit : **la capacité existe, elle est à la portée d'une soirée, et elle s'exerce.** Une capacité qu'on n'exerce jamais finit par disparaître sans que personne ne s'en aperçoive — pas par interdiction, simplement parce qu'un jour plus aucun appareil ne la propose et que personne ne l'aura réclamée.
## Et votre téléphone à vous ?
C'est la première question qu'on m'a posée, et elle est la bonne. Voici de quoi y répondre — les chiffres viennent du dépôt `pmaports` au 5 septembre 2026 et du site officiel d'Ubuntu Touch, pas d'une liste recopiée quelque part.
D'abord un avertissement sur le vocabulaire. postmarketOS classe ses appareils en trois niveaux, et ils veulent dire quelque chose :
- **`community`** — ça marche globalement, avec des manques identifiés. **39 appareils**, dont seulement quatorze téléphones.
- **`testing`** — de « ça démarre, en un sens » à « presque tout fonctionne ». **149 appareils.** C'est là que se trouve la majorité du parc, et c'est là qu'il y a du travail.
- **`downstream`** — noyau Android d'origine, fonctionnalités très limitées. **20 appareils**, déconseillés.
Aucun appareil n'est aujourd'hui classé au-dessus de `community`. Ça situe honnêtement l'état de l'écosystème.
### Les quatorze téléphones en `community`
| Année | Appareil |
|---|---|
| 2009 | Nokia N900 |
| 2012 | Samsung Galaxy S III |
| 2014 | Samsung Galaxy Core Prime VE LTE |
| 2018 | OnePlus 6 · OnePlus 6T · Samsung Galaxy S9 · Xiaomi Poco F1 |
| 2019 | **Google Pixel 3a** · Pixel 3a XL · Purism Librem 5 |
| 2020 | SHIFT6mq |
| 2021 | **Fairphone 4** · PinePhone Pro |
Deux surprises dans cette liste. Le **Xiaomi Poco F1** et les **OnePlus 6 / 6T** sont d'excellents candidats : puissants pour leur âge, très répandus d'occasion, et portés depuis longtemps. Et le **PinePhone d'origine**, pourtant conçu pour Linux, est en `testing` — c'est son successeur Pro qui est en `community`.
Le reste de la catégorie n'est pas fait de téléphones : une douzaine de **Chromebooks** ARM, le Lenovo ThinkPad X13s, la PineNote, l'Odroid XU4, le RockPro64. Si vous cherchez un petit ordinateur ARM sous Linux plutôt qu'un téléphone, c'est une piste largement sous-estimée.
Côté `testing`, les 149 appareils se répartissent surtout entre **Samsung** (30), **Xiaomi** (18), **Sony**, **OnePlus**, **LG** et **Google** (5 chacun), et **Fairphone** (4). Il y a donc de fortes chances que votre téléphone y figure — avec du travail à faire dessus, ce qui est précisément l'intérêt.
### Si vous voulez un téléphone qui marche, pas un banc d'essai
C'est un autre besoin, et il a d'autres réponses. **Ubuntu Touch** annonce **111 appareils** pris en charge, avec un taux de fonctionnalités par appareil. Les mieux servis :
| Appareil | Fonctionnel |
|---|---|
| Lenovo Tab M10 HD 2ᵉ gén. (WiFi) | 100 % |
| BQ Aquaris M10 HD / FHD | 98,7 % |
| **Fairphone 5** (2023) | 97,4 % |
| Xiaomi Redmi Note 9 Pro · Poco X3 NFC | 97,4 % |
| OnePlus Nord N10 5G · Nord N100 | 97,4 % |
| **Fairphone 4** · Pixel 3a / 3a XL | 97,3 % |
| **Nothing Phone (1)** (2022) | 95,6 % |
| Fairphone 3 / 3+ | 95,6 % |
Le **Fairphone 4** est le point d'équilibre de tout ça : il est à la fois en `community` chez postmarketOS **et** à 97,3 % chez Ubuntu Touch, et c'est par ailleurs le téléphone le plus réparable du marché. Si quelqu'un me demandait quoi acheter pour faire ça sérieusement, ce serait lui — ou le Fairphone 5 si l'objectif est d'abord de s'en servir.
Et si vous voulez rester sur Android tout en sortant de chez Google, **GrapheneOS** reste la réponse la plus solide — mais uniquement sur Pixel 6 et suivants, avec sept ans de mises à jour garanties sur les Pixel 8, 9 et 10. Le partenariat annoncé en août 2026 avec Motorola devrait lever cette exclusivité en 2027 ; la liste officielle, elle, est encore exclusivement Pixel aujourd'hui.
### Comment vérifier pour le vôtre
Cherchez le nom de code de votre appareil — pas son nom commercial — sur le wiki de postmarketOS et sur `devices.ubuntu-touch.io`. Le nom de code se lit en une commande, l'appareil branché en USB :
```bash
adb shell getprop ro.product.device
```
Sur le mien, ça répond `sargo`. Et deux conditions préalables valent pour tout le monde, indépendamment de la liste : **le bootloader doit être déverrouillable**, ce qui exclut la plupart des appareils vendus par les opérateurs américains ; et l'opération **efface tout**.
## Ce que je retiens
La partie technique est presque anecdotique. Trois choses me restent.
**Le piège n'est nulle part.** L'autosuspend USB n'est mentionné dans aucun guide d'installation. Quelqu'un qui le rencontre voit une commande qui se fige sans message, essaie un autre câble, un autre port, et conclut que son matériel est en cause. Il renonce. Le correctif fait deux lignes et vaut pour tous les Pixel. C'est ce que je vais écrire en premier — avant tout code, avant la caméra. Une soirée perdue par moi peut en épargner beaucoup à d'autres, et c'est probablement la contribution la plus rentable de toute l'histoire.
**J'ai cherché au mauvais endroit pendant une heure.** Non par manque de méthode, mais parce que je continuais à interroger l'appareil — retenter la commande, changer un paramètre, réessayer — au lieu d'interroger le système qui pilotait l'appareil. La réponse était dans un fichier texte de neuf caractères. Chaque fois qu'un outil se tait au lieu d'échouer, il faut arrêter de le relancer et aller lire l'état de la couche d'en dessous.
**Et puis il y a le fond.** Ce téléphone porte gravée au dos une poubelle barrée, ce pictogramme qui signifie qu'on ne le jette pas avec les ordures. Le symbole est là depuis 2019, obligatoire, décoratif. Ce soir il est devenu exact : l'appareil n'est pas allé à la benne, il tourne, et il tourne sur un noyau plus récent que celui de bien des machines en service.
Ce n'est pas un exploit technique — des gens autrement compétents ont fait le travail difficile, celui de porter un noyau moderne sur cette puce. Je n'ai fait que suivre leurs traces et me cogner à un piège qu'ils n'avaient pas documenté. Mais c'est une démonstration : la fin de support n'est pas une propriété du matériel. C'est une décision. Et quand le fabricant laisse la porte ouverte — comme Google le fait sur les Pixel, à son honneur —, cette décision peut être reprise par quelqu'un d'autre.
Un Pixel 3a d'occasion se trouve pour quelques dizaines d'euros. Il y en a des millions dans des tiroirs.
La suite, c'est la caméra.