Un broker MQTT est le serveur central qui reçoit chaque message MQTT et le distribue aux clients qui l'ont demandé. Dans ce guide du débutant, vous verrez comment fonctionne le modèle publish/subscribe, ce que fait un broker MQTT en coulisses, comment sont structurés les topics et les wildcards, ce qui distingue MQTT 3.1.1 de MQTT 5.0, et comment envoyer vos premiers messages en ligne de commande et en Python.
Qu'est-ce que MQTT ?
MQTT est un protocole de messagerie léger conçu pour les appareils disposant de peu de bande passante, d'énergie ou de puissance de calcul. Il fonctionne sur TCP (et sur WebSocket pour les navigateurs), possède un en-tête fixe minuscule de seulement deux octets et maintient une connexion unique et durable au lieu d'interroger le serveur en boucle. Il est donc tout indiqué pour les capteurs, passerelles, véhicules, compteurs intelligents et machines industrielles, et tout aussi utile pour les tableaux de bord et services backend qui consomment leurs données.
MQTT est un standard ouvert de l'OASIS ; le site officiel du protocole est mqtt.org.
Le modèle publish/subscribe
Dans un système requête/réponse classique comme HTTP, un client appelle un serveur précis et attend la réponse. MQTT utilise à la place le modèle publish/subscribe :
- Un publisher envoie un message sur un topic, par exemple
home/livingroom/temperature. - Un subscriber indique au broker les topics qui l'intéressent.
- Le broker se place au milieu et transmet chaque message à tous les abonnés dont l'abonnement correspond au topic.
Voici le flux schématisé :
[Temperature sensor] --PUBLISH home/livingroom/temperature 22.5--> [MQTT broker]
[MQTT broker] --deliver--> [Mobile app] (subscribed to home/+/temperature)
[MQTT broker] --deliver--> [Analytics service] (subscribed to home/#)
Trois formes de découplage font la force de ce modèle :
- Dans l'espace : le capteur ne connaît pas l'adresse de l'application, et l'application ne connaît pas celle du capteur. Tous deux ne connaissent que le broker.
- Dans le temps : grâce aux sessions persistantes et aux retained messages, un abonné n'a pas besoin d'être en ligne au moment précis où un message est publié.
- En volume : ajouter un dixième ou un millième abonné ne change absolument rien pour le publisher.
Que fait un broker MQTT ?
Le broker MQTT est bien plus qu'un simple relais. Il assume plusieurs rôles à la fois.
Gérer les connexions
Chaque client ouvre une connexion TCP, TLS ou WebSocket et envoie un paquet CONNECT contenant un client ID, éventuellement un nom d'utilisateur et un mot de passe, un intervalle de keep-alive et des indicateurs de session. Le broker authentifie le client, répond par un CONNACK puis surveille la connexion avec PINGREQ/PINGRESP afin de détecter les clients morts.
Conserver les sessions
Une session contient les abonnements d'un client et les messages mis en file d'attente pendant qu'il était hors ligne. Avec une clean session, l'état est supprimé à la déconnexion. Avec une session persistante, le broker le conserve : un appareil qui perd son réseau mobile reçoit à son retour ce qu'il a manqué. MQTT 5 remplace l'ancien indicateur binaire par un intervalle d'expiration de session exprimé en secondes.
Router par topic
Chaque PUBLISH entrant est comparé à tous les abonnements actifs, y compris les filtres avec wildcards, puis distribué aux clients correspondants. Le routage est le cœur du broker MQTT, et c'est pourquoi la conception des topics compte autant.
Retained messages
Un publisher peut activer l'indicateur retain. Le broker conserve alors le dernier retained message de chaque topic et l'envoie immédiatement à tout nouvel abonné. C'est idéal pour un état comme device/42/status = online ou la dernière configuration : un tableau de bord ouvert plus tard voit tout de suite la valeur courante sans attendre la prochaine mise à jour.
Last Will and Testament
À la connexion, un client peut enregistrer un message de « dernière volonté » (last will), par exemple device/42/status = offline. Si le client disparaît sans DISCONNECT propre (coupure de courant, panne réseau, expiration du keep-alive), le broker publie ce message à sa place. Combiné à un message online retenu, cela vous offre une détection de présence fiable.
Qualité de service
MQTT définit trois garanties de livraison, et le broker les applique sur les deux étapes du trajet (du publisher vers le broker, puis du broker vers l'abonné) :
| QoS | Nom | Garantie | Usage typique |
|---|---|---|---|
| 0 | At most once (au plus une fois) | Envoi sans accusé de réception | Mesures fréquentes de capteurs où un échantillon perdu est acceptable |
| 1 | At least once (au moins une fois) | Accusé par PUBACK, doublons possibles | La plupart des télémesures et événements |
| 2 | Exactly once (exactement une fois) | Échange en quatre étapes, sans doublon | Facturation, commandes qui ne doivent pas être répétées |
La QoS effective pour un abonné est la plus faible entre la QoS de publication et la QoS d'abonnement. Pour aller plus loin, lisez Les niveaux de QoS MQTT expliqués.
Topics et wildcards MQTT
Les topics sont des chaînes UTF-8 découpées en niveaux par une barre oblique. Ils sont créés à la volée : rien n'est à déclarer à l'avance.
factory1/line1/cnc1/temperature
factory1/line1/cnc1/spindle_rpm
factory1/line2/press3/status
home/kitchen/light/state
Une bonne conception de topics va du général au particulier, évite les barres obliques initiales et les espaces, et ne place pas de données sensibles dans les noms de topics. Les topics commençant par $ sont réservés au broker ; ConnectMQ publie par exemple $SYS/broker/connection/{clientId}/state.
Wildcard à un niveau : +
Le signe plus correspond à exactement un niveau.
| Filtre d'abonnement | Correspond à | Ne correspond pas à |
|---|---|---|
factory1/+/cnc1/temperature |
factory1/line1/cnc1/temperature |
factory1/line1/cell2/cnc1/temperature |
home/+/light/state |
home/kitchen/light/state |
home/light/state |
Wildcard multiniveau :
Le dièse correspond à un nombre quelconque de niveaux, zéro compris, et doit être le dernier caractère du filtre.
| Filtre d'abonnement | Correspond à |
|---|---|
factory1/# |
factory1, factory1/line1/cnc1/temperature, factory1/line2/press3/status |
factory1/line1/# |
Tout ce qui se trouve sous factory1/line1 |
# |
Tous les topics hors $ que le client a le droit de voir |
Les wildcards ne s'utilisent que pour s'abonner ; on publie toujours sur un topic concret. Dans les projets industriels, une hiérarchie cohérente comme ISA-95 (entreprise, site, zone, ligne, cellule) devient un Unified Namespace ; consultez MQTT Sparkplug B et Unified Namespace pour ce modèle.
MQTT 3.1.1 ou MQTT 5.0
La plupart des brokers et bibliothèques actuels prennent en charge les deux versions. MQTT 5.0 conserve le même modèle et ajoute des fonctionnalités qui facilitent l'exploitation des grands déploiements.
| Fonctionnalité | MQTT 3.1.1 | MQTT 5.0 |
|---|---|---|
| Retour d'erreur | Codes de retour limités | Reason codes sur la plupart des accusés (par exemple 0x97 Quota exceeded) |
| Durée de vie de la session | Clean session activée/désactivée | Intervalle d'expiration de session |
| Durée de vie des messages | Non disponible | Intervalle d'expiration des messages |
| Répartition de charge | Absente du standard | Shared subscriptions $share/{group}/{filter} |
| Économie de bande passante | Topic complet à chaque fois | Topic aliases |
| Requête/réponse | Conventions ad hoc | Response topic et correlation data |
| Limites du broker | Implicites | Annoncées dans le CONNACK (Maximum QoS, Receive Maximum, etc.) |
| Métadonnées | Payload uniquement | User properties |
Pour un nouveau projet, utilisez MQTT 5.0, sauf si une bibliothèque côté appareil ne gère que la 3.1.1. La spécification complète est publiée par l'OASIS sur docs.oasis-open.org, et notre présentation des fonctionnalités de MQTT 5 en résume les points pratiques.
En pratique : testez un broker MQTT en cinq minutes
Le moyen le plus rapide de comprendre un broker MQTT, c'est d'en utiliser un. broker.connectmq.com est un serveur MQTT public gratuit : sa zone publique sert aux tests anonymes.
| Protocole | Port | URL |
|---|---|---|
| MQTT (TCP) | 1883 | mqtt://broker.connectmq.com:1883 |
| MQTT sur TLS | 8883 | mqtts://broker.connectmq.com:8883 |
| WebSocket | 8083 | ws://broker.connectmq.com:8083/mqtt |
| WebSocket sécurisé | 8084 | wss://broker.connectmq.com:8084/mqtt |
Règles de la zone publique : connectez-vous sans nom d'utilisateur ni mot de passe, utilisez un client ID unique et non vide (un client ID vide est refusé), et gardez à l'esprit que tout ce que vous publiez est lisible par n'importe qui. Choisissez un préfixe aléatoire comme connectmq/demo/<your-random-id>/ et n'envoyez jamais de données personnelles ou sensibles. Les limites sont de 64 Ko par message, 10 messages par seconde et 10 abonnements par client, et 8 niveaux de topic au maximum.
S'abonner et publier avec mosquitto
Installez les clients en ligne de commande Eclipse Mosquitto, ouvrez un terminal et abonnez-vous avec un wildcard. Remplacez k9x2 par votre propre chaîne aléatoire :
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-k9x2 \
-t "connectmq/demo/k9x2/#" -v
Dans un second terminal, publiez une mesure :
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-k9x2 \
-t "connectmq/demo/k9x2/room1/temp" -m '{"temp":22.5}' -q 1
Le premier terminal affiche :
connectmq/demo/k9x2/room1/temp {"temp":22.5}
Essayez maintenant un retained message. Publiez un état avec -r, puis lancez un nouvel abonné qui n'utilise que le wildcard à un niveau :
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-k9x2 \
-t "connectmq/demo/k9x2/room1/status" -m "online" -r
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub2-k9x2 \
-t "connectmq/demo/k9x2/+/status" -v -C 1
Le nouvel abonné reçoit online immédiatement, alors qu'il s'est connecté après l'envoi du message. C'est le broker qui a stocké puis rejoué la valeur retenue. Pour l'effacer, publiez un retained message vide avec -r -n.
Pour chiffrer le trafic, passez au port 8883 et indiquez au client les certificats CA de votre système (par exemple --capath /etc/ssl/certs sous Linux), puis ajoutez -V mqttv5 pour parler MQTT 5.0.
Exemple Python avec last will
Installez paho-mqtt 2.x avec pip install paho-mqtt et exécutez :
import json
import uuid
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}"
CLIENT_ID = f"py-{uuid.uuid4().hex[:8]}"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(f"{PREFIX}/#", qos=1)
client.publish(f"{PREFIX}/sensor1/status", "online", qos=1, retain=True)
client.publish(f"{PREFIX}/sensor1/temp", json.dumps({"temp": 21.8}), qos=1)
def on_message(client, userdata, msg):
print(f"{msg.topic} -> {msg.payload.decode()}")
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=CLIENT_ID,
protocol=mqtt.MQTTv5,
)
client.will_set(f"{PREFIX}/sensor1/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=30)
client.loop_forever()
Le script enregistre un last will, s'annonce online avec un retained message et publie une mesure de température qu'il reçoit en retour via son propre abonnement avec wildcard. Si vous tuez brutalement le processus, le broker publie offline sur le topic d'état dès l'expiration du keep-alive.
Vous préférez le navigateur ? Le même broker accepte les connexions WebSocket sur les ports 8083 et 8084 ; consultez MQTT sur WebSocket.
Du serveur MQTT public gratuit à la production
Le serveur MQTT public gratuit est parfait pour apprendre et prototyper, mais la production exige des identifiants privés, le TLS et une isolation vis-à-vis des autres utilisateurs. ConnectMQ exploite le broker pour vous, en tant que broker MQTT managé : créez-en un dans le portail, recevez un nom d'utilisateur, un mot de passe et un client ID, et connectez-vous en mqtts:// sur le port 8883. Vos topics restent isolés des autres tenants et de la zone publique, et le portail vous offre un explorateur de topics en temps réel, des tableaux de bord et des règles d'alerte. Lisez Qu'est-ce qu'un broker MQTT managé ? pour comparer les options d'hébergement.
Démarrer avec ConnectMQ
Inscrivez-vous sur app.connectmq.com pour créer votre propre broker MQTT avec l'offre Serverless gratuite, sans carte bancaire. Vous enverrez des messages en TLS en quelques minutes, avec les mêmes commandes que celles que vous venez d'essayer.
Questions fréquentes
Qu'est-ce qu'un broker MQTT, en termes simples ?
Un broker MQTT est un serveur qui reçoit les messages des clients qui publient et les transmet à chaque client abonné à un topic correspondant. Les appareils ne communiquent jamais directement entre eux ; ils ne parlent qu'au broker.
Quelle est la différence entre un broker MQTT et un client MQTT ?
Un client est tout appareil ou toute application qui publie ou s'abonne, comme un capteur ou un tableau de bord. Le broker est le serveur central qui authentifie les clients, conserve les sessions et achemine les messages entre eux.
Quel port utilise un broker MQTT ?
Les ports standard sont 1883 pour MQTT en clair et 8883 pour MQTT sur TLS. Les connexions WebSocket utilisent généralement des ports distincts ; sur broker.connectmq.com, ce sont les ports 8083 et 8084 avec le chemin /mqtt.
Existe-t-il un broker MQTT gratuit pour faire des tests ?
Oui. broker.connectmq.com est un serveur MQTT public gratuit, avec une zone anonyme réservée aux tests, et l'offre Serverless gratuite de ConnectMQ vous fournit un broker privé avec identifiants et TLS.
Faut-il utiliser MQTT 3.1.1 ou MQTT 5.0 ?
Utilisez MQTT 5.0 pour les nouveaux projets, car il apporte les reason codes, l'expiration des sessions et des messages, les shared subscriptions et les topic aliases. Ne revenez à la 3.1.1 que si une bibliothèque côté appareil ne prend pas en charge la version 5.
