Tous les articles

Cahier des charges GTB : les 29 points à ne pas oublier

Ce qui n'est pas écrit dans le CCTP ne sera jamais livré. Les 29 points à vérifier avant qu'un cahier des charges GTB parte en consultation.

Adrien Lafond
16 min de lecture

Ce qui n'est pas écrit dans le CCTP ne sera jamais livré. Un cahier des charges GTB peut être propre, rédigé par un bureau d'études sérieux, et laisser le maître d'ouvrage sans code source, sans export de données et sans idée de ce que sa GTB lui coûtera chaque année. Voici les 29 points que nous vérifions avant qu'un CCTP parte en consultation, et pourquoi chacun d'eux se paie s'il manque.

Le CCTP est le seul moment où le maître d'ouvrage a la main

Ce qu'on observe, c'est que la GTB est le lot où le maître d'ouvrage a le moins de compétence interne, et le lot où le cahier des charges pèse le plus lourd. Un mur mal fait se voit. Une séquence de régulation mal programmée ne se voit pas : elle se paie, en kilowattheures et en plaintes, sur toute la durée de vie de l'installation.

Avant la signature, tout est possible. On peut exiger le code source des programmes, un export CSV des historiques, un protocole de recette avec des tests nommés. Ça ne coûte rien à écrire, et un intégrateur sérieux n'y trouvera rien à redire. Après la signature, chacune de ces lignes devient un devis. L'intégrateur n'est pas malhonnête. Il lit le CCTP comme un contrat, parce que c'en est un. Ce qui n'y figure pas est une option, et une option se facture.

C'est l'asymétrie de fond de ce métier. Le maître d'ouvrage décide sans expertise GTB interne, sur un document qu'il n'a pas les moyens de relire, et le seul avis technique qu'il reçoit vient de ceux qui répondront à l'appel d'offres. Le CCTP est le dernier moment où cette asymétrie peut être corrigée à bas coût.

Un cas réel : 6 sur 100

Nous avons passé récemment au crible un CCTP de remplacement de régulation sur un étage d'un immeuble de bureaux en Île-de-France. Des ventilo-convecteurs, trois zones, une migration du bus LonWorks (souvent abrégé en LON) vers IP, deux supervisions à alimenter. Un chantier banal, comme il s'en lance des dizaines chaque mois.

Le document n'était pas mauvais au sens où on l'entend d'habitude. Le périmètre était clair. Le DOE était exigé, avec un délai précis avant réception. Les garanties légales étaient rappelées avec des délais d'intervention. Des essais en fonctionnement et une visite préparatoire à la réception étaient prévus. Une liste de sept types de points par ventilo-convecteur était fournie.

6/100Le score de ce CCTP sur nos 29 critères d'exploitabilité. Le périmètre, le DOE et la liste de points sauvent la note. Tout le reste est absent.

Voici ce qui n'y figurait pas. Qui administre la GTB, les comptes et le réseau après livraison : rien. Si les programmes automates peuvent être modifiés par un autre intégrateur sans perdre la garantie : rien. Comment les historiques sont exportés : rien. Une convention de nommage : rien. La cybersécurité, sur un réseau IP fraîchement installé dans un immeuble multi-locataires : rien. Le coût annuel des licences et de la maintenance : rien. Aucun scénario d'exploitation, aucune plage horaire, aucun mode inoccupé, aucune alarme décrite.

Ce CCTP achetait des régulateurs et des points. Il n'achetait pas une GTB exploitable. Et je tiens à le dire clairement : le bureau d'études qui l'a rédigé n'a rien fait d'anormal par rapport aux usages du marché. C'est précisément le problème. Les usages du marché produisent des cahiers des charges qui décrivent le matériel et oublient l'exploitation.

Un bon CCTP ne prescrit pas une marque

Un directeur technique d'hôpital, qui préparait sa mise en conformité au décret BACS (pour building automation and control system), m'a demandé un jour de l'aider à choisir la meilleure marque de GTB. Sa crainte était légitime : choisir un système qui l'enfermerait demain dans des problèmes d'interopérabilité. Mon premier réflexe a été de réfléchir à la « meilleure » solution. Puis je me suis dit que ce n'était justement pas mon rôle.

