Audit ‘santé’ d’une installation KNX existante (avec ETS ou partiel) avant extension

Illustration générée par IA — visuel conceptuel.

Étendre une installation KNX existante (nouvelles zones, éclairage, stores, CVC, scénarios, supervision, accès distant) peut très bien se passer… à condition de savoir dans quel état réel se trouve l’existant. Sur une villa, le risque n’est pas seulement “technique” : une extension menée sans diagnostic peut rendre le système moins fiable, plus difficile à maintenir, voire dépendant d’un seul prestataire.

Ce guide propose un protocole d’audit “santé KNX” orienté extension (avec projet ETS complet, partiel, ou absent), une checklist et une manière de classer les constats par gravité, afin de décider quoi corriger avant d’ajouter des fonctions.

Pourquoi un audit “santé KNX” avant extension change le résultat

Sur le papier, une extension KNX consiste à “ajouter des participants” et “créer des adresses de groupe”. Sur le terrain, elle dépend d’au moins quatre piliers :

• Le bus KNX (TP) : alimentation, segmentation, stabilité, charge réelle, symptômes intermittents.
• Le projet ETS : qualité de la structure, cohérence avec le terrain, noms, commentaires, sauvegardes.
• La couche IP (si présente) : interfaces KNX/IP, réseau, multicast, accès à distance, modes dégradés.
• La maintenabilité : DOE, sauvegardes, traçabilité des changements, reprise par un tiers.

L’audit “santé” vise donc un objectif concret : réduire l’incertitude avant de toucher aux fonctions, pour que l’extension soit chiffrable, testable, et maintenable.

Ce qu’on fige avant de toucher quoi que ce soit

Avant d’ajouter des fonctions, il faut se donner un point de retour. Même si la documentation est imparfaite, ce “gel” initial évite de dégrader un système qui fonctionne déjà.

Qualifier le niveau de “matière première” ETS

• Cas A — Projet ETS complet et ouvrable : audit = aligner ETS / terrain + tests ciblés + plan d’extension.
• Cas B — Projet ETS partiel : audit = aligner ETS / terrain + remise à niveau (noms, topologie, IP, Secure, sauvegardes) avant extension.
• Cas C — Projet ETS absent : audit = inventaire terrain + cartographie + stratégie de reprise (avec limites à expliciter).

Si vous êtes dans le cas C, l’article Reprendre une installation KNX sans projet ETS vous aide à cadrer ce qui est réaliste (et ce qui ne l’est pas) avant toute promesse.

Sauvegarde “avant intervention” : ce qu’il faut viser (même en reprise)

• Exporter le projet ETS au format .knxproj dès que possible (si ETS est disponible).
• Identifier la version ETS utilisée (utile pour la reprise et les imports).
• Mettre en place une routine de sauvegarde (archive / copies datées) dès la phase d’audit, pas “après l’extension”.

À ce stade, l’objectif n’est pas de produire un “DOE parfait”, mais d’empêcher une situation classique : une extension commence, et on découvre trop tard que personne ne possède un projet ETS exploitable. Pour cadrer les livrables attendus au-delà d’ETS, voir aussi DOE domotique : quels documents et sauvegardes le client doit-il recevoir ?.

Protocole d’audit “santé KNX” avant extension (terrain + ETS + réseau)

Le protocole ci-dessous est volontairement structuré comme une démarche d’ingénierie : inventorier → vérifier → tester → classer → décider. Il s’applique à une villa, qu’elle soit occupée ou non, et s’adapte selon la disponibilité d’ETS.

Bloc 1 — Inventaire physique (ce qui existe vraiment)

Objectif : obtenir une cartographie “as-built” minimale, même si elle est schématique.

• Tableaux / armoires : alimentations KNX, coupleurs, actionneurs, passerelles (CVC, DALI, etc.).
• Couche IP : interfaces KNX/IP, routeurs KNX/IP, serveur de supervision/visualisation, placement réseau (baie, switch, VLAN).
• Points critiques d’exploitation : accès à la baie, repérage, état général, signes de reprises successives (ajouts non documentés).

Livrable minimal : un schéma de principe (lignes/segments, équipements principaux, interfaces IP) + un inventaire (références, emplacement, rôle).

Bloc 2 — Audit ETS (qualité du projet et cohérence)

Objectif : mesurer la capacité du projet à être maintenu/étendu sans dérive.

