MQTT vs AMQP : différences, cas d'usage, performances

La question MQTT vs AMQP se pose dès qu'une équipe qui développe des appareils connectés exploite aussi des services backend sur un broker de messages comme RabbitMQ. Les deux protocoles reposent sur un broker, fonctionnent tous deux sur TCP et proposent tous deux des acquittements de livraison, mais ils ont été conçus pour des missions très différentes. Ce guide compare les modèles de broker, le routage, les garanties et l'empreinte côté client, et se termine par une règle pratique indiquant quand chacun a sa place dans votre architecture.

Les origines de chaque protocole

MQTT a été conçu pour la télémétrie d'équipements distants sur des liaisons peu fiables et à faible bande passante. Ses priorités sont un client minuscule, un format de paquet compact et un modèle simple : les clients publient sur des topics hiérarchiques et s'abonnent à l'aide de wildcards. C'est un standard OASIS, dont les versions 3.1.1 et 5.0 sont largement utilisées.

AMQP (Advanced Message Queuing Protocol) est issu du secteur financier, où la priorité était une messagerie fiable et interopérable entre systèmes métier. Il existe en deux lignées assez différentes. AMQP 0-9-1 est le modèle que la plupart des développeurs connaissent grâce à RabbitMQ, avec ses exchanges, ses bindings et ses files (queues). AMQP 1.0 est le standard OASIS et ISO, un protocole de transfert pair à pair plus général, utilisé par des services comme Azure Service Bus et pris en charge par des brokers comme Apache ActiveMQ Artemis. Quand quelqu'un dit « AMQP », il vaut la peine de demander lequel.

MQTT vs AMQP en un coup d'œil

Aspect	MQTT	AMQP 0-9-1 (style RabbitMQ)	AMQP 1.0
Modèle de base	Topics en publish/subscribe	Les exchanges routent vers des files via des bindings	Liens entre nœuds ; sémantique du broker définie par l'implémentation
Routage	Topics hiérarchiques, wildcards `+` et `#`	Exchanges direct, topic, fanout, headers	Adresses et filtres, spécifiques au broker
Files	Pas de files explicites (files de session par client)	Files explicites, nommées et durables	Nœuds définis par le broker
Garanties de livraison	QoS 0, 1, 2	Acks, publisher confirms, transactions	Modes de règlement, au plus une fois et au moins une fois
Répartition du travail	Abonnements partagés (MQTT 5)	Consommateurs concurrents sur une file	Récepteurs concurrents sur un nœud
Contrôle de flux	Receive maximum (MQTT 5)	Prefetch (basic.qos)	Contrôle de flux par crédits sur les liens
Taille des en-têtes	Très petite, en-tête fixe de 2 octets minimum	Trames et propriétés plus volumineuses	Encodage plus volumineux et richement typé
Empreinte client	Tient sur des microcontrôleurs	À l'aise sur serveurs et passerelles	À l'aise sur serveurs et passerelles
Terrain de prédilection	Appareils, passerelles, navigateurs, applications mobiles	Microservices backend, files de tâches	Intégration d'entreprise, services de messagerie cloud

Modèle de broker et routage

Un broker MQTT route uniquement par topic. Un éditeur envoie sur plant1/line2/press4/temperature, et chaque client dont le filtre d'abonnement correspond en reçoit une copie. Il n'y a pas de configuration de routage distincte ; la hiérarchie des topics constitue la table de routage. MQTT est ainsi facile à adopter et facile à appréhender, surtout lorsque les topics suivent une structure comme ISA-95 ou un Unified Namespace. L'article sur le modèle publish/subscribe de MQTT explique plus en détail ce découplage.

AMQP 0-9-1 sépare l'endroit où les messages sont envoyés (un exchange) de l'endroit où ils sont stockés (des files). Des bindings relient les deux selon des règles. Un exchange topic se comporte un peu comme les wildcards MQTT, un exchange fanout copie vers chaque file liée, et un exchange direct route selon une clé exacte. Cette flexibilité est puissante pour les workflows backend, par exemple pour diffuser un événement de commande vers des files de facturation, d'expédition et d'analyse, chacune avec sa propre rétention et ses propres consommateurs. Le prix à payer : davantage de concepts à apprendre et davantage de configuration à gérer.

Garanties de livraison

MQTT propose trois niveaux de QoS : au plus une fois (QoS 0), au moins une fois (QoS 1) et exactement une fois entre client et broker (QoS 2). Les sessions persistantes permettent au broker de conserver les messages QoS 1 et 2 pour un abonné temporairement hors ligne. Pour un rappel, consultez les niveaux de QoS MQTT expliqués.

AMQP vous offre les acquittements consommateur, les acquittements négatifs avec remise en file, les publisher confirms et, en 0-9-1, les transactions. Les messages restent dans une file durable jusqu'à ce qu'un consommateur les acquitte explicitement, ce qui est exactement ce qu'il faut pour des tâches comme « générer cette facture », qui doivent être traitées par un seul worker et retentées en cas d'échec.

En pratique, les deux peuvent livrer de façon fiable. La différence tient à l'orientation : MQTT est optimisé pour des flux d'état et d'événements vers de nombreux abonnés, AMQP pour des unités de travail durables traitées par des consommateurs concurrents.

Performances et empreinte

Aucun des deux protocoles n'est « plus rapide » dans l'absolu. Le débit dépend bien davantage de l'implémentation du broker, des réglages de persistance, de la taille des messages et du mode d'acquittement que du format sur le réseau.

