Choisir un protocole de transport IoT : UDP, TCP/IP, HTTPS, MQTT et le rôle de TagoTiP

Tout projet IoT commence par la même question fondamentale : comment mon appareil communique-t-il avec le cloud ? Les capteurs, les actionneurs et les microcontrôleurs génèrent des données qui ne prennent de la valeur qu’une fois arrivées sur une plateforme où elles peuvent être stockées, visualisées et exploitées. Mais acheminer des données d’un appareil vers le cloud n’est pas un simple détail technique : le protocole que vous choisissez aura un impact direct sur l’autonomie de la batterie, les coûts de données, la fiabilité, la complexité et l’extensibilité de votre appareil.

Dans cet article, nous passons en revue les protocoles de connectivité les plus courants en IoT, UDP, TCP/IP, HTTPS et MQTT, puis nous présentons TagoTiP (Transport IoT Protocol), un nouveau protocole ouvert développé par TagoIO et conçu spécialement pour les appareils aux ressources limitées comme l’Arduino, l’ESP8266, l’ESP32 et toute autre petite carte IoT qui doit atteindre le cloud le plus efficacement possible.

UDP, rapide, léger, à sens unique

UDP (User Datagram Protocol) est l’un des protocoles de transport les plus fondamentaux des réseaux. Il envoie des paquets de données sans établir de connexion préalable et sans aucun accusé de réception confirmant que les données sont bien arrivées.

Imaginez UDP comme une carte postale glissée dans une boîte aux lettres. Vous l’envoyez et vous passez à autre chose : impossible de savoir si elle est vraiment arrivée.

Les avantages d’UDP sont notables pour les applications IoT où la vitesse et la faible surcharge comptent plus que la garantie de livraison. Comme il n’y a ni établissement de connexion ni processus d’accusé de réception, UDP est extrêmement rapide et n’impose presque aucune surcharge à l’appareil. Les paquets sont petits, et l’appareil peut se rendormir presque immédiatement après l’émission. Cela rend UDP particulièrement adapté aux appareils sur batterie, aux déploiements NB-IoT et aux scénarios où une perte occasionnelle de paquet est acceptable, par exemple l’envoi de relevés de capteurs périodiques où manquer une valeur sur cent ne pose pas de problème.

Les inconvénients sont bien réels eux aussi. UDP n’offre absolument aucune garantie de livraison. Les paquets peuvent être abandonnés par le réseau, arriver dans le désordre ou être dupliqués, sans que l’émetteur n’en sache jamais rien. Il n’y a pas non plus de sécurité intégrée, pas de gestion de session, ni de prise en charge native de la communication bidirectionnelle. Mettre en place de la fiabilité par-dessus UDP exige une logique applicative sur mesure, ce qui ajoute de la complexité au développement.

Idéal pour : la télémétrie à haute fréquence, les appareils contraints sur réseaux basse consommation, les applications où la vitesse prime sur la garantie de livraison.

TCP/IP, une communication fiable orientée connexion

TCP (Transmission Control Protocol), toujours associé à IP (Internet Protocol), constitue l’épine dorsale d’Internet. Contrairement à UDP, TCP établit une connexion entre l’appareil et le serveur avant tout échange de données, suit chaque paquet, retransmet ceux qui sont perdus et garantit que les données arrivent dans l’ordre.

Si UDP est une carte postale, TCP est une lettre recommandée avec accusé de réception.

Les atouts de TCP/IP sont évidents : vous obtenez une livraison garantie, une transmission ordonnée et un contrôle d’erreurs intégré. Pour les cas d’usage IoT où l’intégrité des données est critique, systèmes de contrôle industriel, dispositifs médicaux, télémétrie financière, TCP/IP est difficile à battre. Il est aussi universellement pris en charge, ce qui signifie que pratiquement tout environnement de programmation, du C embarqué sur un microcontrôleur à Python sur un Raspberry Pi, dispose de bibliothèques TCP/IP.

Les coûts sont eux aussi clairs. La fiabilité de TCP a un prix : la surcharge. Établir une connexion nécessite une poignée de main en trois temps. Maintenir la connexion ouverte exige des paquets keep-alive périodiques. Chaque segment transporte des en-têtes qui alourdissent les coûts de données. Sur des appareils très contraints à la RAM limitée ou sur des connexions cellulaires facturées au kilo-octet, cette surcharge compte. TCP maintient également une connexion persistante ouverte, ce qui entre en conflit avec les cycles de veille et de réveil qui prolongent l’autonomie des appareils basse consommation.

