Cartographie SI : les 5 étapes ANSSI expliquées

La cartographie d’un système d’information n’est pas un dessin figé. L’ANSSI la présente comme un outil de maîtrise du SI qui participe à sa protection, à sa défense et à sa résilience. Son guide propose une démarche en cinq étapes conçue pour être pratique et progressive.1

Le point important est souvent mal compris : la difficulté n’est pas de produire une première vue. Elle est de construire un référentiel suffisamment précis pour répondre à des questions opérationnelles, mais suffisamment maîtrisable pour rester à jour. Une cartographie peut donc commencer petite, à condition que son modèle, ses responsabilités et son usage soient explicites.

FIG. 01Le cycle de construction d’une cartographie utile

01 / CadrerObjectif & périmètre

02 / ModéliserObjets & relations

03 / OutillerRéférentiel & vues

04 / ConstruireDonnées prioritaires

05 / PérenniserGouvernance & mise à jour

Les cinq étapes de l’ANSSI, traduites en décisions concrètes

1. Initier la démarche : commencer par la question, pas par l’inventaire

Le guide ANSSI commence par les enjeux, le périmètre, les acteurs, les besoins et le niveau de détail attendu.1 C’est logique : une cartographie construite pour préparer un audit n’a pas exactement le même grain qu’une cartographie utilisée pendant une crise ou pour analyser un PRA.

Avant de collecter des milliers d’objets, il est donc utile d’écrire cinq éléments sur une page : objectif, périmètre, utilisateurs, questions à résoudre et fréquence de mise à jour. Cette fiche évite qu’un projet de cartographie ne devienne un programme d’inventaire sans fin.

Exemples de questions de départ : quelles applications supportent un processus critique ? De quels services IAM, bases de données ou fournisseurs cloud dépendent-elles ? Quels flux traversent une frontière de confiance ? Quelles briques doivent être restaurées avant les autres ?

2. Définir le modèle : décider ce qu’un objet signifie

L’ANSSI recommande de s’appuyer sur les inventaires et schémas disponibles puis de définir un modèle de représentation commun.1 C’est l’étape où l’on choisit ce que l’on appellera une application, un service, un serveur logique, un site, un flux ou un tiers — et surtout quelles relations peuvent exister entre eux.

Un dictionnaire minimal peut ressembler à ceci : Processus → supporté par → Application ; Application → échange avec → Application ; Application → hébergée sur → Infrastructure ; Application → dépend de → Identité ; Tiers → fournit → Service.

La règle utile est de ne pas créer un type d’objet parce qu’il « serait intéressant de l’avoir », mais parce qu’il permet de répondre à une question. Un modèle trop riche dès le départ augmente le coût de collecte et de maintenance sans garantir une meilleure compréhension.

3. Choisir l’outillage : privilégier le référentiel avant le dessin

L’outil sert à produire des vues, mais sa valeur dépend surtout de sa capacité à conserver les objets et leurs relations, à les rechercher, à les importer, à tracer les changements et à générer plusieurs représentations à partir d’une même donnée.

Le guide ANSSI ne prescrit pas un produit particulier.1 Les critères sont donc d’abord opérationnels : gestion des droits, modèle extensible, import/export, historique, capacité à relier des sources existantes, vues adaptées à différents publics et mécanismes de mise à jour.

Un fichier ou un outil de dessin peut être suffisant pour un prototype. Il devient fragile lorsque plusieurs équipes doivent partager la donnée ou lorsque la même application doit apparaître dans une vue métier, une vue de flux et une vue d’infrastructure sans être ressaisie trois fois.

4. Construire progressivement : viser une première chaîne de dépendances complète

L’approche progressive décrite par l’ANSSI conduit à privilégier un périmètre utile plutôt qu’une couverture superficielle de tout le SI.1 Une bonne première itération peut être une application critique avec son processus métier, ses identités, ses données, ses principaux flux, son hébergement et ses tiers.

Cette chaîne est plus instructive qu’un inventaire de centaines d’applications sans relations. Elle permet aussi de tester le modèle : si l’équipe ne parvient pas à représenter correctement un service connu, il vaut mieux corriger la structure avant d’industrialiser la collecte.

5. Pérenniser : transformer la cartographie en processus

La cinquième étape du guide porte explicitement sur la pérennité : gouvernance, diffusion, promotion et maintien.1 C’est souvent ce qui sépare une cartographie utile d’un projet ponctuel.

