Commande confirmée, livreur à deux arrêts, alerte de prix déclenchée : votre backend publie l’événement une fois, et chaque onglet de navigateur et appli mobile abonné le reçoit aussitôt en MQTT sur WebSockets sécurisés — sans polling ni serveur de sockets maison.
Aucune carte bancaire requise
PUBLISH orders/ord-58213/status
{"status":"out_for_delivery","eta":"14:35","stops_away":2,"courier":"c-221","ts":"2026-10-22T14:02:51Z"}QoS 1 · TLS 8883 · PUBACK
Les applis qui interrogent une API toutes les quelques secondes chargent votre backend et restent lentes. Un service WebSocket maison, c’est écrire soi-même la reconnexion, le fan-out et la montée en charge — et l’utilisateur qui passe du Wi-Fi à la 4G manque quand même la mise à jour qui comptait.
Le service de commandes, le système de dispatch ou le job d’alertes publie un petit événement JSON sur un topic comme orders/{id de commande}/status à chaque changement.
Les applis web se connectent avec MQTT.js via WebSockets sécurisés, les applis mobiles avec un client MQTT natif, et s’abonnent aux topics de l’utilisateur.
ConnectMQ livre chaque événement à tous les clients abonnés en même temps : le téléphone du client, son onglet ouvert et la console de votre support.
L’appli fait avancer le suivi de commande, met à jour un badge ou affiche une bannière. Pour les applis fermées, votre service de push continue d’envoyer via APNs et FCM.
MQTT sur WebSockets sécurisés permet au navigateur de se connecter directement au même broker que votre backend joint en MQTT avec TLS.
L’authentification par identifiant et mot de passe et les ACL par topic limitent chaque client à son arborescence, comme users/{id}/#, où seul votre backend peut publier.
Les messages retenus livrent le dernier statut de commande dès l’abonnement ; les sessions persistantes en QoS 1 livrent ce qui a été manqué pendant une courte coupure.
QoS 0 pour les positions fréquentes du livreur, où seule la dernière compte, QoS 1 pour les changements de statut et les alertes qui doivent arriver.
orders/ord-58213/status (retained)
orders/ord-58213/courier/location
users/u-90417/notifications
users/u-90417/badge (retained)Les deux : MQTT fonctionne sur WebSockets. Un WebSocket brut n’est qu’un tuyau ; il vous reste à construire topics, fan-out, reconnexions et garanties de livraison. MQTT sur WebSockets sécurisés ajoute publication/abonnement, QoS, messages retenus et Last Will, et ConnectMQ gère le côté serveur.
Pour les applis ouvertes ou au premier plan, oui : MQTT livre les mises à jour plus vite et avec plus de données. Appli fermée, iOS et Android limitent les connexions en arrière-plan : gardez APNs et FCM pour ces cas. Un schéma courant consiste à publier une fois et à laisser un petit service relayer certains événements en push.
Avec MQTT.js : connectez-vous à l’endpoint WebSockets sécurisés de ConnectMQ, abonnez-vous aux topics de l’utilisateur et mettez à jour l’état à chaque message. Ne livrez jamais dans le front-end un identifiant aux droits étendus : donnez aux clients navigateur des identifiants dont l’ACL n’autorise que la lecture de leurs propres topics.
Commencez avec l’offre Free, sans carte bancaire : connectez vos premiers équipements dès aujourd’hui et évoluez au moment du lancement.
