Exigences de cybersécurité GTB dans un CCTP : ce qu'il faut écrire, et comment le réceptionner
Une GTB est un système informatique qui commande le chauffage, la ventilation, l'éclairage, parfois les accès et la sûreté d'un bâtiment, souvent accessible à distance par l'intégrateur. L'ANSSI a publié un guide de recommandations de sécurité pour la GTB/GTC ; il ne contient ni clauses ni check-list. Voici comment ses recommandations se transforment en exigences de CCTP vérifiables, famille par famille, avec la preuve à exiger en réception.
Pourquoi la cybersécurité se décide au CCTP
Une fois la GTB installée, changer une architecture réseau, remplacer un automate sans chiffrement ou renégocier les accès distants de l'intégrateur coûte un avenant et une saison de mise au point. Au CCTP, les mêmes exigences coûtent quelques lignes. Le guide de recommandations de l'ANSSI pour la gestion technique du bâtiment (référence ANSSI-PA-110, publié en avril 2026) donne la référence technique ; le travail du rédacteur est de transformer chaque recommandation en une exigence vérifiable, avec un niveau (essentiel ou renforcé) et une preuve attendue à la réception.
Deux niveaux, un choix du maître d'ouvrage
Toutes les exigences n'ont pas le même coût ni la même urgence. Une approche courante distingue un niveau Essentiel, applicable à tout lot GTB (les mesures qui évitent les incidents les plus fréquents à coût faible), et un niveau Renforcé, pour les bâtiments sensibles (santé, données, sites industriels, établissements recevant du public importants) ou les GTB raccordées à la sûreté. Le CCTP nomme le niveau retenu dans son chapeau, et chaque exigence indique à quel niveau elle s'applique : sans cela, les candidats chiffrent des choses différentes.
Les dix familles d'exigences
| Famille | Ce que le CCTP exige | Preuve en réception |
|---|---|---|
| 1. Cartographie et inventaire | Inventaire de tous les équipements (automates, supervision, passerelles, équipements réseau, objets connectés) avec version logicielle, adresse, rôle, et schéma réseau à jour. Tenu par l'intégrateur puis remis à l'exploitant. | Inventaire et schéma remis dans le DOE, vérifiés par sondage sur site. |
| 2. Segmentation réseau | Réseau GTB séparé du réseau bureautique et d'Internet, cloisonnement entre niveaux (terrain, automatisme, supervision) et entre domaines si nécessaire, filtrage des flux par règles explicites, aucun équipement GTB exposé directement sur Internet. | Matrice de flux, configuration des pare-feu, test d'accès depuis le réseau bureautique. |
| 3. Administration et accès distants | Télémaintenance uniquement par un accès dédié, chiffré de bout en bout (tunnel IPsec ou équivalent, terminé au plus près des équipements), activé à la demande et journalisé ; pas d'accès permanent ; comptes nominatifs et authentification forte pour les administrateurs ; registre des accès distants tenu par l'exploitant. | Démonstration de l'activation et de la désactivation, extrait du journal, registre remis. |
| 4. Comptes et authentification | Suppression ou changement de tous les comptes et mots de passe par défaut, comptes nominatifs, profils de droits (consultation, exploitation, administration), politique de mots de passe, désactivation des comptes de l'intégrateur à la réception sauf contrat de maintenance explicite. | Liste des comptes et de leurs droits, test de connexion avec les identifiants par défaut (doit échouer), remise des mots de passe sous pli. |
| 5. Durcissement des équipements | Services et ports inutiles désactivés, interfaces web non utilisées fermées, démarrage sur support amovible (USB) interdit sur les postes de supervision, liste blanche des applications autorisées sur les serveurs au niveau renforcé, postes de supervision dédiés. | Relevé de configuration par équipement, scan des ports ouverts comparé à la liste attendue. |
| 6. Mises à jour et vulnérabilités | Versions à jour à la livraison, procédure de mise à jour documentée et testée, engagement de fourniture des correctifs de sécurité pendant la garantie, information de l'exploitant en cas de vulnérabilité publiée sur un composant installé. | Tableau des versions installées et des dernières versions éditeur, procédure dans le DOE. |
| 7. Journalisation et supervision de sécurité | Journalisation des connexions, des actions d'administration et des modifications de programmes, horodatage fiable (synchronisation horaire des automates et de la supervision, y compris en BACnet), conservation des journaux sur une durée définie, export possible vers un outil de l'exploitant au niveau renforcé. | Extraits de journaux horodatés, vérification de la synchronisation horaire. |
| 8. Sauvegarde et restauration | Sauvegarde des programmes des automates, de la configuration de la supervision et des bases de données, stockée hors du système, procédure de restauration testée, mode de repli manuel des installations vitales en cas de panne de la GTB. | Test de restauration en présence du maître d'ouvrage, procès-verbal, démonstration du mode de repli. |
| 9. Protocoles et flux | Protocoles sécurisés quand ils existent (BACnet/SC, HTTPS, OPC UA avec sécurité activée, SSH), protocoles non chiffrés confinés au réseau terrain cloisonné, interdiction des protocoles d'administration en clair. | Capture réseau ou configuration montrant les protocoles actifs. |
| 10. Documentation, outils et réversibilité | Programmes sources, outils de programmation et licences remis ou identifiés, dossier de sécurité dans le DOE, procédure de gestion des incidents, conditions de reprise par un tiers. | Contrôle du contenu du DOE sur une check-list signée. |
Écrire une exigence vérifiable
Une exigence de CCTP a quatre parties : un identifiant (E-07 par exemple), le niveau auquel elle s'applique, l'énoncé (« l'accès de télémaintenance est établi par un tunnel chiffré terminé sur un équipement dédié placé au plus près des automates ; il est activé par l'exploitant pour une durée définie et désactivé automatiquement à son terme »), et la preuve attendue à la réception (« démonstration de l'activation et de la désactivation, extrait de journal »). La référence à la recommandation ANSSI correspondante permet aux candidats de comprendre l'intention et au contrôleur de ne rien oublier. Une exigence formulée « l'entreprise respectera les bonnes pratiques » n'est ni chiffrable, ni réceptionnable.
La réception : une check-list, un taux, des bloquantes
La réception cybersécurité se fait sur une check-list qui reprend chaque exigence avec son résultat (conforme, non conforme, partiel, sans objet), la preuve fournie et un commentaire. Un taux de conformité se calcule, mais certaines non-conformités sont bloquantes quelles que soient les autres : des identifiants par défaut encore actifs, un accès distant permanent non journalisé, un équipement exposé sur Internet, l'absence de sauvegarde restaurable. Elles conditionnent la réception, pas seulement une réserve. Le statut « sans objet » doit être justifié (par exemple : pas d'accès distant prévu).
Après la réception : deux registres à tenir
La sécurité d'une GTB se dégrade dès qu'on cesse de la tenir. Deux tableaux suffisent à l'exploitant : le registre des accès distants (qui, quand, pourquoi, autorisé par qui, clôturé quand) et l'inventaire des équipements avec leurs versions et la date de dernière mise à jour. Le contrat de maintenance précise qui fournit les correctifs, sous quel délai, et comment les comptes de l'intégrateur sont gérés entre deux interventions.
Comment évaluer les offres sur ce chapitre
Dans la grille d'analyse des offres, la cybersécurité mérite un critère pondéré à part, noté sur des éléments concrets : réponse exigence par exigence (conforme, variante, non conforme), architecture réseau proposée, dispositif d'accès distant décrit, engagements de mise à jour, moyens affectés (compétences des intervenants, et non de simples références de chantiers), contenu du DOE de sécurité. Un candidat qui répond « conforme à tout » sans décrire son dispositif d'accès distant mérite une question avant la notation.
Référence : guide ANSSI-PA-110, recommandations de sécurité pour la GTB/GTC (avril 2026), disponible sur le site de l'ANSSI ; recommandations relatives à l'administration sécurisée des systèmes d'information (ANSSI-PA-022) pour les principes d'administration. Les exigences ci-dessus sont des exemples de formulation, à adapter au niveau retenu et au bâtiment.
Questions fréquentes
- Un intégrateur peut-il refuser ces exigences ?
- Il peut les chiffrer, proposer une variante ou signaler une impossibilité technique sur un équipement existant ; c'est le rôle de la réponse exigence par exigence. Un refus global est une information sur le candidat.
- Et pour une GTB existante ?
- Les mêmes familles s'appliquent, dans un ordre de priorité : inventaire, suppression des accès permanents et des mots de passe par défaut, segmentation, sauvegarde testée. Elles peuvent faire l'objet d'un marché de mise en sécurité séparé, avec la même logique de preuves.
- Faut-il un audit de sécurité à la réception ?
- Pour le niveau renforcé ou un bâtiment sensible, un contrôle par un tiers (test d'intrusion limité au périmètre GTB, revue de configuration) complète utilement la check-list. Pour le niveau essentiel, la check-list avec preuves, signée des deux parties, est l'objectif réaliste.
Contenu pédagogique à partir des textes et guides publics cités. Il ne constitue pas un conseil juridique ; vérifiez les textes consolidés sur Légifrance et les guides sur le site de l'ANSSI à la date de votre projet.