Projet GTB : comment bien définir son besoin avant de consulter un intégrateur ?

Un projet de Gestion Technique du Bâtiment commence encore trop souvent par une question du type : « Quelle GTB devons-nous installer ? » Pourtant, ce n’est généralement pas la première question à poser. Avant de choisir une marque, un logiciel ou un intégrateur, il faut déterminer ce que la GTB devra réellement faire. Quels équipements doivent être surveillés ? Quelles commandes doivent être possibles ? Quelles informations doivent être historisées ? Quels systèmes doivent communiquer entre eux ? Qui utilisera la supervision au quotidien ? Plus ces éléments sont définis en amont, plus il devient possible d’obtenir des offres comparables et d’éviter les incompréhensions pendant le projet.

Commencer par définir le périmètre du projet

La première étape consiste à déterminer ce qui doit réellement entrer dans le périmètre de la GTB. Selon le bâtiment, cela peut concerner uniquement le chauffage et la ventilation, ou englober également l’éclairage, le comptage énergétique, les protections solaires, la production photovoltaïque, certains équipements électriques ou d’autres installations techniques. Il faut également savoir si le projet concerne : - une installation neuve ; - une rénovation complète ; - une évolution d’une GTB existante ; - l’ajout de nouveaux équipements ; - ou la centralisation de plusieurs systèmes déjà présents. Ces situations ne nécessitent pas la même approche.

« Une grande partie des difficultés apparaît lorsque le périmètre n’a pas été clairement défini au départ. Chaque lot suppose alors que certaines fonctions seront réalisées par un autre intervenant, et les oublis n’apparaissent parfois qu’au moment de la mise en service. »

Lister les équipements réellement concernés

Une GTB ne pilote pas « un bâtiment » de manière abstraite. Elle échange avec des équipements concrets : chaudières, pompes, vannes, centrales de traitement d’air, ventilateurs, groupes froids, compteurs, éclairages, stores ou équipements spécifiques. Avant consultation, il est donc utile d’établir une première liste des installations concernées. Elle n’a pas besoin d’être parfaitement exhaustive à ce stade, mais elle doit permettre aux intégrateurs de comprendre l’ampleur du projet.

Définir ce que l’on souhaite faire avec chaque équipement

Connaître la liste des équipements ne suffit pas. Pour chacun d’eux, il faut déterminer les fonctions utiles. Un équipement peut être simplement surveillé, commandé, régulé, programmé ou intégré dans une stratégie plus globale. Par exemple, pour une pompe, le besoin peut inclure : - état marche/arrêt ; - commande ; - défaut ; - retour de fonctionnement ; - vitesse ; - consommation électrique ; - heures de fonctionnement. Toutes ces informations n’ont pas nécessairement la même importance.

La liste de points GTB : un document central

La liste de points est l’un des documents les plus importants d’un projet GTB. Elle décrit les informations qui doivent circuler entre les équipements et le système de supervision. Elle peut notamment préciser : - la désignation du point ; - son type ; - son origine ; - le protocole utilisé ; - s’il s’agit d’une lecture ou d’une commande ; - son unité ; - ses limites éventuelles ; - son besoin d’historisation ; - son utilisation dans les alarmes. Plus ce document est précis, plus les responsabilités deviennent claires.

Définir les protocoles et interfaces nécessaires

La plupart des bâtiments utilisent plusieurs technologies. Un même projet peut rencontrer BACnet, Modbus, KNX, DALI ou différentes interfaces propriétaires. Le choix du protocole n’est pas seulement une question informatique. Il détermine quelles données pourront être échangées, avec quel niveau de contrôle et dans quelles conditions l’installation pourra évoluer. Avant consultation, il faut donc identifier les équipements devant communiquer avec la GTB et les interfaces disponibles.

Pour comprendre le rôle respectif de la supervision et de l’intégration : GTB, GTC et hypervision : quelles différences ?

Ne pas oublier les équipements fournis par les autres lots

