Choisir un broker MQTT pour une startup n'est pas le même problème que pour une grande entreprise établie : il vous faut une solution gratuite ou presque aujourd'hui, rapide à intégrer, et facile à quitter ou à faire évoluer si l'activité décolle. Ce guide donne aux jeunes équipes IoT une démarche de décision concrète, une conception de firmware qui préserve votre portabilité, et un plan par étapes, d'un broker ConnectMQ Serverless gratuit jusqu'à une capacité dédiée.
Ce dont les startups ont réellement besoin
Les contraintes d'une startup sont le temps, l'argent et l'incertitude. Vous ne savez pas encore si vous aurez cinquante ou cinquante mille appareils l'an prochain, quels protocoles les équipes informatiques de vos clients accepteront, ni quelles fonctionnalités de votre produit survivront à la confrontation avec le marché. Cela mène à une courte liste d'exigences :
- Zéro exploitation. Chaque heure passée à corriger la VM d'un broker est une heure de moins consacrée au produit. Un broker MQTT managé supprime ce travail.
- Gratuit ou très bon marché à petite échelle. Votre MVP ne doit pas supporter des coûts d'infrastructure conçus pour des flottes en production.
- Protocole standard, sans SDK propriétaire. MQTT 3.1.1 et 5.0 standard signifie que n'importe quelle bibliothèque fonctionne sur n'importe quel appareil, et que vous pourrez changer de fournisseur plus tard.
- TLS et identifiants dès le premier jour. Ajouter la sécurité après coup coûte cher ; commencez avec des connexions chiffrées.
- Un chemin de croissance visible. Vous voulez savoir ce qui se passe à 25, 1 000 et 10 000 connexions avant d'y arriver.
Les options comparées
| Option | Effort initial | Coût au stade MVP | Risque de dépendance | Remarques |
|---|---|---|---|---|
| Serveur MQTT public gratuit | Aucun | Gratuit | Aucun | Parfait pour les démos, jamais pour des données clients |
| Mosquitto auto-hébergé sur une VM | Moyen | Faible coût de VM plus votre temps | Faible | Correctifs, TLS, supervision et pannes sont à votre charge |
| Plateforme IoT cloud avec SDK propriétaire | Moyen | Variable | Élevé | Code des appareils lié aux API du fournisseur |
| Broker MQTT serverless managé | Faible | Palier gratuit disponible | Faible avec du MQTT standard | Les quotas déterminent quand passer au niveau supérieur |
Pour la plupart des jeunes équipes, la bonne réponse est un broker MQTT managé serverless pour tout ce qui est réel et un serveur MQTT public gratuit pour les expériences jetables. Le serveur MQTT public gratuit broker.connectmq.com est idéal pour un premier essai ou un prototype : anonyme, n'importe quel client ID unique et non vide, et des topics sous un préfixe unique comme connectmq/demo/k29xq/.... Comme tout y est lisible par n'importe qui, passez à un broker privé dès que les données d'un client pilote sont en jeu.
Le plan étape par étape
Étape 1 : prototype rapide (quelques jours)
Utilisez le serveur MQTT public gratuit pour valider la boucle appareil-tableau de bord. Servez-vous de mosquitto_pub et mosquitto_sub pour vérifier vos topics :
mosquitto_sub -h broker.connectmq.com -p 1883 -i spike-sub-k29xq -t 'connectmq/demo/k29xq/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i spike-pub-k29xq \
-t 'connectmq/demo/k29xq/dev1/telemetry' -m '{"temp":22.4}'
Étape 2 : MVP et pilotes (de quelques semaines à quelques mois)
Créez un broker ConnectMQ Serverless gratuit. Il prend en charge jusqu'à 25 connexions, la QoS jusqu'à 1 et des messages de 256 Ko, ce qui couvre quelques unités pilotes, un worker backend et deux ou trois tableaux de bord. Vous disposez de TLS sur 8883, de WebSocket sur 8083 et 8084, d'un client dans le navigateur, d'un explorateur de topics, d'un tableau de bord et de règles d'alerte à seuil, ce qui suffit souvent pour une démo devant des investisseurs sans construire votre propre interface d'administration.
Étape 3 : premiers revenus (des centaines d'appareils)
Passez à Serverless (Paid) : jusqu'à 1 000 connexions, QoS 2, messages de 1 Mo et shared subscriptions, afin de faire tourner plusieurs workers backend qui se partagent un même flux avec $share/workers/devices/+/telemetry. Lisez les niveaux de QoS MQTT expliqués avant d'activer la QoS 2 partout ; la plupart de la télémétrie se porte très bien en QoS 1.
Étape 4 : passage à l'échelle et clients grands comptes
Quand vous avez besoin d'isolation, d'une marge prévisible ou de réponses pour un audit de sécurité, passez à un broker MQTT dédié. Si un grand client exige que le broker tourne dans son compte cloud, BYOC couvre ce cas tout en laissant l'exploitation à ConnectMQ.
Concevoir pour la portabilité dès le premier jour
La dépendance vient rarement du broker lui-même. Elle vient des raccourcis pris dans votre firmware et votre backend. Ces habitudes vous laissent libre de changer.
Sortez les paramètres de connexion du code
Ne compilez jamais le nom d'hôte et les identifiants dans le firmware sous forme de constantes impossibles à modifier. Provisionnez-les en fabrication ou via un processus d'enrôlement sécurisé, et stockez-les en mémoire non volatile. Voici un modèle minimal pour un ESP32 avec la bibliothèque Preferences :
#include <Preferences.h>
struct MqttConfig {
String host;
uint16_t port;
String user;
String pass;
String clientId;
};
MqttConfig loadMqttConfig() {
Preferences prefs;
prefs.begin("mqtt", true); // lecture seule
MqttConfig cfg;
cfg.host = prefs.getString("host", "broker.connectmq.com");
cfg.port = prefs.getUShort("port", 8883);
cfg.user = prefs.getString("user", "");
cfg.pass = prefs.getString("pass", "");
cfg.clientId = prefs.getString("cid", "");
prefs.end();
return cfg;
}
void saveMqttConfig(const MqttConfig& cfg) {
Preferences prefs;
prefs.begin("mqtt", false);
prefs.putString("host", cfg.host);
prefs.putUShort("port", cfg.port);
prefs.putString("user", cfg.user);
prefs.putString("pass", cfg.pass);
prefs.putString("cid", cfg.clientId);
prefs.end();
}
Avec ce mécanisme, passer d'un broker serverless à un broker dédié, ou même à un autre fournisseur, devient un envoi de configuration plutôt qu'une nouvelle version de firmware.
Utilisez du MQTT standard, pas un SDK fournisseur
Tenez-vous-en aux bibliothèques open source largement utilisées : PubSubClient ou AsyncMqttClient sur ESP32, paho-mqtt en Python, MQTT.js en Node.js et dans les navigateurs. Elles fonctionnent avec n'importe quel broker conforme aux standards.
Maîtrisez votre structure de topics
Concevez vos topics autour de votre métier, pas de votre fournisseur : acme/{customerId}/{siteId}/{deviceId}/telemetry. Notre guide comment choisir un broker MQTT pour l'IoT détaille d'autres critères d'évaluation, et une bonne structure de topics survit à n'importe quel changement de broker.
Gardez les intégrations en dehors du broker
Écrivez la télémétrie dans votre base de données avec votre propre service abonné, un flow Node-RED ou Telegraf. Cette logique vous suit partout. ConnectMQ garde volontairement le broker dans son rôle de broker ; les intégrations tournent comme des clients MQTT ordinaires, ce qui est justement le modèle portable que vous recherchez de toute façon.
Les erreurs fréquentes des startups
- Livrer des unités de démo pointant vers un broker public. Cela fonctionne jusqu'au jour où un client remarque que ses données sont lisibles par le monde entier.
- Un même nom d'utilisateur pour tous les appareils. Impossible alors de révoquer une seule unité compromise. Utilisez des identifiants distincts, ou au minimum des client ID distincts par appareil.
- Des client ID dupliqués. Deux appareils avec le même ID se déconnectent mutuellement en boucle.
- Aucun backoff de reconnexion. Après une panne, tous les appareils martèlent le broker en même temps. Ajoutez un backoff exponentiel avec jitter.
- Considérer la QoS 2 comme « plus fiable, donc toujours meilleure ». Elle ajoute des allers-retours et de l'état ; rendez vos consommateurs idempotents et utilisez la QoS 1.
- Des payloads énormes. Envoyez les images ou les journaux vers un stockage objet et publiez une référence.
- Aucun topic de statut. Utilisez un message Last Will et un topic de statut retained pour que votre tableau de bord sache quels appareils sont hors ligne.
Une checklist de décision simple
Avant de vous engager, répondez à ces questions avec votre équipe :
- Pouvons-nous créer un broker et connecter un appareil en TLS en moins d'une heure ?
- Le protocole est-il du MQTT 3.1.1 ou 5.0 standard, sans SDK obligatoire ?
- Les limites du palier gratuit sont-elles documentées, et savons-nous laquelle nous atteindrons en premier ?
- Existe-t-il une évolution claire vers davantage de connexions, puis vers une capacité isolée ?
- Pourrions-nous passer à un autre broker en changeant uniquement la configuration ?
- Le portail nous donne-t-il assez de visibilité (explorateur de topics, tableau de bord, alertes) pour éviter de construire nos propres outils dès le premier jour ?
Si les réponses sont oui, vous avez un broker adapté à une startup. Pour une vision plus large des modèles d'hébergement, consultez notre guide du broker MQTT cloud.
Lancez votre MVP sur ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Vous obtiendrez vos identifiants en quelques minutes, des endpoints TLS et WebSocket, ainsi que des outils de portail pour faire la démo de votre produit. Quand la flotte grandit, ConnectMQ propose les plans Serverless (Paid), Dedicated et BYOC sur le même protocole standard : passer à l'échelle est une mise à niveau, pas une réécriture.
Questions fréquentes
Quel est le meilleur broker MQTT pour une startup au budget serré ?
Un broker MQTT managé avec un vrai palier gratuit et une prise en charge de MQTT standard, pour ne rien payer pendant le MVP et éviter le travail d'exploitation. Un plan Serverless gratuit, par exemple, prend en charge jusqu'à 25 connexions avec TLS.
Une startup devrait-elle plutôt auto-héberger Mosquitto ?
C'est possible, mais vous prenez alors en charge les correctifs, les certificats, la supervision et les pannes. La plupart des petites équipes tirent plus de valeur de ce temps en le consacrant au produit.
Comment éviter la dépendance à un fournisseur de broker MQTT ?
Utilisez des bibliothèques MQTT standard, gardez les paramètres de connexion configurables, concevez votre propre structure de topics et faites tourner les intégrations comme des abonnés externes.
Quand une startup doit-elle passer à un broker dédié ?
Lorsque vous approchez des quotas de connexions, que vous avez besoin de performances prévisibles sous une charge constante, ou que l'audit de sécurité d'un client exige une infrastructure isolée.
