Utiliser MQTT pour un SaaS IoT vous permet de livrer des données d'appareils en temps réel à de nombreux clients depuis un seul produit, à condition de bien séparer ces clients dès le premier appareil. Ce guide montre comment choisir un modèle d'isolation, concevoir les identifiants et les préfixes de topics, intégrer les appareils et structurer votre backend sur un broker MQTT managé, pour lancer plus vite et monter en charge sans tout réarchitecturer.
L'anatomie d'une plateforme SaaS IoT
La plupart des produits SaaS IoT suivent le même schéma. Les appareils sur le terrain publient de la télémétrie et des états. Un backend s'abonne, stocke les données, applique la logique métier et expose une API. Une application web ou mobile montre à chaque client uniquement ses propres appareils et renvoie des commandes vers eux. MQTT se trouve au milieu parce qu'il gère bien la connectivité intermittente, les petits payloads et la messagerie bidirectionnelle. Si le protocole est nouveau pour vous, commencez par le rôle d'un broker MQTT.
Le broker est une infrastructure partagée pour votre activité, mais les données qu'il transporte appartiennent à vos clients. Trois décisions de conception en découlent :
- À quel point les clients sont-ils séparés au niveau du broker ?
- Comment les appareils sont-ils identifiés et authentifiés ?
- Comment les topics sont-ils structurés pour que votre backend puisse router les données par client ?
Décision 1 : choisir un modèle d'isolation des clients
Modèle A : un broker par client
Chaque client dispose de son propre broker, avec ses propres identifiants d'endpoint et son propre espace de topics. Les appareils du client A ne peuvent physiquement pas s'abonner aux topics du client B, car ils ne partagent pas le même espace de noms de broker. Votre backend se connecte à chaque broker client en tant que client MQTT.
C'est la séparation la plus forte, et elle simplifie les limites par client, le départ d'un client et la suppression des données : il suffit de supprimer le broker. La contrepartie : davantage de brokers à provisionner et un backend qui gère de nombreuses connexions.
Modèle B : un broker partagé avec des préfixes de topics
Les appareils de tous les clients se connectent à un seul broker, et les topics de chaque client commencent par un préfixe comme acme/ ou un identifiant client. Votre backend s'abonne à +/devices/+/telemetry et déduit le client du premier niveau du topic.
C'est simple et efficace, mais un préfixe de topic n'est en soi qu'une convention d'organisation, pas une frontière de contrôle d'accès. Si n'importe quel appareil du broker peut s'abonner à #, il voit les données de tous les clients. N'utilisez ce modèle que si vous maîtrisez l'ensemble des firmwares et qu'aucun élément côté client ne se connecte directement au broker, ou si votre broker impose des restrictions de topics par tenant.
Modèle C : par paliers
Les petits clients partagent un broker, tandis que les grands comptes ou les clients réglementés obtiennent leur propre broker, un cluster dédié ou un déploiement dans leur propre compte cloud. Cela reflète la manière dont de nombreuses entreprises SaaS construisent leurs offres tarifaires.
| Modèle | Force de la séparation | Charge opérationnelle | Idéal pour |
|---|---|---|---|
| A : un broker par client | Forte, imposée par le broker | Modérée | Produits B2B, accès côté client |
| B : broker partagé, préfixes | Dépend de l'application des règles | Faible | Firmware entièrement maîtrisé, données internes uniquement |
| C : par paliers | Forte là où c'est nécessaire | Modérée | Produits avec offres self-service et entreprise |
Les concepts sous-jacents sont détaillés dans l'isolation des tenants MQTT et l'architecture d'un broker MQTT multi-tenant.
Décision 2 : conception des identifiants
Votre modèle d'identifiants détermine la sécurité avec laquelle vous pouvez intégrer, révoquer et renouveler les accès des appareils.
- Un client ID par appareil. Chaque appareil a besoin d'un client ID unique et stable. Dérivez-le d'un numéro de série ou d'un enregistrement de provisionnement, jamais d'une valeur aléatoire générée au démarrage, sinon les sessions persistantes ne reprendront pas.
- Pas d'identifiants dans des dépôts publics ni dans les applications. Les applications mobiles et web ne doivent pas contenir d'identifiants broker de niveau appareil. Faites-les passer par votre API et laissez le backend dialoguer avec le broker, ou émettez des identifiants à portée limitée et de courte durée si votre broker le permet.
- Procédure de révocation. Lorsqu'un client part ou qu'un appareil est volé, vous devez pouvoir le couper sans toucher aux autres appareils.
- Procédure de rotation. Prévoyez comment le firmware reçoit de nouveaux identifiants, par exemple via un topic de configuration authentifié ou lors d'une mise à jour OTA.
Décision 3 : conception des topics pour le routage multi-clients
Une arborescence de topics prévisible simplifie le backend et sécurise les abonnements à wildcards. Un schéma qui fonctionne bien :
<customer>/<site>/<device-id>/telemetry
<customer>/<site>/<device-id>/status
<customer>/<site>/<device-id>/cmd
<customer>/<site>/<device-id>/cmd/response
Recommandations :
- Placez le client en premier, de sorte qu'un wildcard par niveau vous donne une vue complète d'un client.
- Gardez des identifiants stables, en minuscules, sans espaces.
- Utilisez des retained messages sur
statuspour que les tableaux de bord voient immédiatement le dernier état connu. - Utilisez les response topics et la correlation data de MQTT 5 pour les échanges commande-réponse au lieu d'inventer votre propre mécanisme.
- Évitez les données personnelles dans les noms de topics ; les topics apparaissent dans les logs et les outils.
Dans le modèle A, le niveau client est implicite puisqu'il correspond au broker : vous pouvez le retirer du topic ou le conserver par cohérence entre les paliers.
Un service d'ingestion backend minimal
Le backend s'abonne, valide et stocke. Cet exemple Python, avec paho-mqtt 2.x et MQTT 5, ingère la télémétrie d'un broker partagé et extrait le client du topic. Sur ConnectMQ Serverless (Paid), vous pouvez faire monter ces workers d'ingestion en charge horizontalement grâce à un abonnement partagé comme $share/ingest/+/+/+/telemetry, qui répartit les messages entre les workers.
import json
import ssl
import paho.mqtt.client as mqtt
SUBSCRIPTION = "+/+/+/telemetry" # utilisez $share/ingest/+/+/+/telemetry sur les plans avec abonnements partagés
def store(customer, site, device, data):
# Remplacez par votre écriture en base de données
print(f"[{customer}] {site}/{device}: {data}")
def on_connect(client, userdata, flags, reason_code, properties):
print("Ingest connected:", reason_code)
client.subscribe(SUBSCRIPTION, qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
if len(parts) != 4:
return
customer, site, device, _ = parts
try:
data = json.loads(msg.payload)
except json.JSONDecodeError:
print("Rejected non-JSON payload on", msg.topic)
return
store(customer, site, device, data)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_forever()
Les intégrations comme les bases de données, les notifications ou l'analytique se greffent sur ce service, ou sur des outils comme Node-RED et Telegraf qui se connectent au broker comme des clients MQTT ordinaires.
Construire sur ConnectMQ
ConnectMQ est un broker MQTT managé qui s'adapte à chacun de ces modèles. Chaque broker que vous créez reçoit des identifiants générés et un client ID qui leur est lié, et les brokers sont isolés les uns des autres sur le cluster mutualisé. Le modèle A devient alors simple : créez un broker par client, stockez ses identifiants dans votre backend et connectez votre service d'ingestion à chacun d'eux.
Les limites des plans correspondent naturellement à des paliers SaaS. Le plan Serverless gratuit prend en charge jusqu'à 25 connexions, une QoS jusqu'à 1 et des messages de 256 Ko, idéal pour le développement et les clients pilotes. Serverless (Paid) prend en charge jusqu'à 1 000 connexions, la QoS 2, des messages de 1 Mo et les abonnements partagés. Dedicated offre à un client un cluster isolé, et BYOC fait tourner le broker dans un compte cloud que vous ou votre client contrôlez, géré par ConnectMQ.
Le portail aide aussi les équipes support : l'explorateur de topics en direct et le client MQTT intégré au navigateur permettent de voir ce que les appareils d'un client envoient réellement, la vue des appareils regroupe les équipements par niveaux ISA-95 pour les clients industriels, et les règles d'alerte de seuil, avec un journal des alertes, signalent les valeurs hors plage.
Checklist de lancement de votre SaaS IoT
- Modèle d'isolation choisi et documenté pour chaque palier tarifaire.
- Client ID et identifiants uniques par appareil, avec une procédure de révocation.
- Arborescence de topics documentée et validée dans le backend.
- TLS uniquement, sur le port 8883 (appareils) et 8084 (clients navigateur).
- Reconnexion avec backoff exponentiel et jitter dans tous les firmwares.
- Service d'ingestion mis à l'échelle avec des abonnements partagés lorsqu'ils sont disponibles.
- Broker de préproduction distinct pour tester le firmware et le backend.
- Supervision et alerting des connexions et du flux de messages par client ; voir la checklist de mise en production MQTT.
Démarrer avec ConnectMQ
Prototypez votre SaaS sur un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, puis ajoutez un broker par client au fil des signatures. Vous pouvez aussi tester vos idées sur le serveur MQTT public gratuit, réservé aux tests et sans données de production, avant de créer un compte, et lire le guide du broker MQTT cloud pour comparer les options d'hébergement.
Questions fréquentes
Chaque client SaaS doit-il avoir son propre broker MQTT ?
Si les clients ou leurs applications se connectent directement, ou si les contrats exigent une séparation, oui. Un broker par client garantit une isolation imposée et un départ client simple.
Les préfixes de topics suffisent-ils à séparer les clients ?
Ils organisent les données, mais ne les protègent que si le broker contrôle les préfixes autorisés pour chaque client. Sans ce contrôle, tout client abonné à # verrait tout.
Comment faire monter en charge le backend qui consomme les données des appareils ?
Faites tourner plusieurs workers d'ingestion avec un abonnement partagé MQTT 5, afin que le broker répartisse les messages entre eux.
Mon application mobile peut-elle se connecter directement au broker ?
Elle le peut via Secure WebSocket sur le port 8084, mais évitez d'intégrer des identifiants d'appareil dans l'application. Passez par votre API ou utilisez des identifiants à portée limitée par utilisateur.
