Broker MQTT cloud : le guide complet du MQTT hébergé

Un broker MQTT cloud offre à vos appareils, applications et services un hub de messagerie fiable et accessible depuis Internet, sans que vous ayez à installer, corriger ou faire évoluer un serveur. Ce guide explique ce qu'est un broker hébergé, en quoi les modèles de déploiement diffèrent, ce qu'il faut vérifier en matière de sécurité, de limites et de coûts, et comment passer d'un prototype sur ordinateur portable à la production. À la fin, vous disposerez d'une connexion fonctionnelle à un broker privé et d'une checklist pour choisir un fournisseur.

Qu'est-ce qu'un broker MQTT cloud ?

Un broker MQTT est le serveur qui reçoit chaque message publié et l'achemine vers chaque abonné correspondant. Si vous avez besoin de vous rafraîchir la mémoire sur ce rôle, commencez par ce que fait un broker MQTT. Un broker MQTT cloud est ce même logiciel, exécuté sur une infrastructure exploitée par un fournisseur et exposé via un nom d'hôte public. Vous obtenez des endpoints, des identifiants et une console d'administration ; le fournisseur gère les serveurs, les systèmes d'exploitation, les certificats TLS, les mises à niveau et la capacité.

La différence avec « une VM sur laquelle tourne Mosquitto » tient à la responsabilité. Avec une VM dans le cloud, le broker reste le vôtre : configuration, certificats, supervision, correctifs de sécurité et panne à 3 heures du matin. Avec un broker MQTT managé, tout cela devient le travail du fournisseur, et vous consommez MQTT comme un service. Ce modèle est souvent appelé MQTT broker as a service, et c'est la raison pour laquelle la plupart des nouveaux projets IoT démarrent dans le cloud plutôt que sur un serveur au fond d'un placard.

Pourquoi les équipes migrent MQTT vers le cloud

• Accessibilité. Les appareils sur le terrain se connectent via l'Internet public à un nom d'hôte stable, sans règles de pare-feu entrantes ni redirection de ports sur chaque site.
• Délai avant le premier message. Créer un broker prend quelques minutes au lieu de jours de durcissement de serveur.
• Charge opérationnelle. Renouvellements de certificats, correctifs de l'OS, mises à niveau du broker et planification de capacité ne sont plus le travail de votre équipe.
• Croissance élastique. Passer de dix appareils de test à des milliers est un changement de plan, pas une refonte d'architecture.
• Outillage intégré. Un bon fournisseur livre un client web, un explorateur de topics et une visibilité sur les connexions, que vous devriez sinon assembler vous-même.

Les contreparties sont tout aussi réelles : vous dépendez de la disponibilité et de la feuille de route du fournisseur, les données quittent vos locaux, et vous travaillez dans les quotas de votre plan. Nous pesons le pour et le contre dans broker MQTT auto-hébergé ou managé.

Les modèles de déploiement d'un broker MQTT cloud

« Broker cloud » recouvre plusieurs architectures très différentes. Savoir laquelle vous achetez compte davantage que n'importe quelle liste de fonctionnalités.

Serverless

Un broker MQTT serverless s'exécute sur un cluster mutualisé multi-tenant. Vous créez un broker en quelques secondes, ne payez rien ou presque à petite échelle et ne vous souciez jamais des instances. Les bons fournisseurs appliquent une isolation stricte des tenants, des quotas par plan et une protection contre le flooding, afin qu'un tenant bruyant ne puisse pas pénaliser les autres. Les contraintes sont les limites de connexions, de taille de message et de débit fixées par le plan. Le fonctionnement de cette isolation est détaillé dans les brokers MQTT multi-tenant.

Dedicated

Un broker MQTT dédié vous attribue un cluster isolé. Personne d'autre ne partage votre CPU, votre mémoire ou votre réseau ; la latence et le débit sont donc plus prévisibles, et les limites sont dimensionnées selon votre charge plutôt que selon une offre mutualisée.

BYOC