C’est l’un des points les plus sensibles dans les projets de GTB. Certains équipements sont fournis par le lot CVC, d’autres par l’électricité, le façadier, le fabricant de groupes froids ou différents spécialistes. Pour chacun, il faut préciser : - qui fournit l’interface de communication ; - qui la paramètre ; - qui fournit la liste des données disponibles ; - qui réalise les essais ; - qui est responsable en cas de problème d’échange. Sans cette répartition, les zones grises apparaissent rapidement.

"Je devais intégrer une CTA dans une solution GTB, mais aucune table d'échange n'était fournie. Il a fallu relancer plusieurs fois le fournisseur pour les obtenir et enfin établir une communication entre la machine et la GTB." S B Intégratrice GTB dans l'ouest

Définir ce que l’exploitant doit voir

La supervision ne doit pas être conçue uniquement comme une reproduction graphique de l’installation. Il faut réfléchir à l’usage réel. Un responsable énergie, un technicien de maintenance et un exploitant CVC n’ont pas nécessairement besoin des mêmes informations. Une bonne supervision doit aider l’utilisateur à comprendre rapidement : - ce qui fonctionne ; - ce qui ne fonctionne pas ; - pourquoi une alarme apparaît ; - quelles consignes sont appliquées ; - comment évoluent les principales grandeurs.

Combien de vues de supervision prévoir ?

Le nombre de vues ne devrait pas être déterminé uniquement par le nombre d’équipements. Une vue générale peut permettre de comprendre l’état global du bâtiment, tandis que certaines installations nécessitent des vues détaillées. Il est souvent utile de prévoir plusieurs niveaux : - synthèse générale ; - vues par zone ou bâtiment ; - vues techniques par installation ; - pages d’alarmes ; - historiques et courbes ; - suivi énergétique. L’objectif est de permettre à l’exploitant de naviguer rapidement du symptôme vers la cause.

Prévoir les alarmes dès la conception

Les alarmes sont parfois ajoutées en fin de projet. C’est rarement une bonne méthode. Il faut définir suffisamment tôt : - quels événements doivent réellement générer une alarme ; - leur niveau de priorité ; - les éventuelles temporisations ; - leur destination ; - la manière dont elles seront acquittées ; - les informations nécessaires pour comprendre le défaut. Une GTB trop bavarde finit souvent par être ignorée.

Décider quelles données doivent être historisées

Historiser toutes les données n’est pas toujours nécessaire. Il faut surtout conserver celles qui permettront de comprendre le fonctionnement du bâtiment. Températures, consignes, états de fonctionnement, consommations ou certaines variables de régulation peuvent être particulièrement utiles pour diagnostiquer une dérive. L’historisation doit donc être pensée en fonction de l’exploitation future.

Pour aller plus loin sur l’exploitation de ces données : Gestion énergétique des bâtiments : par où commencer ?

Définir les automatismes attendus

Une GTB ne doit pas uniquement afficher des informations. Selon le projet, elle peut également contribuer à automatiser et coordonner les équipements. Il faut donc décrire les stratégies attendues. Par exemple : - programmation horaire ; - réduction des consignes hors occupation ; - adaptation à la température extérieure ; - coordination chauffage/refroidissement ; - arrêt automatique de certains équipements ; - remontée des besoins des zones ; - limitation de puissance ; - optimisation énergétique. Ces fonctions doivent être définies suffisamment précisément pour que les différents intégrateurs chiffrent la même prestation.

Penser au fonctionnement en cas de panne de la supervision

Un point souvent oublié consiste à demander : Que se passe-t-il si le serveur GTB est indisponible ? Les fonctions essentielles du bâtiment devraient généralement continuer à fonctionner localement. Un défaut de supervision ne doit pas nécessairement arrêter le chauffage ou la ventilation. Ce principe influence fortement l’architecture de l’installation.

Rénovation : ne pas partir du principe qu’il faut tout remplacer

