Qu'est-ce que le root ? Ce que l'accès root Android signifie vraiment

Rooter un téléphone Android, c'est obtenir l'accès superutilisateur, le compte que Linux appelle root, identifié par l'identifiant utilisateur 0 (UID 0). Android refuse normalement cet accès à toutes les applis, et à vous aussi. Une fois le téléphone rooté, vous, ou une appli que vous autorisez, pouvez faire ce que le bac à sable des applis interdit : lire les données d'autres applis, modifier des fichiers système, lancer des outils privilégiés.

Voici ce que la plupart des réponses courtes passent sous silence : le root n'est pas un interrupteur unique. C'est le résultat de l'ouverture d'une chaîne de protections qu'Android ferme volontairement, et la manière dont vous les ouvrez décide de ce que vous perdez. Le root diffère aussi du jailbreak iOS, du déverrouillage du bootloader et du désimlockage ; le tableau comparatif les distingue.

Si vous hésitez : le root vous donne du contrôle et vous coûte une partie des contrôles de sécurité d'Android. Il convient bien mieux à un téléphone de rechange, à un bidouilleur ou à une tâche qui exige le root qu'au seul téléphone qui contient vos applis bancaires, professionnelles et de paiement. Pour le verdict complet, lisez faut-il rooter votre Android.

Sources vérifiées le 5 novembre 2026 : documentation AOSP, documentation des projets Magisk, KernelSU et APatch, documentation Play Integrity de Google et texte de la réglementation fédérale américaine. Il s'agit d'un article explicatif fondé sur la documentation. DroidRooter n'a rooté ni testé aucun téléphone pour le rédiger, et il ne constitue pas un avis juridique.

Accès rapide : Ce que signifie rooter · Pourquoi Android bloque le root · Comment on obtient le root · Ce que le root permet et ne permet pas · Root, jailbreak et déverrouillage · Les coûts · Est-ce légal ? · Qui devrait rooter · Vérifier votre téléphone · Dépannage · FAQ

Que signifie « rooter » sur Android ?

Android repose sur le noyau Linux, et Linux possède un compte tout-puissant : root, UID 0. Sur un téléphone normal, rien de ce que vous installez ne s'exécute en root. Chaque appli reçoit son propre identifiant utilisateur sans privilège, et le système isole les applis les unes des autres et du système d'exploitation.¹

Si vous connaissez l'ordinateur, pensez à l'« Administrateur » de Windows ou à sudo sous Linux. L'analogie est utile mais incomplète : sur un ordinateur, l'accès administrateur est une fonctionnalité fournie d'origine, alors que sur Android le constructeur a supprimé cette porte volontairement et rooter revient à la reconstruire. Wikipédia, une source secondaire, décrit la même idée : un contrôle privilégié sur les sous-systèmes d'Android, comparable aux droits d'administrateur sur les systèmes de type Unix.¹⁷

Ce qu'est su et comment les applis demandent le root

Un téléphone rooté ajoute un programme su ainsi qu'une appli de gestion du root qui s'interpose entre su et chaque appli qui le demande. Magisk, KernelSU et APatch sont les trois gestionnaires en usage actuellement. Quand une appli demande le root, le gestionnaire vous interroge et retient votre réponse.

Les gestionnaires récents vont plus loin que le simple oui ou non. Le App Profile de KernelSU vous permet de restreindre ce que le shell root d'une appli autorisée peut faire : son uid, son gid, ses groupes, ses capacités et ses règles SELinux. La documentation présente cela comme le principe du moindre privilège.¹¹ Dire « cette appli a le root » ne désigne donc pas un niveau de puissance fixe, identique sur tous les téléphones rootés.

Pourquoi Android ne vous donne pas le root par défaut

Trois couches indépendantes tiennent le root hors de portée. Une méthode de root doit les franchir toutes, ce qui explique qu'elle tienne rarement en un clic.

Si vous voulez la version texte de l'image : les applis sont en haut dans des pièces scellées, SELinux est le couloir que tout processus doit emprunter, et Verified Boot est la porte de coffre en bas. Le root est un laissez-passer qui fait franchir à une seule appli approuvée une seule porte, pas un passe-partout.

Couche 1 : le bac à sable des applis

