Maîtrise d'ouvrage

Qui détient vraiment les clés de votre bâtiment ?

, · Lecture 10 min · Par Patrick Savioz

Schéma : reprendre une régulation suppose trois éléments indépendants, les fichiers, les droits et les moyens ; il en manque presque toujours un
Les fichiers, les droits, les moyens : trois livrables distincts. Aucun des trois ne suffit seul, et le dossier n’en prévoit presque jamais les trois.

La réception s’est bien passée. Les essais fonctionnels sont conformes, le procès-verbal est signé, l’installation est en service. Vous avez payé l’automatisation du bâtiment, y compris la programmation : c’est un poste identifié dans le décompte, avec un montant.

Trois ans plus tard, vous voulez faire trois choses banales : ajouter deux zones, remettre la maintenance en concurrence, et faire vérifier la régulation par un bureau indépendant.

Les trois se heurtent au même mur. Vous avez payé la programmation. Vous ne l’avez jamais reçue.

Ce n’est pas une panne. Rien ne s’est mal passé. C’est simplement ce qui arrive par défaut quand personne n’a rien exigé.

Ce que vous avez reçu n’est pas ce que vous avez payé

L’automate contient un programme exécutable. C’est ce qui fait fonctionner le bâtiment, et c’est tout ce que la réception vérifie.

Mais un programme exécutable ne se lit pas, ne se modifie pas, et ne se transmet pas. Ce qui permet d’intervenir, c’est autre chose. Neuf livrables, et ce qu’il en advient d’ordinaire :

  • Programme chargé dans l’automate : l’exécutable en service. Remis par construction.
  • Projet source : le fichier éditable de l’atelier logiciel (CODESYS, TwinCAT, WAGO ou l’équivalent constructeur), avec les blocs fonctionnels et la logique lisible. Rarement remis.
  • Configuration matérielle : topologie bus, adressage des entrées et sorties, paramétrage des modules. Rarement remise.
  • Description fonctionnelle : séquences, priorités, conditions de basculement, points de consigne calculés. Souvent partielle.
  • Liste de points : EDE en BACnet, table d’adressage Modbus, projet .knxproj en KNX. Variable.
  • Outil de programmation : le logiciel lui-même, sa version exacte, sa licence. Presque jamais.
  • Mots de passe : automates, niveaux d’accès supervision, comptes ingénieur, accès distant. Presque jamais au complet.
  • Licences de supervision : au nom de qui sont-elles enregistrées ? combien de points ? qu’est-ce qui devient payant à l’extension ? Rarement vérifié.
  • Sauvegarde de la supervision : la base, les vues, les historiques, et la procédure pour les restaurer ailleurs. Rarement testée.

Le cas KNX est le plus parlant, parce qu’il est binaire : un projet ETS peut être remis protégé par un mot de passe. Vous avez le fichier. Vous ne pouvez rien en faire. Personne n’a menti, le livrable figure bien au dossier.

Trois choses distinctes, qu’on confond toujours

C’est ici que la plupart des dossiers échouent, y compris ceux qui ont pensé au sujet. Pouvoir reprendre une régulation suppose trois éléments indépendants, et il en manque presque toujours au moins un.

1. Les fichiers. Les sources sous forme éditable. Une obligation de faire : quelqu’un doit les copier et les remettre.

2. Les droits. L’autorisation de les utiliser, de les modifier, et surtout de les faire modifier par un tiers. En droit suisse, avoir payé un développement n’emporte pas automatiquement la cession des droits d’auteur sur le programme : le transfert doit être convenu. Autrement dit, le silence du contrat ne joue pas en votre faveur. Il joue par défaut contre vous.

3. Les moyens. L’atelier logiciel, dans la bonne version, avec une licence utilisable. Beaucoup sont nominatifs, liés à une certification constructeur, ou délivrés au partenaire agréé et non au maître d’ouvrage.

Les fichiers sans les droits : vous détenez un document que vous n’avez pas le droit de faire modifier. Les droits sans les fichiers : vous détenez une clause. Les deux sans l’outil : vous détenez un fichier illisible et le droit de le regarder.

Aucun des trois ne suffit. Il faut les écrire séparément.

Pourquoi c’est le défaut, et pas une malveillance

Il faut être clair sur ce point, parce que la conclusion inverse est à la fois injuste et inutile : votre intégrateur ne vous piège pas. Trois mécanismes suffisent à expliquer la situation, et aucun ne suppose une intention.

La soumission décrit des fonctions, pas des livrables numériques. Un cahier des charges MCR courant spécifie des séquences, des performances, des protocoles. Il ne dit presque jamais ce qui doit être remis sous forme de fichiers, dans quel format, ni ce qu’on a le droit d’en faire. Ce qui n’est pas demandé n’est pas chiffré, et ce qui n’est pas chiffré n’est pas livré.

