KNX IoT : que change cette évolution pour le Smart Building ?

Le terme KNX IoT ne désigne pas simplement une application cloud ajoutée à une installation KNX. Il correspond à une évolution du standard visant à faciliter l’intégration d’objets et d’interfaces sur des réseaux IP, en complément de l’écosystème KNX existant (source KNX : KNX Technology). Pour un bâtiment intelligent, la bonne question est celle des usages ciblés et des compatibilités réellement disponibles au moment du projet.

Photo by Sasha Pleshco on Unsplash

Synthèse pour décideur (Maroc)

• KNX IoT ajoute des briques IP (modèle d’information, API, routeur) qui peuvent faciliter une intégration… si les produits choisis les supportent effectivement et si le projet cadre l’exploitation (sources KNX : KNX IoT Downloads ; KNX Technology).
• Ce n’est pas une “migration automatique”. Une installation KNX existante ne devient pas KNX IoT sans composants compatibles (routeur / serveur d’API / appareils). Les scénarios locaux restent à préserver.
• Le vrai risque est opérationnel. Gouvernance des accès, mises à jour, sauvegardes, et coordination IT/OT (informatique vs systèmes techniques) doivent être posées en livrables de projet (périmètre, responsabilités, recette).

Pourquoi faire évoluer le protocole

Les bâtiments intègrent davantage de capteurs IP, de supervision (GTB/BMS) et de services analytiques. KNX IoT s’inscrit dans cette trajectoire en proposant des briques orientées IP (modèle d’information et API) et des rôles d’interconnexion avec l’écosystème KNX existant (source KNX : KNX Technology).

Important : KNX IoT ne se réduit pas à une application mobile ou à un service cloud. Dans un projet, KNX TP (Twisted Pair, bus filaire) et KNX RF (radio) peuvent rester en place ; l’ajout d’interfaces ou d’équipements KNX IoT se fait via des composants compatibles (routeur, serveur, appareils), à préciser selon les références retenues (source KNX : KNX Technology).

Ce que KNX IoT change concrètement pour un Smart Building

Pour un décideur (maître d’ouvrage, AMO, exploitant, DSI), l’enjeu n’est pas « d’avoir de l’IoT », mais de cadrer ce qui change dans l’architecture : effort d’intégration, gouvernance des données, cybersécurité, et exploitabilité sur 5 à 10 ans. Les bénéfices ci-dessous doivent être lus comme des hypothèses à confirmer sur vos références produit, votre GTB/BMS et votre périmètre d’intégration (cadres officiels listés par KNX : KNX IoT Downloads).

• Intégration SI/GTB potentiellement plus accessible côté API. KNX présente un KNX IoT API Server comme un composant exposant une API à des clients tiers autorisés, à partir du KNX Information Model (KIM) exporté par ETS6 (source KNX : KNX Technology). Le gain projet (temps d’intégration, couverture de points) reste à démontrer par un pilote et dépend du serveur choisi, des fonctions exposées et des contraintes d’intégration de la GTB/BMS.
• Reprise des points : un objectif, pas une promesse. Un modèle d’information (KIM) peut aider à structurer la sémantique (noms, unités, fonctions) lors d’une intégration (source KNX : KNX Technology). La réduction de l’effort de “mapping” n’est envisageable que si le KIM est correctement renseigné, si les conventions de nommage sont alignées et si l’application consommatrice exploite réellement ces informations.
• Exigences réseau plus proches de l’IT. L’introduction de composants IP (serveur d’API, routeur, appareils IoT) amène des sujets concrets de réseau (adressage, segmentation, services d’infrastructure, journalisation), à traiter tôt avec la DSI et l’intégrateur.
• Maintenance à cadrer (MCO). Le MCO (maintien en conditions opérationnelles) recouvre notamment la gestion des mises à jour, des identifiants/certificats, des sauvegardes et du monitoring des composants IP. Sans gouvernance, une interface d’intégration peut devenir un point de fragilité en exploitation.
• Dépendances produit et maturité marché. KNX liste plusieurs frameworks KNX IoT (KIM, 3rd Party API, Point API, Router) mais chaque produit n’implémente pas nécessairement toutes les possibilités : il faut vérifier la compatibilité réelle sur les références consultées (source KNX : KNX IoT Downloads).
• Cybersécurité : surface d’exposition accrue si mal intégrée. Toute interface IP (serveur, routeur, API) peut augmenter les risques (accès non autorisé, mouvements latéraux, indisponibilité). La valeur de KNX IoT se concrétise lorsque la sécurité et l’exploitation sont traitées comme des livrables de projet (architecture, responsabilités, preuves de recette).

