Les tarifs des brokers MQTT déroutent surtout parce que les fournisseurs ne mesurent pas la même chose : l'un facture à la connexion, un autre au message, un troisième au gigaoctet et un quatrième au cluster dédié. Ce guide explique chaque modèle de tarification, montre quelles charges de travail il avantage ou pénalise, et vous donne une méthode reproductible pour estimer votre propre usage afin de comparer les devis à armes égales. Il ne contient volontairement aucun prix, car ceux-ci changent souvent ; la méthode, elle, reste valable.
Pourquoi les tarifs des brokers MQTT varient autant
Les coûts réels d'un broker proviennent de quelques ressources : la mémoire par connexion ouverte, le CPU par message routé, la bande passante réseau, le stockage des messages retenus et en file d'attente, et les personnes qui l'exploitent. Chaque fournisseur choisit une ou deux de ces ressources comme unité de facturation et intègre le reste dans les limites de ses offres. Résultat : deux services peuvent sembler bon marché ou chers pour exactement la même flotte, selon le profil de votre trafic.
Prenons deux flottes. La première compte plusieurs milliers d'appareils qui envoient chacun une petite mesure toutes les quinze minutes. La seconde compte quelques dizaines de machines qui diffusent des données à haute fréquence. La première est riche en connexions et pauvre en messages ; la seconde, l'inverse. Un modèle par connexion avantage la seconde flotte, un modèle par message avantage la première. Connaître votre profil, c'est tout l'enjeu.
Les modèles de tarification courants des brokers MQTT
1. À la connexion
Vous payez le nombre de connexions simultanées, souvent mesuré en pic ou en maximum mensuel. Le volume de messages peut être illimité dans le cadre d'un usage raisonnable ou plafonné selon l'offre.
- Avantage : les appareils bavards, les débits de messages élevés, les petites flottes.
- Pénalise : les très grandes flottes d'appareils majoritairement inactifs, et les architectures où chaque onglet de navigateur ou application mobile maintient sa propre connexion.
- Points de vigilance : le décompte est-il simultané ou cumulé, et les rafales de reconnexions brèves comptent-elles dans le pic ?
2. À la minute de connexion (temps de session)
Vous payez la durée totale pendant laquelle les clients restent connectés, généralement comptée en minutes de connexion ou de session. Ce modèle est courant sur les plateformes IoT cloud qui facturent tout à la consommation.
- Avantage : les appareils qui se connectent brièvement, publient puis se déconnectent.
- Pénalise : les appareils connectés en permanence, qui accumulent chacun un mois complet de minutes.
- Points de vigilance : l'arrondi des fractions de minute, et la question de savoir si le trafic keepalive compte aussi comme des messages.
3. Au message
Vous payez chaque message publié ou livré, souvent par paquets. Certains services comptent un message une seule fois à la publication ; d'autres comptent chaque livraison à chaque abonné, si bien qu'une publication avec dix abonnés compte pour onze. Certains comptent par incréments de taille fixe, de sorte qu'un payload volumineux compte pour plusieurs messages.
- Avantage : les grandes flottes peu bavardes.
- Pénalise : la télémétrie haute fréquence, la diffusion vers de nombreux abonnés et les payloads volumineux.
- Points de vigilance : les pings, les abonnements, les livraisons de messages retenus et les accusés de réception QoS sont-ils comptés ?
4. Au volume de trafic
Vous payez au gigaoctet transféré en entrée, en sortie ou les deux. C'est proche de la façon dont le réseau cloud est facturé.
- Avantage : les payloads binaires compacts comme Sparkplug B ou CBOR.
- Pénalise : le JSON verbeux, la diffusion massive et les charges de type vidéo.
- Points de vigilance : le TLS et la surcharge protocolaire sont-ils inclus, et l'entrée et la sortie sont-elles tarifées différemment ?
5. Offres par paliers avec quotas
Vous payez un montant fixe par palier, et chaque palier inclut des limites de connexions, de taille de message, de niveau de QoS, de débit ou de fonctionnalités. C'est le modèle le plus prévisible pour budgéter.
- Avantage : les équipes qui veulent une facture mensuelle connue.
- Pénalise : les charges de travail situées juste au-dessus d'une limite de palier.
- Points de vigilance : ce qui se passe à la limite : rejet, limitation de débit ou facturation automatique du dépassement.
6. Capacité dédiée
Vous payez un cluster isolé dimensionné en instances, nœuds ou unités de capacité, quel que soit votre usage réel. Le BYOC (bring your own cloud) en est une variante dans laquelle l'infrastructure tourne dans votre propre compte cloud : vous payez les ressources au fournisseur cloud et la gestion à l'éditeur.
- Avantage : les charges importantes et stables, les exigences strictes d'isolation et de résidence des données.
- Pénalise : les charges petites ou en pics qui laissent de la capacité inutilisée.
- Points de vigilance : les engagements minimums, les multiplicateurs liés à la haute disponibilité et la prise en charge du trafic inter-zones.
7. Licences auto-gérées
Pour un logiciel que vous exploitez vous-même, les éditeurs peuvent facturer par nœud, par cœur, par palier de connexions ou via un contrat entreprise. La licence n'est qu'une partie du coût ; l'infrastructure et le temps des équipes pèsent souvent davantage. Notre guide sur le coût total de possession d'un broker MQTT détaille ces coûts cachés.
Les modèles de tarification en un coup d'œil
| Modèle | Unité de facturation | Idéal pour | Principal risque |
|---|---|---|---|
| À la connexion | Clients simultanés | Peu de clients très actifs | Grandes flottes inactives |
| Minutes de connexion | Temps connecté | Appareils intermittents | Appareils toujours connectés |
| Au message | Messages publiés ou livrés | Grandes flottes peu bavardes | Diffusion et débits élevés |
| Au trafic | Gigaoctets | Payloads compacts | JSON verbeux, diffusion |
| Offres par paliers | Montant fixe par palier avec quotas | Budgets prévisibles | Limites de palier |
| Capacité dédiée | Taille du cluster | Charge forte et stable, isolation | Capacité inutilisée |
| Licence auto-gérée | Nœuds, cœurs ou contrat | Contrôle total | Coût d'exploitation caché |
Comment estimer votre usage
Avant de comparer le moindre devis, mesurez ou estimez votre charge de travail. Tous les modèles de tarification peuvent se calculer à partir des mêmes quelques chiffres :
- Appareils (D) : nombre de clients qui publient.
- Autres clients (B) : backends, tableaux de bord, sessions navigateur, instances Node-RED.
- Pic de connexions simultanées : généralement D + B, plus une marge pour le chevauchement des reconnexions.
- Messages par appareil et par heure (R).
- Taille moyenne du payload en octets (S).
- Nombre moyen d'abonnés par message (F) : le facteur de diffusion.
- Fraction du temps connecté (C) : 1,0 pour des appareils toujours connectés.
À partir de là, calculez les chiffres mensuels (sur la base de 730 heures par mois) :
published messages / month = D x R x 730
delivered messages / month = published x F
connection-minutes / month = (D + B) x C x 730 x 60
payload traffic in (bytes) = published x S
payload traffic out (bytes) = delivered x S
Un exemple chiffré avec des hypothèses : 400 appareils qui publient toutes les 30 secondes (R = 120), un payload JSON de 200 octets et deux abonnés par message (un enregistreur en base de données et un tableau de bord).
published = 400 x 120 x 730 = 35,040,000 messages / month
delivered = 35,040,000 x 2 = 70,080,000 messages / month
traffic in = 35,040,000 x 200 bytes = about 7 GB / month
traffic out= 70,080,000 x 200 bytes = about 14 GB / month
peak connections = 400 + 3 backend clients + headroom
Appliquez les unités de chaque fournisseur à ces chiffres, puis ajoutez aux estimations de trafic une surcharge protocolaire (TLS, en-têtes MQTT, keepalives) de quelques dizaines de pour cent, plutôt que de supposer que les octets du payload racontent toute l'histoire. Un pilote sur un vrai broker, observé via sa console ou ses statistiques $SYS, vous permet de remplacer les hypothèses par des valeurs mesurées.
Les leviers de coût que vous maîtrisez
Quel que soit le modèle, vous pouvez généralement réduire la facture par des choix de conception :
- Publier sur changement ou avec des bandes mortes plutôt qu'à intervalles rapides et fixes.
- Regrouper plusieurs mesures dans un seul message lorsque la latence le permet.
- Utiliser des payloads compacts ou les alias de topic de MQTT 5 pour réduire le nombre d'octets.
- Utiliser des abonnements partagés plutôt que de nombreux consommateurs identiques.
- Éviter une connexion au broker par onglet de navigateur lorsqu'un backend peut assurer la diffusion.
Faire correspondre votre estimation aux offres ConnectMQ
ConnectMQ propose des offres par paliers définies par des limites, ce qui simplifie l'estimation : trouvez la plus petite offre dont les limites couvrent votre pic de connexions, votre QoS et votre taille de message. Serverless (Free) fonctionne sur un cluster partagé avec jusqu'à 25 connexions, une QoS jusqu'à 1 et des messages de 256 Ko, ce qui convient aux prototypes et aux petits pilotes. Serverless (Paid) porte ces limites à 1 000 connexions, la QoS 2, des messages de 1 Mo et les abonnements partagés. Au-delà, Dedicated fournit un cluster isolé, BYOC fonctionne dans votre propre compte cloud géré par ConnectMQ, et Self Managed Enterprise tourne sur votre infrastructure. Lorsqu'un quota est atteint, les clients MQTT 5 reçoivent un code de raison explicite comme 0x97 (quota dépassé), si bien que les limites n'échouent jamais en silence. L'article sur les quotas de connexion d'un broker MQTT explique comment les anticiper.
Comparer les offres sur ConnectMQ
Commencez avec l'offre Serverless gratuite sur app.connectmq.com, sans carte bancaire, mesurez votre trafic réel pendant un pilote et ne montez en gamme que lorsque les chiffres le justifient. Pour un tout premier essai sans compte, le serveur MQTT public gratuit broker.connectmq.com suffit, mais il est réservé aux tests et aux prototypes, jamais aux données de production. ConnectMQ est un broker MQTT managé avec les mêmes endpoints et le même code client sur toutes les offres. Pour mieux comprendre les modèles de déploiement, lisez notre guide sur le broker MQTT cloud, et consultez l'offre gratuite d'un broker MQTT pour savoir à quoi vous attendre des offres gratuites du marché.
Questions fréquentes
Quel modèle de tarification de broker MQTT est le moins cher ?
Aucun ne l'est dans l'absolu. La tarification à la connexion convient à quelques clients très actifs, la tarification au message à de nombreux appareils peu bavards, et la capacité dédiée aux charges importantes et stables. Estimez d'abord votre charge de travail, puis appliquez chaque modèle.
Les pings keepalive comptent-ils comme des messages ?
Cela dépend du fournisseur. Certains ne comptent que les publications applicatives, d'autres comptent tous les paquets MQTT. Posez explicitement la question, car des intervalles keepalive courts sur une grande flotte peuvent vite s'additionner.
Comment éviter les frais de dépassement inattendus ?
Choisissez une offre dont les limites rejettent ou limitent plutôt que de facturer automatiquement, surveillez l'usage dans la console et configurez des alertes avant d'approcher d'un quota.
Puis-je estimer les coûts sans appareils réels ?
Oui, en utilisant la formule de ce guide avec des débits et des tailles de payload supposés. Remplacez ces hypothèses par des valeurs mesurées lors d'un petit pilote dès que possible.
