Bluetooth, Wi-Fi et NFC : comprendre les communications radio de proximité

Objectif pédagogique

Dans le Cours 01 du Module 02, nous avons volontairement évité de commencer par un catalogue de technologies. Nous avons d’abord étudié ce qu’elles ont toutes en commun : fréquence, spectre, modulation, puissance, sensibilité, bruit, antennes, propagation, budget de liaison, consommation énergétique et exposition radio.

Nous savons désormais qu’une technologie radio ne peut pas être correctement évaluée avec une simple indication de portée ou de débit.

Nous pouvons maintenant descendre d’un niveau supplémentaire. Lorsqu’un objet utilise Bluetooth, Wi-Fi ou NFC, comment se rend-il visible, trouve-t-il un pair et établit-il une relation ? Que transporte réellement une caractéristique GATT, et que signifie « être connecté au Wi-Fi » lorsque le service distant reste inaccessible ? Les réponses exigent de suivre les protocoles, le temps radio et les réveils énergétiques, pas seulement de comparer les débits annoncés.

NFC pose encore un autre problème : comment un tag sans batterie répond-il au lecteur, et que prouve réellement cette proximité ? Pour les trois technologies, la question transversale reste : où se situe la frontière de sécurité, de l’interface radio jusqu’à la décision applicative ?

Ce cours étudie trois technologies souvent regroupées sous l’étiquette très générale de « communications sans fil de proximité », mais qui reposent sur des philosophies profondément différentes.

Bluetooth, Wi-Fi et NFC ne sont pas trois versions plus ou moins puissantes d’une même technologie. Ils répondent à des problèmes différents et organisent différemment la découverte, la communication, l’énergie, l’architecture et la confiance.

Public cible

Ce cours s’adresse aux étudiants et professionnels de l’IoT, des télécommunications, des réseaux, des systèmes embarqués et de la cybersécurité souhaitant comprendre suffisamment profondément les interfaces radio de proximité pour pouvoir les choisir, les intégrer, les exploiter ou les évaluer.

Il suppose les notions introduites dans le Cours 01 du Module 02, notamment fréquence, canal, puissance, sensibilité, propagation, RSSI, énergie et budget de liaison.

Objectifs d’apprentissage

À la fin de ce cours, vous devrez être capable de :

• distinguer Bluetooth Classic et Bluetooth Low Energy ;
• comprendre l’organisation générale d’une pile Bluetooth LE ;
• expliquer les mécanismes d’advertising, scanning et connexion ;
• distinguer les rôles Central/Peripheral de Client/Server ;
• comprendre ATT, GATT, services, caractéristiques et descripteurs ;
• expliquer l’influence des paramètres Bluetooth LE sur l’autonomie ;
• comprendre les principes de pairing et bonding ;
• interpréter correctement les principales méthodes d’association Bluetooth ;
• comprendre pourquoi Bluetooth et Wi-Fi peuvent se perturber mutuellement dans la bande 2,4 GHz ;
• expliquer ce qui se passe réellement lorsqu’un objet rejoint un réseau Wi-Fi ;
• distinguer couche Wi-Fi, réseau IP et protocole applicatif ;
• comprendre les rôles d’un point d’accès, d’un SSID et d’une station ;
• expliquer les principaux compromis entre 2,4 GHz, 5 GHz et 6 GHz ;
• comprendre pourquoi les générations Wi-Fi récentes n’améliorent pas uniquement le débit ;
• expliquer les différences entre WPA2, WPA3, authentification personnelle et entreprise ;
• comprendre le fonctionnement conceptuel du NFC ;
• distinguer Reader/Writer, Card Emulation et Peer-to-Peer ;
• expliquer pourquoi proximité physique et sécurité cryptographique sont deux propriétés distinctes ;
• choisir rationnellement entre Bluetooth LE, Wi-Fi et NFC selon un cas d’usage.

1. Trois technologies de proximité, trois philosophies

Un premier réflexe consiste souvent à comparer les technologies sans fil avec un tableau comportant trois colonnes :

portée — débit — consommation

Cette comparaison est utile, mais insuffisante.

Prenons trois objets.

Une montre doit envoyer périodiquement quelques mesures physiologiques vers un smartphone.

Une caméra connectée doit transporter plusieurs mégabits par seconde vers le réseau local.

Un badge doit permettre à son utilisateur de s’identifier lorsqu’il l’approche volontairement d’un lecteur.

Ces trois systèmes communiquent sans câble.

Pourtant, leurs contraintes sont radicalement différentes.

La montre doit économiser son énergie et profiter du smartphone comme intermédiaire.

La caméra doit transporter beaucoup de données et bénéficier d’une connexion IP directe.

Le badge doit fonctionner à très courte distance et peut éventuellement ne disposer d’aucune batterie.

Le choix technologique commence donc moins par :

Quelle technologie est la meilleure ?

que par :

Quelle forme de communication le système doit-il réaliser ?

Cette question va guider tout le cours.

Suivre la donnée, pas seulement le signal

Le Cours 01 nous a conduits du bit à l’onde. Nous allons maintenant faire aussi le trajet inverse : lorsqu’une application affiche une température, par quelles couches cette valeur est-elle passée, lesquelles ont ajouté des informations de transport, et à quel endroit la confiance a-t-elle été établie ? Une technologie radio ne se comprend réellement que lorsqu’on sait suivre une donnée depuis l’application jusqu’à la couche physique (PHY), puis remonter vers l’application distante.

Ces chaînes ne sont pas des séquences universelles : tous les usages BLE n’emploient pas GATT, MQTT ne fonctionne pas sans adaptation sur n’importe quel transport, et un échange NFC n’utilise pas nécessairement NDEF. Elles servent de carte de lecture. À chaque problème, demandons-nous d’abord : à quelle couche se situe le mécanisme observé ?

PARTIE I — BLUETOOTH

2. Il n’existe pas un seul Bluetooth

Le terme Bluetooth recouvre aujourd’hui deux grandes familles radio qu’il faut distinguer :

Bluetooth Classic, également appelé BR/EDR ;

et

Bluetooth Low Energy, ou Bluetooth LE.

Ils partagent notamment l’utilisation de la bande autour de 2,4 GHz et appartiennent à la même famille de spécifications, mais leurs architectures et leurs objectifs historiques ne sont pas identiques.

Bluetooth Classic a notamment été largement développé et adopté pour des flux continus tels que l’audio entre un téléphone et un casque, une enceinte ou un système automobile.

Bluetooth LE a été conçu avec une priorité beaucoup plus forte accordée aux communications intermittentes et à la consommation énergétique réduite.

Cela ne signifie plus aujourd’hui :

Classic = audio
LE = capteurs uniquement

Bluetooth LE possède désormais ses propres capacités audio, de diffusion, de localisation et de nombreuses autres fonctions.

La distinction reste néanmoins essentielle pour comprendre l’architecture d’un produit.

Avant de demander « cet appareil utilise-t-il Bluetooth ? », il faut souvent demander : quel Bluetooth et pour quel type de transport ?

La pile Bluetooth LE : du capteur au PHY

Une application peut produire une valeur métier, par exemple une température de 23,6 °C. Si le produit expose cette valeur avec GATT, elle est rangée dans une characteristic appartenant à un service ; des descripteurs peuvent préciser son usage et des permissions déterminent les opérations autorisées. GATT décrit cette organisation et les procédures de lecture ou de notification. ATT transporte les opérations sur les attributs identifiés par un handle. Confondre la caractéristique avec un paquet radio efface plusieurs décisions de conception.

Les messages ATT passent par L2CAP, qui multiplexe les protocoles du Host et assure, selon le canal et le mécanisme utilisés, l’adaptation ainsi que la segmentation et le réassemblage. SMP intervient notamment pendant le pairing ; ce n’est pas le chemin ordinaire de chaque mesure. Plus bas, la Link Layer organise les événements de connexion, la sélection des canaux, les retransmissions et le chiffrement de liaison. Le PHY fixe la manière d’émettre les symboles, par exemple en LE 1M, LE 2M ou LE Coded. Chaque étage a ses limites de taille, son coût temporel et ses propres causes d’échec.

On parle de Host pour les couches supérieures et de Controller pour la Link Layer et la radio. HCI est l’interface fonctionnelle entre ces deux blocs : commandes et données descendent, événements et données remontent. Host et Controller peuvent se trouver dans une seule puce ou dans deux composants distincts. Pour le diagnostic, cette distinction explique pourquoi « l’application a demandé une notification » ne signifie pas encore « un paquet a été émis ».

3. Bluetooth LE et la bande des 2,4 GHz

Bluetooth LE utilise la bande ISM autour de 2,4 GHz.

Cette bande est divisée en 40 canaux espacés de 2 MHz.

Parmi eux, trois occupent une place particulière :

37, 38 et 39

Ce sont les canaux primaires d’advertising.

Les 37 autres peuvent notamment être utilisés pour les communications générales une fois la liaison organisée.

Cette répartition illustre immédiatement une idée importante.

Bluetooth LE ne repose pas sur un objet qui choisit un canal puis y reste indéfiniment.

Une connexion Bluetooth LE utilise au contraire des mécanismes de saut de fréquence adaptatif.

