Qu'est-ce que MQTT ? Le protocole IoT expliqué de A à Z
MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger basé sur le modèle Publish/Subscribe. Découvrez en détail le fonctionnement des clients, des topics, des payloads et des garanties de livraison.
MQTT en une phrase
MQTT est un protocole de communication réseau ultra-léger et asynchrone, basé sur le modèle Publish/Subscribe (Publication / Abonnement), conçu pour échanger des messages en temps réel entre des appareils et des applications avec un minimum d'énergie et de bande passante.Pourquoi MQTT est devenu le standard mondial de l'IoT
Créé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper pour surveiller des pipelines pétroliers par satellite, MQTT est aujourd'hui une norme internationale (OASIS & ISO/IEC 20922). Contrairement au protocole HTTP qui nécessite une requête pour chaque réponse, MQTT maintient une connexion TCP légère et pousse instantanément les données dès qu'elles sont produites.
En-tête de 2 octets
Là où une requête HTTP envoie 500 à 1000 octets d'en-tête (headers), MQTT ne consomme que 2 octets pour acheminer un paquet.
Découplage Asynchrone
L'émetteur n'a pas besoin de savoir qui reçoit le message, ni si le récepteur est en ligne au moment exact de la transmission.
Connexion permanente
Une connexion TCP persistante avec Keep-Alive permet au broker de pousser (Push) des données en direct avec une latence quasi nulle.
Architecture & Flux de données en direct
Découvrez le découplage MQTT : observez les liaisons physiques TCP entre les appareils à gauche et le Broker à droite. Cliquez sur un émetteur pour voir le paquet circuler le long du câble vers le Broker, puis être redistribué aux abonnés ciblés.
Broker MQTT
C'est quoi un Topic MQTT ?
Un topic (ou sujet) est une chaîne de caractères textuelle, sensible à la casse, organisée de manière hiérarchique avec des barres obliques (/). C'est l'adresse de routage du message. Contrairement à une boîte mail ou une file d'attente classique, un topic n'a pas besoin d'être configuré à l'avance sur le broker : il existe dès qu'un message y est publié.
Anatomie d'une hiérarchie de Topic :
maison)salon)temperature)Testeur interactif de Jokers MQTT (+ et #)
Simulez la publication d'un message et vérifiez quels filtres d'abonnement le reçoivent.
maison/+/temperature pour écouter tous les capteurs d'un coup).maison/# pour recevoir l'intégralité des flux de la maison).2. Distribution aux abonnés (Subscribers) :
3 / 4 clients reçoivent le fluxmaison/salon/temperatureCapte uniquement la température du salon.
maison/+/temperatureCapte la température de toutes les pièces.
maison/#Capte tous les capteurs et sous-dossiers de la maison.
usine/#Ne capte que les équipements du domaine "usine".
3. Tester un filtre d'abonnement sur mesure :
ReçuExplication : Correspondance validée grâce au joker mono-niveau "+".
+ et #), vous pouvez configurer une seule Règle de Stockage MQpanel (ex : usine/+/temperature) pour historiser automatiquement les données de vos capteurs.C'est quoi un Payload MQTT ?
Le payload (charge utile) est le contenu réel de la donnée transportée par le message. MQTT est agnostique au format de données : pour le broker, le payload n'est qu'une suite d'octets bruts (bytes). Le broker ne modifie jamais le payload, il le transmet tel quel aux abonnés.
maison/salon/temperatureTaille : 42 octets{
"valeur": 22.4,
"unite": "°C",
"batterie": 95
}Comment le client traite ce Payload :
Le format le plus populaire en IoT. Permet d'associer des clés/valeurs explicites et d'envoyer plusieurs mesures dans une seule trame.
client.publish("maison/salon/temperature", JSON.stringify({ valeur: 22.4, unite: "°C", batterie: 95 }))Récapitulatif fondamental : Topic vs Payload
| Caractéristique | Topic MQTT | Payload MQTT |
|---|---|---|
| Rôle | Adresse de routage du message | Contenu des données transportées |
| Analysé par le Broker ? | Oui (pour router aux abonnés) | Non (opaque, transmis tel quel) |
| Format imposé | Texte UTF-8 avec slashes (/) | Aucun (binaire brut, JSON, texte...) |
Qualité de Service (QoS) : quelle garantie de livraison ?
MQTT propose 3 niveaux de Qualité de Service (QoS) définis à chaque message entre le client et le broker :
QoS 1 : Au moins une fois (At least once)
1 acquittement (PUBACK)Le broker valide la réception par un accusé PUBACK. En l'absence de réponse (timeout), l'émetteur renvoie le message.
Cas d'usage recommandé : Recommandé par défaut : alertes critiques, commandes domotiques, détection d'intrusion.
Mécanismes avancés : Retain, Testament (LWT) & Keep-Alive
Message Retenu (Retain Flag)
Quand un message est publié avec le flag Retain = true, le broker le conserve en mémoire comme dernière valeur connue de ce topic. Tout nouveau client qui s'abonne à ce topic reçoit immédiatement cette valeur sans devoir attendre la prochaine publication.
Le Testament (Last Will and Testament - LWT)
À la connexion, un client confie au broker un message « testament » avec un topic et un payload. Si la connexion TCP du client se coupe brutalement (panne électrique, coupure internet), le broker publie automatiquement ce message aux autres abonnés.
Keep-Alive & Ping
Un intervalle de temps (ex: 60s) convenu entre le client et le broker. Si aucun message n'est échangé pendant ce délai, le client envoie un paquet PINGREQ (2 octets) et attend un PINGRESP pour confirmer que la liaison est toujours vivante.
MQTT face à HTTP et WebSockets
Pourquoi l'Internet des Objets et le temps réel ont fait de MQTT la référence :
| Critère | MQTT | HTTP (REST) |
|---|---|---|
| Modèle d'échange | Publish / Subscribe (Asynchrone) | Requête / Réponse (Synchrone) |
| Taille minimale d'en-tête | 2 octets | Plusieurs centaines d'octets (headers) |
| Consommation réseau / batterie | Ultra faible (optimisé microcontrôleurs) | Élevée (overhead à chaque requête) |
| Communication Push serveur → client | Natif et temps réel | Non (nécessite Polling ou SSE) |
| Détection de perte réseau | Natif (Last Will & Testament) | Aucune (attente de timeout requête) |
| Support des wildcards | Oui (+ et #) | Non |
Sécurité dans l'écosystème MQTT
Dans un environnement de production, les échanges MQTT sont systématiquement sécurisés par : le chiffrement TLS/SSL (port standard 8883) pour protéger les données en transit, l'authentification par identifiant/mot de passe ou certificat client X.509, et le contrôle d'accès (ACL) restreignant les topics autorisés pour chaque client.
Comment MQpanel propulse votre infrastructure MQTT
MQpanel combine la puissance d'un Broker MQTT managé haute performance avec une plateforme complète de visualisation, stockage et automatisation :
Broker Cloud Sécurisé & Managé
Connexions MQTTS (port 8883) et WebSockets (port 8084) prêtes à l'emploi, authentification granulaire par clés d'API et contrôle d'accès (ACL).
Tableaux de bord temps réel sans code
Reliez vos topics à des jauges, courbes interactives, interrupteurs et cartes géographiques en quelques clics.
Stockage & Historisation automatique
Définissez des règles de stockage pour archiver automatiquement vos payloads de capteurs sans gérer de base de données.
Agents IA & Automatisation
Connectez des agents d'intelligence artificielle qui analysent vos flux MQTT en direct et déclenchent des actions correctives.
Prêt à démarrer avec MQpanel ?
Connectez votre premier appareil, publiez vos données de télémétrie et créez votre premier tableau de bord en moins de 5 minutes grâce à MQpanel !