Qui a inventé MQTT ? Des oléoducs à l'IoT

Qui a inventé MQTT ? Andy Stanford-Clark, d'IBM, et Arlen Nipper, d'Arcom Control Systems, l'ont conçu en 1999 pour surveiller des oléoducs via de coûteuses liaisons satellite. Cet article suit MQTT depuis cette niche industrielle jusqu'à un standard ouvert OASIS et ISO devenu le protocole de référence de l'IoT, et explique comment les objectifs de conception d'origine façonnent encore aujourd'hui votre façon de l'utiliser.

Le problème en 1999 : oléoducs, satellites et bande passante

À la fin des années 1990, les exploitants pétroliers et gaziers devaient collecter la télémétrie d'équipements de pipelines isolés : pressions, débits, positions de vannes, états des pompes. De nombreux sites ne disposaient d'aucun réseau terrestre ; les données transitaient donc par des liaisons satellite lentes, intermittentes et facturées à l'octet. Les approches existantes interrogeaient chaque appareil selon un calendrier fixe, gaspillant de la bande passante pour des valeurs inchangées et peinant dès que la liaison tombait.

Deux ingénieurs ont abordé le problème sous des angles différents :

Andy Stanford-Clark, chez IBM, qui travaillait sur les middlewares de messagerie et s'intéressait de près à l'informatique ubiquitaire.
Arlen Nipper, chez Arcom Control Systems (intégrée plus tard à Eurotech), qui apportait une solide expérience du SCADA et du matériel embarqué acquise sur le terrain.

Ensemble, ils ont conçu un protocole qui n'enverrait les données qu'en cas de changement, survivrait à des liaisons peu fiables et fonctionnerait sur du matériel modeste.

Les objectifs de conception d'origine

Les objectifs qu'ils se sont fixés ressemblent à une checklist IoT moderne :

Simple à implémenter sur de petits appareils à la mémoire et au processeur limités.
Surcoût minimal, pour que chaque octet transmis par satellite transporte des données utiles.
Publish/subscribe, pour que les appareils distants n'aient pas besoin de savoir qui consomme leurs données.
Niveaux de qualité de service, pour que l'émetteur puisse arbitrer entre fiabilité et bande passante pour chaque message.
Tolérance à la connectivité intermittente, y compris un moyen de prévenir tout le monde lorsqu'un appareil se déconnecte de façon inattendue.
Indépendance vis-à-vis des données, avec la possibilité de transporter n'importe quel format de payload sans que le protocole s'en préoccupe.

Chaque objectif correspond directement à des fonctionnalités que vous utilisez encore : l'en-tête fixe minimal de deux octets, le modèle publish/subscribe centré sur le broker, les QoS 0/1/2, le keep-alive et le Last Will, ainsi que les payloads opaques.

Que signifie MQTT ?

Le « MQ » venait de la famille de produits de messagerie MQSeries d'IBM, et le protocole s'appelait à l'origine MQ Telemetry Transport. Ce nom a semé la confusion pendant des années, car MQTT n'est pas une file de messages au sens de MQSeries. Lors de sa standardisation, le nom est devenu simplement « MQTT », qui n'est plus officiellement considéré comme un acronyme.

Chronologie de MQTT : qui a inventé MQTT et ce qui a suivi

Année	Étape
1999	Andy Stanford-Clark et Arlen Nipper créent la première version pour la télémétrie des pipelines
Années 2000	IBM utilise MQTT en interne et dans ses produits de messagerie ; l'adoption progresse dans l'industrie et l'énergie
Fin des années 2000	MQTT-S (devenu MQTT-SN) est spécifié pour les réseaux de capteurs sans TCP
2010	IBM publie MQTT 3.1 libre de redevances, permettant à chacun de l'implémenter
Début des années 2010	Apparition de clients et de brokers open source, dont Eclipse Paho et Mosquitto
2013	OASIS crée un comité technique MQTT pour standardiser le protocole
2014	MQTT 3.1.1 devient un standard OASIS
2016	MQTT 3.1.1 est publié comme norme internationale ISO/IEC 20922
À partir de 2016	Sparkplug, initié par Cirrus Link (cofondée par Arlen Nipper), ajoute des conventions industrielles au-dessus de MQTT, puis rejoint la fondation Eclipse
2019	MQTT 5.0 devient un standard OASIS, avec notamment les reason codes, l'expiration de session et les abonnements partagés

Les documents de spécification sont disponibles auprès du comité OASIS et résumés sur mqtt.org.

Du propriétaire à l'ouvert : pourquoi 2010 a marqué un tournant

Pendant sa première décennie, MQTT est resté essentiellement une technologie IBM. La publication de la spécification 3.1 libre de redevances en 2010 a tout changé. Les développeurs pouvaient désormais écrire des clients et des brokers sans se soucier des licences, et ils ne s'en sont pas privés :

Eclipse Paho a fourni des bibliothèques clientes dans de nombreux langages, offrant aux développeurs un point de départ commun.
Mosquitto, un broker open source léger, a rendu trivial le fait d'exécuter MQTT sur un ordinateur portable ou un Raspberry Pi.
Les amateurs et les startups l'ont adopté pour la domotique et les produits connectés, en le découvrant souvent au travers de projets Arduino et Linux.

