L’amélioration incrémentale, appliquée aux bâtiments en exploitation

Manifeste IZHO

Pourquoi dit-on que le bâtiment a vingt ans de retard ?

La formule est usée, mais la réponse est instructive. Un bâtiment en exploitation est un système opaque. Régulations, horaires, consignes, courbes de chauffe, occupation réelle et dérives des équipements interagissent de façon rarement intuitive. Un réglage améliore un indicateur et en dégrade un autre, parfois des mois plus tard, parfois dans un local que personne ne surveille.

Et l’information de départ manque. Retrouver les DOE relève de l’enquête, les intervenants changent, et une part significative du budget se consomme avant d’avoir amélioré quoi que ce soit, simplement pour comprendre ce dont on parle.

Le retard du bâtiment n’est pas un défaut de compétence. C’est ce que produit un système opaque sur lequel on agit avec des moyens limités.

Ce que la tech a réussi, et ce qu’on peut en garder

Pendant la même période, l’industrie du logiciel a construit des systèmes d’une complexité considérable, avec une fiabilité qu’on aurait jugée inatteignable il y a vingt ans. Elle n’y est pas parvenue par de grands projets refondateurs, mais par amélioration incrémentale. On passe d’un état stable au suivant, en vérifiant à chaque étape que la modification produit l’effet attendu sans rien dégrader ailleurs. Presque rien ne se perd, et chaque effort sert de socle au suivant.

C’est ce cumul, et non le génie d’une refonte, qui produit la performance.

La méthode ne se transpose pas telle quelle. La tech concentre des moyens considérables sur peu de projets. Le bâtiment disperse des moyens limités sur autant de projets qu’il y a de bâtiments, chacun singulier par son site, ses usages et son historique. Un bâtiment rendu performant n’aide presque pas le suivant : le cumul s’arrête à la porte du site. C’est là, bien plus que dans un supposé conservatisme du secteur, que se situe le verrou.

Trois enseignements restent pourtant valables, bâtiment par bâtiment.

Mesurer ce qui compte

Sans observabilité, c’est-à-dire la capacité à comprendre l’état d’un système à partir de ce qu’il expose, on intervient à l’aveugle : impossible de prioriser, de vérifier ou de capitaliser. Il ne s’agit pas de tout mesurer, mais ce dont l’exploitant est responsable. L’énergie et l’eau comptent partout. S’y ajoutent, par exemple, la température des chambres froides dans un commerce alimentaire, ou celle de la boucle d’eau chaude sanitaire dans un hôtel.

Agir petit

L’effet est contre-intuitif : c’est en réduisant la taille, la complexité et le coût de chaque action que l’on progresse le plus vite. La décision est plus facile à prendre, parce qu’un échec coûte peu. Les équipes restent engagées, parce qu’elles constatent vite le résultat. Dans l’existant, ces unités sont concrètes : un automatisme modifié, un horaire repris, un équipement remplacé. Inutile de viser d’emblée la solution parfaite : un dispositif fonctionnel, limité à l’indispensable, permet de commencer à apprendre.

Vérifier et garder

Chaque action est contrôlée par la mesure. Ce qui marche reste acquis, ce qui ne marche pas est corrigé. C’est ce qui transforme une suite d’interventions en progrès cumulé.

Ce qui bloque

Trois freins empêchent d’appliquer ces principes au bâtiment existant.

L’investissement initial. Rendre un bâtiment observable coûte cher avant de rapporter quoi que ce soit. Tant qu’il faut une étude et un intégrateur avant la première mesure, rien ne démarre. Et quand la démarche démarre, on instrumente tout d’un coup, à l’opposé du principe des petites actions.

La friction à l’évolution. Ajouter une mesure ou instrumenter un équipement oublié, c’est revenir sur le dispositif, et chaque retour porte un coût fixe, quelle que soit sa taille : une intervention, un tiers à mobiliser, un délai. Ce coût écrase précisément les petites évolutions, et la démarche s’arrête après le premier pas.

La tension entre commun et local. Pour que le cumul dépasse le site, il faut mettre en commun : un même modèle, un même vocabulaire, une même façon de faire. Mais la mise en commun rigidifie. Chaque site doit entrer dans le cadre, et toute évolution du cadre engage l’ensemble, alors que chaque bâtiment est singulier. On oscille alors entre deux impasses : tout standardiser, au risque de figer des projets qui doivent s’adapter, ou laisser chaque site indépendant, et repartir de zéro à chaque fois.

Mettre en commun ce qui peut l’être, laisser local ce qui doit l’être

Cette tension n’a pas de réponse générale. Elle en a une par fonction, selon que celle-ci se prête ou non à des concepts communs solides.

Le suivi s’y prête. Une boucle d’eau chaude sanitaire se surveille ici comme ailleurs, et un sous-comptage se répartit toujours par zone, par usage ou par preneur. Les besoins sont partout les mêmes : restituer et comparer, pour le décret tertiaire, la CSRD ou entre les sites d’un parc. Le cadre est stable, parce que c’est le processus qui le fait évoluer, pas le bâtiment. Et quand il évolue, il évolue pour tous les sites à la fois. Le suivi doit être centralisé.

