Checklist de mise en production MQTT : 30 vérifications avant le lancement

Cette checklist de mise en production MQTT rassemble les vérifications qui séparent une démo qui fonctionne sur votre bureau d'une flotte qui tourne pendant des années. Parcourez-la avant le lancement pour couvrir TLS, les identifiants, les client IDs, les reconnexions, la conception des topics, les sessions, la supervision et l'alerting. Chaque point est court et testable, et le code en fin d'article présente un client prêt pour la production que vous pouvez adapter à un broker ConnectMQ.

Comment utiliser cette checklist

Traitez chaque point comme une question fermée et joignez une preuve : un fichier de configuration, un résultat de test, une capture d'écran. Les points volontairement ignorés doivent être consignés avec leur justification. Passez la liste une fois pendant le développement, une autre avant le lancement, puis après chaque changement majeur du firmware ou du backend.

Si vous en êtes encore au prototype, le serveur MQTT public gratuit convient pour apprendre, mais aucun point de cette liste ne doit être validé sur lui. La production implique un broker privé avec vos propres identifiants.

Section 1 : broker et sécurité

1. Broker privé en place. Le trafic de production passe par un broker privé, pas par le serveur MQTT public gratuit ni par un autre broker public.
2. TLS uniquement. Les appareils utilisent le port 8883 (MQTT sur TLS), les navigateurs le 8084 (Secure WebSocket sur /mqtt). Les ports clairs 1883 et 8083 ne sont pas utilisés dans le firmware de production.
3. Validation des certificats activée. Les clients vérifient le certificat du broker auprès d'une autorité de certification de confiance. Aucun flag insecure oublié après les tests.
4. Stratégie de bundle CA définie. Les appareils disposent d'un moyen de recevoir des certificats racines à jour avant l'expiration des actuels.
5. Identifiants uniques. Chaque appareil ou passerelle possède ses propres identifiants, afin de pouvoir en révoquer un sans affecter les autres.
6. Aucun secret dans le contrôle de version. Les identifiants résident dans un stockage sécurisé ou un système de provisionnement, pas dans Git ni dans les applications.
7. Révocation testée. Vous avez réellement révoqué un identifiant en préproduction et constaté que l'appareil est refusé.

Consultez les bonnes pratiques de sécurité MQTT pour comprendre le raisonnement derrière ces points.

Section 2 : identité des clients et sessions

8. Client IDs uniques et stables. Chaque client ID est dérivé d'un numéro de série ou d'un enregistrement de provisionnement et ne change jamais d'un redémarrage à l'autre.
9. Aucun client ID en double. Deux processus ne partagent jamais un ID ; les doublons s'expulsent mutuellement dans une boucle sans fin.
10. Clean start ou session persistante choisi par client. Les abonnés qui ne doivent manquer aucun message utilisent des sessions persistantes ; les outils éphémères utilisent des sessions propres.
11. Expiration de session définie délibérément. En MQTT 5, l'intervalle d'expiration de session correspond à la durée pendant laquelle un appareil peut rester hors ligne.
12. Last Will configuré. Les appareils définissent un Last Will sur un topic de statut pour que le backend soit informé des déconnexions inattendues.

Section 3 : connectivité et reconnexions

13. Reconnexion automatique. Les clients se reconnectent d'eux-mêmes après une perte réseau ou un redémarrage du broker.
14. Backoff exponentiel avec jitter. Les délais de nouvelle tentative augmentent et sont aléatoires, pour que la flotte ne se reconnecte pas en bloc.
15. Réabonnement à la reconnexion. Sans sessions persistantes, les abonnements sont restaurés dans le callback de connexion.
16. Keepalive ajusté. Les valeurs typiques vont de 30 à 120 secondes : plus court sur des réseaux stables, plus long en cellulaire pour économiser les données.
17. Mise en mémoire tampon hors ligne. Les appareils stockent localement les mesures pendant la déconnexion, avec un plafond pour protéger la mémoire.
18. Défaillances testées. Vous avez débranché le câble réseau, redémarré la connexion au broker et coupé l'alimentation des appareils, et la reprise a fonctionné.

Section 4 : topics, payloads et QoS

19. Arborescence de topics documentée. Une convention écrite couvre les niveaux, le nommage et des exemples. Partez des niveaux sur lesquels votre backend doit router, comme le site, la ligne et l'appareil.
20. Aucun wildcard dans le code de publication. Seuls les abonnés utilisent + et #.
21. Format de payload versionné. Les payloads JSON ou binaires incluent un champ de version pour pouvoir faire évoluer le schéma plus tard.
22. Taille des payloads dans les limites. Les messages respectent la taille maximale de votre plan, avec de la marge.
23. QoS choisie par type de message. QoS 0 pour la télémétrie haute fréquence où une perte est acceptable, QoS 1 pour les événements et les commandes. Voir les niveaux de QoS MQTT expliqués.
24. Retained messages utilisés à dessein. Conservez en retained les états et la configuration, pas chaque mesure de télémétrie.

Section 5 : capacité et limites

