Illustration générée par IA — visuel conceptuel.
Pourquoi un plan d’adressage « orienté exploitation » change tout
Dans un hôtel, un immeuble ou une grande villa, le réseau IP n’est pas un simple LAN bureautique. Il porte souvent plusieurs services à cycles de vie différents : Wi‑Fi invités, Wi‑Fi staff, vidéosurveillance, téléphonie, TV/IPTV, contrôle d’accès, interphonie, GTB/GRMS, passerelles domotiques, supervision, etc. Quand le plan d’adressage et la nomenclature sont improvisés, l’exploitation le paie au quotidien : dépannage plus long, modifications risquées, extensions difficiles, responsabilités floues.
Ce guide propose une méthode simple, maintenable, et surtout documentable (DOE + exploitation). Elle ne remplace pas l’ingénierie réseau (firewalling, QoS, Wi‑Fi, redondance…), mais elle pose une base structurante. Pour la segmentation par VLAN et le rôle des règles inter‑VLAN, vous pouvez aussi lire : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?
Étape 1 — Définir le découpage « par usages » avant de créer des VLAN
Avant de décider « VLAN 10 / VLAN 20… », clarifiez les familles d’équipements et leurs besoins de communication. L’objectif n’est pas de multiplier les segments, mais de créer des frontières utiles pour :
- réduire les échanges inutiles (donc le bruit et les risques),
- simplifier le diagnostic (qui parle à qui ?),
- faciliter l’évolution (ajouter un lot sans casser le reste).
Exemples de domaines fonctionnels (à adapter)
- MGMT : management des équipements réseau (switches, AP, contrôleur Wi‑Fi, firewall, supervision).
- STAFF / IT : postes et services internes (réception, back‑office, imprimantes, applicatifs…).
- GUEST : invités (Internet, isolation inter‑clients selon stratégie).
- CCTV : caméras et NVR/VMS.
- IPTV / AV : TV, set‑top box, middleware, éventuel AV-over-IP.
- VOICE : téléphonie IP si périmètre séparé.
- OT / BÂTIMENT : GTB/GRMS/contrôleurs/passerelles techniques.
- ACCESS : contrôle d’accès, interphonie IP, serrures online, etc.
En hôtellerie, cette logique s’inscrit naturellement dans une architecture IP convergée (Wi‑Fi, IPTV, VoIP, CCTV, GRMS…). Pour aller plus loin sur la coexistence des services, voir : Architecture réseau IP d’un hôtel.
Étape 2 — Créer une nomenclature cohérente (VLAN, SSID, équipements, ports)
Une nomenclature n’est pas un « bonus documentation » : c’est ce qui permet à un technicien, un intégrateur ou une DSI de comprendre le réseau sans reconstruire l’historique.
Choisir un code site stable
Définissez un code court et unique pour le site : hôtel, immeuble, résidence, villa. Exemples (illustratifs) : HTL-AZR, RES-ANF, VIL-001. Sur un multi‑bâtiments, ajoutez des repères simples (B1, B2…), et sur un site à plusieurs baies, identifiez les locaux (R1, R2…).
Nommage VLAN : lisible « terrain »
Recommandation pratique : inclure dans le nom VLAN ce que vous voulez comprendre en intervention : site, zone/étage (si utile), fonction. Exemple de format (à adapter) :
<SITE>-<ZONE>-<FONCTION>-V<ID>
HTL-AZR-CORE-MGMT-V10HTL-AZR-GUEST-WIFI-V30HTL-AZR-CCTV-CAM-V40
Le point important n’est pas le format exact, mais l’uniformité (mêmes conventions sur firewall, switches, contrôleur Wi‑Fi, supervision, DOE).
Nommage SSID : distinguer le visible et l’exploitable
Un SSID est « marketing et expérience client » (hôtel) ou « usage et simplicité » (entreprise/villa). En parallèle, gardez un nom interne/profil orienté exploitation. Exemple :
- SSID affiché :
Hotel-Azur→ profil interne :HTL-AZR-GUEST - SSID affiché :
Hotel-Azur-Staff→ profil interne :HTL-AZR-STAFF
Étape 3 — Construire un plan d’adressage IP « bloc site » (puis découpe par VLAN)
Pour l’adressage interne IPv4, les plages privées reconnues sont celles décrites par la RFC 1918 : 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Le point clé en projet bâtiment : réserver un bloc par site pour limiter les collisions futures (VPN, interconnexion multi‑sites, supervision centralisée, prestataires multiples).
Règle simple (recommandation) pour rester lisible
Dans de nombreux projets, une stratégie simple et robuste consiste à garder un sous‑réseau par VLAN (souvent en /24 pour commencer), puis à élargir uniquement les segments qui en ont besoin (invités, IPTV…). L’objectif n’est pas d’optimiser chaque adresse, mais de rester maintenable.
Définir des conventions à l’intérieur de chaque sous-réseau
Décidez dès le départ d’une convention de plages, et appliquez-la partout. Exemple (illustratif) :
.1: passerelle (SVI / interface firewall).2–.49: infrastructure (core, contrôleurs, serveurs internes, supervision…).50–.199: pool DHCP dynamique.200–.254: réservations DHCP (terminaux techniques « semi‑fixes »)
Cette convention est une règle de projet : elle doit être notée dans le DOE et comprise par l’exploitation.
Étape 4 — Cadrer DHCP et les réservations (pour éviter les pannes « bizarres »)
DHCP (Dynamic Host Configuration Protocol) est spécifié par l’IETF et repose sur la distribution dynamique d’adresses et de paramètres réseau sous forme de baux (leases). Dans un bâtiment, DHCP est rarement un « détail IT » : une panne DHCP/DNS peut se traduire par une indisponibilité massive (Wi‑Fi, TV, VoIP, systèmes techniques), d’où l’intérêt d’une gouvernance claire.
Options DHCP minimales à standardiser
Sans entrer dans les options spécifiques à chaque métier, deux paramètres sont fondamentaux sur la plupart des VLAN :
- Passerelle (option DHCP « Router ») : indique au client où envoyer son trafic hors sous-réseau.
- DNS (option DHCP « Domain Name Server ») : conditionne la résolution de noms (et donc une grande partie des usages).
Ensuite seulement viennent les options « confort » (NTP, domaine, etc.), à définir si elles apportent une valeur opérationnelle réelle.
Réservations DHCP vs IP fixes : choisir une règle et la tenir
Dans beaucoup de projets « bâtiment », on cherche une IP stable pour des équipements terrain (AP, caméras, TV, passerelles, automates IP…), sans pour autant configurer une IP fixe sur chaque appareil (surtout quand plusieurs lots interviennent). Les réservations DHCP sont une approche pragmatique, à condition d’être gouvernées et documentées.
Exigence d’exploitation (recommandation de projet) : toute réservation doit exister dans un registre « réservations » (voir templates plus bas), avec MAC, IP, VLAN, rôle, emplacement et responsable.
Protéger la distribution DHCP sur le LAN (si votre matériel le permet)
Sur le réseau filaire, des mécanismes comme le DHCP snooping (selon plateformes) peuvent aider à limiter les effets d’un serveur DHCP « pirate » branché par erreur ou d’un équipement mal configuré. Le sujet est à cadrer au cas par cas (plateforme réseau, architecture, responsabilité IT).
Étape 5 — Documenter pour que le réseau soit maintenable (DOE réseau exploitable)
Un plan IP sans DOE n’est pas une méthode, c’est une hypothèse. Le DOE doit permettre de passer d’un incident (« la caméra du parking ne remonte plus ») à une action (« port switch X, VLAN Y, réservation Z ») sans dépendre de la mémoire de l’installateur.
Pour une structure de dossier complète (schémas, inventaires, sauvegardes, tables de brassage, recettes…), voir : Documentation réseau : quels schémas et sauvegardes remettre au client ?
Le trio minimal à exiger
- Schéma physique : baies, switches, uplinks, brassage, repérage réel.
- Schéma logique : VLAN, sous‑réseaux, passerelles, zones firewall (et principes).
- Tableaux exploitables : VLAN/IP, SSID↔VLAN, scopes DHCP, réservations, plan de ports, table de brassage.
Étape 6 — Préparer l’exploitation (jour‑2) pour réduire le SAV
La stabilité d’un réseau ne dépend pas uniquement de la conception initiale. Elle dépend aussi de la discipline d’exploitation : qui change quoi, comment, et avec quelles preuves.
Gouvernance simple (recommandation)
- Une source de vérité : registre VLAN/IP + réservations + plan de ports.
- Gestion de changement : création/modification VLAN, scope DHCP, SSID = date + responsable + justification.
- Sauvegardes de configuration : firewall/switch/Wi‑Fi, avec procédure de restauration testée (pas seulement des exports).
- Supervision : au minimum sur uplinks, erreurs de ports, saturation, équipements critiques (contrôleur Wi‑Fi, DHCP/DNS selon périmètre).
En hôtel, cette démarche s’articule bien avec une vision « services » (Wi‑Fi invités, TV, téléphonie, CCTV, GRMS…). Elle est détaillée dans notre approche d’architecture convergée : Architecture réseau IP d’un hôtel.
Cas villa : ne pas sous-estimer le réseau « infrastructure »
Dans une grande villa, la maintenabilité dépend fortement de la baie, des points d’accès, du PoE, du repérage et de la segmentation (invités, caméras, équipements techniques). Pour replacer le plan IP dans cette réalité, voir : Wi‑Fi dans une grande villa : pourquoi un simple routeur ne suffit pas.
Exemples de segmentation (hôtel / immeuble / villa)
Les exemples ci-dessous sont volontairement simples. L’important est la logique (et sa documentation), pas le nombre de VLAN.
Exemple hôtel (réseau convergé)
- MGMT (management équipements)
- STAFF (réception / back‑office)
- GUEST (Wi‑Fi invités)
- CCTV (caméras, NVR/VMS)
- IPTV/TV (TV, STB, plateformes)
- OT (GRMS/GTB/contrôleurs techniques)
À ce stade, votre livrable clé n’est pas « la liste des VLAN », mais la liste des flux autorisés (qui a le droit d’atteindre quoi) et les dépendances (DHCP/DNS, contrôleur Wi‑Fi, portails, etc.).
Exemple immeuble (parties communes + éventuellement multi-occupants)
- VLAN parties communes (CCTV, interphonie, accès, GTB) avec plan IP propre.
- Si multi‑occupants : séparation par occupant (selon architecture et gouvernance), sans confondre réseaux locataires et réseaux techniques.
Exemple villa (peu de VLAN, mais très structurants)
- MGMT
- LAN « famille / résidents »
- GUEST
- CCTV
- IoT / systèmes techniques (selon périmètre)
Templates DOE (prêts à adapter)
Les tableaux ci-dessous sont des structures de DOE. Adaptez-les à votre outil (XLSX/CSV) et à votre périmètre contractuel.
Template 1 — Registre VLAN / sous‑réseaux
| Site | VLAN ID | Nom VLAN | Usage | Zone/VRF | Sous-réseau | Passerelle | DHCP | Pool dynamique | Plage réservations | Notes firewall |
|---|---|---|---|---|---|---|---|---|---|---|
| HTL-AZR | 10 | HTL-AZR-CORE-MGMT-V10 | Management | MGMT | 10.42.10.0/24 | 10.42.10.1 | Oui | .50-.199 | .200-.254 | Accès restreint |
Template 2 — Matrice SSID → VLAN → sécurité
| Site | SSID affiché | Nom interne | VLAN | Authentification | Isolation inter-clients | Portail captif | Remarques |
|---|---|---|---|---|---|---|---|
| HTL-AZR | Hotel-Azur | HTL-AZR-GUEST | 30 | Selon stratégie | Oui/Non | Oui/Non | Limiter accès LAN |
Template 3 — Scopes DHCP (par VLAN)
| VLAN | Sous-réseau | Serveur DHCP | Pool | Durée bail | Options minimales | Exclusions | Commentaires |
|---|---|---|---|---|---|---|---|
| 30 | 10.42.30.0/24 | FW-Core | .50-.199 | À définir | GW + DNS | .1-.49, .200-.254 | Invités |
Template 4 — Table des réservations DHCP (clé SAV)
| Hostname | Rôle | VLAN | IP | MAC | Switch/Port | Emplacement | Lot | Date | Commentaire |
|---|---|---|---|---|---|---|---|---|---|
| SW-R1-01 | Switch accès | 10 | 10.42.10.11 | xx:xx:xx:xx:xx:xx | CORE/Trk1 | Baie R1 | Réseau | AAAA-MM-JJ | Réservation DHCP |
Template 5 — Plan de ports (minimum exploitable)
| Équipement | Interface | Mode | VLAN untagged | VLAN tagged | Description | Câble | Destination |
|---|---|---|---|---|---|---|---|
| SW-R1-01 | Gi1/0/24 | Trunk | 10 | 20,30,40,50 | Uplink vers cœur | C-024 | CORE-SW-01 |
Pour aller plus loin (liens utiles)
- VLAN : séparer domotique, caméras, invités…
- Documentation réseau (DOE) : schémas, sauvegardes, tables
- Architecture réseau IP d’un hôtel (convergence des services)
- Wi‑Fi dans une grande villa (infrastructure et exploitation)
Besoin d’un cadrage projet ? Si vous préparez un hôtel, un immeuble ou une villa haut de gamme, l’étape la plus rentable est souvent de figer dès l’étude : (1) la segmentation par usages, (2) le plan d’adressage, (3) la gouvernance DHCP/réservations, (4) le DOE exploitable et la procédure d’exploitation (jour‑2).
