Plan d’adressage IP & nomenclature (VLAN/SSID/DHCP/réservations) : méthode ‘bâtiment’ orientée exploitation

Illustration générée par IA — visuel conceptuel.

Pourquoi un plan d’adressage « bâtiment » est un sujet d’exploitation (pas seulement de réseau)

Dans un hôtel, un immeuble ou une grande villa, le réseau IP devient une infrastructure de service : Wi‑Fi, IPTV, VoIP, vidéosurveillance, contrôle d’accès, GRMS/GTB, supervision et postes d’administration cohabitent souvent sur le même LAN. L’erreur classique consiste à faire “fonctionner” le réseau, sans construire un plan d’adressage et une nomenclature capables de survivre aux extensions, aux remplacements, aux nouveaux prestataires et au turnover exploitation.

L’objectif de ce guide est opérationnel : fournir une méthode maintenable (DOE + exploitation) pour structurer VLAN, SSID, DHCP et réservations, avec une gouvernance simple. Les conventions proposées sont des recommandations de projet (elles ne sont pas des obligations normatives universelles) : elles doivent être adaptées au bâtiment, aux outils (firewall, switches, contrôleur Wi‑Fi, serveur DHCP) et aux responsabilités (IT, intégrateur courant faible, exploitant).

Prérequis : ce que le plan doit clarifier avant de parler d’IP

Découper le réseau par usages (et pas par fabricants)

Commencez par lister les familles d’équipements et leurs besoins d’échange. Dans un hôtel, cette démarche est cohérente avec une architecture IP convergée (Wi‑Fi, IPTV, VoIP, CCTV, GRMS, etc.) telle que décrite dans notre guide : Architecture réseau IP d’un hôtel.

Exemples de familles (à adapter) :

• Invités (Internet uniquement, isolation entre clients selon projet)
• Personnel / métiers (PMS, back-office, terminaux, imprimantes)
• Voix (IPBX/VoIP)
• Vidéo (caméras ↔ NVR/VMS)
• Systèmes techniques (GRMS/GTB/contrôleurs/automates, passerelles)
• Administration (management équipements réseau, consoles, supervision)

Cette étape sert à produire des VLAN utiles, pas une collection de numéros. Pour le principe de séparation logique et le rôle du filtrage inter-VLAN, voir : VLAN : pourquoi séparer domotique, caméras, invités….

Repère (guide constructeur, non “normatif”) : Cisco rappelle, dans un guide orienté équipements Cisco Business, des bonnes pratiques comme la séparation du trafic de management et du trafic utilisateur, et la nécessité de restreindre l’interconnexion inter‑VLAN si elle est requise (Cisco — VLAN Best Practices and Security Tips).

Définir le niveau de dépendance au DHCP

Décidez clairement quels équipements peuvent être en DHCP “pur”, lesquels doivent être stables (réservations DHCP ou IP fixes), et lesquels doivent rester en IP fixe (cas typiques : certains cœurs de réseau, certains serveurs, certaines passerelles critiques selon architecture). Il n’existe pas de règle universelle : l’enjeu est la maintenabilité et la cohérence des procédures.

Recommandation de projet : évitez d’avoir en parallèle (sans règle) des IP fixes « prises à la volée », des réservations non documentées et des plages DHCP qui se chevauchent. Le sujet n’est pas uniquement technique ; c’est une discipline d’exploitation.

Choisir une stratégie d’adresses privées réaliste (RFC1918) et éviter les collisions

Pour l’adressage interne, les plages privées IPv4 de référence sont celles décrites par la RFC1918 : 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 (références : IANA – Private-use IP addresses, RFC1918).

Point d’attention : 100.64.0.0/10 correspond au « Shared Address Space » défini par la RFC6598, conçu pour des usages côté fournisseurs d’accès / déploiements CGN. Ce n’est pas une plage RFC1918. Recommandation de projet : dans un réseau “bâtiment”, évitez de le traiter comme une alternative “équivalente” aux plages RFC1918 ; si un contexte vous conduit malgré tout à l’utiliser, documentez-le explicitement et anticipez les cas où ce choix peut créer des difficultés lors d’interconnexions avec des environnements utilisant déjà du CGN (références : RFC6598, IANA – IPv4 Address Space).

Recommandation de projet : notez explicitement vos contextes de risque de collision (VPN inter-sites, prestataires connectés, interconnexions avec un siège, réseaux opérateurs). L’objectif n’est pas d’interdire une plage « par principe », mais d’éviter les chevauchements qui rendent un dépannage interminable.

