Mercator est un outil de cartographie du SI : il modélise les assets (applications, serveurs, réseaux, données…), leurs dépendances et leur exposition aux risques. Il répondra aux exigences NIS2 liées à l'inventaire et à la connaissance du SI (art. 21 – mesures de gestion des risques).
Deming est un outil de gestion de la conformité : il pilote les mesures de sécurité, les plans d'action, les audits et les indicateurs. Il couvre la partie gouvernance et suivi de la conformité, qui est aussi au cœur de NIS2.
Les deux sont complémentaires, pas redondants :
Mercator te dit ce qui existe et comment c'est utilisé
Deming te dit ce que tu fais pour le sécuriser et comment tu le prouves
Des liens entre les deux sont clairement envisagés dans la roadmap : l'idée est que les actifs cartographiés dans Mercator puissent être référencés dans Deming, pour ancrer les mesures de conformité sur des assets réels plutôt que sur des abstractions.
Si NIS2 est ton objectif principal, les deux outils ensemble te donnent une couverture solide — mais tu peux très bien commencer par Mercator seul pour structurer ton inventaire, puis brancher Deming pour la partie conformité.
Ah, permettez-moi de vous éclairer (c'est le chat qui parle) !
Ce chien n'est pas n'importe quel toutou : c'est le gardien du SMSI. Et comme tout bon gardien qui se respecte, il ne fait pas le tour du périmètre à pied comme les autres — il survole l'ensemble du système de management depuis les airs.
La casquette et les lunettes ? Ce sont des lunettes d'aviateur. Notre mascotte est un pilote. Pendant que les équipes ont la tête dans le guidon à traiter leurs non-conformités et leurs plans de traitement des risques, lui observe le SMSI d'en haut, avec la sérénité de celui qui a une vue à 360° sur toute l'organisation.
C'est une posture que tout bon RSSI reconnaîtra immédiatement.
Quant à la référence culturelle… disons que l'aviateur-chien le plus célèbre de la culture populaire est un certain Snoopy qui rêvait de combats aériens depuis le toit de sa niche. Ce logo est en réalité une déclaration d'intention : gérer un SMSI ISO 27001, c'est aussi un peu rêver en grand.
Sur Excel/ODS/CSV : le format XLSX a été retenu pour l'import des référentiels car il permet de structurer plusieurs feuilles, d'y inclure des métadonnées et des listes de validation en un seul fichier, ce qui simplifie la distribution des référentiels. Cela dit, l'idée d'un import ODS est une suggestion pertinente — n'hésite pas à ouvrir une issue sur GitHub, les contributions sont les bienvenues !
Sur le nom : le choix de « Deming » est effectivement un clin d'œil assumé à la roue de Deming et au cycle PDCA — planifier, mettre en œuvre, vérifier, améliorer — qui est précisément la colonne vertébrale d'un SMSI selon ISO 27001. C'est un homonyme voulu, pas subi 😄. Pour les recherches, « Deming SMSI » ou « Deming ISMS » lève l'ambiguïté assez rapidement.
Sur le tag GRC : il s'agit bien ici de Governance, Risk & Compliance, acception très répandue dans le monde de la cybersécurité et du management des risques. La cohabitation avec la Gestion de la Relation Client est en effet source de confusion, mais c'est malheureusement un faux-ami bien installé dans les deux communautés.
Sur les questions de la dépêche précédente : tu as tout à fait raison de le signaler, je vais y répondre sans tarder !
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.
Sur la comparaison avec une CMDB type ServiceNow :
Ce que Mercator fait différemment (et en mieux pour ce cas d'usage) :
Il est structuré autour des 5 vues cartographiques ANSSI (écosystème, métier, applicatif, administration, infrastructure), ce que ServiceNow ne fait pas nativement
Il modélise les dépendances entre couches (application → serveur logique → serveur physique → réseau), pas seulement un inventaire à plat
Il intègre la conformité ANSSI avec scoring, et l'IRN (Indice de Résilience Numérique)
Il est pensé pour le RSSI, pas pour l'ITSM
Ce que ServiceNow fait que Mercator ne fait pas :
Gestion des tickets / incidents / changements (c'est un outil ITSM complet)
Découverte automatique du parc (Mercator s'appuie sur GLPI ou des imports pour ça)
Workflows et automatisations métier
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.
Nous l'avons fait à partir de fichiers CSV et de la commande "LOAD DATA" de MySQL. Il est prévu de mettre en place des REST API pour faciliter l'importation.
Cet outil a été développé bénévolement afin de répondre à un besoin qu'ont les OIV de maîtriser leur système d'information. Il est utilisé dans plusieurs établissements hospitalier afin de maintenir leur cartographie à jour.
La mise en place d'un outil unique de cartographie permet d'avoir une vue globale de l’ensemble des éléments qui constituent le système d’information pour d’obtenir une meilleure lisibilité, et donc un meilleur contrôle.
[^] # Re: Deming versus Mercator
Posté par didierb . En réponse à la dépêche Deming — un SMSI Open Source par et pour des RSSI. Évalué à 2 (+1/-0).
Bonne question !
Voici comment les deux outils se complètent :
Mercator est un outil de cartographie du SI : il modélise les assets (applications, serveurs, réseaux, données…), leurs dépendances et leur exposition aux risques. Il répondra aux exigences NIS2 liées à l'inventaire et à la connaissance du SI (art. 21 – mesures de gestion des risques).
Deming est un outil de gestion de la conformité : il pilote les mesures de sécurité, les plans d'action, les audits et les indicateurs. Il couvre la partie gouvernance et suivi de la conformité, qui est aussi au cœur de NIS2.
Les deux sont complémentaires, pas redondants :
Des liens entre les deux sont clairement envisagés dans la roadmap : l'idée est que les actifs cartographiés dans Mercator puissent être référencés dans Deming, pour ancrer les mesures de conformité sur des assets réels plutôt que sur des abstractions.
Si NIS2 est ton objectif principal, les deux outils ensemble te donnent une couverture solide — mais tu peux très bien commencer par Mercator seul pour structurer ton inventaire, puis brancher Deming pour la partie conformité.
[^] # Re: Conseil cosmétique subjectif
Posté par didierb . En réponse à la dépêche Deming — un SMSI Open Source par et pour des RSSI. Évalué à 3 (+2/-0).
Ah, permettez-moi de vous éclairer (c'est le chat qui parle) !
Ce chien n'est pas n'importe quel toutou : c'est le gardien du SMSI. Et comme tout bon gardien qui se respecte, il ne fait pas le tour du périmètre à pied comme les autres — il survole l'ensemble du système de management depuis les airs.
La casquette et les lunettes ? Ce sont des lunettes d'aviateur. Notre mascotte est un pilote. Pendant que les équipes ont la tête dans le guidon à traiter leurs non-conformités et leurs plans de traitement des risques, lui observe le SMSI d'en haut, avec la sérénité de celui qui a une vue à 360° sur toute l'organisation.
C'est une posture que tout bon RSSI reconnaîtra immédiatement.
Quant à la référence culturelle… disons que l'aviateur-chien le plus célèbre de la culture populaire est un certain Snoopy qui rêvait de combats aériens depuis le toit de sa niche. Ce logo est en réalité une déclaration d'intention : gérer un SMSI ISO 27001, c'est aussi un peu rêver en grand.
[^] # Re: simple fichier Excel ?
Posté par didierb . En réponse à la dépêche Deming — un SMSI Open Source par et pour des RSSI. Évalué à 10 (+9/-0).
Sur Excel/ODS/CSV : le format XLSX a été retenu pour l'import des référentiels car il permet de structurer plusieurs feuilles, d'y inclure des métadonnées et des listes de validation en un seul fichier, ce qui simplifie la distribution des référentiels. Cela dit, l'idée d'un import ODS est une suggestion pertinente — n'hésite pas à ouvrir une issue sur GitHub, les contributions sont les bienvenues !
Sur le nom : le choix de « Deming » est effectivement un clin d'œil assumé à la roue de Deming et au cycle PDCA — planifier, mettre en œuvre, vérifier, améliorer — qui est précisément la colonne vertébrale d'un SMSI selon ISO 27001. C'est un homonyme voulu, pas subi 😄. Pour les recherches, « Deming SMSI » ou « Deming ISMS » lève l'ambiguïté assez rapidement.
Sur le tag GRC : il s'agit bien ici de Governance, Risk & Compliance, acception très répandue dans le monde de la cybersécurité et du management des risques. La cohabitation avec la Gestion de la Relation Client est en effet source de confusion, mais c'est malheureusement un faux-ami bien installé dans les deux communautés.
Sur les questions de la dépêche précédente : tu as tout à fait raison de le signaler, je vais y répondre sans tarder !
[^] # Re: Cartographie cloud
Posté par didierb . En réponse à la dépêche Mercator — Cartographie de SI Open Source. É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.
[^] # Re: Cartographie cloud
Posté par didierb . En réponse à la dépêche Mercator — Cartographie de SI Open Source. É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: Choix du metamodele?
Posté par didierb . En réponse à la dépêche Mercator — Cartographie de SI Open Source. É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: Des screenshots !
Posté par didierb . En réponse à la dépêche Mercator — Cartographie de SI Open Source. É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.
[^] # Re: Évolution
Posté par didierb . En réponse à la dépêche Deming : gestion de votre système de management de la sécurité de l'information Open Source. Évalué à 3.
L'outil va encore évoluer dans les mois et années à venir grâces aux excellentes idées d'amélioration proposées par les utilisateurs !
[^] # Re: intéressant
Posté par didierb . En réponse à la dépêche Mercator - La cartographie du système d’information. Évalué à 0.
Nous l'avons fait à partir de fichiers CSV et de la commande "LOAD DATA" de MySQL. Il est prévu de mettre en place des REST API pour faciliter l'importation.
[^] # Re: windows?
Posté par didierb . En réponse à la dépêche Mercator - La cartographie du système d’information. Évalué à 1.
Cela ne devrait pas poser de problèmes. Il n'y a rien de spécifique à Linux dans le code.
[^] # Re: intéressant
Posté par didierb . En réponse à la dépêche Mercator - La cartographie du système d’information. Évalué à 5.
Cet outil a été développé bénévolement afin de répondre à un besoin qu'ont les OIV de maîtriser leur système d'information. Il est utilisé dans plusieurs établissements hospitalier afin de maintenir leur cartographie à jour.
La mise en place d'un outil unique de cartographie permet d'avoir une vue globale de l’ensemble des éléments qui constituent le système d’information pour d’obtenir une meilleure lisibilité, et donc un meilleur contrôle.