Procotole MQTT : Websocket en mieux ?

Si vous faites du web depuis quelque temps, vous avez sûrement déjà utilisé des Websockets, et si c'est le cas, vous détestez sûrement ce protocole et son implémentation. Personnellement, je ne le trouve pas fiable, lourd à implémenter et pas du tout performant. C'est cette haine du Websocket qui m'a fait chercher de nouvelles solutions pour faire de la communication bilatérale entre un client et un serveur, et j'ai trouvé mon bonheur : le MQTT.
MQTT.png
Arthur.jpg
Arthur COMBE, JavaScript loverlogo Linkedin
JavaScript Lover & lead développeur sur des projets d'apps métiers depuis bientôt 10 ans ! Mis à jour le 1 Avr 2025

17+

ans
d'experience

60+

experts
techniques

100K

écoutes de notre podcast
logo Axopen

Qu'est-ce qu'un protocole de communication ?

Avant de plonger dans le MQTT, rappelons ce qu'est un protocole. En informatique, un protocole est simplement un ensemble de règles qui permettent à des machines de communiquer entre elles.Les plus connus sont HTTP, FTP, ou encore Websocket, mais il en existe des dizaines d'autres, chacun conçu pour répondre à des besoins spécifiques.

Voyez ça un peu comme une enveloppe que vous voulez envoyer à quelqu'un. Vous devez suivre des règles, sinon votre lettre n'arrivera jamais. C'est pareil avec un protocole informatique !

MQTT : une nouveauté de 2025 ? 
Pasted image 20250329123929.png

MQTT est un protocole de messagerie M2M (Machine to Machine) créé le siècle dernier, en 1999 plus précisement, pour l'industrie pétrolière. Il a été créé initialement pour des environnements où la bande passante est limitée et la fiabilité cruciale.

Publié en 2012 et standardisé en 2014, il est aujourd'hui devenu une référence dans le monde des objets connectés (appelé aussi IoT).

Ce qui fait la force de MQTT, c'est sa simplicité, sa légèreté et sa fiabilité, qui le rendent parfait pour des appareils à ressources limitées. Vous comprenez donc son utilisation dans l'IoT !

Comment fonctionne MQTT ?

Le modèle publish/subscribe

MQTT utilise un modèle de communication publish/subscribe, qui diffère fondamentalement du modèle requête/réponse utilisé par HTTP.

3 notions sont importante à comprendre :

  • Les clients : Ce sont tous les appareils qui communiquent via MQTT. Un client peut être un capteur, une application mobile, web, un serveur, etc.
  • Le broker : C'est l'élément central qui agit comme un intermédiaire entre les clients. Il reçoit tous les messages et les transmet aux clients concernés.
  • Les topics : Ce sont les canaux de communication. Un client publie un message sur un topic, et le broker le transmet à tous les clients abonnés à ce topic. 
    Pasted image 20250329124019.png

Par exemple, un capteur de température pourrait publier la température actuelle sur le topic /capteurs/temperature, et une application de tableau de bord pourrait s'abonner à ce topic pour capter cette information, et ainsi l'afficher.

Pour reprendre l'analogie de l'enveloppe, on peut voir le broker comme la poste, et les topics comme des journaux. Vous, le client, vous abonnez à un journal (un topic). Dès qu'un nouveau numéro sort, la poste (le broker) l'envoi à tous les clients abonnés à ce journal.

Les avantages de ce modèle de communication résident en plusieurs points

  • Une communication bilatérale. Un client peut autant envoyer que recevoir.
  • La simplicité. Pas besoin de créer des endpoints et de les administrer, on push simplement sur un topic, et le broker s'occupe du reste.
  • La fiabilité. Il existe plusieurs niveaux de fiabilité (QoS) que vous pouvez configurer, afin de s'assurer qu'un message arrive bien.
  • La performance.

Qualité de service (QoS)

Une des fonctionnalités les plus puissante de MQTT est sa gestion de la qualité de service (QoS). Il en existe 3 :

  • QoS 0 (At most once) : Le message est envoyé une seule fois et rien ne s'assure qu'il soit bien arrivé.
  • QoS 1 (At least once) : Le message est envoyé jusqu'à ce que sa livraison soit confirmée, ce qui peut entraîner des doublons.
  • QoS 2 (Exactly once) : Le message est arrivé 1 seule fois, ni plus, ni moins.