Les frameworks KNX IoT : ce qui est attesté et ce qui doit être confirmé

Le site support de KNX liste explicitement les frameworks suivants : KNX Information Model (KIM), KNX IoT 3rd Party API, KNX IoT Point API et KNX IoT Router (source KNX : KNX IoT Downloads).

En parallèle, KNX décrit sur sa page institutionnelle :

• des appareils KNX IoT Point API sur IP (la page mentionne explicitement IPv6) ;
• un KNX IoT Router comme passerelle entre KNX TP/RF/IPv4 et des dispositifs KNX IoT ;
• un KNX IoT API Server utilisant le KIM exporté par ETS6 pour exposer une API à des clients tiers (source KNX : KNX Technology).

Point d’attention (important pour la décision) : la page « KNX Technology » atteste le rôle du KNX IoT API Server, mais ne démontre pas dans ce dossier la relation normative exacte entre cet « API Server » et le framework « KNX IoT 3rd Party API » listé sur la page « Downloads ». Dans un cahier des charges, il est donc préférable de les traiter séparément : d’une part un rôle produit (API Server), d’autre part un cadre de spécification (3rd Party API), à confirmer sur la documentation du fabricant retenu et les références visées (source KNX : KNX IoT Downloads).

KNX IoT Point API et 3rd Party API : distinguer les finalités (avec prudence)

Sur la base d’une source secondaire (SDK/éditeur), Nordic Semiconductor propose le positionnement suivant (à lire comme illustratif, non normatif) :

• Point API : plutôt orientée vers des appareils/participants KNX IoT (vue “device”).
• 3rd Party API : plutôt orientée vers des applications tierces (vue “app/IT”).

Cette lecture est cohérente avec l’existence des deux frameworks sur la page KNX « Downloads » (source KNX : KNX IoT Downloads), mais la terminologie, la portée et les détails doivent être confirmés dans les spécifications KNX correspondantes et/ou la documentation des produits choisis (source secondaire : Introduction KNX IoT (Nordic)).

Interagir avec l’existant KNX TP

Une installation KNX déjà en service ne devient pas automatiquement KNX IoT : des équipements ou interfaces compatibles sont nécessaires. L’objectif, côté exploitation, est de préserver les scénarios locaux et la programmation existante, tout en ajoutant des capacités d’intégration.

Une villa, un immeuble de bureaux ou un hôtel déjà équipé de KNX TP ne doit pas être entièrement reconstruit pour envisager de nouvelles interfaces. Une architecture peut s’appuyer sur un routeur/serveur KNX IoT compatible tout en conservant les fonctions locales existantes, sous réserve de compatibilité produit et de conception réseau (source KNX : KNX Technology).

Interopérabilité et modèles de données

Un modèle de données structuré permet de mieux décrire fonctions et propriétés. Mais sa richesse n’efface ni les différences fonctionnelles entre fabricants, ni l’exigence de tests d’intégration (interop).

Le KNX Information Model (KIM) est présenté par KNX comme exporté par ETS6 et utilisé par le KNX IoT API Server pour exposer une API aux clients tiers (source KNX : KNX Technology). Pour une intégration de supervision, l’intérêt est d’avoir une sémantique (température, commande, état, mesure) mieux décrite que de simples adresses. En contrepartie, la qualité du résultat dépend du travail de configuration (conventions, unités, cohérence) et de la capacité des applications à exploiter ces informations.

Prérequis et risques à cadrer (à réutiliser dans le cahier des charges)

