Protocoles IoT : MQTT, CoAP
Définition
Les environnements IoT nécessitent des protocoles de communication légers, adaptés aux appareils à ressources limitées (CPU, RAM, batterie). Les deux protocoles dominants sont :
- MQTT (Message Queuing Telemetry Transport) : protocole publish/subscribe fonctionnant sur TCP, conçu pour les réseaux à faible bande passante et haute latence.
- CoAP (Constrained Application Protocol) : protocole requête/réponse (RESTful) fonctionnant sur UDP, pensé pour les micro-contrôleurs et les réseaux contraints (6LoWPAN).
Contexte
Alors que HTTP est trop lourd pour la plupart des capteurs et actuateurs IoT, MQTT et CoAP offrent des échanges efficaces avec un overhead minimal. La certification CCST attend du candidat qu'il comprenne le rôle de ces protocoles dans l'écosystème IoT et leurs différences fondamentales.
Détails techniques
MQTT — architecture publish/subscribe
Capteurs ──publish──▶ BROKER MQTT ──deliver──▶ Abonnés (dashboard, backend)
(Mosquitto, (filtrage par topic)
HiveMQ, AWS IoT Core)
| Concept |
Description |
| Broker |
Serveur central qui reçoit les messages et les distribue aux abonnés |
| Topic |
Chemin hiérarchique de publication (ex : usine/ligne1/temperature) |
| QoS 0 |
At most once — fire-and-forget, aucune garantie |
| QoS 1 |
At least once — le broker acquitte ; doublon possible |
| QoS 2 |
Exactly once — handshake en 4 étapes, le plus fiable mais le plus lent |
| Retained message |
Le broker garde le dernier message d'un topic pour les nouveaux abonnés |
| Last Will & Testament |
Message envoyé automatiquement si un client se déconnecte anormalement |
- Port par défaut : 1883 (non chiffré), 8883 (MQTT over TLS).
- Overhead : en-tête fixe de seulement 2 octets (vs ~700 octets pour HTTP).
CoAP — architecture requête/réponse
| Propriété |
Détail |
| Transport |
UDP (port 5683), DTLS pour chiffrement (port 5684) |
| Méthodes |
GET, PUT, POST, DELETE (similaires à HTTP) |
| En-tête |
4 octets fixes |
| Mode Observe |
Le client s'abonne à une ressource ; le serveur pousse les mises à jour (équivalent simpliste de pub/sub) |
| Découverte |
/.well-known/core expose les ressources disponibles au format CoRE Link Format |
MQTT vs CoAP
| Critère |
MQTT |
CoAP |
| Modèle |
Publish/Subscribe |
Requête/Réponse (+ Observe) |
| Transport |
TCP |
UDP |
| Sécurité |
TLS |
DTLS |
| Broker requis |
Oui |
Non (point-à-point) |
| Overhead |
~2 octets |
~4 octets |
| Cas d'usage idéal |
Télémétrie vers cloud, many-to-many |
Communication M2M locale, découverte de services |
| Fiabilité |
QoS 0/1/2 |
Confirmable / Non-confirmable |
Autres protocoles IoT notables
| Protocole |
Caractéristique |
| AMQP |
File d'attente de messages ; plus lourd que MQTT, utilisé en entreprise |
| HTTP/REST |
Compatible partout mais lourd pour l'IoT |
| Bluetooth LE |
Courte portée, très basse consommation |
| Zigbee / Z-Wave |
Réseaux mesh domotiques, basse puissance |
| LoRaWAN |
Longue portée (km), très bas débit, idéal pour les capteurs extérieurs |
Exemple concret
Scénario : une serre intelligente surveille 200 capteurs (température, humidité, luminosité, CO₂).
- Chaque capteur publie ses mesures toutes les 30 secondes sur un topic MQTT (
serre/zone-A/temperature, serre/zone-B/humidite…) avec QoS 1 pour garantir la livraison.
- Un broker Mosquitto local reçoit tous les messages et les redistribue :
- Un dashboard Grafana s'abonne à
serre/# pour l'affichage en temps réel.
- Un service d'alerte s'abonne à
serre/+/temperature et déclenche une alarme si T > 35 °C.
- Les actuateurs (vannes d'arrosage) utilisent CoAP en mode Observe : ils exposent une ressource
/valve/state que le contrôleur surveille et commande via PUT.
- Toutes les communications MQTT sont chiffrées via TLS (port 8883) ; les échanges CoAP locaux utilisent DTLS.
