> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/what-is-mqtt.md).
# Qu’est-ce que MQTT
Qu’est-ce que MQTT ? Un protocole IoT léger de publication-abonnement — brokers, topics, QoS — et comment il se mappe au connecteur Kilo.
MQTT est un protocole de messagerie léger de type publication-abonnement, conçu pour les réseaux et les appareils contraints, initialement spécifié par IBM en 1999 pour les systèmes SCADA via des liaisons satellitaires et désormais normalisé sous la norme ISO/IEC 20922. Trois propriétés en font aujourd’hui le protocole dominant de l’IoT industriel : une faible surcharge au format filaire adaptée aux terminaux cellulaires et alimentés par batterie, des producteurs et consommateurs découplés via un broker central, et des garanties de livraison bien définies (QoS 0/1/2) qui permettent aux intégrateurs d’arbitrer entre débit et fiabilité pour chaque topic.
Si vous intégrez un système existant produisant du MQTT — un système de gestion technique du bâtiment, une flotte de compteurs connectés au cellulaire, un parc d’automates PLC reliés par MQTT — au Kilo IoT Server, l’aperçu ci-dessous couvre le modèle supposé par la plateforme. Si vous exploitez déjà MQTT en production et souhaitez passer directement à la suite, [MQTT Cloud](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) et [MQTT externe](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) décrivez directement la configuration du connecteur.
## Rôles architecturaux
Trois rôles interviennent dans tout échange MQTT :
* **Broker** — l’infrastructure de routage. Les appareils et applications se connectent au broker ; le broker associe les éditeurs aux abonnés en fonction des motifs de topic et gère la livraison selon le niveau de QoS demandé. Le broker est le point de connexion unique pour chaque participant MQTT ; il n’existe pas de repli de pair à pair.
* **Éditeurs** — produisent des messages vers des topics. En pratique, les éditeurs industriels incluent des PLC équipés d’un firmware MQTT, des passerelles de périphérie traduisant Modbus / BACnet / OPC-UA vers MQTT, des passerelles propres aux fournisseurs (Zigbee2MQTT, ESPHome) et des firmwares embarqués sur mesure sur les équipements de terrain.
* **Abonnés** — consomment des messages. Le connecteur MQTT du Kilo IoT Server est un abonné. Plusieurs abonnés peuvent consommer les mêmes topics indépendamment — votre tableau de bord existant, votre historien sur site et la plateforme peuvent tous recevoir les mêmes données sans coordination.
```
Équipements de terrain ──┐
Automates PLC ───────────┤
Passerelles ────────┼──> Broker ──> Abonnés (Kilo, historien, tableaux de bord, ...)
Passerelles de périphérie ──┘
```
Les appareils sont généralement à la fois éditeurs (rapportant la télémétrie) et abonnés (recevant des consignes, de la configuration et des liaisons descendantes). Le broker est l’intermédiaire toujours présent.
## Topics : la clé de routage
Chaque message MQTT transporte un **topic** — une chaîne UTF-8 séparée par des barres obliques. Le broker utilise les topics pour faire correspondre les éditeurs aux abonnés ; les abonnés déclarent leur intérêt pour des motifs à l’aide de `+` (joker d’un seul niveau) et `#` (joker multi-niveaux à la fin). Les topics ne sont pas prédéfinis ; la partie qui publie choisit le topic, et un catalogue de topics est établi par convention ou par accord avec le fournisseur.
Conventions courantes dans les déploiements industriels :
* **Structure hiérarchique des topics par site/actif/métrique** — par exemple, `plant-3/line-a/extruder-04/temperature` ou `building-12/floor-2/ahu-1/setpoint`. Cela rend les abonnements avec jokers naturels pour l’agrégation à l’échelle du site.
* **Schémas préfixés par le fournisseur** pour les passerelles de protocole — p. ex. `zigbee2mqtt/{friendlyName}`, `tasmota/{deviceName}/SENSOR`, `mosquitto/+/state`. Le Kilo IoT Server prend en charge toute forme de topic grâce au **Topic ID de l’appareil** champ pattern — voir [Sujets et routage des dispositifs](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md).
* **espaces de noms Sparkplug B** pour des hiérarchies de style OPC-UA — p. ex. `spBv1.0/{group}/DDATA/{node}/{device}`. La plateforme les consomme comme des topics MQTT ordinaires ; le décodage spécifique à Sparkplug est pris en charge par la passerelle de périphérie émettrice.
La configuration du connecteur de la plateforme traite les topics comme des motifs : pour chaque appareil, vous construisez le topic à partir de segments et vous marquez celui qui porte l’identifiant de l’appareil, et la plateforme extrait l’identifiant depuis cette position à l’arrivée de chaque message.
## Charges utiles : JSON structuré en pratique
Le protocole MQTT lui-même est indifférent à la charge utile — des octets entrent, des octets sortent. Dans les déploiements de production, JSON est de très loin le format de prédilection pour les nouveaux systèmes, avec occasionnellement Sparkplug B (Protocol Buffers) et des formats binaires propriétaires pour les passerelles héritées. Le connecteur MQTT du Kilo IoT Server analyse automatiquement les charges utiles JSON — les objets plats, les objets imbriqués (aplatis en chemins en notation par points) et les valeurs primitives sont tous pris en charge.
Un exemple typique de charge utile de télémétrie industrielle :
```json
{
"horodatage": "2026-01-15T14:32:18Z",
"température": 78.4,
"pression": 4.21,
"vibration": {"rms": 0.42, "pic": 1.8},
"statut": "en marche"
}
```
Lorsqu’ils sont mappés aux métriques de la plateforme, `temperature`, `pression`, `vibration.rms`, `vibration.peak`, et `état` deviennent chacun une clé de connecteur adressable. L’onglet Mapping relie chaque clé de connecteur à une métrique normalisée, qui alimente ensuite le Digital Twin, le moteur de règles et le stockage historique.
Pour les schémas d’une métrique par topic (passerelles héritées, motifs d’aliasage OPC-UA), les **Topics de télémétrie** lignes de l’onglet Topic vous permettent d’associer explicitement chaque topic à une clé de connecteur nommée.
## QoS, messages retenus, dernière volonté et testament
Trois fonctionnalités du protocole reviennent suffisamment souvent dans les déploiements industriels pour mériter d’être mentionnées explicitement :
* **Niveaux de QoS** — 0 (au plus une fois), 1 (au moins une fois), 2 (exactement une fois). Le connecteur de la plateforme gère le niveau de QoS utilisé par l’éditeur ; choisissez le niveau qui correspond à votre tolérance opérationnelle aux doublons par rapport aux pertes. Le QoS 2 impose la surcharge la plus élevée au broker et est généralement réservé aux commandes de contrôle ou aux changements d’état critiques.
* **Messages retenus** — messages marqués que le broker stocke et réémet aux nouveaux abonnés lors de la connexion. Utiles pour publier l’état courant (par ex. des annonces « en ligne/hors ligne »). Si le broker livre les messages retenus à la plateforme comme des publications souscrites standard, ils peuvent être mappés comme n’importe quelle autre charge utile — vérifiez le comportement de votre broker.
* **Dernière volonté et testament (LWT)** — un message que le broker publie au nom de l’éditeur s’il se déconnecte de manière inattendue. Schéma courant : le LWT d’un appareil publie `"hors ligne"` sur son topic d’état, afin que les abonnés voient les changements d’état de déconnexion sans interrogation périodique. Si votre broker livre les messages LWT au connecteur comme des publications MQTT standard, ils peuvent être mappés comme n’importe quelle autre charge utile.
Ces fonctionnalités sont configurées par la partie qui publie, et non par le connecteur. Le connecteur accepte tout ce que le broker délivre.
## Pourquoi MQTT pour l’IoT industriel
L’adoption du protocole dans les déploiements commerciaux est portée par trois propriétés qui se traduisent bien en exigences opérationnelles :
* **Efficacité de la bande passante.** La surcharge du format filaire est suffisamment faible pour les équipements de terrain connectés au cellulaire et les déploiements sans fil à forte densité. Les keep-alives et les pings sont configurables pour s’adapter aux fenêtres de connectivité disponibles.
* **Producteurs et consommateurs découplés.** L’ajout d’un nouvel abonné (un historien, une plateforme d’analyse tierce, le Kilo IoT Server) ne nécessite pas de reconfigurer les éditeurs. Les équipes d’exploitation peuvent déployer de nouveaux consommateurs sans intervenir sur le terrain.
* **Écosystème mature.** Mosquitto, HiveMQ, AWS IoT Core, Azure IoT Hub et de nombreux autres brokers existent. La plupart des passerelles de protocoles industrielles modernes (Modbus vers MQTT, BACnet vers MQTT, passerelles de périphérie Sparkplug B) intègrent une publication MQTT de premier ordre.
Pour une configuration spécifique au déploiement, poursuivez vers [MQTT Cloud](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) pour les brokers gérés par la plateforme, ou [MQTT externe](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) pour connecter un broker existant.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/what-is-mqtt.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