• Compatibilité réelle. Valider, sur les références exactes (SKU), quels frameworks KNX IoT sont effectivement supportés et à quelles versions (source KNX : KNX IoT Downloads).
• Périmètre d’API. Définir à l’avance ce qui doit être lisible/commandable, par qui, et depuis quel réseau (IT/OT), plutôt que de supposer qu’« une API » donnera accès à « tous les points ».
• Dépendance à une brique IP. Documenter les modes dégradés : que se passe-t-il si le routeur, le serveur d’API ou la supervision est indisponible ?
• MCO et transfert d’exploitation. Prévoir procédures de sauvegarde/restauration, inventaires de versions, habilitations, et conditions d’intervention.

Cybersécurité (et limites de ce guide)

Prévoir identités, mises à jour, gestion des clés, segmentation et contrôle des interfaces. Réduire les accès distants exposés et documenter les flux entre réseau métier et systèmes techniques (IT/OT).

Les équipements IP (serveur d’API, routeur, passerelles, postes d’administration) créent des exigences de segmentation, d’identités et de mise à jour. L’architecture KNX IoT doit être alignée avec la politique de cybersécurité du site et documenter les modes de fonctionnement locaux et de secours.

Sur le plan réglementaire marocain, la loi n°05-20 et son décret d’application constituent un cadre général dont l’applicabilité dépend de la catégorie d’entité/activité concernée : c’est donc un point de qualification projet, à traiter avec les parties prenantes (sources : ANRT – Loi 05-20 (PDF) ; ANRT – Décret n°2-21-406).

Limite : ce passage est une aide au cadrage et ne constitue pas un avis juridique. L’interprétation et l’applicabilité se déterminent au cas par cas, selon le contexte du projet et les parties impliquées.

Bonnes pratiques de cadrage (exemples contractuels, non normatifs)

• Segmentation réseau. Séparer réseau invités / bureautique / techniques (ex. VLAN) et limiter les flux nécessaires (ACL). Le design exact est à valider avec la DSI et l’intégrateur réseau.
• Administration durcie. Comptes nominatifs, principe du moindre privilège (lecture vs commande), révocation possible, et gestion des secrets selon la politique interne.
• Mises à jour et gestion des vulnérabilités. Définir qui met à jour quoi (routeur, serveur API, équipements), fréquence, fenêtre de maintenance et procédure de retour arrière (à valider avec les fabricants et l’exploitant).
• Journalisation. Logs d’accès, d’authentification, d’erreurs et d’actions de commande (au minimum sur le serveur/API). Rétention et export à cadrer avec les contraintes IT.
• Sauvegardes et reprise. Sauvegarde du projet ETS, des paramètres serveur/API et de la configuration réseau associée. Tester une restauration sur un environnement de recette quand c’est possible.
• Accès distant maîtrisé. Éviter l’exposition directe ; privilégier des mécanismes de l’entreprise (VPN/bastion) si la politique interne le requiert. Point à valider avec les responsables sécurité.

Cas d’usage

Examiner capteurs connectés, exploitation multi-bâtiments, visualisation énergétique, intégration à une GTB et diagnostics. Choisir les fonctions qui ont une valeur opérationnelle au lieu de déployer IoT pour l’étiquette.

Les cas pertinents concernent notamment l’accès à des données de bâtiment et les applications qui exploitent une API documentée. Le bénéfice doit se mesurer sur un usage précis (ex. réduire un développement spécifique), pas sur une promesse vague d’intelligence supplémentaire.

Coexistence avec KNX Secure : questions à poser

La sécurité d’une architecture dépend des composants réellement installés (supports, passerelles, serveurs, paramétrage) et de leur administration. Faute d’une source primaire ouverte décrivant précisément l’articulation technique entre KNX Secure et KNX IoT dans ce dossier, cette section est volontairement ramenée à des questions de projet à traiter avec les fabricants et l’intégrateur :

• Quels liens (segments/médias) doivent être sécurisés, et par quels mécanismes supportés par les composants choisis ?
• Quels sont les périmètres d’accès (lecture/commande) exposés via les interfaces IP, et comment sont-ils tracés (logs) ?
• Quels modes dégradés sont acceptables si une brique IP (serveur d’API, supervision) devient indisponible ?

Pour cadrer KNX IoT, se référer aux frameworks listés officiellement (KIM / APIs / Router) et à leurs versions (source KNX : KNX IoT Downloads).

Feuille de route d’adoption

