Bluetooth Low Energy (BLE) dans le développement mobile : ce que c'est, les protocoles et son fonctionnement

Qu'est-ce que Bluetooth Low Energy (BLE) et comment ça marche ?

Bluetooth Low Energy (BLE) fonctionne selon un modèle client-serveur avec deux rôles : Central (appareil mobile) et Peripheral (périphérique). Central scanne les ondes et initie la connexion, tandis que Peripheral transmet les données. Contrairement au Bluetooth classique, BLE n'est pas conçu pour les flux audio — sa tâche est de transmettre de petits paquets avec une consommation d'énergie minimale. Selon Bluetooth SIG Core Specification 5.4 (2025), BLE prend en charge des vitesses allant jusqu'à 2 Mbps avec un courant inférieur à 15 mA en mode actif.

Hiérarchie GATT : Service, Characteristic, Descriptor

GATT (Generic Attribute Profile) définit la structure de données de Bluetooth Low Energy. Service est un groupe logique de caractéristiques (par exemple, Heart Rate Service 0x180D). Characteristic est un point de données avec une valeur spécifique. Descriptor sont les métadonnées de la caractéristique, y compris CCCD pour la gestion des notifications. Chaque élément a un UUID — 16 bits pour les profils standard Bluetooth SIG ou 128 bits pour les personnalisés.

Bluetooth Low Energy dans les applications mobiles utilise cette hiérarchie pour organiser l'échange de données entre un smartphone et les périphériques. Une bonne compréhension de GATT est la base du développement d'applications BLE sur les deux plateformes. Le développeur doit connaître les UUID des services et caractéristiques de l'appareil, ainsi que les propriétés de chaque caractéristique (read, write, notify, indicate).

Advertising Data et Scan Response

Les appareils BLE transmettent des paquets publicitaires (advertising packets) pour la détection. Advertising Data contient le nom de l'appareil, les UUID des services, le RSSI et Manufacturer Specific Data. La taille du paquet publicitaire est limitée à 31 octets. Pour transmettre des données supplémentaires, on utilise Scan Response — un second paquet que l'appareil central demande après la détection.

BLE sur iOS : Core Bluetooth, CBCentralManager, CBPeripheral

Sur iOS, le framework Core Bluetooth gère le Bluetooth Low Energy. CBCentralManager gère le scan et la connexion, CBPeripheral représente un appareil BLE distant. Le processus est standard : initialisation de CBCentralManager, vérification de l'état poweredOn, lancement de scanForPeripherals, connexion et découverte des services. Core Bluetooth gère automatiquement l'alimentation du module radio — si BLE n'est pas utilisé, il s'éteint.

BLE dans le développement mobile sur iOS nécessite de prendre en compte les modes d'arrière-plan. Le mode arrière-plan de Core Bluetooth est activé via les Capabilities du projet (Uses Bluetooth LE accessories). En arrière-plan, l'application peut recevoir des notifications de caractéristiques, mais le scan est limité — le système ne le relance que lorsque l'appareil bouge. Pour iBeacon, le scan en arrière-plan fonctionne plus activement via CLLocationManager.

Exemple de scan BLE en Swift

import CoreBluetooth

class DeviceScanner: NSObject, CBCentralManagerDelegate {
    var centralManager: CBCentralManager!

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

    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        guard central.state == .poweredOn else { return }
        central.scanForPeripherals(withServices: nil, options: nil)
    }

    func centralManager(_ central: CBCentralManager,
                        didDiscover peripheral: CBPeripheral,
                        advertisementData: [String: Any],
                        rssi RSSI: NSNumber) {
        print("Trouvé : \(peripheral.name ?? "unknown")")
    }
}

Dans cet exemple, CBCentralManagerDelegate traite tous les événements de connexion BLE. La méthode centralManagerDidUpdateState vérifie si Bluetooth est activé sur l'appareil mobile. Après une initialisation réussie, le scan démarre. Le callback didDiscover est invoqué pour chaque appareil trouvé.

Connexion et lecture des caractéristiques dans Core Bluetooth

Après avoir découvert un appareil, il faut appeler connect et discoverServices. CBPeripheralDelegate fournit des méthodes pour traiter chaque étape : didDiscoverServices, didDiscoverCharacteristics, didUpdateValueFor. Chaque méthode est asynchrone — les données arrivent via des callbacks délégués. RSSI (Received Signal Strength Indicator) indique le niveau du signal : plus la valeur est proche de 0, plus le signal est fort.

BLE sur Android : BluetoothAdapter, BluetoothGatt, BluetoothLeScanner

Sur Android, Bluetooth Low Energy est implémenté via le package android.bluetooth. BluetoothAdapter est le point d'entrée pour toutes les opérations BLE. BluetoothLeScanner lance le scan avec des callbacks ScanCallback. Après avoir découvert un appareil, BluetoothGatt est créé — une connexion au périphérique. BluetoothGattCallback gère les événements : connexion, découverte de services, lecture de caractéristiques, changements RSSI.

