Accueil/Téléphones sous Linux

Téléphones sous Linux : ce que ce choix change vraiment

Un téléphone fonctionnant sous un système Linux mobile n'est pas simplement « un Android sans Google ». C'est un changement de modèle plus profond, dans la continuité directe de ce qui distingue Linux des systèmes fermés sur le plan de la sécurité : moins de télémétrie collectée par défaut, un modèle de permissions plus strict entre les applications, et une dépendance réduite aux services propriétaires qui, sur un téléphone classique, tournent avec des privilèges rarement audités par l'utilisateur.

Android et iOS : deux écosystèmes fermés malgré leurs différences

Android repose sur un noyau Linux, mais la couche applicative qui l'entoure — services propriétaires, télémétrie intégrée au système, dépendance à un compte associé à l'ensemble des applications installées — s'écarte largement des principes qui font la spécificité de Linux sur le poste de travail. iOS, de son côté, ne partage même pas cette base technique et fonctionne selon un modèle entièrement fermé, où l'audit indépendant du code reste impossible par construction.

Dans les deux cas, une part significative des données collectées ne sert pas directement à la fonction annoncée de l'application, mais à des usages secondaires — publicité ciblée, analyse comportementale, revente à des tiers dans certains cas documentés. Cette collecte n'est pas illégale en soi ; elle est simplement rarement visible pour l'utilisateur au moment où elle a lieu, faute d'un mécanisme clair pour l'observer.

Ce qu'un système mobile basé sur Linux change concrètement

Un système mobile construit sur une base Linux plus proche du noyau standard, sans les couches propriétaires ajoutées par les grands éditeurs, réduit d'abord le nombre de processus qui tournent en arrière-plan sans action explicite de l'utilisateur. Chaque processus supprimé est une source de télémétrie potentielle en moins, et une surface d'attaque en moins.

Le modèle de permissions y est généralement plus granulaire : une application peut se voir accorder l'accès au réseau sans accès simultané à la géolocalisation, ou l'accès au microphone sans accès à la liste de contacts, avec une notification claire à chaque sollicitation plutôt qu'une autorisation globale accordée une fois à l'installation. Ce niveau de granularité existe en théorie sur Android récent, mais reste souvent contourné par des permissions groupées ou des justifications peu vérifiables fournies par l'application elle-même.

Le matériel, une contrainte à part entière

La compatibilité matérielle reste le principal obstacle pratique à l'adoption d'un système mobile Linux. Les pilotes pour les composants radio (modem, Wi-Fi, Bluetooth), souvent fournis sous forme de blobs binaires propriétaires par le fabricant du composant, ne sont disponibles que pour un nombre restreint d'appareils, généralement ceux conçus dès l'origine avec ce type d'usage en tête plutôt que des téléphones grand public reconvertis après coup.

Cette contrainte matérielle a une conséquence directe sur la sécurité elle-même : un appareil dont le firmware radio reste propriétaire et non audité conserve, quel que soit le système d'exploitation installé par-dessus, une composante qui échappe à l'examen ouvert du code. La rigueur obtenue au niveau logiciel ne s'étend pas automatiquement au firmware bas niveau, une nuance souvent absente des comparatifs qui se limitent à la couche applicative visible.

La séparation entre modem et système, un principe de sécurité en soi

Certains appareils pensés pour la confidentialité isolent physiquement ou logiquement le modem cellulaire du reste du système, de sorte qu'une compromission du firmware radio — dont le code reste, comme évoqué plus haut, largement fermé — ne donne pas automatiquement accès au système d'exploitation principal et à ses données. Cette architecture répond à une menace précise : le modem est un point d'entrée réseau permanent, actif même lorsque l'écran est éteint, et donc une cible privilégiée pour une interception qui ne dépend d'aucune action de l'utilisateur.

Un interrupteur matériel coupant physiquement le microphone, la caméra ou la radio — plutôt qu'un simple réglage logiciel désactivable à distance par un logiciel malveillant suffisamment privilégié — prolonge cette même logique : une garantie physique résiste à une compromission logicielle, là où un réglage purement logiciel n'y résiste pas par définition.

La provenance des applications, un facteur souvent oublié

Sur les écosystèmes propriétaires classiques, l'installation passe presque toujours par un magasin d'applications centralisé, contrôlé par l'éditeur du système, qui impose ses propres critères d'acceptation — pas nécessairement liés à la protection des données de l'utilisateur, mais souvent orientés vers la viabilité commerciale de la plateforme elle-même. Une application peut y collecter une quantité importante de données tout en respectant strictement les règles du magasin qui l'héberge.

Les dépôts associés aux systèmes mobiles Linux, ou aux magasins alternatifs orientés logiciel libre, appliquent des critères différents : code source disponible et vérifiable, absence de bibliothèques de traçage publicitaire tierces, description explicite des permissions réellement utilisées plutôt qu'accordées en bloc. Cette différence de gouvernance ne garantit pas qu'une application donnée soit irréprochable, mais elle change la nature du contrôle exercé en amont, avant même que l'utilisateur n'installe quoi que ce soit.

La durée de support, un facteur matériel autant que logiciel

Un téléphone grand public reçoit, dans la plupart des cas, des mises à jour de sécurité garanties pendant une durée fixée par le fabricant — généralement entre deux et cinq ans selon le segment de gamme — après laquelle l'appareil continue de fonctionner mais accumule des vulnérabilités connues et non corrigées. Cette limite n'est pas de nature technique : le matériel reste capable de faire tourner un système à jour, mais le fabricant cesse de publier les correctifs pour des raisons commerciales.

Les projets communautaires à l'origine de certains systèmes mobiles Linux ne sont pas soumis à cette même contrainte de rentabilité par appareil : le support d'un modèle donné peut se prolonger tant qu'une communauté de mainteneurs continue à s'y intéresser, indépendamment d'un calendrier commercial fixé à l'avance. Ce n'est pas une garantie automatique de support plus long — certains projets communautaires s'arrêtent aussi, parfois plus brutalement qu'un calendrier constructeur annoncé à l'avance — mais la logique sous-jacente diffère sensiblement de celle d'un fabricant qui a intérêt à ce que l'appareil soit renouvelé.

Ce que ce choix ne résout pas

Cette limite rejoint directement la question du chiffrement des correspondances : un téléphone qui collecte peu de télémétrie au niveau système n'apporte rien si les messages échangés dessus restent lisibles en clair par un intermédiaire, ce que couvre le chiffrement des e-mails pour la correspondance écrite, et ce que le choix d'une application de messagerie chiffrée de bout en bout couvre pour les échanges instantanés.

Un choix qui dépend du niveau de menace réel

Pour un usage courant, la friction supplémentaire d'un système mobile Linux — compatibilité matérielle réduite, écosystème applicatif plus restreint, certaines fonctionnalités bancaires ou administratives parfois indisponibles faute de prise en charge officielle — n'est pas toujours justifiée par le niveau de menace réel auquel l'utilisateur fait face. Pour un usage exposé à un risque précis et identifié, la réduction de la télémétrie et le contrôle matériel qu'offre ce type d'appareil représentent un gain mesurable, comparable dans sa logique à ce qu'apporte une distribution de bureau durcie face à une installation par défaut.

Le point commun entre ces choix, sur poste fixe comme sur mobile, reste le même : la sécurité gagnée dépend moins du système choisi en soi que de la cohérence avec laquelle il est configuré et maintenu dans le temps.