Illustration générée par IA — visuel conceptuel.
Pourquoi la « sauvegarde projet ETS » est un sujet contractuel autant que technique
Un projet KNX n’est pas seulement une liste d’appareils. Dans ETS, le fichier de projet contient la structure (topologie), les adresses, les paramètres et les éléments nécessaires pour comprendre et faire évoluer l’installation. Sans ce fichier, une modification ultérieure peut devenir incertaine, plus longue et plus risquée.
Le point clé, côté propriétaire comme côté intégrateur, est de distinguer trois notions qui sont souvent mélangées dans les discussions : export, sauvegarde et archive dans ETS. Les pages support KNX font précisément cette distinction et décrivent plusieurs méthodes de backup et d’archivage.
À ne pas confondre : sauvegarde ETS vs DOE domotique (et maintenance)
Une sauvegarde ETS vise d’abord à rendre le projet ré-importable et modifiable dans ETS (pour reprendre la configuration KNX). Cela ne couvre pas, à lui seul, toute la remise documentaire d’un projet domotique.
À l’inverse, un DOE domotique regroupe généralement les fichiers ETS mais aussi des éléments hors ETS : schémas, repérage, interfaces (CVC, DALI, supervision, réseau…), logique fonctionnelle, recette, et règles de conservation. Pour cadrer cette remise au-delà du seul .knxproj, voir notre guide : DOE domotique : quels documents et sauvegardes le client doit-il recevoir ?
Enfin, la sauvegarde n’a de valeur que si elle reste à jour et intégrée à une routine de suivi. Sur ce point, voir aussi : Maintenance KNX : comment garantir qu’une installation restera maintenable dans 10 ou 15 ans ?
Export ETS : le fichier .knxproj, le livrable de base
Qu’est-ce qu’un export de projet ETS ?
Dans ETS, l’export standard d’un projet produit un fichier .knxproj. C’est ce fichier qui permet ensuite de réimporter le projet dans ETS.
Point important : la compatibilité dépend de la version d’ETS utilisée pour exporter.
- Avec ETS5, la documentation KNX indique qu’un export est importable dans la même version ou une version supérieure, et jamais dans une version plus ancienne.
- Avec ETS6, la logique est plus fine : un export est importable dans la même version ou une version supérieure, mais pas dans une version 6.x plus ancienne (par exemple, un export réalisé en 6.4 ne sera pas importable en 6.1).
Conséquence pratique (propriétaire / intégrateur) : si vous remettez un export au client, documentez toujours la version ETS exacte et évitez de « monter de version » en fin de chantier sans stratégie, surtout si plusieurs intervenants utilisent des versions différentes.
Que contient (ou implique) cet export ?
La documentation KNX précise notamment que les connexions de ligne (utilisées ensuite pour l’accès bus / bus access) font partie intégrante du projet et sont incluses dans l’export.
À ce stade, il est important de rester factuel : les pages consultées décrivent l’export/import ETS et l’archivage ETS, mais ne décrivent pas une « restauration complète » au sens d’une reconstruction automatique depuis les appareils KNX. Dans cet article, on se limite donc à ce que la source documente : importer un .knxproj (et restaurer via l’archive ETS lorsqu’elle est utilisée).
Point de vigilance : options d’export et Device Configuration Apps (DCA)
Selon la documentation support KNX, ETS propose des options d’export (par exemple inclusion d’informations de catalogue, de programmes d’application compatibles et de DCA). En revanche, KNX précise que les paramètres fonctionnels des DCA (DCA “functional settings”) ne sont pas inclus dans l’export.
Traduction opérationnelle : si votre projet utilise des DCA, ne présumez pas qu’un .knxproj « suffit » à reconstituer l’intégralité de l’état de configuration. C’est un point à cadrer au projet : que faut-il remettre (exports, procédures, captures, versions) pour qu’un futur intervenant puisse reprendre proprement l’installation.
Sauvegarde ETS : trois options décrites par KNX
Dans l’article support KNX « Project backup » (marqué Deprecated par KNX, mais utile pour comprendre les mécanismes), KNX présente trois approches de sauvegarde (au sens “backup”) :
- Option 1 : export standard du projet (fichier .knxproj).
- Option 2 : Project Archive, via la sauvegarde vers l’archive.
- Option 3 : application tierce de type Autobackup, basée sur des instantanés/export en .knxproj.
En pratique, cela signifie qu’un “backup ETS” peut être un simple fichier .knxproj, ou un mécanisme d’archivage géré par ETS, ou encore une automatisation qui génère régulièrement des exports.
Project Archive ETS : stocker, versionner et partager une archive proprement
À quoi sert le Project Archive ?
L’article KNX « Project archive » présente l’archive comme un moyen de stocker des sauvegardes dans un dépôt central (central repository), en dehors du stockage local du poste, et d’avoir une archive pouvant être partagée entre plusieurs postes ETS.
L’exemple typique est un emplacement réseau ou un espace synchronisé, avec un mécanisme géré par ETS (et pas par une copie “manuelle” du dossier interne ETS).
Check-out / check-in : un cycle de travail explicite
KNX décrit un principe de cycle : check-out d’un projet depuis l’archive vers les projets locaux (Local Projects), modifications locales, puis check-in (sauvegarde) vers l’archive. L’intérêt est de formaliser où se trouve la “référence” et comment le projet est remis dans un dépôt d’archive.
Versions : historique, limite et “Pin”
La même page précise que chaque action de sauvegarde vers l’archive crée une nouvelle version. ETS peut conserver un nombre maximal de versions (paramétrable) et il est possible de “Pin” une version pour éviter qu’elle soit supprimée automatiquement.
Condition “operational” : ETS refuse d’archiver un projet dégradé
KNX indique également une règle importante : l’archive n’accepte un projet que si tous les appareils du projet sont marqués operational. Si un appareil est broken, ETS refuse la copie vers l’archive, afin de garantir des sauvegardes valides.
Ce qu’il ne faut pas faire : copier manuellement la “Project/Product Memory”
La documentation KNX sur « Project/Product Memory » insiste sur un point : le stockage interne ETS (Project/Product Memory) ne doit pas être copié ou déplacé manuellement d’un PC à un autre. Pour relocaliser ou transférer, KNX recommande de passer par Export/Import ou par Project Archive.
La même source déconseille fortement l’usage de services de synchronisation (type Dropbox) pour synchroniser la Project/Product Memory. En clair : si l’objectif est de travailler sur plusieurs postes, on privilégie les mécanismes ETS (export/import, archive), pas la synchronisation brute du répertoire interne.
ETS5 vs ETS6 : point de vigilance sur la conversion d’archives
Si votre projet historique est en ETS5, KNX précise (page « Convert ETS5 archived projects ») qu’ETS6 peut convertir des projets archivés ETS5 vers un format d’archive ETS6. Après conversion, ils ne sont plus réutilisables dans ETS5. KNX recommande donc de sauvegarder ces fichiers avant conversion si l’on veut conserver une éditabilité ETS5.
Remise au propriétaire : une proposition de kit ETS (et ses limites)
Les pages support KNX consultées ici détaillent les mécanismes ETS (export, archive, compatibilités, bonnes pratiques), mais ne constituent pas un « standard DOE » complet. La remise ci-dessous est donc présentée comme une proposition de projet (à cadrer au devis/contrat), et à compléter par une remise documentaire plus large (voir plus haut : DOE domotique).
Proposition de remise minimale (ETS)
- Le fichier .knxproj final correspondant à l’installation réellement livrée (export ETS).
- Une stratégie de versions : soit un usage de l’archive ETS, soit (à défaut) plusieurs exports .knxproj datés (par exemple : “avant réception”, “après levée de réserves”).
- Une note de compatibilité : version ETS utilisée pour produire l’export, et règle de compatibilité à retenir (import possible en même version ou version supérieure ; attention aux versions 6.x minor plus anciennes côté ETS6).
Proposition de remise “exploitation” (utile au propriétaire et à un futur intégrateur)
- Une nomenclature claire : comment sont nommées les zones, les tableaux, et la logique de versions (sans imposer un format, mais en évitant les fichiers “final_final_v3”).
- Un emplacement de conservation choisi avec le propriétaire (support chiffré, coffre documentaire de projet, etc.).
- Une règle de mise à jour : toute modification ultérieure doit produire un nouvel export .knxproj et, si l’archive est utilisée, une sauvegarde vers l’archive correspondante.
Cas particulier : et si le projet ETS n’est pas remis ?
Si un propriétaire se retrouve avec une installation fonctionnelle mais sans fichier ETS exploitable, la reprise devient possible mais plus incertaine, plus longue et plus coûteuse. Pour comprendre ce qui est réaliste dans ce cas (et comment organiser la recherche documentaire avant toute intervention), voir : Reprendre une installation KNX sans projet ETS : que peut réellement faire un nouvel intégrateur ?
Conseil discret pour sécuriser la maintenabilité
Avant réception, un réflexe simple consiste à demander que l’export remis au propriétaire soit testé (importé sur un poste ETS de référence du prestataire, ou dans un environnement maîtrisé) afin de vérifier qu’il s’agit bien d’un fichier exploitable. Cela reste une décision de projet : la documentation support KNX consultée ici n’impose pas un protocole de test, mais elle rappelle l’importance d’utiliser les bons mécanismes (export/import, archive) plutôt que des copies manuelles.
Si vous souhaitez cadrer la remise documentaire dès le devis (format, versioning, conservation, droits) Domocasa peut vous aider à formaliser des livrables adaptés à votre projet KNX, en cohérence avec les mécanismes ETS décrits par KNX.