Lorsqu’une GTB existe déjà, le premier travail doit être de comprendre ce qui peut être conservé. Automates, réseaux, capteurs, actionneurs ou équipements de terrain peuvent parfois rester parfaitement exploitables. Le remplacement intégral n’est donc pas toujours la meilleure solution. Une phase de diagnostic peut permettre de distinguer : - ce qui doit être remplacé ; - ce qui peut être conservé ; - ce qui doit simplement être reprogrammé ; - les interfaces qui peuvent être ajoutées.

Si votre bâtiment dispose déjà d’une supervision : Votre GTB est ancienne : faut-il la remplacer ou la faire évoluer ?

Faut-il intégrer les exigences BACS dès le projet ?

Lorsque le bâtiment est concerné, les fonctions attendues dans le cadre du BACS doivent être prises en compte dès la définition du projet. Il est beaucoup plus efficace de prévoir les données, automatismes et capacités d’analyse nécessaires pendant la conception que de les ajouter après la mise en service.

Pour comprendre comment vérifier les fonctions réellement présentes : Audit BACS : déroulement, points contrôlés et livrables

Définir clairement les livrables

La documentation ne doit pas être considérée comme un détail administratif. Elle conditionne la maintenance future. Il faut donc préciser dès la consultation ce qui devra être remis en fin de projet.

• architecture GTB mise à jour ;
• liste de points définitive ;
• sauvegarde des automates ;
• sauvegarde de la supervision ;
• documentation des réseaux et interfaces ;
• paramètres importants ;
• identifiants et procédures nécessaires à la maintenance ;
• synoptiques et vues définitives ;
• procédures de sauvegarde et restauration ;
• procès-verbaux d’essais ;
• DOE actualisé.

Prévoir la maintenance dès le départ

Une GTB évolue pendant toute la vie du bâtiment. Des locaux changent d’usage, des équipements sont remplacés, des consignes sont adaptées et de nouveaux besoins apparaissent. La maintenance ne doit donc pas être pensée uniquement après la réception. Il est utile de définir dès le départ : - qui pourra intervenir ; - comment les sauvegardes seront conservées ; - comment les modifications seront documentées ; - si un accès distant est prévu ; - quelles compétences seront nécessaires.

Comment comparer plusieurs offres GTB ?

Comparer uniquement le prix global ne suffit pas. Deux intégrateurs peuvent proposer des montants très différents simplement parce qu’ils n’ont pas compris le même périmètre. Il faut donc vérifier que chaque offre couvre bien les mêmes fonctions.

Quand faire intervenir l’intégrateur GTB ?

Le plus tôt possible. Faire intervenir l’intégrateur uniquement lorsque tous les équipements ont déjà été commandés limite fortement sa capacité à proposer une architecture cohérente. Lorsqu’il participe en amont, il peut identifier les interfaces nécessaires, préciser les données à prévoir et détecter les incohérences avant qu’elles ne deviennent coûteuses.

« Sur beaucoup de projets, on nous appelle souvent trop tard. Les équipements ont déjà été choisis, les marchés sont signés et l’on découvre seulement ensuite qu'il est nécessaire de faire appel à un intégrateur pour programme les équipements. Et, bien entendu, cela n'a pas été prévu dans le budget. » S T - Intégateur dans le sud est

Une bonne consultation GTB doit permettre à l’intégrateur de comprendre le résultat attendu

Il n’est pas nécessaire que le maître d’ouvrage définisse lui-même chaque détail technique. C’est aussi le rôle des professionnels qui l’accompagnent. En revanche, il doit être capable d’exprimer clairement : - ce qu’il souhaite surveiller ; - ce qu’il souhaite piloter ; - ses principales difficultés actuelles ; - ses objectifs d’exploitation ; - ses contraintes ; - et les résultats attendus. À partir de cette base, l’intégrateur peut proposer une architecture cohérente.

Vous préparez une consultation ou une évolution de votre installation ? Découvrir les projets GTB / GTC