Pourquoi le QoS existe
Les objets connectes vivent sur des reseaux imparfaits. Ils dorment, se deplacent et perdent des paquets. Les niveaux QoS de MQTT definissent un contrat simple entre emetteur, broker et abonne pour dire a quel point il faut insister.
Le QoS n’elimine pas les erreurs, mais clarifie les comportements. Vous pouvez alors concevoir vos traitements pour gerer pertes, doublons et reprises.
QoS 0 : au plus une fois
Le QoS 0 est du “fire and forget”. Pas d’ack, pas de retry. C’est le plus leger et ideal pour la telemetrie a fort volume ou la perte est acceptable.
Un capteur qui envoie une temperature toutes les secondes peut perdre une mesure sans impact. QoS 0 minimise le trafic et la charge.
QoS 1 : au moins une fois
Le QoS 1 exige un accusé de reception. En absence d’ack, l’emetteur renvoie, ce qui peut creer des doublons. C’est un bon compromis pour des commandes ou mises a jour importantes.
Avec QoS 1, il faut des traitements idempotents. Une commande qui arrive deux fois ne doit pas provoquer un effet double.
QoS 2 : exactement une fois
Le QoS 2 utilise un handshake en deux temps pour garantir une livraison unique. C’est le plus fiable, mais aussi le plus couteux en latence et en stockage.
Il est reserve aux evenements critiques comme la facturation ou des transitions d’etats sensibles.
Choisir selon le type de message
La telemetrie frequente convient au QoS 0. Les commandes utilisateur preferent le QoS 1. Les evenements transactionnels rares peuvent justifier le QoS 2.
Le plus important est de definir un contrat par topic. Chaque topic doit annoncer clairement son niveau de fiabilite.
QoS et messages retenus
Un message retenu stocke la derniere valeur dans le broker. Le QoS s’applique aussi a sa livraison. Un retained en QoS 2 peut peser lourd sur le broker.
Un retained en QoS 1 est souvent le meilleur compromis : fiable pour les nouveaux abonnes sans surcout excessif.
Conseils operationnels
Surveillez les taux de retry et de doublons. Un trop grand nombre de doublons signale souvent un reseau instable ou un client mal configure.
Documentez le QoS par topic. L’equipe doit savoir ce qui est best-effort et ce qui est critique.