Le contrôle ne s’y prête pas. Régulation et automatismes doivent coller à la réalité du site et évoluer avec lui : une extension, un changement d’usage, un équipement remplacé. Mettre en commun du spécifique crée des couplages entre des projets qui n’ont rien à partager, et chacun perd la liberté d’évoluer qu’exige son objectif, qui est local. Un système de contrôle se juge à une question : peut-on lui ajouter quelque chose sans toucher à ce qui fonctionne déjà ? Si la réponse est non, chaque évolution devient risquée, et le système se fige jusqu’à l’obsolescence. Le contrôle doit rester local.

Le rêve du système unique, paradoxalement le plus tenace sur les parcs de sites similaires, se paie donc toujours d’un côté ou de l’autre. Le terrain le confirme : sur les GTB, le comptage, l’historisation et les interfaces de suivi sont rarement à la hauteur. Ce n’est pas un défaut de fabrication. Ces systèmes sont conçus pour faire fonctionner un bâtiment, pas pour produire une donnée comparable sur dix ans.

Notre architecture : une enveloppe commune autour de systèmes locaux

Tout ce qui peut être mis en commun l’est, dans la plateforme. Tout ce qui doit rester local le reste, sur le site.

Côté suivi, les systèmes locaux sont réduits au plus simple : une passerelle et des capteurs connectés, pour mesurer d’abord ce qui est le plus critique. L’investissement initial est faible et produit immédiatement quelque chose d’exploitable. Ajouter une mesure ne demande aucune compétence d’intégration : une sonde se paramètre, s’envoie, et l’équipe technique du site la pose avec notre accompagnement à distance. Le coût croît linéairement avec le nombre de mesures. Toute l’intelligence (modèles de processus, historisation, analyses) réside dans l’enveloppe commune, et c’est elle qui accumule, d’une mesure à l’autre et d’un site à l’autre.

Certaines mesures exigent un équipement neuf, par exemple un compteur là où rien n’est compté. Nous ne réduisons pas cette dépense, mais elle reste la propriété de l’exploitant, indépendamment de nous. Ce que nous réduisons, c’est tout ce qui l’entoure.

Côté contrôle, la plateforme ne pilote rien. Elle donne un accès distant sécurisé aux GTB présentes sur site, depuis le même endroit que les données. Elle peut aussi récupérer les données qu’elles exposent, mais nous le déconseillons : la mesure dépendrait alors d’un système qui évolue au rythme du site, et chaque modification risquerait de rompre une série qu’on veut comparable dans le temps.

Lorsque le client le souhaite, nous prenons aussi en charge le contrôle, selon les mêmes principes : des GTB légères, simples et indépendantes par ensemble fonctionnel. Quand il s’agit de commander à distance, d’ajuster des consignes et de superviser des équipements, un seul automate suffit pour le site. Un ensemble plus complexe, comme une production de chaud ou de froid, a son propre système. Chacun peut être modifié, étendu ou remplacé sans toucher aux autres.

La réglementation va dans le même sens

La directive (UE) 2024/1275 impose aux bâtiments non résidentiels des systèmes capables de suivre et d’analyser en continu les consommations, et d’alerter en cas de perte d’efficacité. En France, le décret tertiaire fixe l’obligation de résultat, avec −40 % en 2030. Le décret BACS fixe l’obligation de moyens, au-delà de 290 kW depuis 2025 et de 70 kW en 2030.

Le décret BACS n’impose pas pour autant un système monolithique. Il définit un ensemble de fonctions : suivre les consommations par zone fonctionnelle au pas horaire, les comparer à des valeurs de référence, ajuster les systèmes techniques, rester interopérable. Ces fonctions peuvent être remplies par « tous les produits, logiciels et services d’ingénierie » nécessaires. C’est un cahier des charges fonctionnel, auquel répond une enveloppe de suivi commune interopérable avec des automatismes locaux. Le décret prévoit aussi une inspection régulière du paramétrage et de l’usage effectif du système : le législateur a identifié le vrai risque, celui du système installé pour être conforme puis laissé à l’abandon.

La conformité ne fait pas la performance.

Reste à choisir : équiper le bâtiment pour satisfaire la règle, ou l’équiper pour le faire progresser, et satisfaire la règle en chemin.

Notre conviction

Nous n’avons pas de révolution à vendre. Nous avons une méthode qui a fait ses preuves ailleurs, et les outils pour l’appliquer ici : mesurer ce qui compte, agir petit, vérifier, garder. Ce n’est pas spectaculaire. C’est ce qui marche.

On n’améliore pas ce qu’on ne voit pas. Si le parc existant stagne, ce n’est pas faute de compétences ni d’idées : voir coûte trop cher, et chaque bâtiment repart de zéro. Faire tomber ce prix, et conserver ce qui a été appris d’un bâtiment au suivant : c’est le projet que nous poursuivons.

Les premières actions deviennent alors accessibles aux équipes du site, qu’il s’agisse de régler un automate ou de corriger un horaire, et voir l’effet de son propre travail vaut autant que l’économie réalisée. Quant aux décisions lourdes, elles cessent de se prendre au jugé.