25. Nombre de connexions compatible avec le plan. Les connexions simultanées en pointe, backends, outils et préproduction compris, restent dans les limites du plan avec de la marge.
26. Débit de messages estimé. Vous connaissez votre nombre attendu de messages par seconde et avez testé à un multiple de celui-ci.
27. Gestion des quotas dans les clients. Les reason codes MQTT 5 comme 0x97 (Quota exceeded) sont journalisés et déclenchent un backoff plutôt que des boucles de nouvelles tentatives serrées.

Section 6 : supervision, alerting et exploitation

28. Supervision active. Les clients connectés, le flux de messages et une sonde de bout en bout sont supervisés. Voir la supervision d'un broker MQTT.
29. Alertes acheminées. Les alertes parviennent à une personne, avec un responsable d'astreinte et un runbook pour les cas broker injoignable, déconnexions massives et erreurs de quota.
30. Environnement de préproduction. Un broker distinct existe pour tester les changements de firmware et de backend avant qu'ils n'atteignent la flotte.

Tableau récapitulatif

Un modèle de client prêt pour la production

Ce client Python, avec paho-mqtt 2.x, met en œuvre plusieurs des points ci-dessus : TLS avec validation des certificats, client ID stable, Last Will, expiration de session MQTT 5, réabonnement à la connexion, backoff et journalisation des reason codes. Remplacez les valeurs génériques par les identifiants du portail ConnectMQ.

import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

HOST = "YOUR_BROKER_HOST"
CLIENT_ID = "YOUR_CLIENT_ID"          # stable et unique par appareil
BASE = f"plant1/line1/{CLIENT_ID}"
STATUS = f"{BASE}/status"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    print("Connected, session present:", flags.session_present)
    client.publish(STATUS, "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd", qos=1)

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("Disconnected:", reason_code)   # par ex. Quota exceeded

def on_message(client, userdata, msg):
    print("Command:", msg.topic, msg.payload.decode())

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.will_set(STATUS, "offline", qos=1, retain=True)
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message

connect_props = Properties(PacketTypes.CONNECT)
connect_props.SessionExpiryInterval = 3600   # conserver la session 1 heure hors ligne

client.connect(HOST, 8883, keepalive=60, clean_start=False, properties=connect_props)
client.loop_start()

while True:
    reading = {"v": 1, "temp": 21.7, "ts": int(time.time())}
    if client.is_connected():
        client.publish(f"{BASE}/telemetry", json.dumps(reading), qos=0)
    time.sleep(10)

Pour ajouter du jitter à la première connexion de toute une flotte, attendez un nombre aléatoire de secondes avant l'appel initial à connect au démarrage.

Dérouler la checklist sur ConnectMQ

Sur ConnectMQ, plusieurs points sont pris en charge pour vous ou faciles à vérifier. Chaque broker reçoit des identifiants générés auxquels les client IDs sont liés, ce qui garantit les points 5 et 8. TLS sur le port 8883 et Secure WebSocket sur le port 8084 utilisent des certificats Let's Encrypt, reconnus par les bundles CA standard. La protection anti-flood et le blocage des IP après des échecs de connexion répétés ajoutent une couche que vous auriez sinon dû construire vous-même.

Pour le point 25, vérifiez les limites du plan : le plan Serverless gratuit prend en charge jusqu'à 25 connexions, une QoS jusqu'à 1 et des messages de 256 Ko ; Serverless (Paid) prend en charge jusqu'à 1 000 connexions, la QoS 2, des messages de 1 Mo et les abonnements partagés ; Dedicated et BYOC vous offrent une capacité isolée. Pour les points 28 et 29, utilisez le tableau de bord du portail, l'explorateur de topics en direct et les règles d'alerte de seuil avec le journal des alertes, et abonnez-vous à $SYS/broker/connection/{clientId}/state pour les passerelles critiques. Un broker Serverless gratuit constitue aussi un bon environnement de préproduction pour le point 30.

Démarrer avec ConnectMQ

Créez votre broker prêt pour la production sur app.connectmq.com, en commençant par le plan Serverless gratuit, sans carte bancaire. Lorsque vous êtes prêt à dépasser le stade du pilote, lisez notre guide pour passer du prototype MQTT à la production, comparez les options dans le guide du broker MQTT cloud, ou découvrez ce qu'un broker MQTT managé prend en charge pour vous.

Questions fréquentes

Quel est le point le plus souvent oublié avant la mise en production MQTT ?

Le comportement de reconnexion face à de vraies défaillances. Beaucoup d'équipes ne testent que le scénario nominal, puis découvrent des tempêtes de reconnexions ou des client IDs en double lors de la première panne.

Les appareils en production doivent-ils utiliser la QoS 2 ?

Rarement. La QoS 1, avec un traitement idempotent côté récepteur, couvre la plupart des cas avec moins de surcharge ; réservez la QoS 2 aux messages pour lesquels les doublons sont réellement nuisibles.

Puis-je utiliser le serveur MQTT public gratuit en production ?

Non. Les brokers publics sont lisibles par tous et ont des limites strictes. Utilisez un broker privé avec vos propres identifiants et TLS.

À quelle fréquence faut-il repasser la checklist ?

Avant chaque lancement et après tout changement important de firmware, de backend ou de plan. Conservez les preuves pour faciliter les audits et les passations.