MQTT vs HTTP pour l'IoT : quel protocole choisir ?

MQTT vs HTTP est généralement la première décision de protocole d'un projet IoT, et une erreur à ce stade se paie plus tard en batteries vidées, en tableaux de bord poussifs ou en serveur submergé de requêtes de polling. Ce guide compare les deux en termes de surcoût, de push face au polling, de consommation d'énergie et de modèle de connexion, puis vous fournit un script de benchmark pour mesurer la différence sur votre propre réseau plutôt que de croire qui que ce soit sur parole.

Deux modèles de communication différents

HTTP est un protocole requête/réponse. Un client ouvre une connexion, envoie une requête avec une méthode, un chemin et des en-têtes, et le serveur répond. Le serveur ne peut pas prendre la parole en premier. Si un appareil doit savoir si une nouvelle commande l'attend, il doit le demander, encore et encore.

MQTT est un protocole publish/subscribe. Chaque client maintient une connexion TCP de longue durée vers un broker, publie des messages sur des topics et s'abonne aux topics qui l'intéressent. Le broker pousse les messages correspondants dès leur arrivée. Éditeurs et abonnés ne s'adressent jamais directement les uns aux autres, ce qui permet à une même mesure de capteur d'atteindre simultanément un tableau de bord, un service d'écriture en base et un service d'alerte. Pour voir ce qui se trouve au milieu, lisez le rôle d'un broker MQTT.

Cette seule différence, celui qui initie la conversation, détermine presque tous les autres compromis ci-dessous.

MQTT vs HTTP en un coup d'œil

Surcoût : les octets sur le réseau

Chaque requête HTTP transporte une ligne de requête, un en-tête Host et généralement le type de contenu, la longueur du contenu, l'autorisation, l'agent utilisateur et plus encore. Tout cela est du texte, et tout cela est renvoyé à chaque requête. Pour une mesure de capteur de 20 octets, les en-têtes peuvent facilement être dix fois plus volumineux que les données.

Un paquet PUBLISH MQTT comporte un en-tête fixe pouvant ne faire que 2 octets, le nom du topic et le payload. L'authentification n'a lieu qu'une fois, au CONNECT. Ensuite, chaque mesure ne coûte guère plus que son topic et ses données. MQTT 5 peut encore réduire ce coût avec les topic aliases, qui remplacent une longue chaîne de topic par un petit entier.

TLS change la donne pour les deux. Le handshake est coûteux, et les clients HTTP qui ouvrent une nouvelle connexion TLS à chaque requête le paient à chaque fois. MQTT le paie une fois par connexion. Le keep-alive HTTP et HTTP/2 réduisent l'écart, mais de nombreux clients HTTP contraints ne les utilisent pas.

Push vs polling

Si le cloud doit envoyer une commande à un appareil, HTTP vous laisse trois options : interroger fréquemment et gaspiller de la bande passante, interroger rarement et accepter la latence, ou greffer un second canal comme WebSocket ou les server-sent events. MQTT, lui, livre tout simplement. Un appareil abonné à devices/pump-7/cmd reçoit une commande dès qu'elle est publiée, généralement dans le temps d'un aller-retour réseau.

Le polling passe aussi mal à l'échelle côté serveur. Mille appareils qui interrogent toutes les cinq secondes, ce sont des centaines de requêtes par seconde, que quelque chose ait changé ou non. Avec MQTT, le broker reste inactif tant qu'il n'y a rien à dire.

Impact sur la batterie et le réseau

Pour les appareils sur batterie, la radio représente généralement le principal poste de consommation, et ce qui compte, c'est la fréquence et la durée de son activation. Le polling HTTP réveille la radio selon un calendrier, ouvre une connexion, négocie éventuellement TLS, envoie des en-têtes et attend une réponse. MQTT maintient une connexion ouverte avec de petits paquets PINGREQ à chaque intervalle de keep alive et, le reste du temps, ne transmet que des données réelles.