Identifier produits certifiés, versions d’ETS (Engineering Tool Software, l’outil de configuration KNX) et outils requis, support fabricant, disponibilité au Maroc, formation et procédures de reprise avant d’inclure un dispositif dans un cahier des charges.

Avant de déployer KNX IoT, inventoriez les appareils réellement disponibles, vérifiez les versions des frameworks KNX IoT et la compatibilité ETS, puis réalisez un pilote sur un périmètre limité. La page support KNX liste les frameworks et leurs versions (source KNX : KNX IoT Downloads) ; elle permet au minimum d’aligner un cahier des charges sur des intitulés/versions publiés, sans extrapoler au-delà des produits.

Décideurs au Maroc : critères d’achat et d’exploitabilité

• Disponibilité réelle des références. Exiger les références exactes (SKU), délais, SAV et chaîne de support local. En cas d’import, clarifier délais de pièces et conditions.
• Compétences et continuité. Vérifier la capacité de l’écosystème (intégrateur, électricien, GTB, DSI) à maintenir ETS et les composants IP (sauvegardes, mises à jour, gestion des accès) sur la durée.
• DOE/as-built exploitable. Le DOE (dossier des ouvrages exécutés / dossier “as-built”) doit inclure des livrables utilisables par l’exploitation : export des points, nomenclature, schémas réseau, règles d’accès, procédures de sauvegarde/restauration. Langue des documents à définir contractuellement (FR/AR/EN) selon l’organisation.
• Coordination DSI / GTB. Dès les phases d’étude (APS/APD : avant-projet sommaire / avant-projet détaillé), clarifier qui fournit VLAN, IP, DNS/NTP, politique de certificats, accès distant, et comment sont validés les flux.
• Objectifs énergie et multi-sites. Si l’objectif est le suivi énergie, définir en amont les données nécessaires (comptage, granularité, rétention, fréquence), plutôt que d’acheter une API sans besoin précis.
• Clauses de maintenance. SLA (accord de niveau de service), fenêtres de maintenance, responsabilité des mises à jour et tests de non-régression (à ajuster selon criticité du bâtiment).

KNX IoT Point API, KNX IoT Router, 3rd Party API et API Server : rôles distincts

Les téléchargements KNX IoT officiels donnent des versions publiées et des statuts (release/outdated/WIP). Pour limiter le risque, retenez une version publiée et supportée par les références choisies : toutes les fonctions décrites par un cadre ou une spécification ne sont pas nécessairement implémentées dans les produits disponibles.

La page d’actualité KNX sur une version du standard peut servir de repère de temporalité ; elle ne remplace pas la vérification des versions/frameworks réellement applicables au moment du projet ni la lecture de la documentation fabricant.

KNX IoT vs passerelle KNX IP classique vs standards GTB : comment décider

Dans un cahier des charges, le bon choix dépend de l’objectif (supervision, énergie, multi-sites, interop GTB) et des contraintes (DSI, sécurité, planning, budget). Le tableau ci-dessous sert de grille de décision indicative : il ne remplace pas une étude d’architecture.

À noter : les comparaisons avec Matter, BACnet ou d’autres protocoles dépendent du périmètre (logement, tertiaire, CVC, supervision). Elles doivent être cadrées au cas par cas pour éviter les “fausses équivalences” techniques.

Exemple d’architecture pour un bâtiment connecté

Exemple illustratif : imaginons une installation KNX TP existante assurant l’éclairage et les stores, à laquelle le maître d’ouvrage souhaite ajouter un outil de suivi des consommations. Lorsque l’architecture retient un KNX IoT API Server et que celui-ci est effectivement compatible avec les références installées, l’objectif peut être de s’appuyer sur le KIM exporté par ETS6 pour structurer les données exposées à une application (source KNX : KNX Technology).

L’exploitant doit pouvoir conserver les commandes essentielles KNX TP lorsque l’API ou le serveur analytique devient indisponible. Les échanges informatiques servent alors au reporting et à la supervision, sans créer une dépendance inutile pour l’éclairage local.

Pour un projet neuf utilisant des équipements IoT natifs, la conception doit tenir compte du réseau IP et des exigences d’exploitation (segmentation, comptes, sauvegardes). Les détails de transport et de sécurité doivent être confirmés sur les fiches produits et les spécifications réellement applicables : ne pas les déduire par défaut du seul terme « KNX IoT » (cadres listés : KNX IoT Downloads).