Chaque famille de données devrait avoir un propriétaire ou, au minimum, une source de vérité identifiée. Une application peut être issue d’un portefeuille applicatif, un serveur d’un outil d’inventaire, un compte cloud d’une organisation cloud et la criticité d’un processus métier d’un référentiel de continuité. La cartographie n’a pas nécessairement vocation à devenir maître de toutes ces données ; elle doit savoir d’où elles viennent et comment elles se rejoignent.

Le modèle de données compte davantage que la beauté de la vue

Une vue peut être très lisible et pourtant trompeuse si elle ne précise ni son périmètre ni sa fraîcheur. À l’inverse, un référentiel structuré peut générer plusieurs vues différentes sans dupliquer les faits.

Trois distinctions évitent beaucoup de confusion :

l’objet : une application, un processus, un serveur, un tiers ;
la relation : « dépend de », « échange avec », « hébergé sur », « fourni par » ;
la vue : une sélection d’objets et de relations pour répondre à une question.

Cette séparation facilite aussi l’automatisation. Une source technique peut mettre à jour des ressources cloud sans décider de la criticité métier ; une équipe métier peut qualifier un processus sans modifier la topologie réseau.

Quatre erreurs qui rendent une cartographie inutilisable

Confondre exhaustivité et utilité

Un référentiel incomplet mais clairement borné peut être utile. Un référentiel présenté comme exhaustif alors qu’il ne couvre qu’une partie du SI est dangereux. Le périmètre et la date de vérification doivent être visibles.

Collecter les objets sans leurs relations

Un inventaire répond à « qu’avons-nous ? ». Une cartographie doit aussi répondre à « comment ces éléments dépendent-ils les uns des autres ? ». Les relations transforment la liste en modèle de système.

Multiplier les niveaux de détail sans besoin identifié

Documenter chaque interface, chaque port réseau et chaque ressource cloud peut être pertinent dans un périmètre technique précis. Le faire partout par principe rend la maintenance coûteuse. Le niveau de détail doit suivre le cas d’usage.

Oublier le mécanisme de mise à jour

La donnée devient obsolète parce que le SI évolue : nouveau SaaS, changement d’hébergeur, fusion d’applications, modification d’un flux, nouvelle dépendance. Une cartographie pérenne prévoit comment ces changements sont détectés, qui les valide et à quelle fréquence les vues critiques sont contrôlées.

Le test de qualité : quelles décisions devient-il plus facile de prendre ?

Une cartographie n’est pas meilleure parce qu’elle contient davantage d’objets. Elle devient utile lorsqu’elle réduit le temps nécessaire pour comprendre un impact : qu’est-ce qui est critique ? de quoi dépend ce service ? quelles données circulent ? quels tiers interviennent ? quel composant faut-il restaurer en premier ?

On peut utiliser ce test dès la conception. Si aucune décision ou question récurrente ne dépend d’un champ, d’un objet ou d’une relation, sa collecte mérite d’être questionnée.

Et le RGPD dans tout cela ?

La CNIL recommande de recenser précisément les traitements, les catégories de données, leurs finalités, les acteurs et les flux, notamment l’origine et la destination des données.2 Elle rappelle aussi que les traitements doivent être identifiés par finalité et non par logiciel, car un logiciel peut servir plusieurs traitements et un traitement peut s’appuyer sur plusieurs outils.3

Une cartographie SI et un registre RGPD ne doivent donc pas être fusionnés. Ils peuvent en revanche partager des points de jonction : une application peut être reliée aux traitements qu’elle supporte, aux données manipulées, aux flux concernés et à l’hébergement.

Une checklist de lancement en dix questions

Avant de lancer ou reprendre une cartographie, vérifier ces dix points permet de détecter rapidement les projets trop flous :

Quel problème voulons-nous résoudre en premier ?
Quel périmètre est explicitement inclus — et exclu ?
Qui utilise la cartographie et pour quelles décisions ?
Quels types d’objets sont réellement nécessaires ?
Quelles relations doivent être conservées ?
Quelles sources de données existent déjà ?
Quelle donnée fait autorité en cas de conflit ?
Qui valide les informations métier et techniques ?
Comment un changement du SI déclenche-t-il une mise à jour ?
Comment mesure-t-on qu’une vue est encore fiable ?

Cette approche ne garantit pas qu’une cartographie sera exhaustive. Elle vise quelque chose de plus utile : un référentiel compréhensible, gouverné et améliorable, capable de grandir avec le système d’information au lieu de vieillir à côté de lui.