Android attribue à chaque appli un identifiant utilisateur unique et s'appuie sur le noyau Linux pour imposer la séparation, de sorte qu'une appli ne peut pas lire les données d'une autre ni utiliser des ressources protégées sans autorisation.¹ L'AOSP documente comment cela s'est renforcé : séparation SELinux des processus système et applicatifs dans Android 5.0, filtrage des appels système seccomp-bpf dans la 8.0, bacs à sable SELinux par appli pour les applis non privilégiées ciblant l'API 28 ou supérieure dans Android 9, et une vue limitée du système de fichiers brut dans Android 10.¹ Sur un appareil correctement configuré, dit l'AOSP, s'échapper exige de compromettre le noyau Linux, et il ajoute que ces protections ne sont pas invulnérables.¹ Cette réserve compte pour la suite : les méthodes de root par exploit existent précisément là où une faille du noyau existe.

Couche 2 : SELinux

Security-Enhanced Linux impose un contrôle d'accès obligatoire sur tous les processus, « même les processus exécutés avec les privilèges root/superutilisateur », et fonctionne sur le principe du refus par défaut. Android l'embarque en mode enforcing.²

Le fait que les lecteurs ratent le plus souvent : le root sur Android n'est pas le root tout-puissant d'une ancienne installation Linux de bureau. Un processus root doit toujours satisfaire la politique SELinux ; les outils de root embarquent donc leurs propres correctifs de politique, et Magisk documente magiskpolicy comme son outil pour cela.³

Couche 3 : Verified Boot et bootloader verrouillé

Verified Boot construit une chaîne de confiance depuis une racine de confiance protégée par le matériel, en passant par le bootloader jusqu'à la partition de démarrage et les autres partitions vérifiées, dont system et vendor. Chaque étape contrôle la suivante, et la protection contre le retour en arrière empêche un attaquant d'installer une version plus ancienne et vulnérable. Android Verified Boot (AVB) fait partie d'Android 8.0 et des versions supérieures.⁴

AVB rapporte le résultat sous forme d'état de démarrage. Selon la documentation d'AVB, le vert signifie que le bootloader est verrouillé et que la clé de vérification n'a pas été définie par l'utilisateur final, et le jaune qu'il est verrouillé avec une clé définie par l'utilisateur. L'orange signifie que le bootloader est déverrouillé.⁵

La plupart des appareils Android sont livrés avec un bootloader verrouillé, afin que personne ne puisse y charger un autre système ou une autre image de démarrage.⁶ Installer le root revient à charger une image de démarrage modifiée : le verrou est donc le premier mur que vous rencontrez.

Pourquoi le débogage USB seul ne donne jamais le root

La documentation de test de l'AOSP indique que adb root n'est pas disponible sur une build user (de production) ; il ne peut être activé sur un appareil en build user qu'avec un ramdisk de débogage et un bootloader déverrouillé.⁷ C'est une affirmation étroite issue d'une page de tests de conformité, à lire donc étroitement : sur un firmware commercial, adb root n'est pas un interrupteur caché universel.

Comment on obtient réellement le root

Il existe trois grandes voies. La première est de loin la plus courante.

Voie 1 : déverrouiller le bootloader et patcher l'image de démarrage

C'est la voie standard, celle que décrit la documentation de Magisk. Ce qui suit est une carte, pas un tutoriel ; les commandes et les notes par marque se trouvent dans le guide complet du root Android.

Avant l'étape 1 : le déverrouillage efface vos données. Le comportement de référence d'Android est de vous avertir puis de réinitialiser le téléphone aux paramètres d'usine quand vous déverrouillez le bootloader, et les constructeurs le suivent en pratique.⁶ Sauvegardez tout d'abord. Le déverrouillage fait aussi passer l'état de démarrage à orange et, chez certaines marques, active un indicateur permanent.

1. Vérifiez que votre téléphone peut être déverrouillé. Le chemin de base de l'AOSP est Paramètres → Système → Options pour les développeurs → Déverrouillage OEM. Fastboot refuse de déverrouiller si ce réglage n'est pas activé, et il peut être absent ou grisé sur les téléphones verrouillés par l'opérateur ou bloqués par le constructeur. Les noms de menus varient selon la marque.⁶
2. Déverrouillez le bootloader. La commande générique est fastboot flashing unlock ; l'appareil doit ensuite vous avertir et se réinitialiser.⁶ Des outils propres aux marques et des délais d'attente existent ; voir le guide de déverrouillage du bootloader.
3. Récupérez l'image d'origine pour votre build exacte. Magisk patche boot.img, init_boot.img ou vendor_boot.img selon l'appareil, ou recovery.img si l'appareil n'a pas de ramdisk de démarrage.⁸
4. Patchez-la sur votre propre téléphone avec l'option Install de l'appli Magisk. Magisk est catégorique : ne flashez jamais une image patchée partagée par d'autres, et ne patchez jamais une image sur un autre appareil.⁸ Une image de démarrage patchée s'exécute avant tout le reste ; celle d'un inconnu est donc du code non relu, avec les privilèges les plus élevés.
5. Flashez-la depuis le mode fastboot. Magisk documente un indicateur vbmeta facultatif (--disable-verity --disable-verification) et prévient qu'il peut effacer vos données.⁸
6. Redémarrez et ouvrez l'appli Magisk. Acceptez l'invite pour terminer la configuration (un redémarrage de plus). L'appli demande ensuite l'autorisation appli par appli.⁸

