ADB via Internet sur Android : configurations sûres avec ou sans root

Vous n’avez pas besoin du root pour atteindre l’ADB de votre téléphone depuis un autre pays. Il vous faut un moyen d’activer ADB sur TCP, et un chemin privé entre votre ordinateur et le téléphone. Le root ne change que la première partie : il permet au téléphone d’activer ADB lui-même et de le garder actif après un redémarrage, sans câble. Tout le reste de ce guide fonctionne de la même façon sur un téléphone d’origine.

Les deux erreurs les plus courantes sont les mêmes avec ou sans root. Soit on suit un tutoriel qui redirige le port 5555 sur le routeur de la maison, soit on fait confiance à une connexion qui marche en Wi-Fi et échoue sans bruit en données mobiles.

Ce guide concerne le téléphone qui vous appartient : un appareil de rechange pour vos tests, un téléphone resté chez vous que vous voulez joindre en voyage, un petit parc d’appareils. Il ne traite pas de l’accès à l’appareil de quelqu’un d’autre. Il explique comment fonctionne l’ADB à distance, comment l’activer avec ou sans root, et trois méthodes de connexion qui n’exposent jamais ADB sur l’Internet public. Les étapes qui exigent le root sont signalées par Root uniquement.

En bref : activez ADB en TCP sur le téléphone, ne le rendez joignable que par un chemin privé chiffré, et utilisez ce chemin depuis votre ordinateur. Tailscale est le plus simple. Un tunnel SSH inversé via un petit serveur à vous est le plus universel. La simple redirection du port 5555 est la seule configuration à éviter.

Avec ou sans root : ce qui change

La différence pratique tient à la fiabilité, pas aux capacités. Un téléphone d’origine fonctionne très bien à distance jusqu’à son redémarrage, puis il reste injoignable tant que quelqu’un n’a pas le téléphone et un ordinateur sous la main pour le remettre en état. Pour un téléphone situé dans une autre ville, c’est la raison de le rooter. Pour un téléphone à portée de main, ou pour un test de courte durée, ce n’est pas nécessaire.

Ce qui protège vraiment ADB, et ce qui ne le protège pas

La plupart des conseils sur l’ADB à distance affirment que l’ADB sur le réseau n’a « ni chiffrement ni authentification ». C’est à moitié vrai, et la moitié fausse compte pour votre configuration.

L’ADB réseau classique, le mode adb tcpip 5555, est non chiffré. Les notes de conception d’ADB d’Android décrivent le transport historique comme des paquets en clair, alors que le mode Wi-Fi introduit avec Android 11 enveloppe la session dans du TLS.source 2 Quiconque peut observer le chemin entre vous et le téléphone peut lire ce que vous envoyez.

L’authentification, c’est autre chose. Sur une build de production normale, ADB demande encore au téléphone d’approuver la clé RSA de votre ordinateur. À la première connexion, adb devices affiche unauthorized et le téléphone ouvre une boîte de dialogue : « Allow USB debugging? » avec l’empreinte de la clé. La documentation d’Android précise que les commandes adb ne peuvent pas s’exécuter tant que vous n’avez pas déverrouillé l’appareil et validé cette boîte de dialogue.source 1 Les clés que vous approuvez sont conservées sur le téléphone, et cocher « Always allow from this computer » rend les connexions suivantes silencieuses.

Deux conséquences pratiques en découlent. D’abord, un port exposé n’est pas une porte ouverte à un inconnu sur un téléphone d’origine, mais c’en est une pour quiconque obtient une clé que le téléphone approuve déjà, et c’est une porte grande ouverte sur tout appareil où l’authentification est désactivée. Les logiciels malveillants qui se sont propagés par le port 5555 ont surtout trouvé ces appareils : box TV, vidéoprojecteurs, builds de développement et téléphones où quelqu’un a désactivé l’indicateur de sécurité. Ensuite, la toute première connexion depuis un nouvel ordinateur exige quelqu’un devant l’écran. Prévoyez d’autoriser votre clé quand vous êtes à côté du téléphone, par câble USB ou sur le Wi-Fi de votre domicile, et cochez la case qui la mémorise.

