Comparatif des brokers MQTT open source : Mosquitto, EMQX, VerneMQ et NanoMQ

Ce comparatif des brokers MQTT open source examine quatre projets largement utilisés, Eclipse Mosquitto, EMQX, VerneMQ et NanoMQ, du point de vue de quelqu'un qui doit les exploiter. Vous découvrirez les points forts de chaque broker, ce qu'il vous coûte en effort d'exploitation et comment lancer chacun localement en quelques minutes. À la fin, vous devriez savoir lequel convient à votre projet, ou s'il vaut mieux confier l'exploitation à un broker MQTT managé.

Pourquoi comparer les brokers MQTT open source ?

Tout déploiement MQTT a besoin d'un broker : le serveur qui accepte les connexions, authentifie les clients et achemine chaque message publié vers tous les abonnés correspondants. Pour un rappel de ce rôle, lisez le rôle d'un broker MQTT. Le protocole est standardisé : n'importe quel client conforme peut dialoguer avec n'importe quel broker conforme. Ce qui diffère d'un broker à l'autre, c'est tout ce qui entoure le protocole : la montée en charge, le stockage des sessions, la configuration de l'authentification, le comportement lors des mises à jour et le temps qu'ils vous demandent.

Les quatre projets ci-dessous sont matures, utilisés en production quelque part et implémentent MQTT 3.1.1 et MQTT 5.0. Aucun n'est « le meilleur » dans l'absolu. Le bon choix dépend du nombre de connexions, du besoin ou non de clustering, de ce que votre équipe connaît déjà et des conditions de licence acceptées par votre organisation.

Les quatre brokers en un coup d'œil

Eclipse Mosquitto

Mosquitto est le point de référence par lequel la plupart des gens commencent. Il est écrit en C, maintenu au sein de la fondation Eclipse, et suffisamment léger pour tourner sur un Raspberry Pi ou dans un conteneur avec quelques mégaoctets de mémoire. La configuration tient dans un seul fichier texte, l'authentification passe par un fichier de mots de passe ou le plugin de sécurité dynamique, et le bridging permet à une instance Mosquitto de relayer des topics vers un autre broker.

La principale limite architecturale est que Mosquitto fonctionne sur un seul nœud. Il n'y a pas de clustering intégré : la haute disponibilité implique un dispositif de bascule externe et une stratégie pour l'état des sessions. Pour un site unique, un laboratoire, une passerelle edge ou quelques milliers d'appareils sur un serveur bien dimensionné, c'est souvent tout à fait suffisant.

EMQX

EMQX repose sur Erlang/OTP et a été conçu dès le départ autour du clustering. Plusieurs nœuds forment un seul broker logique, ce qui permet de répartir de très grands nombres de connexions sur plusieurs machines. Il est livré avec un tableau de bord web, un système riche d'authentification et d'autorisation, ainsi qu'un moteur de règles et des intégrations de données parmi ses fonctionnalités. Un opérateur Kubernetes est disponible pour les déploiements en cluster.

La licence mérite votre attention : EMQX a changé de modèle de licence au fil des versions, et les conditions des dernières versions diffèrent de celles des anciennes versions open source. Lisez la licence actuelle sur le site d'EMQX et vérifiez qu'elle convient à votre usage avant d'en faire votre standard.

VerneMQ

