Illustration générée par IA — visuel conceptuel.
Fin de contrat d’infogérance, changement d’exploitant, rénovation, migration vers une nouvelle architecture: la “sortie de parc” d’une baie réseau (et, très souvent, des serveurs/accès IT d’une gestion technique du bâtiment (GTB)) se joue moins sur le démontage du matériel que sur la rotation des accès et l’effacement maîtrisé de ce qui reste sur les équipements.
L’objectif de ce guide est simple: vous aider à produire une passation testable et traçable (inventaire, sauvegardes, rotation des secrets, révocation des certificats, retrait des accès distants, effacement des supports) pour un site hospitality/tertiaire, sans dépendre d’une marque de firewall/switch/GTB en particulier.
Dans quels cas ce guide s’applique (et ce qu’il ne couvre pas)
Cas typiques: changement de prestataire réseau, transfert d’un établissement à un nouvel exploitant, changement de solution GTB/GRMS, restructuration de l’architecture (segmentation OT/IT, nouveau firewall), remplacement d’un parc d’équipements, fin de location/retour constructeur.
Ce guide reste volontairement agnostique constructeur: pour les commandes exactes (effacement, export, “factory reset”, de-provision cloud), référez-vous à la documentation du fabricant de chaque équipement. En revanche, la logique (quoi inventorier, quoi révoquer, quoi tester, comment tracer) est largement transposable.
Pour replacer ces actions dans une architecture d’hôtel (réseaux Wi‑Fi, IPTV, VoIP, CCTV, GRMS/GTB), voir aussi: Architecture réseau IP d’un hôtel : principes et dépendances.
Et si vous cherchez une vue “cybersécurité” plus large (au-delà de la seule passation/sortie de parc): Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?.
1) Cadrer la passation avant de toucher au matériel
Clarifier le scénario de “sortie”
- Transfert: une partie des équipements et/ou des configurations doit continuer à vivre (nouvel exploitant, nouvelle équipe IT/OT).
- Remplacement: les équipements sont retirés et remplacés, avec bascule vers une nouvelle architecture.
- Rebut / recyclage / revente: les supports sortent de votre contrôle; l’effacement devient un sujet central.
Définir le périmètre (réseau + “IT de la GTB”)
Au-delà de la baie, une GTB moderne implique souvent des éléments IT (serveur de supervision, VM, base de données, accès distant intégrateur, passerelles IP, comptes “service”). Une passation sérieuse couvre généralement:
- Edge/accès Internet: routeur, firewall, VPN, liens de secours éventuels.
- Switching: cœur/distribution/accès, PoE, ports critiques (caméras, AP, contrôleurs).
- Wi‑Fi: contrôleur (ou plateforme cloud), SSID, sécurité, éventuel RADIUS/802.1X.
- Services d’infra: supervision, syslog, sauvegarde, NTP/DNS/DHCP/RADIUS si sur site.
- “IT de la GTB”: serveur(s) GTB, passerelles, accès distant, comptes d’intégration (API/BDD), historiques si présents sur supports locaux.
Si votre établissement est segmenté entre OT et IT, ce moment est souvent l’occasion de valider que la séparation est compréhensible et documentée: Séparer les équipements du bâtiment du réseau informatique (OT/IT).
Geler, capturer l’état, préparer un retour arrière
- Geler les changements non tracés pendant la fenêtre de passation (sinon l’inventaire devient faux).
- Capturer l’état: versions logicielles, topologie logique, photos de baie, exports de configuration quand c’est pertinent.
- Valider un plan de retour arrière: si une rotation de secrets coupe un service critique, comment revenir au dernier état fonctionnel.
2) Inventaire “utile” : matériel, accès, secrets, certificats, accès distants
Le point qui fait échouer une passation n’est pas l’absence d’un schéma, mais l’oubli d’un point d’entrée: un compte support, une clé API, un secret RADIUS, un certificat 802.1X, un tunnel VPN encore actif, ou un équipement “adopté” dans un tenant cloud dont personne ne récupère la main.
Un tableau unique pour piloter la sortie
Créez un tableau “Identité / Secret / Où c’est configuré / Action (révoquer, détruire, transférer) / Preuve”. Exemple de structure:
| Domaine | À inventorier | Exemples | Preuve attendue |
|---|---|---|---|
| Comptes | Comptes locaux + comptes annuaires/cloud | Admins, comptes “break-glass”, comptes support | Liste des comptes restants + responsabilité (qui en a la garde) |
| Secrets machine-à-machine | Secrets partagés et jetons | RADIUS shared secret, tokens API, secrets d’intégration GTB | Journal de rotation (sans stocker les secrets en clair) |
| Clés | Clés SSH, clés privées, PSK | Accès admin, VPN, Wi‑Fi (selon design) | Anciennes clés invalidées / nouvelles clés déployées |
| Certificats | Chaînes de confiance, certificats serveur & client | EAP‑TLS/802.1X, VPN, HTTPS d’administration | Liste des certificats révoqués + test d’échec/succès |
| Accès distants | Tunnels et portails | VPN SSL/IPsec, bastion, accès cloud constructeur, modem/4G | Tableau des accès supprimés/transférés (date + responsable) |
| Supports & stockage | Tout ce qui stocke des données | SSD/HDD, eMMC, cartes SD, logs locaux, VM/snapshots | Fiche d’effacement (méthode, outil, n° de série, destination) |
Ne pas oublier les “dépendances invisibles”
Les services d’adressage, de noms et d’authentification sont souvent hors de la baie (VM, cloud, prestataire) mais indispensables: DNS/DHCP/RADIUS/NTP, supervision, sauvegarde, licences. Si vous devez sécuriser la continuité de service, gardez une vue “jour‑2”: Réseau informatique : quelles sauvegardes prévoir pour redémarrer après une panne ?.
3) Sauvegardes et DOE : ce qu’on transfère vs ce qu’on détruit
Transférer ce qui rend l’exploitation possible (sans exposer les secrets)
- Dossier réseau: plan IP/VLAN, schémas, logique de nommage (si vous en avez une), règles firewall structurantes, paramètres Wi‑Fi.
- Procédures d’exploitation: restauration, mises à jour, supervision, points de contact.
- Configurations exportées si elles servent de base au nouvel exploitant (et seulement via un canal sécurisé).
Sur la logique “DOE orienté exploitation” (qui remet quoi, sous quelle forme), vous pouvez compléter avec: DOE et maintenance d’un hôtel connecté : livrables à remettre à l’exploitant.
Éviter la fuite par les exports et les images systèmes
- Considérez tout export comme potentiellement sensible: certains équipements incluent des secrets (ou des éléments dérivables) dans les sauvegardes.
- Une image VM/snapshot peut contenir des clés, des jetons, des historiques, et des identifiants de services.
- Si une configuration doit être transmise, planifiez la rotation des secrets (section suivante) comme une action à part entière, avec tests.
4) Rotation des secrets : la règle de base en sortie de parc
En fin de contrat, le risque n’est pas seulement qu’un ancien compte reste actif. C’est aussi que quelqu’un conserve une ancienne copie de configuration (ou un export) qui, si les secrets n’ont pas été changés, reste exploitable.
Rotation, révocation, destruction : clarifier l’action attendue
- Rotation: on conserve le service, mais on change les secrets (comptes, mots de passe, clés, jetons) et on met à jour les dépendances.
- Révocation: on invalide une identité (certificat, accès) et on force l’échec des tentatives d’usage futures.
- Destruction: on supprime toute trace d’un secret pour qu’il ne puisse pas être récupéré (référence utile côté cryptographie: la définition de “key destruction” dans NIST SP 800‑57 Part 1 Rev.5). Source NIST SP 800‑57 Part 1 Rev.5 (PDF).
Check-list de rotation (ordre conseillé)
- Comptes: supprimer les comptes nominaux sortants, supprimer/justifier les comptes génériques, changer les mots de passe des comptes administrateurs conservés.
- Chemins d’administration: remplacer les clés SSH, désactiver les jetons d’API, retirer les adresses IP/ACL “allowed hosts” associées à l’ancien prestataire.
- Secrets d’infrastructure: secrets partagés RADIUS/802.1X, secrets entre contrôleur et équipements, secrets de supervision/collecte (SNMPv3, syslog, agents).
- VPN et interconnexions: comptes VPN, tunnels site-à-site, comptes “support”, règles temporaires (NAT/port-forward) laissées pendant un chantier.
Point d’attention: ne stockez pas les secrets en clair dans le DOE. Préférez un coffre (ou un mécanisme interne) et un journal “fait / vérifié”, qui prouve la rotation sans divulguer la valeur.
5) Certificats 802.1X (EAP‑TLS) : révocation, chaîne de confiance, tests
En environnement hôtel/tertiaire, 802.1X peut être utilisé sur le Wi‑Fi staff, certains VLAN d’administration, ou des ports filaires. C’est puissant… mais les certificats sont des identités “durables”, donc la passation doit traiter explicitement la révocation.
Ce que disent les textes (et ce que ça change côté projet)
La RFC 5216 (EAP‑TLS) rappelle que les certificats sont des assertions d’identité longue durée et que les implémentations doivent pouvoir vérifier la révocation; elle impose le support des Certificate Revocation Lists (CRL) et recommande le support d’OCSP. Source RFC 5216 (EAP‑TLS).
Procédure de passation (agnostique constructeur)
- Identifier où “vit” l’autorité de certification (CA) et qui en a la responsabilité (interne, prestataire, cloud).
- Inventorier les certificats et chaînes de confiance réellement utilisés (serveur RADIUS, certificats clients, éventuels certificats sur contrôleurs/équipements).
- Révoquer ce qui doit l’être (ex: certificats d’équipements appartenant à un prestataire sortant) et vérifier que l’infrastructure de statut (CRL/OCSP) reste atteignable dans la nouvelle organisation.
- Nettoyer les “trust anchors”: retirer les CA/intermédiaires qui ne doivent plus être approuvés.
- Tester avec un certificat révoqué (échec attendu) et un certificat valide (succès attendu).
Pour une approche orientée exploitation (éviter les pannes liées aux certificats, organiser le renouvellement et la révocation, définir des tests), voir aussi: Wi‑Fi 802.1X : éviter la panne quand un certificat expire (EAP‑TLS).
6) Retirer les accès distants (firewall, GTB, supervision) : l’angle mort classique
Un démontage “propre” peut laisser intact un accès distant, si l’équipement (ou son remplaçant) reste joignable via VPN, NAT, compte cloud, tunnel support, ou bastion. Dans un transfert, l’objectif est de fermer ce qui doit disparaître et de transférer ce qui doit rester, avec de nouveaux secrets et une nouvelle responsabilité.
Côté firewall / routeur
- Supprimer ou transférer les comptes VPN, certificats VPN, tunnels IPsec/SSL, et les règles temporaires (port-forwarding de chantier, accès “exceptionnels”).
- Désactiver l’administration depuis Internet si elle n’est pas strictement nécessaire (et, si elle est nécessaire, limiter par IP, MFA, bastion, journalisation).
- Vérifier qu’aucune IP de prestataire sortant n’est encore autorisée dans des ACL d’administration.
Côté GTB / supervision
- Retirer les tunnels “support” permanents, VPN intégrateur, accès distants implicites.
- Si la GTB ou des équipements réseau sont gérés via une plateforme cloud: prévoir une étape de désassociation / de-provision du tenant sortant et valider que la nouvelle équipe récupère l’administration.
- Changer les comptes “service” des connecteurs (BDD, API, passerelles) lors d’un transfert d’exploitation.
7) Effacement des configurations et des supports : s’aligner sur une méthode (Clear / Purge / Destroy)
Un switch, un firewall, un contrôleur Wi‑Fi, un serveur GTB ou une VM de supervision peuvent contenir: configuration, logs, captures, certificats, clés privées, tokens, historiques, parfois des identifiants d’accès à d’autres systèmes. Traitez donc l’effacement comme un vrai sujet de sanitization, pas comme un simple “factory reset”.
Trois méthodes à connaître (repère: NIST SP 800‑88 Rev.2)
NIST SP 800‑88 Rev.2 (septembre 2025) propose une classification pratique:
- Clear: techniques logiques visant les zones adressables par l’utilisateur (par ex.: réécriture, ou option de remise à l’état usine). Le document indique que ces techniques n’affectent typiquement pas l’utilisabilité du support.
- Purge: techniques physiques ou logiques rendant la récupération infeasible même avec des moyens de laboratoire “state of the art”, tout en gardant le support potentiellement réutilisable; NIST indique que, lorsque possible, Purge devrait être utilisé plutôt que Clear.
- Destroy: destruction rendant la récupération infeasible et rendant le support inutilisable.
Référence: NIST SP 800‑88 Rev.2 (PDF) (page CSRC: NIST SP 800‑88 Rev.2 (fiche publication)).
Choisir la méthode selon la destination (décision projet)
- Transfert interne: un Clear peut être acceptable si vous gardez le contrôle du support et si la vérification est possible, mais l’arbitrage dépend de votre niveau de sensibilité et de ce qui est stocké (clés privées, historiques, données personnelles, etc.).
- Transfert à un tiers / revente: privilégier une approche de type Purge (voire Destroy selon la sensibilité) et documenter la méthode + la preuve.
- Recyclage / rebut: la question devient: qui a le contrôle du support, et quelle preuve vous pouvez archiver.
Si votre projet traite aussi l’effacement de serveurs vidéo/NAS/NVR, vous pouvez compléter avec: Remplacer un NVR, NAS ou serveur vidéo : effacer disques et cartes SD (méthode NIST 800‑88).
Vérifier et tracer: une preuve d’effacement, pas une intention
NIST SP 800‑88 Rev.2 insiste sur la vérification des résultats (inspection pour confirmer que la technique a bien abouti) et propose un modèle de Certificate of Sanitization (annexe) pour documenter l’opération: méthode (Clear/Purge/Destroy), technique, outils (avec version), vérification/validation, destination, signatures. Source NIST SP 800‑88 Rev.2 (PDF).
Concrètement, votre dossier de clôture doit permettre de répondre à deux questions simples:
- “Qu’est-ce qui est sorti du site?” (numéro de série, support, destination)
- “Qu’est-ce qui a été fait dessus?” (méthode, outil, qui, quand, vérification)
8) Dossier de clôture : ce qu’on remet à l’exploitant (ou au propriétaire)
Livrables minimum (orientés passation)
- Inventaire final: matériel, versions, numéros de série, rôle, destination.
- Dossier réseau: schémas, plan IP/VLAN, éléments Wi‑Fi utiles, sauvegardes transmises (si applicable).
- Journal de rotation / révocation: comptes, clés, tokens, secrets partagés, certificats.
- Journal de retrait / transfert des accès distants: VPN, portails, bastions, comptes support.
- Fiches d’effacement: par support/équipement sortant, avec preuve vérifiable.
Critères d’acceptation (tests simples, reproductibles)
- Un compte de l’ancien prestataire ne fonctionne plus (connexion admin/VPN: échec attendu).
- Un certificat 802.1X révoqué n’ouvre plus l’accès (échec attendu) et un certificat valide fonctionne (succès attendu).
- Aucun tunnel VPN/support “historique” n’est actif.
- Les équipements sortants redémarrent sans configuration, sans comptes, sans certificats importés (selon la méthode retenue) et la preuve d’effacement est archivée.
Check-list imprimable (résumé)
A. Préparation
- [ ] Scénario validé (transfert / remplacement / rebut / retour constructeur)
- [ ] Fenêtre d’intervention + rollback validés
- [ ] Gel des changements + capture de l’état (versions/topologie/photos)
B. Inventaire
- [ ] Matériel + stockage + numéros de série + destination
- [ ] Comptes, secrets, certificats, accès distants listés dans un tableau unique
C. Sauvegardes / DOE
- [ ] Livrables à transférer identifiés (schémas, configs utiles, procédures)
- [ ] Risques de fuite par exports/images pris en compte (secrets non transmis en clair)
D. Rotation / révocation
- [ ] Comptes admins changés / comptes sortants supprimés
- [ ] Clés SSH, tokens API, secrets partagés (RADIUS/802.1X, supervision) rotatés
- [ ] Certificats 802.1X: inventaire, révocation, nettoyage CA, tests d’échec/succès
E. Accès distants
- [ ] VPN/tunnels supprimés ou transférés avec nouveaux secrets
- [ ] Portails cloud/support: désassociation (de-provision) du tenant sortant et transfert de la responsabilité
F. Effacement & preuve
- [ ] Méthode Clear/Purge/Destroy choisie selon la destination du support
- [ ] Effacement réalisé + vérifié
- [ ] Preuve archivée (fiche / certificat interne, incluant outil et version)
G. Passation
- [ ] Dossier final remis (inventaire, journaux rotation/révocation, retraits d’accès distants, preuves d’effacement)
- [ ] Tests d’acceptation réalisés et signés
Sources et documentation
- NIST SP 800‑88 Rev.2 — Guidelines for Media Sanitization (PDF)
- NIST SP 800‑88 Rev.2 — fiche publication CSRC
- RFC 5216 — The EAP‑TLS Authentication Protocol
- NIST SP 800‑57 Part 1 Rev.5 — Recommendation for Key Management: Part 1 – General (PDF)
Pour une passation “fin de vie / transfert” adaptée à votre établissement (baie réseau, Wi‑Fi, GTB/GRMS, vidéosurveillance, contrôle d’accès), l’idéal est de transformer cette check-list en plan d’exécution (responsables, séquencement, tests, preuves). Si vous souhaitez un cadrage projet ou une revue de dossier de passation, vous pouvez nous contacter via Domocasa.