Au fil des événements de connexion, les équipements changent de canal selon un algorithme commun.

Si certains canaux sont fortement perturbés, ils peuvent être identifiés comme défavorables et évités.

Cette capacité est particulièrement importante parce que Bluetooth partage la bande 2,4 GHz avec de nombreuses autres technologies, notamment le Wi-Fi.

4. Advertising : exister avant de se connecter

Imaginons un capteur de température Bluetooth LE placé sur une table.

Votre smartphone ne sait pas encore qu’il existe.

Comment peut-il le découvrir ?

Le capteur commence généralement par advertiser.

Il émet périodiquement de petites trames contenant certaines informations.

Le smartphone effectue de son côté un scan.

Lorsqu’il reçoit l’advertising du capteur, il peut découvrir sa présence et, selon la configuration, obtenir certaines informations ou demander l’établissement d’une connexion.

La logique générale devient :

Peripheral → advertising → Central

puis éventuellement :

Central → demande de connexion → Peripheral

Cette phase est fondamentale.

Une grande partie de l’écosystème Bluetooth LE commence donc avant toute connexion.

L’advertising peut même être utilisé sans connexion permanente.

Les beacons en sont un exemple classique : ils peuvent diffuser périodiquement une information destinée à être observée par les équipements situés à proximité.

Les advertisements dits legacy utilisent les canaux primaires 37, 38 et 39. L’extended advertising conserve une annonce primaire mais peut déplacer une partie des données et de la suite de l’échange vers des canaux secondaires. Il serait donc inexact de décrire tout Bluetooth LE contemporain comme trois petits paquets sur trois canaux. Dans les deux cas, l’intervalle d’émission et le temps de scan restent des paramètres d’énergie et de délai de découverte.

5. Advertising interval : un paramètre devient un compromis énergétique

Supposons que le capteur émette un advertising toutes les 20 millisecondes.

Un smartphone qui arrive à proximité a de fortes chances de le découvrir rapidement.

Mais le capteur active très souvent sa radio.

Supposons maintenant qu’il n’émette qu’une fois toutes les quelques secondes.

La consommation moyenne peut fortement diminuer.

En revanche, la découverte peut devenir plus lente.

Nous retrouvons immédiatement le raisonnement du Cours 01 :

réactivité ↑ → activité radio ↑ → consommation potentielle ↑

et inversement :

activité radio ↓ → autonomie potentielle ↑ → découverte potentiellement plus lente

Le paramétrage radio est donc déjà une décision d’architecture.

Il ne suffit pas de choisir Bluetooth LE pour obtenir une faible consommation.

Il faut également l’utiliser correctement.

6. Scanner coûte lui aussi de l’énergie

Le périphérique qui advertise n’est pas le seul à consommer.

Le scanner doit ouvrir régulièrement son récepteur afin d’écouter les canaux appropriés.

Deux paramètres deviennent particulièrement importants :

scan interval : fréquence à laquelle les fenêtres d’écoute sont planifiées ;

scan window : durée pendant laquelle le récepteur reste effectivement à l’écoute.

Si la fenêtre se rapproche de l’intervalle, le récepteur écoute presque continuellement.

La découverte est excellente.

L’énergie consommée augmente.

Si les fenêtres sont courtes et espacées, l’énergie diminue mais certaines émissions peuvent être manquées et la découverte peut prendre davantage de temps.

Encore une fois :

Une technologie dite basse consommation ne supprime jamais les compromis. Elle donne surtout à l’architecte des mécanismes permettant de les gérer.

7. Central et Peripheral : des rôles radio

Lorsqu’une connexion Bluetooth LE est créée, les termes Central et Peripheral définissent des rôles dans l’établissement et le fonctionnement de la liaison.

Dans notre exemple :

le capteur peut être Peripheral ;

le smartphone peut être Central.

Le Central initie généralement la connexion à partir des advertisements reçus.

Cette terminologie doit cependant être distinguée d’une autre paire de rôles souvent confondue :

Client / Server.

Central n’est pas synonyme de Client.

Peripheral n’est pas synonyme de Server.

Nous allons comprendre pourquoi.

8. GATT : donner un sens aux données

Une fois connectés, les deux équipements doivent savoir comment organiser et interpréter les informations échangées.

C’est ici qu’intervient notamment GATT — Generic Attribute Profile.

Un serveur GATT expose des données organisées sous forme de :

services

contenant des :

characteristics

qui peuvent elles-mêmes disposer de :

descriptors.

Prenons une station environnementale.

Elle pourrait exposer :

Service environnement

puis :

• Characteristic température ;
• Characteristic humidité ;
• Characteristic niveau batterie.

Le smartphone peut découvrir le service et ses caractéristiques puis effectuer certaines opérations.

Selon la configuration, une caractéristique peut notamment être :

• lue ;
• écrite ;
• notifiée ;
• indiquée.

L’application n’a donc pas à interpréter un flux arbitraire de bits sans structure.

Elle dispose d’un modèle de données.

9. ATT et GATT ne sont pas la même chose

Cette distinction est importante.

ATT — Attribute Protocol fournit le mécanisme permettant de manipuler des attributs.

GATT — Generic Attribute Profile construit au-dessus de ce mécanisme une organisation standardisée des services, caractéristiques et procédures.

Nous pouvons simplifier ainsi :

ATT = mécanisme d’accès aux attributs

GATT = manière d’organiser et d’utiliser ces attributs

Cette distinction illustre exactement ce que nous avons appris dans le Cours 01 : une technologie possède plusieurs couches.

Une Characteristic température n’est donc pas « envoyée directement par l’antenne ».

Entre l’application et la radio existent plusieurs traitements protocolaires.

10. Client/Server n’est pas Central/Peripheral

Reprenons notre thermomètre.

Le thermomètre est Peripheral.

Il peut également être serveur GATT en exposant ses mesures.

Le smartphone est Central.

Il peut être client GATT et lire ces mesures.

Cette combinaison est fréquente :

Central + Client

Peripheral + Server

Mais elle n’est pas une loi.

Les rôles radio et les rôles applicatifs appartiennent à des dimensions différentes.

Cette distinction devient importante dès que les architectures deviennent plus complexes.

Du 23,6 °C à l’onde radio

11. Read, Write, Notify et Indicate : quatre comportements distincts

Supposons qu’une application souhaite afficher le rythme cardiaque provenant d’un bracelet.

Une première approche serait de demander continuellement :

Quelle est la valeur maintenant ?

C’est une logique de Read répété.

Mais cela multiplie les échanges.

Une autre approche consiste à demander au bracelet :

Préviens-moi lorsque la valeur change ou lorsqu’une nouvelle mesure est disponible.

Le bracelet peut alors envoyer des notifications.

Cela permet souvent un fonctionnement plus efficace.

De manière générale :

Read : le client demande une valeur.

Write : le client transmet une valeur ou une commande.

Notify : le serveur envoie spontanément une nouvelle valeur au client sans acquittement applicatif GATT de type indication.

Indicate : similaire dans l’idée, mais avec confirmation au niveau concerné.

Le choix dépend des besoins de fiabilité, de fréquence et d’énergie.

ATT_MTU : le débit utile n’est pas le débit radio

Sur le bearer ATT LE non amélioré, la valeur ATT_MTU initiale est de 23 octets ; une procédure d’échange peut déterminer une taille supérieure compatible avec les deux équipements. Une notification ATT classique contient un octet de code d’opération, deux octets de handle et la valeur. Avec un ATT_MTU de 23, il reste donc au plus 20 octets pour cette valeur dans une notification de ce type. Un message applicatif de 45 octets ne rentre pas dans une seule telle notification : l’application doit prévoir plusieurs notifications, ou adopter un mécanisme de transport adapté.

Il ne faut pas confondre ATT_MTU avec la taille de la charge utile Link Layer. L2CAP et les couches inférieures ont leurs propres règles de taille et peuvent segmenter puis réassembler les données. La Data Length Extension concerne la capacité des paquets de données de la Link Layer ; augmenter l’ATT_MTU seul n’impose donc pas qu’un énorme paquet unique traverse l’air. Les bearers ATT améliorés et les capacités négociées changent également le résultat. Avant d’annoncer un débit, il faut connaître la pile réellement utilisée.

À titre d’intuition, avec 20 octets de valeur par notification, 45 octets utiles demandent au moins trois notifications de ce format, même avant de compter les autres en-têtes et les événements de connexion. « LE 1M » décrit un mode physique, pas un mégabit par seconde garanti à l’application.

12. LE 1M, LE 2M et LE Coded : même Bluetooth, compromis différents

Bluetooth LE peut utiliser plusieurs couches physiques.

Le LE 1M PHY constitue une référence commune.

Le LE 2M PHY augmente le débit radio brut.

Le LE Coded PHY ajoute davantage de redondance afin d’améliorer la capacité de réception dans des conditions difficiles et d’étendre potentiellement la couverture, au prix d’un débit réduit et d’un temps d’occupation supérieur.

Cette possibilité est particulièrement instructive.

Le même protocole Bluetooth LE peut donc changer de compromis radio.

On retrouve directement ce que nous avons appris dans le Cours 01 :