Le rôle de la maîtrise d'œuvre GTB, c'est d'écrire précisément ce que le système devra savoir faire, et comment on vérifiera qu'il le fait : données fiabilisées, interopérabilité sans licence supplémentaire, historisation systématique, export facile, cas d'usage définis, tests de réception prévus dès le CCTP. L'intégrateur connaît les marques, les modèles, leurs forces et leurs faiblesses, et ses propres capacités de mise en œuvre. À lui de proposer l'architecture qui répond au cahier des charges.

Un bon CCTP ne prescrit pas une marque. Il élimine celles qui ne savent pas faire le boulot. Si vous lisez dans votre CCTP « on veut du Distech Controls ou du Niagara, mais pas du Siemens ni du Schneider Electric », interrogez-vous sur l'approche. Ce n'est pas que ces marques soient bonnes ou mauvaises. C'est que la ligne remplace des exigences vérifiables par une préférence, et qu'une préférence ne se teste pas à la réception.

Les 29 points qui suivent sont écrits dans cet esprit. Aucun ne nomme un produit. Chacun décrit une exigence, et ce qu'il faut pour qu'elle soit vérifiable.

Cadrage et responsabilités

  1. Le CCTP liste-t-il précisément les équipements à raccorder à la GTB, et ce qui est exclu du périmètre ? Une liste d'équipements par lot et par niveau, et une phrase sur ce qui reste hors périmètre. Les litiges à la réception commencent presque toujours par un équipement que chacun pensait dans le lot de l'autre.
  2. En rénovation : l'existant est-il inventorié, et pour chaque automate est-il décidé s'il est conservé, migré ou remplacé, et pourquoi ? Un CCTP qui ne dit rien de l'existant laisse l'intégrateur décider seul de ce qui est « obsolète ». Nous avons vu un mainteneur annoncer un million d'euros pour remplacer trois cents automates d'un bâtiment de onze ans qui fonctionnait. Le remplacement d'un seul automate, en production, a suffi à prouver qu'un échange un pour un était possible.
  3. Les responsabilités entre lots sont-elles réparties ? Qui fournit les régulateurs des CTA, les sondes, le câblage, qui met en service, qui teste. Sans matrice d'interfaces, le lot CVC livre une CTA « avec sa régulation », le lot GTB la « supervise », et personne n'a écrit la séquence.
  4. Les exigences réglementaires et la classe visée sont-elles explicitées fonction par fonction ? Le décret BACS fixe ses propres exigences fonctionnelles ; la norme NF EN ISO 52120-1 est un référentiel d'évaluation, pas une obligation, et le décret n'impose aucune classe. Une ligne « GTB de classe B » vaut 1 sur 3. Un tableau des fonctions avec le niveau exigé pour chacune vaut 3. Si une prime CEE est visée, ses propres exigences de classe s'ajoutent et se vérifient séparément.
  5. Qui administre la GTB, les accès et le réseau après livraison, et que remet-on au maître d'ouvrage ? Le code source des programmes, les licences à son nom, les comptes administrateur. Sur le CCTP à 6/100, personne n'était désigné pour gérer les comptes et les switches IP après la réception. Le vide se comble tout seul : par l'intégrateur, qui garde les clés.

