Documentation réseau : quels schémas et sauvegardes remettre au client ?

Un réseau peut parfaitement fonctionner le jour de sa livraison et devenir difficile à maintenir six mois plus tard si personne ne sait quel câble dessert une caméra, quelle configuration contient les VLAN (réseaux locaux virtuels) ou comment restaurer un switch (commutateur). Le DOE réseau informatique (dossier des ouvrages exécutés, aussi appelé dossier de récolement) doit permettre au propriétaire et à un futur mainteneur de comprendre, diagnostiquer et faire évoluer l’installation sans dépendre de la mémoire de l’équipe de chantier.

Pour rester exploitable, ce dossier doit être aligné sur le périmètre contractuel (marché privé ou public) : pièces techniques (ex. CCTP) et pièces administratives (ex. CCAP) lorsqu’elles existent, ou tout document contractuel équivalent (CPS/DCE, cahier des charges, annexes techniques, etc.). Au Maroc, selon le type de marché et les pièces applicables, on rencontre dans certains dossiers une organisation en réception provisoire puis réception définitive ; dans ce cas, il est utile de définir dès l’appel d’offres quels livrables sont attendus, à quel moment (remise initiale, puis mise à jour après levée de réserves), dans quels formats et avec quelles règles de confidentialité (version exploitation vs version restreinte). Sources (exemples de pièces de marchés, sans valeur de règle générale pour tous projets/secteurs) : OFPPT — DCE (PDF) ; APDN — CPS/RC (PDF).

  • Synthèse décideur — pack minimal à remettre (à adapter au parc réellement posé et aux règles du client) :
    • Schémas : physique + logique, en PDF et en format éditable.
    • Table de brassage (ports/prises) : fichier éditable (CSV/XLSX) + PDF.
    • Inventaire matériel : modèle, emplacement, rôle, numéros de série (si requis), versions, garanties/maintenance si inclus.
    • Sauvegardes de configuration : exports nommés, horodatés, avec version logicielle/firmware et procédure de restauration.
    • Recette : résultats des tests (cuivre/fibre/Wi‑Fi) et PV/compte-rendu de recette lorsque prévu au contrat.
    • Gouvernance : qui administre quoi, où est la « version de référence », et comment on trace les changements.
    • Secrets (mots de passe, clés, certificats) : hors DOE diffusé, remis via un coffre ou une annexe à accès contrôlé.

Photo by Scott Rodgerson on Unsplash

Séparer plan physique et architecture logique

Le schéma physique présente bâtiments, locaux techniques, baies, switches, câbles et uplinks, avec les identifiants réellement posés. L’architecture logique expose VLAN, sous-réseaux, passerelles, routes, pare-feu et principaux services. Les deux se complètent sans se confondre.

Un plan indiquant uniquement « switch étage 2 » ne permet pas de retrouver rapidement la caméra ou le téléphone qui a perdu sa liaison. L’objectif est de passer de la plainte d’un utilisateur au port, au câble et à l’équipement concerné.

Fournir un tableau de brassage exploitable : exemple de traçabilité

Chaque liaison doit être repérée aux deux extrémités. La nomenclature peut associer bâtiment, niveau, local, panneau et numéro de port. Un tableau de brassage indique origine, destination, type de câble, prise, VLAN affecté si pertinent et observations.

Lorsque l’exploitation ajoute un équipement, cette table doit être mise à jour. Les photos de baies sont utiles en complément, mais ne remplacent ni les étiquettes physiques ni les fichiers éditables. Notre guide sur le courant faible d’un immeuble propose un éclairage méthodologique sur l’intérêt de préparer ces repérages dès les travaux (renvoi éditorial).

Documenter les configurations et versions

Le client doit recevoir les sauvegardes exportables des switches, routeurs, pare-feu, contrôleurs Wi‑Fi et équipements de supervision concernés, selon les droits contractuels, les licences éditeur et les règles internes (DSI/RSSI) du client. Indiquez date d’export, version du firmware/OS, nom de l’équipement, rôle (accès/distribution/cœur, WAN, sécurité) et procédure de restauration associée.

Il est important de vérifier qu’un fichier peut réellement être relu ou restauré avec le matériel et la version attendus. Un dossier plein de fichiers « config-final.txt » sans identification précise a une valeur limitée. Les licences et accès de support doivent également être documentés (si ces éléments font partie du périmètre livré).