Cela ne rend pas MQTT automatiquement meilleur pour tous les appareils sur batterie. Un capteur qui se réveille une fois par heure, envoie une mesure puis se rendort ne tire aucun avantage d'une connexion persistante, et un simple POST HTTP peut être plus simple. Le modèle de connexion persistante est rentable lorsque les appareils envoient fréquemment, doivent recevoir des commandes ou doivent signaler leur état en ligne. Sur les liaisons cellulaires, où chaque octet et chaque établissement de connexion coûtent de l'argent, des paquets plus petits et moins de handshakes font vite la différence.

Lancez votre propre benchmark MQTT vs HTTP

Les chiffres dépendent de votre réseau, de vos réglages TLS et de votre bibliothèque : mesurez donc. Le script ci-dessous envoie 200 petites mesures JSON en MQTT au serveur MQTT public gratuit, réservé aux tests, et 200 en HTTP POST à un serveur de test local, puis affiche le temps écoulé pour chacun. Installez d'abord les deux dépendances.

pip install "paho-mqtt>=2.0" requests

import json
import threading
import time
import uuid
from http.server import BaseHTTPRequestHandler, HTTPServer

import paho.mqtt.client as mqtt
import requests

N = 200
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}"
reading = json.dumps({"device": "bench-1", "temp": 21.7, "hum": 48})

# --- Point d'accès HTTP local minimal ---
class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        self.rfile.read(int(self.headers["Content-Length"]))
        self.send_response(204)
        self.end_headers()
    def log_message(self, *args):
        pass

server = HTTPServer(("127.0.0.1", 8080), Handler)
threading.Thread(target=server.serve_forever, daemon=True).start()

# --- HTTP : un POST par mesure, nouvelle connexion à chaque fois ---
start = time.perf_counter()
for _ in range(N):
    requests.post("http://127.0.0.1:8080/telemetry", data=reading,
                  headers={"Content-Type": "application/json"})
http_new = time.perf_counter() - start

# --- HTTP : réutiliser une seule session keep-alive ---
session = requests.Session()
start = time.perf_counter()
for _ in range(N):
    session.post("http://127.0.0.1:8080/telemetry", data=reading,
                 headers={"Content-Type": "application/json"})
http_keepalive = time.perf_counter() - start

# --- MQTT : une connexion, QoS 1, attente de chaque PUBACK ---
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"bench-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

start = time.perf_counter()
for _ in range(N):
    info = client.publish(f"{PREFIX}/telemetry", reading, qos=1)
    info.wait_for_publish()
    time.sleep(0.11)  # rester sous la limite de 10 msg/s par client du broker public
mqtt_elapsed = time.perf_counter() - start - N * 0.11

client.loop_stop()
client.disconnect()
server.shutdown()

print(f"HTTP new connection : {http_new:.2f}s")
print(f"HTTP keep-alive     : {http_keepalive:.2f}s")
print(f"MQTT QoS 1 (net)    : {mqtt_elapsed:.2f}s")

Deux réserves garantissent l'honnêteté de la comparaison. Le serveur HTTP tourne sur localhost, il n'a donc pas d'aller-retour Internet, alors que le broker MQTT est distant ; pointez le test HTTP vers un vrai point d'accès distant si vous voulez comparer la latence à armes égales. Par ailleurs, le serveur MQTT public gratuit limite chaque client à 10 messages par seconde : le script marque donc une pause entre les publications et soustrait ce temps. Pour compter les octets plutôt que le temps, exécutez le même script sous Wireshark et comparez le nombre total d'octets par mesure. C'est généralement là que la différence est la plus frappante.

Quand HTTP est le bon choix

HTTP reste le meilleur outil dans plusieurs situations :

• Envois peu fréquents depuis des appareils qui dorment longtemps et n'ont jamais besoin de commandes.
• Transferts volumineux comme les images de firmware, les journaux ou les instantanés de caméra, où les requêtes HTTP par plage, les CDN et la mise en cache excellent.
• API publiques et partenaires, où chaque développeur et chaque outil parle déjà REST.
• Réseaux restrictifs qui n'autorisent que le HTTPS sortant. Même dans ce cas, le MQTT sur WebSocket sécurisé est souvent autorisé, car il démarre comme un upgrade HTTPS ordinaire.