Cas d'usage et exploitation

  1. Les objectifs de la GTB sont-ils rappelés et traduits en cas d'usage concrets ? La journée type de l'exploitant : ce qu'il regarde le matin, ce qu'il modifie, ce qui l'alerte. Un catalogue de fonctions n'est pas un cas d'usage.
  2. Une analyse fonctionnelle (consignes, plages horaires, séquences) est-elle exigée et validée avant programmation ? Voir ci-dessous. C'est le point le plus rentable de la liste.
  3. Les marches forcées (overrides) sont-elles journalisées et remontées en supervision, y compris celles faites depuis les armoires ? Voir ci-dessous.
  4. La gestion des alarmes est-elle spécifiée, et la liste des alarmes est-elle un livrable ? Hiérarchisation et routage au minimum. Une GTB qui remonte 400 alarmes de même priorité forme des exploitants qui n'en lisent aucune.
  5. Les programmes automates peuvent-ils être modifiés et repris par un tiers sans perte de garantie ni intégrateur imposé ? Sources livrées, outils de programmation standards du constructeur, et une clause qui dit que la garantie ne tombe pas si un autre intégrateur qualifié intervient.
  6. Le pilotage à distance est-il prévu et sécurisé ? Un accès IP n'est pas un pilotage à distance sécurisé. Il faut écrire VPN, authentification, journalisation des connexions, cloisonnement du réseau GTB.
  7. L'historisation est-elle spécifiée : quels points, à quel pas de temps, sur quelle profondeur, dans les automates et dans la supervision ? « Historisation prévue » vaut 1. Mesures analogiques toutes les cinq minutes, états sur changement, trois ans glissants, vaut 3.
  8. Interopérabilité en pratique : les points peuvent-ils être exposés via un protocole ouvert sans surcoût ni licence additionnelle, pour un jour-homme au plus ? Voir ci-dessous.
  9. Toute donnée historisée peut-elle être exportée simplement depuis la supervision, sans devis ? Format, procédure documentée au DOE, sans intervention du titulaire. Un client nous a demandé un jour de récupérer ses historiques de température par zone pour prouver à ses locataires que le confort livré était meilleur que ce qu'ils affirmaient. Il a fallu aller les chercher dans les sauvegardes. Ils étaient à lui depuis le début.

Oubli n°1 : personne n'a écrit ce que la GTB doit faire

Un CCTP dit « régulation en fonction de l'occupation », « optimisation de relance », « loi d'eau ». Ce sont des intentions. Ce qui manque presque toujours, c'est le document où ces intentions deviennent des valeurs : consigne à 21 °C en occupation, 17 °C la nuit, relance calculée sur la température extérieure et l'inertie du bâtiment ou relance fixe à 6 h, alarme si l'écart à la consigne dépasse 2 °C pendant plus d'une heure. Ce document s'appelle l'analyse fonctionnelle, et il devrait être rédigé par l'intégrateur et validé par le maître d'ouvrage ou son AMO avant la première ligne de programme.

Quand il n'existe pas, voici ce qui se passe. L'intégrateur programme ce qu'il a dans sa bibliothèque, qui fonctionne, et qui ressemble à ce qu'il a livré sur le chantier précédent. La « relance optimisée » du cahier des charges est une heure fixe, parce que personne n'a écrit autre chose. À la réception, on teste les points un par un : la sonde remonte, la vanne bouge, le ventilateur démarre. Tout est vert. Le test point à point vérifie le câblage, pas le comportement. Et sans analyse fonctionnelle, il n'y a rien contre quoi tester le comportement : un test de séquence sans référence écrite se résume à « ça tourne ».

Trois ans plus tard, quand le maître d'ouvrage veut changer de mainteneur, celui qui reprend n'a que du code à lire. Il propose de tout refaire. C'est là que nous intervenons d'habitude, et c'est la mission la plus évitable de notre catalogue.

Oubli n°2 : les marches forcées que personne ne voit

Sur la porte d'une armoire de CTA, il y a un commutateur auto / 0 / manu. Un technicien le bascule en manu pour dépanner un vendredi après-midi, et repart. Vu de la supervision, la CTA tourne. Vu du bâtiment, elle tourne à pleine vitesse, nuits et week-ends compris, jusqu'à ce que quelqu'un s'étonne de la facture. Cela peut durer des mois, parce que rien, dans la GTB, ne signale qu'un équipement n'est plus piloté.

Le CCTP peut régler ce point en deux lignes : la position du commutateur est recâblée en entrée tout-ou-rien et remontée en supervision comme un point, et toute marche forcée faite depuis la supervision est journalisée, avec l'utilisateur et l'heure, et expire automatiquement. Sur les supervisions du marché, le journal des actions opérateur est natif. Le retour d'état du commutateur d'armoire, lui, ne l'est jamais : c'est un fil à tirer, et il faut que quelqu'un l'ait écrit.

Nous voyons régulièrement des GTB dont une part des équipements est en marche forcée depuis si longtemps que plus personne ne sait pourquoi. Une GTB qui ne sait pas dire ce qu'elle ne pilote plus n'est pas une GTB, c'est un afficheur.

Oubli n°3 : « les régulateurs supportent BACnet »