Ce moment coïncidait avec l'essor des microcontrôleurs Wi-Fi bon marché et des smartphones. Un protocole conçu pour les liaisons satellite s'est révélé idéal pour les capteurs sur batterie et les applications mobiles sur des réseaux cellulaires capricieux.

Standardisation : OASIS et ISO

Les implémentations ouvertes ont créé une dynamique, mais les entreprises voulaient un standard indépendant des fournisseurs. IBM et d'autres ont porté MQTT devant OASIS, où un comité technique a fait évoluer la version 3.1 vers MQTT 3.1.1, en clarifiant les zones ambiguës tout en restant compatible en pratique. Elle est devenue un standard OASIS en 2014 et a été adoptée par l'ISO/IEC sous la référence 20922 en 2016.

Le comité s'est ensuite attaqué aux enseignements tirés des grands déploiements. MQTT 5.0, approuvé en 2019, a conservé le modèle de base tout en ajoutant ce qui manquait aux exploitants : des reason codes pour diagnostiquer les échecs, l'expiration des sessions et des messages, les abonnements partagés pour l'équilibrage de charge, les topic aliases, les user properties et les métadonnées de requête/réponse. Notre présentation des fonctionnalités de MQTT 5 détaille chaque ajout.

Idées reçues sur les origines de MQTT

Quelques mythes reviennent régulièrement sur les forums et en entretien :

« MQTT a été conçu pour l'Internet des objets. » Le terme IoT existait à peine en 1999. MQTT a été conçu pour la télémétrie industrielle et n'est devenu que plus tard le protocole IoT de référence.
« MQTT est une file de messages. » Le MQ du nom d'origine désigne une famille de produits, pas une sémantique de file. Chaque abonné correspondant reçoit sa propre copie d'un message.
« MQTT a toujours été ouvert. » Il est resté propriétaire pendant une dizaine d'années avant sa publication libre de redevances en 2010.
« MQTT 5 a remplacé 3.1.1. » Les deux restent largement utilisés, et la plupart des brokers prennent en charge les deux côte à côte.

Pourquoi la conception d'origine compte encore

Beaucoup des bonnes pratiques actuelles ne sont que les exigences de 1999 sous de nouveaux habits :

Gardez des connexions de longue durée. MQTT suppose une liaison persistante et amortit le coût d'établissement sur de nombreux messages.
Publiez sur changement, pas sur minuterie, lorsque la bande passante ou la batterie sont précieuses.
Utilisez le Last Will pour la présence, exactement l'exigence de « prévenir tout le monde quand un appareil décroche ».
Choisissez la QoS selon le type de message, en arbitrant entre fiabilité et coût comme l'entendaient les concepteurs.
Choisissez librement le format de payload, que ce soit JSON, Protobuf ou Sparkplug B.

Cette histoire explique aussi les limites de MQTT. Il n'a pas été conçu comme un journal durable ni comme une plateforme de traitement de flux ; c'est pourquoi les systèmes de production associent un broker à des bases de données, des historiens ou des moteurs de traitement de flux connectés en tant que clients.

Des brokers auto-hébergés au broker MQTT managé

Les premiers utilisateurs exploitaient leurs propres brokers sur leurs propres serveurs. C'est toujours possible, mais cela signifie que les correctifs, le renouvellement des certificats, la supervision et la montée en charge vous incombent. Une part croissante des équipes choisit désormais un broker MQTT managé et consacre son temps aux appareils et aux applications.

ConnectMQ est l'un de ces brokers MQTT dans le cloud. Il prend en charge MQTT 3.1.1 et 5.0, propose TLS sur le port 8883 et WebSocket sécurisé sur le port 8084, et inclut des fonctionnalités industrielles qui auraient plu aux origines du protocole, la surveillance de pipelines : détection des topics ISA-95 et Unified Namespace, et décodage Sparkplug B. Pour découvrir sans aucune configuration le protocole imaginé par ses inventeurs, connectez-vous au serveur MQTT public gratuit, réservé aux tests :

mosquitto_sub -h broker.connectmq.com -p 1883 -i history-sub-e41f \
  -t "connectmq/demo/e41f/pipeline/#" -v

mosquitto_pub -h broker.connectmq.com -p 1883 -i history-pub-e41f \
  -t "connectmq/demo/e41f/pipeline/station7/pressure" -m "42.7" -q 1

Une station distante publie une valeur, le broker la pousse vers chaque abonné intéressé, et personne n'interroge personne. C'est l'idée de 1999 en deux commandes. Pour aller plus loin, poursuivez avec le tutoriel MQTT ou découvrez où le protocole est utilisé aujourd'hui dans les cas d'usage MQTT par secteur.

Démarrez avec ConnectMQ

Découvrez MQTT tel que ses inventeurs l'ont voulu, sans faire tourner de serveur. Inscrivez-vous sur app.connectmq.com, créez un broker Serverless gratuit sans carte bancaire, et utilisez le client intégré au navigateur de ConnectMQ pour publier votre premier message en quelques minutes.

Questions fréquentes