débit ↑ n’implique pas automatiquement portée ↑ ;

redondance ↑ peut améliorer la robustesse mais augmente le temps nécessaire pour transporter l’information.

Le choix d’un PHY dépend du produit.

Une montre située à quelques dizaines de centimètres du téléphone n’a pas le même besoin qu’un capteur placé à l’extrémité d’un grand bâtiment.

13. Connection interval : l’horloge énergétique de la liaison

Une connexion BLE n’implique pas nécessairement que les deux radios transmettent ou écoutent continuellement.

La communication s’organise autour d’événements de connexion.

Le connection interval définit notamment l’espacement temporel entre ces événements.

Un intervalle court permet généralement une meilleure réactivité et potentiellement davantage de données.

Mais les radios doivent se réveiller plus souvent.

Un intervalle plus long permet aux équipements de dormir davantage, au prix d’une latence accrue.

Cette relation peut être résumée ainsi :

intervalle court → réactivité ↑ → activité radio ↑

intervalle long → consommation moyenne ↓ → latence potentielle ↑

La maîtrise de ces paramètres est l’une des raisons pour lesquelles deux produits utilisant exactement la même puce Bluetooth peuvent avoir des autonomies radicalement différentes.

Une connexion n’est pas une radio ouverte en permanence : sommeil → événement de connexion → échanges éventuels → sommeil. Le connection interval fixe la cadence de ces occasions d’échange. La peripheral latency peut permettre au périphérique de ne pas participer à certains événements lorsqu’il n’a rien à transmettre ; le supervision timeout borne le temps sans paquet reçu avant que le lien soit considéré perdu. Ces paramètres se négocient et doivent rester cohérents entre eux.

Un capteur qui publie une mesure toutes les quelques secondes peut accepter davantage d’attente qu’une manette interactive. En revanche, un intervalle très long et une forte latence compliquent une commande urgente ou la détection rapide d’une rupture de lien. Pour estimer l’énergie, on peut partir de E = V × I × t : à 3 V et 15 mA, un réveil radio de 5 ms représente 0,225 mJ ; cent réveils de ce type représentent 22,5 mJ, avant même les scans et retransmissions. Réduire le nombre de réveils aide souvent, mais une reconnexion plus longue peut annuler le gain.

14. Pairing et bonding : ne pas confondre

Lorsque deux équipements Bluetooth établissent une relation sécurisée, deux termes reviennent souvent.

Pairing désigne le processus permettant notamment de créer les informations de sécurité nécessaires à la relation.

Bonding désigne la conservation de certaines de ces informations afin que les équipements puissent se reconnaître ultérieurement sans recommencer entièrement la procédure.

Tous les appareils n’ont pas nécessairement besoin d’un bonding permanent.

Un objet temporairement utilisé par un technicien peut avoir des besoins différents d’une montre associée pendant plusieurs années au smartphone de son propriétaire.

15. Just Works n’est pas « sécurité maximale sans effort »

Bluetooth LE prévoit plusieurs modèles d’association, notamment :

• Just Works ;
• Passkey Entry ;
• Numeric Comparison ;
• Out-of-Band.

Le modèle réellement utilisable dépend notamment des capacités d’entrée/sortie de l’équipement.

Un petit capteur sans écran ni clavier ne peut évidemment pas présenter la même expérience qu’un smartphone.

C’est ici qu’apparaît un problème classique de l’IoT :

l’absence d’interface utilisateur limite les possibilités d’authentification humaine.

Le nom Just Works est parfois trompeur pour les débutants.

Il décrit une expérience simple.

Il ne signifie pas :

« protection maximale contre toutes les attaques d’interposition ».

L’architecte doit donc toujours examiner le modèle d’association réellement utilisé et la menace pertinente pour le produit.

16. LE Secure Connections

Les générations modernes de Bluetooth LE peuvent utiliser LE Secure Connections, qui améliore fortement le mécanisme d’établissement des clés par rapport aux anciennes méthodes de pairing.

Mais même une excellente primitive cryptographique ne résout pas automatiquement tous les problèmes.

La sécurité finale dépend également :

• de la méthode d’association ;
• de la validation effectuée par l’utilisateur ;
• de la qualité des clés ;
• de la protection des secrets dans le firmware ;
• de la configuration des permissions GATT ;
• de la gestion du bonding ;
• du comportement de l’application ;
• des mises à jour du produit.

C’est un principe que nous retrouverons régulièrement :

La cryptographie peut être correcte alors que l’architecture de sécurité reste mauvaise.

17. L’adresse Bluetooth n’est pas toujours une identité permanente

Les systèmes modernes doivent également limiter les possibilités de suivi passif des utilisateurs ou équipements.

Bluetooth LE prévoit des mécanismes permettant l’utilisation d’adresses privées changeantes.

Cela rappelle une distinction importante :

adresse radio ≠ identité métier

Un produit correctement conçu ne doit pas supposer aveuglément qu’une adresse observée dans l’environnement constitue toujours une identité immuable et fiable.

Cette question devient particulièrement importante pour les wearables, smartphones et objets personnels.

Avec une Resolvable Private Address, l’adresse diffusée peut tourner, tandis qu’un équipement autorisé emploie une Identity Resolving Key (IRK) pour reconnaître son pair. Cela améliore la confidentialité face au suivi naïf par adresse fixe, sans résoudre à lui seul toute possibilité de tracking : cadence d’émission, contenu d’advertising ou comportement applicatif peuvent encore distinguer un produit. Pour l’inventaire et le dépannage, on doit séparer l’identité gérée par le service de l’adresse momentanément vue par un scanner.

Bluetooth ne sert plus uniquement à transporter des données

Bluetooth Channel Sounding illustre cette évolution : le contrôleur réalise des mesures radio que l’application peut exploiter pour estimer une distance, notamment par des méthodes de phase et de temps aller-retour. Cela ouvre des usages de localisation ou de contrôle d’accès plus robustes que la seule déduction de distance à partir du RSSI. La spécification Bluetooth Core 6.3 décrit ce mécanisme et ses évolutions ; elle ne transforme cependant pas toute mesure de distance en preuve suffisante d’identité ou d’autorisation. Le système complet doit encore décider qui peut demander la mesure, comment interpréter son incertitude et quelle action en découle.

Pairing ≠ chiffrement ≠ authentification ≠ autorisation ≠ bonding

Le pairing établit initialement les éléments de sécurité entre deux appareils. Le chiffrement protège la confidentialité des échanges sur la liaison. L’authentification dépend de la méthode d’association et du niveau de confiance réellement obtenu : Just Works ne fournit pas la même résistance à une interposition qu’une méthode avec vérification appropriée. Le bonding conserve la relation et des clés pour les connexions futures. Ces opérations ne répondent pas toutes à la même question.

L’autorisation est la décision de l’application : cet appareil, même reconnu et sur une liaison chiffrée, peut-il modifier le seuil d’alarme ou lire l’historique ? Une permission GATT peut exiger une liaison sécurisée, mais un service sensible peut nécessiter en plus un rôle, une validation métier et une traçabilité. La cryptographie du transport ne remplace jamais cette décision.

PARTIE II — WI-FI

18. Wi-Fi n’est pas Internet

C’est probablement l’une des confusions les plus fréquentes.

Un équipement peut être connecté au Wi-Fi sans avoir accès à Internet.

Wi-Fi fournit principalement une connectivité de réseau local sans fil fondée sur la famille IEEE 802.11.

Après la liaison radio et l’association au réseau, d’autres couches prennent le relais.

Une chaîne classique peut ressembler à :

objet → Wi-Fi → point d’accès → réseau local → routeur → Internet → cloud

Mais elle pourrait également être :

objet → Wi-Fi → point d’accès → serveur local

sans Internet.

De la même manière :

MQTT n’est pas Wi-Fi.

MQTT peut fonctionner au-dessus de TCP/IP, lui-même transporté par Wi-Fi, Ethernet ou d’autres réseaux.

Comprendre ces couches évite énormément d’erreurs d’architecture et de diagnostic.

19. Station, Access Point et BSS

Dans une architecture Wi-Fi classique, nous rencontrons notamment :

STA — Station : équipement Wi-Fi client ;

AP — Access Point : point d’accès ;

BSS — Basic Service Set : ensemble de base structurant la communication autour d’un point d’accès dans l’architecture la plus courante.

Un capteur, un ordinateur ou une caméra peuvent agir comme stations.

Le point d’accès fait le lien entre le réseau radio et l’infrastructure réseau associée.

Il joue donc un rôle beaucoup plus important qu’une simple « antenne Wi-Fi ».

20. SSID : le nom n’est pas le réseau entier

Le SSID identifie logiquement un réseau Wi-Fi présenté aux utilisateurs ou équipements.

Mais deux notions ne doivent pas être confondues :

SSID : nom logique ;

BSSID : identifiant associé à une instance radio/BSS, généralement lié à une interface du point d’accès.

Dans une infrastructure d’entreprise, plusieurs points d’accès peuvent diffuser le même SSID.

Un utilisateur se déplace alors entre plusieurs cellules radio tout en restant logiquement sur le même réseau.

