Liste de points GTB : partir des usages et du périmètre
Commencez par les décisions à prendre. Une température peut servir à suivre le confort, à commander une séquence ou à détecter une dérive. Ces usages ne demandent pas nécessairement la même précision, la même fréquence ni le même traitement d’un défaut. Lister tous les points disponibles sans expliquer leur rôle risque de produire une base volumineuse que personne ne sait exploiter.
Recensez les installations couvertes : CVC, éclairage, comptage, froid ou équipements de process selon la mission. Définissez les limites entre GTB, automatismes locaux et systèmes spécialisés. Une fonction de sécurité ou de protection reste soumise à ses exigences propres ; l’ajout d’un point dans la supervision ne permet pas de transférer automatiquement cette responsabilité à la GTB.
Pour chaque usage prioritaire, identifiez les informations nécessaires et leur source réelle. Demandez si le point existe, s’il doit être créé et qui en assurera la disponibilité. Le bureau d’études peut structurer cette analyse sans imposer un constructeur. L’objectif consiste à obtenir une base compréhensible par le propriétaire, l’exploitant et les intervenants qui intégreront ou maintiendront le système.
Définir un identifiant stable et un libellé lisible
Attribuez à chaque point un identifiant unique dans le périmètre retenu. Il peut associer site, bâtiment, zone, équipement et fonction selon une convention documentée. L’identifiant doit rester distinct du libellé affiché : celui-ci peut évoluer pour améliorer la compréhension sans casser les historiques, les exports ou les liens utilisés par les autres outils.
Précisez les règles de nommage et les abréviations autorisées. Une désignation comme « température 1 » laisse trop de place à l’interprétation. Un nom qui indique l’équipement et la position de mesure aide à retrouver le point sur un schéma et sur le terrain. La convention doit rester assez courte pour être utilisable et assez précise pour distinguer deux informations proches.
Dans une gestion multisite, utilisez un socle commun et documentez les exceptions. Deux sites peuvent employer des systèmes différents tout en partageant la même signification métier. Conservez l’adresse native à côté de l’identifiant patrimonial, au lieu de remplacer l’une par l’autre. Ce rapprochement facilite les migrations, les comparaisons et les diagnostics sans effacer les particularités locales.
Renseigner type, unité, échelle et états
Pour une valeur analogique, indiquez l’unité attendue, la plage utile, le traitement éventuel et le sens physique. Une énergie cumulée n’est pas une puissance instantanée ; une différence de température ne se lit pas comme une température absolue. Ces distinctions doivent être explicites avant l’intégration, puis vérifiées sur des données réelles avec les spécialistes compétents.
Pour un état ou une commande, décrivez les valeurs possibles et leur signification. « 0 » peut désigner arrêt, contact ouvert, état normal ou absence d’information selon le système. Ne déduisez pas cette signification d’un affichage existant. Associez chaque valeur à une définition validée et prévoyez le traitement des états inconnus, indisponibles ou incohérents.
Voici un exemple pédagogique : le point de température d’air repris d’une centrale comporte un identifiant, une localisation, une unité, une source et un statut de qualité. Son seuil d’alarme et son usage dans la régulation sont décrits dans les documents appropriés. La liste ne remplace pas l’analyse fonctionnelle ; elle fournit les informations qui permettent d’appliquer et de tester celle-ci.
Relier l’adresse technique à sa source vérifiée
Identifiez le système d’origine, le protocole, l’équipement et les paramètres nécessaires à la lecture. La forme dépend de l’architecture : objet, registre, chemin ou référence propre à un logiciel. Ne supposez pas que deux systèmes qui utilisent le même protocole possèdent la même cartographie. Les détails doivent provenir de la documentation et être confirmés avec l’intégrateur.
Conservez la version du document de référence et la date de contrôle. Lors d’une reprise de GTB, une liste ancienne peut décrire une configuration qui a changé. Rapprochez la donnée exportée, la configuration active et le relevé terrain. Si un point n’a pas pu être vérifié, marquez-le comme tel et affectez une action ; ne transformez pas une hypothèse en information validée.
Les informations d’adressage peuvent être sensibles. La liste de points n’est pas un annuaire de mots de passe et ne doit pas contenir des secrets d’accès. Définissez les destinataires, les droits et les conditions de partage. Les recommandations GTB/GTC de l’ANSSI constituent une référence utile pour traiter ces questions dans l’architecture et les procédures de maintenance.
Décrire la qualité et l’horodatage des données
Une valeur reçue n’est pas nécessairement une valeur exploitable. Précisez comment le système signale une perte de communication, un défaut de capteur, une valeur forcée ou une donnée trop ancienne. L’affichage et les calculs doivent tenir compte de ces statuts. Une ancienne mesure présentée comme actuelle peut conduire à une mauvaise décision de conduite ou de maintenance.
Définissez l’origine de l’horodatage et les règles de synchronisation adaptées au système. Distinguez la date de mesure, celle de réception et celle d’archivage lorsque ces informations sont disponibles. Pour les tendances, décrivez la fréquence, la conservation et les traitements appliqués. Une moyenne, un maximum et un cumul ne racontent pas le même événement.
Pour un indicateur énergétique, documentez les données d’entrée et le comportement lorsque l’une manque. Signalez les périodes incomplètes au lieu de fabriquer une continuité trompeuse. La méthode de remplacement éventuelle doit être explicite, autorisée et traçable. Ces règles permettent de discuter d’un résultat avec des preuves, sans annoncer une économie sur la seule base d’un tableau de bord.
Encadrer les commandes et les droits
Pour un point commandable, distinguez lecture, réglage et action. Indiquez les profils autorisés, les limites et les conditions nécessaires avant intervention. Une commande distante doit rester cohérente avec les automatismes locaux, les priorités et les protections de l’équipement. Les modalités dépendent du projet et doivent être validées par les responsables des lots concernés.
Décrivez aussi le retour d’état. Une commande envoyée ne prouve pas que l’équipement a exécuté l’action. Selon la fonction, il faut un retour physique, un état calculé ou une vérification terrain. La liste précise la relation attendue ; l’analyse fonctionnelle définit les délais, les réactions aux écarts et les conditions de reprise.
Pendant les essais, organisez les autorisations et le retour à l’exploitation normale. Identifiez les forçages, les paramètres temporaires et les sauvegardes à conserver. Sur un site logistique ou industriel, une vérification ne doit pas perturber les produits, le confort ou la production. Préparez les essais avec l’exploitant et retenez un scénario sûr lorsque la fonction ne peut pas être sollicitée directement.
Préparer une recette et une gestion des versions
Ajoutez à la liste une colonne de contrôle : méthode, résultat, date, intervenant et preuve. Les vérifications peuvent porter sur le nom, l’unité, l’adresse, la qualité, l’horodatage ou la relation commande-retour. Choisissez des contrôles adaptés à chaque famille de points et justifiez les éventuels échantillonnages ; ne présentez pas un contrôle partiel comme une validation exhaustive.
Classez les réserves selon leur impact et attribuez un responsable. Un libellé peu clair, une unité fausse et une commande sans retour n’ont pas les mêmes conséquences. Le procès-verbal doit permettre de suivre la correction et le retest. Une capture d’écran isolée est souvent insuffisante : reliez-la au point, à la condition d’essai et à la version contrôlée.
Après réception, définissez qui met à jour le référentiel. Une modification d’automate, de capteur ou de supervision peut changer les correspondances. Le dossier exploitable associe liste de points, analyse fonctionnelle, architecture et sauvegardes dans des versions cohérentes. Supernova CSE peut cadrer ces livrables indépendamment des intégrateurs et constructeurs, avec une attention au coût global et à la réversibilité. La liste contribue à la qualité du projet ; elle ne constitue pas, à elle seule, une attestation de conformité BACS ou Tertiaire.
Questions fréquentes
Qui prépare la liste de points GTB ?
Le bureau d’études peut structurer les besoins et conventions. L’intégrateur précise les correspondances techniques ; l’exploitant contribue aux usages et aux contrôles.
Une liste de points prouve-t-elle la conformité BACS ?
Non. Elle documente les informations et leur contrôle. L’assujettissement et les obligations applicables doivent faire l’objet d’une vérification réglementaire distincte.
Faut-il intégrer tous les points disponibles ?
Priorisez les fonctions attendues, puis justifiez les données nécessaires. Une accumulation sans usage défini alourdit l’intégration et la maintenance.
Peut-on réutiliser une liste ancienne ?
Oui comme base de travail, à condition de la rapprocher de la configuration active et d’identifier explicitement les éléments non vérifiés.
Pour aller plus loin
Sources et méthode
Sources consultées le 5 octobre 2026. Les exemples sont pédagogiques ou fictifs ; les propositions de méthode relèvent de l’analyse éditoriale.