Vos capteurs IoT et vos microservices parlent le même protocole — et c’est le même broker qui les connecte

Février 2026. Mosquitto 2.1.2 sort avec 11 000 étoiles GitHub et la réputation d’être le broker MQTT le plus déployé au monde. Juin 2026. EMQX 6.2.1 franchit les 16 400 étoiles et revendique 100 millions de connexions MQTT simultanées sur un cluster de 23 nœuds. Entre les deux, RabbitMQ 4.x adopte le moteur de consensus Khepri et NATS termine son incubation CNCF pour devenir le standard de messagerie cloud-native.

Trois protocoles, un même besoin : faire circuler des messages entre des machines qui ne se connaissent pas. Et en 2026, la frontière entre l’IoT et le backend a disparu.

MQTT : le protocole qui pèse 2 octets et connecte des milliards de capteurs

MQTT (Message Queuing Telemetry Transport) est né en 1999 chez IBM pour surveiller des pipelines pétroliers par satellite. Son cahier des charges : un en-tête fixe de 2 octets, une connexion TCP persistante, et trois niveaux de qualité de service qui permettent de choisir entre vitesse et fiabilité.

Le protocole est standardisé par OASIS depuis 2013. La version 5.0, finalisée en mars 2019, ajoute les abonnements partagés (plusieurs consommateurs sur le même topic), l’expiration des messages, et un modèle requête-réponse. Ces ajouts le rendent utilisable bien au-delà des capteurs — vos microservices peuvent parfaitement dialoguer en MQTT.

Le modèle est celui du publish/subscribe : un client publie sur un topic (usine/ligne4/presse/temperature), et tous les abonnés à ce topic reçoivent le message. Le broker centralise le routage. Pas de découverte de service, pas d’adresses IP à connaître.

Les trois niveaux de QoS structurent toutes les décisions d’architecture :

• QoS 0 — le message est envoyé une fois, sans accusé de réception. Pour la télémétrie où une mesure perdue n’est pas grave.
• QoS 1 — le message est retransmis jusqu’à réception d’un accusé. Le destinataire peut recevoir des doublons. C’est le niveau le plus utilisé en production.
• QoS 2 — handshake en quatre étapes garantissant une livraison exactement unique. Le surcoût est significatif, et il est rarement justifié hors transactions financières.

Le Last Will est une fonctionnalité souvent négligée qui rend MQTT précieux pour la supervision : chaque client peut enregistrer un message que le broker publiera automatiquement si la connexion est perdue. Un capteur qui se déconnecte déclenche immédiatement une alerte, sans polling.

Mosquitto vs EMQX : deux philosophies, un même protocole

Mosquitto est écrit en C, pèse quelques centaines de kilo-octets, et tourne sur un Raspberry Pi comme sur un serveur x86. Son architecture mono-thread le limite à environ 160 000 connexions simultanées et 120 000 messages par seconde en QoS 0. Pour 90 % des déploiements IoT, c’est largement suffisant. C’est le choix par défaut des industriels qui veulent un broker léger, déterministe et sans surprise.

EMQX est écrit en Erlang/OTP, adopte une architecture distribuée maître-less, et peut monter à 4 millions de connexions par nœud. Sa fonctionnalité signature : MQTT over QUIC, qui remplace TCP par le protocole UDP multiplexé de Google. Résultat : zéro head-of-line blocking, changement de réseau sans reconnexion (WiFi → 5G), et des temps d’établissement de connexion divisés par deux sur les liaisons à forte latence.

Le tableau ci-dessous résume l’écart :

CritèreMosquitto 2.1.2EMQX 6.2.1Connexions max par nœud~160 0004 000 000Messages/sec (QoS 0)120 0002 000 000Clustering natifNonOui (23+ nœuds)MQTT over QUICNonOuiLicenceEPL/EDLApache 2.0 (≤ v5.8), BSL 1.1 (≥ v5.9)Stars GitHub11 00016 400

La réalité du terrain : Mosquitto en edge, EMQX dans le cloud. Les deux se pontent en MQTT natif — un capteur publie sur un Mosquitto local, le bridge le relaie vers un cluster EMQX régional, et le tableau de bord central s’abonne sans savoir où le message est né.

AMQP : le protocole qui a bâti RabbitMQ

AMQP (Advanced Message Queuing Protocol) est un protocole de messagerie d’entreprise standardisé en 2011 par l’OASIS. Contrairement à MQTT qui ne connaît que les topics, AMQP introduit un modèle de routage à trois étages : les exchanges reçoivent les messages, les bindings définissent les règles de routage, et les queues stockent les messages en attente de consommation.

Un exchange peut router par clé de topic, par en-tête, en fanout (toutes les queues), ou en direct. Cette flexibilité fait d’AMQP le choix naturel pour l’intégration d’applications d’entreprise : un ERP qui publie un ordre de fabrication, un MES qui le consomme, un système de facturation qui reçoit une copie par fanout.

