Un broker MQTT pour applications mobiles permet à un téléphone de voir les données d'un appareil dès qu'elles changent et de renvoyer des commandes avec très peu de surcoût. Ce guide explique comment les applications mobiles doivent se connecter, quand MQTT est le bon outil et quand ce sont les notifications push de la plateforme, comment limiter la consommation de batterie et comment gérer les identifiants en toute sécurité, avec un exemple fonctionnel sur le broker MQTT managé ConnectMQ.
Pourquoi les applications mobiles utilisent MQTT
Les applications IoT mobiles ont généralement besoin de trois choses : afficher l'état en direct (la porte d'une maison connectée est-elle verrouillée, quel est le niveau de la cuve), envoyer des commandes (allumer la pompe) et réagir rapidement aux changements. Interroger une API REST toutes les quelques secondes remplit mal ces trois missions : cela gaspille batterie et données, ajoute de la latence et charge votre backend. MQTT maintient une seule connexion de longue durée tant que l'application est active et ne pousse que ce qui a changé.
Le broker au milieu découple l'application des appareils. Le téléphone n'a jamais besoin de l'adresse IP d'un appareil ; les deux côtés parlent à un endpoint connu. Si ce rôle est nouveau pour vous, lisez d'abord ce que fait un broker MQTT.
Les options de connexion depuis un téléphone
| Transport | URL | Quand l'utiliser |
|---|---|---|
| MQTT sur TLS | mqtts://broker.connectmq.com:8883 |
Applications natives avec une bibliothèque MQTT capable de TCP (Kotlin, Swift, Flutter) |
| MQTT sur Secure WebSocket | wss://broker.connectmq.com:8084/mqtt |
React Native, Ionic, PWA et webviews ; réseaux qui bloquent le 8883 |
Les deux sont chiffrés et fonctionnent avec MQTT 3.1.1 et 5.0. WebSocket est souvent la voie la plus simple dans les applications basées sur JavaScript et sur les réseaux Wi-Fi restrictifs ; le TLS natif est légèrement plus efficace. N'utilisez jamais les ports non chiffrés 1883 ou 8083 depuis une application en production. Le guide MQTT over WebSocket explique en détail le transport WebSocket.
MQTT ou notifications push
C'est la décision de conception la plus importante, et la réponse est généralement « les deux ».
| Besoin | MQTT | Push de la plateforme (APNs / FCM) |
|---|---|---|
| Mises à jour en direct quand l'application est ouverte | Excellent | Peu adapté |
| Alertes quand l'application est fermée | Pas fiable | Conçu pour cela |
| Commandes bidirectionnelles | Oui | Non |
| Coût en batterie en arrière-plan | Élevé si la connexion reste ouverte | Géré par l'OS |
| Livraison quand le téléphone est hors ligne | Session persistante tant qu'elle dure | Mise en file par la plateforme |
Les systèmes d'exploitation mobiles suspendent les applications en arrière-plan et leurs sockets. iOS en particulier ne vous laisse pas maintenir indéfiniment une connexion MQTT ouverte en arrière-plan. L'architecture robuste est donc la suivante :
- Premier plan : l'application se connecte au broker, s'abonne aux appareils que l'utilisateur consulte et envoie des commandes via MQTT.
- Arrière-plan : l'application se déconnecte proprement. Un petit service backend s'abonne aux topics d'alerte sur le broker et envoie des notifications push de la plateforme quand un événement important survient.
- Retour au premier plan : l'application se reconnecte, les retained messages livrent immédiatement l'état courant, et l'interface est à jour en quelques instants.
Le relais backend de l'étape 2 n'est qu'un client MQTT de plus que vous exécutez, par exemple un service Node.js ou Python. ConnectMQ n'envoie pas lui-même de notifications push, et garder cette logique dans votre propre service vous permet de décider quels événements deviennent des notifications.
Batterie et consommation de données
- Ne vous connectez que lorsque c'est nécessaire. Ouvrez la connexion quand l'écran concerné s'affiche et fermez-la quand l'application passe en arrière-plan.
- Abonnez-vous de façon ciblée. Abonnez-vous à
home/42/devices/+/state, pas à#. Chaque message reçu coûte du temps radio. - Utilisez les retained messages pour l'état. L'application reçoit instantanément la dernière valeur connue à l'abonnement : plus besoin d'interroger ni de demander un rafraîchissement.
- Choisissez un keep alive modéré. 30 à 60 secondes offrent un bon équilibre entre détection rapide des connexions mortes et réveils radio moins fréquents.
- Gardez des payloads compacts. Des clés JSON courtes ou des encodages binaires aident sur les liaisons cellulaires.
- Utilisez les topic aliases et l'expiration des messages de MQTT 5 quand c'est possible. Les alias réduisent les longs noms de topics répétés ; l'expiration des messages empêche des commandes périmées d'être livrées en retard.
- Appliquez un backoff à la reconnexion. Les réseaux mobiles changent constamment ; un backoff exponentiel évite des boucles de tentatives serrées qui vident la batterie.
Exemple fonctionnel : React Native ou web avec MQTT.js
MQTT.js fonctionne dans les navigateurs et dans React Native via WebSocket. Ce module encapsule la connexion, l'abonnement et la gestion du cycle de vie de l'application.
import mqtt from "mqtt";
const BROKER_URL = "wss://broker.connectmq.com:8084/mqtt";
export function createDeviceConnection({ clientId, username, password, homeId, onState }) {
const client = mqtt.connect(BROKER_URL, {
clientId,
username,
password,
protocolVersion: 5,
keepalive: 45,
clean: true,
reconnectPeriod: 3000,
connectTimeout: 10000,
});
const stateTopic = `homes/${homeId}/devices/+/state`;
client.on("connect", () => {
client.subscribe(stateTopic, { qos: 1 }, (err) => {
if (err) console.warn("Subscribe failed", err.message);
});
});
client.on("message", (topic, payload) => {
const deviceId = topic.split("/")[3];
try {
onState(deviceId, JSON.parse(payload.toString()));
} catch {
console.warn("Ignoring non-JSON payload on", topic);
}
});
client.on("error", (err) => console.warn("MQTT error", err.message));
return {
sendCommand(deviceId, command) {
client.publish(
`homes/${homeId}/devices/${deviceId}/cmd`,
JSON.stringify(command),
{ qos: 1, properties: { messageExpiryInterval: 30 } }
);
},
pause() {
client.end(false);
},
resume() {
if (!client.connected) client.reconnect();
},
};
}
Dans React Native, appelez pause() et resume() depuis un listener de changement d'AppState. L'expiration de message de 30 secondes garantit qu'une commande mise en file pendant qu'un appareil est hors ligne ne se déclenchera pas à l'improviste quelques minutes plus tard. Certaines configurations React Native nécessitent un polyfill WebSocket ou Buffer ; consultez le guide React Native MQTT pour les particularités de la plateforme, et Flutter MQTT si vous développez en Dart.
Pour essayer sans compte, pointez ce code vers le serveur MQTT public gratuit, omettez le nom d'utilisateur et le mot de passe, utilisez n'importe quel client ID unique et non vide et préfixez les topics par une valeur unique comme connectmq/demo/m7d2w/homes/.... Tout ce qui se trouve dans l'espace public est lisible par n'importe qui : réservez-le aux démos et aux tests, jamais aux données de production.
Gérer les identifiants en toute sécurité
Le binaire d'une application mobile peut être décompilé : considérez tout ce qui y est embarqué comme public.
- N'embarquez pas un mot de passe de broker unique et partagé dans l'application. S'il fuit, le trafic de tous les utilisateurs est exposé et vous ne pouvez pas le révoquer sans casser toutes les installations.
- Émettez des identifiants par utilisateur ou par session depuis votre backend. Une fois l'utilisateur connecté à votre application, votre API renvoie les identifiants MQTT et le client ID qu'il doit utiliser.
- Cloisonnez les topics par utilisateur ou par foyer. Concevez les topics pour que les données de chaque utilisateur se trouvent sous leur propre préfixe, et contrôlez côté appareil et côté backend quelles commandes sont acceptées et de qui.
- Renouvelez et révoquez. Quand un utilisateur se déconnecte ou qu'un téléphone est perdu, révoquez ses identifiants.
- Validez les commandes sur l'appareil ou le backend. Ne présumez jamais qu'une commande provient d'un écran légitime.
ConnectMQ lie les client ID aux identifiants émis et bloque les IP après des échecs de connexion répétés, ce qui aide contre le credential stuffing. Lisez les bonnes pratiques de sécurité MQTT pour la liste complète.
Planifier la capacité pour les applications
Chaque application ouverte représente une connexion. Dix appareils et cinquante utilisateurs actifs de l'application, cela fait soixante connexions simultanées au pic, pas dix. ConnectMQ Serverless (Free) autorise jusqu'à 25 connexions, ce qui convient au développement et à une petite bêta ; Serverless (Paid) monte jusqu'à 1 000 connexions avec QoS 2 et shared subscriptions ; les clusters dédiés gèrent des audiences plus importantes. Comme les applications se déconnectent en arrière-plan, les connexions simultanées sont généralement bien moins nombreuses que les installations, mais mesurez votre comportement réel plutôt que de deviner.
Pour les options d'hébergement derrière ces plans, consultez le guide du broker MQTT cloud.
Connectez votre application à ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, testez vos topics dans le client intégré au navigateur et pointez l'exemple MQTT.js vers votre nouvel endpoint. ConnectMQ est un broker MQTT managé dont les endpoints TLS et Secure WebSocket sont prêts pour les clients mobiles dès la première minute.
Questions fréquentes
Une application mobile peut-elle garder une connexion MQTT ouverte en arrière-plan ?
Pas de manière fiable. Les systèmes d'exploitation mobiles suspendent les sockets en arrière-plan : utilisez MQTT quand l'application est au premier plan et les notifications push de la plateforme pour les alertes en arrière-plan.
Une application mobile doit-elle utiliser WebSocket ou TCP pour MQTT ?
Les applications basées sur JavaScript utilisent généralement Secure WebSocket sur le port 8084 avec le chemin /mqtt. Les applications natives peuvent utiliser TLS sur 8883 ; les deux sont chiffrés.
Comment obtenir l'état courant de l'appareil à l'ouverture de l'application ?
Faites publier l'état par les appareils sous forme de retained messages. Le broker livre la dernière valeur immédiatement quand l'application s'abonne.
Est-il sûr d'embarquer les identifiants du broker dans une application mobile ?
Non. Émettez des identifiants par utilisateur depuis votre backend après la connexion, afin qu'un identifiant divulgué puisse être révoqué individuellement.
