Votre installation sait écrire elle-même la liste de tout ce qu'elle contient. Ce fichier existe depuis 2004, il tient dans un tableur, et presque personne ne le demande.
Demandez à votre intégrateur l'export EDE de l'installation. S'il arrive le lendemain, vous saurez enfin ce que vous avez acheté. S'il demande une semaine, c'est que le fichier n'existait pas — et qu'il est en train d'être écrit à la main.
Un fichier que l'installation sait écrire toute seule
EDE, pour Engineering Data Exchange, est un tableur qui liste tous les objets BACnet d'une installation : une ligne par point de données, quatre feuilles en tout. Il n'y a rien de mystérieux là-dedans, et c'est précisément ce qui le rend utile.
La recommandation BACnet de la KBOB — la Conférence de coordination des services de la construction et des immeubles des maîtres d'ouvrage publics, dont font partie l'OFCL, armasuisse et le Domaine des EPF — le situe en une phrase, dans son édition de juillet 2021 : la liste EDE « n'est pas définie au niveau de la norme, mais correspond à une recommandation publiée en 2004 par BIG-EU ». Et elle ajoute l'essentiel : ces listes « peuvent être établies par lecture automatique de la fonctionnalité BACnet d'un appareil BACnet projeté ».
Lecture automatique. C'est tout le sujet.
La liste de points annexée à une soumission est un document d'intention : ce qu'on a l'intention de livrer. L'EDE généré depuis l'installation est un relevé : ce qui existe réellement, avec les noms réellement écrits dans les automates. Ce sont deux documents de même apparence et de nature opposée. Confronter l'un à l'autre prend une demi-journée et ne demande aucune visite de site.
Dix-sept colonnes, dont cinq obligatoires
Le gabarit officiel est publié par le BACnet Interest Group Europe. Sa version de disposition — le champ se lit Version_Of_Layout dans l'en-tête du fichier — est la 2.3, datée du 16 janvier 2017. La KBOB recommande de ne pas descendre en dessous : « Il est recommandé de recourir au moins à la version 2.3 des fichiers EDE de BIG-EU. »
Ce gabarit prévoit dix-sept colonnes. Cinq seulement sont obligatoires.
| Colonne | Statut | Ce qu'elle apporte au maître d'ouvrage |
|---|---|---|
| keyname | obligatoire | clé unique de la ligne |
| device obj.-instance | obligatoire | de quel automate vient le point |
| object-name | obligatoire | le nom, donc la lisibilité |
| object-type | obligatoire | mesure, commande, compteur… |
| object-instance | obligatoire | le numéro dans l'automate |
| description | optionnelle | le texte en clair de la fonction |
| present-value-default | optionnelle | la valeur de repli |
| min-present-value | optionnelle | début de l'échelle |
| max-present-value | optionnelle | fin de l'échelle |
| settable (commandable) | optionnelle | lecture seule ou écriture |
| supports COV | optionnelle | remontée sur changement |
| hi-limit | optionnelle | seuil d'alarme haut |
| low-limit | optionnelle | seuil d'alarme bas |
| state-text-reference | optionnelle | les textes d'état (arrêt / marche) |
| unit-code | optionnelle | l'unité physique |
| vendor-specific-address | optionnelle | l'adresse interne du fabricant |
| notification-class | optionnelle | qui est alerté, et comment |
La conséquence est directe, et c'est elle qu'il faut retenir : un fichier EDE parfaitement conforme peut ne contenir que des numéros. Cinq colonnes remplies, douze vides, et le document est valable. Il ne dit alors ni ce que mesure le point, ni dans quelle unité, ni entre quelles bornes, ni s'il est alarmé.
Exiger « un export EDE » ne sert donc à rien. Ce qui sert, c'est d'exiger les colonnes optionnelles. C'est une ligne de cahier des charges, pas une négociation.
Ce que l'EDE ne fait pas
Autant le dire tout de suite, parce qu'on le présente parfois comme un format d'échange universel qu'il n'est pas.
Il n'est pas normatif. C'est la recommandation d'un groupe d'intérêt, pas un chapitre de la norme BACnet. Sa dernière version date de 2017 et n'a pas bougé depuis.
Il est incomplet par construction. La KBOB est explicite : les listes EDE « comprennent des informations simplifiées et incomplètes », et « sont utiles lorsque des informations plus complètes ne sont pas disponibles ». C'est un relevé, pas une documentation.
Il ne décrit aucune logique. Pas les programmes, pas les asservissements, pas les horaires, pas les courbes. Il dit ce qui existe et comment cela s'appelle — jamais ce que cela fait. Un bâtiment entièrement décrit en EDE reste un bâtiment dont on ignore la régulation.
Il ne contient pas les valeurs. Ce n'est pas un historique, et il ne remplace pas l'export des mesures.
Enfin, le gabarit lui-même porte l'avertissement de ses auteurs : le fichier EDE « n'a jamais été conçu pour fournir un format d'échange de machine à machine » — il est pourtant utilisé partout pour cela. Autrement dit : il marche, mais il n'a rien promis.
Trois moments où il change quelque chose
À l'appel d'offres, il transforme une annexe en gabarit. Au lieu de décrire la liste de points en prose, le maître d'ouvrage la fournit au format EDE, avec les colonnes qu'il exige remplies. Les offres reviennent comparables, ligne à ligne, sans interprétation.
À l'intégration, il évite la ressaisie. Les supervisions courantes importent un EDE pour créer leurs points. Sur une installation de quelques milliers d'objets, la différence entre un import et une saisie manuelle ne se discute pas — et ce qui est importé ne contient pas de fautes de frappe.
À la réception, il devient le seul document confrontable. On relit l'EDE exporté de l'installation et on le compare à celui de la soumission : les points manquants apparaissent, les points ajoutés aussi, les noms non conformes également. Ce contrôle est mécanique. Aucune autre pièce du dossier MCR ne permet cela.
C'est là que se trouve le vrai gain de temps. Pas dans le fichier lui-même, mais dans les allers-retours qu'il supprime entre la mise en service et la première année d'exploitation.
Le trou que l'EDE ne comble pas : les noms
Un détail déplaisant, qu'il vaut mieux connaître avant la signature qu'après.
La recommandation de la KBOB exclut explicitement de son périmètre « la désignation des points de données et le concept de numérotation ». Et son chapitre sur les noms d'objets le dit sans détour : « Aucune règle n'est prescrite pour l'attribution du nom des objets. »
Traduisez : la recommandation suisse de référence organise le protocole, les profils d'appareils et les longueurs de chaînes — Object_Name sur 64 caractères au minimum, Description sur 128 pour une unité de commande et de gestion, jeu de caractères UTF-8 imposé — mais elle laisse délibérément le choix des noms au projet.
Si le maître d'ouvrage n'impose pas sa nomenclature, chaque intégrateur appliquera la sienne. Le bâtiment aura alors deux ou trois langues, et un EDE irréprochable qui les documente toutes les trois.
Le gabarit les laisse facultatives. Ce sont pourtant elles qui font la différence entre un fichier et une documentation :
description · present-value-default · min-present-value · max-present-value · settable · supports COV · hi-limit · low-limit · state-text-reference · unit-code
S'y ajoutent trois règles que le gabarit ne couvre pas et qu'il faut écrire soi-même : les textes en français, une description qui accepte au moins 128 caractères, et des numéros d'instance qui ne changent pas d'une version du fichier à la suivante — les nouveaux objets s'ajoutent en fin de feuille, on ne renumérote jamais l'existant. C'est la disposition la plus utile de toutes : sans elle, comparer deux versions du même fichier ne veut plus rien dire.
Des maîtres d'ouvrage institutionnels y consacrent des directives de dix-sept pages. Un maître d'ouvrage privé n'en a pas besoin : les trois phrases plus bas produisent le même effet.
Les sept contrôles à passer sur un fichier EDE reçu
- Les quatre feuilles sont présentes : EDE, State-Texts, Unit-Texts, Object-Types. Une seule feuille livrée, c'est un fichier amputé.
- L'en-tête est rempli : nom de projet, version du fichier de référence, date et auteur de la dernière modification, et Version_Of_Layout à 2.3 au minimum.
- Les colonnes optionnelles exigées au contrat sont effectivement remplies — pas seulement présentes. Une colonne vide sur 4 000 lignes se repère en une seconde dans un tableur.
- Chaque unité et chaque texte d'état référencés existent : tout unit-code utilisé dans la feuille EDE figure dans Unit-Texts, et toute state-text-reference dans State-Texts. Sinon l'import en supervision produira des points sans unité ni texte.
- Les noms d'objets respectent la nomenclature du maître d'ouvrage, sur toute la longueur, sans exception tolérée « pour les quelques points du sous-traitant ».
- Les descriptions sont en français et dépassent le stade de l'abréviation. C'est ce texte que l'exploitant lira pendant vingt ans.
- Le nombre de lignes correspond à la liste de points contractuelle. L'écart, dans un sens comme dans l'autre, se justifie par écrit.
« L'entreprise remet, à la mise en service et à chaque modification ultérieure, le fichier EDE complet de l'installation au gabarit BIG-EU version de disposition 2.3 ou supérieure, comprenant les quatre feuilles EDE, State-Texts, Unit-Texts et Object-Types. Outre les champs obligatoires du gabarit, les colonnes description, min-present-value, max-present-value, settable, supports COV, hi-limit, low-limit, state-text-reference, unit-code et notification-class sont remplies. Les noms d'objets respectent la nomenclature du maître d'ouvrage et les numéros d'instance restent stables d'une version du fichier à la suivante. »
Ce que nous faisons avant le contrôle
Un contrôleur ne sert à rien sans règle à faire respecter. C'est donc par là que nous commençons : nous écrivons pour nos clients leur directive de désignation des points de données, sur la base de la recommandation BACnet de la KBOB — précisément là où elle s'arrête.
Ce n'est pas un modèle recopié d'un projet à l'autre. Un maître d'ouvrage qui possède quarante bâtiments en a déjà trente-huit de nommés, souvent de trois façons différentes, et son exploitant travaille depuis quinze ans avec ses propres repères. Une nomenclature qui obligerait à tout renommer rétroactivement ne sera jamais appliquée : elle finira en annexe que personne n'ouvre. La directive se construit donc à partir du patrimoine existant — ce qui est déjà en place, ce qui se reprend, ce qui se laisse derrière et ce qui s'impose seulement aux nouvelles installations.
Une fois écrite, nous la faisons tenir, et c'est là que se joue l'essentiel :
- nous développons les outils qui la contrôlent — le contrôleur EDE ci-dessous en est un ;
- nous conseillons le maître d'ouvrage sur ce que ses choix engagent, avant qu'ils ne soient dans un appel d'offres ;
- nous accompagnons l'intégrateur pendant le projet, pour que ce qui est livré corresponde à ce qui a été écrit — l'objectif n'est pas de prendre un intégrateur en défaut à la réception, c'est qu'il n'ait aucune raison de l'être.
Les sept contrôles ci-dessus se font à la main dans un tableur. C'est faisable sur deux cents lignes, pénible sur quatre mille. Nous avons donc écrit l'outil qui les fait d'un coup.
On y dépose le fichier de l'intégrateur, on choisit le profil d'appareil, et il vérifie en une passe le jeu de caractères, la longueur des descriptions, les types d'objets admis pour ce profil, les classes de notification, la présence des unités et des textes d'état référencés, et la conformité de chaque nom d'objet à la désignation attendue. Il sort la liste des écarts, ligne par ligne, exportable en CSV — le document à joindre à un procès-verbal de réception.
Le contrôle s'exécute sur la directive du projet — celle du maître d'ouvrage lorsqu'il en a une, la nôtre sinon — et sur les profils d'appareils de la recommandation BACnet de la KBOB.
Le fichier déposé ne quitte jamais le navigateur : tout le contrôle s'exécute sur le poste, rien n'est envoyé sur un serveur. Une liste de points reste un document de projet, et elle n'a pas à transiter.
L'outil n'est pas public. Nous le mettons à disposition des maîtres d'ouvrage, des architectes et des bureaux CVC avec lesquels nous travaillons, le temps d'un projet. Si vous avez un fichier EDE sur les bras et que vous ne savez pas par quel bout le prendre, écrivez-nous : c'est en général l'affaire d'un échange.
Un fichier EDE ne prouve pas qu'une installation est bien faite. Il prouve seulement ce qu'elle contient, et sous quels noms. C'est déjà le seul document du dossier MCR dont on puisse vérifier l'exactitude sans se déplacer — à condition de l'avoir demandé avant la mise en service, et avec les bonnes colonnes.
wall-i est un bureau d'ingénieurs indépendant en MCR et GTB, basé en Valais. Nous écrivons les directives de désignation de nos clients et les outils qui les contrôlent. Un sujet que vous aimeriez nous voir traiter : hello@wall-i.ch