Idéal pour : la transmission fiable de données pour applications critiques, les appareils de type middleware et gateway, les systèmes nécessitant une communication bidirectionnelle avec garanties de livraison.

HTTPS, le standard du web pour des données IoT sécurisées

HTTPS est HTTP (HyperText Transfer Protocol) superposé à TLS (Transport Layer Security), qui s’appuie lui-même sur TCP/IP. C’est le même protocole que votre navigateur utilise à chaque visite d’un site web sécurisé, et il est devenu un choix populaire pour que les appareils IoT poussent leurs données vers des API cloud.

L’attrait de HTTPS en IoT tient à son universalité et à sa simplicité. Toute plateforme cloud, y compris TagoIO, expose une API REST sur HTTPS. Envoyer des données revient simplement à effectuer une requête HTTP POST avec un payload JSON. Des bibliothèques existent pour pratiquement tous les langages et tous les frameworks de microcontrôleurs, dont le HTTPClient d’Arduino et la pile Wi-Fi intégrée de l’ESP32. L’authentification se gère via des en-têtes de jeton, et TLS fournit un chiffrement de bout en bout d’emblée, satisfaisant la plupart des exigences de sécurité en entreprise sans implémentation sur mesure.

Le problème est que HTTPS est le plus lourd des protocoles IoT courants. Les poignées de main TLS sont coûteuses en calcul et gourmandes en mémoire, souvent trop pour de très petits microcontrôleurs. Chaque cycle requête-réponse ouvre une connexion, négocie TLS, envoie les données, reçoit une réponse et ferme la connexion. Pour un appareil qui envoie un relevé par minute, ce cycle est acceptable. Pour un appareil qui envoie des dizaines de relevés par seconde, ou qui tourne sur un minuscule microcontrôleur 8 bits doté de 2 Ko de RAM, HTTPS devient vite impraticable. La consommation d’énergie est aussi nettement plus élevée qu’avec UDP ou MQTT, à cause du temps durant lequel la radio doit rester active pendant l’ensemble du cycle requête-réponse.

Pour illustrer concrètement le poids de HTTPS : un payload HTTP/JSON classique transportant un relevé de capteur pèse environ 487 octets une fois pris en compte les en-têtes, la structure JSON et les champs d’authentification. Pour un appareil qui transmet sur une liaison cellulaire contrainte, cette surcharge s’accumule vite.

Idéal pour : les appareils Wi-Fi ou cellulaires connectés au cloud disposant de suffisamment de mémoire, les intégrations d’API REST, l’envoi sécurisé de données depuis des gateways et des appareils edge.

MQTT, le standard de l’industrie IoT

MQTT (Message Queuing Telemetry Transport) a été conçu dès le départ pour l’IoT. Développé à l’origine à la fin des années 1990 pour surveiller des oléoducs via des liaisons satellites, il est devenu l’un des protocoles de messagerie les plus largement adoptés du secteur.

MQTT utilise un modèle publication/abonnement piloté par un broker central. Les appareils publient des messages sur des topics (comme factory/machine1/temperature), et les abonnés, dashboards, moteurs d’analyse ou autres appareils, reçoivent ces messages en s’abonnant aux topics concernés. L’appareil et le dashboard ne communiquent jamais directement ; le broker gère tout le routage.

Les atouts de MQTT sont nombreux. Il est léger et efficace, avec une surcharge minimale de seulement 2 octets par paquet. Il prend en charge trois niveaux de qualité de service (QoS) : QoS 0 pour l’envoi à sens unique, QoS 1 pour une livraison au moins une fois, et QoS 2 pour une livraison exactement une fois. Cette souplesse vous permet d’ajuster le protocole aux exigences de fiabilité de votre application. MQTT prend aussi en charge les sessions persistantes, si bien qu’un broker peut mettre en file d’attente les messages destinés à un appareil temporairement hors ligne, ce que ni UDP ni HTTPS brut ne savent faire nativement.

TagoIO propose plusieurs options de broker MQTT dédié. Les appareils publient leurs données, le Live Inspector de la plateforme les montre arriver en temps réel, et les Actions peuvent les traiter et les stocker automatiquement, sans middleware sur mesure supplémentaire.

