Merci pour ton message et pour l’intérêt que tu portes au projet. N’hésitez pas à faire un retour une fois vos tests réalisés, je serai curieux de connaître tes scénarios d’usage.
Pour répondre à votre question : oui, l’IA fait partie des outils utilisés dans le cycle de développement. Il serait d’ailleurs difficile de prétendre le contraire. Aujourd’hui, plus aucun projet hébergé sur GitHub n’y échappe vraiment, que ce soit par l’éditeur, les outils d’analyse ou les services de la plateforme elle-même.
Dans le cas de ce projet, l’IA est utilisée principalement pour la vérification et la validation du code : relecture, détection d’erreurs, de failles potentielles ou d’incohérences. Les choix d’architecture, les décisions de conception et la responsabilité du code publié restent les miens. Chaque modification est relue et comprise avant d’être intégrée, et il en va de même pour les contributions externes : ce qui compte, c’est que le contributeur maîtrise et assume ce qu’il propose, quel que soit l’outil qui l’a aidé à l’écrire.
En revanche, je ne citerai pas les modèles ou agents utilisés : je ne souhaite faire la publicité d’aucun outil d’IA dans ce projet, d’autant que ces outils évoluent très vite et qu’une telle liste serait rapidement obsolète.
Bien vu sur les deux points. Les clés sont aujourd’hui montées par le noyau (lecture seule, noexec, seuls vfat/exfat/ntfs3/ext4 acceptés, racine dm-verity), ce qui limite les dégâts sans régler le problème : j’ajoute à la roadmap le montage via FUSE ou lklfuse dans le bac à sable des moteurs, voire dans une micro-VM jetable. Quant au reformatage, je l’ajoute en option : on recrée le système de fichiers et on n’y réécrit que les fichiers sains, pour que le poste suivant ne monte plus une structure fournie par l’attaquant.
Désactiver l'USB mass storage sur les postes, c'est effectivement la bonne approche, et c'est ce que je recommande aussi quand c'est possible. Mais même dans une organisation qui l'applique, il reste des cas où la clé USB est incontournable :
Les environnements industriels ou médicaux : automates, équipements IoT ou machines de production volontairement déconnectés du réseau. Pour leur pousser une mise à jour de firmware ou récupérer des logs, il n'y a pas de Teams ni de partage de fichiers. Il y a une clé USB, souvent apportée par un prestataire externe.
Les équipes infra : la configuration initiale d'un switch, d'un firewall ou d'un routeur se fait avant qu'il soit sur le réseau. On charge l'image ou la config depuis une clé, puisque l'équipement n'a pas encore de connectivité.
Le directeur ou le VIP qui arrive avec ses fichiers sur sa clé USB pour sa présentation au comité de direction. La politique dit non, mais en pratique on lui trouve toujours une exception… autant que cette exception passe par une borne plutôt que directement sur un poste.
La borne ne remplace pas la politique de blocage, elle traite les exceptions qu'on ne peut pas éviter.
Quant à ta borne qui ne marchait plus au bout de deux mois, c'est exactement le problème que je veux résoudre avec la nouvelle version : image système en lecture seule avec dm-verity, mises à jour atomiques A/B (si la mise à jour échoue, on revient à la version précédente), et mises à jour de signatures signées, y compris hors ligne pour les bornes isolées. Une borne qu'on installe et qu'on oublie, c'est une borne qui finit par ne plus servir. L'objectif est qu'elle reste fonctionnelle sans qu'un admin doive passer la voir tous les mois.
Oui, c'est prévu dès la conception. La Pandora-Box repose sur une architecture de moteurs en plugins : chaque moteur implémente une interface commune (un fichier en entrée, un verdict en sortie : sain, suspect, malveillant, erreur, ignoré). ClamAV, YARA-X, MalwareBazaar ou Hashlookup sont des plugins comme les autres. Ajouter un moteur supplémentaire revient donc à écrire un petit connecteur, sans toucher au cœur du projet. Les moteurs tournent en parallèle, et une politique d'agrégation configurable décide du verdict final (par exemple, un seul moteur positif suffit à bloquer).
Pour les antivirus commerciaux, c'est faisable dès que l'éditeur fournit sous Linux un scanner à la demande, en ligne de commande ou via un démon/SDK. Plusieurs éditeurs le proposent. Il faudra en revanche vérifier que la licence autorise l'usage sur une borne. Un plugin générique « commande externe », configurable sans écrire de code, serait une bonne piste pour faciliter ce type d'intégration.
Pour les EDR, c'est plus délicat. Leur valeur tient surtout à l'analyse comportementale et à la télémétrie remontée vers leur console, alors qu'une borne fait de l'analyse statique de fichiers, hors ligne. Beaucoup d'EDR n'exposent d'ailleurs pas de scan à la demande exploitable. Installer plusieurs agents propriétaires irait aussi à l'encontre des principes du projet : image minimale, durcie, sans réseau, avec chaque analyseur isolé dans une sandbox. La bonne approche serait d'intégrer le moteur de scan de l'éditeur plutôt que l'agent EDR complet.
Si tu as des produits précis en tête, n'hésite pas à ouvrir une issue sur GitHub : ça m'aidera à prioriser les connecteurs. Les contributions sont évidemment les bienvenues !
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: USB NoFuture
Posté par didierb . En réponse à la dépêche PandoraBox : la borne de décontamination USB. Évalué à 2 (+1/-0).
Recherche USB Rubber Ducky
[^] # Re: Usage de l'IA ?
Posté par didierb . En réponse à la dépêche PandoraBox : la borne de décontamination USB. Évalué à 5 (+4/-0).
Merci pour ton message et pour l’intérêt que tu portes au projet. N’hésitez pas à faire un retour une fois vos tests réalisés, je serai curieux de connaître tes scénarios d’usage.
Pour répondre à votre question : oui, l’IA fait partie des outils utilisés dans le cycle de développement. Il serait d’ailleurs difficile de prétendre le contraire. Aujourd’hui, plus aucun projet hébergé sur GitHub n’y échappe vraiment, que ce soit par l’éditeur, les outils d’analyse ou les services de la plateforme elle-même.
Dans le cas de ce projet, l’IA est utilisée principalement pour la vérification et la validation du code : relecture, détection d’erreurs, de failles potentielles ou d’incohérences. Les choix d’architecture, les décisions de conception et la responsabilité du code publié restent les miens. Chaque modification est relue et comprise avant d’être intégrée, et il en va de même pour les contributions externes : ce qui compte, c’est que le contributeur maîtrise et assume ce qu’il propose, quel que soit l’outil qui l’a aidé à l’écrire.
En revanche, je ne citerai pas les modèles ou agents utilisés : je ne souhaite faire la publicité d’aucun outil d’IA dans ce projet, d’autant que ces outils évoluent très vite et qu’une telle liste serait rapidement obsolète.
[^] # Re: Filesystem monté par Linux ?
Posté par didierb . En réponse à la dépêche PandoraBox : la borne de décontamination USB. Évalué à 2 (+1/-0). Dernière modification le 19 octobre 2026 à 18:14.
Bien vu sur les deux points. Les clés sont aujourd’hui montées par le noyau (lecture seule, noexec, seuls vfat/exfat/ntfs3/ext4 acceptés, racine dm-verity), ce qui limite les dégâts sans régler le problème : j’ajoute à la roadmap le montage via FUSE ou lklfuse dans le bac à sable des moteurs, voire dans une micro-VM jetable. Quant au reformatage, je l’ajoute en option : on recrée le système de fichiers et on n’y réécrit que les fichiers sains, pour que le poste suivant ne monte plus une structure fournie par l’attaquant.
[^] # Re: USB NoFuture
Posté par didierb . En réponse à la dépêche PandoraBox : la borne de décontamination USB. Évalué à 9 (+8/-0).
Désactiver l'USB mass storage sur les postes, c'est effectivement la bonne approche, et c'est ce que je recommande aussi quand c'est possible. Mais même dans une organisation qui l'applique, il reste des cas où la clé USB est incontournable :
La borne ne remplace pas la politique de blocage, elle traite les exceptions qu'on ne peut pas éviter.
Quant à ta borne qui ne marchait plus au bout de deux mois, c'est exactement le problème que je veux résoudre avec la nouvelle version : image système en lecture seule avec
dm-verity, mises à jour atomiques A/B (si la mise à jour échoue, on revient à la version précédente), et mises à jour de signatures signées, y compris hors ligne pour les bornes isolées. Une borne qu'on installe et qu'on oublie, c'est une borne qui finit par ne plus servir. L'objectif est qu'elle reste fonctionnelle sans qu'un admin doive passer la voir tous les mois.[^] # Re: Flexibilité dans les moteurs utilisés
Posté par didierb . En réponse à la dépêche PandoraBox : la borne de décontamination USB. Évalué à 8 (+7/-0).
Oui, c'est prévu dès la conception. La Pandora-Box repose sur une architecture de moteurs en plugins : chaque moteur implémente une interface commune (un fichier en entrée, un verdict en sortie : sain, suspect, malveillant, erreur, ignoré). ClamAV, YARA-X, MalwareBazaar ou Hashlookup sont des plugins comme les autres. Ajouter un moteur supplémentaire revient donc à écrire un petit connecteur, sans toucher au cœur du projet. Les moteurs tournent en parallèle, et une politique d'agrégation configurable décide du verdict final (par exemple, un seul moteur positif suffit à bloquer).
Pour les antivirus commerciaux, c'est faisable dès que l'éditeur fournit sous Linux un scanner à la demande, en ligne de commande ou via un démon/SDK. Plusieurs éditeurs le proposent. Il faudra en revanche vérifier que la licence autorise l'usage sur une borne. Un plugin générique « commande externe », configurable sans écrire de code, serait une bonne piste pour faciliter ce type d'intégration.
Pour les EDR, c'est plus délicat. Leur valeur tient surtout à l'analyse comportementale et à la télémétrie remontée vers leur console, alors qu'une borne fait de l'analyse statique de fichiers, hors ligne. Beaucoup d'EDR n'exposent d'ailleurs pas de scan à la demande exploitable. Installer plusieurs agents propriétaires irait aussi à l'encontre des principes du projet : image minimale, durcie, sans réseau, avec chaque analyseur isolé dans une sandbox. La bonne approche serait d'intégrer le moteur de scan de l'éditeur plutôt que l'agent EDR complet.
Si tu as des produits précis en tête, n'hésite pas à ouvrir une issue sur GitHub : ça m'aidera à prioriser les connecteurs. Les contributions sont évidemment les bienvenues !
[^] # 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.
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.
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.
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.
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.
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.
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é à 4.
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.