QoS MQTT expliquée : niveaux QoS 0, 1 et 2

La QoS MQTT (Quality of Service, qualité de service) définit l’effort que le protocole fournit pour livrer un message. Il existe trois niveaux de QoS — 0, 1 et 2 — et chacun ajoute des paquets d’acquittement en échange d’une garantie plus forte. Choisir le bon niveau est l’une des décisions de conception les plus importantes d’un système MQTT : trop bas et vous perdez des données, trop haut et vous gaspillez bande passante et latence.

Les niveaux de QoS en un coup d’œil

QoS	Garantie	Paquets par saut	Doublons possibles ?
0	Au plus une fois	1 (`PUBLISH`)	Non — mais des messages peuvent être perdus
1	Au moins une fois	2 (`PUBLISH`, `PUBACK`)	Oui
2	Exactement une fois	4 (`PUBLISH`, `PUBREC`, `PUBREL`, `PUBCOMP`)	Non

Un détail important : la QoS se négocie par saut. La QoS de l’éditeur régit le trajet jusqu’au broker, et la QoS de l’abonnement régit le trajet du broker vers chaque abonné.

QoS 0 — au plus une fois

L’émetteur envoie le PUBLISH une seule fois puis l’oublie. Il n’y a ni acquittement ni identifiant de paquet. Si la connexion TCP se rompt pendant que le message est en transit, il est perdu.

Échange en QoS 0

Sender                     Receiver
  | ---- PUBLISH (QoS 0) ---> |
  |                           |  (no reply)

La QoS 0 est l’option la moins coûteuse et convient parfaitement à la télémétrie à haute fréquence — une mesure de température chaque seconde, une position GPS, un heartbeat — où le message suivant remplace celui qui a été perdu. Notez que TCP protège toujours contre la corruption et le réordonnancement sur une connexion active ; le risque, c’est de perdre des messages lorsque la connexion tombe.

QoS 1 — au moins une fois

L’émetteur attribue un identifiant de paquet, stocke le message et attend un PUBACK portant le même identifiant. Tant que l’acquittement n’est pas arrivé, le message est considéré comme en vol. Si la connexion tombe avant, l’émetteur le retransmet avec le flag DUP lorsque la session reprend.

Échange en QoS 1

Sender                          Receiver
  | ---- PUBLISH (QoS 1, id=7) ---> |  store + deliver
  | <--------- PUBACK (id=7) ------ |
  |  delete stored message          |

Le piège : si le PUBACK se perd, le récepteur a déjà traité le message et le reçoit une seconde fois lors de la retransmission. La QoS 1 garantit donc la livraison mais autorise les doublons. Pour la plupart des applications, c’est le bon compromis — rendez vos handlers idempotents (par exemple en incluant un ID de message ou un horodatage dans le payload) et vous obtenez la fiabilité pour un surcoût faible.

QoS 2 — exactement une fois

La QoS 2 utilise une poignée de main en quatre étapes pour qu’aucune des deux parties ne puisse livrer le message deux fois :

Échange en QoS 2

Sender                          Receiver
  | ---- PUBLISH (QoS 2, id=9) ---> |  store id=9, (deliver)
  | <--------- PUBREC (id=9) ------ |
  | ---------- PUBREL (id=9) -----> |  release id=9
  | <--------- PUBCOMP (id=9) ----- |
  |  done                           |

PUBLISH — l’émetteur transmet le message et en conserve une copie.
PUBREC — le récepteur confirme la réception et enregistre l’identifiant de paquet. Tout PUBLISH retransmis avec cet identifiant est reconnu comme un doublon et n’est pas livré à nouveau.
PUBREL — l’émetteur supprime le message et indique au récepteur qu’il peut libérer l’identifiant.
PUBCOMP — le récepteur confirme ; l’identifiant peut être réutilisé.

Le coût : deux allers-retours par saut et un état à maintenir des deux côtés. La QoS 2 a du sens pour les messages dont un doublon serait réellement nuisible et ne peut pas être filtré dans l’application — des événements de facturation ou des commandes d’actionneur à usage unique, par exemple. En pratique, beaucoup d’équipes préfèrent la QoS 1 combinée à une déduplication.

La règle de rétrogradation : la QoS effective

Un abonné demande une QoS maximale dans son paquet SUBSCRIBE, et le broker renvoie la QoS accordée dans le SUBACK. Chaque message est ensuite livré avec la plus basse des deux QoS : celle de la publication et celle accordée à l’abonnement.

