On commence souvent un réseau un peu « à l’arrache ». Un /24 par ici, un autre /24 par là. Ça marche. Puis un jour, on ajoute un nouveau bâtiment, une salle info, un VLAN voix, un Wi-Fi invités, un bout de DMZ… et là, tout devient fragile.
Le vrai problème n’est pas IPv4 en soi. C’est l’absence de plan. Un plan d’adressage, c’est ce qui évite les renumérotations douloureuses, les routes statiques bricolées, les ACL impossibles à maintenir, et les conflits d’IP qui apparaissent au pire moment.
Dans cet article, on va construire un plan d’adressage IPv4 qui tient la route, qui reste lisible, et surtout qui peut grandir. Le genre de truc que tu peux poser dans un dossier E4 ou E5, puis réutiliser en stage, puis en alternance, sans avoir honte dans six mois.
Pourquoi la croissance casse les plans « simples »
Au départ, tu as peut-être :
- 192.168.1.0/24 pour « le LAN »
- 192.168.2.0/24 pour « les serveurs »
- 192.168.3.0/24 pour « le Wi-Fi »
Et tu te dis que c’est propre.
Mais quand tu ajoutes :
- un VLAN imprimantes (parce que sécurité)
- un VLAN admin (parce que sécurité, encore)
- un VLAN caméras (parce que IoT…)
- un réseau de management (switch, iDRAC, iLO)
- un site distant à relier en VPN
- un PRA, un lab, un réseau de test
- une DMZ, voire plusieurs
Tu réalises que « un /24 par usage » ne te donne pas une structure. Tu ne peux pas agréger (summarize) facilement, tu ne peux pas réserver de place pour l’avenir, et tu ne peux pas déduire une zone juste en lisant une IP.
Un plan qui survit à la croissance, c’est un plan qui :
- réserve de l’espace (vraiment)
- organise par zones (utilisateurs, serveurs, management, DMZ, invités)
- permet l’agrégation (important pour le routage)
- standardise les tailles de sous-réseaux
- documente tout, sinon ça ne sert à rien
Les bases qu’on va utiliser (sans partir en thèse)
On va bosser avec :
- une plage privée RFC1918, souvent 10.0.0.0/8 ou 172.16.0.0/12
- du VLSM (Variable Length Subnet Mask) pour adapter la taille au besoin
- une logique « hiérarchique » pour pouvoir résumer des routes
Petit rappel rapide des tailles utiles (ordre d’idée) :
- /24 : 254 hôtes
- /25 : 126 hôtes
- /26 : 62 hôtes
- /27 : 30 hôtes
- /28 : 14 hôtes
Et oui, on va essayer de ne pas coller des /24 partout « parce que c’est simple ». Simple maintenant, pénible après.
Étape 1 : choisir une plage privée « large », mais pas n’importe comment
Pour un réseau qui grandit, 10.0.0.0/8 est tentant. Immense. Mais en entreprise, tu dois penser aux interconnexions VPN avec d’autres organisations. 10.0.0.0/8 est souvent déjà utilisé ailleurs. 192.168.0.0/16 aussi. 172.16.0.0/12 est parfois un bon compromis.
Exemple réaliste pour un établissement, une PME, ou une infra de formation type BTS :
- 172.20.0.0/16 comme « super bloc » interne
Pourquoi /16 ? Parce que tu peux découper par sites ou par grandes zones, et garder de la place.
Tu peux aussi faire :
- Site A : 172.20.0.0/20
- Site B : 172.20.16.0/20
- Site C : 172.20.32.0/20
Et hop, déjà tu as une hiérarchie.
Étape 2 : découper par zones (la partie qui change tout)
Avant même de parler VLAN, parle « zones fonctionnelles ». Un plan d’adressage, c’est aussi un plan de sécurité et d’exploitation.
Voici une proposition simple, qui marche souvent :
- utilisateurs
- serveurs
- wifi invités
- voix
- iot (caméras, badgeuses, TV, etc.)
- management (switch, hyperviseurs, iDRAC, iLO, contrôleurs Wi-Fi)
- dmz
- transit (liens routeurs, point à point)
On va réserver des blocs par zone. Même si tu ne les utilises pas tout de suite. Oui, ça fait « vide ». C’est le but.
Exemple sur 172.20.0.0/16 :
- Utilisateurs : 172.20.0.0/18
- Serveurs : 172.20.64.0/19
- Management : 172.20.96.0/20
- Voix : 172.20.112.0/20
- IoT : 172.20.128.0/19
- DMZ : 172.20.160.0/20
- Invités : 172.20.176.0/20
- Transit : 172.20.240.0/20
- Réserve : 172.20.192.0/18 (pour le futur, ou un nouveau site)
Tu vois l’idée. Chaque zone est un bloc qu’on peut résumer dans le routage.
Étape 3 : à l’intérieur d’une zone, standardiser avec une logique lisible
Dans « utilisateurs », tu vas probablement faire des VLAN par étage, bâtiment, service, ou salle.
Imaginons un campus ou un bâtiment :
- Bâtiment A : 172.20.0.0/20
- Bâtiment B : 172.20.16.0/20
- Bâtiment C : 172.20.32.0/20
Puis à l’intérieur du bâtiment A, tu fais des /24 ou /23 selon la densité.
Mais attention. Le piège, c’est de refaire du « /24 par VLAN » sans réfléchir. Si tu as 40 postes dans une zone, un /26 suffit. Et ça te laisse plus de VLAN possibles.
Exemple bâtiment A (172.20.0.0/20) :
- VLAN 10 admin : 172.20.0.0/26
- VLAN 20 profs : 172.20.0.64/26
- VLAN 30 élèves : 172.20.0.128/25
- VLAN 40 salle info 1 : 172.20.1.0/26
- VLAN 50 salle info 2 : 172.20.1.64/26
- VLAN 60 imprimantes : 172.20.1.128/27
- VLAN 70 wifi corp : 172.20.1.160/26
Et tu continues.
Astuce importante : garde une convention.
- la passerelle est toujours .1 (ou .254, mais choisis)
- DHCP commence à .50
- IP fixes serveurs ou imprimantes dans un range dédié
Exemple standard :
- .1 : gateway
- .2 à .49 : réservations, équipements
- .50 à .200 : pool DHCP
- .201 à .254 : réserve
C’est simple, et quand tu dépannes, tu bénis ton toi du passé.
Étape 4 : prévoir l’agrégation de routes (même si tu n’as pas BGP)
Même en OSPF, même en statique, l’agrégation est ton amie.
Si « utilisateurs » = 172.20.0.0/18, alors ton cœur de réseau peut annoncer un seul préfixe vers le firewall, au lieu de 40 VLAN.
Et si tu as plusieurs sites :
- Site A utilisateurs : 172.20.0.0/19
- Site B utilisateurs : 172.20.32.0/19
Tu peux résumer par site, puis par zone. Ça devient propre.
Ce que ça change au quotidien :
- règles firewall plus simples
- tables de routage plus petites
- moins d’erreurs humaines
- dépannage plus rapide
Et franchement, en contexte BTS SIO SISR, c’est typiquement le détail qui montre que tu sais concevoir, pas juste configurer.
Étape 5 : un exemple complet (que tu peux adapter)
On part sur 172.20.0.0/16.
Découpage par zones
- Utilisateurs : 172.20.0.0/18
- Serveurs : 172.20.64.0/19
- Management : 172.2096.0/20
- Voix : 172.20.112.0/20
- IoT : 172.20.128.0/19
- DMZ : 172.20.160.0/20
- Invités : 172.20.176.0/20
- Transit : 172.20.240.0/20
Serveurs (172.20.64.0/19)
Tu peux séparer par rôles :
- VLAN 200 serveurs Windows : 172.20.64.0/24
- VLAN 210 serveurs Linux : 172.2065.0/24
- VLAN 220 stockage iSCSI ou NFS : 172.20.66.0/24 (ou /25 si petit)
- VLAN 230 sauvegarde : 172206700./24
- VLAN 240 virtualisation vMotion ou live migration : 17222068./24
Même si tu n’as pas tout, tu réserves.
En parlant de gestion des ressources réseau, il est intéressant de noter que des concepts avancés comme le network slicing utilisés dans les réseaux 5G peuvent également être appliqués pour optimiser la distribution des ressources dans un environnement réseau complexe tel que celui décrit ci-dessus.
Management (172.20.96.0/20)
- VLAN 300 management réseau : 172.20.96.0/24
- VLAN 310 management serveurs (iLO, iDRAC) : 172.20.97.0/24
- VLAN 320 management Wi-Fi : 172.20.98.0/24
Ici, tu fais souvent beaucoup de statique. Donc garde un plan d’IP clair.
DMZ (172.20.160.0/20)
- VLAN 400 reverse proxy : 172.20.160.0/26
- VLAN 410 web public : 172.20.160.64/26
- VLAN 420 bastion d’admin : 172.20.160.128/27
La DMZ est souvent petite. Inutile de gaspiller.
Transit (172.20.240.0/20)
Pour les liens point à point, beaucoup utilisent des /30. Mais aujourd’hui, on préfère souvent /31 sur du routeur à routeur (RFC3021), si supporté. Sinon /30.
Exemples :
- Lien core vers firewall : 172.20.240.0/31
- Lien core vers routeur WAN : 172.20.240.2/31
- Lien core vers core2 : 172.20.240.4/31
C’est petit, clair, et ça évite de cramer des /24 pour des liens.
Les pièges classiques (et comment les éviter)
Mélanger prod et lab
Même si c’est tentant, il est crucial de séparer ces environnements pour éviter toute confusion ou erreur potentielle dans le réseau IP utilisé[https://fr.wikipedia.org/wiki/Sous-r%C3%A9seau]. Réserve un bloc « lab » et ne le réutilise pas.
Oublier les VPN et les collisions d’IP
Si tu fais du VPN site à site, ou du client VPN avec split tunneling, les collisions avec 192.168.1.0/24 sont un enfer à gérer.D’où l’intérêt d’un bloc IP comme 172.20.x.x qui est un peu moins « commun ».
Ne pas documenter
Un plan non documenté, c’est juste des chiffres.
Fais au minimum :
- un tableau VLAN, réseau, passerelle, DHCP, usage
- une carte simple des zones
- une convention écrite (gateway, ranges, DNS, etc.)
Sur BTS SIO2 SISR Tech Lab ( https://sio1blog.blogspot.com/ ), on publie souvent des labs et des fiches méthodo dans cet esprit. Si tu veux, tu peux t’en servir comme base de documentation pour tes comptes rendus, puis itérer dessus au fil de tes projets.
Mini modèle de tableau (à copier dans ton doc)
| VLAN | Nom | Réseau | Passerelle | DHCP | Notes |
| 10 | admin | 172.20.0.0/26 | 172.20.0.1 | non | postes IT |
| 30 | élèves | 172.20.0.128/25 | 172.20.0.129 | oui | pool .150 à .250 |
| 200 | srv-win | 172.20.64.0/24 | 172.20.64.1 | non | AD, DNS, DHCP |
| 300 | mgmt-net | 172.20.96.0/24 | 172.20.96.1 | non | switch, AP, etc. |
| 500 | invités | 172.20.176.0/23 | 172.20.176.1 | oui | NAT, isolation |
Tu peux ajouter : DNS, NTP, domaine, relais DHCP, scope.
Et IPv6 dans tout ça
Oui, IPv6 est le futur. Mais dans la vraie vie, beaucoup de réseaux sont encore IPv4 first, surtout en PME, en éducation, et dans les environnements mixtes.
Le bon move, c’est :
- plan IPv4 solide maintenant
- activer IPv6 progressivement, proprement
- éviter le « dual stack accidentel »
Mais ça, on pourra en faire un autre article, plus orienté lab.
Conclusion : un plan d’adressage, c’est un investissement, pas une corvée
Le plan d’adressage IPv4 qui survit à la croissance, c’est celui qui accepte l’idée suivante : tu ne sais pas exactement ce que le réseau va devenir. Donc tu structures, tu réserves, tu standardises, tu documentes.
Si tu devais retenir trois choses :
- Pars sur un bloc assez large (et pas trop commun si VPN).
- Découpe par zones, puis par sites, puis par VLAN.
- Garde une convention d’IP et documente tout.
Si tu veux d’autres contenus dans le même style, orientés pratique, avec des schémas, des tableaux, et des labs reproductibles, passe sur BTS SIO2 SISR Tech Lab ( https://sio1blog.blogspot.com/ ) et fouille les catégories réseau, sécurité, virtualisation. Ça sert à ça.
Questions fréquemment posées
Pourquoi un plan d'adressage IPv4 est-il essentiel pour un réseau qui grandit ?
Un plan d'adressage IPv4 évite les renumérotations douloureuses, les routes statiques bricolées, les ACL difficiles à maintenir et les conflits d'IP. Il assure une organisation claire, facilite la croissance du réseau et permet une gestion efficace des différentes zones comme les VLANs, la DMZ ou le Wi-Fi invités.
Quels sont les problèmes courants avec un plan d'adressage « simple » basé sur un /24 par usage ?
Un plan basé uniquement sur un /24 par usage ne permet pas une agrégation facile des routes, ne réserve pas de place pour l'avenir, et rend difficile la déduction de la zone fonctionnelle simplement en lisant une adresse IP. Cela peut entraîner une structure fragile et difficile à gérer lors de l'ajout de nouveaux services.
Quelles sont les bonnes pratiques pour construire un plan d'adressage IPv4 robuste ?
Il faut réserver suffisamment d'espace d'adressage, organiser le réseau en zones fonctionnelles (utilisateurs, serveurs, management, DMZ, invités), utiliser l'agrégation pour simplifier le routage, standardiser les tailles des sous-réseaux via VLSM et surtout documenter soigneusement tout le plan.
Quelle plage d'adresses privées choisir pour un réseau d'entreprise en croissance ?
La plage 172.16.0.0/12 est souvent un bon compromis car elle offre suffisamment d'espace tout en étant moins utilisée que 10.0.0.0/8 ou 192.168.0.0/16 dans les interconnexions VPN avec d'autres organisations. Par exemple, utiliser 172.20.0.0/16 comme super bloc interne permet de découper facilement par sites ou zones.
Comment découper efficacement un plan d'adressage par zones fonctionnelles ?
Avant même de définir des VLANs, il faut penser aux zones fonctionnelles telles que utilisateurs, serveurs, Wi-Fi invités, voix, IoT (caméras, badgeuses), management (switchs, hyperviseurs) etc. Chaque zone se voit attribuer une plage dédiée facilitant la sécurité et l'exploitation du réseau.
Pourquoi éviter de coller systématiquement des /24 partout dans un plan d'adressage ?
Utiliser systématiquement des /24 est simple à court terme mais pénible à long terme car cela gaspille de l'espace IP et complique la gestion lorsque le réseau évolue. Il est préférable d'utiliser des masques variables (VLSM) adaptés aux besoins réels pour optimiser l'utilisation des adresses et faciliter la croissance future.
0 Commentaires