Avec un broker MQTT BYOC, le broker s'exécute dans votre propre compte cloud : les données restent dans une infrastructure que vous contrôlez et les dépenses s'imputent sur vos accords cloud existants, tandis que le fournisseur continue d'exploiter le broker pour vous. C'est souvent la réponse adaptée aux secteurs réglementés ; voir la résidence des données MQTT pour l'aspect conformité.

Self Managed Enterprise

Certains environnements, comme les usines sans accès sortant à Internet, ne peuvent utiliser aucun service externe. Une édition autogérée vous permet d'exécuter le même logiciel de broker sur votre propre matériel, exploité par votre équipe.

La sécurité d'un broker MQTT hébergé

Passer au cloud place votre broker sur l'Internet public : la sécurité n'est donc pas optionnelle. Les points essentiels, par ordre d'importance :

1. TLS sur chaque connexion. Utilisez le port 8883 pour MQTT sur TLS et le 8084 pour Secure WebSocket. Le port 1883 en clair n'est acceptable que pour des tests jetables sur des données non sensibles.
2. Des identifiants uniques par appareil ou par service. Des mots de passe partagés transforment un appareil compromis en parc compromis.
3. Liaison du client ID. Lorsque les client ID sont liés aux identifiants émis, un mot de passe volé ne permet pas d'usurper un autre appareil.
4. Protection contre la force brute. Le broker doit bloquer les adresses IP après des échecs de connexion répétés.
5. Isolation des tenants. Sur une infrastructure mutualisée, vérifiez que les topics d'un client sont invisibles pour un autre.
6. Protection contre le flooding et quotas. Un client défaillant bloqué dans une boucle de publication doit être bridé, et non autorisé à faire tomber le broker.
7. Hygiène des payloads. Ne mettez jamais de secrets ni de données personnelles dans les noms de topics ; les chaînes de topics apparaissent dans les journaux et les outils.

La liste complète, y compris l'épinglage de certificats sur les appareils et la rotation des identifiants, se trouve dans nos bonnes pratiques de sécurité MQTT.

Les limites et quotas à bien comprendre

Chaque broker hébergé applique des limites, et elles façonnent votre conception bien plus qu'on ne l'imagine. Demandez ces chiffres avant de vous engager :

Lorsqu'un client dépasse un quota sur un broker MQTT 5, il reçoit un reason code au lieu d'un rejet silencieux ; 0x97 (Quota exceeded) est celui à surveiller. Notre article sur les quotas de connexion d'un broker MQTT explique comment les dimensionner.

Comment fonctionne la tarification du MQTT cloud

Les fournisseurs facturent le MQTT hébergé selon quelques modèles reconnaissables :

• Au nombre de connexions, souvent le facteur dominant pour les parcs d'appareils.
• Au volume de messages ou au débit, ce qui compte pour la télémétrie à haute fréquence.
• Par cluster ou par instance, typique des déploiements dédiés.
• Par niveau de fonctionnalités, la QoS 2, les messages plus volumineux ou les abonnements partagés étant débloqués sur les plans supérieurs.

Le plan le moins cher sur le papier n'est pas toujours le système le moins cher. Tenez compte du temps d'ingénierie consacré à l'exploitation, du coût des pannes et de l'effort nécessaire pour partir si le fournisseur ne convient pas. La tarification des brokers MQTT détaille les modèles, et le coût total de possession compare les dépenses managées et auto-hébergées dans le temps. Le risque de dépendance est le plus faible lorsque le fournisseur parle le MQTT standard sans SDK propriétaire, un sujet traité dans éviter le verrouillage fournisseur MQTT.

Se connecter à un broker MQTT dans le cloud : en pratique

Le moyen le plus rapide de comprendre le MQTT hébergé est d'en utiliser un. Commencez sur le serveur MQTT public gratuit broker.connectmq.com, partagé, sans compte et réservé aux tests et aux prototypes. Utilisez un client ID unique et un préfixe de topic unique, et rappelez-vous que l'espace public est lisible par tous :

# Terminal 1 : s'abonner
mosquitto_sub -h broker.connectmq.com -p 1883 -i cloud-sub-r4t7 \
  -t "connectmq/demo/r4t7w2/#" -v

