Checklist de tests MQTT : 12 vérifications avant la mise en production

Cette checklist de tests MQTT vous guide à travers les douze vérifications qui permettent de détecter la plupart des incidents de production des applications MQTT avant vos utilisateurs. Chaque point s'accompagne d'un test rapide que vous pouvez lancer depuis un ordinateur portable sur le serveur MQTT public gratuit : à la fin, vous disposerez d'une routine de mise en production reproductible, plutôt que d'une vague impression que « ça marchait sur mon bureau ».

Pourquoi les applications MQTT ont besoin de leur propre plan de test

Les tests unitaires couvrent votre logique d'analyse et votre logique métier, mais la plupart des défaillances MQTT surviennent entre le client et le broker : un appareil qui ne se réabonne jamais après une reconnexion, un tableau de bord qui affiche une valeur retenue périmée, un Last Will qui se déclenche pour une mauvaise raison, ou un payload qui pèse soudain 70 Ko parce que quelqu'un a ajouté un champ de débogage. Rien de tout cela n'apparaît dans une démonstration où tout se passe bien.

La bonne nouvelle, c'est que le comportement de MQTT est observable. Chaque message transite par le broker : avec deux terminaux et un abonné sur un wildcard, vous voyez exactement ce que font vos appareils et vos services. Si vous avez besoin d'un rappel sur les différents rouages, commencez par le fonctionnement de MQTT, puis revenez ici.

Préparez d'abord un environnement de test

Utilisez un environnement jetable pour ces vérifications. Le serveur MQTT public gratuit broker.connectmq.com accepte les connexions anonymes avec n'importe quel client ID unique et non vide. Choisissez un préfixe de topic aléatoire pour que vos tests n'entrent pas en collision avec ceux des autres, et n'oubliez pas que l'espace public est lisible par tous : n'envoyez jamais de vrais identifiants ni de données clients.

# Choisir un préfixe unique pour cette session de test
export PREFIX="connectmq/demo/$(openssl rand -hex 4)"
echo $PREFIX

# Terminal 1 : tout observer sous votre préfixe, en mode verbeux, MQTT 5
mosquitto_sub -h broker.connectmq.com -p 1883 -V mqttv5 \
  -i watcher-$RANDOM -t "$PREFIX/#" -v

Gardez cet observateur ouvert pendant toute la session.

Prenez connaissance des limites du serveur MQTT public gratuit avant de commencer, car certaines vérifications les atteignent volontairement : 64 Ko par message, 10 messages par seconde et par client, 10 abonnements par client, 8 niveaux de topic et une expiration de session maximale de 30 minutes. Votre broker de production aura des limites différentes, et c'est précisément pourquoi vous devez les tester explicitement.

La checklist de tests MQTT

Parcourez la liste dans l'ordre. Les points 1 à 4 concernent la connectivité, les points 5 à 8 la sémantique des messages, et les points 9 à 12 la robustesse.

1. Connexion et authentification. Un mauvais mot de passe, un mauvais port et les échecs TLS produisent des erreurs claires.
2. Unicité du client ID. Deux clients avec le même ID ne s'éjectent pas mutuellement en boucle sans bruit.
3. Reconnexion et réabonnement. Après une coupure réseau, le client se reconnecte avec un backoff et restaure ses abonnements.
4. Keep alive. Une connexion à demi ouverte est détectée en environ 1,5 fois l'intervalle de keep alive.
5. Comportement de la QoS. La QoS demandée est celle obtenue, et les doublons sont gérés.
6. État retenu. Les nouveaux abonnés reçoivent la bonne dernière valeur connue, et les retained messages périmés peuvent être effacés.
7. Last Will and Testament. Une déconnexion brutale produit un statut hors ligne ; un arrêt propre, non.
8. Sessions persistantes. Les messages publiés pendant qu'un abonné est hors ligne lui parviennent à son retour (QoS 1 et 2 uniquement).
9. Validation des payloads. Le JSON mal formé, les champs manquants et les types erronés sont rejetés sans faire planter le consommateur.
10. Limites de taille, de débit et de topics. Les payloads trop volumineux, les rafales de publication et les topics trop profonds échouent de manière prévisible.
11. Conception des topics et des wildcards. Les abonnements correspondent exactement à ce que vous voulez, et à rien d'autre.
12. Charge et endurance. Le système tient un nombre de connexions et un débit de messages réalistes pendant des heures, pas quelques secondes.

Les sections ci-dessous montrent comment exécuter chaque groupe.

Vérifications de connectivité (points 1 à 4)

Commencez par les cas négatifs. Un bon client journalise une raison explicite lorsqu'il ne parvient pas à se connecter ; un mauvais client réessaie indéfiniment sans rien dire.

# Le TCP simple doit réussir
mosquitto_pub -h broker.connectmq.com -p 1883 -i test-pub-$RANDOM \
  -t "$PREFIX/ping" -m "hello"

# TLS sur 8883 doit réussir et valider le certificat Let's Encrypt
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i test-tls-$RANDOM -t "$PREFIX/ping" -m "hello over tls"