Débogage sans fil : mal adapté à l’accès distant sans surveillance

Le débogage sans fil semble le choix le plus sûr, et pour un ordinateur portable sur votre Wi-Fi domestique, il l’est. Pour l’accès à distance, il vous complique la vie. Le port de connexion est aléatoire et change quand vous désactivez puis réactivez la fonction ; la découverte repose sur mDNS, qui ne traverse pas un VPN ; et les versions récentes d’Android le désactivent d’elles-mêmes. Android 17 avec ADB 37 ajoute « ADB Wi-Fi 2.0 », qui coupe le débogage sans fil sur les réseaux que vous n’avez pas marqués comme de confiance et se reconnecte automatiquement sur ceux que vous avez marqués.source 4 C’est un excellent comportement pour le bureau d’un développeur, et exactement le contraire de ce qu’il faut pour un téléphone à joindre depuis un autre pays.

Pour le détail de cette fonction, notre guide sur l’ADB sans fil sur Android 17 couvre l’appairage, les réseaux de confiance et le problème de l’appareil appairé mais hors ligne. Pour l’usage à distance, la meilleure brique reste le port TCP fixe, que vous activez avec ou sans root, puis que vous protégez par quelque chose de plus solide que le port lui-même.

Étape 1 : activer ADB en TCP

Choisissez la partie qui correspond à votre téléphone. Les deux aboutissent au même état : le démon ADB du téléphone écoute sur le port 5555, et l’étape 2 le protège.

Sans root

Sur n’importe quel téléphone Android, activez les options pour les développeurs et le débogage USB, branchez le téléphone à un ordinateur avec un câble, approuvez la clé quand le téléphone le demande, puis lancez :

adb tcpip 5555

Débranchez le câble. Le téléphone accepte désormais ADB sur le réseau, sur le port 5555, jusqu’à son redémarrage. Certaines builds réinitialisent aussi ce réglage quand vous basculez le débogage USB : si le port ne répond plus, relancez la commande. Comme le réglage est perdu au redémarrage, un téléphone non rooté exige quelqu’un avec un câble après chaque redémarrage. C’est acceptable pour un téléphone que vous maîtrisez, et mal adapté à un téléphone hors de portée.

Sous Android 11 et versions ultérieures, il existe un moyen de faire la même étape sans ordinateur, très répandu dans la communauté, même si nous ne l’avons pas testé sur tous les appareils. Vous activez le débogage sans fil, installez Termux et son paquet d’outils Android, appairez Termux au téléphone lui-même avec le code d’appairage, vous connectez à l’adresse du téléphone et lancez adb tcpip 5555 depuis là. Le téléphone doit être connecté au Wi-Fi à ce moment-là. Considérez cette méthode comme un plan B pour le jour où vous avez oublié votre câble, et consultez un guide Termux à jour pour les commandes exactes, car elles changent selon le paquet et la version d’Android.

Avec root (root uniquement)

Sur un téléphone rooté, ouvrez une application de terminal comme Termux et obtenez un shell root. La propriété qui contrôle le port est lue par le démon ADB lui-même, et le code source du démon vérifie service.adb.listen_addrs, puis service.adb.tcp.port, puis persist.adb.tcp.port.source 3

su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

Redémarrer le démon coupe toute session de débogage USB ouverte : lancez donc la commande depuis le téléphone, pas depuis un PC relié par câble. Vérifiez qu’il écoute :

getprop service.adb.tcp.port
ss -ltn | grep 5555

Certaines builds d’Android n’incluent pas ss ; netstat -ltn fonctionne sur d’autres. Si aucun des deux n’est présent, le vrai test est la connexion depuis votre ordinateur à l’étape 2.

La propriété service. est perdue au redémarrage du téléphone. Un téléphone injoignable après une coupure de courant n’est pas un téléphone distant : rendez donc le réglage persistant. Il y a deux façons, qui se combinent bien. La première est la propriété persistante :

setprop persist.adb.tcp.port 5555

