Cartographie SI

Définition de la cartographie SI

La cartographie du système d'information, souvent abrégée cartographie SI, désigne l'ensemble des représentations structurées qui décrivent les composants d'un SI, leurs caractéristiques et leurs relations. C'est à la fois une démarche, un livrable et un outil de pilotage.

Une cartographie SI moderne couvre plusieurs niveaux superposés. Le niveau métier décrit les processus et les services rendus aux utilisateurs. Le niveau applicatif détaille les applications, les modules logiciels et les flux de données entre eux. Le niveau technique précise les serveurs, les conteneurs, les bases de données, les composants réseau et les configurations cloud.

Pourquoi cartographier son SI ?

Cartographier son SI répond à plusieurs enjeux qui se sont intensifiés ces dernières années.

Le premier enjeu est la conformité réglementaire. NIS2 impose en pratique de connaître précisément ses SI critiques pour pouvoir notifier un incident dans les 24 heures. ISO 27001 demande une analyse de risques par actif. RGPD exige le traçage des flux de données personnelles. Aucune de ces obligations n'est tenable sans cartographie à jour.

Le deuxième enjeu est la cybersécurité opérationnelle. En cas d'incident, la capacité à identifier en quelques minutes les applications affectées, leurs dépendances et les utilisateurs impactés détermine le délai de réponse. Sans cartographie, l'équipe perd des heures à reconstituer manuellement la chaîne d'impact.

Le troisième enjeu est la gouvernance du SI. Les décisions d'évolution (migration cloud, rationalisation applicative, modernisation d'une couche technique) supposent de connaître l'existant. La cartographie devient le langage commun entre la DSI, le RSSI, les architectes et les équipes métier.

Le quatrième enjeu est la maîtrise des coûts. Identifier les applications redondantes, les serveurs sous-utilisés ou les contrats de support à renégocier suppose de voir l'ensemble.

Les méthodes traditionnelles et leurs limites

Les méthodes traditionnelles de cartographie reposent sur trois piliers : interviews des sachants, ateliers d'architecture et formalisation dans des outils de modélisation (Visio, Archi, Enterprise Architect).

Cette approche fonctionne pour un SI stable, dans une organisation où les équipes ont le temps de tenir la documentation à jour. Elle se heurte rapidement à trois limites dans un contexte moderne.

La première limite est la dérive temporelle. Une cartographie produite en six mois est obsolète au moment où elle sort. Avec le rythme de déploiement actuel (CI/CD, provisionning cloud automatisé), le SI change tous les jours.

La deuxième limite est la dépendance aux sachants. La connaissance reste détenue par quelques personnes-clés. Quand un architecte part, c'est une partie du SI qui devient opaque.

La troisième limite est l'absence de preuve. Une cartographie sous Visio est un document statique, sans lien avec la réalité opérationnelle. Difficile de l'utiliser face à un auditeur ANSSI qui demande à prouver l'état actuel du SI.

Cartographie automatique : la nouvelle génération

L'approche moderne consiste à automatiser la cartographie à partir des sources de vérité opérationnelle. Plutôt que de demander aux équipes de saisir manuellement, on se branche sur les outils existants : monitoring (Datadog, Prometheus, New Relic), IaC (Terraform, Pulumi), CMDB (ServiceNow, BMC), cloud (AWS Config, Azure Resource Graph), code source (analyse des dépendances).

La plateforme reconstruit en continu la cartographie applicative à partir de ces sources, détecte les évolutions et alerte sur les écarts. Les architectes passent du rôle de scribe à celui de pilote : ils enrichissent la cartographie automatique avec la vision cible et les choix d'architecture, mais ne perdent plus de temps sur la collecte.

C'est cette approche qu'Uncia incarne, en combinant l'ingestion automatique de sources et l'expertise des architectes pour produire une cartographie vivante, fiable et exploitable pour la conformité NIS2 et ISO 27001.

Par où commencer une cartographie SI ?

Un projet de cartographie réussi commence rarement par la totalité du SI. La logique gagnante est de partir d'un cas d'usage précis : par exemple la conformité NIS2 d'une activité essentielle, ou la préparation d'une migration cloud, ou la réponse à un audit ISO 27001.

Ce cas d'usage définit le périmètre minimum à cartographier (les SI critiques de cette activité) et la profondeur utile (applications, flux, dépendances infrastructure). Une fois la première itération réussie, l'élargissement à d'autres périmètres devient mécanique.

La deuxième règle est de partir des sources existantes plutôt que de la page blanche. Quelques jours d'ingestion produisent une première cartographie utilisable, qu'on enrichit ensuite avec les architectes.