Une cartographie du système d’information n’est pas un schéma décoratif que l’on sort seulement pour un audit. C’est un outil de lecture qui permet de voir les composants, les flux, les dépendances et les points de rupture avant qu’ils ne deviennent des incidents. Dans un contexte d’informatique et de cybersécurité, elle sert autant à piloter qu’à protéger, à condition de rester simple, lisible et mise à jour.
L’essentiel à retenir avant de cartographier un SI
- Une cartographie utile relie le métier, les applications et l’infrastructure au lieu de se limiter aux serveurs.
- Le bon format est progressif: commencer par une vue claire, puis enrichir les détails par itérations.
- Les flux sensibles, les dépendances externes, les comptes à privilèges et les sauvegardes doivent apparaître en priorité.
- Une cartographie qui n’est pas mise à jour à chaque changement majeur perd rapidement sa valeur opérationnelle.
- Le meilleur niveau de détail est celui qui aide à décider vite en cas de panne, d’audit ou d’attaque.
Ce qu’une bonne cartographie doit montrer
Je distingue toujours la cartographie utile du simple inventaire. Un inventaire liste des éléments; une cartographie montre surtout comment ces éléments travaillent ensemble, où passent les flux et ce qui dépend de quoi. L’ANSSI recommande de partir de trois vues qui vont du métier vers la technique: la vue métier, la vue applicative et la vue infrastructure. C’est cette progression qui évite de tomber dans un schéma trop bas niveau, illisible pour les équipes métier, ou trop abstrait, inutile pour les équipes techniques.
| Vue | Ce qu’elle montre | À quoi elle sert | Exemple concret |
|---|---|---|---|
| Vue métier | Les processus, les acteurs, les données critiques et la mission du SI | Comprendre ce que l’entreprise cherche vraiment à faire | Prise de commande, facturation, support client |
| Vue applicative | Les applications, services, API et flux de données entre eux | Identifier les dépendances logicielles et les points de rupture | Site web, CRM, ERP, outil de ticketing, service d’authentification |
| Vue infrastructure | Les serveurs, réseaux, environnements cloud, stockages et liaisons techniques | Voir où résident les risques techniques et les chemins d’accès | VPC cloud, VPN, DNS, bases de données, sauvegardes |
À mon sens, c’est la combinaison de ces trois niveaux qui rend la cartographie exploitable. Si l’une des couches manque, on perd soit le sens métier, soit la logique des flux, soit la réalité technique. C’est précisément ce qu’illustre un cas concret.
Un exemple concret pour une PME connectée
Prenons une PME de vente en ligne avec un site e-commerce, un ERP, un CRM, une messagerie cloud et une solution de paiement externe. Sur le papier, l’environnement semble simple. En pratique, il dépend d’une chaîne de composants et de flux qu’il faut rendre visible pour éviter les angles morts.
Si je construis cette cartographie, je commence par les flux qui portent la valeur:
- Commande client du site web vers le moteur de paiement puis vers l’ERP.
- Synchronisation stock entre l’ERP et la boutique en ligne.
- Flux support entre le CRM et l’outil de ticketing.
- Accès internes des équipes via SSO, VPN ou accès cloud sécurisé.
- Sauvegardes des bases de données et des fichiers critiques vers un stockage distinct.
| Élément | Rôle | Ce que je note dans la cartographie | Point d’attention |
|---|---|---|---|
| Site e-commerce | Canal de vente principal | Hébergement, dépendances API, flux de paiement | Disponibilité et exposition Internet |
| ERP | Gestion commandes, stock et facturation | Interfaces avec la boutique, le CRM et la compta | Effet domino en cas de panne |
| CRM | Suivi client et relation commerciale | Accès utilisateurs, synchronisation des données | Données personnelles et droits d’accès |
| Solution de paiement | Encaissement | Flux sortants, prestataire, contrats, authentification | Dépendance externe critique |
| Sauvegardes | Restitution après incident | Lieu de stockage, fréquence, tests de restauration | Vérifier qu’elles sont réellement restaurables |
Ce type d’exemple montre une chose très simple: la valeur de la cartographie ne vient pas du nombre de boîtes dessinées, mais de la capacité à lire un scénario réel. Quand un flux tombe, on doit pouvoir dire tout de suite ce qui est touché, qui intervient et ce qui doit être rétabli en priorité. Une fois ce cas posé, la vraie question devient la méthode.
Comment la construire en cinq étapes sans la surcharger
Le guide de l’ANSSI propose une démarche en cinq étapes, et c’est l’une des rares méthodes qui reste suffisamment pragmatique pour un projet réel. Je la résume ici dans une version opérationnelle, sans jargon inutile.
- Cadrer le périmètre. Définir ce qui entre dans la cartographie, pourquoi on la fait, qui la porte et quel niveau de détail est attendu.
- Recenser l’existant. Rassembler les schémas déjà disponibles, les inventaires techniques, les documents d’architecture, les listes d’applications et les flux connus.
- Fixer un modèle commun. Choisir les types de vues, la nomenclature, les objets à nommer de la même façon et les règles de représentation.
- Construire pas à pas. Avancer par itérations, en commençant par les éléments essentiels, puis en affinant les dépendances et les attributs utiles.
- Organiser la mise à jour. Définir un propriétaire, une règle de version, un circuit de validation et un point de revue intégré aux changements du SI.
Dans cette logique, je préfère presque toujours une cartographie macroscopique mais à jour à un document ultra-détaillé que personne n’entretient. Un schéma trop ambitieux au départ finit souvent abandonné, alors qu’une première version simple peut déjà servir aux équipes projet, à l’exploitation et au RSSI. Une fois la méthode posée, il faut encore savoir quoi faire ressortir en priorité pour la sécurité.
Ce que la cybersécurité doit faire ressortir en priorité
Quand j’analyse une cartographie avec un angle cyber, je cherche moins la beauté du schéma que ses zones de fragilité. Le but est de repérer rapidement les actifs critiques, les dépendances externes, les chemins d’administration et les points où une attaque pourrait provoquer un effet cascade. C’est là que la cartographie devient un vrai support de défense.
Les éléments à faire apparaître en priorité sont généralement les suivants:
- Les actifs critiques: base de données clients, ERP, annuaire d’identité, outils de paiement, sauvegardes.
- Les flux sensibles: API, échanges inter-applicatifs, synchronisations automatiques, flux vers des SaaS.
- Les accès à privilèges: comptes administrateurs, bastion, consoles cloud, droits d’exploitation.
- Les dépendances externes: prestataires, hébergeurs, éditeurs, connecteurs tiers, services de messagerie.
- Les mécanismes de résilience: sauvegarde, restauration, redondance, plan de continuité, bascule.
- Les localisations et zones d’exposition: datacenter, cloud, réseau interne, accès distants, site de secours.
Je garde aussi en tête deux notions souvent confondues. Le MCO, ou maintien en condition opérationnelle, désigne la capacité à faire fonctionner le SI sans interruption excessive. Le MCS, ou maintien en condition de sécurité, couvre les mesures qui évitent ou limitent les incidents de sécurité. Une cartographie efficace aide les deux: elle montre ce qu’il faut maintenir en service et ce qu’il faut protéger en premier. C’est justement là que beaucoup d’équipes se trompent.
Les erreurs qui la rendent vite obsolète
La plupart des cartographies inutiles échouent pour les mêmes raisons. Elles sont trop détaillées au départ, mal gouvernées ou coupées de la vie réelle du SI. Le problème n’est pas seulement technique; il est surtout organisationnel.
- Vouloir tout couvrir immédiatement. Le résultat devient lourd, coûteux à maintenir et inutilisable en exploitation.
- Confondre inventaire et vision. Une liste d’outils ne dit pas comment circule l’information ni où se situe le risque.
- Oublier les dépendances externes. Un service cloud ou un prestataire critique absent du schéma peut fausser toute l’analyse.
- Laisser le document hors du cycle de changement. À partir du moment où les projets évoluent sans mise à jour, la cartographie vieillit en silence.
- Ne pas nommer de responsable. Sans propriétaire, il n’y a ni version fiable, ni arbitrage, ni discipline de mise à jour.
Je conseille aussi de bannir les schémas “jolis mais inutilisables”, où tout est visuel mais rien n’est actionnable. Un bon schéma doit permettre de retrouver un flux, un composant ou un risque en quelques secondes. Cette exigence nous amène au dernier point, souvent sous-estimé: le niveau de détail vraiment utile au quotidien.
Le niveau de détail qui reste exploitable en audit comme en crise
Le réflexe le plus sain, à mes yeux, consiste à viser un référentiel unique par système d’information, daté, versionné et confié à une personne clairement identifiée. Il vaut mieux une seule cartographie bien tenue qu’une collection de schémas divergents qui racontent chacun une partie différente de la réalité. Il faut aussi pouvoir la consulter même quand le SI est dégradé, voire indisponible, sinon elle perd son intérêt au pire moment.
- Garder une cartographie par SI, au lieu de multiplier les copies.
- Associer une date, un numéro de version et un responsable de maintien.
- Rendre le document accessible aux bonnes personnes, avec un niveau de confidentialité adapté.
- Mettre à jour la cartographie à chaque changement majeur du système.
- Intégrer sa revue dans les projets d’évolution, les audits et les exercices de crise.
En pratique, je vise toujours le même équilibre: assez de détail pour agir, pas assez pour noyer la lecture. Une cartographie réussie ne sert pas seulement à documenter un SI; elle aide à décider, à expliquer et à réagir plus vite. Si elle remplit ces trois rôles sans ambiguïté, elle a trouvé son vrai niveau de maturité.