VerneMQ repose lui aussi sur Erlang et propose un clustering sans maître, des hooks de plugins pour l'authentification et l'autorisation, et des fonctionnalités comme les mountpoints pour séparer les espaces de topics. Le code source est publié sous licence Apache 2.0. Ses paquets précompilés et images de conteneur officiels ont leurs propres conditions (l'image Docker vous demande d'accepter un EULA via une variable d'environnement) : vérifiez donc quelle distribution vous utilisez. Comme pour tout projet, examinez l'activité récente des versions et les canaux de support de la communauté avant de vous engager.

NanoMQ

NanoMQ, de l'équipe EMQ, est un broker léger écrit en C au-dessus de la bibliothèque de messagerie NNG. Il cible les appareils edge et les passerelles : faible empreinte, performances multi-threads sur du matériel modeste et bridging vers un broker amont. C'est un choix naturel quand vous voulez un broker local sur un PC industriel ou une passerelle qui relaie certains topics vers un broker central ou cloud.

Tableau comparatif des fonctionnalités et de l'exploitation

Le tableau résume l'architecture et les caractéristiques d'exploitation typiques. Vérifiez toujours les détails dans la documentation actuelle de chaque projet, car les fonctionnalités évoluent d'une version à l'autre.

Deux constats ressortent. D'abord, les brokers mono-nœud sont plus simples à exploiter mais vous obligent à résoudre vous-même la disponibilité. Ensuite, les brokers en cluster résolvent la disponibilité et la montée en charge mais ajoutent des pièces mobiles : découverte des nœuds, partitions réseau, mises à jour progressives et supervision consciente du cluster.

Testez chaque broker localement avec Docker

Le moyen le plus rapide de se faire une opinion est de lancer chaque broker et d'y connecter un client. Les commandes ci-dessous sont réservées aux tests locaux, avec l'accès anonyme activé. N'exposez pas ces configurations sur Internet.

# Mosquitto 2.x a besoin d'un listener explicite pour accepter les connexions hors localhost
mkdir -p mosquitto/config
cat > mosquitto/config/mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
EOF
docker run -d --name mosquitto -p 1883:1883 \
  -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto:2

# EMQX (tableau de bord sur http://localhost:18083)
docker run -d --name emqx -p 1884:1883 -p 18083:18083 emqx/emqx:latest

# VerneMQ (acceptez l'EULA de l'image et autorisez l'accès anonyme pour un test local)
docker run -d --name vernemq -p 1885:1883 \
  -e DOCKER_VERNEMQ_ACCEPT_EULA=yes \
  -e DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on vernemq/vernemq

# NanoMQ
docker run -d --name nanomq -p 1886:1883 emqx/nanomq:latest

Exécutez ensuite le même test de publication et d'abonnement sur chaque port :

for port in 1883 1884 1885 1886; do
  mosquitto_sub -h localhost -p $port -i sub-$port -t 'test/compare' -C 1 -W 5 &
  sleep 1
  mosquitto_pub -h localhost -p $port -i pub-$port -t 'test/compare' -m "hello from $port"
  wait
done

Chaque abonné doit afficher un message puis se terminer. Une fois que cela fonctionne, la partie intéressante commence : activez l'authentification, ajoutez TLS, redémarrez le conteneur pendant qu'un client détient une session persistante, et observez ce qui survit. Cet exercice vous en apprend davantage sur l'exploitation au quotidien que n'importe quelle liste de fonctionnalités.

Ce que la liste de fonctionnalités ne dit pas

TLS et certificats

Tous les brokers prennent en charge TLS, mais quelqu'un doit obtenir les certificats, les renouveler avant expiration et recharger le broker sans déconnecter tous les appareils. L'automatiser avec des outils ACME est tout à fait faisable, et c'est aussi une source classique de pannes lorsqu'une tâche de renouvellement échoue silencieusement.

Mises à jour et connexions de longue durée

Les connexions MQTT durent des jours, voire des mois. Redémarrer un broker mono-nœud déconnecte tous les clients d'un coup, et tous se reconnectent au même moment. Les brokers en cluster peuvent appliquer les mises à jour nœud par nœud, mais les clients du nœud redémarré se reconnectent malgré tout. Prévoyez un délai de reconnexion aléatoire côté appareil, quel que soit le broker choisi.

Supervision et capacité

Vous devez surveiller le nombre de connexions, les débits de messages, les messages perdus, la mémoire et les descripteurs de fichiers. Mosquitto publie ses statistiques dans les topics $SYS/ ; les brokers en cluster exposent des API HTTP et des endpoints de métriques. Dans tous les cas, c'est à vous de construire les tableaux de bord et les règles d'alerte. Notre guide de supervision d'un broker MQTT liste les métriques à suivre.

Opérations de sécurité

Les ports MQTT exposés attirent rapidement les scanners. Le durcissement consiste à désactiver l'accès anonyme, limiter les tentatives de connexion échouées, maintenir à jour le broker et l'image de base, et revoir la configuration après chaque mise à jour. L'article sur les bonnes pratiques de sécurité MQTT couvre le côté client de la question.

Comment choisir entre eux

Utilisez ces questions comme fil de décision :

1. Combien de connexions simultanées prévoyez-vous dans deux ans ? Si un seul serveur bien dimensionné les couvre largement, Mosquitto vous simplifie la vie. Sinon, tournez-vous vers les options en cluster.
2. Avez-vous besoin du broker en edge ? Pour les passerelles et les PC industriels, Mosquitto ou NanoMQ sont des choix naturels, généralement avec un bridge vers un broker central.
3. La haute disponibilité est-elle une exigence ferme ? Dans ce cas, exploitez un broker en cluster ou concevez une bascule externe pour un broker mono-nœud, y compris le sort des sessions persistantes.
4. Quelles conditions de licence votre organisation peut-elle accepter ? Lisez la licence actuelle de la version et de la distribution exactes que vous déploierez.
5. Qui sera d'astreinte ? Un broker est une infrastructure. Si personne dans l'équipe ne veut prendre en charge les correctifs, les certificats et les alertes de 3 heures du matin, tenez-en compte dès maintenant.

Si la cinquième question vous fait hésiter, comparez l'effort à l'aide d'une analyse broker MQTT auto-hébergé ou managé avant de décider.

Quand un broker MQTT managé est plus pertinent

Les brokers open source sont d'excellents logiciels. Le coût de leur exploitation tient surtout au temps humain : mise en place de TLS, construction de la supervision, gestion des mises à jour, réglage des limites et réponse aux incidents. Pour de nombreuses équipes IoT, ce temps est mieux investi dans les appareils et les applications.

Un broker MQTT managé transfère ces tâches au fournisseur. Avec ConnectMQ, vous créez un broker dans le portail et recevez un nom d'utilisateur, un mot de passe et un client ID. Les endpoints sont prêts en TCP 1883, TLS 8883, WebSocket 8083 et Secure WebSocket 8084 (chemin /mqtt) avec un certificat Let's Encrypt, et les clients MQTT 3.1.1 comme MQTT 5.0 fonctionnent sans modification. MQTT étant un standard, le même code client que vous avez testé avec Mosquitto ou EMQX se connecte à ConnectMQ en changeant l'hôte, le port et les identifiants.

ConnectMQ ajoute aussi des outils que vous devriez sinon assembler vous-même : un client MQTT dans le navigateur, un explorateur de topics en direct, un tableau de bord, une vue des appareils organisée par niveaux ISA-95 et des règles d'alerte sur seuil avec journal des alertes. Les plans vont d'une offre Serverless (Free) sur un cluster mutualisé à des clusters isolés Dedicated, jusqu'au BYOC dans votre propre compte cloud, si bien que le modèle d'hébergement peut suivre vos exigences. Le guide du broker MQTT cloud explique comment ces modèles se comparent.

Un schéma judicieux est l'hybride : gardez Mosquitto ou NanoMQ en edge pour la résilience locale, et relayez certains topics vers un broker hébergé utilisé par vos applications cloud et vos tableaux de bord.

Testez un broker hébergé en quelques minutes

Avant de choisir, pointez votre client existant vers un broker hébergé et comparez l'expérience avec vos conteneurs locaux. Le serveur MQTT public gratuit broker.connectmq.com ne nécessite aucun compte et sert aux tests et aux prototypes, pas aux données de production ; utilisez un client ID et un préfixe de topic uniques, et rappelez-vous que les topics publics sont lisibles par tous.

mosquitto_sub -h broker.connectmq.com -p 1883 -i cmp-sub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -v &
mosquitto_pub -h broker.connectmq.com -p 1883 -i cmp-pub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -m 'hello from the comparison test'

Pour des données de production, créez un broker privé et connectez-vous en TLS sur le port 8883 avec vos propres identifiants.

Démarrez avec ConnectMQ

Si vous préférez consacrer votre temps aux appareils et aux applications plutôt qu'à l'exploitation d'un broker, créez un broker Serverless (Free) sur app.connectmq.com. Aucune carte bancaire n'est requise, et vous pourrez passer plus tard à Dedicated ou BYOC sans modifier votre code client MQTT.

Questions fréquentes

Quel broker MQTT open source est le meilleur pour débuter ?

Mosquitto est généralement le point de départ le plus simple. Il s'installe en quelques minutes, utilise un seul fichier de configuration lisible et est documenté dans d'innombrables tutoriels.

Mosquitto peut-il fonctionner en cluster ?

Pas nativement. Mosquitto fonctionne sur un seul nœud ; vous pouvez relier des instances par bridge ou construire une bascule externe, mais pour un véritable cluster multi-nœuds, il faut se tourner vers un broker conçu pour le clustering.

EMQX est-il toujours open source ?

La licence d'EMQX a changé au fil des versions : la réponse dépend donc de la version que vous déployez. Vérifiez la licence publiée avec la version exacte que vous comptez utiliser.

Puis-je passer plus tard d'un broker open source à un broker MQTT managé ?

Oui. MQTT est un standard : les clients n'ont généralement besoin que d'un nouvel hôte, d'un nouveau port et d'identifiants. Passez en revue les fonctionnalités propres au broker dont vous dépendez, comme les moteurs de règles ou les plugins, car elles ne migrent pas automatiquement.