Les meilleurs brokers MQTT comparés : Mosquitto vs EMQX vs HiveMQ vs managé

Tous les brokers MQTT routent les messages des éditeurs vers les abonnés, et tous les brokers sérieux prennent en charge MQTT 3.1.1 et 5. Les vraies différences se situent au niveau de la montée en charge, de l’exploitation et des licences : comment il se met en cluster, dans quel langage il est écrit, ce qu’il coûte à faire tourner et qui le maintient. Ce comparatif s’en tient à des faits connus et vérifiables — aucun benchmark inventé — et se termine par un guide pratique pour choisir.

Vous voulez juste essayer un broker tout de suite ? Notre liste de brokers publics propose des endpoints de test prêts à l’emploi, et vous pouvez vous connecter à chacun d’eux depuis le navigateur.

Se connecter à un broker public dans le navigateur

Les brokers MQTT en un coup d’œil

Pour une matrice détaillée fonctionnalité par fonctionnalité que vous pouvez filtrer, utilisez le comparatif interactif des brokers MQTT.

Eclipse Mosquitto

Mosquitto est le broker open source le plus utilisé et le choix par défaut pour les déploiements petits et moyens. Écrit en C, il tourne sans peine sur un Raspberry Pi ou une passerelle edge, et se configure avec un seul fichier texte. Il est livré avec les clients en ligne de commande mosquitto_pub et mosquitto_sub qu’utilisent la plupart des tutoriels MQTT.

• Points forts : empreinte minuscule, mise en place simple, maturité, paquets pour la plupart des distributions Linux et image Docker officielle.
• Limites : nœud unique — pas de clustering intégré ; vous pouvez relier des brokers par des bridges, mais les sessions ne sont pas partagées. L’authentification repose sur des fichiers ou des plugins.

Pour démarrer : installer Mosquitto, le générateur de mosquitto.conf et le broker public test.mosquitto.org.

EMQX

EMQX, développé par EMQ Technologies, est écrit en Erlang/OTP et conçu pour le clustering et un très grand nombre de connexions simultanées. Au-delà de MQTT, il inclut un moteur de règles de type SQL, des intégrations avec des bases de données et des plateformes de streaming, un tableau de bord web et des backends d’authentification et d’autorisation intégrés.

• Points forts : clustering natif, fonctionnalités riches prêtes à l’emploi, bonne observabilité, extras comme les stratégies d’abonnements partagés et le préfixe $queue.
• Limites : plus lourd à faire tourner et à exploiter que Mosquitto ; vérifiez la licence de la version déployée.

Essayez-le via le broker public EMQX.

HiveMQ

HiveMQ est un broker en Java fortement orienté entreprise. La HiveMQ Community Edition open source est un broker MQTT 3.1.1 et 5 complet pour un usage mono-nœud, avec un SDK d’extensions. Le clustering, la sécurité entreprise, la supervision et le support commercial font partie de HiveMQ Enterprise, et HiveMQ propose aussi un service cloud managé.

• Points forts : conforme à la spécification, bien documenté, support commercial et outillage solides pour les secteurs réglementés.
• Limites : le clustering exige l’édition commerciale ; la JVM consomme plus de mémoire que les brokers écrits en C.

Essayez-le via le broker public HiveMQ.

VerneMQ et NanoMQ

VerneMQ

VerneMQ est un broker sous licence Apache, écrit en Erlang, avec clustering intégré et support de MQTT 5. C’est une option solide si vous voulez du clustering open source sous licence permissive. Vérifiez le rythme actuel des releases du projet et la façon dont les paquets binaires officiels sont distribués avant de vous engager.

NanoMQ

NanoMQ, également d’EMQ, est un broker léger en C destiné aux appareils edge et aux passerelles. Il prend en charge MQTT 5, le bridging vers des brokers cloud et MQTT sur QUIC. Voyez-le comme un compagnon côté edge d’un broker central plutôt que comme son remplaçant.

Brokers MQTT managés et cloud

Un broker managé supprime le travail d’exploitation — correctifs, certificats TLS, supervision, sauvegardes et montée en charge — en échange d’un abonnement. Parmi les options :

• HiveMQ Cloud et EMQX Cloud — les versions hébergées des brokers ci-dessus.
• AWS IoT Core et Azure IoT Hub / Azure Event Grid — des endpoints MQTT intégrés à des plateformes IoT cloud plus larges. Ils s’intègrent aux services d’identité et de données de chaque cloud, mais utilisent une authentification propre à la plateforme et, dans certains cas, un sous-ensemble restreint des fonctionnalités MQTT ou des structures de topics imposées.
• ConnectMQ — un broker MQTT managé qui fournit des instances privées et isolées avec authentification par nom d’utilisateur/mot de passe, contrôle d’accès par topic, TLS et WebSockets sécurisés, et prise en charge de MQTT 3.1.1 et 5. Voir ConnectMQ dans notre liste de brokers.

Les services managés diffèrent surtout par leur modèle de tarification, leurs limites de connexions et de messages, les fonctionnalités MQTT 5 qu’ils exposent, et par le fait qu’ils utilisent une authentification standard par nom d’utilisateur/mot de passe ou des schémas d’identité propriétaires. Comparez-les à vos besoins plutôt qu’aux arguments marketing.

Comment choisir un broker MQTT

1. Apprentissage, prototypage ou domotique : Mosquitto sur un Raspberry Pi ou dans Docker, ou un broker de test public gratuit. Voir Home Assistant MQTT pour une configuration courante.
2. Passerelles edge : Mosquitto ou NanoMQ, reliés par bridge à un broker central.
3. Production en haute disponibilité sur votre propre infrastructure : un broker avec clustering comme EMQX, VerneMQ ou HiveMQ Enterprise — et une équipe à l’aise pour l’exploiter.
4. Intégration poussée avec un fournisseur cloud : le service IoT de ce fournisseur, si son sous-ensemble de fonctionnalités MQTT convient à vos appareils.
5. Production sans gérer de serveurs : un broker managé avec MQTT standard, TLS et des identifiants par appareil.

Quel que soit votre choix, vérifiez ces points avant de vous engager :

• Les fonctionnalités du protocole dont vous dépendez : propriétés MQTT 5, abonnements partagés, messages retenus, limites de taille des messages. Voir MQTT 5 vs 3.1.1.
• Les transports : TCP, TLS et WebSockets pour les clients navigateur — voir les ports MQTT.
• La sécurité : authentification, ACL par topic et TLS. Nos bonnes pratiques de sécurité MQTT listent ce qu’il faut rechercher.
• L’exploitation : supervision, mises à jour, sauvegardes et qui est réveillé la nuit.

Testez avant de décider

Quels que soient les brokers retenus, soumettez-les tous aux mêmes vérifications : connectez-vous via chaque transport dont vous avez besoin, vérifiez la QoS et les messages retenus, et confirmez que votre configuration d’authentification fonctionne. Notre guide comment tester un broker MQTT détaille la démarche étape par étape.

Questions fréquentes