> 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/external-mqtt.md).
# MQTT externe
Connectez Kilo IoT Server à votre propre broker MQTT — Mosquitto, AWS IoT Core, HiveMQ — avec authentification TLS et routage des topics.
External MQTT connecte le serveur Kilo IoT à un broker MQTT que vous exploitez déjà. La plateforme établit une connexion sortante vers le broker, s'abonne aux topics pertinents et consomme les messages dans le même pipeline de routage que les données Cloud MQTT. Choisissez cette option lorsque le broker fait déjà partie de votre empreinte d'infrastructure — un cluster Mosquitto sur site, AWS IoT Core, un déploiement HiveMQ d'entreprise ou un broker géré par un fournisseur partagé entre plusieurs sites.
## Quand External MQTT est le bon choix
* **Un broker existant fait déjà partie des opérations.** Les appareils y publient déjà ; plusieurs abonnés (historiens, tableaux de bord, plateformes d'intégration) en consomment déjà. Ajouter la plateforme comme un abonné supplémentaire est opérationnellement plus simple que de rerouter les éditeurs.
* **Exigences de conformité ou de résidence des données** stipulent que la télémétrie doit transiter par votre propre broker avant d'atteindre les consommateurs SaaS.
* **Architectures hybrides** où un traitement en périphérie sur site a lieu avant qu'un sous-ensemble de la télémétrie ne soit transféré vers la plateforme.
Pour les déploiements sans broker existant, [Cloud MQTT](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) est la voie la moins lourde.
## Exigence de joignabilité
Kilo IoT Server se connecte sortant à votre broker, donc le broker doit être joignable depuis Internet public via DDNS, redirection de port ou IP publique dédiée. Un broker accessible uniquement sur un VLAN privé n'est pas joignable depuis le plan de contrôle cloud de la plateforme.
Le schéma de production standard consiste à utiliser une IP publique ou un nom d'hôte DDNS pour le broker, avec des règles de pare-feu contrôlant quelles sources peuvent se connecter.
Pour les déploiements de développement ou pilote, un tunnel d'exposition comme ngrok fonctionne pour des tests de courte durée — mais notez que l'utilisation d'un outil d'exposition ne confirme pas à elle seule que Kilo peut joindre le broker. Après avoir enregistré le connecteur, **publiez un message de test et confirmez que les dernières données reçues se mettent à jour** sur la page de détail du connecteur. C'est la seule façon de vérifier la joignabilité de bout en bout.
## Options d'authentification
Le connecteur prend en charge quatre méthodes d'authentification, sélectionnables à la création :
| Méthode | Quand l'utiliser | Champs de configuration |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Anonyme** | Réservé aux brokers de développement. **Ne pas utiliser pour des brokers exposés en production** — toute personne sur Internet qui trouve le broker peut publier ou s'abonner. | Aucun |
| **Basique** | Authentification par nom d'utilisateur et mot de passe. La configuration la plus courante pour les déploiements de production où TLS protège les identifiants en transit. | Nom d'utilisateur, mot de passe |
| **Certificat** | Authentification TLS mutuelle utilisant des certificats client. Niveau d'assurance le plus élevé ; standard pour les déploiements réglementés. | Fichier du certificat de l'AC, fichier du certificat client, fichier de clé privée (téléversés en tant que fichiers ; ne collez pas le contenu PEM) |
| **Jeton JWT** | Authentification basée sur un jeton compatible avec les brokers qui valident les JWT (p. ex. AWS IoT Core avec des autoriseurs personnalisés, ou d'autres brokers avec des plugins JWT). | Jeton |
Pour la méthode Certificat, les trois fichiers téléversés constituent le côté client d'un échange mTLS ; le broker doit être configuré pour faire confiance à l'autorité de certification et pour valider le certificat client par rapport à celle-ci. La clé privée doit être non chiffrée au moment du téléversement.
## Provisionnement du connecteur
1. Accédez à **Connecteurs** dans la barre latérale.
2. Cliquez sur **Ajouter un connecteur**.
3. Sélectionner **External MQTT** depuis le **type de connecteur** menu déroulant.
4. Renseignez :
| Champ | Obligatoire | Détails |
| ----------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Nom** | Oui | Libellé opérationnel, par ex. `Mosquitto de l'usine 3` ou `Cluster de brokers Amérique du Nord`. |
| **URL du broker** | Oui | URL complète avec schéma et port. Exemples : `mqtts://broker.facility.example.com:8883`, `ssl://broker.example.com:8883`. |
5. Choisissez la méthode d'authentification et renseignez ses champs.
6. Cliquez sur **Ajouter**.
Le connecteur apparaît dans le tableau des connecteurs. Cliquez sur la page de détail pour trouver l' **Dernières données reçues** indicateur.
## Étape de vérification
La joignabilité de bout en bout n'est confirmée que par la réception effective d'une publication sur la plateforme. Après avoir enregistré le connecteur :
1. Publiez un message de test sur votre broker sur n'importe quel topic auquel le connecteur est abonné.
2. Ouvrez la page de détail du connecteur dans Kilo.
3. Confirmez **Dernières données reçues** se met à jour en quelques secondes.
Un test simple en une seule commande depuis un hôte capable d'atteindre le broker :
```bash
mosquitto_pub \\
-h broker.facility.example.com -p 8883 \\
--cafile /path/to/ca.crt \\
-u {username} -P {password} \\
-t "test/connectivity" \\
-m '{"hello":"world"}'
```
(Remplacez le schéma/le port et les identifiants par ceux correspondant à la méthode d'authentification de votre broker.)
Si **Dernières données reçues** ne se met pas à jour après une publication locale réussie, voir [Dépannage](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md). Les causes les plus courantes sont des règles de pare-feu entre la sortie de la plateforme et votre broker, des incohérences de liste d'autorisation IP, des sessions de tunnel expirées lors de l'utilisation de ngrok pour les tests, ou une mauvaise configuration TLS côté broker.
## Déploiement de référence Mosquitto auto-hébergé
Pour les déploiements qui ont besoin d'une référence rapide pour configurer un broker Mosquitto auto-hébergé à des fins de test ou de pilote, le compose Docker minimal ressemble à ceci :
```yaml
services:
mosquitto:
image: eclipse-mosquitto:2
container_name: mosquitto
restart: unless-stopped
ports:
- "1883:1883"
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/data:/mosquitto/data
```
`mosquitto.conf`:
```
listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/
log_dest stdout
```
Deux remarques opérationnelles :
* **`log_dest stdout`** La journalisation sur stdout est préférable à la journalisation dans des fichiers dans les déploiements conteneurisés. Les répertoires de journaux montés en bind échouent souvent sous SELinux/AppArmor ou à cause de divergences de propriété ; le stdout du conteneur est collecté par le pilote de journalisation Docker.
* **Conflit sur le port 1883.** Sur une infrastructure de développement ou partagée, le port 1883 peut déjà être occupé (par ex. un port-forward kubectl, un autre broker local). `ss -tlnp \| grep 1883` identifie le processus qui l'occupe. Reconfigurez le port côté hôte (par ex. `"1885:1883"`) et redirigez plutôt le nouveau port hôte — le port interne du conteneur peut rester 1883 pour les éditeurs du réseau.
Pour la terminaison TLS, un reverse-proxy séparé ou la configuration TLS native de Mosquitto (hors périmètre ici — voir la documentation Mosquitto) est nécessaire avant une exposition publique.
## les limites
Les connecteurs External MQTT sont limités à 10 par organisation. Pour les déploiements nécessitant des intégrations de broker supplémentaires au-delà de cette limite, faites appel à l'équipe d'ingénierie de la plateforme lors de la planification du déploiement.
---
# 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/external-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.
