GTB
Sarah.S
19 octobre 2026
Sommaire
Sarah.S
– 19 octobre 2026 –
22 min
Vingt bâtiments tertiaires, vingt serveurs, vingt interfaces. Et un gestionnaire qui jongle d’un site à l’autre pour comprendre où la consommation énergétique dérape : c’est le quotidien de nombreux parcs multisites.
Une solution GTB SaaS change la donne. Cette plateforme cloud intègre les données de chaque équipement, capteur, automate et actionneur, puis les centralise dans un cockpit unique : alerte automatique, commande à distance, analyse de la performance et du confort de chaque occupant. L’optimisation de la gestion devient simple, et l’équipe gagne un temps précieux.
Cette centralisation permet surtout de passer d’une gestion site par site à une vision globale du patrimoine. L’exploitant peut comparer les consommations entre bâtiments, repérer plus rapidement une dérive, suivre l’évolution d’un équipement ou ajuster une consigne sans se déplacer. Les données ne restent plus enfermées dans des serveurs isolés : elles deviennent accessibles aux équipes autorisées depuis une même interface et peuvent alimenter des tableaux de bord communs. Pour un parc qui évolue, le modèle SaaS facilite également l’ajout de nouveaux sites, de nouveaux équipements ou de nouvelles fonctionnalités sans multiplier les infrastructures locales. À l’échelle de plusieurs dizaines de bâtiments, cette capacité à superviser, analyser et agir depuis un environnement unique peut transformer profondément l’organisation de l’exploitation.
Mais le modèle ne fait pas tout. Serveur local ou service en ligne, trois questions restent décisives : la sécurité des réseaux, la continuité de fonctionnement en cas de coupure et la conformité au décret BACS. Sans oublier le coût réel : tarif de l’abonnement, investissement, budget de maintenance et travaux d’installation.
Ce guide vous aide à choisir l’approche conçue pour votre parc : démo, diagnostic de l’existant, intégrateur, accompagnement par un expert.
Pour que votre logiciel de GTB serve enfin vos décisions, à l’échelle de tout le patrimoine.
GTB SaaS ou GTB on-premise : quel modèle faut-il privilégier ?
La réponse ne dépend pas uniquement de la technologie. Elle dépend de la taille du patrimoine, du nombre de bâtiments, de l’organisation des équipes techniques, des exigences de cybersécurité, de la politique informatique de l’entreprise, de la fréquence des mises à jour et du niveau d’autonomie recherché.
Il faut également regarder le projet sur plusieurs années. Une solution on-premise qui semble économique à l’achat peut nécessiter davantage de maintenance informatique. Une solution SaaS simple à déployer peut, de son côté, créer une dépendance au fournisseur si les conditions d’export et de réversibilité ont été négligées.
Le véritable choix n’est donc pas : « cloud ou serveur local ? »
Il consiste plutôt à déterminer où doivent se trouver l’intelligence, les données et les fonctions de supervision pour exploiter efficacement votre parc immobilier pendant les cinq ou dix prochaines années.
Comment fonctionne un logiciel de GTB ?
Avant de comparer les modèles, il faut comprendre ce que fait concrètement un logiciel de GTB. Quel que soit le mode d’hébergement, le principe est le même : le bâtiment mesure, le système décide, les équipements agissent, et l’exploitant garde la vue d’ensemble.
Les quatre couches des systèmes de gestion technique du bâtiment
- Les capteurs et compteurs mesurent les températures, la qualité de l’air, les consommations, l’état des équipements ou l’occupation.
- Les automates et actionneurs exécutent la régulation : ils ouvrent une vanne, démarrent une pompe, modulent une centrale de traitement d’air ou coupent l’éclairage selon un scénario défini.
- Les réseaux et passerelles font circuler l’information entre les équipements et le logiciel, avec des protocoles comme BACnet ou Modbus. Le marché propose aussi des passerelles IoT spécialisées dans le bâtiment (Wattsense en est un exemple) qui facilitent le raccordement d’installations existantes.
- Le logiciel de supervision, installé en local ou fourni en ligne, centralise les données, affiche les synoptiques, déclenche les alertes, conserve l’historique et permet la commande à distance.
Ce que le logiciel apporte à l'exploitant
Concrètement, un logiciel de GTB permet de visualiser l’état du bâtiment en temps réel, de recevoir une alerte lorsqu’un équipement sort de sa plage de fonctionnement, de modifier une consigne ou un horaire sans se déplacer, de suivre les consommations par usage ou par zone, et de produire des rapports. Une interface web ou une application mobile (app) rend ces fonctions accessibles depuis un poste de travail comme depuis un smartphone.
Ce que change le modèle SaaS
Avec un logiciel en ligne, la couche de supervision n’est plus installée sur un serveur local : elle est proposée comme un service, accessible depuis un navigateur, tandis que les automates continuent de réguler le bâtiment sur place. Les évolutions, l’hébergement et une partie de la maintenance sont pris en charge par l’éditeur. L’exploitant retrouve les mêmes fonctions, avec une accessibilité plus large et un déploiement plus simple d’un site à l’autre.
GTB SaaS et GTB on-premise : de quoi parle-t-on exactement ?
Une GTB on-premise, parfois appelée GTB locale, repose sur une infrastructure installée directement dans le bâtiment ou dans le système informatique de l’entreprise. Le serveur, le logiciel de supervision et généralement la base de données sont hébergés localement. L’entreprise dispose donc physiquement ou virtuellement de l’infrastructure permettant de faire fonctionner son logiciel GTB.
Une GTB SaaS, pour Software as a Service, fonctionne différemment. L’application de supervision est proposée comme un service accessible à distance, généralement depuis un navigateur web. L’éditeur gère l’infrastructure logicielle, les évolutions et une partie de la maintenance technique. Les bâtiments communiquent avec cette plateforme à travers des passerelles et des connexions sécurisées. L’utilisateur n’a donc pas besoin d’installer le cœur du logiciel de supervision sur chacun de ses postes.
L&Smart utilise notamment cette approche avec une plateforme GTB SaaS permettant le suivi et le pilotage à distance des installations énergétiques : découvrir la solution GTB L&Smart.
Mais cette distinction devient rapidement plus subtile. Une GTB utilisant une plateforme SaaS ne signifie pas nécessairement que toute l’intelligence du bâtiment se trouve dans le cloud. Les automatismes essentiels peuvent rester locaux. Et une solution on-premise peut elle aussi communiquer avec des services extérieurs. Entre les deux apparaît donc une troisième possibilité de plus en plus importante : l’architecture hybride.
Quels systèmes de GTB sont disponibles ?
GTB, GTC et hypervision : quelles différences ?
Sur le marché, plusieurs termes cohabitent. La GTB et la GTC (gestion technique centralisée) sont souvent employées l’une pour l’autre : la GTC met surtout l’accent sur la centralisation des états et des alarmes, la GTB sur le pilotage global du bâtiment et de ses consommations. Dans une approche GTB GTC moderne, les deux fonctions se retrouvent dans un même logiciel. L’hypervision, enfin, désigne la couche située au-dessus de plusieurs systèmes de supervision existants : elle les fédère sans les remplacer. À l’international, on parle plutôt de BMS (building management system), l’équivalent anglo-saxon de la GTB.
Trois grandes familles de solutions
La norme NF EN ISO 52120-1 permet de situer le niveau d’automatisation d’un bâtiment, de la classe D (système non efficace) à la classe A (haute performance énergétique). Quel que soit le modèle retenu, la classe visée dépend des fonctions réellement déployées, pas du mode d’hébergement.
- La GTB on-premise : serveur et logiciel installés localement, pour un site autonome ou des contraintes informatiques spécifiques.
- La GTB SaaS : supervision en ligne, adaptée aux parcs multisites et aux déploiements évolutifs.
- L’architecture hybride : automatismes et fonctions critiques en local, supervision centralisée sur une plateforme.
Ces modèles se déclinent ensuite selon l’usage. Un immeuble de bureaux, un établissement de santé, un groupe scolaire ou un réseau d’agences n’ont ni les mêmes équipements ni les mêmes priorités. D’où l’importance de choisir un éditeur et un intégrateur capables de proposer plusieurs modèles de déploiement, et pas uniquement celui qu’ils maîtrisent le mieux. Pour comprendre comment un intégrateur certifié intervient dans un projet, consultez la page consacrée au partenaire intégrateur GTB certifié.
Quels sont les avantages d'une solution GTB SaaS ?
Les avantages d’une solution GTB SaaS tiennent surtout à l’échelle et à la simplicité d’exploitation. Les principaux sont détaillés dans les sections suivantes :
- Un pilotage centralisé du parc : une seule interface pour comparer, alerter et intervenir sur tous les bâtiments.
- Des mises à jour mutualisées : les nouvelles fonctions, les évolutions réglementaires et les correctifs de sécurité arrivent sans intervention sur chaque serveur.
- Un déploiement et une administration simplifiés : ajout d’un site, gestion des droits utilisateurs, accès à distance.
- Un gain de temps pour les équipes : moins de déplacements, moins de connexions successives, des tableaux de bord consolidés.
- Un socle de données cohérent pour la maintenance prédictive, le benchmark entre bâtiments et l’intelligence artificielle.
- Une infrastructure serveur gérée par le fournisseur, ce qui allège la charge de la DSI ou des prestataires.
Ces avantages ne sont pas automatiques : ils supposent une architecture bien conçue, une réversibilité garantie et des automatismes locaux solides. C’est tout l’objet des sections qui suivent.
Le SaaS est particulièrement adapté au pilotage d'un parc multisite
C’est probablement l’avantage le plus visible. Imaginez une entreprise disposant de trente agences réparties sur le territoire. Avec trente GTB locales totalement indépendantes, le responsable énergie peut devoir accéder successivement à plusieurs outils : site 1, site 2, site 3. Chaque bâtiment possède éventuellement une interface différente, voire un intégrateur ou une technologie différente.
Le problème n’est pas que ces installations locales fonctionnent mal. Le problème est qu’il devient difficile de raisonner à l’échelle du patrimoine.
Une architecture SaaS permet de faire remonter les informations utiles des différents bâtiments vers un même environnement. Le gestionnaire commence alors sa journée non plus en choisissant un bâtiment, mais en regardant l’ensemble du parc. Quel site consomme anormalement ? Où une alarme importante s’est-elle déclenchée ? Quels bâtiments fonctionnent encore en dehors de leurs horaires ? Quelle agence présente la consommation au mètre carré la plus élevée ?
La centralisation transforme progressivement la manière dont les équipes exploitent le patrimoine. Elle permet de passer d’une logique « je supervise chaque bâtiment » à une logique « je supervise d’abord mon parc, puis j’interviens sur les bâtiments qui nécessitent mon attention ». Ce cockpit énergétique du patrimoine offre une vision globale sans interdire le détail.
C’est précisément l’intérêt d’une GTB multisite, qui centralise plusieurs bâtiments tout en conservant la possibilité de descendre jusqu’au niveau d’une zone ou d’un équipement : découvrir comment fonctionne une GTB multisite. Pour un propriétaire ou une collectivité possédant beaucoup de sites, cet avantage peut être déterminant.
Le on-premise conserve un avantage important : l'autonomie locale
La centralisation ne doit cependant pas conduire à rendre un bâtiment dépendant en permanence d’une connexion internet pour assurer son fonctionnement élémentaire. Imaginez qu’une chaudière ne puisse plus respecter sa régulation parce que la connexion avec le cloud est interrompue : l’architecture serait extrêmement fragile.
Les fonctions critiques de régulation doivent donc être pensées avec un niveau d’autonomie adapté. Une installation bien conçue peut conserver localement les automatismes essentiels : régulation des températures, sécurité des équipements, horaires indispensables, automatismes de chauffage ventilation et climatisation (CVC) ou scénarios de fonctionnement fondamentaux.
La plateforme SaaS vient ensuite apporter une couche supérieure : supervision, historique, tableaux de bord, comparaison multisite, modification de consignes ou analyse énergétique. Cette séparation permet d’obtenir le meilleur des deux mondes.
Le bâtiment continue à fonctionner localement, tandis que sa supervision peut être centralisée à distance.
C’est l’une des raisons pour lesquelles le débat « SaaS contre on-premise » devient progressivement moins binaire. Dans de nombreux projets, la véritable architecture pertinente est hybride.
SaaS : des mises à jour beaucoup plus simples à déployer
Prenons un parc de cinquante bâtiments. Une nouvelle fonctionnalité doit être ajoutée au logiciel GTB. Dans une architecture SaaS centralisée, l’éditeur peut généralement mettre à jour sa plateforme sans qu’une intervention soit nécessaire sur cinquante serveurs différents. Les utilisateurs retrouvent ensuite la nouvelle fonctionnalité lors de leur prochaine connexion.
Cette logique présente un avantage important dans un secteur où les besoins évoluent rapidement : nouveaux tableaux de bord, nouveaux indicateurs, évolutions réglementaires, amélioration de la cybersécurité, fonctions d’intelligence artificielle, nouveaux outils de reporting, API supplémentaires. L’éditeur peut faire évoluer la plateforme progressivement, et chaque innovation profite à tous les sites en même temps.
À l’inverse, une solution totalement locale peut nécessiter davantage de gestion des versions. Un site utilise la version 4.2. Un autre la 4.5. Un troisième n’a pas été mis à jour depuis plusieurs années parce qu’une migration pourrait perturber certains automates. À l’échelle d’un grand patrimoine, cette fragmentation peut devenir difficile à gérer.
Le SaaS facilite donc généralement l’homogénéisation du parc logiciel.
On-premise : davantage de maîtrise sur l'infrastructure
Le modèle local conserve néanmoins un avantage évident pour certaines organisations : elles contrôlent directement l’environnement d’hébergement. Serveur, réseau, sauvegardes, politique de mise à jour, accès, localisation des données : tout est sous leur responsabilité. L’entreprise peut intégrer la GTB dans son propre système informatique selon les règles définies par sa DSI.
Cette approche peut être recherchée lorsque le bâtiment appartient à un environnement particulièrement sensible ou lorsque l’organisation dispose déjà d’une infrastructure informatique capable d’héberger et de maintenir ce type d’application. Certains acteurs ne souhaitent également tout simplement pas dépendre d’un abonnement ou d’une plateforme extérieure pour leur supervision.
Il faut toutefois éviter une confusion fréquente : on-premise ne signifie pas automatiquement plus sécurisé. Un serveur local non mis à jour, accessible avec des identifiants faibles ou mal segmenté du réseau de l’entreprise peut être beaucoup plus vulnérable qu’un service SaaS correctement administré. Inversement, mettre une GTB dans le cloud ne garantit évidemment pas sa sécurité. Dans les deux cas, la cybersécurité dépend de l’architecture complète.
SaaS ou on-premise : lequel est le plus sécurisé ?
C’est probablement la question sur laquelle les idées reçues sont les plus nombreuses. Une entreprise peut penser : « mes données sont chez moi, elles sont donc en sécurité ». Mais leur emplacement ne suffit pas. Il faut regarder comment elles sont protégées.
- Qui peut accéder au système ?
- Les accès administrateurs sont-ils correctement gérés, avec un code d’accès robuste ?
- Une authentification multifacteur est-elle disponible ?
- Les communications sont-elles chiffrées ?
- Les réseaux GTB sont-ils correctement segmentés ?
- Les sauvegardes sont-elles testées ?
- Les mises à jour de sécurité sont-elles réalisées ?
- Les accès des mainteneurs sont-ils supprimés lorsqu’ils ne sont plus nécessaires ?
L’ANSSI rappelle d’ailleurs que le choix d’un modèle cloud doit être réalisé en fonction de la sensibilité du système d’information, des données traitées et du niveau de menace, et non à partir d’une opposition simpliste entre cloud et infrastructure locale.
Dans un environnement SaaS, une partie de ces responsabilités est transférée au fournisseur. Dans un modèle on-premise, elles reposent davantage sur le propriétaire, son service informatique ou ses prestataires. La question pertinente devient donc : « Qui est réellement le mieux placé pour assurer correctement ces tâches pendant les dix prochaines années ? »
Une entreprise disposant d’une DSI structurée peut parfaitement gérer un environnement local. Une PME possédant vingt bâtiments mais aucune équipe dédiée à l’administration de serveurs peut au contraire bénéficier d’une solution SaaS maintenue par un spécialiste.
Pour aller plus loin sur ce point, L&Smart détaille également les principaux enjeux liés à la cybersécurité des systèmes GTB et GTC : lire le guide L&Smart sur la cybersécurité GTB.
Où sont stockées les données de votre GTB ?
Le choix SaaS ou on-premise pose naturellement la question des données. Une GTB peut enregistrer plusieurs années de températures, consommations, états d’équipements, consignes, alarmes et historiques de fonctionnement. Dans une solution locale, ces informations peuvent rester stockées sur l’infrastructure du bâtiment ou de l’entreprise. Dans une plateforme SaaS, elles sont généralement hébergées dans l’infrastructure utilisée par le fournisseur.
Avant de choisir, plusieurs questions doivent donc être posées. Dans quel pays les données sont-elles hébergées ? Qui est l’hébergeur ? Quelles sauvegardes existent ? Pendant combien de temps les historiques sont-ils conservés ? Que se passe-t-il lorsque le contrat est résilié ? Peut-on récupérer plusieurs années de données ? Dans quel format ? Vérifiez également les mentions légales du service, la politique de confidentialité et les engagements de l’éditeur à propos de l’usage de vos données.
Le sujet devient encore plus important lorsqu’un même logiciel centralise plusieurs dizaines ou centaines de bâtiments. Cette base constitue progressivement la mémoire énergétique du patrimoine immobilier. Il faut donc s’assurer qu’elle reste exploitable même si l’entreprise décide un jour de changer de solution.
Le SaaS ne doit pas signifier dépendance au fournisseur
C’est l’un des principaux risques à anticiper. Une entreprise utilise une plateforme GTB SaaS pendant huit ans. Elle accumule des millions de données. Elle construit ses tableaux de bord. Elle connecte progressivement cinquante bâtiments. Puis elle souhaite changer de fournisseur. Peut-elle sortir facilement ? La réponse doit être connue dès la signature du contrat.
Cette problématique dépasse d’ailleurs largement le secteur de la GTB. Le Data Act européen prévoit désormais des dispositions spécifiques pour faciliter le changement entre fournisseurs de services de traitement de données, notamment les services cloud et SaaS. Il impose en particulier des règles destinées à réduire les obstacles contractuels et techniques au changement de fournisseur et prévoit des possibilités d’export des données dans des formats structurés, couramment utilisés et lisibles par machine.
Le règlement prévoit également la disparition des frais de changement de fournisseur concernés à compter du 12 janvier 2027, sous réserve du champ précis d’application du texte et de ses différentes dispositions.
Cette évolution réglementaire va dans le sens d’un principe particulièrement important pour les maîtres d’ouvrage : une solution SaaS performante ne doit pas devenir une prison technique. Avant de signer, il faut donc vérifier la réversibilité, les formats d’export, les API disponibles, les protocoles utilisés et la documentation remise au client.
Le on-premise protège-t-il réellement contre le vendor lock-in ?
Pas nécessairement. Une GTB peut être entièrement installée sur votre propre serveur et rester extrêmement propriétaire : logiciel fermé, protocole propriétaire, configuration accessible uniquement à l’intégrateur historique, licences dépendantes du constructeur, bases de données difficilement exportables, outils de programmation réservés à certains partenaires. Vous hébergez alors physiquement votre système sans être réellement libre de le faire évoluer.
À l’inverse, une plateforme SaaS peut fonctionner avec BACnet, Modbus, API et différents standards ouverts permettant de changer une partie de l’architecture sans tout reconstruire.
Le véritable opposé du vendor lock-in n’est donc pas on-premise. C’est l’interopérabilité. Le choix de la GTB doit être analysé à plusieurs niveaux : les protocoles utilisés, l’accès aux données, les possibilités d’intégration, la documentation et les conditions contractuelles.
L&Smart s’appuie notamment sur une logique de plateforme ouverte et sur des protocoles comme BACnet et Modbus afin de pouvoir s’intégrer aux équipements existants plutôt que d’imposer systématiquement leur remplacement : découvrir l’approche interopérable L&Smart.
Quels sont les coûts d'une solution GTB ? Quel modèle coûte réellement le moins cher ?
La réponse dépend du périmètre étudié. Une comparaison limitée au prix de la licence risque d’être trompeuse.
Les postes de coût d'une GTB on-premise
Il faut potentiellement financer : le serveur, la licence logicielle, la configuration, les sauvegardes, la maintenance de l’infrastructure, les mises à jour, son éventuel remplacement après plusieurs années et les interventions nécessaires pour maintenir l’environnement informatique.
Les postes de coût d'une GTB SaaS
Une solution SaaS transforme généralement davantage ces coûts en abonnement. Le client paie alors régulièrement pour accéder au service et bénéficier de son infrastructure et de ses évolutions. Le tarif varie selon le nombre de bâtiments, le nombre de points supervisés et les fonctions retenues. À cela s’ajoutent les investissements initiaux : capteurs, automates, passerelles, intégration et mise en service.
CAPEX, OPEX et coût total de possession
Le modèle est souvent présenté comme une opposition entre CAPEX pour l’on-premise et OPEX pour le SaaS. Dans la réalité, la frontière est moins nette. Une GTB locale génère également des dépenses récurrentes. Et une GTB SaaS nécessite souvent des investissements initiaux.
Pour comparer correctement deux offres, il faut raisonner en coût total de possession, ou TCO, sur cinq ou dix ans. Combien coûtent les licences ? L’hébergement ? Les mises à jour ? La maintenance ? L’ajout de nouveaux bâtiments ? L’ajout de points ? Les sauvegardes ? Les évolutions ? Le support ? Les interventions ? La cybersécurité ? Le remplacement du serveur ? Une offre moins chère la première année peut devenir plus coûteuse à partir de la quatrième.
Quels ordres de grandeur ?
Les fourchettes publiées par les acteurs du secteur varient sensiblement. Certaines estimations citent, pour la GTB d’un bâtiment tertiaire, des montants de l’ordre de 15 à 45 € par m², selon le niveau de fonctionnalités et la complexité du site. Ces valeurs sont à prendre comme un repère indicatif, jamais comme un devis : seule une étude du bâtiment, avec un diagnostic de l’existant, permet de chiffrer un budget fiable. Pour situer les postes d’un projet réel, consultez notre contenu sur l’installation d’une GTB, entre économies et confort.
Aides, retour sur investissement et réduction des charges
La réduction des consommations et des interventions correctives alimente le retour sur investissement. Selon les opérations, les certificats d’économies d’énergie (CEE) peuvent aussi financer une partie du projet, sous conditions d’éligibilité à vérifier avant d’engager les travaux. Notre contenu sur le décret BACS, la GTB et son financement présente les pistes à explorer.
Pour un bâtiment unique, l'on-premise peut rester très pertinent
Toutes les organisations n’ont pas besoin d’une grande plateforme cloud. Prenons un bâtiment unique. Il fonctionne de manière relativement autonome. Une équipe technique est présente sur place. Le besoin de comparaison multisite est inexistant. La DSI souhaite limiter les services hébergés à l’extérieur. Le besoin principal consiste à superviser quelques installations CVC et à disposer d’une interface locale.
Dans cette situation, une GTB locale peut parfaitement répondre au besoin. Pourquoi payer en permanence pour certaines fonctionnalités centralisées qui seront peu utilisées ? Le modèle on-premise devient particulièrement intéressant lorsque l’entreprise recherche une forte autonomie locale, une architecture relativement stable et une maîtrise directe de l’infrastructure.
C’est d’ailleurs la raison pour laquelle certains éditeurs proposent désormais plusieurs modèles plutôt qu’une approche unique. L&Smart dispose par exemple d’une offre SaaS mais également d’une approche GTB locale avec mini-serveur et licence unique, destinée aux projets recherchant un fonctionnement on-premise sans abonnement mensuel. Le bon modèle dépend donc réellement du projet.
Pour un grand patrimoine multisite, le SaaS prend généralement l'avantage
Changeons maintenant de contexte. Une foncière possède 80 bâtiments. Une collectivité doit gérer 40 écoles, plusieurs gymnases et des bâtiments administratifs. Une chaîne de magasins possède 120 points de vente. Le besoin n’est plus seulement de faire fonctionner chaque bâtiment. Il faut pouvoir piloter le parc comme un ensemble.
À cette échelle, le SaaS présente plusieurs avantages opérationnels. Les équipes se connectent à une même plateforme. Les mises à jour sont mutualisées. Les données sont comparables. Les tableaux de bord sont consolidés. Les accès utilisateurs peuvent être administrés de façon centralisée : un responsable national peut consulter tout le parc tandis qu’un technicien régional ne voit que ses bâtiments.
L’ajout d’un nouveau site peut également être plus simple lorsque l’architecture a été pensée pour évoluer. C’est particulièrement important pour les entreprises qui acquièrent régulièrement de nouveaux bâtiments. Le quatre-vingt-unième site ne doit pas conduire à reconstruire l’ensemble du système.
Comment intégrer une GTB dans un bâtiment existant, même avec plusieurs GTB différentes ?
C’est probablement le cas le plus fréquent. Un patrimoine immobilier existant n’est pas homogène. Un bâtiment utilise une ancienne GTB Siemens. Un autre dispose d’automates Schneider. Un troisième possède seulement une GTC chauffage. Certains sites communiquent en BACnet. D’autres en Modbus. Le plus récent a été équipé avec une architecture différente. Le projet ne part donc pas d’une feuille blanche.
Les étapes d'une intégration réussie
- Dresser l’état des lieux. Recensez les équipements, les automates, les protocoles, les compteurs et les accès réseau. Un audit permet de savoir ce qui est déjà mesuré et piloté. Notre contenu sur l’audit GTB et audit énergétique détaille la démarche.
- Définir les besoins prioritaires. Alertes, suivi énergétique, pilotage des horaires, reporting réglementaire : mieux vaut commencer par un périmètre précis que par une liste de fonctions interminable.
- Choisir les points à remonter. Inutile de tout connecter : quelques dizaines de points bien choisis suffisent souvent pour démarrer.
- Raccorder l’existant. Selon le cas, on utilise les protocoles déjà présents (BACnet, Modbus), des passerelles, ou des capteurs sans fil lorsque le câblage serait trop lourd. Cette solution limite les travaux dans un bâtiment occupé.
- Mettre en service et former. Vérification des mesures, paramétrage des alertes et des règles, formation des équipes d’exploitation.
- Étendre progressivement. Une fois le premier site validé, le modèle est dupliqué sur les suivants.
Sans tout remplacer : le rôle de l'hypervision
Dans cette situation, imposer la même architecture locale à tous les bâtiments peut nécessiter des investissements importants. Une plateforme de niveau supérieur peut au contraire jouer un rôle d’hypervision. Chaque bâtiment conserve une partie de ses équipements et automatismes locaux. Les données utiles sont ensuite centralisées dans un environnement commun.
Le SaaS devient alors moins un remplacement de la GTB existante qu’une couche d’unification du patrimoine. Cette approche peut permettre de moderniser progressivement un parc plutôt que de tout remplacer simultanément.
Un cadre réglementaire à garder en tête
Côté réglementation, pour les bâtiments tertiaires équipés de systèmes de chauffage ou de climatisation d’une puissance nominale utile supérieure à 70 kW, le dispositif BACS impose sous certaines conditions des systèmes d’automatisation et de contrôle. Les bâtiments dépassant 290 kW sont concernés depuis le 1er janvier 2025, et l’échéance maximale pour la dernière catégorie de bâtiments existants est fixée au 1er janvier 2030, sous réserve des conditions de rentabilité et exemptions prévues par les textes. Intégrer une GTB dans un bâtiment existant est donc aussi un moyen de préparer sa conformité : consultez notre contenu sur la conformité GTB au décret BACS.
Comment optimiser la gestion technique du bâtiment ?
Une fois la GTB en place, la question devient : comment en tirer le meilleur ? L’optimisation de la gestion technique du bâtiment repose sur une boucle simple, que le SaaS facilite à l’échelle d’un parc.
- Mesurer : disposer de données fiables sur les consommations, les températures, la qualité de l’air et l’état des équipements.
- Centraliser : regrouper ces informations dans un même outil pour comparer les sites et repérer les écarts.
- Paramétrer : ajuster les horaires, les consignes et les scénarios à l’usage réel des occupants plutôt qu’à un planning théorique.
- Alerter : définir des règles d’alerte pour être prévenu d’une dérive avant que l’inconfort ou la panne n’apparaisse.
- Analyser : viser l’efficacité énergétique en suivant la tendance des consommations, comparer des bâtiments similaires et hiérarchiser les actions.
- Agir et vérifier : corriger, puis mesurer l’effet pour entretenir une amélioration continue.
Pour optimiser la gestion d’un parc, la supervision seule ne suffit pas : il faut aussi une organisation. Qui reçoit les alertes ? Qui décide de la correction ? Quelle fréquence de revue des indicateurs ? La GTB fournit les outils, l’équipe les transforme en décisions. Cette optimisation de la gestion technique bénéficie aussi du suivi énergétique prévu par le décret BACS, qui demande de suivre, enregistrer et analyser en continu les données de consommation.
Pour aller plus loin, explorez nos contenus sur la maintenance prédictive, la GTB et l’intelligence artificielle et sur les enjeux énergétiques des bâtiments tertiaires.
SaaS et intelligence artificielle : un avantage supplémentaire pour demain
La centralisation des données présente également un intérêt pour les nouveaux usages : maintenance prédictive, détection automatique de dérives, benchmark entre bâtiments, prévisions de consommation, optimisation énergétique par intelligence artificielle. Ces fonctions nécessitent généralement un volume important de données structurées.
Un parc dont les historiques restent dispersés dans vingt serveurs indépendants sera plus difficile à exploiter qu’un patrimoine disposant d’un socle de données cohérent. Le SaaS facilite donc naturellement certaines analyses à grande échelle. Cela ne signifie pas qu’une architecture on-premise ne peut pas utiliser l’intelligence artificielle. Mais le modèle centralisé facilite souvent la mutualisation des modèles, des données et des nouvelles fonctionnalités.
L’enjeu est donc également de choisir une architecture capable de répondre aux usages futurs et pas seulement aux besoins actuels. Sur ce sujet, découvrez notre contenu sur la GTB et l’IA générative pour les exploitants de bâtiments.
Et si le cloud devient indisponible ?
C’est une question que tout maître d’ouvrage devrait poser. Une panne de connexion internet ne doit pas conduire à arrêter le chauffage d’un bâtiment. Une interruption temporaire de la plateforme SaaS ne doit pas empêcher les automatismes essentiels de remplir leur rôle. Il faut donc distinguer deux niveaux.
Le fonctionnement local du bâtiment doit pouvoir assurer les fonctions essentielles grâce aux automates et aux logiques locales nécessaires. La couche de supervision peut dépendre davantage de la plateforme centrale pour les historiques, tableaux de bord, analyses ou commandes à distance.
Avant de choisir une architecture SaaS, demandez donc : « Que se passe-t-il concrètement si le bâtiment perd sa connexion internet pendant six heures ? »
La réponse doit être précise. Quels équipements continuent de fonctionner ? Quels scénarios restent disponibles ? Les données sont-elles temporairement stockées localement puis synchronisées ? Quelles fonctions deviennent indisponibles ? La continuité de service doit être documentée dans le contrat, avec les temps de reprise attendus. Cette question révèle souvent beaucoup plus sur la qualité de l’architecture qu’une longue présentation commerciale.
SaaS, on-premise ou hybride : comparaison rapide
| Critère | GTB SaaS | GTB on-premise | Architecture hybride |
|---|---|---|---|
| Pilotage multisite | Très adapté | Plus complexe à centraliser | Très adapté |
| Mises à jour | Généralement centralisées | À gérer localement | Réparties selon les composants |
| Infrastructure serveur | Principalement gérée par le fournisseur | Gérée par le client ou son prestataire | Partagée |
| Autonomie locale | Dépend de l’architecture | Forte | Forte si correctement conçue |
| Accès distant | Naturellement facilité | À mettre en place et sécuriser | Facilité |
| Évolutivité multisite | Généralement élevée | Variable | Élevée |
| Données | Hébergées selon l’offre du fournisseur | Hébergées localement | Réparties |
| Budget | Souvent abonnement + intégration | Licence + infrastructure + maintenance | Modèle mixte |
| Dépendance fournisseur | À contrôler par la réversibilité | Possible également | À contrôler |
| Cas d’usage typique | Patrimoine multisite, déploiements évolutifs | Site autonome, contraintes IT spécifiques | Parcs cherchant centralisation et autonomie locale |
Ce tableau ne désigne pas un gagnant. Il permet surtout de comprendre qu’aucun modèle n’est idéal dans toutes les situations.
Comment choisir un logiciel de GTB ? Les 6 questions à poser avant de choisir
Avant de décider entre SaaS et on-premise, six questions permettent généralement de clarifier le besoin :
- Combien de bâtiments voulons-nous superviser aujourd’hui et dans cinq ans ? Une architecture parfaite pour un bâtiment peut devenir difficile à maintenir lorsque le parc atteint cinquante sites.
- Avons-nous réellement les ressources internes pour maintenir une infrastructure locale ? Héberger soi-même n’a de sens que si quelqu’un est effectivement responsable des sauvegardes, des mises à jour et de la sécurité.
- Quelles fonctions doivent absolument continuer en cas de perte de connexion ? Cette réponse permet de définir ce qui doit rester local.
- Où voulons-nous héberger nos données et avec quelles exigences de sécurité ? La réponse doit tenir compte du niveau de sensibilité réel du patrimoine.
- Pourrons-nous facilement récupérer nos données et changer de fournisseur ? Cette question est indispensable, SaaS comme on-premise.
- Quel sera le coût total du système sur dix ans ? Installation, abonnement, serveurs, support, maintenance et évolutions doivent être intégrés dans la comparaison.
C’est seulement après avoir répondu à ces questions que le choix technologique devient réellement pertinent.
Le choix du logiciel se joue aussi sur des critères moins visibles dans une brochure commerciale :
- Interopérabilité : BACnet, Modbus, API documentées, capacité à dialoguer avec l’existant.
- Expertise de l’éditeur et de l’intégrateur : une expertise de tout premier plan sur votre secteur (bureaux, santé, enseignement, commerce) et un centre d’expertise capable d’accompagner le déploiement.
- Qualité de la démonstration : demandez une démo sur vos propres cas d’usage, avec vos équipements, plutôt qu’une présentation générique.
- Sécurité : authentification renforcée, chiffrement, interface sécurisée, traçabilité.
- Cadre contractuel : droit d’accès aux données, réversibilité, mentions légales, politique de confidentialité, niveau de service.
- Évolutivité : feuille de route, capacité à ajouter des sites, des fonctions et des analyses sans tout reconstruire.
- Accompagnement : formation, support technique, documentation.
Pour les acheteurs publics, ces critères se traduisent dans un cahier des charges précis : notre contenu sur le CCTP GTB pour les marchés publics détaille les clauses à prévoir.
Le meilleur choix est souvent moins binaire qu'il n'y paraît
Le SaaS et l’on-premise sont encore régulièrement présentés comme deux modèles opposés. D’un côté, un bâtiment entièrement connecté au cloud. De l’autre, un serveur enfermé dans un local technique. La réalité des GTB modernes est plus nuancée.
Les automatismes locaux restent indispensables pour faire fonctionner le bâtiment. La centralisation dans une plateforme permet de superviser efficacement un patrimoine important. Les données doivent pouvoir circuler entre les deux de manière sécurisée. Cette combinaison conduit naturellement à des architectures hybrides.
Local pour assurer l’autonomie opérationnelle.
Centralisé pour superviser, comparer et optimiser.
Pour beaucoup de parcs tertiaires multisites, cette organisation représente aujourd’hui un compromis particulièrement intéressant.
Alors, GTB SaaS ou on-premise ?
Pour un bâtiment unique disposant d’une équipe technique autonome et d’exigences IT spécifiques, une solution on-premise peut être parfaitement cohérente.
Pour un patrimoine composé de nombreux bâtiments, une GTB SaaS facilite généralement la centralisation, le déploiement, l’administration et la comparaison des performances.
Pour beaucoup d’entreprises, la réponse se situera entre les deux : une architecture hybride dans laquelle les automatismes critiques restent locaux tandis qu’une plateforme centralisée apporte l’hypervision et les nouveaux services numériques.
Le critère déterminant ne doit donc pas être : « Est-ce du cloud ? » Il doit être : « Cette architecture me permet-elle d’exploiter efficacement mon patrimoine, de rester maître de mes données et de faire évoluer mes bâtiments pendant les dix prochaines années ? »
Une GTB doit rester un outil au service du patrimoine. Pas une contrainte technique supplémentaire. Chez L&Smart, cette logique se traduit par plusieurs possibilités de déploiement, depuis la plateforme SaaS multisite jusqu’à une solution locale, afin d’adapter l’architecture aux contraintes réelles du bâtiment plutôt que d’imposer un modèle unique.
FAQ – Logiciel GTB SaaS ou on-premise
Qu'est-ce qu'un logiciel GTB SaaS ?
Un logiciel GTB SaaS est une solution de Gestion Technique du Bâtiment dont la plateforme de supervision est accessible comme un service en ligne. L’éditeur gère généralement l’infrastructure logicielle, les mises à jour et une partie de la maintenance, tandis que les équipements du bâtiment communiquent avec la plateforme à travers une architecture adaptée.
Qu'est-ce qu'une GTB on-premise ?
Une GTB on-premise est une solution dont le logiciel et l’infrastructure de supervision sont installés localement dans le bâtiment ou dans le système informatique de l’organisation. Le propriétaire ou son prestataire assure alors davantage de responsabilités liées aux serveurs, sauvegardes et mises à jour.
Comment fonctionne un logiciel de GTB ?
Des capteurs et des compteurs mesurent l’état du bâtiment, des automates et des actionneurs exécutent la régulation, un réseau de communication transmet l’information et un logiciel de supervision centralise les données, affiche les synoptiques, déclenche les alertes et permet la commande à distance.
Quels systèmes de GTB sont disponibles ?
On distingue principalement la GTB on-premise installée localement, la GTB SaaS accessible en ligne et l’architecture hybride qui combine automatismes locaux et supervision centralisée. L’hypervision permet en outre de fédérer plusieurs systèmes existants.
Comment choisir un logiciel de GTB ?
Définissez d’abord le nombre de bâtiments, les fonctions qui doivent rester locales, les exigences de sécurité et d’hébergement des données, puis vérifiez l’interopérabilité, la réversibilité, la qualité de l’accompagnement et le coût total sur plusieurs années. Demandez une démonstration sur vos propres équipements.
Une GTB SaaS peut-elle fonctionner sans internet ?
Cela dépend de l’architecture choisie. Dans une installation correctement conçue, les automatismes indispensables au fonctionnement du bâtiment peuvent rester locaux et continuer à fonctionner en cas de coupure internet. Certaines fonctions de supervision, de synchronisation ou de commande distante peuvent en revanche devenir temporairement indisponibles.
Une GTB on-premise est-elle plus sécurisée qu'une GTB cloud ?
Pas automatiquement. La sécurité dépend de l’architecture réseau, de la gestion des accès, des mises à jour, des sauvegardes, du chiffrement et des pratiques d’exploitation. Une solution locale mal administrée peut présenter davantage de risques qu’une plateforme SaaS correctement sécurisée, et inversement.
Quel modèle GTB privilégier pour plusieurs bâtiments ?
Pour un patrimoine multisite, une architecture SaaS ou hybride facilite généralement la centralisation des données, la supervision à distance, la gestion des utilisateurs et la comparaison des performances entre bâtiments.
Quels sont les avantages d'une solution GTB SaaS ?
Pilotage centralisé d’un parc multisite, mises à jour mutualisées, déploiement et administration simplifiés, gain de temps pour les équipes, accès à distance et socle de données cohérent pour les analyses avancées et l’intelligence artificielle.
Quels sont les coûts d'une solution GTB ?
Le coût dépend de la taille du parc, de l’état de l’existant, du nombre de points supervisés et du modèle choisi : licence et infrastructure pour l’on-premise, abonnement pour le SaaS, auxquels s’ajoutent le matériel, l’intégration et la mise en service. Certaines estimations sectorielles évoquent quelques dizaines d’euros par m², à confirmer par une étude. Comparez toujours le coût total de possession sur cinq à dix ans.
Comment intégrer une GTB dans un bâtiment existant ?
On commence par un état des lieux des équipements et des protocoles, puis on définit les besoins prioritaires, on choisit les points à remonter, on raccorde l’existant par les protocoles en place, des passerelles ou des capteurs sans fil, et on étend progressivement. Une couche d’hypervision permet d’unifier plusieurs GTB sans tout remplacer.
Comment optimiser la gestion technique du bâtiment ?
En mesurant de façon fiable, en centralisant les données, en paramétrant les horaires et scénarios selon l’usage réel, en définissant des règles d’alerte, en analysant les écarts entre bâtiments et en vérifiant l’effet des corrections dans une logique d’amélioration continue.
Une solution SaaS permet-elle de récupérer ses données ?
Il faut le vérifier avant la signature du contrat. Les formats d’export, API disponibles, durées de conservation et conditions de réversibilité doivent être clairement définis. Le Data Act européen introduit également des obligations destinées à faciliter le changement entre certains services de traitement de données.
Une GTB on-premise nécessite-t-elle un abonnement ?
Pas nécessairement. Certains modèles reposent sur l’achat d’une licence et d’une infrastructure locale. Des coûts récurrents peuvent néanmoins subsister : support, maintenance, cybersécurité, sauvegardes, mises à jour et renouvellement du matériel.
Peut-on combiner GTB SaaS et on-premise ?
Oui. Une architecture hybride peut conserver les automatismes et certaines fonctions localement tout en utilisant une plateforme SaaS pour l’hypervision, le multisite, les historiques et les analyses. Cette approche permet d’associer autonomie du bâtiment et centralisation du patrimoine.
Faites de votre GTB un véritable outil de pilotage immobilier
Lire aussi
GTB
Sarah.S
12 octobre 2026
