Un broker MQTT serverless vous fournit un endpoint MQTT opérationnel, des identifiants et un tableau de bord sans provisionner le moindre serveur, car votre broker vit sur un cluster mutualisé multi-tenant exploité par le fournisseur. Dans ce guide, vous verrez comment fonctionne le modèle serverless en coulisses, quelles limites d'utilisation comptent vraiment, à quelles charges il convient, et comment créer et tester pas à pas un broker serverless gratuit sur ConnectMQ.
Ce que « serverless » signifie pour un broker MQTT
Il y a évidemment toujours des serveurs. « Serverless » décrit qui les possède et comment vous les consommez. Avec un broker auto-hébergé comme Mosquitto sur une machine virtuelle, vous choisissez la taille de la machine, installez les paquets, ouvrez les ports du pare-feu, renouvelez les certificats TLS et appliquez les correctifs du système d'exploitation. Avec un broker MQTT serverless, tout cela incombe au fournisseur. Vous recevez un nom d'hôte, des ports, un nom d'utilisateur, un mot de passe et un client ID, et vous commencez à publier.
L'idée centrale est le multi-tenant. Un cluster de broker bien dimensionné sert de nombreux clients en même temps. Chaque client dispose d'un « broker » logiquement isolé sur ce cluster : ses propres identifiants, son propre espace de topics et ses propres quotas. Comme la capacité est mutualisée, le fournisseur peut proposer un petit palier gratuit ou très peu cher, et vous ne payez jamais une machine virtuelle inactive qui tourne à 2 % de CPU.
Si vous avez besoin de revoir le rôle du broker lui-même, consultez ce que fait un broker MQTT avant de poursuivre.
Comment fonctionne l'isolation entre clients
Un cluster mutualisé n'est sûr que si les clients ne peuvent ni se voir ni se perturber. Un broker serverless bien conçu applique l'isolation à plusieurs niveaux :
- Authentification. Chaque connexion présente des identifiants émis pour un seul client. Ici, les client ID sont liés aux identifiants émis, si bien qu'un autre client ne peut pas usurper l'identité de vos appareils.
- Espace de noms des topics. Vos topics sont limités à votre broker : un abonnement à
#ne renvoie donc jamais que votre propre trafic. - Quotas. Le nombre de connexions, la taille des messages et le niveau de QoS sont appliqués par plan, afin qu'aucun client ne puisse épuiser les ressources partagées.
- Protection contre les abus. La protection contre les inondations de messages et le blocage d'IP après des échecs de connexion répétés empêchent un client défaillant de dégrader le cluster pour tout le monde.
Quand un quota est atteint, un client MQTT 5 reçoit un reason code explicite (par exemple 0x97, quota exceeded) plutôt qu'un rejet silencieux, ce qui rend les limites diagnosticables au lieu de mystérieuses.
Serverless, dédié ou auto-hébergé
Le palier serverless est l'une des façons de consommer un broker MQTT managé. Le tableau compare les options courantes.
| Aspect | Auto-hébergé | Serverless (mutualisé) | Dédié (isolé) |
|---|---|---|---|
| Qui exploite les serveurs | Vous | Le fournisseur | Le fournisseur |
| Délai avant le premier message | Des heures à des jours | Quelques minutes | Étape de provisionnement |
| Capacité | Celle que vous dimensionnez | Mutualisée, quotas par plan | Réservée pour vous |
| Voisins bruyants | Aucun | Atténués par les quotas | Aucun |
| Coût à vide | Coût complet de la VM | Gratuit ou faible | Capacité réservée |
| Idéal pour | Contrôle total, sites isolés du réseau | Prototypes, petites flottes, enseignement, premiers produits | Flottes en production à charge stable |
Le compromis, en toute honnêteté : le serverless renonce à la capacité réservée et à une partie de la configurabilité en échange de zéro exploitation et d'un coût quasi nul à petite échelle. Quand vous avez besoin d'une isolation garantie et d'une marge prévisible, un broker MQTT dédié est l'étape suivante.
Les limites qui comptent sur un broker MQTT serverless
Chaque palier mutualisé publie ses quotas. Lisez-les comme des contraintes de conception, pas comme des petites lignes. Les plans serverless de ConnectMQ se présentent ainsi :
| Limite | Serverless (Free) | Serverless (Paid) |
|---|---|---|
| Connexions simultanées | Jusqu'à 25 | Jusqu'à 1 000 |
| QoS maximale | 1 | 2 |
| Taille maximale des messages | 256 Ko | 1 Mo |
| Shared subscriptions | Non | Oui |
| Protocoles | MQTT 3.1.1 et 5.0 | MQTT 3.1.1 et 5.0 |
Ce que cela signifie en pratique :
- Les connexions sont la ressource rare. Chaque appareil, chaque onglet de tableau de bord et chaque worker backend occupe une connexion. Vingt capteurs plus une instance Node-RED plus deux tableaux de bord dans le navigateur, cela fait déjà 23 connexions. Comptez-les avant de déployer.
- La QoS 1 couvre la plupart de la télémétrie. La livraison au moins une fois (at-least-once) avec des consommateurs idempotents suffit pour presque toutes les charges de capteurs. Si vous avez vraiment besoin d'une sémantique exactement une fois, lisez les niveaux de QoS MQTT expliqués et envisagez le palier payant.
- La taille des messages gêne rarement la télémétrie. Une mesure en JSON pèse quelques centaines d'octets. C'est pour les images et les morceaux de firmware que les 256 Ko comptent ; publiez une URL vers un stockage objet plutôt que le fichier lui-même.
- Les shared subscriptions permettent des consommateurs horizontaux. Si vous prévoyez plusieurs workers backend qui se répartissent un même flux de topic, il vous faut
$share/group/topic, disponible sur le palier serverless payant.
Les charges adaptées au serverless
Un broker MQTT serverless convient parfaitement pour :
- Les prototypes et preuves de concept. Vous passez de l'idée à une boucle appareil-tableau de bord fonctionnelle en un après-midi.
- Les petites flottes en production. Un bâtiment avec une douzaine de capteurs, un contrôleur de serre ou un petit déploiement en magasin tiennent largement dans les quotas de connexions.
- Les salles de classe et les hackathons. Chaque équipe obtient un broker isolé sans que personne n'ait à gérer d'infrastructure.
- Les produits en phase de lancement. Les startups peuvent valider leur marché avant de s'engager sur de la capacité réservée. Notre guide pour choisir un broker MQTT pour startups décrit le chemin de croissance.
- Les environnements de développement et de préproduction. Même les équipes disposant d'un broker de production dédié gardent souvent un broker serverless pour le développement.
Il convient moins bien si vous avez des milliers d'appareils toujours connectés, des budgets de latence stricts sous un débit élevé et soutenu, ou une politique qui interdit l'infrastructure partagée.
Tutoriel : créer un broker Serverless ConnectMQ gratuit
Étape 1 : s'inscrire et créer le broker
Rendez-vous sur ConnectMQ, ouvrez le portail, choisissez le plan Serverless (Free) et créez un broker. Le portail génère un nom d'utilisateur, un mot de passe et un client ID. Copiez-les en lieu sûr ; traitez le mot de passe comme n'importe quel autre secret.
Étape 2 : tester avec le client intégré au navigateur
Le portail inclut un client MQTT dans le navigateur et un explorateur de topics en direct. Abonnez-vous à test/#, publiez sur test/hello et vérifiez que le message apparaît. Cela valide les identifiants avant même d'écrire du code pour un appareil.
Étape 3 : se connecter en ligne de commande
Une fois les clients Mosquitto installés, connectez-vous en TLS sur le port 8883 :
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -t 'sensors/#' -v
Le broker utilise un certificat Let's Encrypt : le magasin de CA du système suffit, aucun fichier de CA personnalisé n'est nécessaire.
Étape 4 : publier depuis Python
Ce script utilise paho-mqtt 2.x avec l'API de callbacks version 2 et publie une mesure toutes les cinq secondes.
import json
import random
import ssl
import time
import paho.mqtt.client as mqtt
HOST = "broker.connectmq.com"
PORT = 8883
USERNAME = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"
CLIENT_ID = "YOUR_CLIENT_ID"
def on_connect(client, userdata, flags, reason_code, properties):
print(f"Connected: {reason_code}")
def on_disconnect(client, userdata, flags, reason_code, properties):
print(f"Disconnected: {reason_code}")
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=CLIENT_ID,
protocol=mqtt.MQTTv5,
)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect(HOST, PORT, keepalive=60)
client.loop_start()
try:
while True:
reading = {"temp_c": round(random.uniform(20, 25), 2), "ts": int(time.time())}
info = client.publish("sensors/room1/temperature", json.dumps(reading), qos=1)
info.wait_for_publish()
print("Published", reading)
time.sleep(5)
except KeyboardInterrupt:
pass
finally:
client.loop_stop()
client.disconnect()
Si vous voulez simplement expérimenter sans vous inscrire, utilisez le serveur MQTT public gratuit sur le port 1883, supprimez les identifiants, utilisez n'importe quel client ID unique et non vide ainsi qu'un préfixe de topic unique comme connectmq/demo/a7f3k2/.... N'oubliez pas que l'espace public est lisible par tout le monde et réservé aux tests et aux prototypes : n'y envoyez jamais de données réelles ou de production.
Étape 5 : suivre l'utilisation dans le tableau de bord
Le tableau de bord du portail affiche l'activité de votre broker, et la vue des appareils regroupe les clients par niveaux ISA-95 lorsque vos topics suivent cette structure. Vous pouvez aussi définir des règles d'alerte à seuil (par exemple, température supérieure à 30) et consulter les alertes déclenchées dans le journal des alertes.
Conseils de conception pour rester dans les quotas
- Réutilisez les connexions. Une passerelle qui agrège dix capteurs BLE sur une seule connexion MQTT occupe un emplacement, pas dix.
- Fermez les tableaux de bord inutilisés. Les onglets de navigateur en WebSocket comptent comme des connexions tant qu'ils sont ouverts.
- Utilisez les retained messages pour l'état. Publier la dernière valeur connue en retained permet aux nouveaux abonnés de lire l'état courant instantanément, sans interrogation périodique.
- Choisissez un keep alive raisonnable. 30 à 60 secondes est la norme. Des intervalles très courts gaspillent du trafic ; des intervalles très longs retardent la détection des déconnexions.
- Gérez les reason codes. Journalisez les reason codes de CONNACK et DISCONNECT pour qu'un refus lié à un quota apparaisse clairement dans vos logs.
- Utilisez des client ID uniques. Deux appareils partageant le même ID vont s'éjecter mutuellement en boucle ; c'est de loin la cause la plus fréquente du problème « mon client n'arrête pas de se reconnecter ».
Aller au-delà du serverless
Dépasser le palier gratuit est un bon problème. Le parcours type est le suivant : Serverless (Free) pour le développement, Serverless (Paid) pour un premier produit avec jusqu'à 1 000 connexions et les shared subscriptions, puis Dedicated quand vous voulez un cluster isolé. Comme tout repose sur MQTT 3.1.1 et 5.0 standard, changer de palier signifie mettre à jour le nom d'hôte et les identifiants, pas réécrire la logique du firmware. Pour une vue d'ensemble des options d'hébergement, lisez notre guide du broker MQTT cloud, et consultez comment choisir un broker MQTT pour l'IoT pour une grille d'évaluation.
Lancez votre broker Serverless sur ConnectMQ
Vous pouvez créer un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Choisissez le plan Serverless (Free), créez un broker, copiez les identifiants générés et exécutez le script Python ci-dessus. En quelques minutes, vos appareils publieront en TLS, avec un explorateur de topics, un tableau de bord et des règles d'alerte pour les surveiller, pendant que le fournisseur gère le cluster.
Questions fréquentes
Un broker MQTT serverless est-il assez sûr pour la production ?
Oui, pour de nombreuses charges. Le trafic est chiffré en TLS, les identifiants sont propres à chaque client et les client ID y sont liés ; optez pour un déploiement dédié ou BYOC si votre politique interdit l'infrastructure partagée.
Que se passe-t-il quand je dépasse la limite de connexions ?
Le broker refuse la connexion supplémentaire. Les clients MQTT 5 reçoivent un reason code tel que quota exceeded, ce qui vous permet de le journaliser et de réagir au lieu de deviner.
Puis-je utiliser les fonctionnalités de MQTT 5 sur le palier gratuit ?
Oui. MQTT 3.1.1 et 5.0 sont tous deux pris en charge, y compris les retained messages, l'expiration de session, l'expiration des messages et les topic aliases ; la QoS est plafonnée à 1 et les shared subscriptions nécessitent le plan serverless payant.
Dois-je modifier le code de mes appareils pour changer de plan ?
Généralement non. Changer de plan modifie les quotas, et passer à un broker dédié implique en général de mettre à jour le nom d'hôte et les identifiants, tandis que la logique MQTT reste identique.
Le serveur MQTT public gratuit est-il la même chose qu'un broker serverless ?
Non. Le serveur MQTT public gratuit broker.connectmq.com accepte les connexions anonymes et tout y est lisible par n'importe qui, alors qu'un broker serverless vous donne des identifiants privés et authentifiés ainsi que vos propres quotas.
