MQTT, du prototype à la production : un parcours de migration étape par étape

Faire passer un prototype MQTT en production consiste surtout à combler les lacunes qu'une démo peut se permettre d'ignorer : qui peut se connecter, qui peut lire les données, comment les topics sont organisés et comment vous êtes averti lorsque quelque chose casse. Ce guide fait passer un projet amateur typique du serveur MQTT public gratuit à un broker privé protégé par TLS, avec un namespace propre et une supervision de base, dans l'ordre qui minimise les reprises.

Le point de départ : un prototype qui fonctionne

La plupart des projets MQTT commencent de la même façon. Un capteur ou un ESP32 publie du JSON sur le serveur MQTT public gratuit, un ordinateur portable exécute mosquitto_sub ou un flux Node-RED, et les données s'affichent. Un prototype typique ressemble à ceci :

mosquitto_pub -h broker.connectmq.com -p 1883 -i proto-dev-x9f3 \
  -t "connectmq/demo/x9f3/temp" -m '{"c":22.1}'

C'est une excellente façon de démarrer. Mais ce n'est pas de la production, pour cinq raisons :

1. Pas d'authentification. N'importe qui peut se connecter ; l'espace public de broker.connectmq.com est lisible par tous.
2. Pas de chiffrement. Le port 1883 transmet identifiants et payloads en clair.
3. Des topics improvisés. L'arborescence des topics a grandi au fil de l'eau et ne tiendra pas au-delà de quelques appareils.
4. Pas de présence. Impossible de distinguer un appareil hors ligne d'un appareil simplement silencieux.
5. Pas de visibilité. Quand les données s'arrêtent, vous le découvrez parce qu'un graphique reste plat.

Les étapes ci-dessous comblent chacune de ces lacunes l'une après l'autre.

Étape 1 : passer à des identifiants privés

Créez un compte sur app.connectmq.com, choisissez une offre, créez un broker et copiez le nom d'utilisateur, le mot de passe et le client ID générés. L'offre Serverless gratuite suffit pour un pilote jusqu'à 25 connexions ; l'offre Serverless payante porte ce chiffre à 1 000 et ajoute la QoS 2, les messages de 1 Mo et les abonnements partagés.

Deux règles rendent le reste de la migration indolore :

• Un jeu d'identifiants par appareil ou service. Les client ID sont liés aux identifiants émis : partager un même jeu entre deux appareils les fait se déconnecter mutuellement.
• Gardez les identifiants hors du contrôle de version. Chargez-les depuis des variables d'environnement, un fichier de secrets exclu de git ou une étape de provisionnement en usine.

# .env (ne jamais committer ce fichier)
MQTT_HOST=broker.connectmq.com
MQTT_PORT=8883
MQTT_USERNAME=YOUR_USERNAME
MQTT_PASSWORD=YOUR_PASSWORD
MQTT_CLIENT_ID=YOUR_CLIENT_ID

Étape 2 : activer le TLS partout

Le trafic de production doit utiliser TLS sur le port 8883 pour les appareils et WebSocket sécurisé sur le port 8084 avec le chemin /mqtt pour les navigateurs. ConnectMQ utilise un certificat Let's Encrypt, que la plupart des systèmes d'exploitation et environnements d'exécution reconnaissent déjà. Sur les microcontrôleurs, on intègre généralement le certificat ISRG Root X1 ; notre guide MQTT SSL pour ESP32 en donne les détails.

Voici l'éditeur du prototype réécrit pour la production en Python avec paho-mqtt 2.x. Il lit les identifiants depuis l'environnement, se connecte en TLS avec MQTT 5, définit un Last Will pour que le broker puisse annoncer les déconnexions inattendues, et publie un statut online retenu.

import json
import os
import time

import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes

HOST = os.environ["MQTT_HOST"]
PORT = int(os.environ.get("MQTT_PORT", "8883"))
CLIENT_ID = os.environ["MQTT_CLIENT_ID"]
BASE = "acme/site1/greenhouse/zone2/sensor-01"   # namespace de production

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect failed:", reason_code)
        return
    print("connected")
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("disconnected:", reason_code)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=CLIENT_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set()
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.on_connect = on_connect
client.on_disconnect = on_disconnect

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

client.connect(HOST, PORT, keepalive=60, properties=connect_props)
client.loop_start()

try:
    while True:
        reading = {"ts": int(time.time()), "temp_c": 22.1, "rh": 61}
        client.publish(f"{BASE}/telemetry", json.dumps(reading), qos=1)
        time.sleep(30)
except KeyboardInterrupt:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True).wait_for_publish()
    client.disconnect()
    client.loop_stop()

Remarquez le peu de changements par rapport au prototype : nom d'hôte, port, identifiants, TLS et quelques propriétés. C'est tout l'intérêt d'utiliser du MQTT standard de bout en bout.

Étape 3 : concevoir un namespace de topics de production

Un topic de prototype comme connectmq/demo/x9f3/temp fonctionne pour un capteur. Un namespace de production doit absorber de nouveaux sites, de nouveaux types d'appareils et de nouveaux consommateurs sans rien renommer. Une bonne structure va du général au particulier et sépare données, commandes et statuts.

Des règles pratiques qui évitent bien des soucis plus tard :

