Choisir un smartphone ne se limite plus à l’écran, la caméra, la batterie, le stockage et la durée des mises à jour. La discussion autour d’Android 17 ajoute une question plus concrète : une fois l’appareil acheté, pouvez-vous retirer les applications préinstallées que vous n’avez jamais demandées ?

Smartphone générique avec applications préinstallées, bouton de désinstallation bloqué et outils ADB pour contrôler le bloatware

Le signal vient de discussions techniques, mais l’enjeu est très grand public. Sur Hacker News, des utilisateurs ont relayé des rapports d’outils de debloating : sur des builds Android 17 sans root, adb shell pm uninstall -k --user 0 <package> peut échouer pour les applications système avec Failure [only root can delete system app for a particular user]. Universal Android Debloater Next Generation et SmartPack PackageManager discutent du même comportement, et le code Android cité contient cette chaîne d’erreur.

Pendant des années, ADB a servi de compromis. La commande ne supprimait pas vraiment l’APK de la partition système protégée ; avec --user 0, elle retirait le paquet pour le profil principal. Ce n’était pas une libération totale du téléphone, mais cela suffisait souvent pour enlever des applications opérateur, boutiques en double, jeux, services publicitaires ou outils constructeur inutiles.

Si Android 17 limite cette voie sans root, l’option restante devient surtout la désactivation ou le gel, quand le paquet et le fabricant l’autorisent. C’est plus réversible, souvent plus sûr, mais moins proche d’un vrai contrôle propriétaire.

Désactiver n’est pas désinstaller

adb shell pm disable-user com.example.package garde le paquet dans le système, mais le désactive pour l’utilisateur. L’application peut disparaître du lanceur et cesser de gêner. Le retour arrière est simple avec adb shell pm enable com.example.package. Pour beaucoup d’utilisateurs, c’est plus raisonnable que des suppressions en série.

La limite est claire : certains paquets ne sont pas désactivables, certains fabricants les réactivent après mise à jour, et le gain de stockage reste limité sur un téléphone verrouillé. Pour les utilisateurs attachés à la vie privée ou au minimalisme, un composant commercial toujours présent dans l’image système reste frustrant.

Ce que cela change à l’achat

Un téléphone Android peu cher peut avoir une bonne fiche technique et un vrai coût caché : applications partenaires, services constructeur, doublons, notifications et bootloader verrouillé. À l’inverse, un modèle avec communauté active, documentation claire et bootloader déverrouillable laisse plus de marge.

L’argument de sécurité existe. Des composants système peuvent porter WebView, paiements, appareil photo, alertes d’urgence, services opérateur, accessibilité ou mises à jour. De mauvaises listes de debloat cassent parfois des fonctions essentielles. Les mainteneurs d’outils ont donc raison de préférer une méthode réversible par défaut.

Mais la confiance dépend de ce qui est protégé. Quand le même mur protège les services critiques et des applications commerciales non souhaitées, l’utilisateur y voit moins une protection qu’une limite imposée après l’achat.

Le bon réflexe

Avant Android 17, sauvegardez la liste des paquets avec adb shell pm list packages > packages-before.txt. Ne lancez pas un vieux script sans lire les notes récentes de Universal Android Debloater NG, SmartPack, Canta, Hail ou des outils Shizuku. Désactivez une application à la fois, redémarrez, testez appels, notifications, caméra, paiement, cartes, Bluetooth et services importants.

Avant d’acheter, vérifiez la réputation de la marque en matière de bloatware, la possibilité de déverrouiller le bootloader, les options de désactivation dans les Réglages, le comportement après OTA et l’existence d’une communauté active. En 2026, la propriété d’un smartphone ne se mesure pas seulement en mégapixels. Elle se mesure aussi à la liberté de contrôler le logiciel préinstallé.