Qu'est-ce que MQTT : le protocole, ses versions et où on l'emploie

# En bref

MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger, fondé sur la publication et l'abonnement, conçu pour des appareils à liaison médiocre, à faible mémoire et dont la batterie doit durer.

Il a été créé en 1999 par Andy Stanford-Clark d'IBM et Arlen Nipper d'Arcom, pour acheminer par satellite la télémétrie d'oléoducs. Les conditions étaient impitoyables : la bande passante coûtait cher et manquait, la liaison tombait sans cesse, et les appareils étaient chétifs. Ces contraintes ont façonné tout le protocole — un en-tête minuscule, une unique connexion de longue durée, et la capacité de survivre à une coupure sans perdre de messages.

MQTT est aujourd'hui une norme OASIS, et la version 3.1.1 a de plus été adoptée comme norme internationale ISO/IEC 20922. Il a depuis longtemps dépassé l'industrie pétrolière : maisons connectées, compteurs, machines-outils, voitures et dispositifs médicaux en dépendent.

Le surcoût minimal par message est de deux octets. Une seule requête HTTP, à titre de comparaison, dépense des centaines d'octets en en-têtes avant même la moindre donnée. Quand un appareil relève une température chaque seconde par modem cellulaire en pleine campagne, cet écart décide de la conception.

# Comment cela marche : publication, abonnement et broker

En HTTP, le client demande et le serveur répond. En MQTT, personne ne demande rien à personne : un appareil publie un message dans un topic, et tous ceux qui y sont abonnés le reçoivent. L'émetteur ignore qui lit, et même si quelqu'un lit ; le destinataire ignore qui a envoyé. La seule chose qui les relie est le nom du topic.

Au milieu se tient toujours un broker — un serveur qui garde les connexions, tient l'arbre des abonnements et distribue les messages. Sans lui, le modèle ne fonctionne pas : c'est le broker qui transforme « envoyé dans le vide » en « livré à tous ceux que cela concerne ».

Ce que fait le broker

• Il accepte et maintient les connexions — des milliers à la fois, des années sans interruption.
• Il vérifie qui se connecte : identifiant et mot de passe, certificat ou jeton.
• Il décide de ce que chaque client peut faire : les droits de publier et de s'abonner se donnent par topic.
• Il confronte chaque message publié à l'arbre des abonnements et en distribue les copies.
• Il conserve l'état : dernières valeurs connues (retain), files pour les clients absents, accusés inachevés.
• Il suit qui est vivant et publie le testament de ceux qui disparaissent.

Découpler l'émetteur du destinataire n'est pas un détail technique mais tout l'intérêt du modèle. Vous pouvez remplacer un capteur, ajouter un second consommateur ou greffer une analyse sur le côté sans rien réécrire : chacun parle à un topic, non aux autres.

# Topics et jokers

Un topic est une chaîne de niveaux séparés par des barres obliques. Rien n'a besoin d'être déclaré à l'avance : publier dans un nouveau topic le crée sur-le-champ.

bureau/etage2/salle14/temperature
bureau/etage2/salle14/humidite
bureau/etage2/salle15/temperature

Un abonnement peut capter des branches entières grâce à deux jokers :

Le joker # n'est valable qu'en dernier niveau : bureau/#/temperature n'est pas un filtre légal. Les topics distinguent majuscules et minuscules, et bureau/etage2 et bureau/etage2/ sont deux topics différents.

# Qualité de service : QoS 0, 1 et 2

MQTT vous laisse choisir l'effort consacré à la livraison de chaque message. Le niveau se règle séparément à la publication et à l'abonnement ; le niveau effectif est le plus faible des deux.

Le coût monte avec la garantie : QoS 2, c'est quatre paquets au lieu d'un, plus de l'état des deux côtés. Résistez à l'envie de « mettre 2 partout au cas où » : dix mille capteurs publiant chaque seconde en QoS 2 chargent un broker d'un ordre de grandeur de plus, sans le moindre bénéfice.

# Retain, Last Will, sessions et keep-alive

Retain — la dernière valeur connue

Un message ordinaire n'atteint que les abonnés du moment. Un message portant le drapeau retain est en outre mémorisé par le broker et remis à chaque nouvel abonné à l'instant même de son abonnement. C'est la réponse standard à l'éternel problème du tableau de bord qui s'ouvre vide et le reste jusqu'à ce qu'un capteur daigne envoyer sa mesure suivante.

Un topic ne garde qu'un seul message retenu — le dernier. Pour l'effacer, publiez une charge utile vide dans le même topic avec le drapeau retain.

