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

HTTP fait tourner le web ; MQTT a été conçu pour des machines sur des réseaux peu fiables. Les deux fonctionnent sur TCP, les deux peuvent être sécurisés avec TLS et les deux peuvent transporter du JSON. La différence tient au modèle de communication — et c’est ce modèle qui détermine lequel convient à votre cas d’usage IoT. Cet article les compare honnêtement, y compris là où HTTP est le meilleur choix.

Deux modèles de communication différents

HTTP fonctionne en requête/réponse. Un client demande une ressource précise à un serveur précis et attend la réponse. Le serveur ne peut pas parler en premier : si un appareil doit être informé d’un changement, il doit interroger périodiquement (polling), garder une longue requête ouverte ou utiliser un mécanisme supplémentaire comme les server-sent events ou les WebSockets.

MQTT fonctionne en publish/subscribe. Les clients se connectent à un broker et gardent la connexion ouverte. Les éditeurs envoient des messages sur des topics ; le broker les pousse vers chaque abonné de ce topic. Émetteurs et récepteurs n’ont jamais besoin de se connaître. Si vous découvrez ce modèle, lisez d’abord qu’est-ce que MQTT.

Comparatif MQTT vs HTTP

Surcoût et autonomie de la batterie

Un paquet MQTT minimal comme PINGREQ ne fait que 2 octets, et une publication n’ajoute que le nom du topic et le payload à un petit en-tête. Une requête HTTP transporte une ligne de méthode, un en-tête host et souvent des en-têtes user-agent, content-type, authorization et cookie — en texte, à chaque requête. Quand un capteur envoie une mesure de 20 octets toutes les quelques secondes, ce surcoût de framing domine le trafic.

L’établissement de la connexion compte encore davantage. Chaque nouvelle connexion HTTPS coûte un handshake TCP et TLS, c’est-à-dire du temps radio et de la batterie sur un appareil cellulaire. MQTT paie ce coût une seule fois, puis réutilise la connexion dans les deux sens. Le keep-alive HTTP et HTTP/2 réduisent l’écart, mais ne donnent pas au serveur le moyen de pousser des données vers l’appareil.

Fiabilité sur des réseaux médiocres

MQTT intègre la sémantique de livraison dans le protocole. Les QoS 1 et 2 acquittent et relancent les messages, les sessions persistantes mettent en file les messages des clients qui décrochent, les messages retenus (retained) donnent immédiatement la dernière valeur connue à un nouvel abonné, et un Last Will prévient tout le monde lorsqu’un appareil disparaît sans dire au revoir. Avec HTTP, vous construisez chacun de ces éléments vous-même : relances, clés d’idempotence, stockage d’état et endpoint de heartbeat.

Sécurité

Les deux protocoles s’appuient sur TLS pour le chiffrement : aucun n’est intrinsèquement plus sûr. La différence tient à l’endroit où s’effectue l’autorisation. Une API HTTP authentifie chaque requête, généralement avec un jeton, et l’autorise par endpoint. Un broker MQTT authentifie une seule fois au CONNECT (nom d’utilisateur/mot de passe, certificats clients ou, en MQTT 5, authentification étendue), puis autorise chaque publication et chaque abonnement selon des règles d’accès par topic. Une hiérarchie de topics bien pensée fait donc partie de votre modèle de sécurité : une règle comme cet appareil ne peut publier que dans son propre sous-arbre est facile à exprimer lorsque les topics contiennent l’ID de l’appareil.

Montée en charge

Les services HTTP montent en charge horizontalement derrière un load balancer, car chaque requête est indépendante. Les brokers MQTT conservent un état pour chaque client connecté — abonnements, sessions, messages en vol — : passer à de grandes flottes implique donc de clusteriser le broker ou de recourir à un fournisseur qui le fait. Côté consommateurs, les abonnements partagés de MQTT 5 répartissent les messages entre plusieurs workers backend. Aucune approche n’est globalement plus difficile ; elles placent simplement la complexité à des endroits différents.

La même mesure, de deux façons

curl -X POST https://api.example.com/devices/sensor-17/readings \
  -H 'Content-Type: application/json' \
  -d '{"temp":21.4}'

mosquitto_pub -h broker.emqx.io -t 'testmqtt/sensor-17/temp' -q 1 -m '{"temp":21.4}'

Avec HTTP, c’est l’API qui décide qui reçoit ensuite la mesure. Avec MQTT, un tableau de bord, un writer de base de données et un service d’alertes peuvent tous s’abonner à testmqtt/+/temp sans que l’appareil sache qu’ils existent.

S’abonner aux mesures en direct dans le navigateur

Quand utiliser MQTT

• Télémétrie fréquente provenant de nombreux appareils.
• Envoi de commandes à des appareils situés derrière un NAT ou un pare-feu — ils se connectent vers l’extérieur, le broker pousse vers eux.
• Tableaux de bord et alertes en temps réel qui ont besoin de push, pas de polling.
• Matériel contraint, liaisons facturées au volume ou appareils sur batterie.
• Un même événement consommé par plusieurs services indépendants.

Quand utiliser HTTP

• Interroger et gérer des ressources (registre d’appareils, paramètres, comptes utilisateurs) via une API REST.
• Transferts de gros fichiers comme des images firmware, des logs ou des captures de caméra.
• Envois ponctuels et peu fréquents, pour lesquels garder une connexion ouverte n’en vaut pas la peine.
• API publiques destinées à des tiers qui attendent l’outillage web standard, le cache et l’authentification habituels.

Et les navigateurs ?

Les navigateurs ne peuvent pas ouvrir de connexions MQTT brutes, mais MQTT fonctionne très bien sur WebSockets, qui commencent par une requête d’upgrade HTTP. Les tableaux de bord web bénéficient ainsi du push en direct sur les mêmes topics que vos appareils. Voir MQTT sur WebSockets pour les ports et la configuration.

Verdict

Choisissez MQTT pour une communication événementielle, bidirectionnelle et impliquant de nombreux appareils ; choisissez HTTP pour les API orientées ressources et les transferts volumineux. En cas de doute, prototypez la partie MQTT en quelques minutes avec le client MQTT en ligne et un broker de test public avant de vous engager.

Questions fréquentes