Cela explique pourquoi « je vois le même nom Wi-Fi » ne signifie pas nécessairement « je communique toujours avec la même radio ».

21. Rejoindre le Wi-Fi est une chaîne de plusieurs opérations

Lorsqu’un objet « se connecte au Wi-Fi », plusieurs mécanismes peuvent se succéder.

De manière simplifiée :

découverte du réseau

→ authentification / établissement de la sécurité

→ association

→ configuration IP

→ résolution DNS éventuelle

→ connexion au service applicatif

Prenons un capteur MQTT.

La radio peut parfaitement être associée au point d’accès alors que :

• l’adresse IP n’a pas été obtenue ;
• la passerelle IP est inaccessible ;
• le DNS ne fonctionne pas ;
• le serveur MQTT est indisponible ;
• le certificat TLS est expiré.

Pour l’utilisateur, le résultat paraît identique :

« l’objet ne marche pas ».

Pour l’ingénieur, ces situations sont radicalement différentes.

La chronologie exacte dépend du mode de sécurité, mais une vue utile est : scan → découverte → authentification 802.11 → association → établissement des clés de protection → configuration IP → ARP ou Neighbor Discovery selon IP → DNS si requis → transport → TLS si utilisé → application. L’authentification 802.11 initiale et l’authentification métier du serveur sont deux étapes distinctes. Après l’association, le terminal peut encore échouer parce qu’il n’a pas de passerelle, parce que le certificat du broker est rejeté ou parce que son identité applicative est révoquée.

Découvrir un WLAN : scan et familles de trames

En passive scan, la station écoute notamment les beacons diffusés par les points d’accès. En active scan, elle peut envoyer des probe requests et recevoir des probe responses. La stratégie influe sur le délai de découverte, l’énergie dépensée et les informations révélées selon la configuration. Un capteur qui ne connaît qu’un réseau fixe n’a pas nécessairement les mêmes besoins de scan qu’un terminal industriel mobile.

IEEE 802.11 distingue les trames Management, qui participent notamment aux beacons, probes, échanges d’authentification et d’association ; les trames Control, comme ACK, RTS ou CTS, qui coordonnent certains aspects de l’accès au médium ; et les trames Data, qui transportent les données des couches supérieures. La radio transmet donc bien davantage que les seuls paquets IP observés par l’application. En diagnostic, une absence de trafic MQTT peut naître d’un échec de trame de gestion avant même qu’un paquet IP n’existe.

22. 2,4 GHz, 5 GHz et 6 GHz : ne pas simplement choisir « la fréquence la plus récente »

Les réseaux Wi-Fi modernes peuvent utiliser différentes bandes selon la génération, les capacités de l’équipement et la réglementation applicable.

La bande 2,4 GHz reste particulièrement importante pour l’IoT.

Elle offre notamment une compatibilité très large et possède souvent des propriétés de couverture intéressantes.

Mais elle est également très sollicitée.

Bluetooth et de nombreux autres systèmes y fonctionnent aussi.

La bande 5 GHz apporte davantage de possibilités de canaux et de capacité dans de nombreux environnements.

La bande 6 GHz étend encore les ressources spectrales disponibles pour les générations compatibles, lorsque son utilisation est autorisée dans la juridiction concernée.

Le raisonnement correct n’est donc pas :

6 GHz > 5 GHz > 2,4 GHz

mais :

Quelle bande répond le mieux à la couverture, à la capacité, à la compatibilité, à l’énergie et aux règles applicables à mon produit ?

23. Canal Wi-Fi : largeur et coexistence

Contrairement aux petits canaux Bluetooth LE, le Wi-Fi peut utiliser des canaux beaucoup plus larges.

Cette largeur permet d’augmenter fortement la capacité.

Mais plus un signal occupe de spectre, plus la planification et la coexistence deviennent importantes.

Dans un environnement dense, rechercher systématiquement la largeur maximale peut être contre-productif.

Un ingénieur Wi-Fi ne cherche donc pas uniquement :

le débit maximal d’un lien isolé

mais également :

la performance globale du système lorsque de nombreux équipements partagent le spectre.

Cette différence entre performance d’un équipement et capacité d’un réseau est fondamentale.

Selon la bande et la génération, on rencontre des largeurs de canal de 20, 40, 80, 160 ou, dans certains systèmes Wi-Fi 7 compatibles, 320 MHz. Un canal large augmente le potentiel d’un lien mais occupe davantage de spectre et réduit les possibilités de réutilisation entre cellules. En 2,4 GHz, des canaux voisins se chevauchent dans les plans usuels ; deux AP sur le même canal se partagent le médium, tandis que deux canaux partiellement superposés peuvent produire une interférence adjacente plus difficile à coordonner. Le plan doit respecter le domaine réglementaire local, la densité et les équipements réels.

Augmenter la puissance d’un AP n’est pas non plus une solution universelle : le terminal doit pouvoir répondre. On peut entendre l’AP très loin tout en étant trop faible en sens montant pour que l’AP reçoive correctement le client. Le dimensionnement d’une cellule est bidirectionnel, comme le budget de liaison du Cours 01. Dans un atelier dense, le canal le plus large ou l’AP le plus puissant n’est pas nécessairement le meilleur choix.

24. Le médium radio est partagé

Sur un câble Ethernet commuté moderne, un équipement dispose d’un comportement très différent d’une station Wi-Fi partageant le même environnement radio avec de nombreuses autres stations.

Le Wi-Fi doit organiser l’accès à un médium partagé.

Historiquement, la famille 802.11 utilise notamment des mécanismes inspirés du principe CSMA/CA — Carrier Sense Multiple Access with Collision Avoidance.

Avant d’émettre, une station observe le médium et applique différentes règles afin de réduire les risques de transmissions concurrentes destructrices.

Mais elle ne peut pas « écouter » exactement comme sur un réseau Ethernet historique utilisant la détection de collisions.

D’où le terme :

Collision Avoidance

plutôt que :

Collision Detection.

Concrètement, une station attend que le canal soit disponible puis applique une période de contention et un backoff avant d’émettre. Une trame unicast correctement reçue peut être acquittée au niveau MAC ; sans acquittement, une retransmission peut suivre. Le temps de contention et les retries consomment du médium même lorsque le débit applicatif affiché semble faible.

Le problème du nœud caché apparaît lorsque deux stations entendent l’AP mais s’entendent mal entre elles : chacune peut estimer le canal libre alors que leurs émissions se gênent au récepteur. RTS/CTS peut aider dans certains scénarios, au prix d’un overhead supplémentaire ; ce n’est ni une garantie universelle ni un substitut à une bonne implantation radio.

Du SNR au débit : le MCS et le temps radio

Le Modulation and Coding Scheme (MCS) indique une combinaison de modulation et de codage utilisée pour transmettre les données. Quand la qualité du canal le permet, un système peut employer une modulation plus dense — de BPSK ou QPSK vers des QAM d’ordre plus élevé selon la génération — et transporter davantage de bits pendant un même temps radio. Lorsque le SNR baisse ou que les erreurs augmentent, un MCS plus robuste peut devenir nécessaire. La modulation la plus dense n’est utile que si le canal la supporte réellement.

Pour une charge brute identique, 6 Mbit/s demandent approximativement dix fois plus de temps de transmission que 60 Mbit/s, si l’on ignore tous les autres coûts. Ce calcul n’est qu’une intuition : les échanges réels incluent préambules, en-têtes, contention, acquittements, agrégation et retransmissions. Une station A à bon SNR et peu de retries peut libérer vite le médium ; une station B à faible MCS et plusieurs retries occupe plus longtemps le canal pour la même donnée utile. Même volume de données ne signifie pas même coût radio.

Un RSSI élevé assorti de nombreux retries ne suffit donc pas à déclarer la liaison saine : il faut croiser SNR, MCS, occupation du canal, voisinage radio et comportement de l’application. Un client lent dégrade parfois les autres non parce qu’il « vole du débit », mais parce qu’il consomme davantage du temps disponible sur le médium partagé.

25. Pourquoi le débit chute lorsque beaucoup d’objets arrivent

Imaginons un point d’accès connecté à dix équipements.

Puis cent objets arrivent.

Même si chaque équipement possède un excellent RSSI, la ressource radio doit désormais être partagée entre davantage de participants.

Des transmissions de gestion existent.

Les stations doivent accéder au médium.

Les retransmissions éventuelles consomment du temps.

Des clients lents peuvent également influencer l’utilisation globale du canal.

Nous retrouvons une idée essentielle :

Une excellente couverture ne garantit pas une excellente capacité.

Couverture et capacité doivent être conçues séparément.

26. Wi-Fi 6 : intéressant aussi pour l’IoT

Les évolutions récentes du Wi-Fi ne concernent pas uniquement la course au débit.

Wi-Fi 6 a notamment introduit ou renforcé des mécanismes particulièrement intéressants dans les environnements comportant de nombreux terminaux.

OFDMA permet une utilisation plus fine des ressources radio en permettant de subdiviser le canal afin de servir plus efficacement plusieurs utilisateurs.

Target Wake Time — TWT permet à certains équipements de négocier des périodes de réveil, ce qui peut aider à limiter l’activité radio inutile.

