Choisir entre un broker MQTT auto-hébergé ou managé détermine la part de votre semaine consacrée à l'infrastructure plutôt qu'au produit. Cet article compare les deux options sous l'angle de l'effort d'exploitation, des coûts cachés et de la responsabilité en matière de sécurité, puis vous propose une matrice de décision pour choisir en toute confiance le bon modèle pour votre projet.
Si vous avez besoin d'un rappel sur le rôle d'un broker MQTT avant de comparer les modèles d'hébergement, commencez par là.
Ce que signifient vraiment « auto-hébergé » et « managé »
Un broker auto-hébergé est un logiciel que vous installez et exploitez vous-même : Mosquitto, EMQX, VerneMQ, NanoMQ ou un autre broker open source ou commercial tournant sur une VM, un Raspberry Pi, un cluster Kubernetes ou un serveur de votre usine. Le système d'exploitation, la configuration du broker, les certificats TLS, la base d'utilisateurs, les sauvegardes et le bipeur d'astreinte sont à votre charge.
Un broker MQTT managé est un service. Le fournisseur exploite le broker, applique les correctifs, renouvelle les certificats et expose les endpoints ; vous recevez un nom d'hôte, des ports et des identifiants. Le design des topics, le code client et les données restent à vous, mais pas les serveurs sous-jacents. Un broker MQTT managé comme ConnectMQ vous fournit un broker prêt à l'emploi en quelques minutes.
Entre les deux se trouve un modèle hybride : bring your own cloud (BYOC), où le broker tourne dans votre compte cloud mais est exploité par l'éditeur. Ce modèle est détaillé dans le guide du broker MQTT BYOC.
Le vrai travail d'exploitation de votre propre broker
Installer Mosquitto prend une minute. L'exploiter correctement demande un effort continu. Une installation auto-hébergée prête pour la production nécessite généralement :
# Minimal production mosquitto.conf - every line is something you now maintain
per_listener_settings true
listener 8883
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl
listener 8084
protocol websockets
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
persistence true
persistence_location /var/lib/mosquitto/
max_queued_messages 1000
message_size_limit 1048576
Ce fichier n'est qu'un début. Autour de lui, il vous faut :
- Cycle de vie des certificats : obtenir les certificats, les renouveler avant expiration et recharger le broker sans déconnecter les clients.
- Correctifs du système et du broker : suivre les bulletins de sécurité du noyau, d'OpenSSL et du broker lui-même.
- Gestion des utilisateurs et des identifiants : créer, faire tourner et révoquer les identifiants des appareils, idéalement sans modifier des fichiers à la main.
- Supervision : surveiller le nombre de connexions, les débits de messages, la mémoire et le disque, et alerter un humain en cas de dérive.
- Protection contre les abus : limites de débit, limites de connexions et blocage des tentatives de connexion par force brute.
- Sauvegardes et reprise : fichiers de persistance, configuration et base de mots de passe.
- Planification de capacité : savoir quand un seul nœud ne suffit plus, et quoi faire à ce moment-là.
- Astreinte : quelqu'un qui répond quand le broker tombe à 3 heures du matin.
Aucune de ces tâches n'est difficile en soi. Ensemble, elles deviennent un emploi à temps partiel qui figure rarement dans l'estimation initiale.
Broker MQTT auto-hébergé ou managé : la comparaison point par point
| Critère | Auto-hébergé | Managé |
|---|---|---|
| Délai avant la première connexion | Des heures à des jours (serveur, TLS, authentification) | Quelques minutes (inscription, création du broker) |
| Coût d'infrastructure | Serveur ou VM, stockage, bande passante | Abonnement ou offre gratuite |
| Coût humain | Exploitation continue, correctifs, astreinte | Essentiellement absorbé par le fournisseur |
| Certificats TLS | Vous les émettez et les renouvelez | Fournis et renouvelés |
| Durcissement de la sécurité | Entièrement à votre charge | Partagé : le fournisseur durcit, vous protégez les identifiants |
| Personnalisation | Contrôle total du broker et des plugins | Limitée à ce que le service expose |
| Emplacement réseau | N'importe où, y compris sur des sites isolés | Endpoint Internet (ou votre cloud avec BYOC) |
| Montée en charge | Vous la concevez et l'exploitez | Changement de plan ou d'offre |
| Contrôle des données | Entièrement sur votre matériel | Dépend du fournisseur et du modèle de déploiement |
Aucune colonne ne l'emporte partout. La question est de savoir laquelle a les faiblesses les moins pénalisantes pour votre projet.
Les coûts cachés que la plupart des équipes oublient
Le coût visible de l'auto-hébergement, c'est la facture de la VM. Les coûts cachés sont généralement plus élevés :
- Le temps des ingénieurs. Chaque heure passée à renouveler des certificats, à diagnostiquer un disque plein ou à mettre à jour un broker est une heure de moins pour le firmware de vos appareils ou votre application.
- Le coût des incidents. Une panne du broker arrête tous les appareils en même temps. Le coût, c'est l'indisponibilité plus la course pour diagnostiquer sous pression un système mal connu.
- La dette de sécurité. Un listener de test oublié sur le port 1883 avec
allow_anonymous trueest l'une des façons les plus courantes de se retrouver avec un broker exposé sur Internet. - La concentration des connaissances. Souvent, une seule personne sait comment le broker est configuré. Quand elle part, le savoir part avec elle.
Pour chiffrer ces éléments de façon structurée, consultez l'article sur le coût total de possession d'un broker MQTT. Utilisez vos propres chiffres de salaires et d'incidents ; les chiffres génériques correspondent rarement à la réalité.
Responsabilités de sécurité : qui gère quoi
La sécurité est partagée dans les deux modèles, mais la répartition diffère.
Avec un broker auto-hébergé, tout vous incombe : règles de pare-feu, configuration TLS, choix des suites de chiffrement, hachage des mots de passe, fichiers d'ACL, durcissement du système, conservation des logs et réponse aux intrusions.
Avec un broker MQTT managé, le fournisseur prend en charge la couche plateforme. Sur ConnectMQ, par exemple, la plateforme fournit TLS sur le port 8883 et Secure WebSocket sur le port 8084 avec un certificat Let's Encrypt, l'isolation multi-tenant, des quotas par plan, une protection contre l'inondation de messages, le blocage d'IP après des échecs de connexion répétés et des client ID liés aux identifiants qu'elle délivre. Il vous reste à :
- Garder les noms d'utilisateur et mots de passe hors des dépôts publics et des dumps de firmware.
- Utiliser TLS (8883 ou 8084) depuis les appareils plutôt que le port 1883 en clair en production.
- Concevoir les topics de sorte que les données sensibles ne soient pas publiées là où elles ne devraient pas l'être.
Le guide des bonnes pratiques de sécurité MQTT détaille le côté client.
Quand l'auto-hébergement est le bon choix
L'auto-hébergement convient bien lorsque :
- Le réseau est isolé. Une usine sans connexion externe ou un navire sans connectivité fiable a besoin d'un broker local.
- Vous avez besoin de fonctionnalités de broker qu'un service n'expose pas, comme un plugin d'authentification personnalisé ou une configuration de bridge spécifique.
- Vous disposez déjà d'une équipe plateforme mature avec supervision, gestion des correctifs et astreinte en place : un service de plus ne représente alors qu'un effort marginal.
- La réglementation impose un traitement sur site et un déploiement exploité par l'éditeur dans votre environnement n'est pas envisageable.
Même dans ces cas, de nombreuses équipes combinent un broker edge local et un broker cloud pour l'accès à distance, via un bridge MQTT ou une application passerelle.
Quand un broker MQTT managé est le meilleur choix
Un broker MQTT managé l'emporte généralement lorsque :
- Vous êtes une petite équipe et personne ne veut être d'astreinte pour l'infrastructure.
- Vous prototypez ou lancez un produit et la rapidité d'obtention du premier appareil fonctionnel compte davantage qu'une personnalisation poussée.
- Les appareils sont dispersés sur Internet (domiciles, véhicules, sites distants) et ont besoin d'un endpoint public stable avec TLS.
- Votre charge augmente par paliers. Passer d'une offre gratuite à une offre payante ou à un cluster dédié est plus simple que de refondre l'architecture d'un serveur.
ConnectMQ couvre ces paliers avec un plan Serverless gratuit (jusqu'à 25 connexions, QoS jusqu'à 1, messages de 256 Ko), un plan Serverless payant (jusqu'à 1 000 connexions, QoS 2, messages de 1 Mo, abonnements partagés), des clusters isolés Dedicated, BYOC et une option Self Managed Enterprise.
Une matrice de décision utilisable dès aujourd'hui
Notez chaque ligne de 0 à 2 pour votre projet, puis additionnez chaque colonne.
| Question | Points pour l'auto-hébergé | Points pour le managé |
|---|---|---|
| Le broker doit-il fonctionner sans accès à Internet ? | 2 si oui | 0 |
| Avez-vous déjà une équipe d'exploitation avec astreinte ? | 2 si oui | 2 si non |
| Avez-vous besoin de plugins de broker personnalisés ? | 2 si oui | 0 |
| Le délai de mise sur le marché est-il critique ? | 0 | 2 si oui |
| Les appareils sont-ils dispersés sur l'Internet public ? | 0 | 2 si oui |
| Moins de deux personnes maintiendront-elles le système ? | 0 | 2 si oui |
| Une dépense mensuelle prévisible compte-t-elle plus que le coût serveur brut le plus bas ? | 0 | 2 si oui |
Si la colonne managé l'emporte, commencez par un broker MQTT managé et gardez des clients standard pour pouvoir changer plus tard si vos besoins évoluent. L'article sur la dépendance fournisseur MQTT explique comment rester portable.
Testez le modèle managé en cinq minutes
Vous pouvez sentir la différence immédiatement. Avec les clients en ligne de commande de Mosquitto installés, abonnez-vous et publiez sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes, jamais aux données de production :
# Terminal 1 : abonnement (utilisez votre propre préfixe unique)
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-7f3a9 -t "connectmq/demo/7f3a9/#" -v
# Terminal 2 : publication
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-7f3a9 -t "connectmq/demo/7f3a9/temp" -m "21.4"
Faites ensuite la même chose sur votre propre broker privé en TLS, avec les identifiants générés dans le portail :
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-V mqttv5 -t "plant1/line1/temp" -m "21.4"
Aucun certificat à émettre, aucun fichier de configuration à modifier. Comparez avec la liste de tâches précédente et vous tenez l'essentiel de la décision.
Démarrez avec un broker MQTT managé
Si la matrice penche vers le managé, essayez ConnectMQ sur de vrais appareils avant de vous engager. Créez un broker Serverless gratuit sans carte bancaire, connectez un appareil en TLS et utilisez le client MQTT intégré au navigateur ainsi que l'explorateur de topics en direct pour voir vos messages arriver. Pour une vue d'ensemble des options d'hébergement, lisez le guide du broker MQTT cloud.
Questions fréquentes
Un broker MQTT auto-hébergé est-il moins cher qu'un broker MQTT managé ?
Le serveur lui-même est souvent moins cher, mais le coût total inclut les correctifs, les certificats, la supervision et le temps d'astreinte. Pour les petites équipes, le coût humain dépasse généralement l'économie réalisée sur le serveur.
Puis-je commencer en managé et passer à l'auto-hébergement plus tard ?
Oui, si vos clients utilisent MQTT 3.1.1 ou 5.0 standard et que vous évitez les fonctionnalités propres au fournisseur. Changer de broker revient alors à modifier l'hôte, le port et les identifiants.
Est-ce que je perds le contrôle de mes données avec un broker MQTT managé ?
Vous gardez le contrôle de ce que vous publiez et de qui détient des identifiants. Si vous avez besoin que le broker tourne dans votre propre compte cloud, un déploiement BYOC y conserve l'infrastructure tandis que l'éditeur l'exploite.
Qu'en est-il des brokers dans des réseaux isolés ?
Un réseau isolé nécessite un broker local. Un schéma courant associe un broker edge local pour l'usine et un broker MQTT managé dans le cloud pour les tableaux de bord à distance, reliés par un bridge ou une passerelle.