En pratique, les constructeurs proposent des exports sous différents formats (texte, archive, base de données, sauvegarde binaire, export projet). Le DOE doit préciser pour chaque équipement le format remis et, si applicable, l’outil ou l’interface nécessaire (ex. console/CLI, interface Web, contrôleur/manager). Ces modalités dépendent du modèle et de la version : elles doivent être confirmées sur l’environnement livré.

Formats, dépôt et méthode de remise (concret)

Pour éviter une remise « difficile à réutiliser », il est utile d’acter dans le projet :

  • Formats attendus :
    • PDF pour consultation + sources éditables pour mise à jour (par exemple fichiers de diagrammes, tableurs/CSV, exports natifs des équipements).
    • CSV/XLSX pour inventaires et tables de brassage (faciles à filtrer et à enrichir).
    • Exports natifs des constructeurs (contrôleur Wi‑Fi, pare-feu, supervision) lorsqu’ils sont nécessaires pour une restauration.
  • Dépôt de référence : un emplacement unique « officiel » côté client (dépôt documentaire, GED, dépôt IT) plutôt qu’un échange par e‑mail.
  • Arborescence simple (illustrative, à adapter) :
    • 00_Lisez-moi/ (périmètre, contacts, règles de confidentialité)
    • 01_Schemas/ (physique, logique, flux)
    • 02_Brassage/ (ports/prises, photos de baies si utilisées)
    • 03_Inventaire/ (matériels, modules optiques, alimentations)
    • 04_Configs/ (par site/baie/équipement)
    • 05_Recette/ (tests cuivre/fibre/Wi‑Fi, PV)
    • 06_Exploitation/ (procédures, changelog, escalade)
    • 99_Annexes_restraintes/ (si le client l’autorise, zone à accès contrôlé)
  • Nommage des fichiers : une convention stable (ex. SITE-BAIE-EQUIPEMENT_YYYY-MM-DD_version.ext) pour identifier la dernière version sans ambiguïté.

Protéger les identifiants et les secrets

La documentation ne doit pas devenir un répertoire de mots de passe en clair accessible à tous les intervenants. Prévoyez un coffre ou une procédure sécurisée pour les identifiants administrateurs, les secrets VPN, les clés et les certificats ; attribuez les accès selon les responsabilités.

À un niveau minimal (à valider avec le RSSI/DSI du client), la remise des secrets peut prévoir : stockage chiffré, canal séparé pour le partage (différent de l’envoi des documents), séparation des rôles (qui peut consulter vs qui peut modifier), rotation après la passation (fin de chantier, changement de prestataire) et procédure de révocation (comptes, certificats, accès distants).

Les droits et rôles doivent survivre au départ d’un prestataire ou d’un collaborateur. La remise d’une sauvegarde ne remplace pas une procédure de transfert des comptes et des contrats. Les principes de cybersécurité des infrastructures IP restent applicables après la livraison (renvoi éditorial).

Point d’attention (données personnelles) : certains éléments d’un DOE (journaux, inventaires, identifiants Wi‑Fi, listes de comptes, etc.) peuvent, selon le contexte, concerner des données permettant d’identifier directement ou indirectement des personnes. La loi marocaine 09‑08 pose notamment des principes de finalité et de proportionnalité, ainsi qu’une conservation n’excédant pas la durée nécessaire aux finalités. Source : Loi 09‑08 (PDF CNDP). La traduction opérationnelle (qui conserve quoi, combien de temps, qui accède) est à cadrer avec le client.

Inclure un inventaire exploitable des matériels

Conservez pour chaque appareil son rôle, son emplacement, sa référence, son numéro de série lorsque nécessaire, sa version, ses ports d’uplink et la personne chargée de sa maintenance. La liste doit également préciser les modules optiques et alimentations qui conditionnent la continuité du service.

Pour les réseaux d’hôtel ou les ensembles multisites, l’inventaire doit distinguer les fonctions critiques, les configurations standard et les exceptions. Ainsi, le remplacement d’un équipement ne dépend pas d’une recherche improvisée dans les factures.

À ajouter lorsqu’ils sont dans le périmètre : implantation de baie (face avant, numérotation RU, bandeaux d’alimentation), cheminements (cuivre/fibre) si disponibles, et dossier opérateur/FAI (références de liens, coordonnées support, responsabilités et éventuellement SLA contractuels).

Tracer les VLAN, SSID et règles de flux

