Si vous êtes RSSI, DSI ou architecte dans une entité concernée par NIS2, vous avez probablement reçu en 2024 ou 2025 une lettre de votre autorité de supervision vous rappelant poliment — mais fermement — que la cartographie de votre système d'information est désormais une obligation réglementaire. Pas une bonne pratique. Pas une recommandation. Une obligation.
NIS2 (transposée en droit national dans les pays membres de l'UE) impose aux entités essentielles et importantes de mettre en place des mesures de gestion du risque cyber, parmi lesquelles figure explicitement la connaissance et la documentation de son système d'information. L'ANSSI en France, le CSIRT Luxembourg, le BSI en Allemagne — tous y font référence. Sans cartographie, pas de gestion du risque sérieuse, pas d'analyse d'impact, pas de plan de continuité fiable.
C'est précisément le problème que Mercator tente de résoudre depuis plusieurs années, et le projet continue d'évoluer.
Qu'est-ce que Mercator ?
Mercator est un outil Open Source de cartographie du système d'information, sous licence GPL, développé en Laravel/PHP. Il est aligné sur le guide de cartographie de l'ANSSI et couvre sept vues complémentaires du SI : écosystème (fournisseurs, sous-traitants), processus métiers, applications, administration (annuaires, comptes à privilèges), infrastructure logique (réseaux, VLANs, flux), infrastructure physique (serveurs, baies, salles), et registre des traitements RGPD.
Le principe central est la navigation par dépendances : depuis n'importe quel objet de la cartographie, on peut remonter ou descendre la chaîne — d'un processus métier jusqu'aux équipements physiques qui le supportent, en passant par les applications et les réseaux intermédiaires. C'est ce qui transforme un inventaire statique en un outil opérationnel pour l'analyse d'impact, la détection de SPOF, la planification de la continuité d'activité.
Mercator calcule également un score de maturité de la cartographie (complétude et qualité des données), par domaine : gouvernance, protection, défense, résilience — directement exploitable pour les audits NIS2, ISO 27001 ou HDS.
Pourquoi cartographier son SI ?
La question peut sembler rhétorique sur LinuxFr, mais elle revient régulièrement en pratique : on sait à peu près ce qu'on a, on a un CMDB approximatif, ça suffira non ?
Non. Voici ce qu'une cartographie bien tenue permet concrètement :
- Identifier les SPOF avant l'incident, pas pendant
- Évaluer l'impact d'une panne ou d'un changement sur les processus métiers, y compris les dépendances croisées
- Répondre aux auditeurs avec des données structurées et non avec un classeur Excel maintenu à la main par une personne qui a changé de poste il y a dix-huit mois
- Qualifier les actifs critiques pour orienter les investissements en sécurité
- Documenter les flux de données pour la conformité RGPD
- Planifier les migrations en connaissant l'ensemble des dépendances applicatives
En résumé : vous ne pouvez pas protéger ce que vous ne connaissez pas. C'est trivial à énoncer, c'est encore courant comme situation en pratique.
Ce que Mercator n'est pas
Point important, car le marché des outils de cartographie et de GRC est traversé depuis quelques années par une lame de fond de fonctionnalités "IA" — parfois utiles, souvent cosmétiques, presque toujours opaques sur ce qui se passe avec vos données.
Mercator est entièrement gratuit sous licence GPL. Il n'y a ni modules cachés, ni limitations fonctionnelles, ni intelligence artificielle. Le code est sur GitHub, lisible, auditable, forkable. L'assistance communautaire passe par GitHub Issues et Discussions. C'est tout.
Nouveautés récentes
Les évolutions récentes portent notamment sur :
- Module BPMN 2.0 pour connecter les processus métiers à l'infrastructure technique, et répondre à la question "si ce serveur tombe, quels processus métiers sont affectés ?" en quelques secondes.
- Analyse des dépendances analyser les dépendances d'un objet en amont ou en aval et générer automatiquement le graphe de ses dépendances.
- Moteur de requêtes, écrivez vos propres requêtes sur la cartographie et générez un graphe ou une liste.
Quelques chiffres
- 500+ étoiles GitHub, 72 forks, déployé dans plus de 30 pays
- Utilisé dans des hôpitaux, grandes écoles, centres de recherche, administrations
- Meilleur Projet Open Source OW2 2024
- Présenté à SSTIC 2023, Hack.lu 2024, Voxxed Days 2025, FIC Lille, FOSDEM, BSides Luxembourg
Aller plus loin
- GitHub (221 clics)
- Documentation (123 clics)
- Site Web (468 clics)
- Discussions (36 clics)
# Des screenshots !
Posté par Dring . Évalué à 3 (+1/-0).
En plus de copies d’écran (j’en ai pas trouvé mais j’ai pas cherché longtemps, j’avoue), j’aimerais savoir comment ça se compare avec une CMDB type ServiceNow au moins pour la partie inventaire applicatif.
[^] # Re: Des screenshots !
Posté par didierb . Évalué à 3 (+2/-0).
Sur la comparaison avec une CMDB type ServiceNow :
Ce que Mercator fait différemment (et en mieux pour ce cas d'usage) :
Ce que ServiceNow fait que Mercator ne fait pas :
En résumé : ServiceNow est une CMDB orientée opérations IT, Mercator est une cartographie orientée sécurité et conformité. Les deux peuvent coexister — Mercator peut consommer des données issues de ServiceNow ou GLPI.
# Ouuuf
Posté par AlexTérieur . Évalué à 0 (+2/-3).
En voyant le nom "Mercator", je me suis dit… dans la cartographie (au sens strict du terme) on va se taper une nouvelle réforme… Or il n'en est rien. Juste un nouveau néologisme/abus de langage etc… comme on aime (dans l'informatique)… apparemment.
[^] # Re: Ouuuf
Posté par bobble bubble . Évalué à 1 (+0/-0).
Tu peux proposer un changement de nom, pourquoi pas "EqualEarth" ? ;)
[^] # Re: Ouuuf
Posté par blfpd . Évalué à 3 (+2/-0).
# Choix du metamodele?
Posté par Jean-Baptiste Sarrodie . Évalué à 5 (+5/-0).
Bonjour et merci pour la news. Savez-vous ce qui a motivé l'utilisation d'un metamodel spécifique plutôt que la réutilisation d'un standard comme ArchiMate qui est par ailleurs utilisé au niveau européen pour differents besoins? Un tel choix aurait l'avantage de l'ouverture avec en prime un format d'échange standard permettant l'interoperabilite avec d'autres outils du marché (opensource ou commercial).
[^] # Re: Choix du metamodele?
Posté par didierb . Évalué à 10 (+9/-0).
Très bonne question, et le sujet mérite une réponse honnête.
Le choix du métamodèle est directement dicté par le guide de cartographie de l'ANSSI, qui définit ses propres vues et objets (entité métier, application, serveur logique, réseau, etc.). Mercator en est une implémentation directe — l'objectif premier était de fournir un outil clé en main pour les RSSI francophones souhaitant se conformer aux recommandations ANSSI, notamment dans le cadre de NIS2.
ArchiMate est effectivement mentionné dans la documentation, et les correspondances avec les vues Mercator existent — les concepts sont proches. Mais ArchiMate dans sa complétude est un standard riche et complexe, souvent perçu comme une barrière à l'adoption pour des équipes sécurité qui ne sont pas architectes d'entreprise.
Sur l'interopérabilité, le point est légitime : Mercator expose une API REST complète qui permet l'échange de données avec d'autres outils, et des imports/exports CSV sont disponibles. Ce n'est pas un format d'échange standardisé au sens ArchiMate/TOGAF, je le concède.
L'intégration d'un export ArchiMate (format .archimate ou XML Exchange Format) est quelque chose qui a été évoqué — si c'est un besoin qui te concerne, n'hésite pas à ouvrir une issue sur GitHub pour qu'on puisse évaluer la demande.
[^] # Re: Choix du metamodele?
Posté par Jean-Baptiste Sarrodie . Évalué à 7 (+7/-0).
Je n'ai pas un besoin direct à titre personnel, mais il se trouve que je suis le Chair du forum ArchiMate à l'Open Group, et par conséquent, je vois cela comme une opportunité de créer des liens entre différentes communautés. Par exemple le SABSA Institute qui a créé la norme du même nom qui traite de la sécurité des systèmes d'information utilise ArchiMate.
Je rencontre souvent des organismes ou entreprises qui ont cet a priori, alors qu'ArchiMate est un standard qui peut être mis en oeuvre très simplement. Je vais peut-etre essayer de me rapprocher de l'ANSSI pour voir ce qu'il serait possible de faire comme travaux conjoints.
Un peu off topic, mais la nouvelle version du standard Archimate (la version 4) a été officialisée cette semaine, et elle simplifie justement le langage (30% de types de concepts en moins).
[^] # Re: Choix du metamodele?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Est-ce qu'il existe un autre modeleur que Archi en open source (véritable, pas de open core ou fauxpensource) pour Archimate ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Choix du metamodele?
Posté par oliboub . Évalué à 2 (+2/-0).
Bonjour Jean-Baptiste,
C'est un sujet que j'avais évoqué sur la communauté mercator il ya quelques mois.
Ce que Didier ne mentionne pas, c'est que Mercator à une très bonne interface API, ou l'on peut collecter, modifier et créé n'importe quel élément:
https://dbarzin.github.io/mercator/fr/api/
J'ai fait à l'époque (avec l'aide de l'ia), un outil en python qui permet de convertir le contenu de la base mercator en fchier xml pour archi tools.
petit exemple en copie d'écran:
https://github.com/dbarzin/mercator/issues/1930
Si besoin, je peux me replonger dedans, metre à jour les api modifiées dernièrement, et mettre le source sur la communauté mercator.
La plus grosse difficulté a été le format xml de architools :)
# Cartographie cloud
Posté par Ant . Évalué à 1 (+0/-0).
ok mais, et pour cartographier les ressources qu'on utilise sur le cloud ?
[^] # Re: Cartographie cloud
Posté par didierb . Évalué à 1 (+0/-0).
Mercator permet également de faire la cartographie de vos ressources utilisées dans le cloud. Le cloud, c'est juste l'ordinateur de quelqu'un d'autre.
[^] # Re: Cartographie cloud
Posté par Ant . Évalué à 4 (+3/-0).
Au temps pour moi, je pensais particulièrement aux ressources éphémères ou serverless, pods, kubernetes et autres. On me dit que ce n'est pas la peine de les cartographier, elles n'ont pas de CID. Pourtant, elles ont une criticité, des dépendances, etc. Comment est-ce que vous traitez le sujet ?
[^] # Re: Cartographie cloud
Posté par cg . Évalué à 3 (+1/-0).
Tu cartographies le service ou le déploiement, et non l'instance particulière ?
C'est pas forcément trivial à représenter, en effet. Comment dire "ce truc est déployé via tel code (une conf Terraform par exemple), a temporairement telle forme, mais n'est pas un actif précis".
[^] # Re: Cartographie cloud
Posté par Ant . Évalué à 2 (+1/-0).
L'instance ne peut pas véritablement se cartographier il me semble, vu qu'elle est éphémère, et d'ailleurs à quoi ça servirait ? Je pensais plutôt à un système de labellisation à mettre au déploiement permettant d'identifier par exemple l'usage de la ressource et sa criticité, à partir de là je peux définir des relations avec d'autres déploiements, les référencer dans un tableau d'actifs, etc
Cela étant, je ne l'ai jamais moi-même mis en oeuvre ni vu mettre en oeuvre, c'est pour cela que je suis preneur d'autres avis.
[^] # Re: Cartographie cloud
Posté par cg . Évalué à 3 (+1/-0).
Je ne me suis pas exprimé clairement, on dit la même chose :). C'était plus clair en disant : "En cartographiant le service ou le déploiement, et non l'instance particulière ?"
[^] # Re: Cartographie cloud
Posté par didierb . Évalué à 3 (+2/-0).
Merci pour vos remarques, c'est très inspirant ! Je vous invite à venir partager vos idées et à discuter de ce sujet sur le GitHub du projet.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.