Cela ne transforme pas automatiquement Wi-Fi en équivalent de Bluetooth LE ou d’un LPWAN.

Mais cela montre pourquoi l’affirmation :

« Wi-Fi consomme toujours trop pour l’IoT »

est trop simpliste.

Tout dépend du matériel, du trafic, du comportement réseau et du cas d’usage.

Avec OFDMA, le canal peut être organisé en ressources plus petites pour servir plusieurs utilisateurs de manière plus efficace ; on ne réserve plus nécessairement toute la chaussée à une petite charge. TWT peut coordonner des périodes de réveil pour des équipements compatibles, mais l’économie réelle dépend du trafic, du point d’accès et du firmware. Ces mécanismes améliorent certaines situations de densité et d’énergie ; ils ne suppriment ni le coût de l’association ni les contraintes d’une batterie de très longue durée.

27. Wi-Fi 7 : davantage que « encore plus rapide »

Wi-Fi 7 s’appuie notamment sur IEEE 802.11be.

Parmi les mécanismes importants figure Multi-Link Operation — MLO, qui permet à des équipements compatibles de mieux exploiter plusieurs liens.

Des canaux jusqu’à 320 MHz sont également possibles dans les contextes compatibles, ainsi que des schémas de modulation plus denses.

Ces capacités peuvent produire des performances impressionnantes.

Mais un capteur de température envoyant 40 octets toutes les dix minutes n’a évidemment pas besoin de dizaines de gigabits par seconde.

La leçon d’ingénierie est donc :

Une technologie peut offrir une capacité extraordinaire sans que cette capacité constitue la raison pertinente de l’utiliser dans votre produit.

Pour un objet connecté, stabilité, disponibilité des composants, énergie, sécurité, durée de support et interopérabilité peuvent être bien plus importantes que le débit maximal.

Les canaux de 320 MHz et les modulations très denses, jusqu’à 4096-QAM dans les modes appropriés, exigent des conditions et des bandes compatibles. MLO ouvre plusieurs liens possibles, mais son intérêt doit être évalué au niveau du système entier. Rien de cela ne rend intrinsèquement meilleur le transport d’une mesure de 20 octets depuis une sonde à batterie.

28. Le coût énergétique d’une connexion Wi-Fi

Un objet Wi-Fi doit potentiellement :

• réveiller son radio ;
• découvrir le réseau ;
• s’authentifier ;
• s’associer ;
• récupérer ou restaurer sa configuration IP ;
• résoudre un nom ;
• établir une connexion TCP ;
• éventuellement négocier TLS ;
• envoyer ses données ;
• recevoir une réponse ;
• maintenir ou fermer les différents états.

Selon l’architecture, ces opérations peuvent coûter beaucoup plus d’énergie que les quelques octets applicatifs réellement transmis.

C’est pourquoi la consommation doit toujours être analysée comme :

coût du service complet

et non :

courant TX × durée du paquet.

29. Faut-il rester connecté ou se reconnecter ?

Cette décision est très importante dans les objets à batterie.

Approche 1 — rester associé

L’objet peut répondre rapidement et évite certains coûts de reconnexion.

Mais il doit maintenir des mécanismes de présence et de veille réseau.

Approche 2 — couper complètement la radio

La consommation pendant le sommeil peut devenir extrêmement faible.

Mais chaque réveil impose une nouvelle phase de connexion.

Si les données sont transmises toutes les quelques secondes, se reconnecter constamment serait probablement inefficace.

Si elles sont transmises une fois par jour, maintenir toute la pile active pendant 24 heures pourrait être absurde.

L’architecture optimale dépend donc du duty cycle applicatif.

Un ordre de grandeur révèle vite les hypothèses manquantes. Supposons une veille à 10 µA, une radio active à 80 mA pendant 2 s, avec 96 envois par jour. Les réveils représentent 80 × 2 × 96 / 86 400 ≈ 0,178 mA de moyenne ; la veille porte le total proche de 0,188 mA, sans compter capteur, démarrage, vieillissement ni autodécharge. Une batterie nominale de 2 400 mAh donnerait alors 2 400 / 0,188 ≈ 12 800 h, soit environ 1,5 an théorique. Si chaque envoi dure 4 s après retransmissions ou reconnexions, la composante radio double presque et cette estimation chute nettement. Ce n’est pas une promesse d’autonomie : le profil de courant mesuré sur le produit réel tranche.

Le roaming : le client n’est pas un simple passager

Dans de nombreuses architectures Wi-Fi, la station décide principalement quand quitter un BSSID pour un autre. Le réseau peut l’aider : 802.11k fournit des informations sur le voisinage, 802.11v facilite certaines indications de transition, et 802.11r peut accélérer des étapes de sécurisation lors du changement de cellule. Leur présence n’oblige cependant pas un terminal à se comporter comme le souhaite l’exploitant.

Dans un entrepôt, un terminal industriel en mouvement peut conserver un AP trop longtemps, subir une baisse de MCS puis perdre des paquets pendant sa session. Le diagnostic compare BSSID, RSSI, SNR, seuils de roaming, latence de transition et continuité IP. Ajouter des AP sans contrôler le recouvrement des cellules, la puissance et le comportement du client peut aggraver la situation.

30. WPA2 et WPA3 : protéger l’accès au réseau

Un réseau Wi-Fi ne doit pas être considéré comme sécurisé simplement parce qu’un mot de passe a été configuré.

Les mécanismes modernes de protection reposent notamment sur les familles WPA.

WPA2 reste très largement présent.

WPA3 apporte plusieurs améliorations, notamment dans son mode personnel avec l’utilisation de SAE — Simultaneous Authentication of Equals, ainsi que des exigences renforcées dans différents domaines.

Mais la technologie choisie ne suffit toujours pas.

Un mot de passe faible, partagé entre des milliers d’équipements et impossible à renouveler proprement reste un problème d’architecture.

31. Personal et Enterprise : deux modèles de confiance

Dans un petit environnement, un réseau Wi-Fi peut utiliser un secret partagé selon un modèle Personal.

Dans une organisation, le modèle Enterprise peut permettre une authentification individualisée via 802.1X et des méthodes EAP.

La différence est importante.

Avec un secret partagé :

compromettre le secret peut compromettre l’accès de plusieurs équipements.

Avec des identités individualisées :

un terminal peut potentiellement être révoqué sans devoir reconfigurer tous les autres.

Pour une flotte importante d’objets IoT, la gestion des identités et des secrets devient donc un problème de cycle de vie, pas seulement un paramètre radio.

Dans un réseau Enterprise, 802.1X organise le contrôle d’accès ; une méthode EAP transporte la preuve d’identité retenue, souvent avec un serveur d’authentification tel que RADIUS. Le choix entre certificat, autre mécanisme EAP ou secret dépend de la politique et des capacités du produit. La protection des données commence ensuite avec des clés de session établies sur la liaison. Lors du 4-way handshake, les parties démontrent qu’elles possèdent le matériel de clé approprié et installent des clés pour protéger les échanges : le mot de passe n’est pas simplement envoyé en clair dans l’air.

32. Le provisioning : comment donner le premier secret à l’objet ?

Avant qu’un objet puisse rejoindre le réseau Wi-Fi, il faut souvent lui fournir :

• le SSID ;
• les informations d’authentification ;
• éventuellement des certificats ;
• parfois l’adresse de son backend.

Mais comment transmettre ces informations à un objet qui n’est pas encore connecté ?

C’est le problème du provisioning ou onboarding.

Plusieurs approches sont possibles :

• interface locale ;
• application mobile ;
• Bluetooth LE ;
• NFC ;
• QR code ;
• mécanisme constructeur ;
• configuration en usine.

Ce moment est extrêmement sensible.

Car celui qui contrôle le provisioning peut souvent contrôler la destination future de l’objet.

Du capteur au broker MQTT

PARTIE III — NFC

33. NFC : changer complètement de modèle mental

Lorsque nous passons de Wi-Fi à NFC, il faut abandonner une partie de notre intuition précédente.

NFC fonctionne autour de 13,56 MHz et exploite principalement les propriétés du champ proche.

Nous ne sommes plus dans le même modèle qu’une liaison Wi-Fi destinée à couvrir une habitation ou qu’un lien Bluetooth entre une montre et un téléphone.

Les deux équipements doivent être très proches.

Cette proximité est volontaire.

À ces distances, le mécanisme pertinent est principalement le couplage magnétique en champ proche entre la bobine de l’initiateur du champ et celle de l’équipement approché. Un champ alternatif à 13,56 MHz peut fournir de l’énergie à un tag passif. Celui-ci répond notamment en faisant varier sa charge électrique ; le lecteur détecte cette load modulation. Il ne faut donc pas imaginer un tag sans batterie comme un minuscule émetteur Wi-Fi autonome. La géométrie des bobines, le métal voisin et l’alignement influent fortement sur le couplage réel.

Elle permet des interactions telles que :

• paiement ;
• titre de transport ;
• badge d’accès ;
• appairage simplifié ;
• identification d’un produit ;
• lecture d’un tag ;
• configuration initiale.

34. Le lecteur peut aussi fournir de l’énergie