Les limites de MQTT tiennent surtout à la surcharge de connexion. MQTT s’appuie sur TCP, ce qui suppose de maintenir une connexion persistante. Pour les appareils qui passent en veille profonde entre deux relevés afin d’économiser la batterie, établir une connexion TCP à chaque réveil ajoute de la latence et de la consommation. Le broker représente aussi un point de défaillance unique, sauf si vous mettez en place du clustering ou de la redondance.

Idéal pour : la télémétrie en temps réel, la gestion de flotte, la communication bidirectionnelle entre appareils, les applications nécessitant la persistance des messages et des garanties de QoS.

TagoTiP, un format de trame commun pour UDP, TCP/IP, HTTPS et MQTT

Chacun des protocoles évoqués plus haut résout le problème du transport, comment les octets passent de l’appareil au serveur, mais aucun ne répond à une autre question, tout aussi pratique : à quoi ces octets doivent-ils réellement ressembler ? Les développeurs qui connectent une petite carte à TagoIO doivent encore décider comment structurer leurs données, comment s’authentifier, comment encoder les noms de variables, les valeurs, les unités et les horodatages, et comment faire tout cela d’une manière que la plateforme sait analyser. Ce travail d’implémentation est généralement reconstruit de zéro à chaque nouveau projet.

C’est le problème que TagoTiP a été conçu pour résoudre.

TagoTiP (Transport IoT Protocol) est un nouveau format de trame ouvert et une spécification de protocole développés par TagoIO, publiés sur github.com/tago-io/tagotip sous licence Apache 2.0. Ce n’est pas une alternative à UDP, TCP/IP, HTTPS ou MQTT : il fonctionne par-dessus chacun d’eux. La même trame TagoTiP peut être envoyée via UDP pour les appareils les plus contraints, via TCP pour la fiabilité, via HTTPS dans les environnements où seul le port 443 est ouvert, ou en tant que payload MQTT pour les déploiements en publication/abonnement. Les développeurs choisissent le transport adapté à leur matériel et à leur réseau ; TagoTiP s’occupe de la structure des données.

L’avantage pratique pour les petites cartes comme l’Arduino, l’ESP8266 et l’ESP32 est important : au lieu de fabriquer à la main des payload JSON, de gérer des en-têtes HTTP ou de construire des encodeurs binaires sur mesure, le développeur écrit une seule ligne compacte et l’envoie. TagoIO l’analyse nativement à l’autre bout.

Une trame lisible et compacte

Une trame TagoTiP est en texte clair, structurée et lisible sans aucun outil :