Méthode en 7 étapes : plan d’adressage IP + nomenclature VLAN/SSID/DHCP

Étape 1 — Écrire une « table des segments » (VLAN ↔ rôle ↔ flux) avant les sous-réseaux

Recommandation de projet : avant d’attribuer une seule IP, formalisez une table des segments (un onglet Excel/CSV suffit) et faites‑la valider par les parties prenantes (IT, exploitant, lots techniques concernés). Cette table est un livrable de conception/exploitation : elle n’a rien d’“obligatoire” au sens normatif, mais elle évite la majorité des incohérences de terrain.

Avant d’attribuer une seule IP, produisez une table simple (un onglet Excel/CSV suffit) :

• Nom du segment (lisible)
• VLAN ID
• Rôle / usage
• Qui s’y connecte (types d’équipements)
• Services attendus (DHCP, DNS, NTP, accès Internet, accès serveurs internes)
• Flux autorisés vers d’autres VLAN (principes de filtrage)

Cette table est le cœur de la discussion IT/OT : elle évite de découvrir après coup que les caméras doivent atteindre le NVR, ou que le GRMS doit parler à une passerelle, ou qu’un VLAN invités a “vu” le réseau technique.

Exemple (simplifié) de table des segments — cas hôtel

Exemple de projet (à adapter) : une structure lisible, orientée exploitation. Les VLAN ID, noms et sous-réseaux ci-dessous sont des exemples ; ils doivent être ajustés à votre firewall, à vos contraintes (multi-bâtiments/étages) et à vos besoins de capacité.

Segment	VLAN	Usage principal	Services attendus	Échanges typiques (principes)
GUEST	20	Wi‑Fi invités	DHCP, DNS, Internet	Internet uniquement (pas d’accès aux réseaux métiers/techniques)
STAFF	30	Personnel / back‑office	DHCP, DNS	Accès restreint aux services internes nécessaires
VOICE	40	Téléphonie IP	DHCP (options selon IPBX), DNS	Accès IPBX + services nécessaires (à cadrer)
VIDEO	50	Caméras ↔ NVR/VMS	DHCP ou réservations, DNS si besoin	Caméras vers NVR/VMS ; administration depuis MGMT uniquement
TECH/GRMS	60	Contrôleurs chambre / GTB / passerelles	Souvent stables (réservations), DNS/NTP selon architecture	Accès uniquement aux serveurs/passerelles requis (PMS/GTB selon projet)
MGMT	99	Administration réseau	IP stables	Accès d’administration aux équipements (switch/AP/firewall/NVR)

Étape 2 — Définir une convention de nommage VLAN cohérente (et acceptable en exploitation)

Recommandation de projet : considérez la nomenclature VLAN comme un outil d’exploitation (incidents, changements, tickets, supervision), pas comme un “détail de config”. L’objectif n’est pas d’être “universel”, mais d’être cohérent et compréhensible par une autre équipe.

Recommandation de projet : adoptez un schéma stable et lisible, par exemple :

• VLAN-[SITE]-[FONCTION]-[ZONE] (ex. VLAN-HOTEL-VIDEO-ETAGE2)
• ou [FONCTION]-[ZONE] si un seul site (ex. VIDEO-ETAGE2)

Évitez les noms qui décrivent uniquement le fabricant ou l’historique (« VLAN-CISCO », « VLAN-NEW »). Un plan doit rester compréhensible par un autre mainteneur.

Étape 3 — Mapper VLAN ↔ sous-réseaux IP : garder une logique « qui se lit »

Recommandation de projet : imposez une logique de lecture (et écrivez-la dans le DOE) : une IP doit donner un indice sur le site/la zone/le rôle, sans avoir à interroger dix personnes. La “bonne” logique dépend de votre exploitation (multi-bâtiments, outillage, supervision, conventions groupe), mais l’absence de logique finit presque toujours en contournements.

Le plan d’adressage doit permettre d’inférer le rôle d’une IP. Une méthode courante consiste à :

• Réserver une plage par macro-famille (ex. utilisateurs / invités / vidéo / technique / admin)
• Allouer ensuite des sous-réseaux par VLAN

Recommandation de projet : documentez explicitement vos choix (pourquoi cette plage, quelles réserves, quelles extensions possibles). Un plan “joli” mais non expliqué finit souvent par être contourné.

Exemple (projet) de mapping VLAN ↔ sous-réseaux — hôtel

Exemple de projet (RFC1918) : une base lisible où le troisième octet reflète le VLAN. Ce schéma n’est pas obligatoire ; l’important est la cohérence et la documentation.

