Bluetooth et BLE : définition, différence entre Classic et Low Energy et fonctionnement

Que sont Bluetooth et BLE ?

Bluetooth est une norme de réseau personnel sans fil (WPAN) fonctionnant dans la bande ISM 2,4 GHz, conçue pour la communication entre appareils à des distances allant jusqu'à 100 mètres. La spécification IEEE 802.15.1 définit les couches physique et MAC, tandis que la pile Bluetooth SIG définit des profils de haut niveau pour des scénarios spécifiques : casque audio (HSP), transfert de fichiers (OPP), saisie au clavier (HID).

La norme s'est divisée en deux branches depuis la version 4.0 (2010) : Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate) et Bluetooth Low Energy (BLE, anciennement Bluetooth Smart). Classic est conçu pour les flux continus — appels audio, musique, fichiers. BLE a été créé pour les applications où les données sont transmises en paquets courts avec des pauses de dizaines de secondes ou minutes — cardiofréquencemètres, balises, capteurs de température.

Selon la Bluetooth SIG (2025), 99 % des nouveaux smartphones prennent en charge les deux versions, et l'écosystème BLE comprend plus de 15 types de profils, de Blood Pressure à Environmental Sensing.

Bluetooth Classic vs BLE : Comparaison

Le choix entre Classic et BLE dépend du scénario : pour le streaming audio, seul Classic est adapté, pour interroger un capteur une fois par heure — seul BLE. BR/EDR utilise 79 canaux avec un espacement de 1 MHz et un saut de fréquence adaptatif (AFH), offrant une résistance aux interférences Wi-Fi.

BLE 5.x a ajouté LE Coded PHY pour augmenter la portée jusqu'à 1 km (en espace ouvert) et LE Audio avec le codec LC3 — la nouvelle version brouille progressivement la frontière entre Classic et BLE pour les scénarios audio.

Architecture BLE : Controller, Host et Application

La pile BLE est divisée en trois couches : Controller (couches physique et liaison), Host (L2CAP, ATT, GATT, gestionnaire de sécurité) et Application (implémentation du profil dans l'application). Cette séparation permet au fabricant de la puce d'implémenter le Controller dans le firmware, tandis que le développeur d'application mobile ne travaille qu'avec des abstractions GATT.

La couche liaison (LL) gère le temps d'antenne : le périphérique alterne entre les états Standby, Advertising, Scanning, Initiating et Connection. À l'état connecté, Central et Peripheral conviennent d'un intervalle de connexion — la fréquence à laquelle ils échangent des paquets de données. Un intervalle typique est de 7,5 à 1000 ms ; plus l'échange est fréquent, plus le débit est élevé et plus la consommation d'énergie est importante.

Le gestionnaire de sécurité (SM) implémente le chiffrement AES-128 avec échange de clés via le protocole d'appairage. Il existe trois modes : Just Works (sans saisie de code), Passkey Entry (code à 6 chiffres à l'écran) et OOB (NFC ou QR). Pour les appareils portables, on utilise généralement Just Works ; pour les dispositifs médicaux, OOB avec vérification supplémentaire.

Selon la Bluetooth Core Specification 5.4 (2023), le temps d'établissement d'une connexion sécurisée en mode LE Secure Connections ne dépasse pas 300 ms avec un intervalle de connexion de 30 ms.

Profil GATT : Services, Caractéristiques et Descripteurs

Le ATT (Attribute Protocol) est le modèle de transport de base où le serveur (périphérique) stocke des attributs et le client (smartphone) les lit ou les écrit. GATT (Generic Attribute Profile) construit une hiérarchie sur ATT : Service → Characteristic → Descriptor.

Chaque service est un groupe logique de caractéristiques décrivant une fonction du périphérique : Heart Rate Service (UUID 0x180D) contient la caractéristique Heart Rate Measurement (UUID 0x2A37) avec un descripteur Client Characteristic Configuration (0x2902) qui contrôle les notifications. Le développeur d'application mobile obtient la liste des services via discoverServices(), puis trouve la caractéristique souhaitée par UUID et s'abonne aux notifications.

BLE utilise des UUID 16 bits pour les services standardisés Bluetooth SIG et des UUID 128 bits pour les services personnalisés du fabricant. Par exemple, un étui tracker peut définir un service A000-… avec une caractéristique pour transmettre le niveau de charge de sa batterie.

Exemple de travail avec GATT en Kotlin (Android)

private val gattCallback = object BluetoothGattCallback() {
    override fun onServicesDiscovered(
        gatt: BluetoothGatt, status: Int
    ) {
        val service = gatt.getService(UUID.fromString("0000180d-0000-1000-8000-00805f9b34fb"))
        val char = service?.getCharacteristic(
            UUID.fromString("00002a37-0000-1000-8000-00805f9b34fb")
        )
        gatt.setCharacteristicNotification(char, true)
    }

    override fun onCharacteristicChanged(
        gatt: BluetoothGatt, char: BluetoothGattCharacteristic
    ) {
        val heartRate = char.getIntValue(BluetoothGattCharacteristic.FORMAT_UINT8, 1)
        updateUi("Pouls : $heartRate bpm")
    }
}

