Documenter une infrastructure : schéma réseau, plan d'adressage, inventaire

Documenter une infrastructure, c'est décrire ce qui existe (réseaux, équipements, serveurs, services, flux) et comment l'exploiter, pour que n'importe quel membre de l'équipe puisse comprendre, dépanner et faire évoluer le système sans dépendre de celui qui l'a construit. Ce chapitre présente le dossier d'une infrastructure, puis ses pièces maîtresses sur l'exemple de Sorbier Logistique : le schéma réseau dessiné avec draw.io, le plan d'adressage et de nommage, l'inventaire, la fiche serveur et la place des secrets.

Le dossier d'une infrastructure

Chez Sorbier, ce dossier est un livre « Infrastructure » du wiki BookStack, dont les chapitres reprennent ce tableau. Le même découpage fonctionne dans un dépôt Git :

infrastructure/
├── 01-schemas/          siege-logique.drawio.svg, siege-physique.drawio.svg
├── 02-adressage/        plan-adressage.md, plan-nommage.md
├── 03-flux/             matrice-des-flux.md
├── 04-serveurs/         srv-ad.md, srv-wiki.md, pf1.md, pve1.md…
├── 05-procedures/       PROC-INFRA-012-deployer-vm-vlan21.md…
├── 06-sauvegarde-pra/   plan-de-sauvegarde.md, pra.md
└── 07-changements/      journal.md

Le schéma réseau : physique ou logique ?

Un schéma réseau répond à une question ; c'est pourquoi on en fait plusieurs.

• Le schéma logique répond à « quels réseaux existent, comment ils sont reliés, qui est où ? » : les VLAN avec leur adresse de réseau, les passerelles, les serveurs avec leur adresse, les liens entre zones. C'est celui qu'on consulte le plus.
• Le schéma physique répond à « où est branché quoi ? » : les baies, les équipements, les numéros de ports, les câbles, les prises murales. C'est celui du technicien qui doit débrancher le bon câble.
• D'autres vues s'ajoutent selon les besoins : les flux d'une application, le site distant et son tunnel, la virtualisation (quelles VM sur quel hôte).

Ce que fait ce schéma, et que tu dois faire sur les tiens :

1. Un cartouche : l'organisation, le périmètre (le siège, pas l'entrepôt de Mâcon), le type de vue, la version, la date, l'auteur. Un schéma sans date est un schéma dont on ne sait pas s'il est encore vrai.
2. Une légende pour chaque type de trait et d'icône.
3. Sur chaque zone : le numéro et le nom du VLAN, l'adresse du réseau, la passerelle.
4. Sur chaque équipement : son nom et son adresse, tels qu'ils figurent dans le plan d'adressage.
5. Un sens de lecture : Internet en haut, les postes et les serveurs en bas, sans croisements de traits.
6. Ce qui manque est dit : le cartouche signale que les VLAN 30 et 50 sont dans le plan d'adressage mais pas sur cette vue. Un schéma simplifié l'assume.

Dessiner un schéma avec draw.io

draw.io (aussi appelé diagrams.net) est un éditeur de diagrammes gratuit et libre (licence Apache 2.0), utilisable dans le navigateur sur app.diagrams.net, en application de bureau ou dans VS Code par une extension. BookStack l'intègre directement dans ses pages.