Il faut documenter les SSID (identifiants Wi‑Fi), les profils d’authentification, les VLAN, les principaux flux interréseaux et les équipements qui fournissent les services de base : DNS (résolution de noms), DHCP (attribution d’adresses IP), synchronisation (NTP) et gestion des accès (AAA, pour Authentication, Authorization, Accounting, via RADIUS ou TACACS+ selon le cas). Une liste de VLAN non reliée aux zones et aux services reste difficile à exploiter.

Toutefois, le document destiné aux utilisateurs ne doit pas nécessairement contenir les détails sensibles des règles de sécurité. Préparez une version technique à accès contrôlé et un résumé d’exploitation. Voir également le guide des VLAN dans un bâtiment connecté (renvoi éditorial).

Remettre la recette et les mesures

Le DOE doit contenir les résultats de certification des câbles lorsque le contrat le prévoit, les tests de fibre, les essais d’uplink et les mesures Wi‑Fi de réception. Ajoutez les incidents de recette corrigés, les exceptions acceptées et les réserves restant à lever.

Ces éléments permettent de distinguer, lors d’une panne future, un défaut apparu après livraison d’un problème initialement connu. Les tests doivent être identifiés par date, zone, méthode et personne responsable.

Définir la gouvernance des modifications

Après une mise à jour de switch ou la création d’un VLAN, il faut enregistrer la version, le motif, les tests et la nouvelle sauvegarde. Le propriétaire doit savoir où se trouve la référence la plus récente et qui peut la modifier.

Le DOE domotique décrit une logique similaire pour d’autres lots techniques. Ici, le périmètre se concentre sur les équipements IP, les liens, la sécurité et les services réseau (renvoi éditorial).

Contenu technique détaillé : checklist DOE réseau

Selon la taille du site et le niveau d’exigence, un DOE réseau informatique peut regrouper les éléments ci-dessous. Cette checklist sert de base de cadrage ; le périmètre exact doit être celui du contrat et des politiques du client.

1) Adressage IP et plan de nommage

  • Plan d’adressage : sous-réseaux, masques, passerelles, plages DHCP, réservations DHCP si utilisées.
  • Adresses statiques : équipements d’infrastructure (cœur, firewall, contrôleur Wi‑Fi), serveurs, imprimantes, VMS (Video Management System) le cas échéant.
  • Nommage : convention de nom des équipements (switches, AP, routeurs), des interfaces/ports si documentés, et des VLAN/SSID.
  • Correspondance zones ↔ VLAN ↔ sous-réseaux : qui est où, et pourquoi (invités, vidéo, voix, GTB, back-office, etc.).

2) Routage, NAT et interconnexions

  • Schéma de routage : où se trouve le routage (cœur L3, firewall), routes statiques/dynamiques si applicables (sans détailler des informations sensibles dans une version publique).
  • NAT (si présent) : principes, objets concernés, dépendances (ex. accès distants, publication de services).
  • Interconnexions : liens WAN, liens vers opérateur/FAI, liens vers sites distants ; responsabilités (qui gère quoi).

3) Services d’infrastructure (DNS/DHCP/NTP/AAA)

  • DHCP : serveur(s), scopes, options importantes, relais DHCP (helpers) si utilisés.
  • DNS : serveurs, zones internes si concernées, principes de résolution.
  • NTP : source de temps, hiérarchie, dépendances (journaux, certificats).
  • AAA / RADIUS / TACACS+ (selon le cas) : principes d’authentification admin et/ou Wi‑Fi, profils, dépendances, sans exposer de secrets dans la version large diffusion.

4) Wi‑Fi (radio, SSID et sécurité)

  • Plan Wi‑Fi : implantation (plans), canaux et largeurs, puissances d’émission, bandes utilisées (2,4/5/6 GHz selon matériel), contraintes particulières (zones denses, chambres, couloirs, salles).
  • SSID : usage, VLAN associés, méthode d’authentification (captive portal, WPA2/WPA3 entreprise, PSK, etc. selon conception).
  • Contrôleur/manager : paramètres clés (site, profils radios, groupes), et sauvegardes associées.
  • Mesures : rapports de couverture/validation si prévus au contrat (site survey), avec date et périmètre.

5) Management et OOB (Out-of-Band)

  • Réseau de management : VLAN/sous-réseau, adresses de management, restriction d’accès (ACL, bastion, VPN) selon politique.
  • Accès console / OOB : présence de console server, procédures d’accès en cas d’indisponibilité du réseau principal.
  • Journalisation : principes syslog/SIEM (Security Information and Event Management) si mis en œuvre, destinations, rétention si définie (à convenir au projet, y compris sur les aspects conformité).