La réception vérifie que ça marche. Elle ne vérifie pas qu’un tiers pourrait reprendre l’installation. Ce sont deux essais différents, et le second ne figure au protocole que si quelqu’un l’y a mis.

Personne n’est en position de le réclamer plus tard. L’exploitant n’a pas le mandat. Le propriétaire ne sait pas que la question existe. Et l’intégrateur n’a aucune raison d’offrir spontanément ce que le contrat ne prévoit pas : ce n’est pas son rôle, et il a lui-même investi dans des bibliothèques de blocs qu’il réutilise d’un chantier à l’autre.

Ce dernier point mérite d’être reconnu plutôt que contesté : une partie du code d’une installation est souvent un savoir-faire d’entreprise légitime. La demande raisonnable n’est pas « donnez-moi tout ce que vous savez faire », c’est « donnez-moi de quoi exploiter, auditer et faire évoluer mon bâtiment ». Formulée ainsi, elle se négocie. Formulée comme une suspicion, elle se referme.

Ce que ça coûte, concrètement

L’audit s’arrête aux symptômes. Sans la logique, on constate qu’un bâtiment chauffe et refroidit simultanément, on ne peut pas dire pourquoi ni corriger la cause. On documente une anomalie au lieu de la résoudre.

La maintenance ne se remet pas en concurrence. Un contrat qu’un seul prestataire peut techniquement exécuter n’est pas un marché : c’est une reconduction. Le prix suit.

Une extension banale devient un projet. Ajouter deux zones sur une installation dont on ne peut pas ouvrir le programme, c’est reprogrammer en aveugle ou remplacer.

Un aléa d’entreprise devient un aléa de bâtiment. Reprise, cessation, fin de partenariat constructeur, départ de la seule personne qui connaissait le projet : tant que la reprise dépend d’une entreprise, la continuité de votre installation en dépend aussi.

Et cela se voit en due diligence. Un immeuble dont l’automatisation ne peut être reprise que par un seul prestataire porte une dépendance qui s’évalue, au même titre qu’un contrat de chauffage à long terme.

Les clauses à écrire

C’est la partie utile. Elle vaut pour un cahier des charges neuf comme pour la prochaine commande sur une installation existante. Chez Workswell, nos soumissions exigent systématiquement la remise du code source, des licences et de la documentation complète. Voici ce que cela veut dire, clause par clause.

  1. Remise des sources sous forme éditable et exploitable. Préciser le format, la version de l’atelier logiciel, et l’absence de protection par mot de passe ou de verrouillage empêchant l’ouverture. Un fichier protégé n’est pas un livrable.
  2. La remise n’est pas un événement, c’est un processus. C’est la clause la plus souvent oubliée, et la plus rentable : sans elle, vos sources datent de la réception et divergent dès la première intervention de service. Exiger la restitution d’une version à jour après chaque modification, et la conserver comme on conserve un plan révisé.
  3. Droit d’usage, de modification, et de faire modifier par un tiers. Sans limitation de durée, transférable à un propriétaire successif. Les trois verbes comptent : c’est le troisième qui ouvre le marché.
  4. L’outil, ou une alternative explicite. Soit la mise à disposition de l’atelier logiciel et de sa licence, soit, quand la certification constructeur l’interdit, l’engagement que la plateforme retenue compte au moins deux entreprises indépendantes capables d’intervenir en Suisse romande, nommées au dossier. C’est un critère de choix de plateforme, pas seulement une clause.
  5. Mots de passe et niveaux d’accès consignés au procès-verbal, y compris les comptes d’ingénierie et les accès distants. Avec la liste des comptes actifs et de leurs titulaires.
  6. Formats d’échange normalisés. EDE pour BACnet, table d’adressage documentée pour Modbus, projet ETS non verrouillé pour KNX. Ce sont eux qui rendent l’installation lisible indépendamment de l’outil.
  7. Une clause de dépôt, en repli. Quand un fournisseur refuse la cession (cela arrive, et ce n’est pas toujours abusif), le dépôt des sources auprès d’un tiers, libérable dans des cas définis (cessation d’activité, refus d’intervenir, fin de contrat), reste bien meilleur que rien.
  8. Le test de réception qui compte. Un tiers, avec les seuls livrables du dossier, doit pouvoir ouvrir le projet, modifier une valeur, recompiler et recharger l’automate. S’il ne le peut pas, le livrable n’existe pas. Cet essai prend une demi-journée et rend toutes les clauses précédentes vérifiables. Sans lui, elles restent déclaratives.

Cet essai n’est pas réservé à la réception. Il se conduit à l’identique sur une installation en service, et il donne la même réponse : reprenable, ou pas. Nous y revenons à la fin.