Cette phrase figure dans la plupart des CCTP, et elle n'a rien obtenu. Supporter un protocole est une capacité du matériel, inscrite sur la fiche technique. Exposer les points de la GTB à travers ce protocole est une prestation : il faut configurer les objets, les nommer, les documenter, et parfois activer une licence. La première est gratuite. La seconde se chiffre en jours-homme, et c'est elle que le maître d'ouvrage croit avoir achetée.

Ce qu'il faut écrire, c'est que l'ensemble des points est exposé en protocole ouvert, sans licence additionnelle, avec la liste des objets livrée au DOE, et que l'exposition de points supplémentaires ne dépasse pas un jour-homme. Pas zéro : exposer des points demande un minimum de travail, et une GTB où tout serait ouvert à tout le monde sans configuration serait une faille de sécurité. Un jour, plafonné, écrit. Une mention de protocole n'est pas une exigence d'interopérabilité.

Vues, tableaux de bord et droits d'accès

  1. Les droits utilisateurs sont-ils précisément définis ? Une matrice de profils (administrateur, exploitant, gestionnaire, lecture seule) avec les actions autorisées. Sans elle, tout le monde a le mot de passe de l'intégrateur, ou personne ne l'a.
  2. La validation des vues et tableaux de bord prévus est-elle organisée avant livraison ? Une maquette validée par le maître d'ouvrage avant développement, puis une recette des vues. Des captures d'écran de l'existant « à titre indicatif » ne sont pas une validation.
  3. Bonus : les vues peuvent-elles être créées ou modifiées en autonomie ? Ce n'est pas indispensable, mais c'est aujourd'hui possible sans licence par poste, et chaque vue modifiée par l'intégrateur est un devis de plus.

Documentation et qualité de données

  1. La liste des points GTB fait-elle partie des livrables prévus ? Complète, avec adresses, unités et plages attendues. C'est le document que tout le monde cherche le jour où quelque chose ne marche plus.
  2. Le plan d'implantation de l'ensemble des capteurs est-il un livrable ? Température, qualité d'air, présence. Une sonde d'ambiance posée au-dessus d'un radiateur produit dix ans de données fausses, proprement historisées. Sans plan, personne ne le découvre.
  3. Une convention de nommage standardisée est-elle imposée ? Bâtiment, niveau, zone, équipement, point. Sans convention, chaque intégrateur nomme à sa façon, et la GTB devient illisible à la deuxième extension.
  4. Le plan de comptage avec sous-compteurs fait-il partie des livrables prévus ? Sur le CCTP à 6/100, la dimension énergétique était totalement absente : pas un sous-compteur, alors que le maître d'ouvrage devra déclarer ses consommations.
  5. Le commissionnement des sous-compteurs est-il prévu ? Un test de cohérence, la somme des sous-compteurs contre le compteur général, avec PV. Nous avons repris un bâtiment neuf où 230 sous-compteurs, posés et raccordés, ne produisaient aucune donnée exploitable. Chacun avait coûté plusieurs milliers d'euros posé.

Maintenance, cybersécurité et tests

  1. La cybersécurité est-elle cadrée dans le cahier des charges ? Segmentation du réseau GTB, changement des mots de passe par défaut, politique de mise à jour des firmwares, journalisation des accès. Un réseau IP neuf sans un mot là-dessus, dans un immeuble multi-locataires, est une porte ouverte.
  2. La documentation de reprise et de maintenance, les sauvegardes et la procédure de restauration sont-elles exigées ? Le contenu du DOE listé, pas seulement son délai. Et une sauvegarde testée : une GTB sans sauvegarde est une GTB qu'on reconstruit après la première panne de disque.
  3. La recette est-elle détaillée : test point à point, test des séquences en conditions réelles, PV, et période d'observation avant levée définitive ? Les deux niveaux de test, nommés, avec des critères mesurables. Une GTB réceptionnée en juin n'a jamais été testée en chauffage. « Essais en fonctionnement » sans protocole, c'est le BE et l'intégrateur qui en discutent à la cantine.
  4. La formation de l'exploitant est-elle prévue ? Durée, public, supports remis. Une demi-journée de démonstration le jour de la réception ne forme personne.