Bluetooth Low Energy dans les applications mobiles sur Android nécessite des autorisations explicites BLUETOOTH_SCAN, BLUETOOTH_CONNECT et ACCESS_FINE_LOCATION. Depuis Android 12, les autorisations sont séparées : BLUETOOTH_SCAN pour le scan, BLUETOOTH_CONNECT pour la connexion. ACCESS_FINE_LOCATION n'est nécessaire que pour scanner certains types d'appareils. Sans ces autorisations, l'application ne peut pas fonctionner avec BLE.

Exemple de scan BLE en Kotlin

class BLEScanner(private val bluetoothAdapter: BluetoothAdapter) {

    fun startScan() {
        val scanner = bluetoothAdapter.bluetoothLeScanner
        val settings = ScanSettings.Builder()
            .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
            .build()
        scanner.startScan(null, settings, scanCallback)
    }

    private val scanCallback = object : ScanCallback() {
        override fun onScanResult(callbackType: Int, result: ScanResult) {
            val device = result.device
            val rssi = result.rssi
            Log.d("BLE", "Appareil : ${device.name}, RSSI : $rssi")
        }
    }
}

ScanSettings permet de configurer le mode de scan : LOW_POWER pour économiser la batterie, BALANCED pour les tâches standard, LOW_LATENCY pour une vitesse de détection maximale. ScanFilter réduit la recherche par UUID de service, nom d'appareil ou adresse MAC. Le filtrage réduit la consommation d'énergie et accélère la détection de l'appareil souhaité.

BluetoothGatt : lecture et notifications sur Android

Après avoir créé BluetoothGatt via connectGatt, l'application appelle discoverServices. BluetoothGattCallback contient onServicesDiscovered, onCharacteristicRead, onCharacteristicChanged. Pour recevoir des notifications sur les changements de caractéristiques, il faut appeler setCharacteristicNotification. Le processus nécessite de l'attention : chaque opération GATT est asynchrone et le résultat arrive dans un callback séparé.

iBeacon, Bonding et Advertising Data dans l'écosystème BLE

iBeacon est la technologie d'Apple pour les balises BLE qui transmettent UUID, Major et Minor. L'appareil balise diffuse un paquet publicitaire, et l'application mobile détermine l'emplacement et la distance à partir de ces données. Sur iOS, iBeacon est pris en charge nativement via CLLocationManager. Sur Android, une bibliothèque tierce est nécessaire (par exemple, AltBeacon ou Android iBeacon Library).

Bonding est la procédure de création d'une connexion sécurisée permanente entre appareils BLE. Après le Bonding, les clés de chiffrement sont sauvegardées et les appareils se connectent automatiquement lorsqu'ils sont à nouveau à portée. Sur iOS, le bonding est géré automatiquement par le système. Sur Android — via BluetoothDevice.createBond(). Le bonding est important pour les appareils portables et les trackers d'activité qui nécessuent une reconnexion rapide.

Paquets publicitaires et Manufacturer Specific Data

Advertising Data est un mécanisme de détection clé dans Bluetooth Low Energy. Les fabricants d'appareils peuvent ajouter Manufacturer Specific Data au paquet publicitaire pour transmettre des données personnalisées. Le format du paquet comprend un Company Identifier (2 octets) et des données arbitraires. Sur iOS, CBCentralManager accepte un tableau d'UUID de services pour le filtrage — cela économise la batterie. Sur Android, ScanFilter fonctionne sur le même principe.

Comparaison d'iOS et Android pour le développement BLE

Optimisation BLE : MTU, Connection Interval et mode arrière-plan

MTU (Maximum Transmission Unit) est la taille maximale d'un seul paquet de données Bluetooth Low Energy. Par défaut, la MTU est de 23 octets (3 octets d'en-tête + 20 octets de données). L'augmentation de la MTU à 512 octets accélère considérablement la transmission lors de l'échange de configurations ou de journaux. Sur iOS, maximumWriteValueLength indique la MTU disponible. Sur Android, requestMtu() est utilisé pour augmenter la MTU.

Connection Interval est la fréquence à laquelle l'appareil central interroge le périphérique. Plus l'intervalle est court, plus la vitesse de transmission est élevée, mais aussi la consommation d'énergie. Les valeurs typiques vont de 7,5 ms à 4 secondes. Pour les trackers d'activité, 100 ms suffisent ; pour l'audio — 7,5 ms. Le BLE dans le développement mobile nécessite un équilibre entre vitesse de transmission et autonomie de la batterie de l'appareil.

Mode arrière-plan sur iOS et Android

iOS prend en charge BLE en mode arrière-plan via Background Modes, mais avec des limitations. Une application en arrière-plan reçoit des notifications de caractéristiques mais ne peut pas scanner activement. Le système relance le scan lorsque la position de l'appareil change. Sur Android, le scan en arrière-plan nécessite un Foreground Service avec une notification persistante. Sans cela, le système mobile tuera le processus lors de la minimisation de l'application.

Recommandations pratiques d'optimisation

Pour un fonctionnement fiable du BLE dans les applications mobiles, suivez ces règles. Utilisez notify plutôt que le polling — une caractéristique avec notifications envoie des données lors des changements, économisant la batterie. Définissez la MTU optimale au début de la connexion. Filtrez les appareils par UUID de service lors du scan. Vérifiez la compatibilité de la pile BLE sur différents modèles — les fabricants (Xiaomi, Huawei, Samsung) apportent des modifications qui affectent le comportement du Bluetooth.