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

En septembre 2023, nous publiions une dépêche sur HCW@Home, notre logiciel libre de téléconsultation médicale sous licence GPL-3.0. Les retours avaient été nombreux et constructifs, et nous remercions chaleureusement la communauté.

Qu’est-ce que HCW@Home ?

HCW@Home (Healthcare Worker @Home) est un logiciel libre (GPLv3) de téléconsultation médicale, conçu pour permettre aux professionnels de santé de mener des appels vidéo avec leurs patients sans friction : la création d’un compte patient n’est pas nécessaire, un simple lien suffit pour rejoindre une consultation. Les comptes existent mais restent optionnels. Le logiciel intègre une salle d’attente virtuelle, la gestion des rendez-vous, l’échange de documents et de messages, et s’interface avec les systèmes SSO existants via OpenID Connect. Le projet est né d’une collaboration avec les Hôpitaux Universitaires de Genève et a permis des dizaines de milliers de consultations à distance pendant la crise du COVID. Il est aujourd’hui utilisé notamment par des organisations humanitaires comme MSF et le CICR.

Pourquoi une réécriture ?

La critique principale de la communauté était légitime : notre dépendance à MongoDB (licence SSPL, non reconnue comme libre par la FSF ni l’OSI) rendait l’ensemble de la stack discutable d’un point de vue copyleft. Des échanges avaient même eu lieu avec l’équipe de FerretDB, qui s’était manifestée directement sur la dépêche. Malgré leur bonne volonté, la migration n’avait pas été concluante à l’époque. Autre faiblesse pointée : une architecture difficile à maintenir sur le long terme.

Nous avons entendu tout cela.

HCW@Home v6 : réécriture from scratch

Grâce à un financement obtenu ces dernières années, nous avons pu reprendre le projet à zéro. Les changements majeurs :

• Backend : réécriture complète en Python/Django, avec l’interface d’administration native, une API REST et une architecture bien plus maintenable.
• Visioconférence : remplacement de l’ancienne solution par LiveKit (Apache 2.0), serveur WebRTC auto-hébergeable et extensible.
• Fonctionnalités disponibles en option, sans aucune dépendance à un service tiers : enregistrement des réunions, sous-titres en temps réel via Whisper, connectivité SIP.
• Calendrier : intégration CalDAV pour la gestion des rendez-vous.
• Côté praticien : mode Picture-in-Picture pendant les appels, gestion des suivis, possibilité de publier des créneaux de disponibilité que les patients peuvent ensuite réserver directement.
• Coté patient : nouveau tableau de bord permettant aux patients de faire une demande de consultation.

La solution est déployable via Docker Compose, Kubernetes ou paquet Debian, selon les préférences et contraintes de l’hébergeur.

Une convergence involontaire avec La Suite Numérique

En choisissant cette stack, nous avons sans le vouloir rejoint les mêmes choix techniques que La Suite Numérique, l’initiative open source de la DINUM (Direction interministérielle du numérique) visant à fournir aux agents de l’État français une alternative souveraine aux outils Microsoft et Google. Leur outil de visioconférence Meet repose en effet exactement sur la même combinaison Django + LiveKit + PostgreSQL qui est pour nous validation plutôt rassurante.