MQTT : le protocole que tout le monde devrait connaître

MQTT (Message Queuing Telemetry Transport) est devenu incontournable dans l’univers de l’IoT et des architectures événementielles. Pourtant, ce protocole créé par IBM dans les années 1990 reste méconnu de nombreux développeurs. Changeons ça et regardons de plus près…

Pourquoi MQTT ?

Contrairement à HTTP qui fonctionne en requête/réponse, MQTT implémente un modèle publish/subscribe ultra-léger. Son principal atout ? Une empreinte réseau minimale, parfaite pour les objets connectés aux ressources limitées ou les connexions instables.

Là où HTTP envoie des headers volumineux à chaque requête, MQTT peut transmettre un message avec seulement 2 octets de surcharge. Sur une connexion 3G instable ou un capteur alimenté par batterie, la différence est considérable.

Architecture : topics et QoS

MQTT repose sur trois acteurs : les publishers qui publient des messages, les subscribers qui s’abonnent à des topics, et le broker qui fait la jonction en tant que serveur. Le broker (Mosquitto, HiveMQ, AWS IoT Core) gère le routage des messages selon une arborescence de topics.

Un topic ressemble à un chemin de fichier : maison/salon/temperature ou usine/ligne3/capteur12/vibration. On peut s’abonner avec des wildcards : maison/+/temperature (+ pour un niveau) ou maison/# (# pour tous les sous-niveaux).

MQTT propose trois niveaux de qualité de service (QoS) :

• QoS 0 : fire and forget, aucune garantie de livraison
• QoS 1 : au moins une fois, avec accusé de réception
• QoS 2 : exactement une fois, avec handshake en quatre étapes

Exemple pratique : monitoring de température

Voici un publisher Python avec Paho MQTT :

import paho.mqtt.client as mqtt
import json
import time
import random

def on_connect(client, userdata, flags, rc):
    if rc == 0:
        print("Connecté au broker MQTT")
    else:
        print(f"Échec de connexion, code: {rc}")

# Configuration
client = mqtt.Client(client_id="capteur_temp_salon")
client.on_connect = on_connect
client.username_pw_set("username", "password")

# Connexion au broker
client.connect("mqtt.exemple.com", 1883, 60)
client.loop_start()

# Publication en boucle
while True:
    temperature = 20 + random.uniform(-2, 5)
    payload = json.dumps({
        "temp": round(temperature, 2),
        "timestamp": int(time.time()),
        "unit": "celsius"
    })
    
    result = client.publish(
        "maison/salon/temperature",
        payload,
        qos=1,
        retain=True  # Garde le dernier message pour les nouveaux subscribers
    )
    
    print(f"Message publié: {payload}, status: {result.rc}")
    time.sleep(60)

Et le subscriber correspondant :

import paho.mqtt.client as mqtt
import json

def on_connect(client, userdata, flags, rc):
    print(f"Connecté avec le code: {rc}")
    # S'abonner à la connexion garantit la réabonnement après déconnexion
    client.subscribe("maison/+/temperature", qos=1)

def on_message(client, userdata, msg):
    data = json.loads(msg.payload.decode())
    room = msg.topic.split('/')[1]
    print(f"🌡️  {room}: {data['temp']}°C à {data['timestamp']}")
    
    # Logique métier
    if data['temp'] > 25:
        print(f"⚠️  Alerte: température élevée dans {room}")

client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.username_pw_set("username", "password")

client.connect("mqtt.exemple.com", 1883, 60)
client.loop_forever()

Fonctionnalités avancées

Last Will and Testament (LWT) : chaque client peut définir un message qui sera automatiquement publié par le broker en cas de déconnexion inattendue. Pratique pour détecter des capteurs hors ligne.

client.will_set("maison/salon/status", "offline", qos=1, retain=True)

Retained messages : le broker conserve le dernier message publié avec le flag retain=True. Les nouveaux subscribers le reçoivent immédiatement, sans attendre une nouvelle publication.

Sessions persistantes : avec clean_session=False, le broker conserve les abonnements et messages QoS>0 pendant une déconnexion.

Cas d’usage concrets

J’ai vu MQTT briller dans des contextes variés : une ferme urbaine avec 200 capteurs d’humidité du sol communiquant via LoRaWAN puis MQTT, un système de suivi de flotte où chaque véhicule publie sa position GPS toutes les 30 secondes, ou encore une usine avec des milliers de machines publiant leurs métriques de production en temps réel. Plus loin ? Une ville et des capteurs sur les conteneurs à ordures présents dans les rues : s’ils sont pleins, une alerte via MQTT est relativement rapide et simple à envoyer, déclenchant l’intervention d’un camion poubelle.

Un cas particulièrement élégant : un système domotique où la simple publication sur maison/salon/lumiere/set avec payload {"state": "ON", "brightness": 80} contrôle l’éclairage, tandis que la lampe confirme son état sur maison/salon/lumiere/state.

MQTT et ses alternatives

Comparé à WebSockets, MQTT gère nativement la reconnexion, les QoS et le routage par topics. Face à AMQP, il est beaucoup plus simple et léger. CoAP est encore plus compact mais moins mature en termes d’écosystème.

La version MQTT 5.0 ajoute des fonctionnalités intéressantes : propriétés utilisateur dans les messages, raison de déconnexion, expiration des messages, et request/response pattern pour simplifier les interactions bidirectionnelles.

Pour démarrer

Sur Linux, installez Mosquitto localement (apt install mosquitto mosquitto-clients sur Ubuntu), lancez un subscriber dans un terminal avec mosquitto_sub -t "test/#" -v, et publiez depuis un autre avec mosquitto_pub -t "test/hello" -m "Hello MQTT". Vous verrez immédiatement l’intérêt !

MQTT n’est pas la solution universelle, mais pour tout ce qui touche à l’événementiel, l’IoT ou les architectures temps réel, il mérite clairement sa place dans votre boîte à outils et dans vos développements.