# Du MQTT simple sur le port TLS doit échouer rapidement, sans rester bloqué
mosquitto_pub -h broker.connectmq.com -p 8883 -i test-bad-$RANDOM \
  -t "$PREFIX/ping" -m "should fail"

Pour le point 2, lancez deux abonnés avec le même client ID. Le broker déconnecte l'ancienne session lorsque la nouvelle se connecte. Si les deux clients se reconnectent automatiquement, ils s'éjecteront à tour de rôle, ce qui se traduit dans vos journaux par une succession rapide de connexions et de déconnexions. Générez les client IDs à partir d'un identifiant d'appareil stable associé à un rôle, jamais à partir d'une constante codée en dur partagée par toute une flotte.

Pour le point 3, le test le plus fiable est physique : lancez votre client, puis débranchez le câble réseau ou désactivez le Wi-Fi pendant 60 secondes. Au retour de la liaison, publiez un message depuis le terminal d'observation et vérifiez que votre client le reçoit toujours. De nombreuses bibliothèques se reconnectent automatiquement, mais ne restaurent les abonnements que si vous vous abonnez dans le callback de connexion. Le script Python ci-dessous illustre ce schéma et affiche chaque changement d'état pour que vous puissiez voir ce qui se passe.

import time
import uuid
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/replace-me"
client_id = f"reconnect-test-{uuid.uuid4().hex[:8]}"

def on_connect(client, userdata, flags, reason_code, properties):
    print(f"{time.strftime('%X')} connected: {reason_code}")
    # S'abonner ici garantit le rétablissement des abonnements après chaque reconnexion
    client.subscribe(f"{PREFIX}/cmd/#", qos=1)

def on_disconnect(client, userdata, disconnect_flags, reason_code, properties):
    print(f"{time.strftime('%X')} disconnected: {reason_code}")

def on_message(client, userdata, msg):
    print(f"{time.strftime('%X')} {msg.topic} qos={msg.qos} retain={msg.retain} {msg.payload!r}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=client_id,
                     protocol=mqtt.MQTTv5)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=30)

client.connect("broker.connectmq.com", 1883, keepalive=20)
client.loop_forever(retry_first_connection=True)

Avec un keep alive de 20 secondes, le broker doit considérer le client comme parti environ 30 secondes après l'arrêt du trafic. C'est le point 4 : si votre appareil met plusieurs minutes à remarquer une liaison morte, votre keep alive est trop long ou la bibliothèque n'envoie pas de PINGREQ.

Vérifications de la sémantique des messages (points 5 à 8)

La QoS se négocie par abonnement et par publication, et le niveau de livraison effectif est le plus faible des deux. Testez-le explicitement plutôt que de le supposer. Si vous n'êtes pas sûr de ce que garantit chaque niveau, lisez d'abord les niveaux de QoS MQTT expliqués.

# Abonnement en QoS 1, publication en QoS 2 : la livraison est rétrogradée en QoS 1
mosquitto_sub -h broker.connectmq.com -i qos-sub-$RANDOM -q 1 \
  -t "$PREFIX/qos" -v -d

mosquitto_pub -h broker.connectmq.com -i qos-pub-$RANDOM -q 2 \
  -t "$PREFIX/qos" -m "qos test" -d

L'option -d affiche le flux de paquets (PUBLISH, PUBACK, PUBREC, etc.), ce qui rend la rétrogradation visible. Votre code consommateur doit aussi tolérer les doublons en QoS 1 : traitez deux fois le même message et vérifiez que rien ne casse, par exemple en indexant les écritures sur un identifiant de message contenu dans le payload.

Pour l'état retenu, publiez une valeur retenue, puis connectez un tout nouvel abonné et vérifiez qu'il la reçoit immédiatement avec le drapeau retain positionné. Effacez-la ensuite en publiant un payload retenu vide, et vérifiez que le nouvel abonné suivant ne reçoit rien.

mosquitto_pub -h broker.connectmq.com -i ret-$RANDOM -r \
  -t "$PREFIX/sensor1/state" -m '{"temp":21.4}'

mosquitto_sub -h broker.connectmq.com -i ret-check-$RANDOM \
  -t "$PREFIX/sensor1/state" -v -C 1 -W 5

# Effacer le retained message
mosquitto_pub -h broker.connectmq.com -i ret-clear-$RANDOM -r -n \
  -t "$PREFIX/sensor1/state"

La vérification du Last Will nécessite un client qui meurt brutalement. Connectez-vous avec un message de will, puis tuez le processus avec kill -9 ou coupez le réseau. L'observateur doit voir le will après l'expiration du keep alive. Recommencez avec une sortie propre par Ctrl+C, qui envoie un DISCONNECT : le will ne doit pas être publié. Le guide du Last Will and Testament explique le schéma online/offline retenu qu'utilisent la plupart des flottes.

mosquitto_sub -h broker.connectmq.com -i lwt-dev-$RANDOM -k 10 \
  --will-topic "$PREFIX/dev1/status" --will-payload offline --will-retain \
  -t "$PREFIX/dev1/cmd"