La seconde est un script de démarrage. Avec Magisk, un script shell enregistré dans /data/adb/service.d/ et rendu exécutable s’exécute en fin de démarrage ; KernelSU et APatch utilisent plutôt un petit module avec un fichier service.sh. Consultez la documentation de votre gestionnaire root pour l’emplacement exact, car il varie selon l’outil et la version.

#!/system/bin/sh
until [ "$(getprop sys.boot_completed)" = "1" ]; do sleep 5; done
setprop service.adb.tcp.port 5555
stop adbd
start adbd

Redémarrez une fois et testez. Les constructeurs Android traitent ces propriétés différemment, et quelques ROM les ignorent ou les réinitialisent. Sous Android 11 et versions ultérieures, une règle SELinux a un temps empêché ADB de définir la propriété du port sur certaines builds, avant d’être assouplie.source 5 Si le réglage ne survit pas à un redémarrage sur votre téléphone, le script de démarrage est la solution ; et si le démon n’écoute jamais, votre ROM bloque peut-être la propriété. Dans ce cas, une session USB avec adb tcpip 5555 après chaque démarrage sert de plan B : c’est la méthode sans root ci-dessus.

Pour le désactiver de nouveau, avec root :

setprop service.adb.tcp.port -1
setprop persist.adb.tcp.port ""
stop adbd
start adbd

Sans root, désactiver le débogage USB dans les options pour les développeurs, ou redémarrer le téléphone, revient au même.

À ce stade, le téléphone écoute sur toutes ses interfaces réseau. C’est acceptable tant que seuls vous et votre réseau de confiance pouvez les atteindre, et c’est le rôle de l’étape suivante.

Étape 2 : choisir un chemin privé vers le téléphone

Chaque méthode ci-dessous fonctionne avec ou sans root. Toutes visent le même but : donner à votre ordinateur une route chiffrée et authentifiée vers le port 5555 du téléphone, sans accepter de connexion entrante depuis l’Internet ouvert. Ce second point compte plus qu’il n’y paraît. La plupart des téléphones en données mobiles sont derrière un NAT de niveau opérateur, si bien qu’une redirection sur le routeur ne peut pas les atteindre, même si vous en vouliez une.

Méthode A : Tailscale

Tailscale crée un réseau privé entre vos appareils et traverse le NAT à votre place, ce qui explique qu’il fonctionne depuis un téléphone en données mobiles. Installez-le sur le téléphone et sur votre ordinateur, puis connectez-vous au même compte. Chaque appareil reçoit une adresse stable commençant par 100., et l’adresse du téléphone est visible dans l’application et dans la console d’administration.

Depuis l’ordinateur :

adb connect 100.x.y.z:5555
adb devices

La première fois, le téléphone vous demande d’approuver la clé : c’est pourquoi il vaut mieux faire cette étape une fois, téléphone en main. L’application Tailscale n’a pas besoin du root. Ensuite, adb shell, adb push, adb logcat et scrcpy fonctionnent comme si le téléphone était sur votre bureau.

Trois réglages rendent le tout fiable, et pas seulement pratique. D’abord, par défaut, Tailscale laisse chaque appareil de votre réseau joindre tous les autres, et c’est le fichier de politique qui permet de restreindre cela. Une règle qui n’autorise que votre propre compte à joindre le téléphone étiqueté sur le port 5555 ressemble à ceci dans la politique d’accès :source 6

{ "action": "accept", "src": ["you@example.com"], "dst": ["tag:phone:5555"] }

Ensuite, désactivez l’expiration des clés pour le téléphone dans la console d’administration, sinon il quittera votre réseau à échéance et vous ne pourrez pas l’y remettre de loin. Enfin, accordez à l’application Tailscale une utilisation de la batterie sans restriction dans les réglages Android. Des utilisateurs signalent que l’application est arrêtée ou se déconnecte toutes les quelques minutes avec une gestion d’énergie agressive, et une coupure en plein transfert en est le symptôme habituel.source 8

Deux limites sont à connaître. Le serveur SSH intégré de Tailscale ne fonctionne pas sur Android, la plateforme n’étant cliente que pour cette fonction ; utilisez donc directement le port ADB, ou le tunnel SSH ci-dessous si vous voulez un shell sans ADB.source 7 Et n’utilisez pas Tailscale Funnel pour cela. Il sert à publier des services web sur l’Internet public, soit l’inverse de ce que vous cherchez.

