Brokers MQTT publics ou privés : quand passer au privé

Presque tous les projets MQTT démarrent sur un broker public. Vous copiez broker.hivemq.com ou broker.emqx.io depuis un tutoriel, vous vous connectez sans identifiants, et les messages circulent en quelques secondes. Cette rapidité est précisément la raison d’être des brokers publics. Mais l’ouverture qui les rend si simples les rend aussi inadaptés à tout ce qui dépasse l’expérimentation. Ce guide expose honnêtement les compromis, pour que vous sachiez quand rester et quand migrer.

Ce qu’est réellement un broker MQTT public

Un broker public est un serveur MQTT partagé qui accepte les connexions anonymes de n’importe qui sur Internet. Des éditeurs et des projets open source les exploitent comme démos et bacs à sable d’interopérabilité. Notre liste de brokers publics recense les plus populaires. Leurs caractéristiques :

• Pas d’inscription et, en général, ni nom d’utilisateur ni mot de passe.
• Un seul espace de noms de topics, partagé par tous les utilisateurs du monde.
• Un fonctionnement « au mieux » destiné aux tests, pas un service supporté.

Les vrais risques des bacs à sable publics

1. N’importe qui peut lire et écrire sur vos topics

Sans authentification ni contrôle d’accès, un abonné à # reçoit tous les messages du broker — y compris les vôtres. N’importe qui peut aussi publier sur vos topics de commande. Si un appareil écoute home/garage/door/set, un inconnu peut l’ouvrir. Des noms de topics obscurs réduisent les collisions, mais ce n’est pas de la sécurité : quiconque est abonné à # les voit.

2. Messages retenus parasites et état périmé

Les messages retenus (retained) persistent jusqu’à ce que quelqu’un les efface. Sur un broker public, les topics sont jonchés de payloads retenus laissés par d’autres utilisateurs et d’anciens tests, et n’importe qui peut écraser votre état retenu. Un tableau de bord qui se fie à la valeur retenue lors de l’abonnement peut afficher des données qui n’ont jamais été les vôtres. Voir les messages retenus MQTT pour comprendre leur fonctionnement.

3. Collisions de topics et de client ID

Des topics génériques comme test/temperature sont partagés avec tous ceux qui ont suivi le même tutoriel. Les client ID génériques sont pires : quand quelqu’un d’autre se connecte avec votre ID, le broker vous déconnecte, et les deux clients finissent dans une boucle de reconnexion. Détails dans les erreurs de connexion MQTT.

4. Pas de SLA, pas de support, pas de préavis

Les brokers publics peuvent être redémarrés, mis à jour ou bridés à tout moment. Certains font volontairement tourner des versions de développement. C’est acceptable pour un bac à sable, mais cela signifie qu’une démo peut échouer devant un client pour des raisons que vous ne pouvez ni voir ni corriger.

5. Limites de débit et fonctionnalités manquantes

Les opérateurs protègent leur infrastructure partagée par des limites de connexions, de débit de messages et de taille de payload, parfois non documentées. Vous ne pouvez pas non plus tester les fonctionnalités dont dépend la production : authentification, permissions par topic, certificats client, bridging ou réglages de persistance.

Quand un broker public convient parfaitement

• Apprendre les concepts MQTT comme la QoS, les jokers (wildcards) et le Last Will.
• Vérifier qu’une nouvelle bibliothèque cliente ou un firmware peut se connecter et publier.
• Des démos rapides avec des données fictives et un préfixe de topic aléatoire.
• Reproduire un bug sur un broker neutre et bien connu.

Si vous en utilisez un, gardez quelques bonnes habitudes :

# Random prefix + random client ID = fewer collisions
PREFIX="testmqtt/$(openssl rand -hex 4)"
mosquitto_sub -h broker.emqx.io -i "sub-$(openssl rand -hex 4)" -t "$PREFIX/#" -v

Essayer un broker public en toute sécurité

Les signes qu’il est temps de changer

1. Vos messages contiennent quoi que ce soit que vous ne publieriez pas publiquement.
2. Vos appareils acceptent des commandes via MQTT.
3. Quelqu’un d’autre que vous en dépend — un collègue, un client pilote, une démo.
4. Vous devez tester l’authentification, les ACL ou les certificats client TLS.
5. Vous subissez des déconnexions inexpliquées, du bridage ou des messages parasites.

Vos options pour un broker privé

L’auto-hébergement est un choix solide qui donne un contrôle total ; le prix, c’est un travail continu — renouvellement des certificats, correctifs de l’OS, sauvegardes et alertes. Un broker managé échange un peu de contrôle contre l’absence de ce travail.

Une approche raisonnable : public pour apprendre, privé pour tout le reste

Vous n’avez pas à choisir une fois pour toutes. Beaucoup d’équipes utilisent un bac à sable public le premier après-midi — pour confirmer qu’une bibliothèque fonctionne et que la conception des topics tient la route — puis passent à un broker privé dès que de vrais appareils ou des collègues entrent en jeu. Dès lors, développement, préproduction et production ont chacun leur propre broker ou leurs propres identifiants, si bien qu’un script de test ne peut jamais publier par accident sur des topics de production.

Gardez les paramètres de connexion (URL, nom d’utilisateur, mot de passe) dans la configuration ou dans des variables d’environnement dès le premier jour. Changer de broker devient alors un changement de déploiement et non de code, et vous pouvez pointer le même build vers un broker public pour une démo ou vers un broker privé pour un pilote.

Ce qu’il faut rechercher dans un broker privé ou managé

• Isolation : votre propre instance ou espace de noms, pas une arborescence de topics partagée.
• Authentification : au minimum un nom d’utilisateur/mot de passe par client ; idéalement des identifiants par appareil.
• Autorisation : un contrôle d’accès par topic, pour qu’un capteur ne puisse publier que sur ses propres topics.
• Chiffrement : TLS sur 8883 et WebSockets sécurisés pour les applications web. Voir les ports MQTT.
• Support du protocole : MQTT 3.1.1 et MQTT 5, pour que les anciens appareils et les nouvelles fonctionnalités cohabitent.
• Endpoints standard : un hôte et un port classiques, pour qu’une migration ultérieure ne soit qu’une question de configuration.
• Visibilité : un moyen de voir les clients connectés et la raison du rejet d’une connexion.

Migrer, c’est surtout de la configuration

MQTT étant un protocole standard, passer d’un broker public à un broker privé touche rarement à la logique applicative :

// Before: public sandbox
mqtt.connect('wss://broker.emqx.io:8084/mqtt');

// After: private broker with credentials over TLS
mqtt.connect(process.env.MQTT_URL, {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `sensor-${deviceSerial}`,
});

Profitez aussi de la migration pour mettre de l’ordre dans votre hiérarchie de topics — une structure cohérente rend les règles d’accès bien plus simples à écrire. Topics et jokers MQTT présente des conventions de nommage qui passent à l’échelle, et vous pouvez vérifier vos filtres avec le testeur de topics.

Questions fréquentes