Dossier technique GTB
GTB ou GTC : définir le périmètre utile au bâtiment
Mis à jour le · Rédaction Pilotage Bâtiment
Les termes GTB et GTC peuvent recouvrir des offres de périmètres différents. Le guide de l’ANSSI sur la sécurité des GTB/GTC (ANSSI-PA-110, 27 avril 2026) présente la GTC comme un sous-élément de la GTB. L’acheteur doit demander ce qui sera mesuré, commandé et enregistré, plutôt que décider sur un sigle. BACS (building automation and control system) désigne le système d’automatisation et de contrôle visé par le décret ; le guide ministériel de janvier 2026 indique qu’il correspond à une gestion technique de bâtiment (GTB). Une offre appelée GTB ou GTC doit être examinée sur ses fonctions effectives et les systèmes concernés.
Décrire les fonctions avant les noms
Un besoin peut porter sur la supervision d’un chauffage, la programmation de plusieurs usages ou l’analyse énergétique d’un bâtiment. Formulez les situations que l’exploitant doit gérer : horaires exceptionnels, alarme de défaut, dérive de consommation ou changement d’occupant. Demandez au candidat la chaîne technique nécessaire à chaque situation, depuis les mesures jusqu’aux actions et aux données conservées.
Le guide ministériel BACS, janvier 2026 présente les différents niveaux du système, notamment le terrain, la régulation et la gestion technique. Utilisez cette distinction pour discuter l’architecture. Un capteur, un automate et une vue de supervision n’ont pas le même rôle. La disponibilité d’un écran ne signifie pas qu’une séquence de régulation est active. Le dossier doit expliquer où se trouve chaque fonction et qui la maintient.
Examiner un périmètre limité
Une gestion centralisée d’un lot peut répondre à un besoin d’exploitation précis. Elle doit néanmoins être confrontée aux exigences BACS si le bâtiment entre dans le périmètre. L’article R. 175-3 du CCH : fonctions et données décrit notamment le suivi et l’analyse énergétiques, l’interopérabilité et la gestion autonome. Demandez une correspondance des fonctions pour les systèmes retenus, sans supposer qu’un lot isolé couvre tout le dossier.
Le devis doit signaler les usages exclus. Une proposition centrée sur le chauffage peut laisser le comptage ou les autres interfaces à un autre lot. Cette répartition peut être pertinente si elle est explicite et coordonnée. L’acheteur doit pouvoir identifier les prestations manquantes et leur responsable. Un intitulé « GTB complète » sans liste de systèmes n’apporte pas cette information.
Choisir l’architecture d’exploitation
Décrivez les utilisateurs : exploitant local, responsable technique et gestionnaire de parc. Leurs droits peuvent différer. Une architecture centralisée doit expliquer le fonctionnement en cas de perte de réseau et les commandes qui restent disponibles localement. Demandez les besoins en serveur, les licences et les responsabilités de maintenance. La facilité de consultation ne doit pas masquer une dépendance opérationnelle.
Les horaires et les consignes doivent être rattachés aux zones. Si la programmation est commune à plusieurs bâtiments, demandez comment une exception locale est traitée. Le DOE doit montrer la relation entre une consigne centrale et le comportement des automates. L’utilisateur doit pouvoir identifier l’origine d’un forçage ou d’un mode particulier. Ces informations rendent le système exploitable au-delà de la démonstration initiale.
Mettre les données au service de la décision
Précisez les historiques nécessaires et leurs usages : diagnostic, suivi énergétique ou préparation d’une déclaration. Les colonnes, les unités et l’horodatage doivent être définis. Une même courbe peut agréger des périmètres différents ; le système doit expliquer ce qu’elle représente. Demandez une procédure pour retrouver les données sources et identifier une période sans mesure.
Le comptage ne doit pas être confondu avec les états de marche. Une durée de fonctionnement et une énergie mesurée répondent à des questions différentes. Le candidat doit dire comment il évalue les consommations, quels compteurs il ajoute et quelles estimations il propose. Les estimations restent identifiées dans les exports. L’acheteur peut alors examiner leur pertinence pour son besoin et leurs limites de preuve.
Comparer la reprise et le remplacement
Une GTC existante peut fournir des automates et des interfaces utiles au projet. Demandez un audit et une option de reprise avant de remplacer l’ensemble. Le prestataire précise les versions compatibles, les droits de programmation et les fonctions manquantes. Un protocole annoncé dans une brochure ne remplace pas un essai sur l’équipement. Le pilote doit produire un relevé des échanges et des commandes testées.
Pour une option de remplacement, demandez les contraintes de bascule et le devenir des historiques. Les travaux de câblage, les arrêts et la formation doivent être inclus ou exclus explicitement. Une comparaison portant uniquement sur le logiciel ne couvre pas ces coûts. Le marché fixe les responsabilités de chaque intervenant et les pièces attendues pour la réception de l’architecture finale.
Faire une démonstration utile
Préparez un scénario proche de l’exploitation : modifier un horaire sur une zone, constater l’effet, retrouver l’historique et annuler la dérogation. Demandez au candidat de montrer les droits d’un utilisateur ordinaire, sans utiliser seulement un compte administrateur. La démonstration doit distinguer les fonctions simulées et les fonctions réellement connectées à un équipement.
Exemple : une solution nommée GTC offre la programmation et des données énergétiques sur le chauffage, tandis qu’une solution nommée GTB ne reprend que des alarmes. L’acheteur ne peut pas choisir sur les appellations. Il compare les fonctions, les usages et les preuves au regard de son périmètre. Les termes commerciaux restent utiles pour présenter une famille d’offres, mais le contrat doit décrire les comportements attendus.
Prévoir l’extension future
Le bâtiment peut évoluer et le système doit avoir des limites connues. Demandez comment un compteur, une zone ou un usage supplémentaire sera intégré. Le contrat précise les licences et les outils nécessaires. Une capacité d’extension annoncée doit être rapprochée du matériel et du réseau disponibles, puis testée lorsqu’elle devient un besoin réel. Ne payez pas une ouverture abstraite sans conditions d’usage.
La réversibilité doit être discutée pour les deux types d’offre. Le propriétaire doit connaître les documents, les données et les droits qu’il récupère à la fin du contrat. Une supervision accessible sur Internet ne signifie pas qu’un autre intégrateur pourra reprendre les programmes. Demandez une liste de livrables et un exercice de récupération adapté au projet, puis conservez le résultat dans le DOE.
Questions pratiques
Une GTC est-elle toujours insuffisante pour BACS ?
Le nom ne permet pas de conclure. Examinez les fonctions et les systèmes raccordés au regard du CCH, avec les preuves de leur mise en œuvre.
Faut-il raccorder tous les usages dès le départ ?
Le périmètre réglementaire dépend du cas. Le besoin commercial peut être plus large. Faites distinguer ces deux périmètres dans l’étude et le devis.
Peut-on conserver la régulation locale ?
Cela peut être étudié si les fonctions, les accès et les interfaces sont démontrés. La supervision doit préciser les commandes et données réellement reprises.
Pages pour préparer la décision
Sources officielles et documents de référence
Références consultées le 1er octobre 2026.