Last Will — un message pour la coupure

En se connectant, un client peut confier au broker un testament : un topic, une charge utile et ses options. Si la connexion meurt sans politesse — sans paquet DISCONNECT —, le broker publie ce message à sa place. Le motif classique est un topic retenu device/42/status qui reçoit online à la connexion et porte offline comme testament. Le système sait toujours qui est présent, sans la moindre interrogation.

Sessions : propres et persistantes

Une session propre dure exactement le temps de la connexion : déconnexion et les abonnements sont oubliés. Une session persistante survit à la coupure : le broker retient les abonnements et met en file les messages QoS 1 et 2 pendant l'absence du client, puis lui livre l'arriéré à son retour. Pour un appareil qui se réveille une fois par heure, c'est la seule façon de ne rien manquer.

Keep-alive — s'apercevoir que la liaison est morte

Une connexion TCP rompue peut sembler parfaitement vivante aux deux bouts pendant longtemps. Le client annonce donc un intervalle de keep-alive et, faute d'autre chose à dire, envoie un ping. N'entendant rien pendant une fois et demie l'intervalle, le broker déclare le client disparu, ferme la connexion et publie son testament.

# Les versions : 3.1, 3.1.1 et 5.0

Trois versions se rencontrent en pratique, et les différences ne sont pas cosmétiques.

À part se tient MQTT-SN, un protocole cousin pour les réseaux sans TCP : ZigBee, liaisons radio, UDP. Ce n'est pas « une version de MQTT » mais une spécification à part ; de tels réseaux reçoivent une passerelle qui traduit le trafic en MQTT ordinaire.

Ce que MQTT 5.0 apporte réellement

La version 5 est née d'agacements accumulés en pratique. Les points les plus lourds de conséquences :

• Codes de raison. En 3.1.1, un refus ressemblait à un socket fermé en silence, et il fallait deviner. En 5.0, le serveur dit ce qu'il en est : mot de passe erroné, pas de droit sur ce topic, paquet trop gros.
• Propriétés de paquet. Un message peut porter des métadonnées : Content Type, Correlation Data, des paires clé-valeur libres. Auparavant, tout cela s'entassait dans la charge utile ou dans le nom du topic.
• Requête et réponse. Les champs Response Topic et Correlation Data font du RPC ordinaire un motif de première classe plutôt qu'une convention bricolée.
• Abonnements partagés via $share/groupe/filtre : plusieurs instances d'un consommateur se répartissent le flux. C'est de la répartition de charge et de la reprise sur incident au niveau du protocole.
• Durées de vie des sessions et des messages. Session Expiry et Message Expiry permettent de dire « garde-le un jour, puis oublie » au lieu du choix binaire propre ou non.
• Contrôle de flux. Receive Maximum plafonne le nombre de messages non acquittés en vol, et Maximum Packet Size protège un petit appareil d'un paquet qu'il ne peut digérer.
• Alias de topics. Un nom long est envoyé une fois puis remplacé par un nombre de deux octets — une économie réelle sur les hiérarchies profondes.
• Identifiants d'abonnement, No Local, Retain As Published, Retain Handling. De petites choses qui suppriment de vieux pièges : entendre l'écho de ses propres messages, une avalanche de messages retenus à chaque reconnexion, ignorer par quel abonnement un message est arrivé.
• Testament différé. Will Delay Interval empêche qu'une coupure passagère déclenche une alarme : le testament n'est publié que si le client ne revient pas à temps.

Conclusion pratique : commencez les nouveaux projets en 5.0. Les abonnements partagés et des codes d'erreur intelligibles épargnent des semaines de débogage, et la compatibilité avec les appareils anciens n'est pas perdue.

# MQTT face à HTTP et aux alternatives

« Pourquoi MQTT alors que REST existe ? » est une question légitime. La différence n'est pas une affaire de mode mais de sens et de coût d'une conversation.

L'interrogation périodique le démontre. Pour apprendre un événement en moins d'une seconde par HTTP, mille appareils doivent demander mille fois par seconde, et presque chaque réponse sera « rien de neuf ». En MQTT, l'événement arrive de lui-même au moment où il se produit, et ne coûte aucun trafic entre-temps.

Et CoAP, AMQP et WebSocket