L’une des propriétés les plus intéressantes du NFC est la possibilité, dans certains modes, d’alimenter un dispositif passif à partir du champ généré par le lecteur.

Un tag peut donc :

• ne posséder aucune batterie ;
• rester inerte la majorité du temps ;
• recevoir suffisamment d’énergie lorsqu’un lecteur s’approche ;
• traiter une opération ;
• répondre par modulation appropriée.

Cette architecture est radicalement différente d’un capteur Wi-Fi.

Nous comprenons maintenant pourquoi une simple comparaison de consommation en milliampères serait absurde.

Le tag passif ne gère pas sa consommation comme un objet alimenté sur batterie.

Dans la terminologie NFC Forum, le Poller initie l’interaction et fournit le champ dans les scénarios concernés ; le Listener répond. Ces rôles de communication ne sont pas exactement les mêmes catégories que les modes applicatifs Reader/Writer ou Card Emulation. Avant l’échange utile, le système doit détecter la présence, résoudre les collisions possibles si plusieurs tags sont dans le champ, sélectionner et activer le bon participant : champ → détection → polling → résolution de collision → sélection → échange.

NDEF : donner un sens aux données lues

NDEF, pour NFC Data Exchange Format, n’est pas la radio NFC. C’est un format de données au-dessus des mécanismes analogiques et numériques : un message NDEF contient un ou plusieurs records, chacun portant notamment un type et une charge utile. Une application peut ainsi lire un texte, une URI ou des données de bootstrap vers une autre communication. Si le téléphone détecte un tag mais n’affiche pas l’information attendue, il faut distinguer la détection RF de la lecture et de l’interprétation NDEF.

Ce tableau n’est ni un classement de sécurité ni une liste exhaustive de fonctions. Les capacités de mémoire, de protection et d’authentification dépendent du tag concret et de l’application. Un type NFC Forum définit l’interopérabilité du format et de l’accès NDEF ; il ne dispense pas d’examiner le composant choisi.

35. Reader/Writer Mode

Dans ce mode, un équipement actif — souvent un smartphone ou un lecteur dédié — interagit avec un tag.

Le lecteur peut récupérer une information telle que :

• identifiant ;
• URL ;
• configuration ;
• données produit ;
• paramètres techniques.

Selon le tag et les permissions disponibles, certaines données peuvent également être écrites.

Ce mode est particulièrement intéressant dans l’IoT pour :

• installation ;
• maintenance ;
• inventaire ;
• configuration ;
• identification locale.

36. Card Emulation Mode

Un smartphone ou autre équipement NFC peut également se comporter comme une carte sans contact vis-à-vis d’un lecteur.

C’est notamment une logique utilisée dans les domaines du :

• paiement ;
• transport ;
• contrôle d’accès ;
• identité numérique selon les systèmes.

Ici, l’appareil n’est plus simplement en train de lire un tag.

Il participe au protocole en jouant le rôle attendu d’une carte.

La différence d’architecture est importante.

37. Peer-to-Peer

NFC permet également des échanges directs entre équipements compatibles selon les mécanismes appropriés.

Ce mode a historiquement permis différents scénarios d’échange local.

Dans de nombreuses architectures modernes, NFC est cependant particulièrement puissant lorsqu’il sert à amorcer une autre interaction.

Par exemple :

NFC → identification / échange initial → Bluetooth ou Wi-Fi pour la suite

Cette combinaison est importante en IoT.

Une technologie n’a pas besoin de tout faire elle-même.

38. NFC et commissioning sécurisé

Imaginons une machine industrielle neuve.

Elle n’est encore connectée à aucun réseau.

Un technicien autorisé approche son terminal NFC.

L’interaction peut permettre de fournir ou déclencher certaines informations nécessaires à l’installation.

Le principal avantage architectural est évident :

le commissioning nécessite une proximité physique volontaire.

Cela réduit certaines formes d’exposition distante.

Mais cela ne suffit pas à garantir la sécurité.

Un attaquant disposant d’un accès physique peut lui aussi être proche.

Il faut donc encore :

• authentifier les participants lorsque nécessaire ;
• protéger les secrets ;
• valider les données ;
• empêcher les rejeux selon le cas ;
• limiter les opérations autorisées.

39. Courte portée ≠ confiance automatique

Cette idée mérite d’être répétée.

Le NFC fonctionne à très courte distance.

Mais :

proximité ≠ identité

et

proximité ≠ autorisation

Un attaquant peut parfois approcher physiquement un lecteur ou un tag.

Certains tags peuvent être copiés si l’architecture repose uniquement sur une donnée statique non protégée.

Des scénarios de relay existent également dans certains systèmes : un adversaire tente d’étendre artificiellement une interaction qui devait dépendre de la proximité.

La sécurité d’une application NFC doit donc reposer sur le protocole complet, pas uniquement sur les quelques centimètres séparant normalement les équipements.

Un UID ou un record NDEF statique peut servir de repère d’inventaire ; il n’est pas automatiquement une preuve cryptographique d’identité. Selon le type de tag, certaines données peuvent être modifiées, copiées ou relues. Une protection en écriture, une authentification du tag, un canal sécurisé et une validation côté backend répondent à des menaces différentes. Les architectures sensibles doivent aussi considérer le rejeu et le relais de communication. Lire une valeur sur un tag n’est pas automatiquement authentifier son porteur.

Approcher, identifier, configurer

PARTIE IV — LES COMPARER CORRECTEMENT

40. Trois technologies, trois questions différentes

Nous pouvons maintenant résumer leur philosophie.

Bluetooth LE

Question typique :

Comment permettre à deux objets proches de découvrir leur présence et d’échanger efficacement des données avec une consommation maîtrisée ?

Wi-Fi

Question typique :

Comment intégrer un objet dans un réseau local IP disposant d’une capacité relativement importante ?

NFC

Question typique :

Comment déclencher une interaction volontaire, extrêmement locale, éventuellement avec un dispositif passif ?

Ces formulations sont beaucoup plus utiles qu’un simple classement par portée.

41. Tableau de comparaison raisonné

Ce tableau doit être lu comme un repère architectural, pas comme un verdict.

42. Bluetooth LE + Wi-Fi : une combinaison extrêmement courante

Un objet n’est pas obligé de choisir une seule radio.

Prenons une enceinte intelligente ou un équipement domestique.

Au premier démarrage :

Bluetooth LE peut permettre au smartphone de découvrir l’objet et de lui fournir les paramètres nécessaires.

Ensuite :

Wi-Fi devient le canal principal permettant à l’objet d’accéder au réseau.

Nous obtenons :

smartphone → BLE → provisioning

puis :

objet → Wi-Fi → réseau IP → services

Cette architecture exploite chaque technologie là où elle est forte.

Mais elle crée également deux surfaces radio à sécuriser.

43. NFC + Bluetooth : proximité pour démarrer, radio pour continuer

Autre architecture possible :

l’utilisateur approche volontairement son téléphone de l’objet.

NFC permet :

• d’identifier l’équipement ;
• de transmettre certaines informations initiales ;
• éventuellement de faciliter l’établissement d’une autre relation.

Bluetooth prend ensuite le relais pour une communication plus longue ou plus riche.

Cette approche peut apporter une expérience utilisateur élégante :

Tap → connect

Mais une expérience simple en surface peut cacher une architecture de sécurité complexe.

Il faut savoir précisément ce que le NFC transmet et ce que Bluetooth considère ensuite comme preuve de confiance.

44. Coexistence Bluetooth / Wi-Fi en 2,4 GHz

Bluetooth LE et Wi-Fi peuvent fonctionner dans la même bande.

Ils peuvent même être intégrés dans le même équipement.

Cela signifie qu’une mauvaise conception matérielle ou logicielle peut provoquer des problèmes de coexistence.

Bluetooth utilise notamment le saut de fréquence adaptatif afin de réduire l’utilisation des canaux défavorables.

Les chipsets combinés peuvent également disposer de mécanismes internes de coordination.

Mais la coexistence dépend toujours :

• des puissances ;
• de la proximité des antennes ;
• des canaux Wi-Fi utilisés ;
• des périodes d’émission ;
• de la conception RF ;
• de la qualité de l’implémentation.

La présence de deux normes conçues pour coexister n’abolit pas les lois de la radio.

Même besoin, plusieurs architectures possibles

Considérons 400 capteurs de vibration et température à batterie, répartis dans un atelier métallique. Ils publient toutes les quinze minutes, doivent viser cinq ans d’autonomie, accepter un diagnostic par smartphone et cohabiter avec un WLAN existant. Avant de choisir, il faut mesurer la couverture aux emplacements réels, estimer l’airtime en charge, définir ce qui fonctionne sans cloud et fixer les exigences de maintenance et de sécurité.

La BOM ne se réduit pas au prix de la radio : antennes, batterie, boîtier, gateway, remplacement sur site et exploitation entrent dans le coût complet. Aucune option ne gagne par défaut. Les mesures de courant, la densité réelle, la disponibilité des passerelles et les exigences de sécurité peuvent inverser le résultat. Une architecture multi-radio apporte de la souplesse, mais aussi davantage d’interfaces à maintenir.

PARTIE V — CYBERSÉCURITÉ