Méthode B : un tunnel SSH inversé via votre propre serveur

Cette méthode n’exige rien d’un tiers. Vous louez le plus petit serveur virtuel possible, le téléphone s’y connecte vers l’extérieur et maintient la connexion ouverte. Votre ordinateur se connecte au même serveur et atteint le téléphone à travers lui. Comme c’est le téléphone qui appelle, cela fonctionne derrière un CGNAT et sur le Wi-Fi d’un hôtel.

Sur le téléphone, dans Termux (qui n’a pas besoin du root), installez le client SSH et créez une clé :

pkg install openssh autossh
ssh-keygen -t ed25519

Sur le serveur, créez un utilisateur dédié et ajoutez la clé publique du téléphone à son fichier authorized_keys, avec des restrictions pour que la clé ne puisse rien faire d’autre qu’ouvrir l’unique port d’écoute sur l’interface loopback :

restrict,port-forwarding,permitlisten="127.0.0.1:15555" ssh-ed25519 AAAA... phone

Ensuite, sur le téléphone, maintenez le tunnel ouvert. Les options ci-dessous font échouer bruyamment la connexion si le port ne peut pas être lié, et l’empêchent de rester bloquée en silence sur un réseau mort :

ssh -N -R 127.0.0.1:15555:127.0.0.1:5555 \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes tunnel@your-server.example

autossh peut superviser cette commande et la relancer, et le module complémentaire Termux:Boot peut la lancer après un redémarrage, avec termux-wake-lock pour garder le processeur éveillé tant que le tunnel est actif. Réglez aussi la batterie de Termux sur sans restriction. Ces éléments dépendent de votre version d’Android et de l’agressivité de votre constructeur envers les applications en arrière-plan : testez donc écran éteint pendant une heure avant de vous y fier.

Depuis votre ordinateur, redirigez un port local vers le tunnel et connectez-vous à travers lui :

ssh -N -L 5556:127.0.0.1:15555 you@your-server.example
adb connect 127.0.0.1:5556

Notez le port local 5556. Votre propre serveur ADB occupe souvent déjà le 5555, et un conflit à cet endroit produit des erreurs déroutantes. La redirection distante est liée à l’adresse loopback du serveur, donc rien sur Internet ne peut l’atteindre directement, et le comportement par défaut d’OpenSSH pour les redirections distantes refuse déjà de se lier à une interface publique, sauf si vous avez modifié GatewayPorts.

Utilisez des connexions par clé uniquement sur le serveur et gardez le mot de passe de cet utilisateur désactivé. Un tunnel inversé avec connexion par mot de passe sur un serveur SSH exposé à Internet n’est guère plus sûr que la redirection de port qu’il remplace.

Méthode C : WireGuard sur votre propre serveur

WireGuard donne le même résultat que Tailscale, avec tous les rouages sous votre contrôle. Lancez un point de terminaison WireGuard sur un serveur à adresse publique, ajoutez le téléphone et votre ordinateur comme pairs, et réglez PersistentKeepalive = 25 côté téléphone pour que les réseaux mobiles gardent la correspondance NAT active. L’application WireGuard d’Android, qui n’exige pas le root, passe du Wi-Fi à la LTE et peut fonctionner comme VPN permanent. Depuis votre ordinateur, vous vous connectez ensuite à l’adresse WireGuard du téléphone sur le port 5555, exactement comme avec Tailscale. C’est le bon choix quand vous voulez une installation fixe et permanente et que la maintenance du serveur ne vous gêne pas.

Une remarque sur une alternative populaire : Cloudflare Tunnel est documenté pour SSH, mais nous n’avons pas vérifié de configuration propre pour du trafic ADB brut, donc nous ne le recommandons pas ici.

La configuration à éviter : rediriger le port 5555 sur votre routeur

Il est tentant de rediriger le port externe 5555, ou un port « astucieux » de votre choix, vers le téléphone et de considérer l’affaire réglée. Ne le faites pas. Cela envoie de l’ADB non chiffré à travers l’Internet public, repose entièrement sur une seule invite de clé, et se signale aux scanners qui cherchent précisément cela.

