iBeacon : définition, principe de fonctionnement des balises et configuration BLE

Qu’est-ce qu’iBeacon ?

iBeacon est une technologie de positionnement intérieur développée par Apple et présentée à la WWDC 2013. Contrairement au GPS, qui ne fonctionne pas dans les bâtiments, iBeacon utilise des balises Bluetooth Low Energy — de petits appareils alimentés par batterie qui transmettent des paquets d’identification fixes. Les appareils iOS et Android reçoivent ces paquets et calculent la distance approximative jusqu’à la balise en fonction du niveau du signal (RSSI).

Histoire et évolution

Le protocole iBeacon a été le premier standard massif de balises BLE, lancé par Apple en 2013 dans iOS 7. Initialement, la technologie était utilisée dans le commerce de détail : les Apple Store ont implémenté iBeacon pour informer les clients des réductions lors de l’entrée dans certaines zones. En 2025, l’infrastructure iBeacon compte des millions de balises installées dans le monde, bien que des protocoles alternatifs soient apparus — Eddystone de Google et AltBeacon open source.

Domaines d’application

iBeacon est utilisé dans cinq scénarios principaux : navigation intérieure (centres commerciaux, aéroports, musées), notifications contextuelles (réductions à l’entrée du magasin), automatisation des flux de travail (marquage de présence), logistique et gestion d’entrepôt, et guides touristiques avec lecture automatique du contenu lors de l’approche d’un objet. Selon ABI Research (2025), le marché des balises BLE est estimé à 3,2 milliards d’appareils en service.

Structure du protocole iBeacon et format du paquet

Le paquet iBeacon est une Advertising PDU (Protocol Data Unit), transmise sur le canal publicitaire BLE aux fréquences 2402, 2426 et 2480 MHz. Le format du paquet est fixe et se compose de quatre champs : préfixe Apple iBeacon (0x4C000215), UUID de 16 octets, Major de 2 octets et Minor de 2 octets, ainsi qu’un TX Power de 1 octet pour l’étalonnage de la distance. La taille totale des données est de 30 octets, tenant dans une seule BLE Advertising PDU.

Hiérarchie UUID, Major et Minor

Les identifiants iBeacon forment une hiérarchie à trois niveaux. L’UUID est attribué à l’organisation (par exemple, une chaîne de magasins), Major au magasin ou étage spécifique, Minor au point spécifique dans la zone (zone de caisse, département produit). Cette hiérarchie permet à l’application de réagir de manière flexible à différents niveaux de contexte : à l’entrée du magasin (UUID + Major), l’application peut charger le plan d’étage, et à l’approche d’un département spécifique (Minor), afficher des informations sur le produit.

TX Power et étalonnage

Le champ TX Power est la valeur de référence du niveau du signal (RSSI) à 1 mètre de la balise. Lors de la réception du paquet, l’appareil enregistre le RSSI réel et calcule la distance selon la formule : distance = 10^((TX_Power - RSSI) / (10 * n)), où n est le coefficient d’atténuation du milieu (généralement 2-4). Un étalonnage correct du TX Power est crucial pour la précision du positionnement : une erreur de 1 dBm donne une imprécision allant jusqu’à 30 % à 5 mètres de distance.

Zones de proximité : Immediate, Near, Far

iOS définit trois zones de proximité basées sur la distance calculée jusqu’à la balise : Immediate (moins de 0,5 mètre), Near (0,5 à 3 mètres) et Far (3 à 30-50 mètres selon les conditions). La distance exacte n’est pas communiquée — seule la catégorie. Cela est intentionnel : le RSSI est sensible aux interférences, aux réflexions du signal et à l’influence du corps humain, donc les catégories offrent une détermination de position plus stable.

Immediate — proximité immédiate

Immediate est la zone de contact direct, lorsque l’appareil se trouve à quelques centimètres de la balise. Utilisée dans les scénarios nécessitant une précision maximale : paiement par terminal, ouverture de serrure numérique, vérification à un point de contrôle. Dans la zone Immediate, le RSSI est généralement compris entre -30 et -60 dBm.

Near — distance moyenne

La zone Near est la principale zone de travail d’iBeacon, couvrant les distances de 0,5 à 3 mètres. Utilisée pour la navigation intérieure — par exemple, à l’approche d’une vitrine avec un produit, l’application affiche des informations détaillées. Dans la zone Near, le RSSI varie de -60 à -80 dBm avec un étalonnage TX Power = -59 dBm.

Far — longue distance

Far est la zone maximale de détection du signal de la balise. Utilisée pour la surveillance d’entrée dans une région (par exemple, entrée dans un centre commercial). À distance Far, le RSSI est généralement inférieur à -80 dBm, et la précision de la détermination de distance diminue considérablement. Pour la surveillance d’entrée, les API système region monitoring sont utilisées, et non la détermination de zone exacte.

Surveillance de région sur iOS

Une région iBeacon est une zone virtuelle définie par l’UUID (et optionnellement Major + Minor). iOS permet de surveiller jusqu’à 20 régions simultanément avec CLLocationManager. Lors de l’entrée dans une région, le système réveille l’application même en mode arrière-plan ou arrêtée et envoie une notification via le délégué locationManager:didEnterRegion. À la sortie de la région, locationManager:didExitRegion est appelé.

import CoreLocation

let locationManager = CLLocationManager()
let region = CLBeaconRegion(
    uuid: UUID(uuidString: "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0")!,
    identifier: "myBeaconRegion"
)
locationManager.delegate = self
locationManager.requestAlwaysAuthorization()
locationManager.startMonitoring(for: region)