Dans l'exemple, l'application trouve le service Heart Rate par l'UUID standard Bluetooth SIG, obtient la caractéristique de mesure du pouls et s'abonne à ses notifications — à chaque changement de pouls, le périphérique envoie des données sans demande explicite du Central.

Advertising, scan et établissement de connexion

L'Advertising est un mécanisme clé du BLE par lequel un périphérique Peripheral envoie périodiquement des paquets de diffusion (PDU d'advertising) sur trois canaux primaires (37, 38, 39). Le dispositif central scanne ces canaux, reçoit les données d'advertising et peut initier une connexion.

Un paquet d'advertising contient jusqu'à 31 octets de charge utile : drapeaux, niveau de puissance TX, nom local, UUID de services, données spécifiques au fabricant. Cela suffit pour transmettre des relevés de capteurs sans établir de connexion — mode sans connexion (type Broadcaster). Pour une transmission continue de données (par exemple, température une fois par minute), on utilise une connexion avec un intervalle allant jusqu'à 1000 ms.

Sur les plateformes mobiles, le scan est lancé via startScan() (Android) ou scanForPeripherals() (iOS). Le filtrage par UUID de service permet d'économiser l'énergie en ne traitant pas tous les appareils visibles — l'application ne reçoit un callback que pour les balises ou capteurs pertinents.

Exemple de scan de périphériques BLE en Swift (iOS)

import CoreBluetooth

class ScannerViewController: UIViewController {
    private var centralManager: CBCentralManager!

    override func viewDidLoad() {
        centralManager = CBCentralManager(
            delegate: self, queue: nil
        )
    }

    func centralManagerDidUpdateState(central: CBCentralManager) {
        if central.state == .poweredOn {
            centralManager.scanForPeripherals(
                withServices: nil, options: nil
            )
        }
    }

    func centralManager(
        central: CBCentralManager,
        didDiscover peripheral: CBPeripheral,
        advertisementData: [String : Any],
        rssi RSSI: NSNumber
    ) {
        if let name = advertisementData[CBAdvertisementDataLocalNameKey] {
            print("Appareil trouvé : \(name)")
        }
    }
}

Après avoir découvert un périphérique, le Central appelle connect(), en passant l'objet CBPeripheral. Les paramètres de connexion (intervalle, latence, temps de supervision) sont négociés au niveau de la couche liaison — le développeur ne les gère pas directement, mais peut les influencer via requestConnectionPriority sur Android.

Bluetooth LE dans le développement mobile : Core Bluetooth et android.bluetooth

Les deux plateformes mobiles fournissent des API natives pour travailler avec BLE. Core Bluetooth (iOS) utilise une approche par délégués : le gestionnaire central initie les opérations et l'objet périphérique rapporte les résultats via des méthodes déléguées. android.bluetooth (Android) est construit sur des interfaces de callback et prend en charge les opérations GATT parallèles avec plusieurs périphériques.

Différences clés entre les plateformes :

• iOS — supporte jusqu'à 7 connexions simultanées ; le mode BLE en arrière-plan nécessite UIBackgroundModes = bluetooth-central ; après avoir quitté le premier plan, le système peut retarder les callbacks de plusieurs minutes
• Android — pas de limite de connexion fixe (limitée par la mémoire) ; nécessite les autorisations BLUETOOTH_SCAN et BLUETOOTH_CONNECT (Android 12+) ; un service au premier plan est nécessaire pour un scan fiable en arrière-plan
• Flutter — le package flutter_blue_plus abstrait les API des plateformes avec une interface Dart unifiée : le code pour le scan et les opérations GATT est identique sur les deux plateformes

Selon les tests de la Bluetooth SIG (2024), le temps de connexion BLE entre un smartphone et un tracker d'activité est en moyenne de 150 à 300 ms sur Android et de 100 à 250 ms sur iOS — la différence est due aux politiques de gestion du module radiofréquence.

Exemple de connexion BLE en Dart (Flutter)

import 'package:flutter_blue_plus/flutter_blue_plus.dart';

class BleService {
  final FlutterBluePlus fbp = FlutterBluePlus();

  Future<void> scanAndConnect(String deviceName) async {
    await fbp.startScan(timeout: Duration(seconds: 15));

    await for (final result in fbp.scanResults) {
      if (result.device.advName == deviceName) {
        await fbp.stopScan();
        await result.device.connect();
        break;
      }
    }
  }
}

Le développeur Flutter obtient une interface API unifiée ; sous le capot, flutter_blue_plus traduit les appels en android.bluetooth natif ou Core Bluetooth. Cette approche réduit le temps de développement d'applications pour travailler avec des périphériques BLE sur les deux plateformes.