Publié en	Abonné en	Livré en
QoS 2	QoS 0	QoS 0
QoS 1	QoS 2	QoS 1
QoS 0	QoS 1	QoS 0
QoS 2	QoS 2	QoS 2

Les brokers peuvent aussi plafonner la QoS : en MQTT 5, un broker peut annoncer un Maximum QoS dans le CONNACK, et certains brokers ou services cloud ne prennent pas du tout en charge la QoS 2. Vérifiez toujours la QoS accordée dans le SUBACK au lieu de supposer que vous avez obtenu ce que vous avez demandé.

QoS et sessions : ce qui se passe hors ligne

La QoS ne protège les messages que tant qu’une session existe. Avec une session propre (cleanSession=true en 3.1.1, cleanStart=true avec une expiration de session à 0 en MQTT 5), le broker supprime les abonnements et les messages en attente dès que le client se déconnecte — les messages QoS 1 et 2 publiés pendant que vous êtes hors ligne ne vous sont donc tout simplement jamais livrés.

Pour recevoir les messages qui arrivent pendant qu’un client est hors ligne, il vous faut ces trois éléments :

un client ID stable et unique,
une session persistante (cleanSession=false, ou en MQTT 5 un Session Expiry Interval non nul),
un abonnement en QoS 1 ou 2, et des messages publiés en QoS 1 ou 2.

Notez aussi que la retransmission des messages non acquittés a lieu lorsque la session reprend après une reconnexion — ni la 3.1.1 ni la 5.0 n’exigent de renvoi sur une connexion active, puisque TCP gère déjà les pertes à ce niveau.

Tester la QoS en pratique

Vous pouvez observer la QoS en action avec la CLI Mosquitto. Le flag -d affiche chaque paquet, ce qui permet de voir passer PUBREC/PUBREL/PUBCOMP :

bash

# subscriber with a persistent session (-c) and fixed client ID
mosquitto_sub -h broker.emqx.io -t 'testmqtt/qos-demo/#' -q 2 -c -i qos-demo-sub -d

# publish at QoS 2
mosquitto_pub -h broker.emqx.io -t 'testmqtt/qos-demo/order' -m 'order-1001' -q 2 -d

Arrêtez l’abonné, publiez quelques messages en QoS 1, puis relancez-le avec le même client ID : les messages mis en file d’attente doivent arriver. Dans le navigateur, le client MQTT en ligne vous permet de choisir la QoS par abonnement et par publication. Pour d’autres scénarios de test, consultez comment tester un broker MQTT.

Essayez-le dans le client MQTT en ligne

Choisir un niveau de QoS

QoS 0 — données de capteurs fréquentes, positions, métriques où seule la dernière valeur compte.
QoS 1 — le choix par défaut raisonnable pour les événements, alertes et commandes ; associez-la à des handlers idempotents.
QoS 2 — les rares cas où les doublons coûtent cher et ne peuvent pas être dédupliqués en aval.

La QoS fonctionne de concert avec les messages retenus (retained) et le Last Will ; si vous découvrez le protocole, commencez par qu’est-ce que MQTT.

Questions fréquentes

Quel niveau de QoS MQTT faut-il utiliser ?

Utilisez la QoS 0 pour la télémétrie fréquente où la perte d’un échantillon n’a pas d’importance, la QoS 1 pour la plupart des événements et commandes (avec des handlers idempotents), et la QoS 2 uniquement lorsque les doublons sont vraiment nuisibles et que vous ne pouvez pas dédupliquer dans l’application.

Pourquoi ai-je reçu deux fois un message en QoS 1 ?

La QoS 1 garantit une livraison au moins une fois. Si l’acquittement se perd, généralement parce que la connexion est tombée, l’émetteur retransmet le message avec le flag DUP après la reconnexion, et le récepteur peut donc le voir deux fois.

La QoS 2 garantit-elle une livraison exactement une fois de bout en bout ?

Non. La QoS s’applique séparément à chaque saut : de l’éditeur au broker, puis du broker à l’abonné. L’abonné reçoit le minimum entre la QoS de publication et celle de son abonnement, et les messages destinés aux clients hors ligne ne sont conservés que s’ils disposent d’une session persistante.

Niveaux de QoS MQTT expliqués : QoS 0, 1 et 2