• VLAN 20 (GUEST) → 10.20.20.0/24
• VLAN 30 (STAFF) → 10.20.30.0/24
• VLAN 40 (VOICE) → 10.20.40.0/24
• VLAN 50 (VIDEO) → 10.20.50.0/24
• VLAN 60 (TECH/GRMS) → 10.20.60.0/24
• VLAN 99 (MGMT) → 10.20.99.0/24

Si vous avez plusieurs bâtiments (annexe, riad, centre de conférences), une variante consiste à réserver un bloc par bâtiment puis à répliquer la logique par VLAN à l’intérieur de ce bloc. L’arbitrage dépend de vos équipes et de vos outils (supervision, inventaire, gestion des incidents).

Étape 4 — Définir le modèle DHCP : scopes, options, et politique de réservations

Recommandation de projet : considérez le DHCP comme un service d’exploitation à gouverner (naming des scopes, règles de changement, traçabilité), pas comme “un automatique” qu’on laisse dériver. Ce n’est pas une obligation du protocole : c’est une décision d’organisation pour garder le réseau maintenable.

Le DHCP n’est pas qu’un service automatique : dans beaucoup d’exploitations, il devient un point de repère utile (baux, attributions, réservations), à condition d’être gouverné et documenté. Ce n’est pas une propriété « universelle » du DHCP : c’est un choix d’exploitation.

Recommandations de projet (à valider selon votre serveur DHCP et votre architecture) :

• Un scope par VLAN (ou par sous-réseau) avec un nom cohérent
• Réservations DHCP pour les équipements qui doivent rester à adresse stable (NVR, contrôleurs, bornes critiques, imprimantes métiers, passerelles), plutôt que des IP fixes dispersées sans gouvernance
• Une règle claire : qui a le droit de créer/modifier une réservation, et comment c’est tracé

Pour la documentation et la remise au client côté réseau, voir : Documentation réseau : schémas et sauvegardes.

Étape 5 — Nomenclature SSID : distinguer “nom visible” et “réseau réel”

Un SSID est le nom donné à un WLAN (réseau Wi‑Fi) que voit le client ; côté contrôleur, on parle souvent de profil SSID / WLAN selon les plateformes. Dans la terminologie ArubaOS, la documentation décrit le SSID comme un nom donné à un WLAN (sources Aruba : ArubaOS WebHelp, AOS 8 User Guide).

Recommandation de projet :

• SSID visible : orienté expérience (ex. HOTEL-GUEST, HOTEL-STAFF)
• Nom interne (WLAN / profil) : orienté exploitation (ex. WLAN-GUEST-VLAN20)
• Mapping SSID ↔ VLAN explicitement documenté (et testé)

Évitez de multiplier les SSID : chaque SSID supplémentaire ajoute de l’overhead (trames de management) et peut réduire l’efficacité radio. Aruba rappelle ce principe dans ses recommandations de planification/déploiement Wi‑Fi (source : Aruba TechDocs — Wi‑Fi 6E planning & deployment).

On retrouve également cette recommandation dans des guides de déploiement voix rédigés par des éditeurs tiers sur base d’infrastructures Aruba (source : Voice SD660 Aruba BPG). Ce n’est pas une règle universelle : le nombre acceptable dépend du design radio, des bandes, des terminaux (legacy/IoT), des exigences de roaming, et doit être arbitré puis validé par étude radio et recette.

Pour l’approche Wi‑Fi en hôtellerie (couverture/capacité/segmentation), voir : Wi‑Fi hôtelier et Wi‑Fi invités : sécurité, isolation et expérience.

Étape 6 — Écrire une politique “IP fixes vs réservations DHCP” (et l’assumer)

Ce point évite les réseaux où chaque prestataire “prend une IP au hasard”. Définissez une politique simple :

• Réseau (routeurs, firewalls, cœurs, management) : IP fixes ou réservations strictement contrôlées (à décider selon vos outils)
• Systèmes critiques (NVR, serveurs, contrôleurs) : stables et documentés
• Terminaux (clients Wi‑Fi, smartphones, laptops) : DHCP sans réservation
• Objets techniques (caméras, interphones, contrôleurs) : souvent en réservations DHCP (meilleure traçabilité si la procédure de remplacement est tenue), avec procédure de remplacement (MAC change, réservation à mettre à jour)

Le choix n’est pas “technique” uniquement : il dépend de votre capacité d’exploitation (qui maintient quoi, avec quel outillage, et quel niveau de contrôle).

Étape 7 — Organiser la gouvernance : qui décide, qui documente, qui valide