6) Sauvegardes par type d’équipement (quoi, comment, dépendances)

  • Switches : configuration, version OS/firmware, paramètres PoE, VLAN/trunks, STP (Spanning Tree Protocol) et agrégations (LACP) si utilisés.
  • Routeurs / pare-feu : configuration, objets/règles (version restreinte), VPN, NAT, certificats (inventaire, dates d’expiration), licences dépendantes.
  • Contrôleur Wi‑Fi : sauvegarde projet/site, profils SSID, groupes d’AP, paramètres radios.
  • Supervision (si incluse) : exports de configuration, listes d’équipements, seuils/alertes, dépendances (comptes, agents, clés API si utilisées — à traiter en canal sécurisé).

7) Supervision, alertes et logs (exploitation)

  • Liste des points de supervision : équipements, interfaces critiques, liens uplink, onduleurs si suivis.
  • Alerting : qui reçoit quoi, escalade, plages horaires (si défini).
  • Procédures de diagnostic : vérifications de base (lien, IP, VLAN, PoE, Wi‑Fi), adaptées à l’environnement livré.

8) Matrice de responsabilités et escalade (qui fait quoi)

  • Responsabilités : qui administre le cœur réseau, le Wi‑Fi, le firewall, les liens opérateurs, la supervision (client, intégrateur, infogérant).
  • Accès : modalités d’accès (VPN, bastion) et règles d’habilitation (références au processus client).
  • Escalade : contacts, plages d’intervention, modalités de prise en charge (si prévues au contrat).

Exemple de livrables réseau pour un étage d’hôtel

Dans un établissement comportant plusieurs baies d’étage, un technicien doit pouvoir partir d’un appel de la réception (« caméra du couloir 2 indisponible ») et retrouver la chaîne physique sans deviner les connexions. Une matrice de brassage lisible peut comprendre les éléments suivants :

Exemple illustratif de table de brassage et de recette (références fictives).
Zone / prise Baie et panneau Port du switch Rôle et réseau logique Essai de recette
Étage 2, couloir est, CAM-02 B2 / PP-01 / port 17 SW-B2-01 / Gi1/0/17 Caméra ; VLAN vidéo (ID/nom) documenté dans le plan VLAN Liaison cuivre certifiée et vidéo visible depuis VMS autorisé
Étage 2, AP-05 B2 / PP-01 / port 18 SW-B2-01 / Gi1/0/18 Point d’accès ; SSID + VLAN associés documentés PoE, adoption contrôleur et SSID conformes
Étage 2, TEL-05 B2 / PP-01 / port 19 SW-B2-01 / Gi1/0/19 Téléphone ; VLAN voix (ID/nom) indiqué Appel réception, qualité audio et PoE vérifiés
Montée étage 2 vers cœur B2 / FO-01 / fibres 1–2 Uplink (interface exacte + vitesse) documenté Trunk de distribution ; modules optiques + débit + VLAN transportés notés Mesure FO, état lien, débit et redondance si prévue

Ces références sont fictives et servent uniquement à illustrer le dossier à produire. La table définitive doit correspondre exactement aux prises, ports, identifiants de baies, chemins et étiquettes posés. Les repérages doivent être vérifiés physiquement à la remise.

Pour éviter les ambiguïtés sur les liaisons critiques (uplinks/trunks), la documentation associée doit indiquer, lorsque c’est applicable à l’architecture livrée : VLAN autorisés (allowed), tagging (802.1Q), mode (access/trunk), agrégation (LACP, nombre de liens), vitesse/duplex (ou auto-négociation), type de module (SFP/SFP+ et référence), ainsi que les principes de redondance (STP : rôle racine attendu, ou mécanismes type MLAG (Multi‑Chassis Link Aggregation)/stacking si présents) et les tests effectués en recette. Les termes et champs exacts dépendent des équipements réellement posés.

Version de référence et procédure de restauration

Le DOE doit distinguer configuration active et configuration enregistrée pour redémarrage lorsque le système utilise cette distinction. Les procédures ne sont pas universelles : elles dépendent du constructeur, de la famille d’équipement, du logiciel et de la version exacte.

Pour chaque élément critique, la livraison devrait indiquer : fichier exporté, horodatage, version logicielle, compatibilité requise pour restauration, emplacement de conservation, responsable et méthode de test. Lorsque c’est pertinent, ajoutez un nommage normalisé (ex. site/baie/équipement/date/version) et une empreinte (checksum) pour détecter une altération accidentelle du fichier. Ces choix doivent être compatibles avec les procédures du client.