Ce n’est pas de la théorie. En 2020, des chercheurs de Keysight qui analysaient le botnet Trinity ont fait état d’environ 40 000 appareils ADB exposés visibles sur Shodan, dont un quart environ de téléphones, le malware s’y connectant avec adb connect lui-même.source 9 Un botnet concurrent, Fbot, a supprimé Trinity des appareils infectés, et Trinity est revenu en quelques heures. En février 2021, le botnet Matryosh, bâti sur du code Mirai, s’est propagé par le même port.source 10 Changer le numéro de port externe ne change rien, car les scanners sondent tous les ports.

Certains guides proposent un compromis : rediriger plutôt le port SSH d’un serveur Termux. C’est mieux que de rediriger ADB, mais cela publie quand même un service SSH sur votre IP domestique, et une connexion Termux par mot de passe n’a rien à faire sur Internet. Un tunnel inversé ou un réseau overlay donne le même résultat sans aucun port entrant.

Checklist de sécurisation

N’autorisez que les ordinateurs que vous utilisez vraiment, et révoquez les anciens. Dans les options pour les développeurs, « Revoke USB debugging authorizations » efface toutes les clés enregistrées, une bonne habitude avant de confier le téléphone à quelqu’un d’autre. Laissez le débogage ADB désactivé sur tout téléphone qui n’en a pas besoin, et considérez le port ouvert à l’étape 1 comme faisant partie de la même décision. Ne cochez pas « Always allow » sur un ordinateur partagé ou public.

Une session ADB autorisée voit ce que voit l’utilisateur shell, ce qui est déjà beaucoup : applications installées, fichiers lisibles, écran et saisie. Root uniquement : sur un téléphone rooté, adb shell su peut accéder à bien plus si votre gestionnaire root l’accorde au shell ; réglez donc le gestionnaire pour qu’il demande confirmation au shell plutôt que d’accepter en silence.

Root uniquement : certains ajoutent une règle de pare-feu sur le téléphone pour que le port 5555 ne réponde que sur l’interface VPN. L’idée est saine, mais nous n’avons pas pu confirmer qu’elle est fiable sur Android. Le démon réseau du système peut réordonner ou purger les règles quand le réseau change, et l’application Tailscale standard ne crée pas d’interface tailscale0 sur laquelle s’appuyer. Si vous essayez, réappliquez la règle depuis votre script de démarrage et testez depuis un appareil qui n’est pas sur le VPN.

Travailler sur une liaison lente

Un téléphone derrière un tunnel paraît plus lent qu’un téléphone sur votre bureau, et la solution consiste généralement à demander moins. Pour la recopie d’écran avec scrcpy, baissez la résolution et le débit, par exemple scrcpy -s 100.x.y.z:5555 -m 1280 -b 4M ; les noms d’options varient un peu selon les versions, vérifiez donc scrcpy --help. scrcpy peut aussi activer le mode TCP pour vous avec --tcpip, et sa documentation recommande de se déconnecter une fois terminé.source 11 Un chemin Tailscale direct est plus rapide qu’un chemin relayé par les serveurs de l’éditeur, et l’état de la connexion dans l’application indique lequel vous avez.

Quand plusieurs appareils sont connectés, indiquez à ADB lequel vous visez avec adb -s 100.x.y.z:5555 ..., ou utilisez -d pour l’appareil USB et -e pour un émulateur. Les transferts de fichiers et adb logcat sont les tâches qui supportent le mieux la latence.

Dépannage

Avec root, vous pouvez vérifier ce que le téléphone utilise réellement en lançant getprop service.adb.tcp.port et getprop persist.adb.tcp.port dans un shell root. Sans root, le test est adb connect depuis l’ordinateur. Si le téléphone utilise aussi le débogage sans fil, rappelez-vous que son port TLS aléatoire est stocké séparément : une connexion sans fil qui marche ne dit donc rien du port fixe.

Questions fréquentes