Samsung est différent. La documentation de Magisk indique que son installation active irréversiblement le bit de garantie Knox, que la première installation exige un effacement complet des données, et que vous ne pouvez plus recevoir les mises à jour OTA : vous patchez vous-même chaque nouveau firmware.⁸ La disponibilité du déverrouillage est aussi en mouvement : Wikipédia rapporte que Samsung a restreint le déverrouillage du bootloader dans le monde entier à partir de One UI 8, tandis que Magisk publie toujours des étapes pour Samsung et précise qu'une valeur OEM Lock absente en mode Téléchargement sur les appareils américains et canadiens signifie probablement que le téléphone n'est pas déverrouillable.¹⁷⁸ Les informations se contredisent : considérez que cela dépend du modèle, de la région et de la version de One UI. La liste des appareils rootables et le guide du root Samsung détaillent chaque modèle.

Voie 2 : les trois frameworks de root

Une fois le bootloader déverrouillé, vous choisissez un framework de root. Chacun traite le problème différemment.

Deux nuances : le statut « Unsupported » de KernelSU n'est pas définitif, puisque sa page renvoie vers une liste non officielle d'appareils pris en charge,¹⁰ et sur APatch CONFIG_KALLSYMS_ALL=n est indiqué comme « initial support », pas comme non pris en charge.¹² Pour le vrai duel, lisez Magisk vs KernelSU vs APatch. Les versions évoluent vite : consultez la page des releases de chaque projet plutôt qu'un numéro de version dans un article.

Voie 3 : root par exploit, limité à la session

Une petite catégorie de méthodes exploite une vulnérabilité sur des builds de firmware précises pour obtenir le root sans déverrouiller le bootloader. Elles sont liées à des modèles et builds exacts, ne durent généralement que jusqu'au redémarrage, et une mise à jour de sécurité peut les fermer. C'est une exception, pas une façon générale de contourner un bootloader verrouillé.

Méfiez-vous de tout APK de « root en un clic » qui promet de fonctionner sur tous les téléphones. Une méthode de root doit franchir les trois couches ci-dessus, et aucun fichier unique ne couvre honnêtement tous les modèles et toutes les builds. Un outil qui vous demande de flasher l'image patchée de quelqu'un d'autre enfreint la propre règle de Magisk.

Ce que vous pouvez faire avec le root, et ce que vous ne pouvez toujours pas

Pour les modules en particulier, voir le guide des modules Magisk.

Ce que le root ne fait pas

• Rendre le téléphone plus rapide à lui seul. Il lève une restriction ; la vitesse dépend de ce que vous modifiez.
• Désactiver SELinux. SELinux contraint aussi le root, c'est pourquoi les outils de root patchent la politique.²
• Désimlocker votre SIM d'un opérateur. C'est un verrou côté opérateur.
• Garantir que les applis bancaires fonctionneront. Les contrôles Play Integrity peuvent échouer sur un téléphone rooté (voir plus bas).
• Annuler un bit Knox activé. Sur Samsung, cet indicateur est permanent.⁸
• Remplacer le sideloading. Installer des APK n'exige pas le root ; voir les changements 2026 du sideloading sur Android.
• Contourner les verrous d'un téléphone qui ne vous appartient pas. Le root ne doit pas servir à contourner la protection contre la réinitialisation d'usine (FRP), un verrou opérateur ou un verrou de compte sur un appareil qui n'est pas le vôtre.

Root, jailbreak, déverrouillage du bootloader, ROM personnalisée et désimlockage

Le root change qui peut agir. Le déverrouillage du bootloader change ce que le téléphone accepte de démarrer. Une ROM personnalisée change ce que le téléphone exécute. Le reste du tableau en découle.