• CoAP est du REST sur UDP pour de très petits nœuds. Plus léger que MQTT, mais il n'offre ni files ni livraison fiable sans effort.
• AMQP est plus lourd et plus riche : routage élaboré, transactions, files de qualité entreprise. Sensé entre serveurs, excessif pour un capteur.
• WebSocket est un transport, pas une alternative : MQTT lui-même passe par WebSocket pour fonctionner dans un navigateur.
• Sparkplug B n'est pas un rival mais une couche au-dessus de MQTT : il dicte comment nommer les topics et encoder les charges utiles dans l'industrie, pour que des logiciels SCADA de fournisseurs différents comprennent les mêmes données.

# Transport, ports et charges utiles

MQTT fonctionne sur TCP et ne demande qu'une livraison fiable et ordonnée. Les ports d'usage :

Pour le protocole, une charge utile n'est qu'une suite d'octets. MQTT ne sait rien du contenu et n'impose rien : JSON, CBOR, protobuf, un simple nombre ou une image conviennent tous. La limite formelle est de 256 Mo, mais en pratique tout ce qui dépasse quelques centaines de kilo-octets relève de HTTP, seul un lien voyageant par MQTT.

En pratique, JSON domine : un humain le lit, tous les langages l'analysent, et il reste assez compact. Sur une liaison étroite, un format binaire gagne sa place — et c'est exactement là que la propriété Content Type de MQTT 5.0 aide, en disant honnêtement ce qu'il y a dedans.

# Sécurité

MQTT ne chiffre rien par lui-même : sur le port 1883, identifiant et mot de passe circulent en clair. La sécurité vient de trois couches indépendantes, et aucune n'est facultative.

Chiffrer le canal

TLS sur le port 8883. Pour les appareils trop faibles pour TLS, la seule option décente est de les garder sur un réseau isolé et de ne rien laisser sortir sinon par une passerelle.

Authentification

Le classique est un identifiant et un mot de passe dans le paquet CONNECT. Plus strict : les certificats clients, l'appareil présentant le sien et le broker vérifiant la signature. Plus souple : JWT, l'appareil apportant un jeton signé et limité dans le temps, dont la révocation ne demande aucun changement sur le broker. Les bons brokers savent aussi lire les comptes dans une base externe, un fichier CSV ou un service HTTP, pour que la liste des appareils n'existe pas en double.

Droits sur les topics

L'authentification répond à « qui êtes-vous » ; l'autorisation à « qu'avez-vous le droit de faire ». Les listes de contrôle d'accès disent quels topics un client peut lire et lesquels il peut écrire. Le bon réglage est tout interdire sauf ce qui est explicitement autorisé.

S'y ajoutent des limites de cadence de publication (pour qu'un seul appareil déréglé n'ensevelisse pas le broker), une taille de paquet maximale et l'hygiène réseau ordinaire : le tableau de bord du broker n'a rien à faire face à l'Internet ouvert.

# Où MQTT est réellement employé

Maison connectée et automatisation du bâtiment

Le plus grand domaine en volume. Home Assistant, Zigbee2MQTT, ESPHome et openHAB parlent tous à travers un broker MQTT, qui sert aussi de ciment entre du matériel de fabricants différents : une prise, un détecteur de fuite et un régulateur de chauffage de trois marques coopèrent parfaitement, car chacun écrit simplement dans son propre topic.

Industrie et SCADA

Mesures machine, état des lignes, compteurs d'heures. Le montage classique est une passerelle qui lit du Modbus ou de l'OPC UA sur les équipements et le republie en MQTT, après quoi SCADA, un historien et un système de maintenance prédictive le consomment tous à la fois sans se gêner. C'est là que Sparkplug B et les abonnements partagés de MQTT 5.0 gagnent leur place.

Comptage et services publics

Compteurs d'eau, de gaz, d'électricité et de chaleur : des appareils sur batterie qui se réveillent une fois par heure, transmettent un relevé et se rendorment. Les sessions persistantes et retain font ici le gros du travail — le serveur voit toujours la dernière valeur même si un compteur ne se manifestera que le soir.

Transport et télématique

Coordonnées, consommation, état du groupe frigorifique, comportement du conducteur. La liaison est un réseau cellulaire qui disparaît dans les tunnels et hors des villes. La mise en file et la retransmission après reconnexion transforment une connexion en lambeaux en un flux de données continu.

Énergie, agriculture, santé

Centrales solaires et postes électriques, systèmes d'irrigation et stations météo, moniteurs de patients et réfrigérateurs à vaccins. Leur point commun : beaucoup de points terminaux, une liaison faible, des événements à ne pas perdre et le besoin d'apprendre une panne immédiatement.

Villes intelligentes et logistique

Éclairage public, stationnement, conteneurs qui signalent leur remplissage, suivi de fret et température de la chaîne du froid. Des dizaines de milliers d'appareils envoyant des messages courts et espacés — précisément le profil de charge pour lequel MQTT a été conçu.