Faut-il le root ? Non. Sans root, vous activez ADB en TCP via USB une fois, puis vous utilisez Tailscale, un tunnel inversé ou WireGuard exactement comme décrit. Le prix à payer : le réglage est perdu à chaque redémarrage, donc quelqu’un doit rebrancher un câble. Le root supprime cette étape et ajoute les options de pare-feu et su, et rien d’autre dans ce guide n’en dépend.

Cela fonctionne-t-il en données mobiles ? Oui, parce que Tailscale, WireGuard et un tunnel inversé se connectent tous vers l’extérieur depuis le téléphone. C’est la redirection de port sur le routeur qui échoue dans ce cas.

Peut-on le laisser actif en permanence sans danger ? Il est aussi sûr que le chemin qui le protège. Derrière un réseau overlay avec une politique d’accès, l’exposition est faible. Ne le laissez actif que si vous comptez vraiment l’utiliser, et désactivez-le sinon.

Quelqu’un peut-il en abuser sans l’invite de clé ? Sur une build normale, un nouvel ordinateur doit être approuvé sur le téléphone. Sur toute build où l’authentification du débogage est désactivée, on peut se connecter sans cela, et c’est pourquoi il ne faut jamais exposer ce port à Internet, quelle que soit la build.

Pourquoi ne pas simplement utiliser une application de bureau à distance ? Pour l’écran, c’est très bien, et une application de partage d’écran n’exige pas du tout le root. ADB est le bon outil quand vous avez besoin de commandes shell, d’installations, de transferts de fichiers ou de journaux à distance.

Avant de vous y fier

Testez tout avec le téléphone en données mobiles et l’ordinateur sur un autre réseau. Redémarrez le téléphone et vérifiez ce qui revient tout seul : sur un téléphone rooté, la connexion devrait se rétablir, et sur un téléphone non rooté, vous devez savoir exactement ce qu’il faut refaire. Essayez aussi écran éteint pendant un moment. Si vous ne pouvez plus joindre le téléphone après l’un de ces tests, vous avez trouvé le problème alors qu’il coûte encore peu à corriger.

Si vous cherchez encore un téléphone pour ce genre de projet, et que vous voulez pouvoir le rooter, notre catalogue des téléphones rootables indique quels modèles se déverrouillent proprement, et le guide des modules Magisk couvre le côté module du script de démarrage réservé au root. Pour un shell Linux qui ne dépend pas du root, consultez Terminal Linux d’Android ou Termux.

Sources et périmètre

Ce guide a été rédigé en octobre 2026 à partir de la documentation et du code source d’Android, ainsi que de publications de constructeurs et de chercheurs en sécurité. Nous n’avons pas testé toutes les versions d’Android ni toutes les ROM. Le comportement des propriétés, les scripts de démarrage, l’astuce d’activation sur le téléphone, l’approche par pare-feu et le comportement de la batterie avec Termux varient selon les appareils : vérifiez chacun sur votre propre téléphone avant d’en dépendre.

• Source 1 : Android Developers, Android Debug Bridge (adb) Ouvrir la source
• Source 2 : Android Open Source Project, notes de conception d’ADB Wi-Fi : le TCP historique n’est pas chiffré, le mode Wi-Fi utilise TLS Ouvrir la source
• Source 3 : Android Open Source Project, adbd main.cpp, choix du port à partir des propriétés Ouvrir la source
• Source 4 : Android Developers Blog, débogage sans fil et ADB Wi-Fi 2.0 Ouvrir la source
• Source 5 : OmniROM, modification de la politique SELinux pour les propriétés d’adbd Ouvrir la source
• Source 6 : Tailscale, listes de contrôle d’accès Ouvrir la source
• Source 7 : Tailscale, prise en charge de Tailscale SSH selon la plateforme Ouvrir la source
• Source 8 : Forum de la communauté Tailscale, déconnexions Android et utilisation de la batterie Ouvrir la source
• Source 9 : Keysight, malware TrinityP2P via ADB Ouvrir la source
• Source 10 : The Hacker News, botnet DDoS Matryosh, février 2021 Ouvrir la source
• Source 11 : Documentation de scrcpy, Connexion Ouvrir la source