> 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/cloud-mqtt.md).
# Cloud MQTT
Provisionnez un broker Cloud MQTT géré dans Kilo IoT — point de terminaison et identifiants dédiés par connecteur, idéal pour les pilotes.
Cloud MQTT est l’option de broker gérée par la plateforme pour un connecteur MQTT. Le serveur IoT Kilo provisionne un endpoint de broker dédié par connecteur, génère les identifiants et attribue un préfixe de topic unique qui délimite l’espace de noms du connecteur au sein du broker géré. Les appareils et les passerelles edge publient vers cet endpoint ; la plateforme consomme les messages directement.
Pour les déploiements qui n’ont pas de besoin opérationnel d’exécuter leur propre broker MQTT — pilotes, sites distants, sites récemment acquis, firmware MQTT fourni par un fournisseur qui a seulement besoin d’une destination publique — Cloud MQTT élimine du périmètre d’intégration le provisionnement du broker, la gestion des certificats et les problèmes d’accessibilité.
## Quand Cloud MQTT est le bon choix
* **Ingestion greenfield.** Aucun broker existant ; en faire fonctionner un ajouterait du périmètre d’infrastructure sans bénéfice opérationnel.
* **Firmware MQTT fourni par un fournisseur.** Un appareil ou une passerelle est configuré pour publier en MQTT vers un endpoint accessible depuis Internet, et un endpoint géré est préférable à la mise en place d’une infrastructure.
* **Sites distants avec des opérations contraintes.** Un site dispose d’une liaison montante cellulaire ou satellite et d’un support informatique limité sur place ; orienter les éditeurs vers un endpoint cloud géré est opérationnellement plus simple que d’exécuter un broker local.
* **Déploiements pilotes.** Valider une intégration MQTT avant d’engager un investissement dans une infrastructure de broker.
Lorsqu’un broker existant est déjà en place — un cluster Mosquitto sur site, AWS IoT Core, une instance HiveMQ d’entreprise ou un autre produit de broker — voir [External MQTT](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) à la place.
## Provisionnement du connecteur
1. Accédez à **Connecteurs** dans la barre latérale.
2. Cliquez sur **Ajouter un connecteur**.
3. Sélectionner **Cloud MQTT** depuis le **type de connecteur** menu déroulant.
4. Fournissez un **Nom** pour le connecteur (libellé opérationnel, par ex. `Télémétrie ligne A usine 3`).
5. Cliquez sur **Ajouter**.
La plateforme provisionne l’endpoint du broker et affiche quatre identifiants :
| Champ | Comportement |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **URL du broker** | L’endpoint géré complet, y compris le schéma et le port. Utilise MQTTS (TLS) sur le port 1884. À copier tel quel — le schéma et le port font partie de l’identifiant. |
| **Préfixe de topic** | Le préfixe d’espace de noms unique pour les messages routés vers ce connecteur. Chaque message publié par vos appareils doit commencer par ce préfixe. Le préfixe a la forme `iot/{org}/{connection}` — deux segments opaques identifiant votre organisation et ce connecteur. |
| **Nom d’utilisateur** | Généré par la plateforme. À copier exactement — il doit être reproduit à l’identique côté publication. |
| **Mot de passe** | Un secret généré aléatoirement. Affiché une seule fois. **À copier et à conserver en lieu sûr lors de la création.** Aucune récupération n’est possible — uniquement une rotation. |
Le mot de passe n’est pas stocké sous une forme récupérable. Considérez la copie effectuée après le provisionnement comme la seule occasion de le capturer ; si vous manquez ce moment, il faut régénérer les identifiants et reconfigurer tous les éditeurs.
## Modèle d’intégration
Les éditeurs Cloud MQTT se connectent en sortie vers le broker géré. Trois points sont importants :
* **TLS sur le port 1884.** Configurez le client MQTT de votre éditeur pour utiliser le `mqtts://` schéma sur le port 1884. N’assumez pas le port 1883 — le broker géré n’accepte pas les connexions en clair. Le certificat du broker est signé par une autorité de certification approuvée publiquement, donc aucun bundle de CA côté client n’est requis pour les bibliothèques standard.
* **Le préfixe de topic est obligatoire sur chaque topic publié.** Un appareil publiant des relevés d’énergie doit publier vers `{Topic prefix}/{your topic}` — par exemple, `iot/{org}/{connection}/meters/EM-4492/power`. Les messages publiés en dehors du préfixe ne sont pas livrés à ce connecteur.
* **Le préfixe de topic est supprimé avant le routage vers l’appareil.** Lorsque vous configurez le topic d’ID de périphérique d’un appareil dans le sous-onglet Topic, vous ne spécifiez que la partie au niveau de l’appareil (`meters/{{deviceId}}/power` ou similaire). La plateforme gère le préfixe en interne.
Pour les appareils reliés via Zigbee2MQTT en particulier, le Z2M `base_topic` paramètre dans `configuration.yaml` doit être `{Topic prefix}/zigbee2mqtt`. Z2M publie ensuite chaque appareil sous `{Topic prefix}/zigbee2mqtt/{friendlyName}`, et le topic de niveau appareil vu pour le routage est `zigbee2mqtt/{friendlyName}`.
## Vérification de l’ingestion
Après le démarrage de l’éditeur, ouvrez la page de détail du connecteur. Le **Dernières données reçues** champ se met à jour dans les secondes qui suivent la première publication. Pour les configurations reliées par Z2M, le propre `bridge/state` l’annonce de message retenu bridge/state est la première chose que le broker accepte — c’est généralement à ce moment que **Dernières données reçues** apparaît pour la première fois, avant qu’aucun appareil n’ait signalé quoi que ce soit.
Si **Dernières données reçues** ne se met pas à jour après que l’éditeur a signalé une connexion réussie au broker, les causes les plus courantes sont un mauvais port (1883 au lieu de 1884), un mauvais schéma TLS ou un décalage du préfixe de topic. Voir [Dépannage](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) pour la séquence de diagnostic complète.
## Rotation des identifiants
Faites tourner les identifiants Cloud MQTT lorsque :
* Le mot de passe d’origine a été perdu ou n’a jamais été capturé.
* Une fuite d’identifiants est suspectée.
* Une transition d’équipe ou le départ d’un prestataire justifie une rotation.
* Une politique de conformité exige une rotation périodique.
Pour faire la rotation :
1. Ouvrez la page de détail du connecteur.
2. En mode édition, régénérez le mot de passe.
3. Capturez immédiatement le nouveau mot de passe.
4. Mettez à jour tous les clients émetteurs (configuration du firmware, Z2M `configuration.yaml`, paramètres de passerelle edge) avec le nouveau mot de passe.
5. Redémarrez les éditeurs pour prendre en compte le nouvel identifiant.
Le nom d’utilisateur et le préfixe de topic restent stables lors de la rotation. Seul le mot de passe change.
## les limites
Les connecteurs Cloud MQTT sont illimités par organisation. Utilisez plusieurs connecteurs pour segmenter les espaces de noms par site, fournisseur ou équipe opérationnelle — chaque connecteur dispose de son propre préfixe de topic et de ses propres identifiants, et l’accès peut être géré indépendamment pour chaque connecteur.
---
# 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/cloud-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.