PUSH|4deedd7bab8817ec|sensor-01|[temperature:=32.5#C;humidity:=65#%]

Décomposons-la : PUSH est la méthode, 4deedd7bab8817ec est le hash d’autorisation (les 8 premiers octets du SHA-256 du jeton de l’appareil), sensor-01 est l’identifiant de série de l’appareil, et le payload entre crochets contient deux variables séparées par des points-virgules. La trame entière pèse environ 112 octets, contre environ 487 octets pour une requête HTTP/JSON équivalente, ce qui rend TagoTiP environ 4,3 fois plus petit pour les mêmes données.

Des métadonnées de variable riches dans une seule expression

Chaque variable accepte des suffixes facultatifs pour l’unité (#), l’horodatage (@), le groupe (^) et les métadonnées ({}), le tout dans une seule expression compacte :

temperature:=32.5#C@1694567890000^reading_001{source=dht22,quality=high}

Cela signifie qu’une seule ligne transporte tout ce dont TagoIO a besoin pour stocker un point de données bien annoté, nom de variable, valeur, unité, horodatage, groupe et métadonnées, sans imbrication JSON ni schéma sur mesure.

Méthodes du protocole

TagoTiP définit quatre méthodes qui couvrent tout le cycle de communication entre l’appareil et la plateforme, quel que soit le transport utilisé en dessous :

Payload en passthrough

Pour les appareils qui produisent déjà des payload binaires, TagoTiP prend en charge le passthrough en hex et en base64, en acheminant les octets bruts directement vers le payload parser d’un appareil dans TagoIO :

PUSH|AUTH|SERIAL|>xDEADBEEF01020304

PUSH|AUTH|SERIAL|>b3q2+7wECAwQ=

TagoTiP devient ainsi utile non seulement pour les nouveaux firmware, mais aussi comme enveloppe légère pour les appareils existants qui génèrent déjà des données binaires structurées sur l’un des transports pris en charge.

TagoTiP/S, la sécurité pour les liaisons sans TLS

Pour les environnements où TLS est indisponible ou trop coûteux en calcul, LoRa, Sigfox, NB-IoT, UDP brut, TagoTiP inclut une variante sécurisée appelée TagoTiP/S. Elle enveloppe les trames TagoTiP dans une enveloppe binaire chiffrée AEAD, offrant une confidentialité et une intégrité fortes sans poignée de main TLS.

TagoTiP/S prend en charge plusieurs suites de chiffrement, du AES-128-CCM obligatoire jusqu’à AES-256-GCM et ChaCha20-Poly1305. Même avec le chiffrement activé, le payload résultant ne pèse qu’environ 119 octets, soit 4,1 fois plus petit que HTTP/JSON, avec seulement 29 octets de surcharge d’enveloppe pour les chiffrements basés sur CCM.

Comparaison des tailles en un coup d’œil

Pourquoi cela compte pour Arduino, ESP et les petites cartes

Le format de trame a été explicitement conçu pour être adapté au C, analyse linéaire, tailles de buffer prévisibles, manipulation de chaînes réduite au minimum, ce qui le rend pratique à implémenter sur les microcontrôleurs AVR 8 bits et au-delà. Des cartes à la flash et à la RAM limitées peuvent implémenter la connectivité TagoIO en quelques lignes de code seulement, en envoyant la même trame compacte sur le transport que leur matériel prend en charge. Le choix du transport reste entre les mains du développeur ; TagoTiP se charge de la structure des données qui le traverse.

Choisir le bon protocole : un guide pratique

Aucun transport unique n’est le meilleur choix pour toutes les applications IoT. Le bon choix dépend des contraintes de votre appareil, de votre réseau, de vos exigences de fiabilité et de votre calendrier de développement.

Quel que soit le transport que vous choisissez, TagoTiP vous offre un format de données cohérent, compact et pris en charge nativement pour le faire transiter par n’importe lequel d’entre eux. Un développeur qui travaille avec un Arduino ou un ESP8266 peut écrire une seule trame TagoTiP et l’envoyer via UDP pour une surcharge minimale, via TCP pour la fiabilité, via HTTPS si seul le port 443 est disponible, ou en tant que payload MQTT pour les déploiements en publication/abonnement, les mêmes données structurées, la même analyse par TagoIO, quel que soit le chemin emprunté. La spécification ouverte complète est disponible sur github.com/tago-io/tagotip.

Pour le transport lui-même : si votre appareil a besoin d’une vitesse maximale et d’une surcharge minimale et qu’il tolère une perte occasionnelle de paquet, UDP est le choix naturel, et TagoTiP via UDP est le chemin le plus efficace vers TagoIO pour le matériel contraint. Si vous avez besoin d’une livraison garantie et ordonnée pour des données critiques, TCP/IP apporte cette fiabilité. Si la sécurité et la compatibilité universelle priment et que votre appareil dispose des ressources pour gérer TLS, HTTPS vous offre l’intégration d’API REST la plus simple. Et si vous avez besoin d’une communication bidirectionnelle, de la persistance des messages et de garanties de QoS sur une grande flotte, MQTT reste le standard éprouvé du secteur.

Pour conclure

La diversité des protocoles de connectivité IoT reflète la diversité des applications IoT elles-mêmes. Un capteur encastré dans un oléoduc au fond d’un champ isolé a des besoins radicalement différents de ceux d’un serveur gateway qui agrège les données de centaines d’appareils dans une usine. Comprendre les compromis de chaque protocole, surcharge, fiabilité, énergie, sécurité et complexité de développement, est essentiel pour bâtir des solutions IoT qui fonctionnent dans le monde réel.

TagoTiP s’insère dans ce paysage non pas en remplaçant l’un de ces transports, mais en résolvant la couche au-dessus d’eux : la structure des données. Plutôt que chaque développeur réinvente la façon d’encoder variables, unités, horodatages et authentification dans le transport qu’il utilise, TagoTiP définit un format unique, compact, lisible par l’humain et à typage sûr qui fonctionne sur tous. Pour les petites cartes comme l’Arduino, l’ESP8266 et l’ESP32, cela se traduit par moins de code, moins de bugs et un chemin cohérent vers TagoIO, peu importe comment voyagent les octets.

Pour explorer la spécification ouverte complète, la grammaire du protocole et les détails d’implémentation, rendez-vous sur le dépôt GitHub de TagoTiP à l’adresse github.com/tago-io/tagotip.