Brokers MQTT gratuits pour les tests : lequel choisir

Le bon broker MQTT gratuit pour les tests dépend de ce que vous testez. Pour une première vérification « mon code se connecte-t-il ? », un endpoint partagé comme broker.connectmq.com ou un sandbox public fonctionne en quelques secondes, sans inscription. Pour les tests automatisés, lancez un broker en local ou dans la CI. Dès qu'il est question d'identifiants, d'ACL ou de charge réaliste, utilisez un broker privé : des offres gratuites existent, et une instance managée privée est l'étape suivante.

Ce guide regroupe les options par type, indique leurs points forts et leurs limites, et propose une vérification d'une minute pour chacune.

Quatre types de brokers de test gratuits

Aucun n'est « le meilleur ». Un projet type en utilise deux ou trois : un endpoint partagé pendant l'écriture des premières lignes, un broker local en CI et un broker privé avant la mise en production.

1. Endpoints partagés et sandboxes publics

Ils ne demandent qu'un nom d'hôte. C'est le moyen le plus rapide de répondre à la question « mon code client est-il correct ? ».

L'endpoint partagé de ConnectMQ

broker.connectmq.com est l'endpoint partagé de ConnectMQ, un broker MQTT managé, prévu pour les tests rapides. Il parle MQTT 3.1.1 et MQTT 5 sur les ports habituels :

Comme c'est le même service qui fait tourner les instances privées, le code que vous testez ici — y compris les réglages TLS et WebSocket — est celui que vous pointerez plus tard vers votre propre broker en ne changeant que le nom d'hôte et les identifiants.

Brokers publics communautaires

• test.mosquitto.org — opéré par le projet Eclipse Mosquitto. Il propose des ports en clair, TLS et WebSocket, ainsi que des ports pour tester les certificats client et l'authentification ; le site les liste tous. C'est explicitement un serveur de test, qui peut être lent ou redémarré.
• broker.hivemq.com — le broker public de HiveMQ, avec TCP sur le 1883 et WebSockets. Pratique pour des démos dans le navigateur.
• broker.emqx.io — le broker public d'EMQX, avec des ports TCP, TLS, WebSocket et WebSocket sécurisé.

Tous sont partagés et anonymes : n'importe quel utilisateur peut lire ce que vous publiez s'il devine votre topic ou s'abonne avec un joker. La disponibilité et les limites dépendent de leurs opérateurs et peuvent changer sans préavis. Pour voir leur comportement côte à côte, consultez le comparatif des brokers MQTT publics.

Vérification en une minute

mosquitto_sub -h broker.connectmq.com -p 1883 -t 'testmqtt/free-test/#' -v

mosquitto_pub -h broker.connectmq.com -p 1883 -t 'testmqtt/free-test/hello' -m 'it works'

Si l'abonné affiche testmqtt/free-test/hello it works, votre chemin réseau, le port et vos outils client sont bons. Changez le nom d'hôte pour essayer un autre broker public. Pas de terminal sous la main ? Utilisez le client MQTT en ligne : il se connecte en WebSockets sécurisés directement depuis le navigateur.

Tester un broker gratuit dans le navigateur

2. Offres gratuites des services managés

Plusieurs services MQTT managés proposent une offre gratuite ou un quota gratuit : vous vous inscrivez et obtenez un broker privé avec vos propres identifiants et TLS. HiveMQ Cloud et EMQX Serverless sont des exemples connus ; il en existe d'autres, et les détails (plafond de connexions, quotas de messages, carte bancaire exigée ou non) varient selon le fournisseur et évoluent dans le temps, donc lisez les conditions actuelles sur leur site.

Les offres gratuites conviennent pour :

• tester l'authentification par nom d'utilisateur et mot de passe et les permissions par topic,
• tester TLS avec une vraie chaîne de certificats,
• un petit prototype ou un projet domotique avec quelques appareils.

Elles conviennent moins aux tests de charge (les quotas s'épuisent vite) et à tout ce qui exige des garanties. Quand le prototype devient un produit, l'étape habituelle est une offre payante ou une instance privée chez le même service, ce qui garde la configuration client identique.

3. Brokers locaux sous Docker ou en CI

Pour les tests automatisés, un broker que vous démarrez vous-même vaut mieux que n'importe quelle option hébergée : il est isolé, sans quotas, fonctionne hors ligne et disparaît après l'exécution.

cat > mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
EOF
docker run --rm -p 1883:1883 -v "$PWD/mosquitto.conf:/mosquitto/config/mosquitto.conf" eclipse-mosquitto:2

Mosquitto 2 n'écoute que sur localhost et refuse les clients anonymes tant que vous ne configurez pas de listener : d'où cette configuration de deux lignes. Générez-en une plus complète avec le générateur de mosquitto.conf, ou démarrez le broker depuis votre code de test avec Testcontainers.

Les brokers locaux ont un angle mort : ils ne montrent pas ce qui se passe sur un vrai chemin Internet — timeouts NAT, TLS depuis un appareil, proxys d'un réseau d'entreprise. Associez-les à au moins un test contre un broker distant.

Lequel utiliser ?

Si la vraie question est « public ou privé ? », brokers MQTT publics vs privés approfondit le sujet, et l'annuaire des brokers recense des options hébergées et auto-hébergées avec leurs protocoles et ports.

Erreurs à éviter

• Topics génériques. test/topic sur un broker public vous montrera les messages d'inconnus et faussera votre test. Utilisez toujours un préfixe unique.
• Client ID fixes. Si deux développeurs lancent le même exemple avec client_id="test", le broker déconnecte l'un quand l'autre se connecte. Utilisez le générateur de client ID ou ajoutez un suffixe aléatoire.
• Compter sur l'état retenu. D'autres utilisateurs peuvent écraser ou effacer les messages retenus sur un broker partagé. N'en dépendez pas d'une exécution de test à l'autre.
• Faire des benchmarks sur un sandbox. Les résultats reflètent le trafic de tous les autres, et des tests lourds peuvent vous valoir une limitation ou un blocage.
• Partir en production avec l'hôte de test. Mettez l'URL du broker dans la configuration, pas dans le code, pour que le passage du broker de test à la production ne soit qu'un changement de configuration.

Les brokers gratuits rendent la première heure de développement MQTT sans friction. Utilisez un endpoint partagé ou un sandbox public pour prouver que votre code fonctionne, un broker local pour garder des tests rapides et fiables, et un broker privé dès que des identifiants, des permissions ou du trafic réel entrent en jeu.

Questions fréquentes