> 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/faq/changelog.md).
# Journal des modifications
Journal des modifications de Kilo IoT Server — entrées Scale Log pour chaque version, avec résumés des fonctionnalités, captures d’écran et liens vers la documentation.
Journal des versions. Version 3.9.0
Les règles Kilo automatisent la façon dont un déploiement réagit aux données des appareils. Un **déclencheur** est une condition enregistrée qui démarre une règle, et il dispose désormais de deux contrôles indépendants : il peut évaluer un seul appareil ou plusieurs appareils sélectionnés, et il peut agir immédiatement ou attendre que la condition reste vraie. Avant la version 3.9.0, appliquer une réponse à 50 appareils nécessitait 50 règles ; maintenant, un seul déclencheur et une seule règle peuvent les couvrir tout en gardant la condition et le compte à rebours de chaque appareil séparés. Cette version regroupe aussi toutes les métriques sur une seule page consultable, ajoute les paiements par facture et les valeurs exactes sur les graphiques en barres, étend l'assistant IA et aide les applications IA connectées à distinguer les actions qui lisent des données de celles qui les modifient. [kiloiot.io](https://kiloiot.io)
***
#### Contenu de cette version
* **Une seule règle pour jusqu'à 500 appareils** — Auparavant, appliquer la même règle à 50 appareils nécessitait 50 règles distinctes. Désormais, un seul déclencheur peut sélectionner ces appareils, évaluer chacun séparément et lancer la règle partagée pour tout appareil qui remplit la condition.
* **Attendre avant qu'une règle s'exécute** — Un déclencheur peut exiger qu'une condition reste vraie pendant 10 secondes à 30 jours avant de lancer la règle. Par exemple, une règle de porte de congélateur peut ignorer une porte ouverte brièvement pour le chargement, mais agir lorsque la porte reste ouverte pendant 10 minutes.
* **Toutes les métriques sur une seule page** — Une métrique est un type de relevé, comme la température ou le niveau de batterie. Les métriques qui étaient réparties sur trois onglets sont désormais disponibles dans une seule liste consultable à **Appareils → Métriques**, où vous pouvez aussi les ajouter et les modifier.
* **Payer par facture plutôt que par carte** — Saisissez les informations de votre entreprise et, si nécessaire, votre numéro de TVA ; puis choisissez le virement bancaire et recevez les informations de facturation par e-mail. La nouvelle **Factures** page indique quelles factures sont ouvertes ou payées et fournit le téléchargement du PDF.
* **Afficher les valeurs sur les graphiques en barres** — **Afficher la valeur sur la barre** imprime chaque valeur sur sa barre. **Afficher les métriques en dessous** ajoute les relevés actuels sous le graphique.
* **Ajoutez des appareils MIOTY avec l'assistant IA** — L'assistant peut désormais utiliser une connexion MIOTY existante pour vous aider à choisir un modèle d'appareil, saisir ses identifiants et créer l'appareil avec un blueprint compatible lorsqu'il en faut un.
* **Utilisez votre propre compte IA** — Connectez un compte OpenAI, Anthropic, OpenRouter, Ollama ou un compte compatible au lieu d'utiliser le quota mensuel de messages inclus dans votre forfait Kilo. Les noms de modèles Ollama avec des balises de version sont désormais pris en charge.
* **Les applications IA connectées peuvent distinguer les actions de lecture et d'écriture** — Les actions disponibles pour ChatGPT, Claude, Cursor et d'autres applications IA connectées indiquent désormais si elles lisent seulement des données ou si elles peuvent modifier ou supprimer quelque chose.
* **Améliorations de fiabilité et d'interface** — Les photos d'appareil sont enregistrées correctement, la piste d'audit se rafraîchit après les changements d'autorisations, les couleurs des widgets fonctionnent à nouveau, la conservation des journaux suit votre forfait, et l'assistant IA signale les actions terminées de manière plus fiable.
***
**Une règle pour de nombreux appareils**
Une règle est un organigramme qui indique à Kilo comment réagir aux données des appareils. Elle peut évaluer des relevés, déclencher une alarme, calculer une valeur ou envoyer une commande à un équipement comme une vanne ou un relais. Un déclencheur définit la condition qui lance la règle.
Avant la version 3.9.0, une règle ne pouvait être déclenchée que par un seul appareil. Si la même condition et la même réponse s'appliquaient à 50 appareils, il fallait 50 règles distinctes. Modifier la condition plus tard signifiait éditer chaque copie.
Désormais, un seul déclencheur peut sélectionner jusqu'à **500 appareils**, et une seule règle s'applique à tous. Ajouter un autre appareil signifie mettre à jour ce déclencheur au lieu de créer une autre règle. La sélection appartient au déclencheur ; ce n'est pas un groupe d'appareils réutilisable ailleurs dans Kilo.
La plupart des déclencheurs multi-appareils sont simples : chaque appareil sélectionné fournit le même relevé et est surveillé indépendamment. Chaque appareil surveillé a son propre état de déclencheur et son propre compte à rebours, donc une porte restée ouverte n'affecte aucune autre porte.
Un appareil sélectionné peut aussi fournir un relevé partagé au lieu d'être surveillé. Par exemple, 50 portes peuvent chacune fournir leur propre `door_open` relevé tandis qu'un contrôleur de bâtiment fournit `heating_on` pour chaque vérification de porte. Avant d'enregistrer, **Comment ce déclencheur s'exécutera** affiche une ligne pour chaque appareil surveillé et identifie tout relevé partagé dans la colonne **Utilise** .
Une alarme peut aussi identifier l'appareil qui a déclenché la règle. Ajoutez `vars.device_name` au message de motivation de l'alarme afin que la notification nomme l'appareil concerné.
[→ Un déclencheur pour plusieurs appareils](/kilo-docs-fr/kilo-iot-server/rules-engine/triggers/multiple-devices.md)
***
**Faire attendre une règle avant son exécution**
Avant la version 3.9.0, une règle s'exécutait dès qu'un relevé d'appareil dépassait la limite que vous aviez définie. Une réponse immédiate est utile pour des situations urgentes comme une fuite d'eau, mais un bref pic de température ou une porte ouverte ne nécessite pas toujours une action.
Un déclencheur peut désormais exiger que la condition reste vraie avant que la règle ne démarre. Choisissez **Seulement s'il dure**, puis définissez une durée en secondes, minutes, heures ou jours. Les nouveaux déclencheurs commencent à 10 minutes ; vous pouvez définir n'importe quelle durée entre 10 secondes et 30 jours.
Par exemple :
* Ignorer une porte de congélateur ouverte brièvement pour le chargement, mais lancer la règle si elle reste ouverte pendant 20 minutes.
* Dans le garage d'un immeuble résidentiel, ignorer la courte visite d'un résident mais déclencher une alarme de sécurité si le mouvement continue pendant 10 minutes durant le programme nocturne de la règle.
* Ignorer un cycle normal de pompe d'une minute, mais agir si la pompe continue de fonctionner pendant deux heures.
* Ignorer une hausse de température brève, mais déclencher une alarme si une pièce reste au-dessus de 25 °C tout l'après-midi.
Deux comportements supplémentaires contrôlent le fonctionnement du minuteur :
* **Un intervalle entre les rapports de l'appareil ne réinitialise pas le compte à rebours.** Un appareil qui rapporte toutes les 15 minutes n'annulera pas une attente de 20 minutes simplement parce qu'aucun nouveau relevé n'est arrivé entre deux rapports.
* **L'effacement du déclencheur peut avoir sa propre condition et son propre délai.** Sous **Comportement d'effacement**, définissez quand le déclencheur revient à l'état normal et combien de temps cette condition d'effacement doit durer. Cela évite qu'un seul relevé normal efface une condition trop tôt.
[→ Temporisation du déclencheur](/kilo-docs-fr/kilo-iot-server/rules-engine/triggers/trigger-timing.md)
***
**Toutes les métriques sur une seule page**
Une métrique définit un type de relevé d'appareil, comme la température, l'humidité, le niveau de batterie ou le fait qu'une porte soit ouverte. La définition indique à Kilo le nom, l'unité et le type de données de la métrique afin que les relevés de différents fabricants d'appareils puissent être utilisés de façon cohérente dans les tableaux de bord et les règles.
Avant la version 3.9.0, les définitions de métriques étaient réparties sur trois onglets. Elles sont désormais gérées dans une seule liste à **Appareils → Métriques**. À partir de cette page, vous pouvez :
* rechercher par nom ;
* filtrer par unité, type ou type de données ;
* sélectionner plusieurs valeurs de filtre à la fois ;
* trier du plus récent au plus ancien ;
* ajouter ou modifier une métrique dans la même boîte de dialogue.
Les métriques appartiennent à l'ensemble de l'organisation. En modifier une la change pour chaque appareil qui l'utilise, donc Kilo vous avertit désormais de l'effet plus large et demande une confirmation avant l'enregistrement.
[→ Métriques](/kilo-docs-fr/kilo-iot-server/devices/metric-templates.md)
***
**Payer par facture plutôt que par carte**
Avant la version 3.9.0, les abonnements Kilo ne pouvaient être payés que par carte. Les organisations qui exigent une facture d'entreprise et un virement bancaire n'avaient pas d'autre méthode de paiement.
Vous pouvez désormais saisir votre raison sociale, votre adresse enregistrée, votre e-mail de facturation et votre numéro de TVA dans les paramètres de l'organisation, puis sélectionner **Payer par facture (virement bancaire)** lors du choix d'un forfait. Les numéros de TVA de l'UE sont vérifiés via le registre VIES, et le formulaire indique si la vérification est en attente ou terminée.
Lorsque vous payez par facture :
* les informations de facture et le lien vers la facture hébergée sont envoyés à votre e-mail de facturation ;
* la facture inclut une page de paiement avec les coordonnées bancaires attribuées à votre organisation afin que le paiement puisse être rapproché automatiquement ;
* la **Factures** page affiche les factures ouvertes et payées ;
* les mises à niveau facturent la différence pour la période restante, tandis que les avoirs de rétrogradation sont appliqués à la facture suivante ;
* votre déploiement continue de fonctionner pendant le traitement du changement de forfait.
Les paiements par carte continuent de fonctionner comme auparavant.
[→ Facturation et factures](/kilo-docs-fr/kilo-iot-server/settings/billing-and-invoices.md)
***
**Afficher les valeurs sur les graphiques en barres**
Un widget de graphique affiche les relevés d'appareils sur un tableau de bord. Avant la version 3.9.0, les valeurs sur un graphique en barres devaient être estimées à partir de l'échelle du graphique.
Activez **Afficher la valeur sur la barre** pour afficher la valeur directement sur chaque barre. Cette option n'est disponible que pour les graphiques en barres.
Activez **Afficher les métriques en dessous** pour ajouter une ligne sous le graphique avec chaque métrique et son relevé actuel. Cela peut rendre les widgets compacts du tableau de bord plus faciles à lire.
[→ Graphique en barres](/kilo-docs-fr/kilo-iot-server/dashboards/adding-widgets/chart-widget/bar-chart.md)
***
**Ajoutez des appareils MIOTY avec l'assistant IA**
MIOTY est un protocole radio conçu pour les grands sites et les environnements soumis à de fortes interférences radio. Pour enregistrer un point de terminaison, Kilo a besoin d'une connexion MIOTY existante, de l'EUI du point de terminaison, de la clé de session réseau, de l'adresse courte et du modèle d'appareil. Certains points de terminaison utilisent aussi une clé d'application. Un blueprint compatible est facultatif et convertit la charge utile brute en relevés nommés que Kilo peut utiliser.
Avant la version 3.9.0, l'assistant IA pouvait créer une connexion MIOTY, mais vous deviez encore enregistrer l'appareil manuellement.
L'assistant peut désormais terminer avec vous la configuration de l'appareil. Il va :
1. vous aider à sélectionner le fabricant, le modèle et une version de blueprint disponible lorsqu'un décodeur est nécessaire ;
2. collecter et valider l'EUI, la clé de session réseau et l'adresse courte au fur et à mesure que vous les saisissez ;
3. créer l'appareil et associer le blueprint sélectionné, le cas échéant.
L'assistant demande des identifiants qui doivent provenir de votre matériel ou de la documentation du fournisseur ; il ne les génère pas.
[→ Construire avec l'IA](/kilo-docs-fr/kilo-iot-server/ai-assistant/building-with-ai.md)
***
**Utilisez votre propre compte IA**
Chaque forfait Kilo comprend un quota mensuel de messages de l'assistant IA. Vous pouvez à la place connecter un compte OpenAI, Anthropic, OpenRouter, Ollama ou un fournisseur personnalisé compatible OpenAI. Les messages envoyés via cette connexion n'utilisent pas le quota inclus dans votre forfait Kilo.
Ouvrir **Connectez votre IA** depuis la barre supérieure du Chat IA et saisissez le fournisseur, le point de terminaison, la clé API et le nom du modèle.
Avant la version 3.9.0, Kilo rejetait les noms de modèles Ollama qui incluaient une version après deux points, comme `gpt-oss:120b`. Les modèles Ollama suggérés n'étaient pas non plus disponibles pour les comptes gratuits. Les noms de modèles versionnés sont désormais acceptés, et les suggestions ont été mises à jour pour des modèles qui fonctionnent avec un compte Ollama gratuit.
Les erreurs de connexion distinguent désormais :
* une clé API que le fournisseur ne reconnaît pas ;
* un compte valide qui n'inclut pas l'accès au modèle sélectionné ;
* un nom de modèle que le fournisseur n'offre pas.
Après connexion, le panneau continue d'afficher le point de terminaison, la clé masquée et le nom du modèle afin que vous puissiez confirmer quelle configuration est utilisée.
[→ Gestion des chats et de l'accès à l'IA](/kilo-docs-fr/kilo-iot-server/ai-assistant/managing-chats-and-ai-access.md)
***
**Les applications IA connectées peuvent distinguer les actions de lecture et d'écriture**
Kilo peut se connecter à des applications IA comme ChatGPT, Claude et Cursor. Ces applications peuvent répondre à des questions sur vos appareils et, avec autorisation, effectuer des actions comme envoyer des commandes au matériel.
Avant la version 3.9.0, les actions disponibles n'avaient pas de titres clairs et n'indiquaient pas si elles se contentaient de lire des données ou modifiaient quelque chose. L'application IA ne pouvait pas distinguer de façon fiable une action telle que lister des appareils d'une action qui supprime un appareil.
Chaque action indique désormais si elle lit des données, modifie ou supprime quelque chose, ou interagit avec l'extérieur de votre organisation. Les applications IA compatibles peuvent utiliser ces informations pour répondre directement aux questions en lecture seule et demander une confirmation avant d'effectuer une modification. Aucune configuration Kilo supplémentaire n'est requise.
La liste des actions publiée est générée à partir des mêmes définitions que celles utilisées par le serveur. Les actions qui étaient listées mais non implémentées ont été supprimées.
[→ Serveur MCP](/kilo-docs-fr/kilo-iot-server/api/mcp-server.md)
***
**Améliorations de fiabilité et d'interface**
L'assistant IA signale désormais plus précisément le résultat d'une action :
* Il confirme un changement d'intervalle de rapport uniquement lorsque l'appareil l'accepte.
* La nouvelle tentative d'enregistrement d'un appareil ne remplace plus le nom que vous aviez choisi.
* L'enregistrement d'un appareil n'ajoute plus de mappage de température non demandé.
* Les connexions MIOTY n'affichent plus un champ de clé API qu'elles n'utilisent pas.
* L'assistant explique correctement que Kilo peut exécuter des commandes d'appareil. Lorsqu'une action doit être effectuée dans l'interface web, il vous dirige vers l'écran approprié.
* Un enregistrement d'appareil réussi n'affiche plus un message d'échec contradictoire.
* Les messages de confirmation affichent correctement les sauts de ligne.
* Les réponses ne répètent plus la même réponse à la fois en texte et dans un widget.
* Les réponses qui arrivent d'un seul coup apparaissent immédiatement sans nécessiter de rechargement de la page.
* Les limites d'appareil sont appliquées de manière cohérente, que l'appareil soit ajouté via l'assistant ou via un formulaire.
Les améliorations supplémentaires de cette version comprennent :
* Les photos d'appareil sont enregistrées correctement.
* La piste d'audit se rafraîchit après les changements d'autorisations, de sorte que les nouvelles entrées apparaissent sans recharger la page.
* Les appareils MIOTY montrent clairement qu'ils utilisent leur propre copie d'un blueprint ; modifier la copie d'un appareil n'a plus l'air d'affecter les autres appareils.
* Les valeurs du widget Dernières données changent à nouveau de couleur selon leurs conditions.
* Les diagnostics des appareils utilisent la terminologie Kilo correcte.
* L'assistant peut récupérer des périodes plus longues de l'historique des appareils.
* Les appareils qui rapportent une fois par jour ne sont plus marqués hors ligne après seulement quelques heures, et l'avertissement indique ses unités.
* La conservation des journaux d'appareil suit la limite incluse dans votre forfait.
* Le formulaire d'assistance vous permet de sélectionner un signalement de bogue, une demande de fonctionnalité ou une demande d'intégration.
* Les appareils émulés horodatent correctement leur premier relevé et s'affichent correctement sur les écrans mobiles.
* La boîte de dialogue du déclencheur s'adapte aux écrans mobiles, et l'icône du Chat IA est plus facile à voir.
* Les états vides sont cohérents pour les connecteurs, les appareils, les règles, les artefacts de règle et les stations de base MIOTY. Les états vides des appareils et des passerelles renvoient aussi vers la boutique lorsqu'aucun matériel n'a été ajouté.
* La page Vue d'ensemble, l'espacement de la navigation, la carte Télécharger l'application, la navigation Factures et les écrans du moteur de règles ont été peaufinés, et le code front-end obsolète a été supprimé.
Journal des versions. Version 3.8.0
Trois gros ajouts dans la version 3.8.0. **Premièrement, vous n'avez plus besoin de matériel pour commencer** — le **Émulateur** construit un site complet sans aucun appareil, tableaux de bord, règles et alarmes à escalade compris, puis confie ces mêmes appareils à de vrais capteurs le jour de leur arrivée. **Deuxièmement, l'assistant IA commande désormais votre équipement**: il liste les commandes d'un appareil, en exécute une après votre confirmation et vérifie qu'elle est bien arrivée. **Et troisièmement — ce qui nous enthousiasme le plus — connectez ChatGPT ou Claude via MCP et ils contrôlent eux aussi vos appareils.** Ce n'est pas un chatbot qui décrit votre bâtiment : c'est votre propre client IA, qui commute des relais et modifie des consignes sur du matériel réel, dans le cadre de vos propres autorisations, avec chaque envoi enregistré. En plus de tout cela, la plateforme vous indique désormais ce qui a été livré dans un **Nouveautés** panneau, et MIOTY atteint un ensemble plus large de stations de base avec **BSSCI 1.1**. [kiloiot.io](https://kiloiot.io)
***
#### Contenu de cette version
* **Connecteur Émulateur** — Construisez et testez un déploiement avant même que le matériel n'existe : des appareils qui génèrent leur propre télémétrie à partir de vrais préréglages d'appareils, avec des valeurs manuelles et un envoi unique, puis basculez vers un connecteur réel le jour de la mise en service.
* **Votre IA commande désormais l'équipement** — Demandez à l'assistant ce qu'un appareil peut faire, dites-lui d'en exécuter une, et il lance la commande et confirme la livraison. La plateforme n'est plus quelque chose sur lequel vous posez seulement des questions.
* **Contrôlez vos appareils depuis ChatGPT ou Claude** — Connectez n'importe quel client MCP — ChatGPT, Claude, Cursor, Codex — et il peut exécuter des commandes sur votre matériel de la même façon, dans le cadre de vos propres autorisations. Un LLM avec les mains sur une infrastructure réelle.
* **L'IA pilote l'émulateur** — Approvisionnez un appareil émulé, modifiez sa configuration, envoyez un relevé et transférez-le vers du matériel réel, le tout en conversation.
* **Nouveautés dans le produit** — Un panneau qui vous dit ce qui a été livré, généré à partir de ce journal des modifications afin qu'il ne puisse jamais diverger de la documentation.
* **MIOTY BSSCI 1.1** — La négociation de la version du protocole permet à des stations de base plus récentes de rejoindre le même centre de service, et les identifiants de station sont acceptés sur toute la plage EUI non signée 64 bits.
* **Piste d'audit réparée** — Les composants cassés sur la page de la piste d'audit sont corrigés.
* **Corrections et peaufinage** — Période du forfait d'abonnement, correction CORS, fiabilité MIOTY, placement des widgets du tableau de bord et corrections d'interface sur les appareils et les seuils.
***
**L'Émulateur — un déploiement que vous pouvez construire avant l'arrivée des capteurs**
Les délais de livraison des capteurs se mesurent en semaines. Jusqu'à présent, le travail de configuration attendait leur arrivée : vous ne pouviez pas voir une mise à jour de tableau de bord, observer le déclenchement d'une règle ou tester si une chaîne d'escalade atteint réellement quelqu'un, car rien n'envoyait de données. L'Émulateur supprime entièrement cette dépendance. Ajoutez le connecteur — il n'a aucun réglage, rien à configurer — créez-y un appareil, et cet appareil commence à produire de la télémétrie à l'intervalle que vous choisissez.
Les relevés proviennent de **une liste intégrée de préréglages d'appareils réels**. Choisissez le modèle que vous avez commandé et l'appareil émulé rapporte exactement ce que ce capteur rapporte — les bons noms de métriques, les bons types de données — afin que les tableaux de bord et les règles que vous construisez maintenant correspondent au matériel lorsqu'il arrivera. Ou définissez les clés manuellement si votre appareil ne figure pas dans la liste. Dans l'onglet Émulateur de l'appareil, vous pouvez figer une valeur pour que l'appareil la conserve — un congélateur bloqué à −18 °C pendant que vous observez une alarme s'aggraver — ou **envoyer une seule fois** pour déclencher un seuil à la demande. Activez **Prendre en charge les commandes** et l'appareil se comporte comme du matériel contrôlable, ce qui vous permet de répéter une boucle fermée avant même que l'équipement n'existe.
Ensuite vient la partie qui en fait plus qu'une démonstration. Lorsque le matériel arrive, changez le connecteur de l'appareil de Émulateur vers le connecteur réel. **Tout ce que vous avez construit reste** — les tableaux de bord, les règles, les seuils, les chaînes d'escalade. Vous remplacez la source des données, vous ne reconstruisez pas le déploiement. L'échange fonctionne dans les deux sens, vous pouvez donc aussi déplacer un appareil réel vers l'émulateur pour reproduire un problème puis le remettre ensuite.
[→ Connecteur Émulateur](/kilo-docs-fr/kilo-iot-server/connectors/emulator-connector.md)
***
**L'IA exécute les commandes des appareils**
C'est le grand changement. Tout le monde a vu la démonstration où une lampe est reliée à un modèle de langage et s'allume — une bonne astuce, pas un système. Il n'y a derrière aucun modèle d'appareil, aucune autorisation, aucun paramètre typé, aucun état de livraison, aucun enregistrement de ce qui s'est passé. Demandez à un modèle de faire cela dans un bâtiment, une usine ou une flotte, et il doit improviser des protocoles radio, des charges utiles et des politiques d'accès à chaque appel. C'est pour cela que ces démonstrations ne quittent jamais le bureau.
La version 3.8.0 place un vrai serveur IoT derrière le modèle — et l'ouvre au client IA que vous utilisez déjà. L'assistant intégré peut **lister les commandes configurées sur un appareil, en exécuter une et vérifier l'état d'exécution**. Il en va de même pour **ChatGPT**. Il en va de même pour **Claude**. Cursor, Codex ou tout autre outil qui parle MCP aussi, via `device_command_list`, `device_command_execute` et `device_command_status`. Modifiez un intervalle de rapport, commutez un relais, ajustez un contrôleur — depuis la fenêtre que vous avez déjà ouverte, sur du matériel réel.
Ce qui rend cela sûr, c'est ce qu'il refuse de faire. Il exécute **des commandes qui existent déjà** sur l'appareil — des actions nommées avec des paramètres typés, définies délibérément par quelqu'un qui connaît l'équipement — plutôt que de composer un downlink brut. Chaque exécution passe par une confirmation explicite, car l'effet est physique. La livraison est asynchrone, donc l'état est signalé ensuite au lieu d'être supposé réussi. Et chaque envoi apparaît dans l'historique d'exécution des commandes comme n'importe quel autre.
[→ Plateforme d'IA physique](/kilo-docs-fr/kilo-iot-server/physical-ai.md) · [→ Construire avec l'IA](/kilo-docs-fr/kilo-iot-server/ai-assistant/building-with-ai.md)
***
**Contrôlez vos appareils depuis ChatGPT ou Claude**
Ce n'est pas seulement l'assistant à l'intérieur de Kilo. Connectez le client IA dans lequel votre équipe travaille déjà — **ChatGPT**, **Claude**, Cursor, Codex, tout ce qui parle MCP — connectez-vous avec votre compte Kilo habituel, et il obtient le même contrôle des appareils via `device_command_list`, `device_command_execute` et `device_command_status`.
Les garanties l'accompagnent : uniquement des définitions de commandes existantes, une confirmation avant qu'une action physique n'ait lieu, l'état de livraison signalé ensuite, et chaque envoi dans l'historique d'exécution des commandes. Ce qui change, c'est l'endroit où vous vous trouvez quand vous demandez.
[→ Serveur MCP](/kilo-docs-fr/kilo-iot-server/api/mcp-server.md)
***
**L'IA pilote l'émulateur**
L'assistant a aussi appris l'Émulateur. Il peut lister les préréglages d'appareils disponibles, approvisionner un appareil émulé, lire et mettre à jour sa configuration et son intervalle, envoyer un relevé ponctuel pour tester une règle, et faire passer l'appareil en direct sur une vraie connexion LoRaWAN lorsque le matériel arrive. Mettre en place un déploiement de test est désormais une conversation plutôt qu'un après-midi.
[→ Appareils émulés](/kilo-docs-fr/kilo-iot-server/devices/emulated-devices.md)
***
**Nouveautés, à l'intérieur du produit**
Les versions ne servent à rien si personne ne les remarque. La plateforme affiche désormais un **Nouveautés** panneau qui présente ce qui a été livré, afin qu'un changement parvienne aux personnes qui utilisent le produit au lieu de rester dans un journal des modifications qu'elles n'ouvrent jamais.
Il est généré à partir de cette page. Le journal des modifications est la source, un pipeline le transforme en flux de versions que le produit lit, et le panneau affiche les mêmes mots que ceux que vous lisez maintenant — ainsi le produit et la documentation ne peuvent pas diverger.
***
**MIOTY atteint davantage de stations de base**
MIOTY est arrivé dans la version 3.7.0. Cette version est la première étape de durcissement pour les déploiements réels. Le centre de service négocie désormais la **version du protocole BSSCI** à mesure que chaque station se connecte et prend en charge **BSSCI 1.1** aux côtés des révisions antérieures, de sorte qu'une station plus récente et une plus ancienne puissent servir le même site et qu'une mise à jour du micrologiciel ne vous coûte pas la connexion. Les identifiants de station sont acceptés sur toute la **plage EUI non signée 64 bits**, y compris les valeurs élevées que certaines plateformes rejettent carrément.
En dessous, la reprise de session, l'émission de certificats et l'envoi en downlink ont été renforcés, et les erreurs de station dupliquée et de page ont été corrigées, tout comme la possibilité de dissocier un point de terminaison MIOTY physique de son appareil numérique.
[→ Stations de base MIOTY](/kilo-docs-fr/kilo-iot-server/gateways/mioty-base-stations.md)
***
**Piste d'audit réparée**
La page de la piste d'audit comportait des composants cassés. C'est corrigé : le filtre d'acteur, le filtre de type d'événement et la plage de dates fonctionnent à nouveau, vous pouvez donc restreindre l'historique d'accès d'une organisation à la personne, au type de changement et à la période qui vous intéressent.
[→ Piste d'audit](/kilo-docs-fr/kilo-iot-server/reports/audit-trail.md)
***
**Corrections et peaufinage**
L'abonnement indique désormais correctement la période du forfait actuel, et une erreur CORS affectant l'interface est résolue. L'ajout d'un widget ne perturbe plus le placement des widgets déjà présents sur un tableau de bord. Les sujets MQTT longs ne débordent plus de leur conteneur sur mobile, le champ **Libellé** est suffisamment large pour lire ce que vous avez saisi, l'info-bulle de mappage d'appareil indique ce qu'elle signifie, et la plage autorisée pour un MIOTY **Adresse courte** est décrite de manière cohérente. La validation de type et un ensemble de correctifs de durcissement du contrôle d'accès complètent la version.
Journal des versions. Version 3.7.0
La version 3.7.0 élargit ce que la plateforme IoT Kilo atteint et renforce ce qu'elle vous dit. **MIOTY** arrive comme protocole à part entière — stations de base, points de terminaison et gabarits de charge utile — de sorte que les déploiements à très grande échelle et à forte interférence pour lesquels LoRaWAN n'a jamais été conçu fonctionnent désormais sur la même plateforme, avec les mêmes tableaux de bord et les mêmes règles. Les tableaux de bord apprennent à sortir du bâtiment : un **lien de partage** transforme n'importe quel tableau de bord en une adresse protégée par mot de passe que vous pouvez envoyer à un client ou afficher sur une tablette murale, avec un accès **Lecture** ou **Contrôle** et une révocation en un clic. **Diagnostic de l'appareil** remplace le pire moment de tout déploiement — *c'est installé, et il ne se passe rien* — par une réponse claire et l'étape suivante. **Coffre de clés** fait sortir les identifiants des appareils des feuilles de calcul. Et un **serveur MCP** permet à votre propre client IA de se connecter et de piloter directement votre déploiement. [kiloiot.io](https://kiloiot.io)
***
#### Contenu de cette version
* **Prise en charge de MIOTY** — Un nouveau connecteur, une catégorie Stations de base Mioty sous Passerelles, des champs de point de terminaison MIOTY et un système complet de blueprints pour décoder les charges utiles — avec des instantanés par appareil afin qu'une modification du catalogue ne perturbe jamais un appareil déjà en production.
* **Partager le tableau de bord** — Publiez un tableau de bord sous forme de lien protégé par mot de passe avec **Lecture** ou **Contrôle** accès. Régénérez-le ou révoquez-le à tout moment ; ouvrez-le en plein écran sur une tablette ou un affichage mural.
* **Diagnostic de l'appareil** — L'onglet Connexion d'un appareil indique désormais son état de réception, le pipeline parcouru par chaque message et un flux d'événements avec une légende d'état — et vous indique quoi vérifier en cas de problème.
* **Coffre de clés** — Un coffre-fort chiffré et contrôlé par accès pour les EUI des appareils et les paires de clés, sous le nouveau groupe **Enregistrements et rapports** avec **Ajouter au coffre** directement sur le formulaire de l'appareil.
* **serveur MCP** — Connectez le client IA que vous utilisez déjà — Claude Code, Claude Desktop, ChatGPT, Codex, Cursor — à votre organisation avec la connexion à votre propre compte, et mettez-le au travail sur votre déploiement réel.
* **Scanner un code QR** — Lisez un DevEUI ou une AppKey avec l'appareil photo d'un ordinateur portable ou d'un téléphone au lieu de taper 16 ou 32 caractères hexadécimaux.
* **Dupliquer et déplacer les widgets** — Répétez un widget configuré sur des capteurs identiques, ou déplacez-en un vers un autre tableau de bord.
* **Corrections et peaufinage** — Corrections de mise en page, mobile et navigation sur les tableaux de bord, les passerelles, les appareils et la piste d'audit.
***
**MIOTY — un second protocole pour les déploiements que LoRaWAN ne peut pas prendre en charge**
MIOTY ([ETSI TS 103 357](https://mioty-alliance.com)) est la plus récente des deux technologies LPWAN, développée à l'Institut Fraunhofer et conçue pour les environnements qui mettent la première génération en échec : des ateliers saturés d'interférences, des dizaines de milliers de points de terminaison sous un seul récepteur, des capteurs sur des machines qui ne s'arrêtent jamais. Il code chaque message, le divise en deux douzaines de rafales d'environ 15 millisecondes, puis les répartit dans la fréquence et le temps — de sorte que la station de base reconstitue tout le télégramme **même lorsque la moitié de ses rafales est détruite**. Un interférent doit faire tomber plus de 50 % d'une transmission unique, à la fois dans le temps et dans la fréquence, pour vous coûter un relevé. C'est pourquoi une station de base prend en charge jusqu'à 110 000 points de terminaison et 3,5 millions de messages par jour. Dans la version 3.7.0, elle devient une partie native de la plateforme plutôt qu'un système parallèle.
Créer un **connecteur Mioty** et un onglet **Stations de base Mioty** apparaît à côté de vos passerelles LoRaWAN. Enregistrez une station de base avec son BS EUI, téléchargez son ensemble de certificats, copiez l'adresse BSSCI, et elle se connecte via un lien sécurisé par certificat — sans répéteur de paquets entre les deux. Les points de terminaison disposent de leur propre formulaire : EUI du point de terminaison, adresse courte, clé de session réseau et les options radio MIOTY qui comptent.
**Il n'y a aucune infrastructure MIOTY à faire fonctionner.** L'édition Entreprise de notre centre de service est intégrée à Kilo Cloud, donc le connecteur constitue à lui seul toute la configuration. Cette distinction est l'objet de la version : un serveur réseau MIOTY déplace les messages et gère les stations de base — utile, mais ce n'est pas la même chose que de pouvoir *faire* quoi que ce soit avec un relevé. Ici, les points de terminaison arrivent sur une plateforme complète, donc le moteur de règles, les alarmes avec escalade, les tableaux de bord, le Jumeau numérique du bâtiment et la piste d'audit s'appliquent aux données MIOTY exactement comme à tout le reste, et une seule règle peut raisonner ensemble sur un point de terminaison MIOTY et un capteur LoRaWAN. Si vous préférez gérer le réseau vous-même, l'édition Communauté — Kilo Center — reste open source et auto-hébergée.
Le décodage des charges utiles est là où la conception montre tout son intérêt. Un **blueprint** est une spécification de décodeur liée à un type d'appareil, organisée selon fabricant → modèle → version et répartie entre un catalogue **Système** que tout le monde peut utiliser et un catalogue **Personnalisé** qui vous appartient. Choisissez-en un pour un appareil et la plateforme en prend un *instantané* sur cet appareil. Modifiez ou supprimez ensuite le modèle du catalogue et rien de déjà déployé ne change — ces appareils continuent de fonctionner avec leur propre copie jusqu'à ce que vous les déplaciez délibérément vers une nouvelle version. Deux appareils du même modèle peuvent exécuter des blueprints différents. Créez-en un nouveau à partir d'un JSON collé et testez le décodeur sur une charge utile d'exemple avant de l'enregistrer.
[→ Qu'est-ce que MIOTY ?](/kilo-docs-fr/kilo-iot-server/connectors/mioty-connector/what-is-mioty.md) · [→ Connecteur Mioty](/kilo-docs-fr/kilo-iot-server/connectors/mioty-connector.md) · [→ Stations de base Mioty](/kilo-docs-fr/kilo-iot-server/gateways/mioty-base-stations.md) · [→ Blueprints Mioty](/kilo-docs-fr/kilo-iot-server/devices/mioty-blueprints.md)
***
**Partager le tableau de bord — un lien, un mot de passe et un interrupteur d'arrêt**
Un tableau de bord s'arrêtait autrefois à la limite de votre organisation. Maintenant, ce n'est plus le cas. Ouvrez le menu d'actions d'un tableau de bord, choisissez **Partager le tableau de bord**, définissez un mot de passe et générez un lien qui ouvre le tableau de bord en plein écran pour toute personne à qui vous l'envoyez — aucun compte requis. Choisissez **Lecture** pour un client, un auditeur ou un prospect qui doit seulement voir, et rien de plus ; choisissez **Contrôle** pour la tablette fixée près de la ligne où un opérateur doit réellement faire fonctionner les appareils. Modifiez le mot de passe lorsque le public change, régénérez le lien pour invalider l’ancien, ou révoquez-le purement et simplement dès qu’un contrat prend fin — le lien cesse de fonctionner immédiatement.
[→ Partage des tableaux de bord](/kilo-docs-fr/kilo-iot-server/dashboards/sharing-dashboards.md)
***
**Diagnostics des appareils — une réponse au lieu du silence**
La mise en service échoue en silence. L’appareil est monté, le connecteur est configuré, et rien n’arrive — sans rien à inspecter hormis un graphique vide. L’onglet Connexion s’ouvre désormais avec un **état de réception** qui indique dans quelle situation réelle vous vous trouvez : *Réception et stockage*, *Envoi de données — configurez le mappage pour la conserver*, *Les données arrivent mais rien n’est stocké*, *Réseau atteint — en attente de données*, ou *N’a pas signalé — l’appareil semble hors ligne*. En dessous, une **pipeline** vue montre jusqu’où chaque message parvient, et un **flux d’événements** les répertorie étape par étape avec une légende qui explique clairement ce que signifient Routé, Mappé, Stocké, OK, Ignoré et Erreur — y compris le fait qu’Ignoré n’est souvent pas une erreur du tout. Chaque état dégradé s’accompagne d’une **liste de vérifications** et, lorsque la correction se trouve dans la plateforme, d’un bouton qui vous y conduit. Les connecteurs disposent de leurs propres diagnostics avec l’état de la source, les messages entrants et l’activité.
Ces états constituent un cycle de vie, et la documentation le dit désormais — y compris l’étape qui piège tout le monde. Un appareil LPWAN appartient à un seul réseau à la fois, donc une unité revenue d’un autre site, achetée d’occasion ou utilisée sur une autre plateforme est toujours jointe *là-bas*. L’enregistrer ici ne change rien : elle reste sur *En attente des premières données* indéfiniment tandis que tous les paramètres vérifiables sont corrects. Il faut la réinitialiser avant qu’elle n’envoie une nouvelle demande d’association. Cette réponse n’apparaissait auparavant nulle part dans la documentation, et elle fait la différence entre une correction de cinq minutes et une visite sur site.
[→ Diagnostics des appareils](/kilo-docs-fr/kilo-iot-server/devices/device-diagnostics.md)
***
**Key Vault — les clés d’appareil là où elles doivent être**
Un DevEUI et une AppKey sont imprimés sur une étiquette, saisis une fois lors de la mise en service, puis vivent dans un tableur, un fil de discussion ou le carnet d’un installateur. Quatre ans plus tard, un appareil doit être remplacé et personne ne les retrouve. Savoir si vous pouvez relire la clé depuis le matériel à ce moment-là relève de la loterie — certains fabricants la livreront via une connexion filaire, beaucoup non, et de toute façon ce n’est pas le genre de tâche que vous voulez faire sur une unité déjà à six mètres de hauteur dans une allée.
**Coffre de clés** est le carnet chiffré qui rend la question sans objet : un espace de stockage pour ces paires, limité à votre organisation, régi par sa propre permission de page, placé dans le nouveau **Enregistrements et rapports** groupe à côté de la Piste d’audit. Enregistrez une paire pendant que vous configurez un appareil avec **Ajouter au coffre**, ou saisissez-la directement ; recherchez par n’importe quel fragment d’un EUI ou d’une clé. DevEUI et AppKey LoRaWAN, EP EUI et Network Key MIOTY, au même endroit, chiffrés, avec un accès que vous contrôlez.
[→ Key Vault](/kilo-docs-fr/kilo-iot-server/reports/key-vault.md)
***
**Serveur MCP — utilisez votre propre client IA**
La version 3.6.0 a intégré un assistant IA dans la plateforme. La 3.7.0 ouvre le même déploiement au client IA que vous utilisez déjà. Pointez Claude Code, Claude Desktop, ChatGPT, Codex, Cursor — tout ce qui parle MCP — vers le point de terminaison de votre organisation, connectez-vous via le navigateur avec votre compte Kilo habituel, et votre client peut lister les appareils, provisionner le matériel, interroger la télémétrie, inspecter les règles et les alarmes, extraire les journaux et gérer votre équipe, le tout avec exactement les permissions déjà associées à votre compte. Aucune clé à copier, aucun jeton à coller. Le point de terminaison par défaut suit l’organisation que vous avez sélectionnée ; un chemin avec un identifiant d’organisation explicite le fixe à une seule, et refuse tout ce dont vous n’êtes pas membre. Comme il s’agit d’un standard ouvert plutôt que d’une intégration ponctuelle, les clients qui adoptent MCP plus tard fonctionnent sans que nous ayons quoi que ce soit à livrer.
[→ Serveur MCP](/kilo-docs-fr/kilo-iot-server/api/mcp-server.md) · [→ Assistant IA IoT](/kilo-docs-fr/kilo-iot-server/ai-assistant.md)
***
**Des petites choses qui font gagner de vraies minutes**
Enregistrer un appareil ne signifie plus recopier un AppKey de 32 caractères depuis une étiquette : **Scanner le code QR** le lit avec la caméra de votre ordinateur portable ou de votre téléphone. Les widgets configurés peuvent être **dupliqués** — une seule configuration, répétée sur une rangée de capteurs identiques — ou **déplacés vers un autre tableau de bord** lorsqu’ils dépassent leur point de départ. Et la localisation d’un appareil peut désormais être modifiée ou supprimée, et non plus seulement définie une seule fois.
[→ Enregistrement des appareils](/kilo-docs-fr/kilo-iot-server/devices/registering-devices.md) · [→ Ajout de widgets](/kilo-docs-fr/kilo-iot-server/dashboards/adding-widgets.md)
***
**Corrections et peaufinage**
Cette version corrige aussi plusieurs problèmes de mise en page et de navigation : les tableaux de bord s’adaptent désormais correctement aux grands écrans au lieu de casser leur mise en page, le formulaire de photo de passerelle correspond au reste de la plateforme, le contrôle de plage de dates de la Piste d’audit est à sa place, le flux d’ajout d’appareil fonctionne correctement sur un téléphone, et les liens Conditions d’utilisation et Politique de confidentialité fonctionnent de nouveau.
Journal des évolutions. Version 3.6.0
La version 3.6.0 est celle où le Kilo IoT Server devient **prioritairement IA**. L’assistant intégré — **AIoT**, l’Intelligence artificielle des objets câblée au cœur de la plateforme — cesse d’être une simple boîte de dialogue et commence à fonctionner comme un intégrateur IoT expérimenté à vos côtés : posez vos questions en langage clair et il provisionne les appareils, écrit le CEL, construit et déploie des règles, et met en place des alarmes, le tout sous votre confirmation. Et le moteur de règles se dote de mains à lui tout seul — un nouveau **Exécuter la commande** nœud permet à une règle d’agir sur un appareil dès qu’une condition est remplie, de sorte qu’une fuite ne déclenche plus seulement une alarme, mais peut couper l’eau. De nouvelles API de commande publiques complètent une version qui rend la plateforme à la fois plus intelligente et plus puissante. [kiloiot.io](https://kiloiot.io)
***
#### Contenu de cette version
* **AIoT — un intégrateur IA intégré à la plateforme** — Ancré dans votre déploiement réel, l’assistant répond à partir de vos vraies données et travaille avec vous : provisionnement des appareils, écriture et déploiement de règles, et création d’alarmes avec escalade — en confirmant avant tout changement ayant des conséquences et en vérifiant ses propres résultats.
* **Commandes dans le moteur de règles** — Un nouveau **Exécuter la commande** nœud transforme l’automatisation en voie bidirectionnelle : une règle peut envoyer une commande directement à un appareil lorsque les conditions sont remplies. Saisir, décider, agir — de bout en bout, sans intervention humaine.
* **API publiques de commande** — Les points de terminaison de commande des appareils font désormais partie de l’API REST publique, avec de nouveaux `Commandes` scopes de lecture et d’écriture pour les clés d’API.
* **Widget de tableau de bord iFrame** — Intégrez une page web externe — un rapport BI, une carte météo, le trafic en direct — directement sur un tableau de bord, à côté de vos données d’appareil.
* **Journaux des appareils plus clairs** — Les journaux sont désormais regroupés par minute, et un indicateur d’état dans l’en-tête de l’appareil montre en un coup d’œil l’état de connexion et l’activité de journalisation en direct.
* **Interface portugaise** — L’interface de la plateforme est désormais disponible en portugais.
* **Corrections et peaufinage** — Une série de corrections de stabilité et de connexion dans les organisations, les alarmes et les clés d’API.
***
**AIoT — votre plateforme, pilotée comme par un intégrateur**
C’est le titre de la 3.6.0, et cela change ce que la plateforme *est*. Nous avons été parmi les premiers à mettre un chat IA au-dessus des données d’appareils — puis nous avons marqué une pause, et au lieu d’aller trop vite, nous avons construit correctement l’infrastructure en dessous : un runtime d’agent de niveau entreprise qui connaît votre déploiement de bout en bout et effectue un vrai travail à l’intérieur. Ouvrez-le depuis **Chat IA** dans la barre latérale et briefez-le comme un collègue.
Il répond à partir de vos données en direct, limité à vos permissions — *« quels appareils n’ont pas signalé depuis 24 heures ? »* — et il agit : décrivez une automatisation et il conçoit la règle, écrit le [CEL](https://cel.dev), la teste et la déploie ; demandez-lui d’intégrer un appareil ou de mettre en place une alarme et il exécute le flux, en s’arrêtant pour votre **Confirmer l’action** avant tout changement ayant des conséquences et en relisant le résultat pour vérifier son propre travail.
C’est le début, pas la ligne d’arrivée : l’architecture est en place, et la précision ainsi que la portée de l’assistant augmentent à mesure que ses agents sont entraînés sur davantage de tâches IoT réelles. Le runtime sous-jacent est [Synthetic Brew](https://syntheticbrew.ai), conçu en interne comme un produit à part entière plutôt que comme un chatbot greffé sur l’API de quelqu’un d’autre.
[→ Assistant IA IoT](/kilo-docs-fr/kilo-iot-server/ai-assistant.md)
***
**Commandes dans le moteur de règles — une automatisation qui agit**
Jusqu’à présent, le moteur de règles pouvait surveiller et avertir ; désormais, il peut agir. Le nouveau **Exécuter la commande** nœud envoie une commande directement à un appareil dès qu’une règle remplit ses conditions — refermant la boucle que la plateforme laissait auparavant à un humain. Une fuite détectée dans un local technique signifiait autrefois une alarme et une course vers la vanne d’arrêt ; désormais, la même règle ferme elle-même la vanne et déclenche l’alarme dans la même évaluation. Une chambre froide qui se réchauffe déclenche sa propre correction de consigne. Une cuve à un niveau haut ferme son entrée. Choisissez l’appareil cible et l’une de ses commandes existantes, définissez chaque paramètre comme une valeur fixe ou une expression CEL pilotée par la lecture en direct, et la règle fait le reste — consigné dans l’historique d’exécution de l’appareil comme n’importe quelle autre commande.
[→ Exécution des commandes d’appareil](/kilo-docs-fr/kilo-iot-server/rules-engine/running-device-commands.md) · [→ Commandes des appareils](/kilo-docs-fr/kilo-iot-server/devices/commands.md)
***
**API publiques de commande**
Les points de terminaison de commande des appareils sont désormais exposés sur l’API REST publique, afin que des systèmes externes puissent définir et envoyer des commandes par programme. Deux nouveaux scopes — **Commandes : lecture** et **Commandes : écriture** — vous permettent d’accorder à une clé exactement l’accès aux commandes dont elle a besoin, et pas davantage.
[→ API REST publique](/kilo-docs-fr/kilo-iot-server/api/public-rest-api.md) · [→ Clés d’API](/kilo-docs-fr/kilo-iot-server/settings/api-keys.md)
***
**Widget iFrame — contexte externe sur le tableau de bord**
Tout ce qu’une équipe d’exploitation surveille ne provient pas d’un capteur. Le nouveau **iFrame** widget intègre une page web externe en direct directement dans une tuile de tableau de bord, de sorte qu’un rapport BI d’entreprise, une carte météo régionale, une vue du trafic en direct ou la page d’état d’une dépendance se trouve à côté de vos données d’appareil au lieu d’être dans un autre onglet du navigateur. Choisissez **iFrame** dans le sélecteur de widgets, collez l’URL d’intégration fournie par la source sous *Partager → Intégrer* — juste le `https://` lien, pas tout le `