# Concevoir ses topics : les décisions à prendre tôt

Votre schéma de topics est l'API de votre système. Le changer plus tard fait mal, car micrologiciel et serveur doivent être mis à jour de concert. Quelques règles qui font gagner du temps.

• Du général au particulier. usine/hall3/ligne2/machine7/temperature permet de s'abonner à n'importe quel niveau. L'ordre inverse rend les jokers inutiles.
• Donnez à l'identifiant de l'appareil son propre niveau. C'est ce qui permet à une seule règle ACL de confiner un appareil à sa branche.
• Pas de barre oblique initiale. /bureau/temp crée un premier niveau vide — légal, mais source durable de confusion.
• Lettres latines, chiffres, tiret et souligné seulement. Les espaces et les caractères +, # et $ dans les noms provoquent des pannes auxquelles personne ne s'attend.
• N'encodez jamais de données changeantes dans le topic. sensor/42/temp/21.5 est une erreur : la valeur va dans la charge utile, sinon le broker se retrouve avec un arbre de topics sans bornes et retain devient inutile.
• Séparez l'état des commandes. Par exemple device/42/state pour ce que l'appareil rapporte et device/42/cmd pour ce qu'on lui ordonne. Sinon l'écho de vos propres commandes finira par boucler la logique.
• Retain pour les états, pas pour la télémétrie. Retain convient au « dernier état connu » et n'a aucun sens pour un flux de mesures.

# Choisir un broker

Les brokers sont nombreux, et le choix se ramène en général à une poignée de questions.

• MQTT 5.0 est-il pris en charge intégralement ? Une prise en charge partielle est fréquente, et on l'apprend d'ordinaire au pire moment possible.
• Voit-on ce qui se passe ? Pouvoir observer qui est connecté, quels topics vivent et ce qui passe à l'instant épargne des heures de débogage. Un broker sans tableau de bord transforme chaque problème en fouille de journaux.
• Comment les appareils sont-ils créés ? À plusieurs milliers, le faire à la main est exclu — il faut une API ou des comptes dans une base externe.
• Survit-il à un redémarrage ? Messages retenus, sessions persistantes et files doivent atteindre le disque, sinon un redémarrage planifié signifie perdre des données.
• Quelles limites propose-t-il ? Un appareil déréglé ne doit pas faire tomber le système : les limites de cadence et de volume comptent.
• Combien coûte-t-il et où tourne-t-il ? Un service en nuage est commode jusqu'à ce qu'il facture au message ; un serveur à soi demande de l'administration mais garde les données chez vous.

Pour une installation petite ou moyenne — d'une maison connectée à une usine de quelques milliers de points —, un seul broker sur une machine modeste suffit normalement. Le clustering est bien moins souvent nécessaire qu'il n'y paraît à la conception ; il vaut plus souvent la peine de relier deux brokers indépendants par un pont qui ne transfère que les topics importants.

# Démarrer en cinq minutes

La façon la plus rapide de comprendre tout cela est de lancer un broker et de regarder les messages soi-même. Sur Debian ou Ubuntu, ce sont trois commandes :

sudo wget -qO /usr/share/keyrings/elx-repo.gpg https://repo.um-d.ru/elx-repo.gpg
echo "deb [signed-by=/usr/share/keyrings/elx-repo.gpg] https://repo.um-d.ru stable main" | sudo tee /etc/apt/sources.list.d/elx-repo.list
sudo apt-get update && sudo apt-get install elxmqttbroker

Le tableau de bord s'ouvre sur http://votre-serveur:8567. Créez un utilisateur, puis essayez l'échange avec n'importe quel client — les outils en console de mosquitto, par exemple :

# dans une fenêtre — s'abonner à tout ce que l'appareil envoie
mosquitto_sub -h localhost -u sensor-42 -P motdepasse -t 'sensor-42/#' -v

# dans une autre — publier une mesure
mosquitto_pub -h localhost -u sensor-42 -P motdepasse -t 'sensor-42/temp' -m '21.5'

# la même chose, mais mémorisée pour les futurs abonnés
mosquitto_pub -h localhost -u sensor-42 -P motdepasse -t 'sensor-42/temp' -m '21.5' -r

Ensuite, jouez avec le drapeau retain, déconnectez un abonné et regardez ce qui s'accumule dans une session persistante, posez un testament et débranchez le câble. Une demi-heure de cela apprend plus que n'importe quel article, celui-ci compris.

# Réponses rapides