Un plan d’adressage maintenable suppose un minimum de gouvernance. Recommandation de projet : formalisez un mini-RACI (Responsable / Approbateur / Consulté / Informé) sur :

• Création d’un VLAN
• Création/modification d’un scope DHCP
• Création d’une réservation DHCP
• Création/modification d’un SSID
• Ouverture d’un flux inter-VLAN (règle firewall)
• Mise à jour DOE réseau (qui commite la version de référence)

Mini-RACI (exemple) : hôtel en exploitation

Exemple de projet : à ajuster selon votre organisation (DSI groupe, IT hôtel, prestataire d’infogérance, intégrateur courant faible).

Action	R (réalise)	A (approuve)	C/I (consulte / informe)
Créer un VLAN / sous-réseau	IT / intégrateur réseau	Responsable IT + exploitation	Sûreté (CCTV), GRMS/GTB (si impact)
Créer un scope DHCP	IT	Responsable IT	Exploitant (info)
Créer une réservation DHCP (caméra, NVR, contrôleur)	IT / intégrateur du lot concerné	IT	Exploitant + mainteneur (info)
Ouvrir un flux inter-VLAN	IT / sécurité	Responsable IT	Propriétaire applicatif (PMS/GRMS/CCTV) (C)
Mettre à jour DOE (tables + sauvegardes)	IT / intégrateur	Responsable IT	Exploitant (info) ; RSSI si existant (C)

Recommandation de projet : associez ce RACI à un process de changement simple (ticket, validation, exécution, test, sauvegarde de config, mise à jour DOE, versionnage). Pour cadrer les livrables, sauvegardes et “qui garde quoi”, la logique présentée dans Documentation réseau est directement applicable (version exploitation vs version restreinte, gestion des secrets hors DOE diffusé, etc.).

Exemples de segmentation (hôtel / immeuble / grande villa) – repères de conception

Les exemples ci-dessous sont des repères : ils ne remplacent pas l’étude de votre architecture réseau, ni les règles de filtrage associées.

Hôtel : segments typiques et points d’attention

• GUEST : invités, Internet uniquement, isolation entre clients selon projet
• STAFF : personnel, accès aux services métiers (à contrôler)
• VOICE : téléphonie IP (voir aussi téléphonie IP hôtel)
• VIDEO : caméras ↔ NVR/VMS (voir aussi vidéosurveillance IP)
• GRMS/TECH : contrôleurs chambre, passerelles, GTB (à isoler)
• MGMT : administration équipements (accès restreint)

À relier explicitement à votre design global : Cybersécurité d’un hôtel connecté (segmentation + contrôle des échanges + accès d’administration).

Immeuble : mutualisation et frontière parties communes / privatif

Dans un immeuble, le plan d’adressage doit souvent distinguer parties communes (CCTV, contrôle d’accès, interphonie, management) et éventuels services IP, avec une architecture conçue dès la conception (locaux techniques, baies, dorsales). Voir : Courant faible dans un immeuble.

Grande villa : simplicité d’usage, mais segmentation utile

Dans une grande villa, l’objectif est souvent une exploitation simple avec une segmentation utile : famille, invités, caméras, équipements techniques. Voir : Wi‑Fi dans une grande villa et VLAN : séparer domotique, caméras, invités….

Livrables DOE : ce qu’il faut remettre pour que le plan reste maintenable

Un plan d’adressage “sur le papier” ne suffit pas. Il doit vivre dans le DOE réseau. Recommandation de projet : remettre au minimum :

• Schéma logique : VLAN, sous-réseaux, passerelles, zones, services
• Schéma physique : baies, switches, uplinks, trunks, ports critiques
• Table VLAN (CSV)
• Table DHCP scopes (CSV)
• Table réservations DHCP (CSV)
• Table SSID ↔ VLAN (CSV)
• Sauvegardes de configuration (firewall, switches, contrôleur Wi‑Fi) avec procédure de restauration

Note sécurité (recommandation de projet) : évitez d’inclure des secrets (mots de passe, clés, certificats) dans un DOE largement diffusé. Prévoyez une remise séparée et contrôlée (coffre à secrets, annexe chiffrée, procédure nominative), en cohérence avec votre gouvernance IT.

Pour une structure DOE complète (schémas, tableaux de brassage, sauvegardes, gouvernance), voir : Documentation réseau : quels schémas et sauvegardes remettre au client ?.

Gabarits CSV prêts à l’emploi (exemples)

