Protocoles IoE

Les protocoles définissent les règles d'échange de données entre les terminaux et les plateformes. En IoE, trois protocoles dominent : HTTP/REST pour le web, MQTT pour le temps réel léger, et CoAP pour les microcontrôleurs contraints.

Objectifs

À la fin de ce chapitre, vous serez capable de :

• Expliquer le fonctionnement de HTTP/REST (requête/réponse).
• Décrire le modèle publication/souscription de MQTT.
• Comprendre le rôle de CoAP pour les réseaux contraints.
• Choisir le protocole adapté selon le contexte IoE.

HTTP / REST → Requête / Réponse

HTTP est le protocole standard du Web. En IoE, il permet à un terminal d'interagir avec une API REST.

Fonctionnement

Le terminal (client) envoie une requête au serveur, qui retourne une réponse :

Méthode	Action	Exemple
GET	Lire des données	GET /capteurs/temperature
POST	Envoyer des données	POST /donnees
PUT	Modifier une configuration	PUT /config
DELETE	Supprimer une ressource	DELETE /capteurs/42

Les données sont généralement échangées au format JSON.

Avantages

• Standard et universel
• Facile à tester et déboguer
• Compatible avec tous les langages et services

Limites en IoE

• Plus lourd que MQTT (en-têtes HTTP importants)
• Le terminal doit toujours initier la connexion
• Consomme plus d'énergie et de mémoire

Contexte d'usage : terminaux puissants, APIs web, services cloud

MQTT → Publication / Souscription

MQTT (Message Queuing Telemetry Transport) est un protocole léger conçu spécialement pour les objets connectés à faibles ressources.

Fonctionnement

MQTT repose sur un modèle publish/subscribe avec un intermédiaire central appelé broker :

1. Un publisher (ex. capteur) publie un message sur un topic
2. Le broker reçoit le message et le redistribue
3. Les subscribers (ex. tableau de bord) abonnés à ce topic reçoivent le message

Exemple de topics MQTT

maison/salon/temperature     → 22.5
maison/cuisine/humidite      → 65
batiment/salle-serveur/alerte → true

Avantages

• Ultra-léger : fonctionne sur des terminaux avec très peu de ressources
• Communication en temps réel
• Le terminal n'a pas besoin d'être interrogé → le message est poussé
• Gestion de la qualité de service (QoS 0, 1, 2)
• Supporte des milliers d'appareils simultanément

Limites

• Nécessite un broker central (ex. Mosquitto, HiveMQ)
• Moins adapté aux interactions de type requête/réponse classiques

Contexte d'usage : capteurs IoE, domotique, temps réel, milliers d'appareils

CoAP → HTTP ultra-léger

CoAP (Constrained Application Protocol) est un protocole conçu pour les microcontrôleurs et les réseaux très contraints.

Fonctionnement

• Modèle requête/réponse similaire à HTTP
• Fonctionne sur UDP (plus léger que TCP)
• Supporte le mode observe (notification automatique en cas de changement)

Comparaison avec HTTP

Critère	HTTP	CoAP
Transport	TCP	UDP
En-têtes	Lourds	Très compacts
Ressources requises	Élevées	Très faibles
Mode push	Non natif	Observe intégré

Contexte d'usage : capteurs embarqués, réseaux LoRa, Zigbee, NB-IoT

Comparaison des protocoles

Critère	HTTP/REST	MQTT	CoAP
Modèle	Requête/réponse	Publish/subscribe	Requête/réponse
Transport	TCP	TCP	UDP
Poids	Lourd	Léger	Ultra-léger
Temps réel	Non	Oui	Partiel (observe)
Usage principal	APIs web, cloud	IoE temps réel	Microcontrôleurs

En résumé

HTTP = web standard · MQTT = publish/subscribe temps réel · CoAP = HTTP ultra-léger pour microcontrôleurs

Résumé

Les protocoles IoE définissent comment les données circulent entre terminaux et plateformes. HTTP/REST convient aux interactions web classiques, MQTT excelle dans les scénarios temps réel avec de nombreux appareils grâce à son modèle publish/subscribe, et CoAP offre une alternative ultra-légère pour les terminaux très contraints. Le choix du protocole dépend des ressources du terminal, du besoin en temps réel et de l'infrastructure disponible.