La cartographie du système d'information est souvent perçue comme un chantier titanesque. On reporte, on hésite, on attend d'avoir "le bon moment". Pourtant, l'absence de cartographie est elle-même un risque majeur. Voici comment démarrer, même quand on part de zéro.
Le paradoxe de la cartographie
Il existe une ironie bien connue dans le monde de la sécurité informatique : les organisations qui ont le plus besoin d'une cartographie de leur SI sont souvent celles qui ont le moins de visibilité sur ce qu'elles possèdent. Elles ne savent pas par où commencer, précisément parce qu'elles ne savent pas ce qu'elles ont.
Ce cercle vicieux explique pourquoi tant de projets de cartographie n'aboutissent jamais. On attend d'avoir un inventaire complet avant de cartographier, mais on ne peut pas faire l'inventaire sans une méthode, et on ne trouve pas la méthode sans avoir déjà une idée de ce qu'on cherche.
La bonne nouvelle : il n'existe pas de point de départ parfait. Il existe seulement un point de départ.
Pourquoi cartographier son SI ?
Avant d'entrer dans la méthode, il est utile de rappeler pourquoi cet exercice est fondamental.
Comprendre ce que vous défendez. On ne peut pas protéger ce qu'on ne connaît pas. Une organisation qui ignore qu'elle héberge un ancien serveur de fichiers oublié ne peut pas surveiller les accès à ce serveur. Or, ces actifs "fantômes" sont souvent les premiers vecteurs d'intrusion exploités lors d'une attaque.
Répondre aux exigences réglementaires. NIS2, DORA, ISO 27001, les référentiels de l'ANSSI... Tous exigent une connaissance documentée du système d'information. La cartographie n'est plus une bonne pratique optionnelle : c'est une obligation pour de nombreuses organisations.
Prendre de meilleures décisions. Budgets, priorisation des correctifs, choix d'architecture : toutes ces décisions sont plus pertinentes quand elles s'appuient sur une vision claire du SI existant.
Étape 1 : Définir le périmètre avant de lister les assets
L'erreur la plus fréquente est de vouloir tout capturer d'un coup. On ouvre un tableur, on commence à lister des serveurs, et au bout de trois jours on a une feuille ingérable et une équipe épuisée.
La bonne approche consiste à définir d'abord les frontières de ce qu'on veut cartographier, puis à descendre progressivement dans le détail.
Posez-vous ces questions en équipe :
- Quel est le SI "cœur de métier" ? Quelles applications sont indispensables à l'activité quotidienne ?
- Quelles sont les interconnexions avec l'extérieur (partenaires, prestataires, cloud) ?
- Quels sont les actifs qui, s'ils tombaient en panne ou étaient compromis, auraient le plus d'impact ?
Ce dernier critère est particulièrement utile : il permet de prioriser par criticité métier plutôt que par exhaustivité technique.
Étape 2 : Adopter une approche par couches
Un SI peut se lire à plusieurs niveaux d'abstraction. Plutôt que de tout traiter à la même granularité, cartographiez couche par couche.
La couche métier — Quels processus font tourner l'organisation ? Facturation, ressources humaines, production, support client... Chaque processus s'appuie sur des applications, et chaque application s'appuie sur une infrastructure.
La couche applicative — Quels logiciels, SaaS, progiciels ou applications maison supportent ces processus ? C'est souvent ici que les surprises apparaissent : des abonnements SaaS souscrits par un service sans validation de la DSI, des applications legacy que personne n'ose décommissionner, des outils gratuits utilisés pour traiter des données sensibles.
La couche infrastructure — Serveurs, postes de travail, équipements réseau, stockage, environnements cloud. C'est la couche la plus volumineuse et la plus technique. Elle vient en dernier, pas en premier.
La couche données — Où sont stockées les données sensibles ? Bases clients, données RH, propriété intellectuelle... Cette couche est souvent la plus critique du point de vue réglementaire (RGPD notamment).
Étape 3 : Identifier les sources d'information existantes
Avant de lancer des scans réseau ou des interviews, consultez les sources d'information qui existent déjà dans l'organisation. Elles sont souvent plus nombreuses qu'on ne le pense.
- Contrats et factures : les abonnements logiciels, licences et contrats de maintenance donnent une liste partielle mais fiable des actifs connus
- Annuaire Active Directory ou équivalent : il contient les postes de travail et serveurs déclarés dans le domaine
- Outils de gestion des actifs (CMDB, ITSM) : s'ils existent, même partiellement à jour, ils sont un point de départ précieux
- Sauvegardes : la liste des systèmes sauvegardés révèle souvent ce qui est considéré comme critique
- Plans réseau anciens : même obsolètes, ils donnent une base de travail
L'objectif n'est pas d'avoir des données parfaites, mais d'avoir un premier référentiel à confirmer ou corriger.
Étape 4 : Compléter par la découverte active
Une fois la base documentaire constituée, il faut confronter ce qu'on croit savoir avec ce qui existe réellement sur le réseau. C'est l'étape de découverte active.
Des outils comme Nmap, Nessus, Lansweeper ou des solutions d'asset management automatisées permettent de scanner le réseau et de détecter des équipements non répertoriés. Cette étape révèle presque toujours des surprises : des machines oubliées, des équipements IoT non déclarés, des serveurs de développement restés en production.
Attention cependant : cette découverte doit être encadrée et autorisée. Un scan réseau non coordonné peut déclencher des alertes de sécurité, perturber des équipements fragiles, ou créer des tensions avec les équipes métier. Prévenez les parties prenantes, planifiez les scans pendant des fenêtres adaptées.
Étape 5 : Impliquer les métiers, pas seulement la DSI
C'est peut-être la leçon la plus importante : une cartographie du SI faite uniquement par la DSI sera toujours incomplète.
Les directions métier savent quels outils elles utilisent réellement, même ceux qu'elles n'ont jamais déclarés. La direction commerciale connaît ses outils CRM et de prospection. Les RH savent si elles utilisent un outil tiers pour gérer les congés. La comptabilité sait si le cabinet expert-comptable a accès à un partage de fichiers.
Organisez des ateliers courts avec chaque direction. Posez une question simple : "Quels outils vous seraient impossibles à perdre pendant une semaine ?" Les réponses donnent immédiatement les actifs critiques du point de vue métier.
Étape 6 : Choisir un format de représentation adapté
La cartographie n'est pas une fin en soi : c'est un outil de communication et de décision. Le format doit donc s'adapter à l'audience.
Pour les directions et le COMEX : une vue fonctionnelle et macroscopique, centrée sur les processus métier et leurs dépendances. Des schémas simples, peu techniques, qui montrent l'impact d'une défaillance sur l'activité.
Pour les équipes techniques : des vues réseau, des diagrammes d'architecture, des matrices de flux. Plus de granularité, plus de détail sur les versions logicielles et les protocoles utilisés.
Pour la gestion des risques : une cartographie croisée avec des niveaux de criticité, des indicateurs de vulnérabilité, des dates de fin de support. C'est la base d'une analyse de risques structurée.
Il n'existe pas un seul "bon" format. Il en existe plusieurs, chacun servant un besoin différent.
Étape 7 : Accepter que la cartographie soit toujours incomplète
Un dernier point, et non des moindres : une cartographie du SI ne sera jamais parfaite. Les systèmes évoluent, des actifs sont ajoutés sans validation, des services cloud sont souscrits en dehors des circuits officiels.
L'objectif n'est pas la perfection, mais la pertinence et la maintenabilité. Une cartographie à 80% à jour vaut infiniment mieux qu'aucune cartographie. Une cartographie imparfaite mais révisée régulièrement est plus utile qu'un document exhaustif mis à jour tous les cinq ans.
Intégrez la mise à jour de la cartographie dans les processus existants : chaque nouveau projet IT, chaque acquisition d'outil, chaque départ de prestataire devrait déclencher une mise à jour.
Par où commencer, concrètement ?
Si vous ne devez retenir qu'une chose : commencez par ce que vous savez déjà.
Prenez une demi-journée avec deux ou trois personnes clés. Listez les dix applications les plus critiques pour votre activité. Pour chacune, notez sur quelle infrastructure elle tourne et quelles données elle manipule. Vous aurez en quelques heures un premier noyau de cartographie, imparfait mais réel, sur lequel vous pourrez construire.
La cartographie du SI n'est pas un projet qui se termine. C'est une pratique qui s'installe. Et comme toute pratique, elle commence par un premier pas — même approximatif.
Chez Cybershell, nous accompagnons les organisations dans leur démarche de sécurisation du système d'information, de la cartographie des actifs à la formation et sensibilisation des collaborateurs. Parce qu'une bonne posture cyber commence toujours par une meilleure connaissance de ce que l'on protège.