Analyse fonctionnelle GTB : partir des usages et des limites
Avant les automatismes, documentez le fonctionnement attendu du bâtiment : occupation, horaires, exigences de température, contraintes de production, zones sensibles et possibilités d’intervention. Une plateforme logistique avec quais intermittents ne se pilote pas comme des bureaux occupés régulièrement. Une zone industrielle peut imposer des conditions de process que la supervision énergétique ne doit pas modifier. Ces différences doivent apparaître dans le périmètre de la mission.
Identifiez les limites entre les lots. Précisez ce que réalise la régulation locale, ce que commande la GTB et ce qui reste sous la responsabilité d’un équipement ou d’un opérateur. Les sécurités machine ne deviennent pas facultatives parce qu’une supervision existe. L’analyse doit expliciter l’autorité de commande et le comportement attendu lorsque la communication avec le système central est perdue.
Produisez d’abord une fiche par système : désignation, usage, équipements, responsables, entrées, sorties et interfaces. Faites relire les hypothèses par l’exploitant. Cette étape révèle souvent un besoin de relève de consigne, une exception de calendrier ou une contrainte de maintenance qui n’apparaît pas dans le schéma technique.
Décrire les modes sans laisser de zone grise
Listez les modes réellement nécessaires : arrêt, occupation, inoccupation, relance, maintenance et fonctionnement dégradé, selon l’installation. Pour chacun, indiquez les conditions d’entrée, les actions autorisées et les conditions de sortie. Un mode n’est pas seulement une couleur sur un synoptique. Il doit produire un comportement identifiable et compréhensible par les personnes qui l’utilisent.
Définissez ensuite l’ordre des priorités. Une commande manuelle, un calendrier, une limitation de puissance et une protection locale peuvent solliciter le même équipement. Si leur hiérarchie reste implicite, l’intégrateur fera un choix qui ne correspondra pas nécessairement à celui du propriétaire. La matrice de priorité décrit la commande gagnante, les conditions de retour et la trace conservée lors d’un conflit.
Prenons un exemple pédagogique : une demande de marche prolongée dans une zone de bureaux. Le document précise qui peut l’activer, sa durée maximale, les équipements concernés et le retour au calendrier. Il indique aussi les protections qui restent actives. Ce scénario illustre une structure de rédaction ; les valeurs réelles doivent être calculées et validées pour le bâtiment.
Transformer une intention en séquence observable
Chaque séquence contient un état initial, un déclencheur, une action, une temporisation éventuelle et un résultat attendu. Ajoutez les conditions qui empêchent l’action et les événements qui la terminent. Écrire « démarrer progressivement » reste insuffisant si personne ne sait quels équipements démarrent, dans quel ordre et à partir de quelles informations. L’objectif est de réduire les interprétations au moment de programmer et de tester.
Pour une relance CVC, identifiez le calendrier de référence, les mesures utilisées, la consigne cible et la stratégie applicable. Décrivez le traitement d’une mesure absente ou incohérente. Précisez les limites de commande et l’arrêt de la relance. Les paramètres restent modifiables uniquement selon les droits prévus. L’analyse doit permettre de distinguer un réglage d’exploitation d’une modification de logique.
Utilisez une rédaction stable : « Si la condition A est vraie et si l’autorisation B est présente, la commande C est émise ; le retour D doit être observé dans le délai prévu. » Cette formulation n’impose pas un langage de programmation. Elle rend simplement explicites les liens entre une hypothèse de fonctionnement et une preuve terrain.
Relier la liste de points aux scénarios
La liste de points doit soutenir les séquences décrites. Pour chaque information, indiquez la source, le type, l’unité, le nom, le droit de lecture ou d’écriture et les règles d’historisation. Une température sans localisation ni qualité de mesure devient difficile à interpréter. Une commande sans retour d’état ne prouve pas que l’équipement a répondu.
Associez les points aux essais. Si un scénario vérifie le démarrage d’un ventilateur, il faut identifier les conditions d’autorisation, la commande et le retour attendu. Selon les équipements, d’autres preuves peuvent être nécessaires. Le bureau d’études valide leur pertinence avec les entreprises concernées au lieu de multiplier les points sans objectif d’exploitation.
Documentez aussi les échanges entre systèmes : protocole, fréquence, responsable de publication, valeur de repli et réaction à une perte de liaison. L’interopérabilité se vérifie au niveau des comportements, pas seulement à partir d’un nom de protocole. Une connexion qui transporte une valeur ne garantit pas que les unités, les horodatages ou les droits de commande sont correctement compris.
Rédiger des alarmes qui déclenchent une action
Une alarme doit décrire un événement, sa conséquence, le destinataire et l’action attendue. Précisez le seuil, la temporisation, les conditions d’apparition, l’acquittement et le retour à l’état normal. Si une alarme reste active pendant une maintenance prévue, son traitement doit être explicite et tracé. Sinon, les équipes risquent d’apprendre à ignorer un signal pourtant important.
Distinguez une information, une dérive de performance et un événement de continuité. Ces situations ne demandent pas toujours le même délai ni le même circuit de traitement. Sur un entrepôt, une dérive dans une zone sensible peut imposer une escalade différente d’une consommation anormalement élevée en période inoccupée. Les priorités doivent découler des risques métier du site.
Écrivez des scénarios de test pour la chaîne complète : détection, affichage, notification, prise en charge et clôture. Un essai réussi ne se limite pas à l’apparition d’un bandeau rouge. Il vérifie que la bonne personne reçoit une information exploitable et que le système retrouve un état cohérent après résolution.
Prévoir les pertes de service et les accès
Décrivez le comportement en cas de perte du serveur, du réseau, d’un capteur ou d’un équipement. Identifiez les fonctions locales qui doivent continuer, les informations indisponibles et les conditions de reprise. Une consigne conservée peut convenir à certains usages et devenir inacceptable dans d’autres. Le choix doit être expliqué, validé et testé sans mettre en danger les personnes, les produits ou la production.
L’ANSSI publie des recommandations spécifiques aux environnements GTB et GTC. Elles constituent un cadre de référence pour organiser la sécurité du système. Dans le projet, documentez notamment les rôles, les accès de maintenance, les responsabilités et les échanges autorisés. La rédaction fonctionnelle doit rester cohérente avec l’architecture de sécurité décidée par les responsables compétents.
Pour chaque intervention, prévoyez le retour à l’exploitation normale : suppression des forçages, rétablissement des calendriers, sauvegarde de la version validée et transmission des changements. Ces tâches évitent qu’un essai ou une maintenance laisse durablement une commande provisoire. Elles facilitent aussi la réversibilité lors d’un changement d’intégrateur.
Construire la recette dès la rédaction
Associez à chaque exigence importante un scénario d’essai et une preuve attendue : tendance horodatée, journal d’événement, lecture terrain ou procès-verbal. Définissez l’état initial, les participants, les autorisations et les conditions de sécurité. Les essais impossibles lors de la réception doivent être identifiés et planifiés, plutôt que considérés comme implicitement satisfaits.
La recette compare le comportement observé à la version approuvée de l’analyse. Chaque écart précise son impact, son responsable et le retest prévu. Une nouvelle demande du propriétaire se distingue d’une non-conformité ; elle appelle une validation de périmètre et de coût. Cette distinction limite les désaccords et protège la lisibilité du rapport final.
Un bureau d’études indépendant peut structurer ces livrables et analyser les preuves sans dépendre du choix d’un constructeur ou d’un intégrateur. Chez Supernova CSE, l’approche consiste à relier exigences, continuité d’exploitation et coût global. Le document utile reste celui que plusieurs intervenants peuvent comprendre, vérifier et mettre à jour.
Garder un document vivant après réception
À la remise du dossier, identifiez la version approuvée, les paramètres retenus, les réserves et les personnes responsables de la mise à jour. Une analyse fonctionnelle obsolète devient rapidement trompeuse. Toute évolution importante doit être rapprochée de la logique réellement installée et de ses sauvegardes, avec une date et une justification.
Sur plusieurs sites, un modèle commun peut faciliter les revues, mais les exceptions locales doivent rester visibles. Le modèle structure les rubriques, les preuves et les responsabilités ; il ne doit pas imposer la même séquence à des bâtiments aux usages différents. Une gouvernance claire permet de comparer le patrimoine sans effacer ses contraintes.
Cette méthode technique ne constitue pas une attestation de conformité réglementaire. L’assujettissement BACS et les autres obligations demandent une vérification dédiée sur les textes applicables au bâtiment. Pour cadrer votre projet, contactez Supernova CSE avec les schémas disponibles, les usages, les incidents connus et les documents d’exploitation existants.
Questions fréquentes
Qui doit valider l’analyse fonctionnelle GTB ?
Le maître d’ouvrage ou son représentant, avec l’exploitant et les spécialistes des lots concernés. L’intégrateur vérifie ensuite la traduction technique et signale les points impossibles ou ambigus avant programmation.
Une liste de points suffit-elle ?
Non. Elle décrit les informations disponibles ; l’analyse explique comment elles déclenchent les séquences et quelles preuves permettent de vérifier le résultat.
Faut-il donner toutes les valeurs de consigne ?
Les valeurs nécessaires doivent être définies ou associées à une méthode de validation. Les paramètres réglables, leurs limites et leurs droits de modification doivent être documentés.
L’analyse vaut-elle conformité BACS ?
Non. Elle contribue à documenter le fonctionnement. La conformité et l’assujettissement nécessitent une étude distincte sur les exigences réglementaires applicables.
Pour aller plus loin
Sources et méthode
Sources consultées le 4 octobre 2026. Les exemples sont pédagogiques ou fictifs ; les propositions de méthode relèvent de l’analyse éditoriale.