Cybersécurité et recette d’une intégration KNX IoT

Un serveur d’API d’installation peut donner une visibilité importante sur les données du bâtiment. Définir les clients autorisés, les droits de lecture ou de commande, l’authentification, la gestion des certificats ou jetons, et les possibilités de révocation. Les services d’administration ne doivent pas être accessibles librement depuis le réseau invité.

À la réception, vérifier au minimum les états, les commandes autorisées, les données incohérentes, les pertes de connexion, les reconnexions, les droits expirés et la réaction en cas d’indisponibilité d’un composant (routeur/serveur/API). Les sauvegardes doivent couvrir le projet ETS et les paramètres nécessaires aux interfaces IP, selon les outils réellement utilisés.

Scénarios de recette (exemples de contrôles)

• Recette fonctionnelle. Lecture de points (états/mesures), commande de points autorisés, cohérence unités/échelles, latences observées.
• Recette des droits. Un compte “lecture seule” ne peut pas commander ; un compte “exploitation” ne peut pas modifier la configuration ; preuve par tests.
• Recette de résilience. Arrêt du serveur/API : l’installation KNX continue de fonctionner localement ; au retour, resynchronisation maîtrisée.
• Recette réseau. Vérifier que seuls les flux nécessaires passent entre VLAN/segments (validation conjointe DSI + intégrateur).
• Recette MCO. Sauvegarde/restauration documentée ; procédure de mise à jour (pré-prod si possible) ; inventaire des versions.

Points à retenir avant consultation

• Définir les fonctions réellement attendues et les risques d’exploitation (disponibilité, commande non autorisée, dépendance SI).
• Comparer les solutions sur une base identique, en demandant les conditions réelles de mise en œuvre (matériels, licences, MCO, limites connues).
• Prévoir le réseau et la maintenance dès les études, avec coordination DSI/GTB (APS/APD) et une matrice de responsabilités.
• Vérifier les références des équipements, leurs versions/frameworks KNX IoT annoncés et la documentation applicable (source cadre/versions : KNX IoT Downloads).
• Tester les scénarios normaux et dégradés avec l’exploitant, et conserver l’autonomie des fonctions critiques.
• Remettre des sauvegardes et documents exploitables (DOE) et former les personnes concernées.

Questions fréquentes

KNX IoT remplace-t-il le bus KNX filaire ?

Non. KNX présente KNX IoT comme une extension de l’écosystème, avec des composants et participants orientés IP, pouvant s’articuler avec KNX TP et KNX RF via les équipements appropriés (source KNX : KNX Technology).

Faut-il un accès Internet pour chaque commande ?

Pas par principe. Selon l’architecture, les fonctions peuvent opérer sur le réseau local. En revanche, certaines applications cloud peuvent introduire des dépendances supplémentaires (comptes, disponibilité, mises à jour) : ces dépendances doivent être explicitement documentées au contrat/projet.

La 3rd Party API signifie-t-elle que tous les logiciels peuvent tout commander ?

Non. Les droits (lecture/commande), le périmètre exposé et les mécanismes d’accès dépendent du serveur/API choisi et de son paramétrage. En pratique, l’accès doit être restreint et journalisé selon les politiques IT/OT.

Comment sélectionner des produits pour un projet au Maroc ?

Vérifier la documentation produit, la compatibilité effective avec les frameworks/versions KNX IoT visés (cadres listés par KNX : KNX IoT Downloads), les médias supportés, le support fabricant, la disponibilité locale, et les conditions d’exploitation (DOE, SLA, MCO) des références concrètes.

Conclusion

KNX IoT peut apporter des briques IP utiles (modèle d’information, API, routeur) pour interfacer un bâtiment KNX avec des applications et une GTB, à condition de choisir des produits compatibles, de cadrer l’exploitation et de valider par un pilote (sources KNX : KNX Technology ; KNX IoT Downloads). Pour poursuivre la réflexion, consultez standard KNX et comparaison des protocoles.

À propos / Contact

Pour cadrer une architecture, un pilote et les livrables d’exploitation (DOE, procédures de sauvegarde/restauration, recette), vous pouvez étudier votre projet avec Domocasa.