• Structure : lignes, zones, participants, cohérence globale.
• Nommage et commentaires : pièces, fonctions, adresses de groupe (GA) compréhensibles par un tiers.
• Écarts ETS ↔ terrain : participants physiquement présents mais absents ETS, appareils “cassés”, incohérences d’adresses.
• Traçabilité : existence d’une version “as-built” (et pas seulement une version “chantier”).

Point de méthode : l’audit ne consiste pas à “rendre ETS beau”. Il sert à déterminer si l’extension peut être menée en confiance, et quelles actions documentaires sont indispensables pour éviter un système dépendant d’un seul intervenant (voir Maintenance KNX : comment garantir qu’une installation restera maintenable dans 10 ou 15 ans ?).

Bloc 3 — Santé du bus KNX TP (alimentation, stabilité, symptômes)

Objectif : s’assurer que le bus est stable avant d’augmenter le trafic (nouveaux participants, nouvelles scènes, nouvelles intégrations).

• Alimentations : identification, rôle par ligne, indices de défaut (selon l’équipement, LED/contacts/diagnostics disponibles).
• Segmentation réelle : quelles zones sont sur quelles lignes (et si cela correspond à ETS).
• Symptômes : pertes intermittentes, comportements “fantômes”, équipements parfois injoignables, instabilités lors de programmations.

Important : l’audit doit distinguer ce qui relève d’un problème de bus (alimentation/segment) et ce qui relève d’un problème de couche IP (routeur/switch/multicast). Sans cette séparation, on “corrige” au mauvais endroit.

Bloc 4 — Topologie logique et couplage (lignes, zones, circulation des télégrammes)

Objectif : éviter que l’extension n’ajoute de la charge au mauvais endroit.

• Coupleurs/routeurs : présents, fonctionnels, cohérents avec la structure ETS.
• Effets d’une extension : ajout d’une zone (ex. pool house) = nouvelle ligne ? nouvelle alimentation ? nouveau couplage ?

Si l’installation a évolué par ajouts successifs, c’est souvent ici que l’audit met en évidence une architecture “à plat” (tout sur une même ligne) qui devient fragile à la moindre extension.

Bloc 5 — KNX IP et réseau (ETS, supervision, accès distant)

Objectif : vérifier que la couche IP ne sera pas le point faible de l’extension.

• Interfaces KNX/IP : rôle (tunneling ETS, routage KNXnet/IP, accès supervision), emplacement et adressage.
• Réseau : segmentation logique, cohérence des switches/baies, dépendances Wi‑Fi si supervision mobile.
• Multicast : en KNXnet/IP, certains usages s’appuient sur du multicast (à vérifier selon l’architecture). Un réseau mal préparé peut provoquer des comportements instables (découverte aléatoire, supervision qui “freeze”, downloads irréguliers).
• Accès distant : vérifier qu’il existe une méthode maîtrisée (et réversible), plutôt qu’une exposition directe du système.

Si la villa utilise des fonctions IP (supervision, accès distant, interconnexions), l’audit doit inclure une discussion “modes dégradés” : que se passe-t-il si Internet tombe ? Si le réseau local tombe ? Si la supervision tombe ? Ce point rejoint la logique de recette décrite dans Réception d’une installation domotique : que faut-il tester avant de prendre possession d’une villa ?.

Bloc 6 — KNX Secure (si présent… ou si on veut l’introduire)

Objectif : ne pas “ajouter Secure” sur un existant non stabilisé, et ne pas étendre une installation Secure sans une gouvernance claire des clés.

• Périmètre actuel : quels équipements/fonctions sont Secure, lesquels ne le sont pas.
• Impact extension : quelles nouvelles adresses de groupe seront sécurisées, qui détient les informations nécessaires à la maintenance.
• Procédures : sauvegardes, remise au client, capacité de reprise par un tiers (sinon Secure peut devenir un verrou involontaire).

Pour cadrer la couche Secure et son articulation avec l’architecture globale (réseau, accès, sauvegardes), voir KNX Secure : comment sécuriser une installation domotique professionnelle ?.

Bloc 7 — Interfaces (CVC, éclairage, passerelles, supervision)

Objectif : vérifier les interfaces avant de promettre une extension de fonctions.

• CVC : quelles commandes/retours sont réellement disponibles (cela dépend de la climatisation et de l’interface).
• Éclairage : variation, DALI éventuel, cohérence des scènes et retours d’état.
• Supervision : dépendances (serveur local, licences, comptes), sauvegardes, comportement en panne.

