Qu’est-ce que MQTT ? Une introduction pratique

MQTT (à l’origine MQ Telemetry Transport) est un protocole de messagerie léger fondé sur le modèle publish/subscribe. Les clients ne se parlent jamais directement — ils envoient leurs messages à un broker central, étiquetés par un topic, et le broker transmet chaque message à tous les clients abonnés à un topic correspondant. C’est ce modèle simple qui permet à MQTT de faire tourner aussi bien des réseaux de capteurs et des maisons connectées que de la télémétrie de véhicules ou des tableaux de bord en temps réel.

Cette introduction explique comment fonctionne MQTT, quelles sont ses fonctionnalités importantes et quand c’est (ou non) le bon outil. Pour suivre en pratique, ouvrez le client MQTT en ligne dans un autre onglet.

Un bref historique

MQTT a été conçu en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper pour surveiller des oléoducs via des liaisons satellite coûteuses et peu fiables. Ses objectifs de conception — des paquets minuscules, un code client minimal, une tolérance aux réseaux instables — se sont révélés parfaitement adaptés à l’Internet des objets. MQTT 3.1.1 est devenu un standard OASIS en 2014 (puis ISO/IEC 20922), et MQTT 5.0 a suivi en 2019 avec les codes de raison, les user properties, l’expiration des messages et bien plus. Les deux versions sont largement déployées aujourd’hui ; voir MQTT 5 vs 3.1.1 pour les différences.

Comment fonctionne MQTT : publish/subscribe

MQTT ne comporte que deux rôles :

• Les clients — tout programme ou appareil qui se connecte au broker. Un client peut publier, s’abonner, ou les deux. Un capteur de température, une application mobile et un service backend ne sont que des clients.
• Le broker — le serveur qui accepte les connexions, authentifie les clients, fait correspondre les topics et livre les messages. Parmi les brokers populaires : Mosquitto, EMQX et HiveMQ.

Éditeurs et abonnés sont découplés : un éditeur ne sait pas qui (ni même si quelqu’un) reçoit son message, et les abonnés ne savent pas qui l’a envoyé. Ils partagent seulement un nom de topic. Il est ainsi facile d’ajouter un nouveau consommateur — un tableau de bord, un enregistreur en base de données, un service d’alertes — sans toucher aux appareils qui produisent les données.

sensor-17  --PUBLISH home/kitchen/temperature "21.5"-->  broker
broker     --PUBLISH home/kitchen/temperature "21.5"-->  dashboard   (subscribed to home/+/temperature)
broker     --PUBLISH home/kitchen/temperature "21.5"-->  logger      (subscribed to home/#)

Les topics : l’adresse d’un message

Un topic est une chaîne UTF-8 composée de niveaux séparés par des barres obliques, comme factory/line-2/press-4/pressure. Les topics ne sont pas créés à l’avance — ils existent dès que quelqu’un publie dessus. Les abonnés peuvent utiliser deux jokers (wildcards) : + correspond à exactement un niveau et # à un nombre quelconque de niveaux en fin de topic. Une bonne conception des topics compte beaucoup pour les permissions et la montée en charge ; notre guide des topics et jokers MQTT l’aborde en détail.

La connexion et ses paquets

MQTT fonctionne sur une connexion de longue durée — généralement TCP, éventuellement encapsulée dans TLS, ou des WebSockets pour les navigateurs. La session commence par un paquet CONNECT (client ID, nom d’utilisateur et mot de passe facultatifs, keep-alive, Last Will) auquel le broker répond par un CONNACK. Ensuite, les paquets les plus courants sont :

L’en-tête fixe d’un paquet MQTT ne fait que deux octets, et le payload est du binaire opaque — JSON, texte brut, Protobuf ou octets bruts conviennent tous. Ce faible surcoût rend MQTT attractif sur les appareils contraints et les réseaux facturés au volume.

Les fonctionnalités clés de MQTT

Qualité de service (QoS)

Chaque publication et chaque abonnement possède un niveau de QoS : 0 (au plus une fois), 1 (au moins une fois) ou 2 (exactement une fois). Les niveaux supérieurs ajoutent des paquets d’acquittement en échange de garanties de livraison plus fortes. Détails et flux de paquets dans les niveaux de QoS MQTT expliqués.

Messages retenus (retained)

Un message publié avec le flag retain est conservé par le broker comme dernière valeur connue du topic et livré immédiatement à chaque nouvel abonné. C’est idéal pour un état comme online/offline ou la consigne courante. Voir les messages retenus.

Last Will and Testament

Un client peut enregistrer un message que le broker publiera à sa place s’il disparaît sans déconnexion propre — la méthode standard pour détecter les appareils hors ligne. Voir Last Will and Testament.

Sessions persistantes

Avec une session persistante (cleanSession=false en 3.1.1, cleanStart=false plus un intervalle d’expiration de session en MQTT 5), le broker mémorise les abonnements d’un client et met en file d’attente les messages QoS 1 et 2 pendant qu’il est hors ligne, puis les lui livre à sa reconnexion.

Essayez MQTT en deux minutes

Le moyen le plus rapide de comprendre MQTT est d’observer un message faire l’aller-retour. Connectez-vous à un broker public, abonnez-vous à un topic unique et publiez dessus :

1. Ouvrez le client en ligne et connectez-vous à un broker de la liste des brokers publics.
2. Abonnez-vous à testmqtt/your-name/#.
3. Publiez hello sur testmqtt/your-name/greeting et regardez-le arriver.

Essayez-le dans le client MQTT en ligne

Ou, depuis un terminal où les clients Mosquitto sont installés :

# terminal 1
mosquitto_sub -h test.mosquitto.org -t 'testmqtt/intro/#' -v

# terminal 2
mosquitto_pub -h test.mosquitto.org -t 'testmqtt/intro/greeting' -m 'hello'

Quand utiliser MQTT (et quand s’en passer)

MQTT est un excellent choix quand :

• De nombreux appareils envoient de petits messages fréquents (télémétrie, mesures de capteurs, statuts).
• Les réseaux sont peu fiables ou la bande passante limitée, et vous avez besoin de reconnexions automatiques et d’une mise en file d’attente hors ligne.
• Les données doivent être poussées vers les clients en temps réel plutôt qu’interrogées.
• Vous voulez une diffusion un-vers-plusieurs sans câbler les producteurs aux consommateurs.

Il est moins adapté quand :

• Vous avez besoin de requête/réponse avec une sémantique riche — de simples API HTTP sont plus simples (MQTT 5 ajoute les response topics, mais cela reste de la messagerie).
• Vous avez besoin de stockage long terme ou de rejouer un historique complet d’événements — c’est le rôle d’un log comme Kafka ou d’une base de données alimentée par MQTT.
• Vous transférez de gros fichiers ; MQTT peut les transporter, mais il n’est pas conçu pour cela.

Pour une comparaison point par point, lisez MQTT vs HTTP.

Et ensuite ?

Maintenant que vous savez ce qu’est MQTT, apprenez à choisir vos niveaux de QoS, à concevoir une hiérarchie de topics et à tester un broker MQTT de bout en bout. Tous les guides se trouvent dans le centre d’apprentissage MQTT.

Questions fréquentes