Les architectes IoT d’entreprise consacrent beaucoup de temps à évaluer le matériel et les technologies de connectivité, mais moins de temps à définir la pile de protocoles qui régit la manière dont les appareils, les réseaux et les plateformes communiquent entre eux. Ce déséquilibre se traduit souvent par des problèmes d'intégration après le déploiement : des appareils qui ne parviennent pas à s'authentifier auprès de la plateforme, des données qui arrivent dans des formats que la tête de réseau ne peut pas analyser, des mises à jour de micrologiciel qui échouent parce que le protocole de transport OTA n'a pas été validé par rapport à la mémoire disponible de l'appareil, et des failles de sécurité résultant d'incompatibilités entre les protocoles des différentes couches.
La pile de protocoles de l'IoT est un ensemble de normes organisées en couches, chacune régissant un aspect différent du cheminement des données depuis un capteur physique jusqu'à une application. Les choix effectués à chaque couche limitent ou permettent ceux des couches adjacentes, et les interactions entre ces choix déterminent si l'ensemble de la pile fonctionne comme un système cohérent ou comme un ensemble de composants validés individuellement qui génèrent des frictions au niveau des interfaces.
Cet article passe en revue la pile de protocoles de l'IoT, depuis la couche de connectivité physique jusqu'à la couche applicative, en abordant les normes pertinentes pour les déploiements en entreprise, les compromis à chaque couche et les enjeux d'intégration qui déterminent si la pile reste cohérente à grande échelle.
Couche physique et couche d'accès : normes de téléphonie mobile
La couche physique et la couche d'accès régissent la manière dont un appareil établit une connexion radio avec un réseau. Dans le domaine de l’IoT d’entreprise, il est utile de définir les normes cellulaires pertinentes et leurs relations réciproques, car le discours marketing autour de ces technologies peut manquer de précision, ce qui peut influencer les décisions de déploiement.
NB-IoT (IoT à bande étroite, 3GPP Release 13 et versions ultérieures) fonctionne sur un canal de 180 kHz au sein du spectre sous licence, soit en bande au sein d’une porteuse d’ LTE , soit dans la bande de garde d’ LTE , soit en déploiement autonome sur le spectre réaffecté de l’ GSM . Caractéristiques clés de la couche physique :
- Débit descendant maximal : environ 250 kbps en mode monofréquence
- Débit maximal en liaison montante : environ 250 kbps
- Budget de liaison : perte de couplage maximale de 164 dBm, soit une amélioration d'environ 20 dB par rapport à GPRS
- Latence : entre 1,6 et 10 secondes pour une transmission de données type, configuration comprise, ce qui la rend inadaptée aux applications nécessitant un temps de réponse inférieur à une seconde
- Mode duplex : semi-duplex uniquement
LTE-M (LTE-MTC, Cat-M1, 3GPP Release 13) fonctionne sur un canal de 1,4 MHz au sein du spectre « LTE », avec prise en charge du mode full-duplex. Caractéristiques clés de la couche physique :
- Débit maximal en liaison descendante : environ 1 Mbps
- Débit maximal en liaison montante : environ 1 Mbps
- Budget de liaison : perte de couplage maximale de 155,7 dBm, soit une amélioration d'environ 15 dB par rapport à GPRS
- Latence : 10 à 15 ms pour la transmission des données après l'établissement de la connexion
- Mode duplex : prise en charge du mode full-duplex, permettant la transmission vocale et la transmission bidirectionnelle de données en temps réel
5G NR pour l'IoT introduit deux catégories d’appareils pertinentes : RedCap (Reduced Capability, 3GPP Release 17), destinée aux appareils IoT de milieu de gamme nécessitant un débit supérieur à celui de l’ LTE-M mais une consommation d’énergie inférieure à celle d’un terminal NR « full- 5G », et le NR standard 5G pour les applications IoT à large bande passante. RedCap vise un débit de 5 à 25 Mbps avec une réduction de la consommation d’énergie et de la complexité par rapport au NR « full 5G », comblant ainsi le fossé entre le « LTE-M » et le « full 5G », qui était historiquement occupé par les appareils 4G Cat-4.
Le choix de la couche physique définit les limites supérieures et inférieures pour toutes les couches situées au-dessus. Une pile de protocoles conçue pour une communication bidirectionnelle en moins d'une seconde et reposant sur NB-IoT échouera au niveau de la couche physique avant même que le protocole d'application n'ait eu le temps d'entrer en action.
Couche réseau : adressage IP et routage pour l'IoT
La plupart des appareils IoT d'entreprise communiquent via IPv4 ou IPv6, mais la configuration de la couche réseau, qui régit l'attribution et la gestion de ces adresses, a des implications opérationnelles que les spécifications de la couche physique ne mettent pas en évidence.
Architecture d'APN privée est la configuration standard de la couche réseau pour les déploiements IoT d'entreprise soumis à des exigences en matière de sécurité des données ou à des contraintes réglementaires. Plutôt que d'acheminer le trafic des appareils via l'APN publique partagée de l'opérateur vers l'Internet public, une APN privée crée un chemin réseau dédié entre l'appareil et l'infrastructure backend de l'entreprise. Le trafic sur une APN privée ne transite pas par l'Internet public, ce qui est important pour :
- Conformité réglementaire dans les secteurs où les données ne doivent pas sortir du périmètre du réseau de l'entreprise
- Surface d'attaque réduite, car les appareils ne sont pas directement accessibles depuis l'Internet public
- Routage déterministe, car le trafic de l'APN e privé suit des chemins réseau prédéfinis plutôt que le routage public sur Internet
L'IPv6 pour l'IoT est pertinent car l'épuisement des adresses IPv4 rend difficile la gestion individuelle des déploiements d'IoT à grande échelle. Le déploiement d'un million de compteurs intelligents, chacun nécessitant une adresse IP routable pour la communication initiée par la tête de réseau, se heurte à des contraintes pratiques d'attribution d'adresses IPv4 que l'IPv6 élimine. L'IPv6 simplifie également l'adressabilité de bout en bout dans les architectures où les appareils doivent être accessibles individuellement sans traversée NAT.
Considérations relatives au CGNAT concernent les déploiements dans lesquels un NAT de niveau opérateur (CGNAT) se trouve entre le dispositif et le backend de l’entreprise, ce qui correspond à la configuration par défaut de la plupart des forfaits grand public et IoT standard. Le CGNAT empêche les connexions entrantes vers les dispositifs, ce qui signifie que toute architecture nécessitant une communication initiée par la tête de réseau vers des dispositifs individuels requiert soit une adresse IP privée APN, soit une connexion initiée par le dispositif et toujours active, soit un dispositif qui maintient une session persistante avec la plateforme backend. Les architectes qui ne tiennent pas compte du CGNAT lors de la conception s’en rendent compte lors des tests d’intégration, stade auquel les solutions correctives s’avèrent plus coûteuses.
Couche de transport : sélection du protocole pour la transmission des données de l'IoT
La couche de transport régit la manière dont les données sont agrégées et transmises de manière fiable (ou, à dessein, de manière non fiable) entre l'appareil et la plateforme. Les protocoles de transport dominants dans l'IoT d'entreprise présentent chacun des compromis différents, adaptés à des profils d'application variés.
MQTT (Message Queuing Telemetry Transport) est le protocole de transport IoT le plus largement déployé pour les appareils connectés au réseau cellulaire. Son architecture de type « publication-abonnement », sa faible surcharge (en-tête fixe de 2 octets minimum) et la prise en charge de trois niveaux de qualité de service (QoS) en font un protocole particulièrement adapté aux appareils aux ressources limitées qui transmettent fréquemment de petites charges utiles sur des connexions potentiellement peu fiables :
- QoS 0 (une seule fois au maximum) : « fire and forget », sans accusé de réception, surcharge minimale
- QoS 1 (au moins une fois) : livraison garantie avec accusé de réception, doublons possibles
- QoS 2 (une seule fois) : livraison unique garantie, surcharge maximale
La fonctionnalité de session persistante de MQTT permet aux appareils de se reconnecter après une interruption de connexion et de recevoir les messages mis en file d’attente par le courtier pendant la période de déconnexion, ce qui est important pour les appareils « NB-IoT » du PSM qui sont périodiquement inaccessibles.
Le protocole CoAP (Constrained Application Protocol) est conçu pour les appareils aux ressources les plus limitées, pour lesquels l'exigence TCP du protocole MQTT engendre une surcharge inacceptable. Le CoAP fonctionne sur UDP, utilise un modèle requête-réponse similaire à celui du HTTP, mais avec un en-tête binaire optimisé pour les environnements contraints, et prend en charge la fonctionnalité « observe » pour un comportement de type publication-abonnement. C'est le choix de transport idéal pour les appareils NB-IoT , pour lesquels la surcharge liée à la gestion des connexions TCP affecterait considérablement le budget énergétique.
AMQP (Advanced Message Queuing Protocol) s'applique davantage à la couche d'intégration back-end qu'à la couche « de l'appareil au cloud ». Grâce à ses capacités avancées de routage des messages, à la prise en charge des transactions et à sa compatibilité avec les brokers de messages d'entreprise, il s'impose comme le protocole de transport standard pour connecter les plateformes IoT aux systèmes back-end d'entreprise : ERP, gestion des actifs et plateformes de technologie opérationnelle qui nécessitent des brokers de messages compatibles AMQP.
HTTPS/REST reste pertinent pour les appareils IoT disposant de ressources de calcul suffisantes et pour lesquels la simplicité de l’intégration REST API l’emporte sur la surcharge liée au protocole HTTP. Les passerelles IoT haut de gamme, les nœuds de calcul en périphérie et les appareils dotés d’une connectivité 4G ou 5G utilisent couramment REST pour l’intégration à la plateforme, en particulier dans les déploiements où l’équipe opérationnelle chargée de la gestion de l’intégration backend est plus familiarisée avec les modèles d’ API s Web qu’avec la configuration des brokers MQTT.
Couche de sécurité : normes d'authentification et d'Encryption
Le choix des protocoles de sécurité dans l'Internet des objets (IoT) est compliqué par les contraintes de puissance de calcul et de mémoire des terminaux périphériques, qui rendent les protocoles de sécurité couramment utilisés dans les environnements informatiques d'entreprise peu pratiques, voire impossibles à mettre en œuvre sur du matériel aux ressources limitées.
TLS 1.2 et TLS 1.3 sont les protocoles de chiffrement standard pour les appareils IoT disposant de ressources de calcul suffisantes. TLS 1.3 réduit la latence de la phase d’établissement de connexion par rapport à TLS 1.2 en éliminant un aller-retour de la séquence d’établissement, ce qui est important pour les appareils NB-IoT et LTE-M où chaque transmission radio a un coût énergétique mesurable. Le choix de la suite de chiffrement au sein de TLS est crucial pour l’IoT : l’échange de clés ECDHE et l’algorithme AES-128-GCM constituent la combinaison recommandée pour les déploiements IoT, offrant un bon équilibre entre la sécurité et l’efficacité de calcul.
Le DTLS (Datagram TLS) est le protocole de sécurité adapté aux déploiements CoAP ; il offre des garanties de sécurité équivalentes à celles de TLS pour le transport basé sur le protocole « UDP ».
L'authentification mutuelle basée sur des certificats X.509 est le mécanisme d’authentification des appareils recommandé pour les déploiements IoT d’entreprise à grande échelle. Les clés pré-partagées sont plus simples à mettre en œuvre, mais posent des problèmes de gestion des clés lorsque le parc d’appareils est important : la rotation d’une clé pré-partagée compromise sur des millions d’appareils déployés est une opération très lourde. Les certificats X.509, associés à l’identité individuelle de chaque appareil, permettent de procéder à la rotation et à la révocation des certificats au cas par cas, sans affecter les autres appareils du parc.
Les modules de sécurité matériels (HSM) et les environnements d'exécution fiables (TEE) jouent un rôle de plus en plus important pour les appareils IoT d’entreprise traitant des données sensibles ou fonctionnant dans des environnements où l’accès physique aux appareils par des personnes non autorisées constitue un risque. Le stockage des clés privées dans un élément protégé par matériel plutôt que dans la mémoire du micrologiciel empêche l’extraction des clés, même si le micrologiciel de l’appareil est compromis.
La pile de protocoles de sécurité doit être validée de bout en bout avant le déploiement. Un appareil qui implémente correctement le protocole TLS mais qui se connecte à un point de terminaison de la plateforme n’appliquant pas l’authentification mutuelle ne dispose que d’une architecture de sécurité incomplète. La validation de la sécurité dans l’IoT doit couvrir l’intégralité du parcours de la négociation de connexion, de l’appareil à la plateforme, y compris la couche réseau ( APN privée), la couche transport (configuration TLS) et la couche application (gestion des jetons d’authentification et gestion des sessions).
Formats de données et protocoles d’ Device Management
C'est au niveau de la couche application que les choix en matière de protocoles ont l'impact le plus direct sur la complexité de l'intégration de la plateforme.
LwM2M (Lightweight M2M, OMA SpecWorks) est le protocole de gestion des appareils conçu pour l’IoT, qui regroupe l’enregistrement des appareils, la mise à jour OTA du micrologiciel, la configuration à distance et la génération de rapports de télémétrie au sein d’un cadre protocolaire unique. Son modèle de données utilise une hiérarchie standardisée d’objets et de ressources qui permet aux plateformes de gestion des appareils d’interagir avec n’importe quel appareil conforme à LwM2M sans nécessiter de travail d’intégration spécifique à l’appareil. Pour les déploiements d’entreprise gérant des parcs d’appareils importants et hétérogènes, le modèle de gestion normalisé de LwM2M réduit considérablement la charge d’intégration liée à l’ajout de nouveaux types d’appareils au parc.
Considérations relatives au protocole FOTA (Firmware Over The Air) au niveau de la couche application sont souvent insuffisamment précis lors de la conception du déploiement. La taille des paquets de mise à jour du micrologiciel pour les appareils IoT peut varier de quelques dizaines de kilo-octets à plusieurs mégaoctets. Le protocole FOTA doit tenir compte des éléments suivants :
- Récupération après interruption du transfert, car un périphérique NB-IoT ou LTE-M peut perdre la connexion au cours du téléchargement du micrologiciel
- Prise en charge des mises à jour delta, dans laquelle seuls les segments de micrologiciel modifiés sont transmis, et non l'image complète, ce qui réduit la taille des données transmises et la consommation d'énergie
- Possibilité de revenir à la version précédente si le nouveau micrologiciel n'est pas validé sur l'appareil
Format de sérialisation des données Les choix effectués au niveau de la couche applicative ont une incidence sur l'efficacité de la transmission et la complexité de l'intégration à la plateforme. Le format JSON est largement pris en charge et lisible par l'utilisateur, mais il entraîne une surcharge importante par rapport aux formats binaires pour les appareils aux ressources limitées. Le format CBOR (Concise Binary Object Representation) offre une expressivité équivalente à celle du JSON dans un encodage binaire qui réduit généralement la taille de la charge utile de 50 à 70 %. Pour les appareils d’ NB-IoT s transmettant à haute fréquence ou disposant d’une autonomie limitée, la réduction de la charge utile offerte par le CBOR par rapport au JSON se traduit directement par une durée de vie de la batterie plus longue et des coûts de données réduits.
Cohérence de la pile de protocoles à l'échelle de l'entreprise
Les choix relatifs à la pile de protocoles décrits ci-dessus ne fonctionnent pas de manière indépendante. Un déploiement qui sélectionne l’ NB-IoT e au niveau de la couche physique, le protocole MQTT sur TCP au niveau de la couche de transport et le protocole TLS 1.2 avec poignée de main complète au niveau de la couche de sécurité a créé une pile dans laquelle la surcharge des couches de transport et de sécurité peut dominer le budget énergétique de l’appareil, au point de compromettre la raison d’être du choix de l’ NB-IoT e, à savoir son efficacité énergétique. CoAP sur UDP avec DTLS constituerait la pile cohérente pour un appareil « NB-IoT » soumis à des contraintes de consommation, tandis que MQTT sur TCP avec TLS est la pile appropriée pour un appareil « LTE-M » disposant d’un budget énergétique plus généreux.
La cohérence de la pile de protocoles est également importante pour l’infrastructure de connectivité. Un déploiement dans lequel les appareils se connectent via une « APN » privée avec des adresses IP statiques, communiquent via MQTT avec un courtier cloud et utilisent l’authentification mutuelle X.509 impose des exigences spécifiques à la plateforme de gestion de la connectivité : provisionnement de l’« APN » privée, attribution d’adresses IP statiques et gestion du cycle de vie des certificats s’intégrant à l’infrastructure d’identité des appareils.
L’infrastructure de connectivité de KORE constitue la base de la couche réseau sur laquelle s’appuient les piles de protocoles d’entreprise, notamment la configuration des adresses « APN », l’attribution d’adresses IP statiques et la connectivité multi-opérateurs grâce à plus de 40 partenariats avec des opérateurs et une présence dans plus de 200 pays. La plateforme ConnectivityPro assure la gestion du cycle de vie des cartes SIM et les contrôles de politique réseau qui régissent la couche de connectivité sous-jacente à toute pile de protocoles d’application utilisée par le déploiement. Avec plus de 21 millions de cartes SIM actives déployées dans des secteurs verticaux où la cohérence de la pile de protocoles influe directement sur les résultats opérationnels, l’infrastructure est conçue pour prendre en charge l’ensemble des configurations de connectivité IoT d’entreprise requises par les déploiements en production.
Pour mettre en place correctement la pile de protocoles, il faut évaluer chaque couche en tenant compte des couches adjacentes, puis valider l'ensemble de la pile de bout en bout avant de procéder au déploiement à grande échelle sur le matériel. Les problèmes d'intégration résultant d'incompatibilités entre protocoles peuvent être résolus, mais il est moins coûteux de les résoudre en laboratoire que sur le terrain.
Discutez avec un ingénieur en connectivité chez KORE des exigences en matière d’infrastructure au niveau de la couche réseau pour votre pile de protocoles IoT.
Publié le 29 mai 2026.