Là où les protocoles diffèrent nettement, c'est l'empreinte. Une bibliothèque cliente MQTT tient sans difficulté sur un ESP32 ou un microcontrôleur similaire, et le surcoût par message est minime, ce qui compte sur les liaisons cellulaires et satellite. Les clients AMQP sont plus lourds, les trames transportent davantage de métadonnées et l'établissement de la connexion implique davantage de négociation. Sur un serveur, cette différence est sans importance ; sur un capteur alimenté par batterie, elle est décisive.

MQTT gère aussi très bien un grand nombre de connexions majoritairement inactives, ce qui est la forme normale d'une flotte IoT. Les brokers AMQP sont généralement optimisés pour des connexions moins nombreuses et plus actives, provenant de services.

Architectures types

Dans la réalité, la réponse la plus courante à MQTT vs AMQP est « les deux, à des niveaux différents » :

Les appareils, passerelles et tableaux de bord se connectent à un broker MQTT.
Un service backend s'abonne aux topics MQTT pertinents, par exemple plant1/+/+/telemetry.
Ce service valide et enrichit les données, puis publie des unités de travail dans une file AMQP pour un traitement en aval comme la facturation, la gestion de tickets ou les mises à jour de l'ERP.

Voici une passerelle minimale en Python qui s'abonne en MQTT et publie dans une file RabbitMQ avec pika. Elle s'exécute dans son propre processus : vous gardez donc la maîtrise du regroupement, du filtrage et de la gestion des erreurs.

import json
import uuid

import paho.mqtt.client as mqtt
import pika

PREFIX = "connectmq/demo/replace-me"

amqp = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = amqp.channel()
channel.queue_declare(queue="telemetry", durable=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("MQTT connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    try:
        body = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("skipping invalid payload on", msg.topic)
        return
    body["topic"] = msg.topic
    channel.basic_publish(
        exchange="",
        routing_key="telemetry",
        body=json.dumps(body),
        properties=pika.BasicProperties(delivery_mode=2),  # persistant
    )

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"amqp-bridge-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

En production, connectez-vous à votre broker privé en TLS sur le port 8883 avec client.tls_set() et client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"), et utilisez le client ID délivré avec ces identifiants. Comme la connexion bloquante de pika n'est pas thread-safe, gardez tous les appels AMQP dans le thread de la boucle réseau MQTT comme ci-dessus, ou confiez les messages à une file consommée par un thread AMQP dédié.

Quand choisir MQTT

Les clients sont des microcontrôleurs, des passerelles, des applications mobiles ou des navigateurs.
Les connexions sont peu fiables, facturées à l'usage ou à forte latence.
De nombreux consommateurs ont besoin du même flux de télémétrie ou d'état.
Vous avez besoin de détecter l'état en ligne/hors ligne (keep alive et Last Will) et de connaître les dernières valeurs (retained messages).
Vous voulez un modèle simple que les techniciens terrain et les intégrateurs comprennent à la seule lecture des noms de topics.

Quand choisir AMQP

Les messages sont des unités de travail qu'un seul consommateur doit traiter et acquitter.
Vous avez besoin de règles de routage sophistiquées, de dead-letter queues et de politiques par file.
Tous les producteurs et consommateurs sont des services backend dans un datacenter ou dans le cloud.
Vous intégrez des systèmes d'entreprise qui parlent déjà AMQP 1.0.

Pourquoi un broker MQTT managé est souvent la solution la plus simple

Côté appareils, la simplicité opérationnelle l'emporte généralement. Un broker MQTT managé supprime le travail de correctifs, de renouvellement des certificats, de montée en charge du nombre de connexions et d'isolation multi-tenant, et laisse votre équipe se concentrer sur la conception des topics et sur les consommateurs. ConnectMQ prend en charge MQTT 3.1.1 et 5.0, TLS avec un certificat Let's Encrypt, les abonnements partagés sur le plan Serverless payant et des quotas par plan avec protection contre les inondations de messages. Il n'inclut pas de passerelle AMQP : vous conservez donc la passerelle comme votre propre service, exactement comme ci-dessus. Pour comparer plus largement les options d'hébergement, lisez le guide du broker MQTT cloud, et pour un rappel sur les topics et les sessions, consultez le tutoriel MQTT. Si vous comparez files et brokers sur le plan conceptuel, broker MQTT vs file de messages va plus loin.

Démarrez avec ConnectMQ

Connectez vos appareils à ConnectMQ en MQTT et gardez AMQP pour les workflows backend dans lesquels il excelle. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, récupérez les identifiants générés et pointez-y vos appareils et votre service passerelle en quelques minutes. Pour un premier essai sans compte, le serveur MQTT public gratuit broker.connectmq.com suffit, à condition de le réserver aux tests et aux prototypes, jamais aux données de production.

Questions fréquentes

MQTT est-il meilleur qu'AMQP pour l'IoT ?

Pour les appareils, généralement oui : les clients MQTT sont plus petits, les paquets plus légers et le modèle gère bien de nombreuses connexions intermittentes. AMQP est mieux adapté aux files de travail backend.

RabbitMQ peut-il parler MQTT ?

RabbitMQ propose un plugin MQTT qui fait correspondre les topics MQTT à son modèle d'exchanges. Un broker MQTT dédié offre généralement une prise en charge plus complète des fonctionnalités MQTT et une exploitation plus simple pour les grandes flottes d'appareils.

MQTT a-t-il des files comme AMQP ?

Pas explicitement. Le broker conserve une file de session par client pour les sessions persistantes, et les abonnements partagés de MQTT 5 permettent à plusieurs consommateurs de se répartir les messages d'un topic, ce qui couvre de nombreux cas d'usage de type file.

Puis-je utiliser MQTT et AMQP ensemble ?

Oui, et c'est courant. Les appareils publient en MQTT, et un service passerelle s'abonne et transfère les messages sélectionnés vers des files AMQP pour le traitement backend.

MQTT vs AMQP : différences, cas d'usage et performances