La cartographie du SI consiste à représenter, de façon lisible et partagée, les composants de votre système d’information et les liens qui les unissent. Applications, serveurs, flux de données, processus métiers : tout y figure, avec ce qui dépend de quoi. Sans cette vue d’ensemble, chaque migration réserve sa part de surprises. Avec elle, en revanche, vos arbitrages s’appuient sur une connaissance réelle du terrain.
En bref
- La cartographie du SI décrit trois niveaux (métier, applicatif et technique) et surtout les liens entre eux.
- Elle réduit les angles morts, prépare les projets et sert de socle à la sécurité.
- Commencez par les applications critiques, puis élargissez le périmètre.
- Sans responsable de la mise à jour, une cartographie vieillit vite.
- Dans Isi-Informatique, « Ma Cartographie » et « Mes interfaces » dessinent le portefeuille et les flux à partir de vos fiches applications.
Qu’est-ce que la cartographie du SI ?
La cartographie du SI est une représentation structurée du système d’information d’un organisme. Elle ne se limite pas à un inventaire de serveurs ou de logiciels. En effet, elle décrit surtout les relations entre les composants : quelles applications échangent des données, quels processus métiers s’appuient sur quels outils, quelles équipes dépendent de quels services.
On distingue généralement plusieurs niveaux de lecture. Au niveau métier, on décrit les processus et les acteurs. Le niveau applicatif recense ensuite les logiciels et leurs interactions. Enfin, la couche technique couvre l’infrastructure : serveurs, réseaux, hébergements. Chaque niveau répond à un besoin différent. C’est pourquoi la cartographie gagne à les articuler plutôt qu’à les traiter séparément.
Cette démarche s’inscrit dans ce que les professionnels appellent l’urbanisation du SI. L’idée consiste à organiser le système d’information comme on planifie une ville, avec des zones, des règles de circulation et des interfaces claires entre quartiers. Par ailleurs, l’ANSSI publie un guide consacré à la cartographie du système d’information, avec une méthode et des vues types dont vous pouvez vous inspirer.
Pourquoi la cartographie du SI est indispensable
Un SI non cartographié ressemble à une ville sans plan cadastral. Les services s’accumulent, les doublons se multiplient et personne ne sait vraiment ce qui dépend de quoi. La cartographie du SI répond donc à plusieurs enjeux très opérationnels.
Réduire les angles morts
Sans représentation formalisée, certaines applications restent dans l’ombre. Il peut s’agir d’un outil adopté par un service sans validation de la DSI, ou d’un flux de données que personne n’a jamais documenté. Bien souvent, c’est une panne qui révèle leur existence. La cartographie fait donc apparaître ces angles morts avant qu’ils ne deviennent des incidents.
Préparer les projets de transformation
Toute migration ou tout changement d’outil commence par la même question : qu’est-ce que ce changement va toucher ? La cartographie du SI fournit la réponse. Elle permet notamment d’anticiper les impacts sur les autres applications et d’identifier les flux à reconfigurer. Ainsi, vous estimez la complexité réelle d’un projet avant de le lancer, et non pendant.
Sécuriser le SI
La sécurité d’un système d’information repose en partie sur la connaissance de sa surface d’exposition. Or, personne n’applique de politique de mise à jour à un composant dont il ignore l’existence. Le guide d’hygiène informatique de l’ANSSI fait d’ailleurs de la cartographie le premier pas vers une meilleure connaissance du SI. Elle constitue donc un préalable à toute démarche sérieuse de cybersécurité ou de conformité, comme la directive NIS 2 dans les ESMS.
Faciliter la gouvernance
Directions générales, comités de pilotage, auditeurs : tous attendent une vision claire du SI. La cartographie fournit ce langage commun entre la DSI et les autres directions. Autrement dit, elle traduit la complexité technique en schémas qu’un non-spécialiste peut lire et discuter.
Les composants d’une cartographie du SI réussie
Une cartographie du SI utile ne se résume pas à un schéma PowerPoint. Elle repose sur plusieurs éléments complémentaires, qu’il faut ensuite tenir à jour.
L’inventaire des applications
Le point de départ reste le recensement des applications en production. Pour chacune, notez son nom, son éditeur, sa version, son hébergement, sa criticité et les équipes qui l’utilisent. Cet inventaire applicatif constitue le socle de toute cartographie sérieuse ; sans lui, les autres niveaux restent incomplets. Notre article sur la gestion des applications détaille aussi ce volet.
La cartographie des flux
Les applications ne fonctionnent pas en silo. Par exemple, le logiciel RH alimente l’annuaire, tandis que l’outil de facturation dialogue avec la comptabilité. Représenter ces flux permet dès lors de comprendre les chaînes de dépendance. De même, vous repérez plus vite les points de fragilité, comme une interface que personne ne surveille.
Les acteurs et les processus
Chaque application sert un ou plusieurs processus métiers, portés par des équipes précises. Relier les outils aux processus et aux personnes donne ainsi à la cartographie sa dimension opérationnelle. C’est aussi à ce niveau que la DSI et les directions métiers trouvent un terrain de dialogue commun.
L’infrastructure et les hébergements
Serveurs physiques, machines virtuelles, services cloud, hébergements externalisés : la cartographie technique recense où tournent les applications et comment elles communiquent. Ce niveau intéresse surtout les équipes chargées de la continuité de service et de la sécurité. Il s’appuie en outre sur des données très terre à terre, comme les plans d’adressage IP ou les connexions internet de chaque site.
Comment conduire une démarche de cartographie du SI
La cartographie du SI n’est pas un projet ponctuel. Il s’agit plutôt d’une démarche continue : une phase de collecte d’abord, puis une structuration dans un référentiel, et enfin un entretien dans la durée.
Cadrer le périmètre et les objectifs
Avant de cartographier quoi que ce soit, définissez ce que vous cherchez à obtenir. En effet, une cartographie orientée cybersécurité ne ressemble pas à une cartographie destinée à préparer la fusion de deux entités. Arrêtez aussi le périmètre dès le départ (sites, services, couches techniques), faute de quoi le projet risque de s’étendre indéfiniment.
Collecter les données auprès des bonnes sources
Les données utiles ne se trouvent pas toutes au même endroit. Certaines viennent de la DSI, d’autres des directions métiers, des éditeurs ou des prestataires. Organisez donc des entretiens ciblés, puis exploitez les contrats et les bons de commande pour croiser les sources. De plus, un outil d’inventaire automatisé vous évite de saisir à la main ce que les postes et les serveurs remontent d’eux-mêmes. En fin de compte, la qualité de la cartographie dépend directement de la rigueur de cette collecte.
Choisir un niveau de granularité adapté
Une cartographie trop détaillée devient illisible et coûteuse à maintenir. À l’inverse, une cartographie trop sommaire ne sert à rien. Le bon niveau dépend de l’usage visé : une vue stratégique pour le comité de direction n’a pas besoin des mêmes détails qu’une vue destinée aux équipes techniques.
Faire vivre la cartographie du SI dans un référentiel
Un schéma figé dans un fichier bureautique vieillit mal. Préférez plutôt un référentiel structuré, que les équipes concernées consultent et complètent à chaque changement significatif : nouvelle application, migration ou retrait d’un service. Autrement dit, la cartographie n’a de valeur que si elle reflète la réalité du moment.
Impliquer les directions métiers
La DSI ne peut pas cartographier seule. Les directions métiers connaissent en effet leurs processus et leurs outils de terrain mieux que quiconque. Les associer dès la collecte évite les oublis majeurs. Leur implication facilite également l’adoption du référentiel une fois constitué.
Les pièges à éviter
Plusieurs erreurs reviennent régulièrement dans les projets de cartographie du SI. Les connaître à l’avance permet d’y échapper.
Vouloir tout cartographier d’un coup. La tentation est grande de produire une cartographie exhaustive dès la première itération. Or, cette ambition conduit à des projets qui s’éternisent et à des livrables trop lourds pour servir. Mieux vaut donc commencer par les applications critiques, puis élargir progressivement le périmètre.
Négliger la maintenance. Une cartographie juste le jour de sa livraison, puis jamais révisée, devient vite trompeuse. Prévoyez par conséquent un circuit de mise à jour dès le départ : qui valide les changements, à quelle fréquence et selon quelle procédure.
Confondre cartographie et documentation technique. La cartographie du SI s’adresse à des publics variés, pas seulement aux techniciens. Un directeur général ou un auditeur doit pouvoir la lire. Adaptez donc le niveau de détail et le format à chaque audience.
Sous-estimer la dimension humaine. La démarche met parfois en lumière des pratiques non officielles ou des responsabilités floues. Ces découvertes peuvent susciter des résistances. Traitez-les néanmoins comme des pistes d’amélioration plutôt que comme des fautes à sanctionner.
Cartographie du SI et CMDB : quelle différence ?
La CMDB (base de données de gestion des configurations) revient souvent dans les mêmes discussions que la cartographie du SI. Les deux notions se recoupent, sans pour autant se confondre.
La CMDB est un référentiel technique qui recense les éléments de configuration du SI : matériels, logiciels, licences et dépendances. Elle répond à une logique de gestion opérationnelle, notamment pour traiter les incidents et les changements. À l’inverse, la cartographie du SI adopte une perspective plus large. Elle intègre aussi les processus métiers, les acteurs et les enjeux stratégiques, et s’adresse ainsi à un public plus vaste.
La CMDB alimente donc utilement la cartographie. Ses données sur les équipements et les applications constituent par exemple une base de départ fiable. C’est le rôle que peut jouer Isi-Informatique, le module de gestion de parc et de CMDB d’Isi-APP. Son agent Isi-OCS remonte automatiquement l’inventaire des PC, serveurs et machines virtuelles, avec une synchronisation toutes les 4 heures. Le référentiel rassemble également les applications, les connexions internet, les plans d’adressage IP, les licences et les baies.
Visualiser votre cartographie du SI dans Isi-Informatique
Une fois vos applications recensées, encore faut-il les rendre lisibles. Isi-Informatique propose pour cela deux écrans dans son module Applications. Tous deux se construisent à partir des fiches applications que vous saisissez : domaine, statut, hébergement, interfaces. Autrement dit, le plan reflète la qualité de votre référentiel, ni plus ni moins.
« Ma Cartographie » : le plan du portefeuille applicatif
Accessible depuis le menu Application › Ma Cartographie, cet écran présente un bloc par domaine fonctionnel et une vignette par application. Chaque vignette résume ainsi l’essentiel :
- le statut de l’application, indiqué par la couleur de fond ;
- son éditeur, ou la mention d’un développement interne ;
- sa criticité ;
- son hébergement : cloud ou SaaS, serveur ou local ;
- le nombre d’interfaces et le nombre de licences achetées.
La légende placée sous le plan sert en outre de filtre : un clic sur une entrée n’affiche que les applications concernées. Vous pouvez aussi regrouper la vue par entité, ce qui devient pratique lorsque plusieurs établissements partagent le même référentiel. Enfin, le plan entier s’imprime en PDF.
« Mes interfaces » : le schéma des flux
Le second écran, « Mes interfaces », affiche dans sa vue Cartographie des cartes d’applications reliées par des flèches. Vous voyez donc d’un coup d’œil quelle application en alimente une autre. Ce schéma répond ainsi à une question que toute DSI se pose avant une migration ou pendant une panne : si cette application tombe, qui est touché ? Il s’exporte également en PDF, par exemple pour l’annexer à un dossier de comité de pilotage.
Ces deux vues relèvent de la cartographie applicative. Elles ne découvrent pas votre réseau et ne dessinent pas votre infrastructure. La couche technique reste donc décrite dans le référentiel, avec l’inventaire remonté par l’agent Isi-OCS, les plans d’adressage IP et les connexions internet.
Cartographie du SI et sécurité : un lien étroit
La cybersécurité et la cartographie du SI dépendent l’une de l’autre. D’une part, la cartographie aide à repérer les composants exposés, les flux non chiffrés ou les applications obsolètes. D’autre part, les exigences de sécurité, qu’elles viennent d’une politique interne ou d’un cadre réglementaire, donnent une raison concrète de la tenir à jour.
Une cartographie à jour nourrit aussi l’analyse de risques. Dans Isi-Informatique, par exemple, le volet sécurité SI propose une matrice d’analyse de risques avec plan d’actions. Notre replay 15 minutes Chrono consacré à l’analyse de risques NIS 2 montre comment structurer cette démarche.
La gestion des identités et des accès s’inscrit dans la même logique. Savoir qui accède à quoi, et avec quels droits, suppose de connaître précisément le périmètre applicatif. Une cartographie bien tenue facilite donc les revues d’accès et limite l’accumulation de droits excessifs. Sur ce point, Isi-Identité, le module de gestion des identités et des accès développé avec Youzer, complète le travail de cartographie. Sa réconciliation des listes d’utilisateurs aide notamment à maintenir les annuaires à jour.
Cartographie du SI en établissement de santé et en collectivité
Établissements de santé, ESMS et collectivités territoriales partagent un point commun : des SI très hétérogènes. De nombreuses applications métiers y coexistent, issues d’éditeurs différents et utilisées par des équipes aux profils variés.
Dans ce contexte, la cartographie du SI aide d’abord à rationaliser un paysage applicatif qui s’est construit par accumulation, un sujet que nous abordons dans notre article sur les DSI qui utilisent trop d’outils différents. Elle prépare ensuite les projets de mutualisation entre entités. Enfin, elle documente l’existant avant les démarches d’audit ou de mise en conformité.
Côté santé, le CERT Santé de l’Agence du numérique en santé propose également un kit de cartographie d’un SI, avec une démarche par étapes et des fiches techniques. Pour les communes, la question se pose aussi avec NIS 2 : notre article NIS 2 et collectivités précise lesquelles sont concernées.
Par où commencer votre cartographie du SI ?
La démarche peut sembler intimidante, surtout lorsque le SI s’est construit au fil des années sans plan d’ensemble. Pourtant, quelques actions simples suffisent à l’amorcer sans attendre des conditions idéales.
- Dressez la liste de toutes les applications en production, même les plus modestes.
- Pour chacune, identifiez qui l’utilise, à quel processus elle sert et qui en assure le support.
- Repérez les échanges de données entre applications, même informels.
- Classez les applications par criticité : lesquelles paralyseraient l’activité en cas de panne ?
- Désignez un responsable du référentiel et fixez une fréquence de révision.
Ces cinq étapes ne produisent pas une cartographie complète. En revanche, elles posent des fondations solides. Ensuite, chaque projet ou incident résolu viendra enrichir la représentation. Si vous partez de zéro en mairie, notre méthode d’inventaire du parc informatique en 5 étapes constitue un bon point d’entrée.
La cartographie du SI n’est pas une fin en soi. C’est un outil de pilotage, qui vous aide à décider en connaissance de cause plutôt qu’à l’aveugle.
Questions fréquentes
Qu’est-ce que la cartographie du SI ?
La cartographie du SI est une représentation structurée du système d’information d’un organisme. Elle recense les applications, les infrastructures, les flux de données et les processus métiers, en montrant les relations entre ces composants. Elle donne ainsi à la DSI et aux directions une vision claire et partagée pour piloter le SI.
Pourquoi faire une cartographie de son système d’information ?
Elle réduit les angles morts, aide à anticiper l’impact des projets et sert de base à la sécurité du SI. Sans elle, les décisions de migration ou d’investissement reposent sur une connaissance partielle, ce qui augmente le risque d’incidents et de surcoûts.
Quelle est la différence entre cartographie du SI et CMDB ?
La CMDB est un référentiel technique qui recense les éléments de configuration du SI : matériels, logiciels, licences et dépendances. La cartographie du SI adopte, en revanche, une perspective plus large, qui intègre aussi les processus métiers, les acteurs et les enjeux stratégiques. La CMDB alimente donc la cartographie en lui fournissant des données de base précises.
Comment maintenir une cartographie du SI à jour ?
Une cartographie perd sa valeur si personne ne la révise. Désignez un responsable de la mise à jour, fixez une fréquence de révision et prévoyez un circuit de validation pour chaque changement significatif : nouvelle application, migration ou retrait d’un service. Un référentiel structuré, accessible aux équipes concernées, facilite aussi cet entretien.
Par où commencer une cartographie du SI dans un établissement de santé ou une collectivité ?
Commencez par lister les applications en production, en précisant pour chacune les utilisateurs, le processus associé et le responsable du support. Identifiez ensuite les échanges de données entre applications, puis classez-les par criticité. Ces premières étapes posent les fondations d’une cartographie que vous enrichirez progressivement.