# Terminal 2 : publier
mosquitto_pub -h broker.connectmq.com -p 1883 -i cloud-pub-r4t7 \
  -t "connectmq/demo/r4t7w2/sensor1/temp" -m "22.4"

Pour un broker privé, le parcours est le suivant :

1. Inscrivez-vous sur app.connectmq.com et choisissez un plan.
2. Créez un broker.
3. Copiez le nom d'utilisateur, le mot de passe et le client ID générés depuis le portail.
4. Connectez-vous en TLS sur le port 8883 (ou en WSS sur le 8084 avec le chemin /mqtt depuis les navigateurs).

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i YOUR_CLIENT_ID -u YOUR_USERNAME -P YOUR_PASSWORD \
  -t "plant1/#" -v

Le certificat est émis par Let's Encrypt, si bien que les bundles CA standard le vérifient. Sous macOS et Windows, utilisez --cafile avec un fichier de bundle CA au lieu de --capath.

Un client Python de niveau production

Ce client paho-mqtt 2.x se connecte avec des identifiants, annonce sa présence avec un statut retenu et un Last Will, et utilise l'expiration des messages de MQTT 5 pour que les mesures périmées ne soient pas livrées aux abonnés qui se connectent bien plus tard :

import json
import time

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

BASE = "plant1/line1/sensor1"

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

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

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="YOUR_CLIENT_ID",
    protocol=mqtt.MQTTv5,
)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.on_connect = on_connect
client.on_message = on_message

client.connect("broker.connectmq.com", 8883, keepalive=30)
client.loop_start()

props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 60  # secondes

while True:
    payload = json.dumps({"temp": 22.4, "ts": int(time.time())})
    client.publish(f"{BASE}/telemetry", payload, qos=1, properties=props)
    time.sleep(10)

Dans le portail ConnectMQ, vous pouvez voir ces messages arriver dans l'explorateur de topics en direct, renvoyer une commande depuis le client MQTT intégré au navigateur, et vérifier si un client donné est connecté en vous abonnant à $SYS/broker/connection/{clientId}/state.

Intégrer un broker cloud au reste de votre stack

Un broker achemine des messages ; il ne les stocke pas dans votre base de données et n'appelle pas vos API. Le pattern propre et portable consiste à connecter les outils d'intégration comme de simples clients MQTT :

• Stockage de séries temporelles : le consumer MQTT de Telegraf écrivant dans InfluxDB, ou un petit abonné Python écrivant dans PostgreSQL ou TimescaleDB.
• Flows et automatisation : Node-RED avec un nœud de configuration mqtt-broker pointant vers votre broker sur le 8883 avec TLS.
• Tableaux de bord : Grafana au-dessus de la base de données, ou une application navigateur utilisant MQTT.js sur WSS.
• Maison connectée : l'intégration MQTT de Home Assistant pour la maison connectée ; Jeedom et Domoticz savent aussi communiquer en MQTT.

Comme chacun de ces outils est un client standard, vous pouvez en remplacer ou en ajouter sans toucher au firmware des appareils. Pour des consommateurs backend avec répartition de charge, les abonnements partagés de MQTT 5 ($share/group/topic) distribuent les messages entre plusieurs workers ; ils sont généralement réservés aux offres payantes, comme dans le tableau des plans ci-dessous.

Choisir un fournisseur de broker MQTT cloud

Utilisez cette checklist pour comparer les fournisseurs. Elle complète notre guide plus général sur comment choisir un broker MQTT pour l'IoT.

1. Prend en charge MQTT 3.1.1 et 5.0 avec des clients standard, sans SDK propriétaire obligatoire.
2. Propose des endpoints TLS et Secure WebSocket avec un certificat publiquement reconnu.
3. Publie des quotas clairs pour les connexions, la taille des messages, la QoS et le débit.
4. Fournit une offre gratuite ou un serveur MQTT public gratuit pour valider vos clients avant de payer.
5. Offre un chemin du mutualisé vers le dédié ou le BYOC sans modifier le code client.
6. Vous donne de la visibilité : état des connexions, vue en direct des topics et alertes sur les valeurs importantes.
7. Documente l'isolation des tenants et la protection contre les abus sur les plans mutualisés.
8. Répond par écrit à vos questions de résidence des données et de support.