RabbitMQ est l’implémentation de référence d’AMQP. Sa version 4.x, sortie en 2025, abandonne le moteur de métadonnées historique (Mnesia) au profit de Khepri, un moteur de consensus inspiré de Raft. Le résultat : des partitions réseau résolues en secondes au lieu de minutes, et une stabilité de cluster qui manquait cruellement aux versions antérieures.

RabbitMQ supporte aussi MQTT 5.0 et STOMP via des plugins, ce qui en fait un hub multi-protocole capable de parler à un capteur en MQTT et à un backend Java en AMQP sur la même instance.

NATS : le nouveau venu qui bouscule tout le monde

NATS est un système de messagerie cloud-native créé par Derek Collison, l’architecte de la messagerie de TWS (le système de trading électronique). Sa philosophie : un binaire de moins de 10 Mo, zéro dépendance externe, et une latence inférieure à la milliseconde.

Trois propriétés différencient NATS des protocoles précédents :

• Clustering natif sans configuration. Un nœud NATS découvre automatiquement ses pairs. Monter un cluster de trois nœuds prend littéralement une ligne de commande par nœud.
• Superclusters. Plusieurs clusters géographiquement distants fusionnent en un espace de nommage global. Un message publié sur usine.paris.ligne4 est accessible depuis usine.singapour.ligne4 sans pont explicite.
• JetStream. La couche de persistance ajoutée en 2021 apporte la rétention configurable par sujet, les groupes de consommateurs, et la livraison exactly-once — le chaînon manquant qui empêchait NATS de concurrencer Kafka sur les workloads avec état.

NATS est sorti de l’incubation CNCF en 2024 et sa feuille de route 2026 met l’accent sur les Leaf Nodes pour l’edge computing : un nœud NATS déployé sur une passerelle industrielle accepte les connexions MQTT locales et les réplique vers le supercluster sans changements applicatifs.

Le tableau comparatif

CritèreMQTTAMQPNATSModèlePub/sub (topics)Routage (exchange/queue)Pub/sub (subjects)Latence< 5 ms5–50 ms< 1 msOverhead2 octets (en-tête fixe)Moyen (frames)Minimal (texte)PersistanceMessages retenusQueues avec TTLJetStream (rétention par sujet)QoS0, 1, 2Acks + dead-letterCore (at-most-once), JetStream (exactly-once)Idéal pourIoT, edge, contraintIntégration entrepriseCloud-native, edge-to-cloudBroker de référenceMosquitto, EMQXRabbitMQnats-server

Quel protocole pour quelle architecture en 2026 ?

La question n’est plus « lequel choisir » mais « dans quel ordre les déployer ». Une architecture réseau moderne combine deux ou trois de ces protocoles, chacun à l’étage où il excelle.

Niveau terrain — MQTT. Un capteur de température sur une chaîne de montage n’a ni la RAM ni la bande passante pour du HTTP. MQTT QoS 1 sur Mosquitto en edge, avec un bridge MQTT vers EMQX dans le cloud, c’est le golden path de l’IoT industriel en 2026. Ajoutez MQTT over QUIC si vos capteurs sont mobiles (véhicules, drones, AGV).

Niveau intégration — AMQP. Votre ERP SAP publie des ordres de fabrication. Votre MES les consomme. Votre système qualité reçoit une copie. Ce routage conditionnel complexe, avec files d’attente persistantes et dead-letter queues, c’est le terrain naturel d’AMQP sur RabbitMQ 4.x. N’essayez pas de le faire en MQTT — les topics hiérarchiques ne remplacent pas les exchanges à clé de routage.

Niveau infrastructure — NATS. Vous avez trois usines, deux datacenters et un cluster Kubernetes dans le cloud. NATS en supercluster unifie tout en un espace de nommage global, avec une latence inférieure à la milliseconde et zéro configuration de pont. C’est le choix des équipes plateforme qui veulent une messagerie qui se comporte comme un utilitaire système — apt install nats-server, une ligne de configuration, et ça tourne.

Le verdict. Si vous gérez un parc de capteurs fixes inférieur à 100 000 unités, déployez Mosquitto et ne cherchez pas plus loin. Si vos capteurs sont mobiles ou que vous dépassez le million de devices, montez un cluster EMQX avec MQTT over QUIC. Si vous intégrez des applications d’entreprise avec du routage complexe, RabbitMQ 4.x est l’outil qu’il vous faut. Et si vous construisez une plateforme multi-site pour vos microservices, NATS mérite d’être votre premier test — il n’y a pas plus simple à opérer.

Références

• MQTT Specification v5.0 — OASIS Standard, mars 2019
• EMQX vs Mosquitto — Features, Scalability, and Use Cases Compared, EMQX Blog, juin 2026
• Network Protocol Comparison 2026: DDS, MQTT, gRPC, Kafka, and Beyond, ZenDevy, avril 2026
• Message Broker Comparison in IIoT: MQTT, Kafka, AMQP or NATS, i-flow
• RabbitMQ 4.0 Release Notes — Khepri Metadata Store, RabbitMQ Blog, février 2025
• NATS — Cloud Native, Open Source, High-performance Messaging
• Eclipse Mosquitto — An Open Source MQTT Broker
• EMQX — The World’s #1 Open Source Distributed MQTT Broker