Certains maîtres d’ouvrage institutionnels ont formalisé tout ou partie de ces exigences dans des directives MCR/GTB publiques, que leurs fournisseurs appliquent sans difficulté particulière. Ce n’est donc pas une demande exotique : c’est une pratique établie, encore peu répandue chez les propriétaires privés et les gérances.

Et si l’installation est déjà en service ?

Trois questions, à poser à votre exploitant ou à votre intégrateur cette semaine :

  1. Où sont les sources de la régulation, et sous quel format ?
  2. Avec quel logiciel, dans quelle version, et sous quelle licence s’ouvrent-elles ?
  3. Quelles entreprises, autres que la vôtre, peuvent intervenir dessus ?

La qualité de la réponse vous renseigne autant que la réponse elle-même. Une réponse précise en 48 heures indique un dossier tenu. Une réponse évasive indique où vous en êtes.

Ensuite : votre levier, c’est la prochaine commande. Une extension, un renouvellement de contrat de maintenance, une migration de supervision. C’est le seul moment où la régularisation des livrables se négocie sans rapport de force défavorable, et où elle coûte quelques lignes de commande plutôt qu’un contentieux.

Deux limites, pour être honnête. Certaines plateformes ne permettent structurellement pas l’intervention d’un tiers, quelle que soit la clause : cela se décide au choix de la plateforme, pas après. Et sur une installation ancienne sans traçabilité, la reconstitution de la logique par l’observation est possible, mais c’est un travail, pas une formalité.

Une remarque pour finir

Là encore, rien n’est en panne.

Le bâtiment fonctionne, la supervision n’affiche aucune alarme, le contrat de maintenance est honoré, et l’exploitant fait correctement son travail. Le problème n’est visible nulle part, jusqu’au jour où vous voulez faire quelque chose, et où vous découvrez que vous ne pouvez pas.

C’est la même mécanique qu’une GTB qui affiche tout en vert pendant qu’un bâtiment chauffe et refroidit simultanément : une situation coûteuse, parfaitement stable, et qui ne déclenche aucun signal.

Ce n’est pas de la méfiance envers l’intégrateur. C’est de la bonne gestion patrimoniale. Le maître d’ouvrage doit rester propriétaire de son bâtiment jusque dans son cerveau : libre d’en maîtriser l’entretien, les évolutions et les coûts sur toute sa durée de vie.

Si votre intégrateur disparaissait demain, seriez-vous capable de faire vivre votre bâtiment ?

Audit de votre logiciel de supervision

Les trois questions ci-dessus vous donnent une indication. Un audit vous donne une réponse.

Nous auditons les supervisions en service, quelle que soit la marque, et sans en représenter aucune. Une journée sur site. Ce que nous vérifions :

  1. Le logiciel lui-même : version installée, support constructeur encore assuré ou non, et les licences : à quel nom sont-elles enregistrées, combien de points couvrent-elles, qu’est-ce qui devient payant le jour où vous étendez.
  2. Où vivent les alarmes, les historiques et les horaires : dans les automates, ou dans la supervision. C’est la question qui décide du coût de votre prochaine migration, et elle ne se pose presque jamais avant qu’il soit trop tard pour y répondre.
  3. Les sorties actuellement forcées, et depuis quand. C’est le point qui produit le plus souvent une correction immédiate, sans coût.
  4. La liste de points : existence, exactitude, lisibilité par un tiers.
  5. La restauration d’une sauvegarde, testée et non supposée. Une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde.
  6. Les comptes et les accès distants encore actifs, et à qui ils appartiennent.
  7. L’essai de reprise : ouvrir le projet avec les seuls éléments en votre possession, modifier une valeur sans effet sur l’exploitation, recompiler, recharger. En présence de votre exploitant, hors période sensible, avec retour arrière préparé et vérifié avant l’essai. C’est le seul test qui tranche : tout le reste est déclaratif.

Le livrable tient sur une page : ce que vous détenez, ce qui manque, ce qu’il faut demander, et à quel moment le demander pour l’obtenir sans rapport de force.

C’est aussi le préalable d’un audit MCR/GTB complet : relevé sur site, lecture des historiques, analyse de la logique de régulation, et un rapport qui distingue ce qui se corrige par paramétrage (effet immédiat, coût nul) de ce qui exige une reprogrammation ou un investissement. Sans les sources, cet audit s’arrête aux symptômes. C’est pourquoi il commence toujours par là.

Périmètre limité, résultat exploitable, aucune obligation de suite.

Demander un audit de votre supervision

← Tous les articles

À lire aussi

Articles

Un projet, une rénovation ou une question ?

Un premier échange suffit en général à cerner le potentiel et le périmètre du mandat.