• Des niveaux en minuscules, sans espaces, sans barre oblique initiale.
• L'ID de l'appareil dans le topic, et pas seulement dans le payload, pour que les abonnés puissent filtrer avec des jokers.
• Une branche cmd distincte pour les commandes, afin que les appareils s'abonnent de façon ciblée.
• Des topics de statut retenus, pour que les abonnés tardifs voient immédiatement l'état courant.
• Une profondeur raisonnable ; le serveur MQTT public gratuit autorise 8 niveaux, un budget judicieux partout.

Si votre projet est industriel, envisagez de vous aligner dès le départ sur les niveaux ISA-95. La vue des appareils de ConnectMQ regroupe les clients par niveaux ISA-95 lorsque vos topics suivent ce schéma. Notre guide sur la structure de topics MQTT pour la maison connectée couvre les projets résidentiels.

Étape 4 : suivre la présence des appareils

Des messages de statut online et offline retenus associés à un Last Will, comme dans le code ci-dessus, donnent à chaque abonné une vue fiable des appareils connectés. Vous pouvez aussi suivre l'état côté broker via $SYS/broker/connection/{clientId}/state, utile pour un service backend qui doit savoir quand un client précis se déconnecte.

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -V mqttv5 \
  -t 'acme/site1/+/+/+/status' -v

Étape 5 : ajouter supervision et alertes

La production, c'est quand quelqu'un découvre les problèmes avant les utilisateurs. Commencez simplement :

• Utilisez le tableau de bord du portail et l'explorateur de topics en direct pour confirmer que les données circulent après chaque déploiement.
• Créez des règles d'alerte à seuil pour les valeurs importantes, comme une température hors plage, et consultez le journal des alertes.
• Journalisez les codes de raison MQTT 5 sur chaque client pour pouvoir diagnostiquer les problèmes de quota et d'autorisation.
• Si vous avez besoin d'un stockage long terme ou de notifications personnalisées, exécutez votre propre abonné, par exemple un service Python, Telegraf ou Node-RED, qui se connecte au broker comme un client MQTT ordinaire et écrit dans votre base de données ou votre outil de messagerie.

Pour une liste plus complète, lisez notre guide sur la supervision d'un broker MQTT.

La checklist de mise en production

Avant de livrer, vérifiez chaque point :

1. Chaque appareil et service dispose de ses propres identifiants et de son propre client ID.
2. Toutes les connexions utilisent TLS (8883) ou WebSocket sécurisé (8084).
3. Aucun identifiant ne se trouve dans le dépôt de code du firmware.
4. Le namespace de topics est documenté et commence par un niveau organisation ou tenant.
5. Les appareils publient un statut retenu avec un Last Will.
6. La logique de reconnexion utilise une temporisation exponentielle avec gigue.
7. Les payloads restent bien en deçà de la limite de taille de message de l'offre.
8. Les commandes utilisent au moins la QoS 1 et peuvent être reçues deux fois sans risque.
9. Vous avez prévu des mises à jour de firmware qui renouvellent les identifiants.
10. Les alertes parviennent à un humain lorsque des valeurs clés ou la présence d'un appareil changent.

Une fois la liste terminée, la checklist de production MQTT et les bonnes pratiques de sécurité MQTT vont plus loin sur le durcissement.

Choisir la bonne offre pour la production

Commencez par la plus petite offre qui couvre votre nombre de connexions avec de la marge. Passez à Serverless payant lorsque vous avez besoin de plus de 25 connexions, de la QoS 2, de messages plus gros ou d'abonnements partagés pour vos consommateurs backend. Choisissez Dedicated si vous voulez un cluster isolé, BYOC si le broker doit tourner dans votre propre compte cloud, et Self Managed Enterprise si vous devez l'exploiter vous-même. Le guide du broker MQTT cloud compare ces modèles d'hébergement plus en détail.

Passez votre prototype en production avec ConnectMQ

ConnectMQ vous offre des identifiants privés, le TLS, MQTT 5 et un portail avec explorateur de topics en direct et règles d'alerte, sur le même MQTT standard que celui que parle déjà votre prototype. Inscrivez-vous sur app.connectmq.com, créez un broker avec l'offre Serverless gratuite sans carte bancaire, et pointez-y votre prototype en quelques minutes. Si vous préférez n'exploiter aucune infrastructure vous-même, un broker MQTT managé est le chemin le plus court.

Questions fréquentes

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

Non. L'espace public de broker.connectmq.com est lisible par tous et applique des limites strictes par client : il est réservé aux tests. Les données de production ont leur place sur un broker privé avec identifiants et TLS.

Dois-je modifier le code de mes appareils pour passer en production ?

En général, seuls les paramètres de connexion changent : nom d'hôte, port 8883, identifiants et TLS. Les noms de topic changent si vous adoptez un nouveau namespace, ce qui vaut la peine d'être fait avant de passer à l'échelle.

Comment gérer les identifiants sur de nombreux appareils ?

Émettez un jeu d'identifiants par appareil, chargez-le lors du provisionnement plutôt que de le compiler dans un firmware partagé, et tenez un registre pour pouvoir révoquer un seul appareil sans toucher aux autres.

Quelle offre choisir pour un petit pilote ?

Un pilote jusqu'à 25 connexions simultanées tient dans l'offre Serverless gratuite. Passez à Serverless payant lorsque vous avez besoin de plus de connexions, de la QoS 2 ou de messages plus gros.