MQTTT
FR
English简体中文Español日本語DeutschFrançaisPortuguês
Guides

Versions du protocole MQTT

Guide détaillé des versions MQTT : MQTT 3.1, MQTT 3.1.1, MQTT 5.0, MQTT-SN, compatibilité, fonctions et migration.

Versions du protocole

Versions du protocole MQTT

Les versions MQTT ne sont pas de simples libellés historiques. Elles déterminent le paquet CONNECT, la compatibilité broker, les diagnostics d'erreur, la durée de session, les métadonnées de message et l'observabilité. En pratique, il faut distinguer MQTT 3.1, MQTT 3.1.1, MQTT 5.0 et le protocole associé MQTT-SN. En mai 2026, le répertoire officiel OASIS liste MQTT 3.1.1 et MQTT 5.0 comme standards principaux, pas MQTT 5.1.

Réponse rapide

  • Choisissez MQTT 5.0 pour les nouveaux systèmes qui ont besoin de reason codes, properties, expiration, request-response, flow control ou diagnostics.
  • Utilisez MQTT 3.1.1 comme base de compatibilité pour anciens appareils, modules économiques, SDK existants et environnements industriels.
  • Considérez MQTT 3.1 comme une cible de compatibilité historique, pas comme une base produit.
  • Évaluez MQTT-SN seulement si le réseau impose un modèle capteurs ou non TCP/IP.
VersionStatutNiveauMeilleur usageConseil nouveau projet
MQTT 3.1Historique3Legacy, anciens brokers, compatibilité IBM initialeSeulement si le legacy l'impose
MQTT 3.1.1OASIS / ISO4Compatibilité IoT large, gateways, télémétrie légèreBase sûre de compatibilité
MQTT 5.0OASIS5Brokers modernes, cloud, multi-tenant, meilleurs diagnosticsPréféré pour le neuf
MQTT-SN 1.2Spécification associéeIndépendantRéseaux de capteurs, non TCP/IP, appareils contraintsSeulement si le réseau l'exige

MQTT 3.1 : version historique pour compatibilité legacy

MQTT 3.1 est la base pré-OASIS et contient déjà clients, brokers, CONNECT, PUBLISH, SUBSCRIBE, QoS, retained messages, will, keep alive et topic filters.

Son intérêt actuel est d'expliquer les anciens protocol names, les paquets CONNECT historiques et les modes de compatibilité broker.

Ne le ciblez pas pour un nouveau produit sauf firmware ou gateway non migrable.

Points à vérifier

  • Vérifier que le broker accepte MQTT 3.1.
  • Inspecter protocol name et protocol level dans CONNECT.
  • Ne pas confondre négociation de version et panne réseau.

MQTT 3.1.1 : base de compatibilité pratique

MQTT 3.1.1 est la version standardisée la plus répandue dans les appareils IoT, gateways, brokers open source, services cloud et clients WebSocket.

Elle suffit si le besoin se limite à publish, subscribe, QoS, retain et last will.

Ses limites concernent les erreurs peu détaillées, l'absence de properties standard, la gestion plus faible des sessions, expirations, flow control et diagnostics disconnect.

Quand rester en 3.1.1

  • SDKs ou modules sans MQTT 5.0.
  • Modèle de messages simple.
  • Compatibilité maximale prioritaire.
  • Coût de mise à jour terrain élevé.

MQTT 5.0 : version moderne de référence

MQTT 5.0 conserve publish/subscribe et ajoute properties et reason codes à la connexion, publication, souscription, confirmations et déconnexion.

Les properties couvrent session expiry, message expiry, packet size, receive maximum, topic alias, response topic, correlation data, user properties et content type.

Les reason codes permettent de distinguer authentification, autorisation, taille de paquet, migration serveur et déconnexion administrative.

Capacités clés

  • Reason codes précis.
  • Properties pour métadonnées.
  • Message Expiry contre les commandes obsolètes.
  • Receive Maximum et Maximum Packet Size pour la protection.
  • Response Topic et Correlation Data pour request-response.

MQTT-SN : protocole associé aux réseaux de capteurs

MQTT-SN ne remplace pas MQTT sur TCP. Il adapte publish/subscribe aux réseaux non TCP/IP et aux capteurs fortement contraints.

Il introduit souvent un gateway qui traduit adresses courtes et Topic IDs vers un broker MQTT classique.

Si TCP/TLS ou WebSocket fonctionne correctement, MQTT-SN est généralement inutile.

Choisir

  • Cloud IoT et WebSocket : MQTT 3.1.1 ou 5.0.
  • Non TCP/IP et appareils dormants : évaluer MQTT-SN.
  • Connexion à un broker existant : concevoir le gateway avec soin.

Migrer de MQTT 3.1.1 à MQTT 5.0

  1. Vérifier le support dans broker, SDKs, gateways, cloud et outils de test.
  2. Commencer par reason codes, DISCONNECT reason, message expiry, session expiry et maximum packet size.
  3. Conserver d'abord la sémantique 3.1.1 puis adopter User Properties, Response Topic et Topic Alias.
  4. Migrer les flottes mixtes par tenant, produit ou génération firmware.

FAQ

MQTT 5.0 est-il compatible avec MQTT 3.1.1 ?

Le modèle publish/subscribe est commun, mais le protocol level CONNECT diffère. Un broker peut accepter les deux, mais une session utilise une seule version.

MQTT 5.1 existe-t-il ?

En mai 2026, OASIS liste MQTT 3.1.1 et MQTT 5.0 comme standards principaux, pas MQTT 5.1.

Tout nouveau projet doit-il utiliser MQTT 5.0 ?

Pas forcément. Si les appareils et la plateforme le supportent, 5.0 est préférable. Sinon 3.1.1 reste pragmatique.

Références officielles

Continuer vers le guide QoS Ouvrir le client MQTT