La ligne du jailbreak ne repose que sur des sources secondaires : lisez-la comme une définition, pas comme un mécanisme.

Les vrais coûts : ce que le root peut casser

Cette section doit orienter votre décision. Le traitement détaillé se trouve dans les risques du root Android.

Play Integrity, expliqué avec précision

Deux corrections au folklore habituel. D'abord, MEETS_BASIC_INTEGRITY et MEETS_STRONG_INTEGRITY sont des libellés à activer sur demande, et sur Android 13 et supérieur ils ne sont renvoyés qu'aux applis sous licence Google Play : toutes les applis ne voient donc pas tous les niveaux ni ne les demandent.¹³ Ensuite, MEETS_STRONG_INTEGRITY signifie intégrité de l'appareil plus des mises à jour de sécurité datant de moins d'un an pour toutes les partitions (système et vendor) : même un téléphone verrouillé et non modifié, resté un an sans mise à jour, peut donc échouer.¹³

Le verdict vide est documenté comme le signe d'une « attaque (comme le hooking d'API) ou d'une compromission du système (comme le fait d'être rooté) », ou d'un appareil qui n'est pas physique, comme un émulateur. La formule est « comme » ; elle ne dit pas que le root vide toujours le verdict.¹³ En pratique, les applis qui exigent l'intégrité de l'appareil peuvent refuser un téléphone rooté, et personne ne peut honnêtement promettre un succès. Le guide Play Integrity et root détaille cela, et l'attestation de clés expose les deux mêmes faits : si l'appareil est verrouillé et son état de démarrage vérifié.¹⁴

Mises à jour et anti-rollback

Une image de démarrage patchée remplace l'image d'origine : une OTA normale peut donc échouer à la vérification ; voir OTA échouée après le root. KernelSU prévient que les appareils récents peuvent avoir une protection anti-rollback liée au niveau de patch de sécurité : une image de démarrage à niveau de patch plus ancien peut donc provoquer un bootloop.¹⁰ Gardez une copie des images d'origine de votre build exacte avant de modifier quoi que ce soit.

Les affirmations sur Samsung Knox proviennent de la documentation de Magisk et n'ont pas été vérifiées dans un document Samsung. Pour les autres marques, le traitement de la garantie varie selon la marque et le pays, et aucune réponse universelle n'est avancée ici.

Bootloops et sécurité

Magisk dispose d'une protection contre les bootloops : si le démarrage n'aboutit pas deux fois de suite, il passe en mode sans échec et désactive les modules, et magisk --remove-modules fonctionne depuis adb shell.⁹ De nombreux bootloops sont récupérables ; « de nombreux » ne veut pas dire « tous », et c'est pourquoi la sauvegarde de l'image d'origine n'est pas facultative.

Le root élargit aussi le rayon d'impact de tout ce qui tourne mal. SELinux contraint toujours le root, mais les autorisations que vous accordez dans le gestionnaire de root deviennent la frontière de confiance. Le README d'APatch indique que sa SuperKey a des privilèges supérieurs au root : le secret qui la protège mérite donc des précautions.¹²

Le root est-il légal ?

Cela dépend de l'endroit où vous vivez. Cette section est de l'information, pas un avis juridique, et elle ne prétend pas que le root est ou n'est pas une infraction là où vous êtes. Les questions juridiques portent généralement sur les règles anti-contournement et sur ce que vous faites avec le root ; le piratage, le contournement des licences d'applis et la fraude sont des sujets distincts.

États-Unis (en novembre 2026, selon la règle de 2024). La section 1201 du DMCA interdit de contourner les contrôles d'accès, mais la Bibliothécaire du Congrès accorde des exemptions temporaires par périodes de trois ans ; la procédure du Copyright Office de 2024 était le neuvième cycle triennal.¹⁵ Le texte actuel du 37 CFR 201.40(b)(9) couvre les programmes informatiques sur les smartphones et les appareils mobiles polyvalents portables, lorsque le contournement vise à exécuter des applications logicielles obtenues légalement, à des fins d'interopérabilité, ou à supprimer des logiciels de l'appareil.¹⁶ Le texte n'emploie pas le mot « root ». L'exemption est généralement lue comme couvrant le root et le jailbreak, mais cette lecture est une interprétation. Trois limites en découlent :

