Meilleurs modules Magisk en 2026 : sources vérifiées et modules abandonnés

Plusieurs modules qui figurent encore sur les listes actuelles n'existent plus. Play Integrity Fix a été supprimé de GitHub par son auteur. Universal SafetyNet Fix a connu sa dernière sortie en janvier 2023. Et l'étape « installer depuis le dépôt en ligne de l'application Magisk » décrite dans la plupart des guides correspond à une fonctionnalité retirée de Magisk il y a des années. Chaque projet ci-dessous a été vérifié par rapport à son propre dépôt avant d'être ajouté à la liste, et chacun dispose d'un lien.

Dernière vérification technique : 30 octobre 2026
Référence Magisk : v31.1 (sortie le 25 octobre 2026)
Couvre aussi : KernelSU, KernelSU Next, SukiSU Ultra et APatch
Couverture Android : 12 à 17, les versions plus récentes n'étant notées que lorsqu'un projet les prend explicitement en charge
Mis à jour le 30 octobre 2026 : Magisk 31.0 et 31.1 (nouvelle application, plus de pop-ups de root, masquage de l'application supprimé), versions actuelles de chaque gestionnaire de root et implémentation Zygisk, alternatives open source à Tricky Store, et plusieurs modules désormais archivés ou obsolètes
Règle de sourcing : uniquement des liens officiels de mainteneurs. Nous ne miroitons pas les ZIP de modules

Commencez ici : la version courte

La plupart des gens veulent l'une de ces quatre choses. Vous n'avez pas besoin de toute la liste.

Tout ce qui suit détaille ces quatre points, plus ce qu'il faut éviter.

Ce qui a changé, et ce qu'il faut retirer

Si vous suivez un guide plus ancien, vous êtes peut-être sur le point d'installer quelque chose qui n'existe plus.

Cette dernière ligne cause le plus de confusion. Les gens ouvrent Magisk en cherchant l'onglet de téléchargement de modules qu'un vieux guide décrit, ne le trouvent pas, et pensent que leur installation est cassée. Ce n'est pas le cas. La découverte et l'installation sont désormais deux étapes séparées : trouvez le module sur GitHub, téléchargez le ZIP, installez-le depuis le stockage.

Plusieurs « modules » populaires n'en sont pas

Cela compte car cela change où vous récupérez la chose et comment vous la réparez quand elle se comporte mal.

Tous ces éléments valent la peine d'être utilisés. Aucun d'eux ne se flashe. Un guide qui liste AdAway entre deux modules Zygisk enseigne une erreur de catégorie, et les lecteurs qui partent ensuite chercher un « ZIP AdAway » finissent exactement sur le genre de site miroir dont cet article essaie de les éloigner.

Ce qui a changé dans Magisk 31.0 et 31.1

Magisk 31.1 est la version stable actuelle (25 octobre 2026), et elle change le comportement quotidien de Magisk. La plupart des anciens guides, y compris les versions précédentes de celui-ci, décrivent l'ancien flux. D'après les notes de version officielles :

Les demandes de root n'apparaissent plus. L'accès superutilisateur est désormais accordé aux applications à l'avance, depuis l'onglet Superuser de l'application Magisk. Si une application de terminal, un outil de sauvegarde ou un module dit avoir besoin du root et que rien n'apparaît à l'écran, ouvrez Superuser et accordez-le là d'abord. Il en va de même pour adb shell, qui n'a pas d'application au premier plan pour afficher une invite. L'équipe Magisk affirme que l'ancienne invite réactive ne peut pas fonctionner sur les appareils HSUM.

Le masquage de l'application Magisk a disparu. La fonctionnalité de repackaging (renommer le gestionnaire avec un nom de paquet aléatoire) a été supprimée, et Magisk ne réinstalle plus son application si elle est absente. L'avis du développeur lui-même est sans détour : masquer réellement un paquet installé est quasiment impossible sur Android, donc une fois vos règles Superuser et vos modules configurés, le moyen le plus efficace de masquer l'application Magisk est de la désinstaller. Les applications qui cherchent le gestionnaire sont une raison de plus de s'appuyer sur la DenyList et les étapes de dissimulation ci-dessous plutôt que sur le nom de l'application.

Avant de mettre à jour un téléphone qui fonctionne, notez votre version actuelle, capturez une copie d'écran de la liste Superuser, et conservez l'image boot stock de votre build. Les téléphones Android 6.0 restent sur la 30.7.

Quel gestionnaire de root utilisez-vous ?

Magisk n'est plus la seule option, et celui que vous utilisez détermine ce que vous pouvez installer. Les modules sont globalement portables, mais pas entièrement.

Deux choses se trompent souvent ici.

Vous ne pouvez pas en faire tourner deux à la fois. Retirez complètement l'un, restaurez l'image stock correspondante, puis installez l'autre. Avoir les deux actifs en même temps crée un conflit.

Les forks de KernelSU ne sont pas interchangeables. KernelSU, KernelSU Next et SukiSU Ultra partagent des idées mais leurs gestionnaires et leurs modifications de kernel diffèrent. Utilisez le build conçu pour le fork que vous avez réellement installé.

Une remarque sur Magisk Alpha : c'est un build non officiel distribué principalement via Telegram. Il a ses adeptes, mais ses sources publiques et son historique de releases sont moins solides que ceux de Magisk officiel, ce qui compte pour quelque chose qui tourne en root. La version stable officielle est plus facile à vérifier. ReZygisk, par exemple, a retiré la prise en charge de Magisk Alpha dans sa v1.0.0.

Ce qui fonctionne sur quoi

La ligne qui compte le plus est SUSFS. Elle se dissimule à l'intérieur du kernel plutôt qu'en espace utilisateur, ce que les modules en espace utilisateur ne peuvent structurellement pas égaler, et cela ne fonctionne pas avec Magisk car Magisk ne touche jamais au kernel. C'est le principal argument technique pour quitter Magisk en 2026, et cela nécessite un appareil avec un kernel compatible, ce que tous les appareils n'ont pas. Notre comparatif Magisk vs KernelSU vs APatch traite correctement ce compromis.

Tout dans cet article fonctionne sur Magisk. Là où quelque chose est réservé à une famille, c'est précisé.

Avant d'installer quoi que ce soit

Capturez une copie d'écran de vos modules actuels. Ouvrez votre gestionnaire de root, allez dans l'onglet Modules, capturez la liste. C'est votre trace de ce qui a changé si quelque chose casse. Cinq secondes, aucun terminal nécessaire.

Notez votre version de Magisk et votre build Android pendant que vous y êtes. Magisk affiche sa version sur l'écran d'accueil. La version d'Android et le correctif de sécurité se trouvent dans Paramètres, sous À propos du téléphone.

Un module à la fois, puis redémarrez, puis vérifiez que ça a marché. Installez-en cinq et redémarrez une seule fois, et vous n'avez aucune idée duquel a cassé le système.

Sachez comment récupérer avant d'en avoir besoin. C'est à la fin de cet article. Lisez-le d'abord.

Étape 1 : choisissez une implémentation Zygisk

Zygisk est la couche d'injection dont dépendent les modules de dissimulation et le framework Xposed. Magisk en intègre une. KernelSU et APatch n'en ont pas, ces utilisateurs ont donc besoin d'une implémentation autonome. Les utilisateurs de Magisk peuvent eux aussi choisir une implémentation autonome plutôt que celle intégrée.

Trois règles qui, ensemble, évitent la plupart des pannes dont on vous parle :

Faites-en tourner exactement une. Si vous installez une implémentation autonome sur Magisk, désactivez d'abord le Zygisk intégré. Faire tourner les deux est une panne fréquente et évitable.

Shamiko ne fonctionne pas avec ReZygisk. Shamiko cible le Zygisk intégré et Zygisk Next. Si vous choisissez ReZygisk, il vous faut un autre module de dissimulation. Les mélanger est la cause classique du « ma dissimulation marchait hier et s'est arrêtée aujourd'hui ». Idem pour Zygisk Assistant.

Désinstallez l'ancien avant de changer. Migrer sans retirer le module précédent d'abord a provoqué des bootloops, en particulier lors des changements d'ID de module.

Le changement de licence de Zygisk Next mérite une décision délibérée plutôt qu'un choix par défaut. C'est un module exécuté avec les privilèges root dont les releases récentes ne peuvent pas être auditées indépendamment, et c'est la raison invoquée pour l'existence de ReZygisk. Que cela compte pour vous est un jugement personnel, pas un défaut technique.

Étape 2 : intégrité et dissimulation, comme un arbre de décision

La correction la plus importante par rapport à la version précédente de ce guide :

Réussir Play Integrity et dissimuler le root à une application sont deux problèmes différents.

Les utilisateurs obtiennent régulièrement tous les verdicts d'intégrité et pourtant Google Wallet ou une banque spécifique refuse quand même l'appareil, car certaines applications regardent des signaux allant au-delà de l'API Play Integrity. Installer toute la pile parce qu'un guide l'a qualifiée d'essentielle, c'est la façon dont les gens finissent avec six modules alors que deux auraient suffi.

Traitez cela comme un arbre. Testez après chaque étape.

Commencez par la DenyList. Intégrée à Magisk, aucun téléchargement nécessaire. Ajoutez les applications auxquelles vous voulez cacher le root. De nombreuses applications arrêtent de se plaindre à cette étape et c'est terminé. Magisk 31.0 a aussi ajouté webview_zygote comme cible de démontage pour la DenyList.

Toujours détecté ? Ajoutez un module de dissimulation. Shamiko, depuis la distribution de releases de LSPosed, v1.2.5 depuis juin 2025 avec des correctifs pour Android 16 et les pages 16K, et aucune release plus récente au 30 octobre 2026. Notez l'exigence contre-intuitive : Shamiko a besoin que l'application de la DenyList soit désactivée tandis que la liste elle-même reste peuplée. Laisser l'application activée désactive Shamiko. C'est la mauvaise configuration la plus fréquente de tout cet article. Sur KernelSU avec un kernel SUSFS, vous n'avez souvent pas du tout besoin de Shamiko, car le kernel fait déjà ce travail.

Vous échouez un verdict d'intégrité spécifiquement ? Ajoutez un module Play Integrity. osm0sis/PlayIntegrityFork, v18 depuis août 2026, est la continuation directe de l'original abandonné et le successeur que son propre auteur a recommandé. KOWX712/PlayIntegrityFix est un autre fork maintenu de la même lignée, v4.9 en octobre 2026. N'installez pas deux forks de PIF à la fois.

Seulement avec une exigence concrète d'attestation de clé, envisagez Tricky Store. 5ec1cff/TrickyStore, Android 10+. Des forks par beakthoven et qwq233 circulent aussi et sont désormais ceux que plusieurs projets d'outillage ciblent.

Pour gérer les applications auxquelles il s'applique : KOWX712/Tricky-Addon-Update-Target-List donne à Tricky Store une vraie interface pour sa liste cible, son keybox et la gestion du correctif de sécurité. C'est un projet séparé et son auteur demande que les problèmes ne soient pas signalés en amont.

Des alternatives open source à Tricky Store existent désormais. beakthoven/TrickyStoreOSS est une réécriture sous licence GPL-3.0 (v3.1.0, août 2026). JingMatrix/TEESimulator est un KeyMint logiciel sous GPL-3.0 qui tourne dans le démon keystore (v4.0, août 2026, Android 10+, appareils 64 bits uniquement). qwq233/OhMyKeymint est une réimplémentation complète du keystore qui vise à ressembler davantage à l'AOSP stock (Android 12+, builds de prévisualisation). Faites-en tourner exactement un. Aucun d'eux ne fournit de keybox fonctionnel, et nous ne pointons toujours vers aucun.

Trois choses que les autres guides ne vous disent pas

Tricky Store est fermé depuis la v1.1.0. Le mainteneur l'a fermé pour des raisons d'abus. Avec le changement de licence de Zygisk Next, les deux outils les plus puissants de cette catégorie sont désormais tous deux des binaires non auditables tournant en root. Sa dernière release était la 1.4.1 en novembre 2025. Bon à savoir avant de l'installer, pas après. Des réécritures open source existent désormais, listées juste en dessous, bien qu'elles soient plus récentes et moins éprouvées.

Tricky Store ne fournit pas de keybox fonctionnel. Il fournit un keybox AOSP qui n'est pas valide pour l'attestation. Les guides disant « installez Tricky Store, obtenez une forte intégrité » passent totalement cela sous silence. Les keybox finissent aussi par être révoqués, et votre configuration s'arrête alors silencieusement de fonctionner. Nous ne distribuons pas de keybox et nous serions prudents envers quiconque le fait.

L'intégrité logicielle des appareils est devenue bien plus difficile en 2026. Une large vague d'empreintes d'appareils a été bloquée en début d'année, et le principal dépôt communautaire qui maintenait cette collection a été archivé par son propriétaire, qui a déclaré qu'il ne restait plus d'empreintes fonctionnelles pour les combinaisons d'architectures les plus courantes. Les approches par empreinte n'ont pas cessé de fonctionner, mais l'offre n'est plus ce qu'elle était.

Le constat honnête : les verdicts basiques restent globalement atteignables, l'intégrité de l'appareil demande plus de travail qu'avant, et une forte intégrité sur un bootloader déverrouillé est réellement difficile. Certaines applications refusent quoi qu'il arrive. Nous ne publions pas de taux de réussite, car il serait faux en quelques semaines.

Vous voulez que ce soit configuré une bonne fois pour toutes, correctement, au lieu de tester des combinaisons pendant une semaine ? Envoyez-nous votre appareil, votre version d'Android, votre méthode de root et les applications dont vous avez besoin. Nous le configurons à distance et vous disons dès le départ lesquelles de vos applications sont réalistement atteignables. Diagnostic gratuit sur le service de root.

Si vous avez besoin d'aide

Le comportement de l'intégrité change constamment, donc « cette pile fonctionne-t-elle avec ma banque » est sans réponse sans détails. Si vous demandez à qui que ce soit, nous y compris, envoyez ceci :

Appareil et modèle exact :
Version Android et build :
Niveau de correctif de sécurité :
Gestionnaire de root et version :
Implémentation Zygisk :
Modules installés, avec versions :
Verdict Play Integrity :
Application et version qui échoue :
Ce qu'elle affiche exactement :

Cela transforme une question à laquelle personne ne peut répondre en une question à laquelle quelqu'un peut répondre. Nous avons retiré les anecdotes anonymes de compatibilité d'applications de la version précédente de ce guide pour la même raison : elles n'avaient aucun de ces détails, donc elles n'étaient pas reproductibles.

Étape 3 : la couche Xposed

Le projet LSPosed original n'a plus de release depuis octobre 2023 ni de commit sur master depuis janvier 2024, et ses releases ciblaient Android 8.1 à 14. Mauvais point de départ sur un appareil moderne.

JingMatrix/LSPosed est le fork maintenu que la plupart des gens utilisent, et il vit désormais dans le dépôt JingMatrix/Vector (l'ancienne URL y redirige). Vector conserve la cohérence d'API avec le Xposed original tout en réécrivant l'interne, avec une prise en charge jusqu'à Android 16 et 17 et les appareils à pages 16K. Ses releases sont actuellement publiées comme des builds canary pré-release (canary-3114 le 26 octobre 2026), pas des versions stables étiquetées, donc lisez les notes de version avant de mettre à jour.

JingMatrix/LSPatch est la voie sans root (builds canary, comme Vector). Il intègre le framework dans une application en patchant l'APK de cette application. Pas de root, pas de Zygisk. Bon à savoir si vous voulez le comportement d'un seul module Xposed et rien d'autre.

ReLSPosed, un autre fork qui a circulé, a été archivé par son propriétaire en février 2026. Vérifiez les dates avant de faire confiance à un fork.

Hide My Applist (Dr-TSNG/Hide-My-Applist) intercepte le scan de la liste d'applications, que certaines applications utilisent pour repérer les gestionnaires de root. Le développement a été suspendu un moment, mais il a livré la v3.8.3 en août 2026. Considérez-le comme maintenu de façon ponctuelle et vérifiez la date de release avant de vous y fier.

Les modules Xposed eux-mêmes ont le même problème. Un module non touché depuis deux ans a peu de chances de fonctionner sur Android 15 ou 16, quoi qu'en dise son fil de discussion.

Étape 4 : la liste vérifiée

Regroupée par ce que vous voudriez réellement. Chaque lien pointe vers le dépôt du mainteneur lui-même. Tout fonctionne sur Magisk sauf mention contraire.

Blocage des publicités et des traceurs

Faites tourner exactement un bloqueur hosts. Deux, ou un plus le mode root d'AdAway, c'est deux choses qui se disputent le même fichier. Les listes agressives cassent aussi des fonctionnalités légitimes d'applications, donc commencez par un profil standard et n'en ajoutez que si vous rencontrez un problème précis.

Pour fixer les attentes : le blocage hosts arrête les résolutions de domaine. Il ne fait rien contre les publicités servies depuis le même domaine que le contenu. Le réglage DNS privé d'Android obtient une grande partie du même résultat sans aucun root.

Batterie et alimentation

ACC est le remplaçant honnête des entrées vagues de « gestion de la batterie » qui apparaissent sur la plupart des listes sans dépôt associé. Utilisez son propre outillage de détection plutôt que de copier l'interrupteur de charge d'un autre téléphone.

Jeu et ordonnancement

Configurez par jeu plutôt que globalement. Les gains dépendent de l'appareil, du kernel et du jeu, et les vidéos de démonstration les exagèrent. Ne le superposez pas avec un autre module d'ordonnancement.

Interface et thèmes

Appliquez un groupe de changements à la fois. Les plantages de SystemUI et les bootloops après des combinaisons ROM/mise à jour non prises en charge sont un schéma connu avec les modules de thème. Annulez les overlays avant une mise à jour système majeure.

Utilitaires

Développement et tests de sécurité

Ces modules élargissent la frontière de confiance de votre appareil. Ils existent pour le débogage de trafic et la recherche en sécurité, et sont une mauvaise idée sur un appareil quotidien. Retirez les CA de test une fois le travail terminé. Aucun des deux ne contourne le certificate pinning.

Boîtes à outils d'intégrité alternatives

Integrity-Box (MeowDump/Integrity-Box) regroupe la gestion de l'intégrité et de l'environnement derrière sa propre interface. PlayIntegrityFix-NEXT (EricInacio01/PlayIntegrityFix-NEXT) était un fork expérimental couvrant Android 10 à 16. Son propriétaire l'a archivé en octobre 2025 après la release v3.0, ne bâtissez donc pas une nouvelle installation dessus. Integrity-Box sort très fréquemment (v46 le 29 octobre 2026), ce qui a deux revers : des corrections rapides, et une cible mouvante.

Les deux se chevauchent avec PlayIntegrityFork. Traitez-les comme des piles alternatives, pas des ajouts. Des outils d'intégrité qui se chevauchent créent des conflits misérables à diagnostiquer.

Dissimulation au niveau kernel, famille KernelSU uniquement

SUSFS vit sur gitlab.com/simonpunk/susfs4ksu avec un module compagnon sur sidex15/susfs4ksu-module. Il nécessite un kernel avec SUSFS patché, c'est donc une option pour KernelSU, KernelSU Next ou SukiSU Ultra. Non disponible sur Magisk ou APatch.

Niveaux de risque

Tous les modules ne présentent pas la même exposition.

Où trouver les modules maintenant

Puisque le dépôt intégré a disparu :

1. La page des releases GitHub du projet lui-même. La source correcte pour tout ce qui précède, et celle vers laquelle pointe chaque lien de cet article. Téléchargez l'asset .zip, pas l'archive source.
2. Magisk-Modules-Alt-Repo, le dépôt communautaire qui accepte les nouvelles soumissions.
3. MMRL, une application de gestion de modules qui gère les modules Magisk, KernelSU et APatch si vous préférez parcourir plutôt que télécharger à la main.

Pour installer : ouvrez votre gestionnaire de root, allez dans Modules, appuyez sur Installer depuis le stockage, choisissez le ZIP, redémarrez.

Nous n'hébergeons pas de binaires de modules et nous serions prudents envers quiconque le fait. Téléchargez depuis le projet, pas depuis un miroir, un lien raccourci, ou un fichier Telegram.

Comment évaluer un module

Les modules root tournent avec des privilèges complets. Appliquez l'examen que cela mérite :

• La source est-elle visible ? Pas de dépôt, pas d'installation. Cela seul élimine beaucoup de candidats.
• Quand était la dernière release ? Un module laissé de côté depuis deux ans sur une cible qui évolue vite est un risque.
• Le mainteneur répond-il aux issues ? Des mois de silence sont un signal.
• Sa documentation indique-t-elle la compatibilité ? Version d'Android, gestionnaire de root, conflits connus.
• Quelqu'un le fait-il tourner sur votre version d'Android et votre gestionnaire de root ? Pas sur l'appareil pour lequel il a été écrit en 2023.
• Demande-t-il d'affaiblir quelque chose ? Tout ce qui exige de désactiver SELinux mérite un examen approfondi.

Se remettre d'un bootloop

Ayez cela prêt avant d'en avoir besoin. Par ordre de préférence :

1. Mode sans échec. Magisk désactive tous les modules quand il détecte un démarrage en mode sans échec. Démarrez en mode sans échec, puis redémarrez normalement, et vous obtenez un système fonctionnel avec tout désactivé pour retirer le coupable depuis l'application. KernelSU fait de même. La combinaison de touches varie selon l'appareil, entraînez-vous une fois pendant que tout fonctionne.

2. La commande de suppression. Si un ordinateur peut voir l'appareil pendant qu'il tente de démarrer, Magisk documente ceci :

adb wait-for-device shell magisk --remove-modules

Cela retire tous les modules et redémarre.

3. Désactiver un module depuis un shell. Créer un fichier disable dans le dossier d'un module sous /data/adb/modules/ désactive uniquement ce module.

4. Restaurer l'image boot stock. Le filet de sécurité, et la raison d'en conserver une. Lisez d'abord la mise en garde ci-dessous.

La mise en garde sur l'image boot

La documentation de Magisk elle-même avertit que la restauration de partitions est spécifique à chaque appareil, et met en garde particulièrement les utilisateurs Samsung contre une restauration à la légère de boot, init_boot, recovery ou vbmeta. Les conseils fastboot génériques ne se transposent pas d'un fabricant à l'autre. Les utilisateurs d'APatch doivent aussi noter qu'il patche boot, pas init_boot.

Suivez la procédure propre à votre appareil exact. Si un flash a déjà mal tourné, diagnostiquez avant de reflasher, et si l'appareil ne démarre plus du tout, déterminez d'abord dans quel état il se trouve.

Quoi que vous fassiez, ne commencez pas à tout effacer. L'ordre des opérations compte, et une réinitialisation d'usine détruit vos clés de chiffrement en même temps que vos données.

Lectures complémentaires : Magisk vs KernelSU vs APatch · SafetyNet et Play Integrity avec le root · Magisk en 2026 : ce qui a changé · Échec de flash Magisk · Échec de mise à jour OTA sur un téléphone rooté · Guide de debloat Android

Sources : le dépôt GitHub ou GitLab de chaque projet, lié directement dans le texte. Documentation officielle, FAQ et notes de version de Magisk. Documentation officielle d'APatch et de KernelSU. Statut des modules vérifié par rapport à l'activité du dépôt et aux déclarations des mainteneurs à la date indiquée ci-dessus.

Dernière vérification : 30 octobre 2026. Cet écosystème évolue vite. Les projets listés ici étaient actifs au moment de la vérification et chacun peut être abandonné, forké ou remplacé sans préavis. Vérifiez le dépôt lié avant d'installer, et considérez la compatibilité comme spécifique à chaque appareil.