Pour les sessions persistantes, connectez un abonné avec un client ID fixe, la QoS 1 et une expiration de session, déconnectez-le, publiez trois messages en QoS 1, puis reconnectez-le avec le même ID. Les trois messages doivent arriver. Sur le broker public, gardez l'expiration de session à 1 800 secondes au maximum.

mosquitto_sub -h broker.connectmq.com -V mqttv5 -i persist-fixed-001 \
  -c -x 600 -q 1 -t "$PREFIX/queue" -v

Vérifications de robustesse (points 9 à 12)

La validation des payloads a sa place dans chaque consommateur. Publiez volontairement des données invalides : JSON incorrect, nombre sous forme de chaîne, payload vide, chaîne de 10 Ko dans un champ censé être court. Le consommateur doit journaliser et ignorer, sans planter ni écrire de données absurdes dans la base.

for p in '{"temp":' '{"temp":"hot"}' '' '{"unexpected":true}'; do
  mosquitto_pub -h broker.connectmq.com -i bad-$RANDOM \
    -t "$PREFIX/sensor1/telemetry" -m "$p"
done

Les limites sont le domaine où les environnements public et de production diffèrent le plus : testez donc le comportement, pas seulement la valeur. Sur le broker public, un payload de plus de 64 Ko, plus de 10 messages par seconde depuis un même client, un onzième abonnement ou un neuvième niveau de topic doivent tous être refusés. Assurez-vous que votre client remonte cela comme une erreur et applique un backoff au lieu de marteler le broker. En MQTT 5, cherchez des reason codes comme 0x97 (quota exceeded) dans la déconnexion ou l'acquittement. Les limites de taille d'un broker MQTT managé dépendent du plan ; chez ConnectMQ, par exemple, le plan Serverless gratuit autorise des messages de 256 Ko et le plan Serverless payant de 1 Mo.

# Payload de 70 Ko : doit être rejeté sur le broker public
head -c 71680 /dev/urandom | base64 > /tmp/big.txt
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i big-$RANDOM \
  -t "$PREFIX/big" -f /tmp/big.txt -d

Pour la conception des wildcards, abonnez-vous avec le filtre exact qu'utilise votre service et publiez sur des topics qui doivent correspondre et d'autres qui ne le doivent pas. Un filtre comme +/+/telemetry correspond souvent à plus de topics que prévu.

Les tests de charge et d'endurance constituent la dernière étape. Simulez le nombre réel d'appareils avec des intervalles et des tailles de payload réalistes, et laissez tourner pendant plusieurs heures. Faites-le sur un broker privé plutôt que sur le broker public, car la limite de débit par client de ce dernier est volontairement basse. Notre panorama des outils de test de charge MQTT compare les options.

Tableau de référence rapide

Des outils pour tester plus vite

Les clients en ligne de commande sont parfaits pour les scripts, mais un outil visuel accélère les tests exploratoires. ConnectMQ propose dans son portail un client MQTT intégré au navigateur et un explorateur de topics en direct, ainsi qu'un explorateur MQTT pour le bureau et une extension VS Code : vous pouvez ainsi observer les topics pendant l'exécution de vos scripts de test. Quel que soit votre outil, enregistrez vos commandes de test dans le dépôt pour que la prochaine version passe la même checklist. Si vous découvrez le protocole dans son ensemble, le tutoriel MQTT est le meilleur moyen d'acquérir les bases sur lesquelles reposent ces vérifications.

Testez sur un broker ConnectMQ privé

Une fois les vérifications réussies sur le serveur MQTT public gratuit, répétez-les sur l'environnement que vous allez réellement livrer. ConnectMQ vous fournit en quelques clics un broker privé avec TLS sur le port 8883, WebSocket sur le port 8084, des quotas par plan et des identifiants générés. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, remplacez YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID, et exécutez la même checklist avant la mise en production.

Questions fréquentes

Que doit contenir une checklist de tests MQTT ?

Au minimum : l'authentification et TLS, l'unicité du client ID, la reconnexion avec réabonnement, le keep alive, la QoS, les retained messages, le Last Will, les sessions persistantes, la validation des payloads, les limites du broker, la correspondance des wildcards et un test de charge de plusieurs heures.

Puis-je tester mon application MQTT sur un broker public ?

Oui, pour les vérifications fonctionnelles. Utilisez un client ID et un préfixe de topic uniques et n'envoyez jamais de données sensibles, car les topics publics sont lisibles par tous. Effectuez les tests de charge sur un broker privé.

Comment tester le Last Will MQTT sans débrancher de matériel ?

Tuez le processus client de façon brutale (par exemple avec kill -9) pour qu'il ne puisse pas envoyer de DISCONNECT. Le broker publie le will après l'expiration de la période de keep alive.

Pourquoi mon client ne reçoit-il plus de messages après une reconnexion ?

Il ne s'abonne probablement qu'une seule fois au démarrage. Déplacez les appels d'abonnement dans le callback de connexion, ou utilisez une session persistante, afin que les abonnements soient restaurés à chaque reconnexion.