• Elle est étroite et liée à un objectif, pas un droit général de faire n'importe quoi avec le root.
• Elle est temporaire. Le prochain cycle triennal, attendu en 2027, pourrait la modifier.
• Elle ne concerne que la règle anti-contournement du DMCA. La même section précise que les exemptions ne protègent pas de la responsabilité au titre d'autres lois applicables et ne constituent pas un moyen de défense.¹⁶

Ailleurs. L'UE, le Royaume-Uni, l'Australie et le Canada adoptent des approches variées. Le résumé de Wikipédia mentionne des transpositions nationales différentes de la directive européenne sur le droit d'auteur de 2001, et un argument de la Free Software Foundation Europe selon lequel remplacer un système d'exploitation n'annule pas à lui seul une garantie légale.¹⁷ C'est une position, pas du droit, et rien de tout cela n'a été vérifié dans la législation primaire.

Il n'existe pas de titre honnête du type « le root est légal partout ». Si cela compte dans votre situation, interrogez un professionnel qualifié dans votre pays.

Qui devrait rooter, et qui ne devrait pas

Pour le verdict complet, utilisez faut-il rooter votre Android.

Vérifiez d'abord votre modèle exact. Le vérificateur de rootabilité est une consultation des voies de root documentées, pas une garantie pour votre build, et la liste des appareils rootables vous aide si vous choisissez un appareil.

Comment savoir si un téléphone est rooté, et si le vôtre peut l'être

1. Est-il rooté ? Ouvrez l'appli de gestion du root si une est installée. Ou, avec le débogage USB activé et ADB autorisé, lancez adb shell su -c id ; un téléphone qui accorde le root au shell renvoie uid=0(root). Si su est introuvable ou si la demande est refusée, le shell n'a pas le root.
2. État du bootloader. Activez les Options pour les développeurs (Paramètres → À propos du téléphone, appuyez sept fois sur Numéro de build), puis ouvrez Paramètres → Système → Options pour les développeurs → Déverrouillage OEM. Grisé signifie en général un verrou de l'opérateur ou du constructeur, ou que le déverrouillage n'est pas autorisé. Les noms de menus varient selon la marque ; le chemin de l'AOSP sert de référence.⁶
3. Couleur du démarrage vérifié. Le vert et le jaune signifient un bootloader verrouillé, l'orange un bootloader déverrouillé.⁵ De nombreux téléphones affichent un avertissement au démarrage lorsqu'ils sont déverrouillés ; son aspect varie selon la marque.
4. Samsung. La documentation de Magisk renvoie au mode Maintenance (Paramètres → Entretien de l'appareil → Mode Maintenance), puis à la ligne OEM Lock en mode Téléchargement : ON (L), ON (U) ou OFF (U). La combinaison de touches dépend du modèle.⁸
5. Play Integrity. Des applis de vérification existent ; aucune n'est recommandée ici car aucune n'a été vérifiée.

Matrice de dépannage : quand l'idée rencontre le vrai téléphone

En résumé

Rooter signifie obtenir l'accès superutilisateur (UID 0) sur Android, que le système bloque avec un bac à sable des applis, SELinux et Verified Boot. Sur la plupart des téléphones, la chaîne est : déverrouiller le bootloader (ce qui efface le téléphone), patcher une image de démarrage ou un noyau, installer un gestionnaire de root et approuver les applis une par une. Les coûts sont Play Integrity et les applis bancaires, les mises à jour, le bit Knox de Samsung, une exposition plus large en matière de sécurité et des questions juridiques et de politique qui dépendent de l'endroit où vous vivez.

Vous hésitez encore ? Commencez par faut-il rooter votre Android. Décidé ? Passez au guide complet du root et vérifiez d'abord votre modèle exact. Si un flash échoue ou si le téléphone tourne en boucle, cessez de répéter le flash et cherchez une voie de sauvetage avant de modifier quoi que ce soit d'autre.

Besoin d'un coup de main pour rooter votre téléphone ? Notre service de root Android est un examen à distance, vérifié sur l'appareil, de votre propre téléphone : nous vérifions le modèle exact, la région, le firmware, l'état du bootloader et le risque pour vos données avant de recommander quoi que ce soit. Certains téléphones ne peuvent pas être rootés, et nous vous le dirons plutôt que d'essayer un fichier générique. Aucune promesse n'est faite concernant les applis bancaires, Play Integrity, les mises à jour ou la garantie, et nous ne contournons ni les contrôles de propriété, ni les verrous de compte, ni les verrous opérateur.

Sources et documentation du projet