Un audit réseau informatique ne se résume pas à scanner des ports et lister des switchs. La valeur d’un audit tient à sa capacité à produire une preuve de maîtrise opérationnelle, pas un simple inventaire statique. Nous abordons ici les points méthodologiques qui font la différence entre un livrable exploitable et un document classé sans suite.
Écart entre configuration déclarée et configuration observée : le vrai point de départ
La plupart des guides d’audit réseau démarrent par la cartographie. C’est nécessaire, mais insuffisant si elle se limite à un export SNMP brut. Le premier réflexe doit être de confronter la configuration déclarée (CMDB, documentation interne, schémas d’architecture) à la configuration réellement observée sur les équipements.
Un switch dont la table de VLANs ne correspond pas au schéma réseau officiel constitue un risque immédiat. Un pare-feu dont les règles actives divergent de la politique de sécurité documentée invalide toute conformité affichée. Chaque écart entre déclaré et observé doit être horodaté et tracé, en identifiant qui a collecté l’information et dans quelles conditions.
Cette approche transforme l’audit en preuve opposable, notamment dans le cadre de la directive NIS2 qui impose de raisonner en périmètre de conformité documenté. Il ne suffit plus de cocher des cases techniques : l’entité auditée doit justifier formellement le scope retenu, y compris la classification des filiales et des interconnexions avec des tiers. Pour réussir un audit réseau informatique, cette rigueur documentaire pèse autant que l’analyse technique elle-même.
Tests de résilience réseau : failover, bascules et restauration effective
Beaucoup d’audits s’arrêtent à l’identification des vulnérabilités. Ils produisent un rapport de failles classées par criticité, puis passent au plan d’action. Le chaînon manquant, c’est le test de résilience contrôlé.
Un plan de reprise non testé n’est pas un plan de reprise. Nous recommandons d’intégrer systématiquement trois vérifications opérationnelles dans le périmètre de l’audit :
- Bascule de lien WAN ou de cluster de pare-feu en conditions réelles, avec mesure du temps de coupure effectif et comparaison au RTO annoncé
- Restauration d’une sauvegarde réseau complète (configuration des équipements actifs, règles de filtrage, certificats) sur un environnement isolé, pour valider l’intégrité des fichiers
- Simulation de perte d’un nœud critique (contrôleur Wi-Fi, serveur DHCP/DNS interne) pour observer le comportement du réseau sans intervention humaine
Ces tests révèlent des fragilités invisibles à la cartographie. Un cluster actif/passif qui met plusieurs minutes à basculer au lieu de quelques secondes signale un problème de heartbeat ou de priorité mal configurée. Une sauvegarde de configuration qui ne se restaure pas correctement rend caduque toute stratégie de continuité.
Posture de sécurité réseau : dépasser le scan de vulnérabilités
Les audits réseau récents ne se limitent plus aux VLAN, aux ACL et aux ports ouverts. La notion de posture de sécurité intègre désormais des éléments organisationnels qui conditionnent la solidité technique.
Premier point : la centralisation des logs. Un réseau dont les équipements actifs n’envoient pas leurs journaux vers un collecteur centralisé (syslog, SIEM) est un réseau aveugle. L’audit doit vérifier que les logs sont collectés, horodatés via NTP et conservés sur une durée cohérente avec les obligations réglementaires (RGPD, NIS2).
Deuxième point : les politiques d’accès aux équipements d’administration. Nous observons régulièrement des accès SSH ou HTTPS aux switchs et routeurs ouverts depuis n’importe quel VLAN utilisateur, sans restriction par ACL de management. L’accès au plan d’administration doit être segmenté et limité à un VLAN dédié, avec authentification centralisée (RADIUS ou TACACS+).
Troisième point : le firmware. Un équipement réseau dont le firmware n’a pas été mis à jour depuis plusieurs années accumule des CVE connues. L’audit doit croiser la version installée avec les bulletins de sécurité du constructeur pour chaque équipement actif.
Conformité NIS2 et cybersécurité réseau
La directive NIS2 élargit le périmètre des entités concernées, y compris les PME de secteurs critiques. Pour ces entreprises, l’audit réseau n’est plus optionnel. Il devient une brique de la démonstration de conformité, au même titre que l’analyse de risques ou le plan de gestion des incidents. Le livrable d’audit doit donc être structuré pour servir de pièce justificative en cas de contrôle.
Livrable d’audit réseau : structurer un rapport exploitable
Un rapport d’audit qui liste des centaines de findings sans priorisation ni contexte métier finit dans un tiroir. La qualité du livrable détermine l’impact réel de l’audit sur l’infrastructure.
Chaque finding doit être rattaché à un risque métier concret. Un port TCP ouvert sur un serveur de production n’a pas la même criticité selon qu’il expose une base de données clients ou un service de supervision interne. Le rapport doit expliciter cette différence.
Nous recommandons de structurer le livrable en trois niveaux :
- Synthèse exécutive destinée à la direction, avec les risques majeurs traduits en impact business (indisponibilité, perte de données, non-conformité réglementaire)
- Rapport technique détaillé pour l’équipe infrastructure, avec les preuves collectées, les captures de configuration et les écarts constatés
- Plan de remédiation priorisé avec estimation d’effort, responsable identifié et échéance, classé par criticité décroissante
Ce découpage permet à chaque interlocuteur de trouver l’information à son niveau de lecture, sans noyer la DSI dans les détails techniques ni laisser la direction sans vision consolidée.
Suivi post-audit et gestion des coûts
Le rapport ne clôt pas l’audit. Un suivi à trois mois permet de vérifier que les remédiations critiques ont été appliquées, que les configurations corrigées n’ont pas régressé et que les outils de supervision couvrent les angles morts identifiés. Sans ce suivi, la majorité des remédiations planifiées ne sont jamais implémentées.
L’audit réseau en entreprise gagne en pertinence quand il est traité comme un processus récurrent, pas comme un événement ponctuel. Planifier un cycle annuel, calé sur les échéances de conformité et les évolutions d’infrastructure (migration cloud, déploiement SD-WAN), garantit que le réseau reste aligné avec les besoins réels des systèmes et des utilisateurs.