Ranging — détermination de la zone exacte

Pour déterminer la zone (Immediate, Near, Far), on utilise le ranging — le scan des balises en temps réel. Contrairement à la surveillance, le ranging ne fonctionne qu’en mode actif de l’application et nécessite une autorisation d’accès à la localisation. La méthode locationManager:didRangeBeacons:inRegion retourne un tableau de CLBeacon avec les champs proximity (CLProximity.immediate, .near, .far, .unknown), accuracy (distance étalonnée en mètres) et rssi.

func locationManager(
    _ manager: CLLocationManager,
    didRangeBeacons beacons: [CLBeacon],
    in region: CLBeaconRegion
) {
    for beacon in beacons {
        switch beacon.proximity {
        case .immediate:
            print("Proximité immédiate")
        case .near:
            print("Proximité proche")
        case .far:
            print("Proximité lointaine")
        default:
            print("Proximité inconnue")
        }
    }
}

iBeacon sur Android : AltBeacon et intégration multiplateforme

Android ne prend pas en charge nativement iBeacon, car le protocole est une solution propriétaire d’Apple. Cependant, avec des bibliothèques tierces comme AltBeacon de Radius Networks (désormais partie de l’organisation Open Beacon), les développeurs peuvent intégrer iBeacon dans les applications Android. La bibliothèque AltBeacon implémente le scan des paquets BLE, l’analyse du format iBeacon et l’émulation du ranging et de la surveillance de région similaires à l’API iOS.

val beaconManager = BeaconManager.getInstanceForApplication(context)
beaconManager.beaconParsers.add(
    BeaconParser().setBeaconLayout(
        "m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
    )
)
beaconManager.backgroundBetweenScanPeriod = 5000
beaconManager.foregroundScanPeriod = 1100
beaconManager.bind(this)

Analyse du paquet iBeacon sur Android

Le format d’analyse d’iBeacon dans la bibliothèque AltBeacon est défini par la chaîne layout : « m:2-3=0215 » — vérification de deux octets du marqueur iBeacon, « i:4-19 » — UUID de 16 octets, « i:20-21 » — Major, « i:22-23 » — Minor, « p:24-24 » — TX Power. Le même format est pris en charge pour Eddystone et d’autres protocoles, ce qui fait d’AltBeacon une bibliothèque universelle pour travailler avec les balises BLE sur Android.

Limitations sur Android

Sur Android, le travail avec iBeacon présente trois limitations principales : le scan en arrière-plan est limité par les fabricants (Xiaomi, Huawei, Samsung tuent souvent les processus en arrière-plan), la précision du RSSI est inférieure à celle d’iOS en raison des différences dans les piles BLE, et l’autorisation ACCESS_FINE_LOCATION est requise depuis Android 6.0 et BLUETOOTH_SCAN depuis Android 12.

iBeacon vs Eddystone : comparaison des protocoles de balises

Eddystone est un protocole ouvert de balises BLE de Google, présenté en 2015. Contrairement à iBeacon, Eddystone prend en charge quatre types de paquets : Eddystone-UID (identifiant fixe), Eddystone-URL (transmission d’URL pour le Physical Web), Eddystone-TLM (télémétrie de la balise — charge de la batterie, température) et Eddystone-EID (identifiant crypté pour la protection contre le clonage). Bien que Google ait arrêté le développement du Physical Web en 2022, le protocole Eddystone continue d’être utilisé dans les solutions d’entreprise.

Choix du protocole pour le projet

Le choix entre iBeacon et Eddystone dépend de la plateforme cible et du scénario d’utilisation. iBeacon est préférable pour les applications iOS grâce à l’intégration native avec CoreLocation et à la surveillance de région en arrière-plan. Eddystone est mieux adapté aux projets orientés Android et aux scénarios Physical Web, où la balise transmet une URL sans installation d’application. Pour les projets multiplateformes, on utilise souvent AltBeacon, qui prend en charge les deux protocoles.

Problèmes courants et limitations d’iBeacon

Lors de l’implémentation d’iBeacon, les développeurs rencontrent plusieurs limitations à prendre en compte dès la phase de conception de l’architecture. Une mauvaise évaluation de ces facteurs conduit à une navigation instable, à des déclenchements intempestifs et à une décharge plus rapide que prévue des batteries des balises.

Influence de l’environnement sur le RSSI

Le niveau du signal RSSI subit des fluctuations importantes dues aux réflexions sur les murs, aux structures métalliques, à la présence de personnes et à d’autres appareils sans fil dans la bande des 2,4 GHz. Dans un environnement intérieur, la variation du RSSI pour une même balise peut atteindre 10-15 dBm par minute, rendant le calcul de distance imprécis sans utilisation de filtres (moyenne mobile, filtre de Kalman).

Limite de surveillance de région

iOS prend en charge la surveillance d’au maximum 20 régions simultanément par application. Pour les projets nécessitant une couverture de grande superficie (aéroport, stade), cela est insuffisant. La solution consiste à utiliser une commutation dynamique des régions : lors de l’entrée dans une région, les régions voisines sont activées et les régions éloignées sont désactivées.

Temps de réponse de la surveillance

Le délai entre l’entrée dans une région et la réception de la notification peut varier de 1 à 30 secondes selon les conditions. iOS scanne les balises périodiquement pour économiser la batterie, il ne faut donc pas s’attendre à une réaction instantanée. Pour les scénarios critiques en termes de temps (ouverture de porte à l’approche), il est recommandé d’utiliser le ranging Immediate, mais il ne fonctionne qu’en mode actif de l’application.