Long terme

  1. Le prestataire s'engage-t-il à proposer un contrat de maintenance après travaux, avec contenu et prix connus ? Remis au plus tard à la réception. Après, le maître d'ouvrage négocie en position de faiblesse, avec un système que seul le titulaire connaît.
  2. Le coût réel annuel de la GTB est-il connu avant signature ? Voir ci-dessous.
  3. La durée de support annoncée des automates proposés est-elle exigée ? Un automate dont le constructeur arrête le support dans trois ans est une obsolescence programmée, achetée neuve.

Oubli n°4 : ce que coûte la GTB une fois livrée

Le CCTP fixe le prix des travaux. Il oublie presque toujours de demander le prix des années suivantes : licences de supervision, abonnements, hébergement, mises à jour, coût d'ajout d'un point, et surtout coût de sortie. Sur le CCTP à 6/100, aucun soumissionnaire n'était invité à chiffrer un coût annuel. Aucune offre de maintenance n'était exigée à la réception. Aucun export de données n'était prévu.

Le mécanisme est connu. Une fois la GTB livrée, le maître d'ouvrage a besoin d'un historique de température pour répondre à un locataire, ou d'un export de consommations pour un reporting. Il demande. Il reçoit un devis, parce que la fonction existe mais n'a pas été livrée, ou parce que la licence ne le permet pas, ou parce que « ce n'est pas dans le périmètre ». Chaque demande devient un jour-homme. Au bout de deux ans, on n'ose plus demander, et les données dorment dans une base à laquelle personne n'accède.

Demander un coût annuel sur cinq ans à chaque soumissionnaire ne coûte rien, et change la comparaison des offres. Une GTB moins chère à l'achat et plus chère à vivre, ça se voit sur cinq ans. Ça ne se voit jamais sur le bordereau de prix.

Cinq lignes qui changent la réception

Il n'y a pas besoin de réécrire le CCTP. Il faut y ajouter les exigences qui protègent l'exploitation, et les formuler de façon vérifiable à la recette, sinon elles ne valent rien. Si vous ne deviez en ajouter que cinq, ce seraient celles-ci.

À exiger noir sur blanc, et à tester à la réception

  1. Analyse fonctionnelle rédigée par le titulaire, avec consignes, plages horaires et séquences chiffrées, validée par le maître d'ouvrage avant programmation. C'est la référence de la recette.
  2. Code source des programmes automates et licences au nom du maître d'ouvrage, remis au DOE, modifiables par tout intégrateur qualifié sans perte de garantie.
  3. Marches forcées journalisées (utilisateur, horodatage, expiration), y compris la position des commutateurs d'armoire, remontée comme un point.
  4. Export de tout historique depuis la supervision, en CSV au minimum, sans intervention du titulaire ; exposition des points en protocole ouvert sans licence additionnelle, pour un jour-homme au plus.
  5. Coût annuel sur cinq ans chiffré par chaque soumissionnaire (licences, maintenance, mises à jour, ajout d'un point) et offre de contrat de maintenance remise à la réception.

Ces cinq lignes ne suffisent pas à faire un bon CCTP. Elles suffisent à faire la différence entre une GTB qu'on possède et une GTB qu'on loue à son intégrateur sans le savoir.

Faire noter son CCTP avant de le publier

Nous avons mis en ligne l'outil qui a produit le 6/100 ci-dessus. Il lit un CCTP GTB et le note sur ces 29 critères, de 0 à 3 chacun : absent, évoqué, traité, vérifiable à la recette. La consigne donnée à l'outil est d'être exigeant. Un 3 est rare, et une simple mention de BACnet ne vaut pas un 3 en interopérabilité. Les deux premières catégories, cadrage et exploitation, sont visibles sans rien saisir. Le reste s'ouvre contre une adresse email.

L'outil ne remplace pas une mission d'AMO. Il relit, dit ce qui manque et propose une formulation pour chaque manque. Si votre CCTP note 60, vous avez un bon document et quelques lignes à ajouter. S'il note 6, il est encore temps : il n'est pas signé.

Noter mon CCTP GTB


Newsletter énergie

Recevez nos articles sur le pilotage CVC

Une étude de cas par mois, sur la régulation fine et l'impact sur la performance énergétique des bâtiments.