45. La première question : qu’est-ce qu’un attaquant peut voir avant l’authentification ?

Avant même de tenter de casser un chiffrement, un analyste peut se demander :

• l’objet advertise-t-il son nom ?
• diffuse-t-il un identifiant stable ?
• son adresse change-t-elle ?
• son SSID révèle-t-il le produit ?
• un service GATT est-il visible ?
• un tag NFC contient-il une information lisible sans authentification ?
• le rythme des émissions révèle-t-il une activité ?

Cette approche est fondamentale.

Une donnée n’a pas besoin d’être secrète pour devenir utile à un attaquant.

Les métadonnées peuvent révéler énormément d’informations.

46. Surface Bluetooth

Une analyse Bluetooth d’un produit doit notamment considérer :

Advertising

Que révèle l’objet avant connexion ?

Pairing

Quelle méthode d’association est utilisée ?

Bonding

Comment les relations de confiance sont-elles stockées et révoquées ?

GATT

Quelles caractéristiques peuvent être lues ou modifiées ?

Authorization

Une connexion chiffrée suffit-elle pour toutes les opérations ?

Firmware

Les secrets sont-ils correctement protégés ?

Lifecycle

Que se passe-t-il lors d’une revente, d’un reset usine ou d’un changement de propriétaire ?

Cette dernière question est souvent oubliée.

47. Surface Wi-Fi

Pour un produit Wi-Fi, il faut notamment étudier :

• mécanisme de provisioning ;
• stockage des credentials ;
• sécurité du réseau rejoint ;
• comportement face aux réseaux malveillants ;
• validation des certificats backend ;
• services réseau locaux exposés ;
• mécanismes de découverte ;
• interfaces d’administration ;
• mises à jour ;
• séparation entre réseau local et cloud ;
• fonctionnement lorsque le cloud n’est plus disponible.

Une liaison WPA3 correctement établie ne protège pas une API locale vulnérable.

Encore une fois :

sécurité radio ≠ sécurité du produit entier.

48. Surface NFC

Pour NFC, l’analyse doit notamment demander :

• les données du tag sont-elles statiques ?
• peuvent-elles être modifiées ?
• constituent-elles une preuve d’identité ?
• existe-t-il une authentification cryptographique ?
• un rejeu est-il possible ?
• l’opération possède-t-elle des conséquences critiques ?
• un relay serait-il pertinent ?
• le backend vérifie-t-il le contexte de la transaction ?

Une architecture dangereuse serait par exemple :

« Je lis un identifiant NFC, donc je sais avec certitude qui est l’utilisateur. »

Cette conclusion n’est valide que si le mécanisme utilisé permet réellement de fournir cette garantie.

49. Le reset usine est aussi une fonction de sécurité radio

Un appareil associé à un utilisateur peut accumuler :

• bonds Bluetooth ;
• credentials Wi-Fi ;
• certificats ;
• tokens ;
• paramètres réseau ;
• identifiants cloud.

Que se passe-t-il lorsqu’il est vendu ?

Réparé ?

Retourné au constructeur ?

Transféré à un autre employé ?

Le Factory Reset ne doit pas simplement remettre le nom du produit à sa valeur par défaut.

Il doit supprimer correctement les relations de confiance qui ne doivent pas survivre.

Le cycle de vie physique de l’objet rejoint donc directement le cycle de vie des identités radio.

Une matrice de confiance pour les trois radios

Une menace n’a pas la même forme sur chaque interface. Cette matrice sert à poser des questions de conception, non à attribuer une note de sécurité à une technologie entière.

Le provisioning relie toutes ces lignes : c’est le moment où l’on déclare qui est l’objet, qui peut le piloter et comment cette relation sera révoquée. Un lien radio chiffré peut transporter une commande non autorisée ; un identifiant NFC valide peut appartenir à un tag copié ; une association Wi-Fi correcte peut mener à une API vulnérable. La sécurité doit être suivie jusqu’à la décision métier.

Quand « ça ne marche pas » : raisonner par couches

BLE. Le téléphone voit l’advertising mais ne lit pas une characteristic. La découverte est acquise ; on vérifie ensuite l’établissement du lien, la découverte GATT, le handle visé, les permissions, le niveau de sécurité, l’abonnement éventuel aux notifications et enfin l’application. Refaire le plan de canaux n’est pas la première action si l’erreur est une autorisation GATT.

Wi-Fi. Le capteur est associé à l’AP mais aucune mesure n’atteint le cloud. On suit : association → adresse IP → passerelle → DNS → TCP → TLS → broker → autorisation MQTT. À chaque étape, un journal ou une capture au bon niveau permet de localiser la première rupture. Un bon RSSI ne prouve ni la résolution DNS ni la validité du certificat.

NFC. Le téléphone détecte un tag mais l’application ne trouve pas sa configuration. On sépare couplage et sélection, lecture du tag, présence d’un message NDEF, type du record, décodage puis traitement applicatif. Remplacer l’antenne n’a aucun sens si le record contient une URI que l’application ne prend pas en charge.

Le diagnostic professionnel consiste à identifier la première couche qui ne fournit plus le service attendu à la couche supérieure.

PARTIE VI — ÉTUDE DE CAS

50. Concevoir un capteur industriel avec maintenance locale

Une entreprise souhaite installer des capteurs sur plusieurs équipements industriels.

Chaque capteur :

• mesure température et vibrations ;
• envoie une synthèse régulièrement ;
• fonctionne sur batterie ;
• doit tenir plusieurs années ;
• doit pouvoir être diagnostiqué localement par un technicien ;
• reçoit occasionnellement une nouvelle configuration ;
• ne doit pas exposer inutilement ses interfaces au public.

Trois technologies sont envisagées :

Bluetooth LE

Wi-Fi

NFC

La bonne démarche consiste à séparer les besoins.

51. Télémétrie régulière

Si la télémétrie doit atteindre directement l’infrastructure réseau existante et que le Wi-Fi couvre correctement l’environnement, Wi-Fi peut sembler naturel.

Mais il faut vérifier :

• coût énergétique ;
• fréquence de transmission ;
• mécanisme d’authentification ;
• densité de capteurs ;
• maintien des credentials ;
• couverture réelle au niveau des machines.

Si une gateway locale est envisageable, Bluetooth LE peut offrir une autre architecture :

capteurs BLE → gateway → Ethernet/Wi-Fi → plateforme

Le coût se déplace alors vers la gateway.

Nous échangeons :

simplicité de chaque capteur

contre :

dépendance à une infrastructure intermédiaire.

52. Maintenance locale

Pour un technicien placé physiquement devant la machine, Bluetooth LE est particulièrement intéressant.

Il peut permettre :

• consultation de diagnostics ;
• lecture d’indicateurs ;
• changement de certains paramètres ;
• transfert limité de données.

Mais l’interface ne doit pas devenir une porte dérobée permanente.

La question devient :

Comment l’objet sait-il que ce smartphone appartient réellement à un technicien autorisé ?

La présence à dix mètres n’est pas une preuve suffisante.

53. NFC pour identifier l’équipement

Un tag NFC peut faciliter l’identification physique de la machine.

Le technicien approche son téléphone.

L’application récupère une référence.

Elle sait immédiatement quel équipement est devant lui.

Mais si le tag ne contient qu’un identifiant statique copiable, cet identifiant ne doit pas automatiquement donner accès aux fonctions sensibles.

Nous pouvons utiliser NFC pour :

identifier ou amorcer

sans nécessairement l’utiliser comme :

preuve ultime d’autorisation.

54. Architecture combinée

Une architecture possible devient :

NFC

pour identifier rapidement l’équipement et amorcer l’expérience locale ;

Bluetooth LE

pour le diagnostic et la configuration de proximité ;

gateway / autre infrastructure

pour la télémétrie régulière vers le système central.

Cette solution utilise plusieurs technologies.

Elle est plus complexe qu’une radio unique.

Mais elle peut mieux séparer les usages.

C’est souvent cela, l’architecture :

ne pas rechercher la technologie universelle, mais affecter chaque technologie au problème pour lequel elle apporte le meilleur compromis.

Revue de conception : sept exigences avant le choix

Reprenons ce capteur en fixant des exigences vérifiables : cinq ans d’autonomie, 400 unités, maintenance locale, remplacement individuel, continuité en cas de panne du cloud et effacement des identités en fin de vie. La première revue porte sur le profil d’énergie : combien de réveils, de scans et de retransmissions par jour, sur une batterie vieillie et aux températures de l’atelier ? Une simulation de capacité nominale sans mesure du courant réel ne valide pas cinq ans.

La deuxième porte sur la densité. Quatre cents capteurs ne sont pas seulement quatre cents adresses : ils représentent des événements radio, des fenêtres de scan, un taux de collision possible et une capacité à répartir entre AP ou gateways. Les vibrations et le métal imposent des essais aux emplacements finaux. La troisième compare la maintenance par BLE, NFC et Wi-Fi direct : fréquence d’intervention, durée autorisée du mode maintenance, disponibilité du téléphone et récupération lorsqu’une radio est en panne.

