Hardware
TestTesteur de signal Bluetooth
Scannez et connectez les appareils BLE alentour depuis le navigateur via Web Bluetooth. Lisez services GATT, caractéristiques et RSSI. Gratuit.
Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons toutÀ propos du Testeur de signal Bluetooth
Testez des périphériques Bluetooth Low Energy (BLE) directement dans votre navigateur via l'API Web Bluetooth. Scannez les appareils à proximité, connectez-vous, explorez les services et caractéristiques GATT, et surveillez le RSSI quand il est disponible. Idéal pour les développeurs IoT, le débogage Bluetooth et les bancs de tests matériels.
How to use:
- Cliquez sur « Rechercher des appareils » pour détecter les périphériques BLE proches.
- Sélectionnez un appareil dans la boîte de dialogue du navigateur.
- Consultez le nom, l'identifiant et l'état de connexion de l'appareil.
- Explorez les services et caractéristiques GATT disponibles sur l'appareil connecté.
- Surveillez la puissance du signal (RSSI) comme une valeur au mieux : elle repose sur watchAdvertisements(), distincte de l'API de scan requestLEScan(), et peut rester indisponible sans un indicateur expérimental, donc ne considérez pas la barre en direct comme garantie.
- Exportez le rapport de l'appareil connecté en JSON ou CSV, ou copiez-le dans le presse-papiers, pour joindre un inventaire BLE reproductible à un ticket QA.
- Cliquez sur « Déconnecter » pour fermer la session lorsque vous avez fini.
Compatibilité navigateur
- Chrome 56+ et Edge 79+ (ordinateur et Android) : prise en charge complète
- Opera et ChromeOS : compatibles
- Safari et Firefox : non pris en charge (pas de Web Bluetooth)
- Navigateurs intégrés Android (Facebook, Instagram, TikTok WebView) : bloqués — ouvrez dans Chrome autonome
- HTTPS / contexte sécurisé obligatoire ; les pages http:// ne peuvent pas scanner
- Linux nécessite chrome://flags/#enable-web-bluetooth-new-permissions-backend plus la pile BlueZ
- Le RSSI en direct est au mieux et peut nécessiter les indicateurs expérimentaux de Chrome
Références techniques
- MDN Web Bluetooth API : https://developer.mozilla.org/fr/docs/Web/API/Web_Bluetooth_API
- Spécification Web Bluetooth : https://webbluetoothcg.github.io/web-bluetooth/
- Chrome Platform Status : https://chromestatus.com/feature/5264933985976320
Questions Fréquemment Posées
L'outil utilise l'API Web Bluetooth pour scanner les annonces Bluetooth Low Energy (BLE) à proximité et se connecter aux services GATT (Attribut Générique) sur un appareil choisi. Il rapporte le nom de l'appareil, l'identifiant de type MAC exposé par le navigateur, la liste des UUID de services annoncés et l'Indicateur de Force du Signal Reçu (RSSI) en dBm lorsque la plateforme l'expose. Une fois connecté, vous pouvez parcourir l'arborescence de services et caractéristiques, lire des caractéristiques statiques comme Informations sur l'Appareil (fabricant, modèle, version du firmware) et surveiller des valeurs en direct comme le niveau de batterie. Il ne mesure pas le Bluetooth classique (BR/EDR) utilisé par les casques anciens, car Web Bluetooth est exclusivement BLE par spécification. Considérez-le comme un inspecteur BLE portable plutôt qu'un analyseur de protocole complet.
L'appairage dans le système d'exploitation vérifie seulement qu'une poignée de main est complétée. Il ne vous dit rien sur la qualité du signal, les services pris en charge ou si le firmware annonce les bonnes capacités. En scannant et en vous connectant via cet outil, vous pouvez confirmer qu'un tracker d'activité expose effectivement le service Fréquence Cardiaque avant de déboguer une app, vérifier qu'une balise diffuse l'UUID iBeacon ou Eddystone attendu, ou voir le RSSI se dégrader en vous éloignant d'une serrure intelligente pour estimer la portée effective. Les tests aident aussi quand une app du fabricant refuse de se connecter — si l'appareil apparaît ici avec les services attendus, le problème est dans l'app ou ses permissions, pas dans la radio.
Le RSSI est rapporté en décibel-milliwatts (dBm) et est toujours négatif pour les signaux reçus. Un guide approximatif : −30 à −50 dBm est excellent, typiquement quand les appareils sont à un mètre l'un de l'autre ; −50 à −70 dBm est bon et donne des connexions fiables pour casques, souris et trackers ; −70 à −85 dBm est marginal et vous pouvez voir des coupures audio ou des lacunes de notification ; en dessous de −90 dBm la connexion échouera probablement. Rappelez-vous que le RSSI est logarithmique — une chute de 10 dBm représente environ 10× moins de puissance reçue. Murs, corps humains, micro-ondes et Wi-Fi 2,4 GHz atténuent ou interfèrent. Pour les périphériques BLE sur batterie, le récepteur du périphérique est souvent plus faible que celui du téléphone, donc un "bon" RSSI dans cet outil ne garantit pas une réception aussi bonne dans l'autre sens.
Les signaux BLE à 2,4 GHz se comportent comme des ondes électromagnétiques avec une longueur d'onde d'environ 12,5 cm, donc de petits changements de position peuvent vous déplacer entre des franges constructives et destructives de propagation multitrajets — le même motif d'onde stationnaire qui cause les zones mortes Wi-Fi. Des variations de RSSI de 5–10 dBm entre positions adjacentes sont tout à fait normales à l'intérieur. L'outil fait aussi la moyenne sur une petite fenêtre, et la radio de votre téléphone peut rapporter des valeurs quantifiées (souvent dBm entiers). Pour une lecture stable, maintenez les appareils immobiles quelques secondes et faites la moyenne mentale sur de nombreux échantillons, ou déplacez-vous lentement en observant la tendance. Si la valeur saute erratiquement sans mouvement, l'antenne peut être obstruée par votre main (effet "death grip").
Un service GATT est un regroupement logique d'éléments de données apparentés appelés caractéristiques. Chaque service a un UUID 16 bits pour les profils standard (ex. 0x180F pour Service de Batterie, 0x180D pour Fréquence Cardiaque, 0x1800 pour Accès Générique) ou un UUID 128 bits pour les services spécifiques au fournisseur. Les caractéristiques dans un service exposent des valeurs lisibles, inscriptibles ou notifiables — le niveau de batterie retourne un seul octet de 0 à 100, tandis que la fréquence cardiaque retourne une petite trame avec drapeaux et BPM. Lire une caractéristique donne la valeur actuelle ; s'abonner aux notifications donne des mises à jour en direct poussées par le périphérique. Les caractéristiques chiffrées nécessitent un appairage avant de répondre. Si une caractéristique retourne des données binaires mystérieuses, cherchez son UUID sur le site de spécifications Bluetooth SIG.
L'API Web Bluetooth n'expose que les appareils qui annoncent activement pendant votre fenêtre de scan, sont à portée et correspondent à tout filtre de service que vous avez fourni. Beaucoup d'appareils arrêtent d'annoncer une fois appairés et connectés à un hôte, donc une enceinte Bluetooth jouant de la musique depuis votre téléphone n'apparaîtra pas. Les appareils Bluetooth classiques (casques anciens, claviers BR/EDR) n'apparaissent jamais car Web Bluetooth est exclusivement BLE. Certains navigateurs exigent aussi une permission unique par appareil et peuvent filtrer les appareils déjà appairés au niveau OS. Essayez d'éteindre et rallumer l'appareil cible pour forcer une nouvelle annonce, rapprochez-vous pour exclure la portée et assurez-vous que le navigateur est Chrome, Edge ou Opera sur une plateforme non-iOS — Safari et Firefox ne prennent pas en charge Web Bluetooth au moment de la rédaction.
BLE 5.0 a introduit le PHY 2 Mbps (débit doublé), le PHY codé Longue Portée (S=2 et S=8 correction d'erreur avant pour ~4× la portée à débit réduit) et les charges utiles d'annonce étendues jusqu'à 255 octets. BLE 5.1 a ajouté la recherche de direction (AoA/AoD), 5.2 a ajouté LE Audio avec codec LC3 et canaux isochrones, et 5.3 a affiné la robustesse de connexion. L'API Web Bluetooth abstrait le PHY utilisé, donc l'outil ne peut pas montrer si votre lien est en 1M, 2M ou PHY codé — cette information n'est disponible qu'avec des sniffers bas niveau comme nRF Sniffer ou Ellisys. Ce que vous pouvez déduire indirectement : des connexions stables à portée extrême (>30 m en visibilité directe) suggèrent un support PHY codé, et le champ données fabricant dans le paquet d'annonce fait souvent allusion à la version BLE.
Rien n'est envoyé. Tout le scan, la connexion, la lecture du RSSI et l'exploration GATT s'exécutent localement dans votre navigateur via l'API Web Bluetooth — aucun nom d'appareil, identifiant, UUID de service, valeur de caractéristique ni échantillon de RSSI n'est envoyé à nos serveurs, et les fichiers d'export (JSON/CSV) sont générés sur votre machine et enregistrés uniquement où vous le choisissez. Lorsque vous choisissez un appareil dans le sélecteur du navigateur, vous accordez une autorisation par origine et par appareil pour que la page puisse se reconnecter à cette unité précise ; cela ne donne pas au site un accès global à tout votre matériel Bluetooth. Pour la vérifier ou la révoquer dans Chrome ou Edge, ouvrez chrome://settings/content/bluetoothDevices (ou cliquez sur l'icône de cadenas/réglages dans la barre d'adresse → Paramètres du site → Appareils Bluetooth) et supprimez les appareils enregistrés de ce site. Effacer les données du site de l'origine supprime aussi les autorisations. C'est pourquoi un poste QA peut utiliser l'outil sans divulguer l'inventaire firmware des appareils testés.
Web Bluetooth est une capacité puissante — elle peut lire et écrire sur les radios proches — donc la spécification ne l'expose que dans un contexte sécurisé. Cela signifie que la page doit être servie en HTTPS (ou depuis localhost en développement) ; sur une origine http:// simple, navigator.bluetooth est retenu et le bouton Rechercher reste désactivé, comportement que vous verrez si vous ouvrez l'outil via un proxy non sécurisé. De plus, la plateforme sous-jacente doit prendre en charge l'API : sous Linux, Chrome verrouille Web Bluetooth derrière l'indicateur expérimental chrome://flags/#enable-web-bluetooth-new-permissions-backend et exige la pile BlueZ installée et en cours d'exécution, car le backend d'autorisations y est encore en maturation. macOS, Windows, Android et ChromeOS fonctionnent immédiatement dans Chrome/Edge. Si l'outil indique que Web Bluetooth n'est pas pris en charge, vérifiez d'abord l'exigence de contexte sécurisé, puis votre navigateur et votre OS, avant de supposer que l'adaptateur est défectueux.
Une fois connecté, trois boutons s'activent à côté d'Actualiser : Exporter JSON, Exporter CSV et Copier le rapport. Exporter JSON télécharge un ble-report-<appareil>-<horodatage>.json comparable par machine contenant le nom et l'identifiant de l'appareil, un horodatage de capture, l'arborescence complète services/caractéristiques avec l'UUID et les propriétés de chaque caractéristique (Lire/Écrire/Notifier/Indiquer), tous les échantillons RSSI observés et le RSSI min/max/moyen calculé — idéal pour joindre à un ticket Jira ou GitHub ou pour comparer deux builds de firmware. Exporter CSV produit un fichier adapté aux tableurs avec un en-tête de métadonnées, un inventaire service_uuid / characteristic_uuid / properties et un tableau d'échantillons RSSI horodatés, pour qu'un atelier de réparation colle des lignes réussi/échoué dans un tableau par lot. Copier le rapport place le même JSON dans votre presse-papiers pour un collage rapide dans un chat ou un ticket. La barre à côté du RSSI est une lecture de qualité normalisée de 0–100 % dérivée du dBm brut affiché dans le badge (−100 dBm ≈ 0 %, −30 dBm ≈ 100 %), donc citez la valeur en dBm, pas le pourcentage, pour comparer des unités.
Non — traitez chaque caractéristique inscriptible comme potentiellement dangereuse jusqu'à connaître sa spécification. Écrire des octets arbitraires dans une caractéristique spécifique au fournisseur peut changer les paramètres du firmware, déclencher une réinitialisation usine, déverrouiller une porte, pousser l'appareil en mode mise à jour firmware (DFU) ou dans le pire des cas bricker l'appareil en écrasant un bloc de configuration. Les services standard du Bluetooth SIG documentent leurs caractéristiques inscriptibles avec des dispositions d'octets strictes ; les services fournisseur n'ont souvent pas de documentation publique et sont non triviaux à rétro-ingénierer. Le flux sûr est : lire tout d'abord pour comprendre l'état actuel, n'écrire que dans des caractéristiques pour lesquelles vous avez de la documentation, garder une sauvegarde de tout paramètre changé et ne jamais exécuter d'opérations d'écriture contre des appareils BLE médicaux, de sécurité ou industriels que vous ne possédez pas.
CONNECTIVITé5
WUTOOLS