En bref
Cartographier son SI, c’est en dresser une représentation claire — applications, données, infrastructure, processus, flux — pour pouvoir le piloter, le sécuriser et décider. Pas besoin de tout cartographier d’un coup : on commence là où le risque et les décisions se concentrent.
« Si ce serveur tombe, quelles activités s’arrêtent ? » — « Quelle application est maître de la donnée client ? ». Quand ces questions restent sans réponse rapide, le diagnostic est posé : le SI n’est pas cartographié. Sa connaissance vit dans la tête d’une ou deux personnes, et chaque décision — un changement, une panne, un projet — se prend un peu à l’aveugle.
À quoi sert une cartographie
Cartographier, ce n’est pas dessiner pour dessiner. Une cartographie du SI sert quatre objectifs très concrets : piloter (savoir ce qu’on a avant de décider quoi en faire) : une cartographie est le socle d’un schéma directeur, sécuriser (identifier les points critiques et les chemins d’attaque), décider (mesurer l’impact d’un changement avant de le lancer) et transmettre (partager une vision commune, ne plus dépendre d’une mémoire individuelle). C’est l’outil de base de la maîtrise du SI — et, de plus en plus, une attente réglementaire côté cybersécurité.
Les questions-test qui révèlent l’absence de cartographie
Nul besoin d’un audit lourd pour savoir où l’on en est : quelques questions simples suffisent. Si les réponses tardent ou divergent, la cartographie manque.
- Si ce serveur ou cette application tombe, quelles activités métier s’arrêtent ?
- Quelle application est maître de la donnée client — et laquelle ne fait que la recopier ?
- Par où transite l’information entre ces deux applications ?
- Qui a accès à quoi, et pour quelle raison ?
- Si cette personne part demain, quelle connaissance du SI part avec elle ?
Les cinq faces d’une cartographie
Une cartographie complète se lit sous plusieurs angles complémentaires. On n’est pas obligé de tous les traiter d’emblée, mais il est utile de savoir ce que chacun apporte.
| Face | Ce qu’elle décrit | La question à laquelle elle répond |
|---|---|---|
| Applicative | Les applications et leurs usages | « Avec quoi travaille-t-on ? » |
| Données | Où vivent les données clés, qui en est maître | « Où est la vérité sur cette donnée ? » |
| Infrastructure | Serveurs, réseau, hébergement | « Sur quoi tout cela repose-t-il ? » |
| Processus | Les processus métier et le SI qui les porte | « Qu’est-ce qui s’arrête si ça tombe ? » |
| Flux | La circulation de l’information entre applications | « Comment les briques se parlent-elles ? » |
Par où commencer
La première cartographie ne doit pas être exhaustive, elle doit être utile. On commence par le périmètre le plus critique — souvent les applications et les données qui portent l’activité — puis on l’enrichit. Un tableur bien tenu suffit pour démarrer ; un outil dédié devient pertinent quand le SI est vaste, évolue vite, ou doit répondre à des exigences de conformité. Deux références publiques pour cadrer la démarche : le Guide pour la cartographie du système d’information de l’ANSSI, qui propose une méthode en cinq étapes, et Mercator, un outil open source aligné sur ce guide. Faire appel à un regard extérieur — une mission de conseil en management informatique ou un DSI de transition — permet souvent d’obtenir une première carte exploitable en quelques semaines.
★ Mon retour d’expérience
Sur une mission d’audit, personne ne savait répondre à une question pourtant simple : « si ce serveur tombe, qu’est-ce qui s’arrête ? ». En construisant une cartographie légère — un tableur, quelques ateliers — deux choses sont apparues aussitôt : un serveur unique dont dépendaient plusieurs activités critiques, un point de défaillance que personne n’avait identifié ; et une ambiguïté sur la donnée client, gérée par deux applications sans que l’on sache laquelle faisait foi. La carte n’a rien créé de nouveau ; elle a rendu visible ce que tout le monde subissait sans le voir.
💡 Le piège : la carte parfaite qui ne voit jamais le jour
Vouloir tout cartographier, parfaitement, du premier coup, est le meilleur moyen de ne jamais commencer. Mieux vaut une carte partielle mais à jour qu’une carte exhaustive qui vieillit dans un tiroir. Cartographiez le critique d’abord, tenez la carte vivante, et étendez-la au fil des besoins.
Questions fréquentes
Excel ou un outil dédié pour cartographier son SI ?
Un tableur suffit pour une première cartographie, surtout en PME. Un outil dédié devient utile quand le SI est vaste, change souvent, ou doit servir à des audits et à la conformité.
Par quelle « face » commencer ?
Par celle qui porte le plus de risque et de décisions — le plus souvent l’applicative et les données. On étend ensuite vers l’infrastructure, les processus et les flux.
Existe-t-il des références publiques pour se lancer ?
Oui. Le Guide pour la cartographie du système d’information de l’ANSSI décrit une méthode en cinq étapes, et l’outil open source Mercator, aligné sur ce guide, permet de l’outiller sans investissement logiciel majeur.
Un SI à rendre lisible avant de décider ?
Arnaud Benistant
Fondateur et président d’Askee, cabinet de conseil en management des systèmes d’information en Auvergne-Rhône-Alpes. Fort de 20 ans d’expérience en SI, il a notamment été DSI de l’Entrepôt du Bricolage (Groupe SAMSE) avant d’accompagner dirigeants et directions comme DSI de transition. Sa conviction : derrière chaque projet IT, c’est presque toujours une question d’humain.