La quatrième exige d’authentifier et d’autoriser le technicien ; approcher une machine ne donne pas le droit de changer un seuil critique. La cinquième décrit le remplacement : supprimer l’ancien bond, révoquer l’identité réseau ou le certificat, enregistrer le nouveau capteur et corriger l’inventaire backend. La sixième demande quelles mesures et alarmes restent disponibles localement pendant une panne du cloud. Enfin, la septième définit le reset et la fin de vie : effacer bonds, credentials Wi-Fi, tokens, certificats et droits liés à l’ancien propriétaire, tout en respectant les contraintes matérielles du support.

Une option possible est NFC pour identifier physiquement l’équipement, BLE pour une session de maintenance autorisée, puis des gateways surveillées pour la télémétrie. Ce n’est une proposition recevable que si la couverture mesurée, la redondance des gateways, l’énergie et la gouvernance des clés satisfont les exigences. Dans un autre atelier, un Wi-Fi direct convenablement dimensionné peut être plus simple et plus fiable.

PARTIE VII — MÉTHODE DE CHOIX

55. Dix questions avant de choisir Bluetooth, Wi-Fi ou NFC

1. L’équipement doit-il accéder directement à IP ?

Si oui, Wi-Fi devient naturellement intéressant.

Mais une gateway Bluetooth peut également fournir indirectement cet accès.

2. Quelle quantité de données doit être transportée ?

Quelques octets ne justifient pas les mêmes mécanismes qu’une vidéo.

3. Quelle distance opérationnelle est nécessaire ?

Centimètres, mètres et couverture d’un bâtiment correspondent à des architectures différentes.

4. Quelle autonomie est attendue ?

Un équipement alimenté sur secteur et un capteur censé fonctionner cinq ans sur pile ne doivent pas être évalués avec les mêmes critères.

5. Une infrastructure existe-t-elle déjà ?

Wi-Fi nécessite généralement un réseau disponible.

Bluetooth peut fonctionner directement entre équipements.

NFC peut permettre une interaction sans infrastructure réseau permanente.

6. La communication doit-elle être spontanée ou volontaire ?

Un tag que l’utilisateur approche volontairement n’a pas la même logique qu’un beacon diffusant continuellement sa présence.

7. Combien d’équipements doivent coexister ?

La densité influence fortement l’architecture radio.

8. Quelle latence est réellement nécessaire ?

Il faut distinguer « agréable pour l’utilisateur » et « indispensable au système ».

9. Comment l’identité sera-t-elle établie ?

Pairing Bluetooth, credential Wi-Fi ou proximité NFC ne répondent pas exactement à la même question.

10. Comment le système sera-t-il administré pendant dix ans ?

Installation, renouvellement des secrets, changement de propriétaire, maintenance, mises à jour et fin de vie doivent faire partie du choix initial.

Ce que l’ingénieur doit savoir observer

Sur Bluetooth LE, le RSSI ne suffit pas. On relève l’intervalle d’advertising, le mode de scan, les paramètres de connexion, le PHY, l’ATT_MTU négocié, le rythme des notifications, la qualité et les retransmissions de liaison, puis la méthode de pairing réellement utilisée. Une autonomie décevante peut venir du temps passé à écouter, pas de la puissance d’émission annoncée.

Sur Wi-Fi, on croise RSSI, SNR, MCS, occupation du canal, taux de retries, bande et largeur de canal. BSSID et historique de roaming expliquent parfois une panne intermittente qu’un relevé statique de couverture ne montre pas. Il faut enfin mesurer la latence et la réussite jusqu’au service applicatif, pas seulement jusqu’à l’AP.

Sur NFC, on identifie la technologie et le type de tag, la distance et l’orientation qui fonctionnent réellement, l’effet du métal sur le couplage, le format NDEF, les permissions de lecture/écriture et l’authentification éventuelle. Le passage de « le téléphone a détecté quelque chose » à « l’application a accepté une action autorisée » doit être traçable.

56. Erreurs fréquentes

« Bluetooth et BLE, c’est exactement la même chose. »

Non. Ils appartiennent à la même famille mais utilisent des architectures radio et des mécanismes différents.

« BLE signifie simplement Bluetooth qui consomme moins. »

Réducteur. Bluetooth LE possède sa propre architecture de communication, ses transports et son modèle protocolaire.

« Central veut dire serveur. »

Non. Central/Peripheral et Client/Server décrivent des rôles différents.

« Un équipement connecté au Wi-Fi est connecté à Internet. »

Non. Wi-Fi fournit le lien WLAN. La connectivité IP et Internet dépend du reste de l’infrastructure.

« 6 GHz est forcément meilleur que 2,4 GHz. »

Non. Tout dépend du besoin, de la couverture, des capacités du terminal et de la réglementation.

« WPA3 sécurise entièrement mon objet. »

Non. WPA3 protège une partie de la chaîne. Les services, API, credentials, firmware et backend restent à sécuriser.

« NFC est sécurisé parce qu’il fonctionne à quelques centimètres. »

Non. La proximité réduit certaines possibilités d’attaque mais ne remplace pas l’authentification.

« Le meilleur choix est la technologie avec le débit le plus élevé. »

Pour de nombreux objets IoT, le débit maximal constitue un critère secondaire.

57. Ce qu’il faut retenir

Bluetooth, Wi-Fi et NFC sont tous des moyens de communication sans fil, mais les considérer comme de simples concurrents serait une erreur.

Bluetooth LE est particulièrement puissant lorsqu’il faut organiser des échanges locaux, économes en énergie et capables de fonctionner avec ou sans connexion permanente. Son fonctionnement repose sur des mécanismes tels que l’advertising, le scanning, les événements de connexion et, pour les données applicatives, des architectures comme GATT.

Wi-Fi répond à une autre logique. Il permet à l’objet d’entrer dans un réseau local de type IP disposant d’une capacité importante. Son coût architectural inclut cependant l’infrastructure, l’authentification réseau, la configuration IP, les services associés et parfois une consommation plus importante.

NFC change encore de paradigme. La proximité volontaire et la possibilité de dispositifs passifs en font une technologie particulièrement intéressante pour l’identification, le commissioning, l’accès et les interactions « tap ».

Mais chacune de ces technologies crée également une surface de sécurité.

Avec Bluetooth, le pairing, les services exposés et les relations de bonding deviennent critiques.

Avec Wi-Fi, le provisioning, les credentials, l’accès au réseau et les services IP doivent être maîtrisés.

Avec NFC, il faut éviter de transformer la proximité en fausse preuve d’identité.

La compétence essentielle n’est donc toujours pas :

connaître la technologie la plus performante

mais :

comprendre ce qu’elle garantit, ce qu’elle suppose et ce qu’elle expose.

Quiz d’auto-évaluation

Situations professionnelles

Conclusion

Dans le Cours 01 du Module 02, nous avons appris à regarder sous la technologie : fréquence, puissance, bruit, propagation, antennes et budget de liaison.

Dans ce deuxième cours, nous avons ajouté une couche essentielle : la manière dont une technologie organise réellement la communication.

Bluetooth LE nous a montré qu’une radio peut être pensée autour de la découverte, de courts événements de communication et d’un modèle de données structuré.

Wi-Fi nous a montré qu’une interface radio peut devenir directement la porte d’entrée d’un équipement dans un réseau IP complet.

NFC nous a montré qu’une communication sans fil peut au contraire être volontairement limitée à une zone extrêmement proche et même apporter l’énergie nécessaire à un dispositif passif.

Ces trois technologies nous apprennent surtout une chose :

La bonne technologie n’est pas celle qui possède les meilleures caractéristiques sur le papier. C’est celle dont les compromis correspondent à l’architecture réelle du système.

Nous sommes maintenant prêts à changer d’échelle.

Jusqu’ici, nous avons principalement étudié les communications locales ou de proximité.

Le prochain enjeu sera de connecter des objets situés à plusieurs centaines de mètres ou plusieurs kilomètres, parfois pendant plusieurs années sur batterie, tout en transportant seulement quelques octets.

C’est le monde des LPWAN.

La question du prochain cours deviendra alors :

Comment obtenir une grande couverture avec très peu d’énergie et très peu de données — et quel prix technique faut-il payer pour y parvenir ?

Références techniques

Ce cours s’appuie sur les ressources officielles suivantes, à consulter pour les paramètres précis d’implémentation, de qualification ou de conformité :

• Bluetooth SIG — Bluetooth Core Specification 6.3 et Bluetooth LE Primer pour GAP, GATT, ATT, L2CAP, SMP, HCI, sécurité et paramètres de liaison ; Channel Sounding technical overview pour la mesure de distance ;
• IEEE — IEEE 802.11-2024 pour la couche MAC/PHY WLAN et IEEE 802.11be-2024 pour les évolutions EHT associées à Wi-Fi 7 ;
• Wi-Fi Alliance — programmes de certification Wi-Fi pour les dénominations Wi-Fi CERTIFIED et WPA ;
• NFC Forum — NFC Technology et catalogue des spécifications, notamment Digital Protocol, NDEF, Type 2/3/4/5 Tag et Authentication Protocol, pour distinguer couche radio, format de données et garanties applicatives.

Ces références complètent le raisonnement architectural présenté dans le cours.