Le premier essai pour transformer son téléphone en serveur s’est terminé avec un écran noir et un appareil presque transformé en presse-papier.

Le deuxième marche parce que son auteur arrête justement d’essayer de faire disparaître Android.

Dans “my server is a phone now”, seg6 raconte comment un CMF Phone 1 qui prenait la poussière a remplacé son petit VPS Hetzner. Il héberge aujourd’hui un navigateur Chrome distant, un outil de finances personnelles, un service de partage d’écran et plusieurs applications web.

L’objet est amusant. La méthode l’est davantage : au lieu de demander au téléphone de devenir un mini-PC Linux conventionnel, il conserve la couche qui sait déjà gérer son Wi-Fi, sa batterie, son modem et tous les détails bizarres du constructeur, puis construit l’environnement serveur au-dessus.

Le Linux plus pur était le moins utile

La première idée paraît logique : installer une distribution Linux classique.

L’auteur essaie postmarketOS. Le port démarre suffisamment loin pour donner de l’espoir, mais son expérience laisse des éléments essentiels hors service pour cet usage, notamment le réseau sans fil et une partie de l’accélération matérielle. Après un écran noir et une restauration compliquée de Nothing OS, il change le problème.

Il n’a pas besoin d’un téléphone qui ressemble à un serveur Linux. Il a besoin d’exécuter de manière fiable ses logiciels Linux sur un appareil dont Android sait déjà faire fonctionner le matériel.

Termux devient donc la couche hôte.

Les propres docs de Termux confirment le point important : par défaut, ses programmes s’exécutent nativement sur le système Android et utilisent son noyau Linux. Ce n’est ni une VM ni un conteneur. L’environnement utilisateur diffère d’une Debian classique, mais le noyau et les drivers restent ceux qui ont été livrés avec le téléphone.

Termux:Boot relance les scripts au démarrage. La documentation du plugin montre même termux-wake-lock dans son exemple de serveur SSH persistant, parce qu’Android reste Android et préfère normalement économiser la batterie plutôt que maintenir votre petit empire personnel à 3 heures du matin.

Garder Android implique de lutter contre Android

Le compromis n’est pas gratuit.

seg6 configure un wake lock permanent, désactive plusieurs mécanismes d’idle, exempte Termux et Tailscale des restrictions d’arrière-plan et ajuste la suspension Wi-Fi. Le téléphone est délibérément détourné de son comportement normal.

La chaîne de récupération devient alors : Android démarre, le VPN Tailscale revient, Termux:Boot lance runit, puis runit relance les services et les health checks vérifient les chemins locaux et publics.

Termux lui-même prévient que les versions modernes d’Android peuvent tuer des processus trop nombreux ou trop gourmands. Ce n’est donc pas le guide universel du serveur fiable à installer chez vos parents.

C’est un exercice de réemploi où les limites du support comptent autant que les huit cœurs du téléphone.

PRoot fonctionne, jusqu’à ce que Chrome commence vraiment à travailler

Les applications de l’auteur existaient déjà sous forme d’images Linux ARM64. Il commence par les faire tourner dans un système Debian via PRoot.

PRoot intercepte des opérations en espace utilisateur pour donner à un processus l’impression qu’il vit dans un autre système de fichiers. C’est pratique parce qu’il n’exige pas de noyau particulier. Ce n’est pas une frontière de sécurité.

Pour les petits services web, ça suffit.

Pour Surf, son backend de navigateur distant avec Chrome, les accès aux bibliothèques, profils et fichiers traversent suffisamment la couche de traduction pour devenir coûteux. L’auteur roote alors le téléphone et utilise un vrai chroot vers le même système de fichiers Debian afin de retrouver des appels système natifs.

Là encore, le résultat n’est pas un Docker miniature. Les workloads partagent toujours le noyau et une grande partie du réseau Android. Les namespaces de montage servent surtout à rendre le montage et le nettoyage prévisibles.

La bonne abstraction ici n’est pas la plus pure. C’est celle qui enlève juste assez de friction au logiciel sans jeter le support matériel qui fonctionne déjà.

Le téléphone finit géré comme une vraie machine

Le détail qui empêche le projet de rester une pile de commandes copiées dans un terminal est Ansible.

Les versions des applications, leurs définitions de service, les routes, les réglages d’alimentation, les secrets et les health checks sont déclarés depuis un dépôt privé. Les artefacts sont épinglés par digest ou checksum, installés dans des répertoires versionnés derrière un lien current. Une vérification ratée bloque le déploiement ; revenir en arrière revient à restaurer le pin précédent.

Le téléphone n’a même pas besoin de Docker ni d’un compilateur pour recevoir les applications. Le poste de travail prépare les systèmes de fichiers ARM64 et Ansible déploie le résultat.

Les services web publics passent par Cloudflare Tunnel. L’administration passe par Tailscale. Comme les deux reposent sur des connexions sortantes, le serveur peut changer de réseau et retrouver ses chemins. La batterie intégrée devient au passage un petit onduleur capable de tenir pendant le déplacement.

Le smartphone était conçu pour exactement ce genre de problèmes : conserver une connexion malgré des réseaux qui changent et rester vivant quand le câble disparaît. On oublie simplement d’appeler ça une fonction serveur quand l’objet possède un écran tactile et des caméras.

Réutiliser la couche la plus ennuyeuse

Le projet ne dit pas qu’un téléphone est meilleur qu’un mini-PC. Il impose plus de contournements, utilise un Android rooté et demande des sauvegardes externes si les données comptent réellement.

Il montre autre chose : dans un détournement matériel, la meilleure pièce à réutiliser n’est pas toujours le processeur ou la batterie. Ça peut être toute la couche logicielle ingrate que quelqu’un a déjà passée des années à adapter au Wi-Fi, à l’énergie, au modem et au SoC exacts.

Le premier essai cherchait un serveur plus propre et a supprimé cette couche.

Le second accepte qu’Android reste responsable du téléphone. C’est à ce moment-là que le téléphone devient un serveur utilisable.