Les gabarits ci-dessous sont fournis comme modèles (à adapter à votre outillage : firewall, switch, DHCP Windows/ISC/Kea, contrôleur Wi‑Fi, etc.).

Gabarit 1 — Table VLAN (vlan.csv)

site;vlan_id;vlan_name;purpose;subnet_cidr;gateway_ip;dhcp_scope_name;notes
HOTEL-A;20;GUEST;WiFi invités;10.20.20.0/24;10.20.20.1;DHCP-HOTEL-A-GUEST;Internet uniquement (filtrage inter-VLAN)
HOTEL-A;30;STAFF;Personnel/back-office;10.20.30.0/24;10.20.30.1;DHCP-HOTEL-A-STAFF;Accès services métiers selon règles
HOTEL-A;50;VIDEO;Caméras vers NVR/VMS;10.20.50.0/24;10.20.50.1;DHCP-HOTEL-A-VIDEO;Réservations DHCP recommandées pour caméras

Gabarit 2 — Scopes DHCP (dhcp_scopes.csv)

site;scope_name;subnet_cidr;range_start;range_end;gateway_ip;dns_servers;ntp_servers;lease_policy;notes
HOTEL-A;DHCP-HOTEL-A-GUEST;10.20.20.0/24;10.20.20.50;10.20.20.250;10.20.20.1;X.X.X.X;X.X.X.X;Standard;Baux invités (pas de réservations)
HOTEL-A;DHCP-HOTEL-A-VIDEO;10.20.50.0/24;10.20.50.200;10.20.50.250;10.20.50.1;X.X.X.X;X.X.X.X;Court ou adapté au projet;Plage dynamique + réservations pour équipements stables

Gabarit 3 — Réservations DHCP (dhcp_reservations.csv)

site;scope_name;hostname;mac_address;reserved_ip;device_type;location;owner;change_ticket;notes
HOTEL-A;DHCP-HOTEL-A-VIDEO;CAM-ET2-COULOIR-01;AA:BB:CC:DD:EE:01;10.20.50.11;camera;Étage 2 - couloir;CCTV;CHG-XXXX;Réservation liée à l'étiquette terrain
HOTEL-A;DHCP-HOTEL-A-TECH;GRMS-GW-01;AA:BB:CC:DD:EE:10;10.20.60.10;gateway;Local technique;GRMS;CHG-XXXX;Adresse stable requise pour interfaces

Gabarit 4 — SSID ↔ VLAN (ssid_vlan_mapping.csv)

site;ssid_visible;wlan_profile_name;vlan_id;security_mode;auth_method;client_isolation;notes
HOTEL-A;HOTEL-GUEST;WLAN-GUEST-VLAN20;20;WPA2/WPA3 selon projet;Portail/PSK/802.1X selon projet;Oui selon politique;Tester casting/imprimantes si besoins
HOTEL-A;HOTEL-STAFF;WLAN-STAFF-VLAN30;30;WPA2/WPA3;802.1X ou PSK;Non;Accès services internes restreints

Points de contrôle en recette (pour éviter un plan “beau mais faux”)

• Concordance VLAN ↔ ports ↔ trunks (switching) : vérifier qu’un trunk transporte bien les VLAN attendus, et que les ports d’accès ne “fuient” pas
• DHCP : chaque VLAN reçoit bien une IP dans le bon scope, avec les bonnes options
• Réservations : remplacement d’un équipement (MAC change) → procédure de mise à jour testée
• SSID : mapping SSID ↔ VLAN cohérent, et règles firewall conformes (invités isolés des systèmes métiers/techniques)
• Accès d’administration : management isolé (réseau d’admin), comptes et procédures définis

Sur la segmentation elle-même et les règles de filtrage, référez-vous au guide : VLAN : pourquoi séparer…. Pour une vision “hôtel” (services IP + documentation), voir : Pré-ouverture d’un hôtel : checklist courant faible.

Conclusion : viser un plan simple, gouverné, et documenté

Un plan d’adressage IP maintenable n’est pas celui qui “optimise” chaque plage au plus juste : c’est celui qui reste lisible, évolutif et documenté, avec une gouvernance claire sur les changements. Dans un hôtel, c’est aussi une condition de la cybersécurité et de la continuité de service.

Si vous préparez une construction ou une rénovation (hôtel, immeuble, villa) et que vous souhaitez cadrer un DOE réseau exploitable (VLAN/SSID/DHCP/réservations + schémas + sauvegardes), l’équipe Domocasa peut vous aider à structurer les livrables et la recette, en cohérence avec l’architecture IP et les systèmes courant faible du bâtiment.