Comme vous pouvez vous en douter, plus vous choisirez une QoS élevée, plus le service sera gourmand en performance. Une QoS 2 demandera beaucoup d'aller-retours entre les clients et le broker, alors qu'une QoS 0 consiste en un envoi unique.

Il est donc important de bien choisir sa QoS en fonction de son utilisation. Si vous avez une application de tableau de bord pour des objets connectés, ce n'est pas la fin du monde si vous ne recevez pas 1 ou 2 valeurs de votre thermomètre.

MQTT vs Websocket : quelle différence ?

Techniquement parlant, ce ne sont pas 2 protocoles comparables. MQTT étant du M2M, et Websocket du web, il ne sont pas utilisés dans les même cas, et pourtant !

Si je vous parles du MQTT, c'est surtout car même s'il s'agit d'un protocole M2M, on peut l'utiliser dans le web ! Mais comme les navigateurs ne le supportent pas nativement, c'est possible grâce au "MQTT over WSS".

Pour faire simple, on a bien toute l'architecture du MQTT avec un broker et des topics, mais la partie transport vers les clients est gérée à travers du Websocket.

Toutefois, utiliser du MQTT dans le web à tout de même des avantages par rapport à Websocket :

  • La QoS : Comme expliqué plus haut, MQTT offre des garanties de livraison que Websocket n'a pas nativement.
  • Simplicité de développement : Une fois la connexion au broker établie, l'utilisation de MQTT est très intuitive.
  • File d'attente de messages : Si un client se déconnecte puis se reconnecte, le broker peut lui envoyer tous les messages qu'il a manqué.
  • Organisation par topics : La structure en topics permet d'organiser les communications de manière claire et hiérarchisée.

Un cas pratique : application de quiz en temps réel

Pour illustrer l'utilité de MQTT, prenons l'exemple d'une application de quiz en temps réel où plusieurs joueurs répondent à des questions sur leur smartphone, avec un autre écran qui gère le déroulement du quiz et les résultats.

Architecture traditionnelle avec WebSocket

Dans une architecture classique utilisant WebSocket, le serveur devrait maintenir la liste des connexions de chaque client (joueurs et écran) et gérer explicitement l'envoi de messages à chacun. 

Pasted image 20250401113125.png

Architecture avec MQTT

Avec MQTT, l'architecture devient plus élégante :

  • L'écran s'abonne au topic /player-join pour recevoir les joueurs qui se connectent.
  • Les joueurs s'abonnent au topic /next-question pour recevoir les nouvelles questions.
  • Les joueurs publient sur le topic /player-join lorsqu'ils se connectent.
  • 'écran publie les nouvelles questions sur /next-question.
  • Le seul appel que le joueur doit faire au serveur, est la réponse donnée à une question. 
    Pasted image 20250401111049.png

Cette architecture est plus découplée, plus facile à faire évoluer, et gère naturellement les déconnexions temporaires.

Comment implémenter MQTT dans vos projets

Si vous voulez essayer MQTT dans vos projets Web, voici quelques pistes :

Avec AWS IoT Core

AWSLe Cloud AWS (Amazon WebServices) est une plateforme de services cloud développée par le géant américain Amazon. offre un service MQTT intégré à IoT Core, qui est assez simple à utiliser :

  • Trouvez une bibliothèque client MQTT compatible avec AWS Cognito pour votre langage de programmation.
  • Authentifiez vous via Amazon Cognito (avec un certificat, anonymement ou avec un utilisateur).
  • Connectez votre client au broker AWS IoT Core en utilisant cette authentification.
  • Commencez à publier et à vous abonner à des topics !

Avec des brokers open source

Il existe aussi d'excellents brokers MQTT open source comme Mosquitto ou EMQX, que vous pouvez héberger vous-même.

Mon avis sur le protocole MQTT

MQTT est un protocole puissant qui, malgré sa simplicité, offre des fonctionnalités avancées pour créer des applications temps réel robustes.
Si vous développez des projets IoT ou des applications web nécessitant des communications en temps réel fiables, je vous encourage vraiment à l'essayer.