> 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/mioty-connector/why-choose-mioty.md). # Pourquoi choisir MIOTY ? MIOTY vs LoRaWAN — comment le fractionnement des télégrammes, les stations de base et BSSCI déterminent quel protocole LPWAN convient à votre site. Choisir un protocole LPWAN est une question d’environnement, pas de savoir quelle technologie est meilleure en théorie. MIOTY, LoRaWAN et LR-FHSS transmettent tous de petits messages depuis des appareils alimentés par batterie sur de longues distances. Ils diffèrent par ce qu’ils supposent du monde à travers lequel ces messages circulent — et c’est cette hypothèse qui devrait guider votre choix. MIOTY part du principe que le canal est hostile et que la population d’appareils est importante, et il est conçu pour ces deux réalités dès la couche physique. *** ### L’argument en faveur de MIOTY #### La robustesse est intégrée, pas ajoutée après coup La plupart des stratégies de fiabilité sont réactives : détecter l’échec, puis réessayer. MIOTY est proactif. En divisant chaque télégramme en sous-paquets répartis dans la fréquence et le temps, puis en reconstituant le message à partir d’un ensemble partiel d’entre eux, il traite la perte comme une condition attendue plutôt que comme une exception. Il n’y a pas de tempête de nouvelles tentatives à gérer dans des conditions congestionnées, car la première tentative réussit généralement même lorsqu’une partie n’arrive pas. #### De la densité sans dégradation Les réseaux ont tendance à se dégrader à mesure qu’ils se remplissent, car plus d’appareils signifie plus de collisions, et plus de collisions signifie plus de retransmissions — une boucle de rétroaction qui empire précisément au moment où le déploiement devient précieux. Quand les collisions coûtent des fragments plutôt que des messages, cette boucle ne se referme pas. Des milliers de terminaux par station de base, voilà ce que cela vous apporte, et c’est ce qui rend des déploiements à l’échelle d’un site ou d’un portefeuille pratiques sur une infrastructure modeste. #### Une base ouverte et standardisée MIOTY est spécifié par l’ETSI comme **TS 103 357** — actuellement partie 2, version 2.1.1 (2024) — sous le nom TS-UNB. Vous vous appuyez sur une norme publiée avec un écosystème multi-fournisseurs derrière elle, et non sur l’interprétation d’un seul fournisseur. Les fabricants de terminaux et de stations de base implémentent la même spécification, et la [MIOTY Alliance](https://mioty-alliance.com) maintient l’écosystème qui l’entoure. L’interface entre la station de base et le centre de service, **BSSCI**est spécifiée séparément par l’Alliance. *** ### MIOTY et LoRaWAN, côte à côte Kilo prend en charge les deux. La comparaison ci-dessous est une orientation technique pour choisir le bon outil pour un site donné — pas un argument contre l’un ou l’autre protocole. | | **MIOTY** | **LoRaWAN** | | ----------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------- | | **Norme** | ETSI TS 103 357 (TS-UNB) | Spécification LoRaWAN (LoRa Alliance) | | **Technique de base** | Découpage du télégramme — sous-paquets répartis dans la fréquence et le temps | Modulation LoRa chirp spread spectrum | | **Gestion des interférences** | Reconstruit le télégramme à partir d’un ensemble partiel de salves | Livraison au niveau du message ; une collision coûte le message | | **Infrastructure de terrain** | Les stations de base réassemblent les télégrammes | Les passerelles acheminent les paquets vers un serveur réseau | | **Interface de backhaul** | BSSCI via TLS mutuel sécurisé par certificat | Transfert des paquets vers le serveur réseau | | **Écosystème d’appareils** | Base de fournisseurs industriels en croissance | Catalogue de capteurs très vaste, mature et diversifié | | **Cas idéal** | Déploiements bruyants, denses ou mobiles | IoT généraliste très large avec un vaste choix de matériels | #### Là où les architectures diffèrent réellement La distinction structurelle mérite d’être dite clairement, car elle façonne la manière dont vous planifiez un site. Dans LoRaWAN, les passerelles relaient les paquets radio et le serveur réseau effectue le travail du protocole — la passerelle est un relais. Dans MIOTY, la **station de base** est l’endroit où les sous-paquets sont collectés et où le télégramme est réassemblé ; elle effectue la reconstruction, et ne se contente pas de transmettre des trames brutes. Les stations de base se connectent ensuite à un **centre de service** via **BSSCI**, sur une liaison TLS mutuelle sécurisée par certificat. Il n’y a pas de passerelle de transfert de paquets au sens LoRaWAN, donc planifiez la couverture MIOTY autour des stations de base et de leur backhaul, et non autour d’une flotte de passerelles. *** ### Comment décider Choisissez **MIOTY** lorsque : * Les interférences constituent une contrainte connue — ateliers industriels, machines lourdes, structures métalliques denses, spectre encombré * Vous déployez des milliers de terminaux et souhaitez réduire le nombre de stations de base * Les appareils sont mobiles, ou l’environnement autour d’eux change * Les mesures manquantes ont un coût réel — dossiers de conformité, données de facturation, tendances de défaillance Choisissez **LoRaWAN** lorsque : * L’environnement radio est raisonnablement propre et le nombre d’appareils est modéré * Le catalogue le plus large possible de capteurs prêts à l’emploi compte pour votre projet * Vous voulez l’écosystème LPWAN le plus établi pour un déploiement polyvalent Et ce n’est pas l’un ou l’autre. Rien ne vous empêche d’exécuter MIOTY là où la RF est difficile et LoRaWAN là où elle ne l’est pas — au sein d’une même organisation Kilo, sur les mêmes tableaux de bord, alimentant les mêmes règles. Une fois les données sur la plateforme, elles sont normalisées, de sorte que le protocole qui a transporté une mesure cesse d’avoir de l’importance dès qu’elle arrive. *** ### Un serveur réseau, ou une plateforme Il existe une deuxième décision derrière celle du protocole, et il vaut la peine de la distinguer : un serveur réseau MIOTY et une plateforme IoT ne sont pas le même produit. Un centre de service fait circuler les messages. Il gère les stations de base et les terminaux, traite les communications montantes et descendantes, et transmet les données plus loin. C’est une couche nécessaire et exigeante — mais, à elle seule, elle vous donne de la télémétrie, pas des réponses. Tout ce que vous voulez réellement *faire* avec une mesure — la tracer, déclencher une alerte, agir dessus, la conserver pour un audit — se passe ailleurs. Kilo vous offre les deux parcours : * **Kilo Center — l’édition Communauté.** Notre centre de service MIOTY open source. Hébergez-le vous-même, maîtrisez l’infrastructure de bout en bout, et intégrez-le à tout ce que vous exécutez en aval. C’est un serveur réseau MIOTY : stations de base, terminaux, trafic et console opérateur. Voir [Centre de service Kilo MIOTY](/kilo-docs-fr/kilo-center/kilo-mioty-service-center.md). * **Kilo Cloud — l’édition Entreprise, intégrée.** L’édition Entreprise du centre de service s’exécute dans Kilo Cloud, donc vous n’avez aucune infrastructure MIOTY à héberger. Enregistrez un [connecteur MIOTY](/kilo-docs-fr/kilo-iot-server/connectors/mioty-connector.md), pointez-y vos stations de base, et vos terminaux arrivent sur une plateforme IoT complète plutôt que sur un simple serveur réseau. Les mêmes mesures arrivent dans le moteur de règles, les alertes avec escalade, les tableaux de bord, le Digital Building Twin, le contrôle d’accès multi-tenant et la piste d’audit — les mécanismes que le reste de votre parc utilise déjà. Un terminal MIOTY et un capteur LoRaWAN deviennent le même type d’objet dès que leurs données sont normalisées, et une seule règle peut raisonner sur les deux. ### Démarrer un déploiement MIOTY sur Kilo Les données provenant des terminaux MIOTY parviennent à votre organisation via le [connecteur MIOTY](/kilo-docs-fr/kilo-iot-server/connectors/mioty-connector.md), et les stations de base desservant ces terminaux sont enregistrées et gérées sous [stations de base MIOTY](/kilo-docs-fr/kilo-iot-server/gateways/mioty-base-stations.md). *** MIOTY est une marque déposée de la MIOTY Alliance. --- # 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/mioty-connector/why-choose-mioty.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.