De nombreux systèmes réels utilisent les deux : MQTT pour la télémétrie, les commandes et l'état, HTTP pour le provisionnement, les téléchargements de firmware et les API de back-office. Un petit service passerelle qui s'abonne à MQTT et expose un point d'accès REST est un schéma courant ; le guide MQTT vers API REST avec Flask en présente un.

Quand MQTT est le bon choix

Choisissez MQTT lorsque les appareils remontent souvent des données, lorsque le cloud doit joindre rapidement les appareils, lorsque plusieurs consommateurs ont besoin des mêmes données ou lorsque vous devez savoir quels appareils sont en ligne. Les retained messages fournissent l'état courant aux retardataires, le Last Will publie un statut hors ligne quand un appareil décroche, et les niveaux de QoS vous permettent d'arbitrer entre surcoût et garanties de livraison pour chaque message. L'article sur le modèle publish/subscribe de MQTT explique pourquoi le découplage des producteurs et des consommateurs compte à mesure qu'un système grandit.

Le prix de MQTT, c'est qu'il vous faut un broker, et l'exploiter de façon fiable représente un vrai travail opérationnel, des certificats TLS aux limites de connexions. ConnectMQ prend en charge cet aspect pour vous. C'est la principale raison pour laquelle les équipes choisissent un broker MQTT managé plutôt que de maintenir le leur. Si vous êtes encore en train d'acquérir les bases, le tutoriel MQTT couvre pas à pas les topics, la QoS et les sessions.

Checklist de décision

1. Le serveur doit-il pousser des données ou des commandes vers les appareils ? Si oui, penchez pour MQTT.
2. Les appareils envoient-ils des données plus de quelques fois par heure ? Si oui, penchez pour MQTT.
3. Plusieurs services consomment-ils les mêmes données ? Si oui, penchez pour MQTT.
4. Le payload est-il volumineux, ou l'échange est-il un transfert de fichier ponctuel ? Si oui, utilisez HTTP.
5. Des tiers doivent-ils s'intégrer avec l'outillage web standard ? Exposez HTTP en bordure de votre système.
6. L'état en ligne/hors ligne est-il important ? MQTT vous offre gratuitement le keep alive et le Last Will.

Essayez MQTT sur ConnectMQ

Le moyen le plus rapide de trancher entre MQTT et HTTP pour votre projet est de faire tourner votre propre appareil face à un vrai broker. ConnectMQ vous fournit un broker privé sécurisé par TLS sur les ports 8883 et 8084, avec des identifiants générés, un client MQTT intégré au navigateur et un explorateur de topics en direct. Commencez avec le plan Serverless gratuit sur app.connectmq.com, sans carte bancaire, et comparez les résultats avec votre configuration HTTP actuelle.

Questions fréquentes

MQTT est-il plus rapide que HTTP ?

Pour des petits messages fréquents, généralement oui, car MQTT réutilise une seule connexion et envoie des en-têtes bien plus petits. Pour un seul transfert volumineux, la différence est faible et l'outillage HTTP est souvent meilleur.

MQTT peut-il remplacer une API REST ?

Il peut remplacer les points d'accès d'appareils basés sur le polling, mais REST reste plus adapté aux API publiques, aux opérations CRUD et aux transferts de fichiers. La plupart des plateformes IoT utilisent les deux.

MQTT consomme-t-il moins de batterie que HTTP ?

Lorsque les appareils communiquent souvent ou doivent recevoir des commandes, généralement oui, puisqu'il n'y a ni handshakes répétés ni polling. Les appareils qui se réveillent rarement pour envoyer une seule mesure en tireront peu d'avantage.

Les navigateurs peuvent-ils utiliser MQTT comme ils utilisent HTTP ?

Oui, grâce au MQTT sur WebSocket. Les clients navigateur se connectent à une URL comme wss://broker.connectmq.com:8084/mqtt à l'aide d'une bibliothèque comme MQTT.js.