Cloud ou on-prem ? La question n’est pas “où est installé le logiciel”, mais qui s’engage pour que la GTB reste utile dans 2, 5, 10 ans. Fonctionnement, impacts, coûts sur 10 ans et rôle réel de l’abonnement : on met tout sur la table.
Cloud ou on-prem ? La vraie question n’est pas “où est installé le logiciel”, mais qui s’engage pour que la GTB reste utile dans 2, 5, 10 ans (mise à jour, sécurité, support, usage réel).
Sur le terrain, on retrouve souvent les mêmes attentes :
Et au milieu : “GTB cloud ou on-premise ?”
Dans cet article, on compare donc GTB cloud vs GTB on-premise, de façon très concrète : fonctionnement, impacts organisationnels, coûts, et lien avec l’abonnement — pour vous aider à faire un choix éclairé !
Avant de parler d’architecture (cloud ou on-premise), il faut repartir de la base : pourquoi installer une GTB en 2025 ?
Elle ne sert pas seulement à “remonter des points”. Elle est au croisement de plusieurs enjeux :
Une GTB qui coche ces cases uniquement le jour de la réception, mais qui n’est plus utilisée ou mise à jour au bout de 3 ans, ne remplit pas sa mission.
Comparez ceci à la maintenance d'une chaudière : si vous faites l'entretien seulement la première année, ne comptez pas sur 10 ans de fiabilité.
Repartons maintenant de la GTB on-premise, celle qui a structuré le marché pendant 30 ans.
Dans ce modèle, le logiciel de supervision est installé sur un serveur ou un PC industriel dans vos locaux. Vous êtes propriétaire de la licence, le poste de supervision est chez vous, les données sont stockées localement. Les automates communiquent avec ce serveur, qui centralise les informations et permet de piloter.
Sur le papier, ce modèle a plusieurs avantages :
Mais ce modèle a une conséquence directe, souvent sous-estimée au moment du choix : si les mises à jour, la sécurité, les sauvegardes et l’évolution de la solution ne sont pas prévues (et budgétées) dans un contrat, elles… n’existent pas. Vous restez propriétaire de la licence, bien sûr, mais aussi propriétaire de tout ce qui va avec : obsolescence, correctifs, sauvegardes, durcissement, remplacement du serveur, etc.
Autrement dit : une GTB on-premise peut très bien être robuste et durable — à condition de traiter dès le départ la question “qui fait vivre le système et avec quel budget ?”.
La GTB cloud part d’une approche différente.
Ici, le cœur de la solution – la base de données, l’interface de supervision, les moteurs de calcul et de reporting – est hébergé dans un datacenter sécurisé. Vous vous connectez via un simple navigateur web, depuis les bureaux, un autre site ou même de chez vous.
Sur le site, les automates continuent de faire leur travail. Les automates et équipements du site envoient leurs données vers la plateforme (souvent via une passerelle/edge), et peuvent recevoir des consignes, des scénarios ou des optimisations.
Point clé (souvent mal compris) : Dans la plupart des cas, la régulation critique reste locale. Donc si Internet coupe, le bâtiment ne “s’arrête” pas : les automates continuent à appliquer leurs lois de régulation. Ce que vous perdez temporairement, c’est l’accès à la plateforme et à certaines fonctions d’optimisation avancée.
Ce que change vraiment le cloud :
C’est là que l’abonnement devient un sujet central : un abonnement GTB, ça finance quoi exactement ?
Personne ne se réjouit d’avoir “un abonnement de plus”. Mais en GTB, la question n’est pas idéologique : c’est souvent ce qui conditionne l’usage dans la durée.
Un abonnement GTB peut financer 3 briques (quand il est bien conçu) :
⚠️ Tous les abonnements ne se valent pas : certains se résument à “login + support si bug bloquant”. C’est “ok”… mais vous restez dans une logique produit, pas service.
Au lieu de comparer “prix d’achat vs prix d’abonnement”, comparez le coût total + le risque d’abandon.
👉 L’enjeu n’est pas “payer moins l’année 1”. C’est : qu’est-ce qui vous coûte (et vous rapporte) au bout de 10 ans ?
Test simple quand vous échangez avec un fournisseur :
“Racontez-moi ce qui se passe 6 mois après la mise en service, puis 2 ans après. Qui regarde quoi ? Qui ajuste quoi ? Qui détecte les dérives ?”
Si c’est flou, le risque n’est pas l’architecture… c’est l’absence de modèle d’exploitation.
Si la GTB doit simplement “tenir” sur un bâtiment unique, avec peu d’évolution, une on-premise bien cadrée peut suffire.
Si vous avez des projets de multisites, d’extensions, de nouveaux usages (sous-comptage, qualité d’air, BACS, etc.), un modèle plateforme cloud sera généralement plus adapté, parce qu’il est pensé pour évoluer avec vous.
Si la GTB est surtout là pour “voir ce qui se passe”, les deux modèles fonctionneront. Si vous comptez dessus pour piloter des plans d’actions, prouver des économies, suivre des trajectoires réglementaires, il faut un système qui se met à jour, qui agrège la donnée proprement et qui permet d’ajuster les réglages dans le temps. Là, la question n’est plus seulement on-prem vs cloud, mais “qui s’engage sur la performance dans la durée ?”.
Si vous avez une équipe interne prête à mettre les mains dans les courbes, les scénarios et les rapports, vous pouvez prendre plus de choses à votre charge. Si ce n’est pas le cas, l’abonnement doit clairement inclure quelqu’un “de l’autre côté” qui ne se contente pas d’attendre vos appels mais vous aide à exploiter la GTB. Sinon, quelle que soit l’architecture, elle finit par tourner en roue libre.
Un gros investissement initial peut sembler plus simple à justifier, mais si derrière il n’y a ni mises à jour, ni accompagnement, ni suivi de performance, vous achetez surtout deux ou trois bonnes années. Un abonnement plus complet peut paraître plus cher à la ligne, mais inclure l’infrastructure, l’évolution fonctionnelle et l’optimisation. L’enjeu n’est pas de payer le moins possible à l’année 1, c’est de regarder honnêtement ce que chaque modèle vous coûte — et vous rapporte — au bout de dix ans.
Oui, les deux modèles ne sont pas forcément exclusifs. Dans beaucoup de bâtiments, il existe déjà une GTB constructeur on-premise qui pilote correctement les équipements et a été amortie.
Dans ce cas, une approche pragmatique consiste à conserver la GTB on-premise pour le pilotage bas niveau, et d'ajouter une couche cloud par-dessus pour centraliser les données, faciliter l’hypervision multisite, et activer des fonctions utiles (analyses, scénarios, ajouts d'équipements ou IoTs, etc.). C’est souvent une bonne façon de tester la valeur d’une solution comme la notre.
SCorp-io coche la case “GTB cloud” : la plateforme est hébergée, maintenue et mise à jour par nos soins, l’accès se fait via une interface web multi-utilisateurs pensée pour les équipes d’exploitation, d’énergie et de direction, et nous pouvons nous connecter aussi bien à des GTB existantes qu’à des équipements neufs (ou anciens).
Mais au fond, le plus important n’est pas le nom sur la solution : c’est le modèle dans la durée. Une GTB doit rester vivante : réglages, évolutions, preuves, conformité, et retours terrain.
Et si vous voulez en discuter, même sans projet immédiat, on le fait volontiers : c’est souvent comme ça qu’on clarifie le bon niveau d’ambition, le bon modèle (cloud, hybride ou on-prem bien cadré) et qu’on se met d’accord sur l’objectif commun… qui est celui nous tous dans ce milieu : mieux consommer, durablement.
.png)