1. Ajoute les bonnes formes. En bas du panneau de gauche, Plus de formes (More Shapes) : coche les bibliothèques réseau (Network, Cisco…). Garde la même famille d'icônes dans tout le schéma.
2. Dessine les zones d'abord. Un rectangle par VLAN ou par site, avec son nom et son adresse dans le libellé ; les équipements viennent ensuite dans leur zone.
3. Relie avec des connecteurs, en style orthogonal (angles droits) : un connecteur reste attaché aux formes quand tu les déplaces. Étiquette les liens importants (« trunk 802.1Q », « IPsec vers Mâcon »).
4. Sépare les vues par calques (Affichage > Calques, ou Ctrl + Maj + L) : un calque pour les réseaux, un pour les flux, un pour les adresses de gestion. On affiche ce dont on a besoin.
5. Ajoute le cartouche et la légende dans un coin, toujours au même endroit.
6. Enregistre dans un format qui reste modifiable. Le fichier .drawio est du XML qui se versionne dans Git. Mieux : un export .drawio.svg ou .drawio.png (option Inclure une copie de mon diagramme, Include a copy of my diagram, à l'export) s'affiche comme une image dans un README ou un wiki et se rouvre dans draw.io pour être modifié. Fini le PNG dont plus personne n'a la source.

Pour un petit schéma de flux dans un README, Mermaid suffit et vit dans le texte (chapitre 4). Le cours UML compare les deux outils.

Le plan d'adressage

Le plan d'adressage est la référence des adresses : avant d'attribuer une adresse, on la cherche ici ; après, on l'y inscrit. Il a deux niveaux : une ligne par réseau, puis une ligne par adresse fixe. Le découpage lui-même (calcul des sous-réseaux, VLSM) est expliqué dans le cours Réseaux.

Les réseaux (extrait du plan du siège, tel que le pare-feu les porte) :

Les adresses du VLAN 21 (extrait) :

Les bonnes pratiques :

• Une seule source : un tableau du wiki pour un petit réseau, un outil de gestion des adresses (un IPAM, comme NetBox ou phpIPAM) quand le réseau grandit. Jamais deux listes.
• Un état pour chaque adresse : libre, réservée (attribution en cours), attribuée.
• Vérifier avant d'attribuer : l'adresse ne répond pas (ping), aucun nom DNS ne pointe vers elle, elle n'est dans aucune plage DHCP.
• Les plages DHCP et les adresses fixes séparées, notées dans le plan.

Le plan de nommage

Un bon nom dit ce qu'est l'équipement et évite les doublons. Sorbier applique ces règles :

La règle sur les numéros de VM est une astuce simple : en lisant qm list, on retrouve l'adresse, et inversement. Elle a une limite : avec plusieurs VLAN, deux machines peuvent avoir le même dernier octet (ct-horaires en 192.168.21.182, srv-collecte en 192.168.10.182) ; si les deux tournaient sur pve1, une seule pourrait porter le numéro 182, car un numéro ne sert qu'une fois sur l'hyperviseur. C'est pour cela que la règle dit « quand c'est possible » : le numéro reste une aide, et c'est le plan d'adressage qui fait foi. Certaines équipes mettent le VLAN en tête du numéro (21182 pour 192.168.21.182), au prix de numéros plus longs.

L'inventaire

L'inventaire recense le matériel, les logiciels, les licences, les contrats et les garanties ; il est tenu dans un outil de gestion de parc, le plus souvent GLPI, alimenté automatiquement par un agent installé sur chaque machine (inventaire avec GLPI Agent). La documentation ne le recopie pas : elle renvoie vers la fiche GLPI de chaque équipement. Les machines virtuelles y ont aussi leur fiche, avec leur hôte : c'est l'une des actions « après l'opération » de la procédure du chapitre 3.

La fiche serveur

La fiche serveur (ou fiche d'exploitation) rassemble sur une page tout ce qu'il faut savoir pour exploiter un serveur. Elle est la première page qu'ouvre le technicien d'astreinte. Voici celle de srv-wiki :

Fiche serveur : srv-wiki

Version 1.0 du 08/11/2026. Propriétaire : Moussa Diallo. Statut : en production.

Rubrique	Valeur
Rôle	Wiki interne de Sorbier (BookStack) : procédures du service informatique et guides des salariés
Hébergement	VM 190 sur pve1, 2 vCPU, 4 Gio de mémoire, disque de 30 Go sur truenas-nfs
Système	Debian 13
Réseau	VLAN 21 APPLIS, 192.168.21.190/24, passerelle 192.168.21.254 ; nom srv-wiki.ad.sorbier.example, alias wiki.ad.sorbier.example
Services	Nginx (HTTPS, port 443), PHP 8.4 et PHP-FPM, MariaDB 11.8 (locale), BookStack
Dépendances	srv-ad et srv-ad2 : DNS et authentification LDAPS des utilisateurs ; autorité de certification interne pour le certificat
Flux autorisés	HTTPS depuis les VLAN 10 et 99 ; SSH depuis le bastion uniquement (matrice des flux)
Sauvegarde	Sauvegarde nocturne de la VM par Proxmox ; export de la base chaque nuit vers le NAS ; restauration testée le 08/11/2026
Supervision	Zabbix agent 2, modèle Linux ; scénario web sur la page de connexion ; alerte d'expiration du certificat 30 jours avant
Accès d'administration	SSH avec clé depuis le bastion, compte sorbier-admin (clés de l'équipe déposées par cloud-init au déploiement, PROC-INFRA-012) ; compte administrateur de BookStack : coffre-fort de l'équipe, entrée srv-wiki
Procédures liées	PROC-INFRA-012 (déploiement), PROC-APP-003 (mise à jour de BookStack), PROC-APP-004 (restauration)
Historique	08/11/2026 : mise en production (M. Diallo)

Remarque la ligne Dépendances : quand l'authentification du wiki échoue, le technicien sait qu'il doit regarder aussi les contrôleurs de domaine. Et la ligne Accès dit où se trouve le mot de passe, sans le donner.

Les secrets ne vont pas dans la documentation

Mots de passe, clés privées, jetons, clés de licence, secrets partagés d'un VPN : aucun ne s'écrit dans un schéma, une fiche, une procédure ou un dépôt. La documentation donne le nom du compte et l'emplacement du secret dans le gestionnaire de mots de passe de l'équipe, dont l'accès est lui-même contrôlé et journalisé.

Attention aussi aux exports de configuration (la sauvegarde XML de pfSense, la configuration d'un switch) : ils contiennent des empreintes de mots de passe et des clés. Ils font partie de la documentation au sens large, mais se rangent dans un espace aux droits restreints, jamais dans un wiki ouvert à tous ou un dépôt public (sauvegarder pfSense).

Tenir la documentation à jour

Une documentation d'infrastructure vieillit à chaque changement. Les équipes qui la gardent juste appliquent trois règles :

• Aucun changement n'est clos sans mise à jour des documents qu'il touche : le ticket de changement contient une case « documentation mise à jour », vérifiée à la clôture (la gestion des changements).
• Un journal des changements daté, une ligne par modification, avec le lien vers le ticket.
• Une relecture périodique : une fois par an, on compare le schéma à la réalité (configurations, inventaire) et on corrige les écarts.

Exercices