Règle simple : une extension “fonctionnelle” (nouvelle scène, nouvelle logique) doit être traitée comme un mini-projet, avec une recette. Une extension “matérielle” (nouvel actionneur) ne garantit rien si l’interface métier (CVC, éclairage) n’a pas été auditée.

Bloc 8 — Exploitation : ce qui rend la villa maintenable après extension

Objectif : transformer l’audit en capacité de maintenance, pas en rapport “qui finit dans un tiroir”.

• DOE et fichiers : ETS, schémas, repérage, inventaire, exports de configurations annexes (supervision/passerelles si possible).
• Runbook : qui appeler, où sont les sauvegardes, comment donner (ou retirer) un accès prestataire, comment faire une restauration.
• Traçabilité des changements : versioning du projet ETS et des principales configurations.

Checklist d’audit avec niveaux de gravité (A/B/C/D)

La valeur d’un audit “santé” tient à sa capacité à prioriser. Voici une grille de gravité typique (à adapter à votre villa et à vos objectifs d’extension).

Niveau	Signification	Décision avant extension
A — Bloquant	Risque direct d’instabilité, de perte de contrôle, ou d’impossibilité de retour arrière.	À corriger avant d’ajouter des fonctions.
B — Majeur	Extension possible mais seulement avec actions compensatoires et périmètre limité.	À traiter dans le plan de remédiation (phase 1).
C — Mineur	N’affecte pas forcément la stabilité, mais dégrade la maintenabilité.	À corriger “en même temps” qu’une extension (opportunité de chantier).
D — Optimisation	Amélioration de confort, de cybersécurité ou d’exploitation, non indispensable à court terme.	À chiffrer comme option (si bénéfice clair pour le propriétaire).

Exemples typiques de constats “A — Bloquants”

• Absence de sauvegarde exploitable (pas d’export ETS, pas de version “as-built”, impossibilité d’identifier un état de référence).
• Bus instable (symptômes récurrents, participants injoignables, comportements erratiques).
• Accès distant non maîtrisé (méthode non documentée, permanente, non révocable, ou exposant inutilement l’installation).

Exemples typiques de constats “B — Majeurs”

• Projet ETS partiel avec écarts terrain significatifs.
• Couche IP fragile (instabilités lors d’accès ETS/supervision, multicast mal géré selon architecture).
• Interfaces non documentées (CVC/éclairage/passerelles) : extension possible mais seulement après validation terrain.

Livrables d’un audit “santé KNX” utile (avant extension)

Un audit n’est pas un “avis”. C’est un dossier de décision. À minima, attendez :

• Rapport d’audit classé (A/B/C/D) : constat → preuve (photo / extrait ETS) → impact → correctif → prérequis.
• Cartographie as-built : lignes/segments, alimentations, coupleurs, interfaces KNX/IP, principales dépendances.
• Pack de sauvegardes : export ETS .knxproj si disponible + organisation d’archives (datées) + éléments annexes (selon périmètre).
• Plan de remédiation : ordre des corrections, lots impactés (électricité / réseau / intégration), risques et méthodes de retour arrière.
• Pré-cadrage recette extension : ce qui sera testé, comment, et à quel moment (avant la réception).

Sur le long terme, la maintenabilité dépend autant de ces livrables que de l’installation elle-même (voir notre guide maintenance KNX).

Comment exploiter l’audit pour chiffrer une extension (sans flou)

Une bonne manière de limiter les dérives consiste à chiffrer le projet en deux couches :

• Couche 1 : remise à niveau “santé” (corrections A/B, sécurisation des sauvegardes, remise en cohérence ETS/terrain, stabilisation IP si nécessaire).
• Couche 2 : extension fonctionnelle (nouveaux usages, nouveaux points, nouvelles scènes, nouvelles interfaces).

Cette séparation est essentielle : elle évite de “cacher” une remise à niveau indispensable dans un devis d’extension, et elle permet au propriétaire de décider en connaissance de cause.

Besoin d’un audit avant d’étendre votre KNX ?

Si vous souhaitez étendre une installation existante (avec ETS complet, partiel, ou absent), Domocasa peut vous accompagner avec une démarche d’audit orientée livrables et reprise. Pour replacer cet accompagnement dans notre offre, vous pouvez consulter Domotique / Smart Home et préparer votre consultation avec le cahier des charges KNX pour une villa.