Fastboot : appareil non détecté, vérifications du câble, du pilote, de l’USB et du mode
Une sortie vide de fastboot devices a six causes possibles, et le pilote n’en est qu’une. Voici comment isoler chaque couche, dans l’ordre.

Sommaire
Une sortie vide de fastboot devices a six causes possibles, et le pilote n’en est qu’une. Le mode, le câble, le port, la version de platform-tools, l’association du périphérique par le système hôte et le pilote se trouvent tous entre votre commande et le téléphone. Isolez-les dans l’ordre et vous trouverez la vraie cause en une dizaine de minutes.
Commencez par confirmer dans quel mode vous êtes vraiment
C’est la vérification que l’on saute, et c’est elle qui produit les pannes les plus déroutantes.
Le fastboot du bootloader et fastbootd sont deux environnements différents. La documentation de l’Android Open Source Project décrit fastbootd comme un démon et un mode en espace utilisateur, introduits quand l’implémentation de fastboot a quitté le bootloader pour l’espace utilisateur afin de gérer des partitions redimensionnables, à partir d’Android 10. Les deux affichent « fastboot » à l’écran. Les deux utilisent le même outil fastboot depuis votre ordinateur. Ils gèrent des partitions différentes et peuvent se comporter différemment sur la même machine.
Sur les appareils compatibles, demandez-lui lequel c’est :
fastboot getvar is-userspace
Un résultat yes signifie que vous êtes dans fastbootd. Un résultat no signifie fastboot du bootloader. Sans aucune réponse, vous avez un problème de connexion et le reste de cet article s’applique.
Le mode Download de Samsung n’est pas fastboot. Les appareils Samsung utilisent en général une interface de flash distincte, avec son propre protocole et ses propres outils. fastboot devices ne trouvera pas un appareil Samsung en mode Download, et c’est le comportement attendu, pas une panne. Si votre appareil affiche un écran Download, fastboot n’est pas le bon outil et aucun travail sur les pilotes n’y changera rien.
Le recovery n’est pas fastboot non plus. Un appareil en recovery répond à adb devices, pas à fastboot devices. Si vous voyez un menu de recovery, utilisez ADB. Voir Android redémarre toujours en recovery pour comprendre cet état.
L’échelle d’isolation
Procédez de haut en bas. Chaque échelon écarte une couche, avec un test précis pour ne pas deviner.
| # | Couche | Test | Si c’est le problème |
|---|---|---|---|
| 1 | Mode | L’écran est-il bien un écran bootloader ou fastboot ? | Vous êtes en recovery, en mode Download ou sous l’OS. Utilisez le bon outil |
| 2 | Câble | Le même câble transfère-t-il des fichiers depuis un téléphone qui fonctionne ? | Prenez un câble dont vous avez vérifié qu’il transmet des données |
| 3 | Port | Un autre port, directement sur la machine, change-t-il quelque chose ? | Passez à un port arrière, sans hub, sans dock, sans rallonge |
| 4 | Détection hôte | Quelque chose apparaît-il dans la liste des périphériques du système au branchement ? | Rien n’apparaît : matériel ou câble. Quelque chose apparaît : continuez |
| 5 | Pilote ou droits | Le système nomme-t-il correctement l’appareil ? | Appareil inconnu ou sans nom : pilote sous Windows, règles udev sous Linux |
| 6 | Outils | fastboot est-il la version officielle actuelle, lancée depuis le bon endroit ? | Mettez à jour platform-tools, cherchez une seconde copie dans votre PATH |
L’échelon 4 décide de tout. Un appareil qui s’énumère en USB mais n’apparaît pas dans fastboot devices a un problème côté hôte que vous pouvez corriger. Un appareil qui ne s’énumère pas du tout, c’est une autre situation, et peut-être pas un problème logiciel. Ne le sautez pas.
Câble
Un câble qui charge ne transmet pas forcément des données. Les câbles de charge seule existent et produisent exactement le symptôme que vous cherchez à résoudre, sans message d’erreur ni indice sur la cause.
Le test est un test de comportement, pas un examen visuel. On ne peut pas le deviner à l’œil. Utilisez un câble avec lequel vous avez déjà transféré des fichiers, depuis n’importe quel appareil, sur cet ordinateur. Si vous n’en avez pas un dont vous êtes sûr, commencez par là : tous les échelons suivants donnent des résultats peu fiables avec un mauvais câble.
Les câbles se dégradent aussi. Un câble qui marchait l’an dernier peut avoir un conducteur cassé, et la panne est souvent intermittente, ce qui fait penser à un problème du téléphone.
Deux autres remarques sur les câbles : celui fourni avec le téléphone est un bon point de départ si vous l’avez encore, et la longueur compte, car un câble long ou fin peut être limite pour les données même s’il charge très bien.
Port et hub
Hubs USB, ports d’écran, ports USB de relais des claviers, docks et rallonges ajoutent chacun une couche qui peut couper la connexion ou perturber l’énumération lors d’un changement de mode.
Utilisez un port directement sur la machine, et préférez un port arrière sur un ordinateur de bureau à un port en façade : les connecteurs de façade sont câblés en interne et sont une source plus fréquente de connexions limites.
La génération du port mérite aussi un test. Des comportements différents ont été signalés pour les appareils en mode bootloader selon la génération du contrôleur USB. Ce n’est ni universel ni prévisible, et c’est justement pour cela qu’on teste : si vous avez un port USB 2.0 et un port USB 3.x, essayez les deux. Cela ne coûte rien et règle une catégorie de problèmes qu’aucune réinstallation de pilote ne touchera.
Version de platform-tools
Utilisez le paquet officiel actuel Android SDK Platform Tools du site développeur de Google. Pas un bundle « minimal ADB and fastboot » reconditionné, pas une copie livrée avec un utilitaire de flash, et pas une version téléchargée il y a trois ans.
Deux choses peuvent mal tourner ici.
La version est trop ancienne pour votre appareil. Les appareils et les dispositions de partitions récents demandent des outils récents. Un binaire fastboot d’une version plus ancienne peut ne pas comprendre ce que lui dit un appareil actuel.
Il y a plusieurs copies sur votre machine. Les utilitaires de flash installent leurs propres copies, et si l’une d’elles est dans votre PATH, la commande que vous tapez n’exécute peut-être pas le binaire que vous croyez. Vérifiez lequel s’exécute réellement :
fastboot --version
Sous Windows, where fastboot. Sous macOS ou Linux, which -a fastboot. Si plusieurs chemins s’affichent, réglez cela avant tout autre dépannage.
État du pilote Windows
Windows associe un pilote à un périphérique USB d’après la façon dont il s’identifie, et un téléphone en mode bootloader s’identifie autrement que le même téléphone sous Android. C’est pourquoi un appareil peut très bien transférer des fichiers et rester invisible pour fastboot, sur la même machine avec le même câble.
Ouvrez le Gestionnaire de périphériques et observez-le pendant que vous branchez le téléphone en mode bootloader. Ce que vous voyez détermine la solution :
- Une interface Android bootloader correctement nommée. Le pilote est associé. Le problème est ailleurs, retournez à l’échelon des outils.
- Un appareil inconnu, ou un appareil avec un indicateur d’avertissement. Le pilote n’est pas associé. C’est le cas classique.
- Rien n’apparaît ni ne disparaît au branchement. Pas d’énumération. Cela pointe vers le câble, le port ou l’appareil lui-même plutôt que vers le pilote.
- L’entrée apparaît puis disparaît. L’appareil redémarre ou perd son alimentation. Essayez un autre port et un autre câble avant de conclure quoi que ce soit.
Si un pilote doit être installé, utilisez le paquet de pilotes USB du constructeur de votre marque, ou le pilote USB de Google pour les Pixel et Nexus, tous deux depuis le site du constructeur. Évitez les lots de pilotes tiers proposés par des portails de téléchargement.
Certaines procédures d’installation de pilotes suggèrent de désactiver la vérification de signature des pilotes de Windows. C’est un vrai paramètre de sécurité du système. Si vous le désactivez, comprenez ce qu’il fait et réactivez-le ensuite.
macOS et Linux
Aucune de ces plateformes n’a besoin d’un pilote au sens de Windows. Les pannes sont différentes.
macOS. Aucune installation de pilote n’est nécessaire. Vérifiez si l’appareil s’énumère dans Informations Système, sous USB, pendant qu’il est connecté en mode bootloader. S’il y apparaît mais que fastboot devices reste vide, le problème est du côté des outils, pas du système. Sur les versions récentes de macOS, les invites d’autorisation au premier lancement des binaires téléchargés peuvent aussi gêner : vérifiez que l’outil est autorisé à s’exécuter.
Linux. L’appareil s’énumère en général sans configuration, mais les droits d’accès ne sont peut-être pas accordés à votre compte. Confirmez l’énumération avec lsusb avant et après le branchement. Si l’appareil apparaît dans lsusb mais pas dans fastboot devices, regardez d’abord les droits. On règle cela avec les règles udev pour appareils Android que beaucoup de distributions fournissent, ou que maintient le projet android-udev-rules.
Le diagnostic rapide : si la même commande lancée avec des privilèges élevés trouve l’appareil alors qu’elle ne le trouve pas sous votre utilisateur, vous avez confirmé un problème de droits et non de connectivité. Corrigez-le avec de bonnes règles udev plutôt que de tout lancer en administrateur.
Machines virtuelles et WSL. Le passthrough USB vers une VM ou WSL ajoute une couche avec ses propres pannes, surtout lors des changements de mode : l’appareil se déconnecte et se reconnecte avec une autre identité USB en entrant ou sortant du mode bootloader, et le passthrough peut ne pas suivre. Si vous dépannez dans une VM, testez d’abord directement sur l’hôte avant de conclure.
Quand ADB fonctionne mais pas fastboot
C’est la version la plus courante du problème, et elle déroute parce que le téléphone se connecte clairement.
L’explication : Android en fonctionnement normal et l’appareil en mode bootloader sont deux périphériques USB différents pour votre ordinateur. Identifiants différents, interface différente, et potentiellement un autre pilote. Qu’ADB fonctionne prouve que votre câble et votre port sont bons, ce qui est utile, mais ne prouve rien sur la connexion en mode bootloader.
Dans ce cas, gardez ce résultat. Le câble et le port sont écartés. Passez directement aux échelons 5 et 6 : association du pilote pour l’interface bootloader sous Windows, udev sous Linux, version des outils partout.
Si l’échelle ne mène à rien
À ce stade, la bonne question n’est plus « pourquoi mon ordinateur ne le voit pas » mais « dans quel état est l’appareil ». Ce sont deux problèmes différents.
Prenez le résultat obtenu à l’échelon 4 et lisez-le à la lumière de soft brick et hard brick. Un appareil qui s’énumère comme quelque chose d’inconnu n’est pas du tout dans la même situation qu’un appareil qui ne s’énumère pas, et cette différence change à la fois ce qui est possible et ce que cela coûte.
Avant de conclure que l’appareil est en cause, faites encore un test : essayez un second ordinateur, idéalement sous un autre système. Cela écarte toute une catégorie de problèmes côté hôte en un seul essai, et c’est plus rapide que de continuer à dépanner la machine de départ.
Questions fréquentes
Pourquoi adb devices fonctionne-t-il alors que fastboot devices n’affiche rien ? Parce que ce sont deux périphériques USB différents pour votre ordinateur. Android en marche et l’appareil en mode bootloader présentent des identités différentes et peuvent s’associer à des pilotes différents. Qu’ADB fonctionne confirme votre câble et votre port, rien de plus.
Dois-je activer le débogage USB pour fastboot ? Non. Le débogage USB est un réglage ADB dans Android. Fastboot fonctionne dans le bootloader, sous l’OS, et n’en dépend pas. Cela compte quand un appareil ne démarre pas, car on ne peut pas activer le débogage USB après coup sur un téléphone qui n’atteint jamais l’écran des réglages.
fastboot devices affiche mon appareil mais les commandes échouent. C’est un autre problème. La détection fonctionne. L’échec vient probablement d’un bootloader verrouillé, d’une partition inaccessible dans le mode actuel, ou d’une commande qui exige fastbootd plutôt que le fastboot du bootloader. Lisez tout le texte de l’erreur : il nomme généralement la raison.
Un câble USB-C vers USB-C fonctionne-t-il ? En général oui, s’il transmet des données. Le type de connecteur n’est pas la variable. Ce qui compte, c’est que le câble ait des conducteurs de données et que les ports des deux côtés prennent en charge la connexion.
Le téléphone doit-il être chargé ? Il lui faut assez de charge pour tenir pendant toute l’opération. Un appareil très déchargé peut perdre la connexion en cours de route, et un flash interrompu est pire qu’aucun flash. Chargez-le avant de commencer.
Peut-on régler cela à distance ? Les couches côté hôte, généralement oui, puisque le travail sur le pilote, les outils et les droits se fait sur votre ordinateur. Nous le faisons régulièrement en session à distance, et voici exactement ce que cela implique et ce que nous pouvons ou non voir. Si l’appareil lui-même ne s’énumère sur aucune machine avec aucun câble, ce n’est pas un problème côté hôte et le travail à distance ne le résoudra pas.
À lire aussi : Soft brick et hard brick · Réparer un bootloop sans perdre de données · Échec du flash Magisk · Android redémarre toujours en recovery · Ce que signifie chaque symptôme à l’écran de démarrage
Sources : Android Open Source Project, documentation de fastboot en espace utilisateur. Android SDK Platform Tools, version officielle.
Dernière vérification : 28 août 2026. Le comportement de l’USB, les pilotes requis et les modes disponibles varient selon le constructeur, le modèle et le système hôte. Vérifiez dans la documentation officielle de votre appareil.