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: simple fichier Excel ?
Posté par didierb . En réponse à la dépêche Deming — un SMSI Open Source par et pour des RSSI. Évalué à 6 (+5/-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.