Une sauvegarde ne sera exploitable que si une vérification d’importation ou de restauration contrôlée a été réalisée lorsque le matériel et l’environnement le permettent (par exemple import « à blanc » sur un équipement de test, ou validation de cohérence de l’export). Les conditions de test (fenêtre de maintenance, matériel disponible, restrictions éditeur/licence) doivent être précisées.

Scénario de passation : reprise d’un switch par un nouvel intégrateur

Imaginons qu’après la réception un switch d’étage soit remplacé. L’équipe habilitée retrouve sa référence, ses interfaces, ses VLAN, ses trunks, ses profils PoE et la version de configuration à restaurer. Elle vérifie ensuite la correspondance entre les ports physiques et les circuits raccordés, puis teste les services de l’étage avant de clôturer l’intervention.

Une procédure de changement doit préciser (convention de projet) qui autorise la coupure, comment les clients ou occupants seront informés, qui possède les sauvegardes et comment revenir à la situation antérieure.

Le dossier après intervention conserve l’ancienne et la nouvelle référence matérielle, les différences de configuration, le résultat des essais et la date de validation. Cela permet à un autre intervenant de comprendre le changement sans reconstituer le chantier.

Contenu minimal d’un DOE réseau

Contenu minimal (à ajuster au contrat, aux politiques client et au périmètre technique livré).
Pièce Format utile Mise à jour
Schémas physique et logique Diagrammes éditables + PDF Après changement de topologie
Table de brassage Tableau ports–prises–destinations À chaque repiquage
Configurations Exports nommés, versions, checksum si pertinent Après intervention
Recettes Résultats cuivre/fibre, mesures Wi‑Fi et tests À réception et extensions
Gestion des droits Procédure sécurisée hors document public À chaque changement d’équipe

Checklist opérationnelle (remise et acceptation)

  • Vérifier que tous les équipements figurent dans l’inventaire (y compris modules SFP, alimentations, contrôleur Wi‑Fi, firewall, liens opérateur dans le périmètre).
  • Comparer les étiquettes de baie et prises aux plans (contrôle terrain).
  • Recueillir les configurations et vérifier leur exploitabilité (format, version, dépendances, test possible).
  • Distinguer version d’exploitation et version confidentielle du DOE (accès contrôlé).
  • Documenter le plan IP, le plan de nommage, les services réseau et les dépendances critiques.
  • Joindre les résultats de recette, les exceptions acceptées et les réserves.
  • Nommer le responsable des révisions documentaires et l’emplacement de la « version de référence ».

Questions fréquentes

Le DOE doit-il inclure les mots de passe ?

Il doit organiser leur remise sécurisée aux personnes autorisées, mais pas exposer tous les secrets dans un dossier largement diffusé. En pratique, privilégiez une version restreinte (accès contrôlé) et un canal séparé pour les secrets, selon les règles du client.

Un schéma PDF suffit-il ?

Non, des fichiers éditables et une table de brassage maintenable facilitent les évolutions. Le PDF reste utile pour consultation, mais ne remplace pas les fichiers sources.

À quelle fréquence mettre à jour le DOE ?

À chaque modification significative, puis lors d’une vérification périodique de cohérence (inventaire, table de brassage, sauvegardes, versions), selon l’organisation d’exploitation.

Conclusion

Le DOE réseau est une composante du service livré au client. En cadrant le périmètre dès le contrat, puis en remettant des plans (physiques et logiques), une table de brassage éditable, des configurations identifiées et testées lorsque possible, des résultats de recette et une gouvernance des changements, le propriétaire réduit le risque de dépendance à un intervenant unique et sécurise la maintenabilité du site après chantier.

Parler de votre projet avec Domocasa

Sources techniques de référence

  • OFPPT — DCE (PDF) : exemple de pièces de marché mentionnant la réception provisoire.
  • APDN — CPS/RC (PDF) : exemple de pièces de marché mentionnant réceptions provisoire/définitive et délais.
  • Loi 09‑08 (PDF CNDP) : définitions et principes généraux (finalité, proportionnalité, durée nécessaire) applicables à la protection des données personnelles.
  • CNDP — Notifier un traitement : point d’entrée informatif sur les régimes de déclaration/autorisation et certains cas de transferts, sans présumer des démarches applicables à un projet donné.
  • CNDP — Publications : accès aux ressources et guides publiés par l’autorité.