Avant le lancement, parcourez la checklist de mise en production MQTT, et si vous quittez un Mosquitto auto-hébergé, les étapes de migrer Mosquitto vers un broker MQTT cloud vous éviteront quelques surprises. Une fois en production, la supervision d'un broker MQTT explique quels signaux surveiller.

La place de ConnectMQ

ConnectMQ est un broker MQTT managé conçu autour des modèles de déploiement décrits ci-dessus :

Chaque broker prend en charge MQTT 3.1.1 et 5.0 sur TCP 1883, TLS 8883, WebSocket 8083 et Secure WebSocket 8084, avec un certificat Let's Encrypt. Le portail comprend un client MQTT dans le navigateur, un explorateur de topics en direct, un tableau de bord, une vue des appareils organisée selon les niveaux ISA-95, et des règles d'alerte à seuil avec un journal des alertes, en anglais ou en turc. Côté sécurité, vous bénéficiez de l'isolation multi-tenant, de quotas par plan, d'une protection contre le flooding, du blocage d'IP après des échecs de connexion répétés et de client ID liés aux identifiants émis. Pour les utilisateurs industriels, ConnectMQ détecte aussi les topics ISA-95 et Unified Namespace et décode les payloads Sparkplug B.

Ce qu'il ne fait volontairement pas, c'est remplacer votre stack de données : il n'y a ni moteur de règles intégré ni passerelle vers une base de données ; le stockage et l'automatisation sont assurés par des clients MQTT standard comme Telegraf, Node-RED ou vos propres services, comme décrit plus haut.

Lancez gratuitement votre broker MQTT cloud

Testez vos clients sur le serveur MQTT public gratuit broker.connectmq.com dès aujourd'hui, puis créez un broker privé sur app.connectmq.com. Le plan Serverless gratuit ne demande aucune carte bancaire, et les mêmes identifiants et le même code restent valables lorsque vous passez à un plan payant, dédié ou BYOC.

Questions fréquentes

Quelle est la différence entre un broker MQTT cloud et un broker MQTT managé ?

En pratique, les termes se recoupent. « Cloud » décrit l'endroit où le broker s'exécute et la façon dont les appareils l'atteignent, tandis que « managé » décrit qui l'exploite ; la plupart des offres hébergées sont les deux, mais une VM exécutant votre propre Mosquitto est hébergée dans le cloud sans être managée.

Un broker MQTT cloud est-il assez sûr pour des données industrielles ?

Il peut l'être, si vous utilisez TLS sur chaque connexion, des identifiants uniques par appareil et un modèle de déploiement adapté à vos exigences. Les usines soumises à des règles strictes de résidence des données choisissent souvent un déploiement dédié ou BYOC plutôt qu'une offre mutualisée.

Peut-on utiliser un broker MQTT cloud gratuit en production ?

Une offre gratuite convient à de petits déploiements non critiques dans ses limites, par exemple jusqu'à 25 connexions sur le plan Serverless gratuit de ConnectMQ. Le serveur MQTT public gratuit, anonyme, ne convient jamais à la production, car n'importe qui peut lire son espace public.

Faut-il un SDK spécial pour se connecter à un broker MQTT hébergé ?

Pas avec un fournisseur fondé sur les standards. N'importe quel client MQTT 3.1.1 ou 5.0 fonctionne, notamment paho-mqtt, MQTT.js, MQTTnet, PubSubClient et les outils CLI de Mosquitto.

Comment stocker les données d'un broker MQTT cloud dans une base de données ?

Exécutez un abonné qui écrit dans votre base de données, comme Telegraf pour InfluxDB ou un court script Python pour PostgreSQL. Le broker livre les messages ; l'abonné décide où ils sont stockés.