Quels contrôles ne pas supprimer lors de la réduction des outils

Par Alec Chizhik · 26 juin 2026 · 12 min de lecture

Un scénario classique : trois outils en moins, des coûts de licence sensiblement réduits, un service de contrôle de gestion satisfait. Six semaines plus tard, première alerte sérieuse. Un compte de service fait tourner les mots de passe la nuit, le mouvement traverse trois segments réseau. Dans le SIEM, les logs du pare-feu de l’outil périmétrique désactivé manquent à l’appel. La détection était là, mais pas la corrélation, car la source de logs n’a jamais été migrée vers la nouvelle plateforme lors du démantèlement. La consolidation permet de réaliser des économies. Mais elle ne doit pas emporter avec elle une fonction obligatoire.

Points clés

Les coûts sont un facteur légitime : Le paragraphe 30 de la loi fédérale sur la sécurité des technologies de l’information (BSIG) exige des mesures adaptées, proportionnées et efficaces, et mentionne explicitement les coûts de mise en œuvre comme critère. Réduire le nombre d’outils est donc autorisé. (Contexte DACH : le BSIG est la loi allemande encadrant la cybersécurité des opérateurs d’importance vitale et des infrastructures critiques.)
La loi ne connaît pas d’outils obligatoires : Le paragraphe 30 définit dix mesures minimales en tant que fonctions. Peu importe que l’authentification multifacteur (MFA) soit assurée par tel ou tel fournisseur : l’essentiel est qu’elle soit imposée.
Un contrôle est une fonction, un outil n’est que le véhicule : Qui désactive un outil sans migrer la fonction sous-jacente crée une faille de visibilité ou de conformité, qui apparaîtra lors d’un audit.
L’efficacité doit rester prouvée : Le paragraphe 30, alinéa 2, point 6, exige des concepts et procédures pour évaluer l’efficacité des mesures. Une consolidation sans preuve documentée constitue un point ouvert lors d’un contrôle.

Pourquoi le stack se réduit et où se situe la limite de conformité

Qu’est-ce que la consolidation du stack de sécurité ? La consolidation du stack de sécurité consiste à regrouper ou désactiver de manière ciblée des outils de sécurité afin de réduire les coûts de licence, les efforts d’intégration et le bruit des alertes. Plusieurs solutions individuelles sont ainsi intégrées dans une plateforme unique, par exemple en fusionnant la détection et la réponse au sein d’un stack combiné SIEM et EDR.

La pression en ce sens est bien réelle. Au fil des années, de nombreuses équipes de sécurité accumulent un véritable zoo d’outils, chacun apportant ses propres parseurs, interfaces et charges de maintenance. S’y ajoute la fatigue liée aux alertes : lorsque les équipes passent à côté de signaux réels noyés dans le bruit des fausses alertes, moins peut parfois signifier plus de sécurité. La consolidation s’impose donc souvent comme une décision judicieuse.

La loi ne s’y oppose pas. L’article 30, paragraphe 1, de la loi fédérale allemande sur la sécurité des systèmes d’information (BSIG) exige des mesures adaptées, proportionnées et efficaces, tout en mentionnant les coûts de mise en œuvre comme l’un des facteurs de proportionnalité, aux côtés de l’exposition aux risques, de la taille de l’organisation et des dommages potentiels. La pression sur les coûts est donc un argument recevable. La limite se situe ailleurs : le paragraphe 1 exige l’efficacité, tandis que le paragraphe 2, point 6, impose des concepts et des procédures pour évaluer cette efficacité. Réduire les dépenses est autorisé, mais désactiver un outil en perdant la fonction obligatoire qui y est associée viole l’obligation d’efficacité.

Un contrôle est une fonction, un outil n’est que le véhicule

L’erreur de raisonnement dans presque toute consolidation ratée est la même : on pense en termes de produits, pas de fonctions. Un contrôle est une capacité vérifiable, par exemple imposer l’authentification multifacteur (MFA) pour les comptes privilégiés, conserver les logs corrélables sur une période définie ou restaurer régulièrement un backup à titre de test. L’outil n’est que le support de cette capacité. La consolidation consiste à réduire le nombre de supports tout en conservant chaque capacité.

J’ai un jour hérité de deux scanners de vulnérabilités, l’un configuré de manière stricte, l’autre de façon plus laxiste. Pour des raisons de coûts, le plus cher a été supprimé. C’était justement le plus strict. Sur le papier, la gestion des vulnérabilités continuait, mais dans les faits, la couverture a diminué et les délais de réaction se sont allongés sans que personne ne s’en aperçoive. C’est ainsi qu’une faille se crée : l’arrêt en lui-même est anodin, mais c’est la réduction inaperçue de la profondeur des contrôles qui cause les dégâts.

Trois schémas reviennent systématiquement. Une source de logs disparaît, mais la règle de détection dans le SIEM (Security Information and Event Management) reste active et tourne dans le vide. Un EDR (Endpoint Detection and Response) couvre les postes de travail, mais après un changement d’outil, les serveurs ou les hôtes Linux se retrouvent sans agent. Ou encore, un contrôle strict est remplacé par un autre plus laxiste, comme une politique d’accès conditionnel par un simple VPN. Dans chaque cas, la fonction reste sur le papier, mais disparaît du terrain opérationnel.

Dix mesures obligatoires qu’aucune licence ne peut remplacer

Le paragraphe 30, alinéa 2 du BSIG (Bundesamt für Sicherheit in der Informationstechnik Gesetz – loi allemande sur la sécurité des technologies de l’information) énumère dix mesures minimales. Elles constituent la pierre de touche de toute décision de réduction des outils. Le tableau suivant traduit les principales exigences dans le langage opérationnel et précise ce qui doit être conservé lors d’un changement d’outil.

Contrôle obligatoire (paragraphe 30)	Outil typique	Réduction possible ?	Ce qui doit être conservé
Gestion des incidents de sécurité (n° 2)	SIEM, EDR/XDR, SOAR	Oui, si migration effectuée	Intégration de toutes les sources de logs, règles de détection, routage des alertes, playbooks, durées de conservation, capacité de signalement
Authentification multifacteur (MFA) et communication sécurisée (n° 10)	Entra ID, Okta, Duo	Oui, en cas de fusion des fournisseurs d’identité (IdP)	Politique obligatoire pour l’accès à distance et les comptes privilégiés, processus d’exception documenté
Acquisition, maintenance, gestion des vulnérabilités (n° 5)	Tenable, Qualys, Rapid7	Oui, si la couverture, la profondeur et les délais restent équivalents	Couverture complète des actifs, y compris le cloud, délais de correctifs, processus de signalement des vulnérabilités
Continuité d’activité et sauvegarde (n° 3)	Veeam, Rubrik, sauvegarde cloud	Oui, avec prudence	Restauration testée (et non pas seulement une sauvegarde réussie), immuabilité, RTO et RPO documentés
Sécurité du personnel, accès, actifs (n° 9)	IAM, CMDB	Partiellement	Cycle de vie des accès, accès privilégié, inventaire de tous les actifs à protéger
Évaluation de l’efficacité (n° 6)	Plateforme GRC, manuelle	Oui, outil interchangeable	Preuves mesurables, vue d’ensemble des KPI, historique des audits. Elle ne doit pas disparaître avec l’export de l’ancien outil

Deux points lient juridiquement ce tableau. Le paragraphe 30, alinéa 1 du BSIG exige que le respect de ces mesures soit documenté. Si les preuves dépendent d’un outil désactivé, une faille de conformité apparaît immédiatement. Pour les entreprises financières soumises à DORA (Digital Operational Resilience Act), cette réglementation européenne prime sur les obligations du BSIG en matière de gestion des risques ICT et de signalement des incidents. Une consolidation des outils ne change rien à ces exigences, seulement à leur mise en œuvre technique.

Cinq pièges qui apparaissent après le démantèlement

Les erreurs se révèlent rarement immédiatement. Elles surgissent lors du prochain incident ou du prochain audit, alors que le projet d’économies est déjà considéré comme terminé.

Interfaces orphelines. Un playbook d’automatisation appelle l’interface de programmation d’un outil désactivé. La détection fonctionne, mais la réaction reste en suspens. L’incident prend du retard précisément là où la rapidité est cruciale.

Sources de logs manquantes. Après la migration, les logs du pare-feu, du proxy, du cloud ou de l’identité ne sont pas réintégrés. La corrélation s’interrompt sans qu’aucune erreur ne soit visible. Résultat : plus rien n’arrive.

Contrôles redondants aux niveaux de sévérité différents. Deux chemins pour une même action, l’un plus strict que l’autre. Le plus coûteux est résilié, souvent sans avoir migré la politique de sécurité au préalable. Il ne reste plus que la version la moins rigoureuse, devenue le nouveau standard.

Preuves ancrées dans l’outil. Les rapports d’export, les justificatifs d’audit et les rapports de tests d’intrusion font référence à d’anciens noms de produits. L’auditeur demande des preuves de continuité, et la réponse fait défaut.

Évaluation d’efficacité sautée. La consolidation est cochée comme un projet terminé, sans vérification préalable de son efficacité avant et après. Manque alors la preuve exigée par les concepts et procédures visés au paragraphe 30, alinéa 2, point 6 (réglementation allemande sur la sécurité des systèmes d’information, imposant une documentation des mesures de protection).

La bonne méthode : l’inventaire des contrôles avant l’inventaire des outils

L’ordre dans lequel on procède détermine le résultat. Commencer par la liste des licences, c’est rogner sur les contrôles. Commencer par l’inventaire des contrôles, c’est optimiser les outils. Six étapes permettent de préserver la fonctionnalité, tandis que l’outil, lui, peut évoluer.

Premièrement : traduire chaque mesure obligatoire issue du paragraphe 30 en fonctions opérationnelles et en indicateurs mesurables, comme la part des actifs équipés d’un EDR, la couverture MFA des comptes administrateurs ou le temps moyen de détection. Deuxièmement : construire une matrice indiquant quel outil couvre quelle fonction, avec quel niveau de robustesse et pour quelle catégorie d’actifs. Troisièmement : n’autoriser le retrait d’un outil que lorsque ses fonctions sont entièrement reproduites et testées dans le système cible – et non pas simplement présentes sur le papier, selon la liste du fournisseur.

Quatrièmement : définir un chemin de migration pour chaque fonction obligatoire, de la redirection des logs aux règles de détection, en passant par les sauvegardes, le tout assorti d’un plan de repli. Cinquièmement : apporter la preuve de l’efficacité, avec une mesure avant/après, un test de restauration et un exercice d’incident simulé. Sixièmement : dater la documentation au moment de la migration du contrôle. Ce qui compte, c’est la date à laquelle la fonction a été transférée, et non celle de la résiliation de la licence. Pour les fonctions critiques comme la journalisation, l’EDR ou les sauvegardes, une période de fonctionnement en parallèle de quelques semaines s’avère judicieuse. Certes, cela engendre un coût à court terme, mais cela évite une phase d’aveuglement où personne ne sait si la détection reste opérationnelle.

Questions fréquentes

Chaque question est verrouillée. Un simple clic permet d’afficher la réponse.

Puis-je regrouper des outils de sécurité sous NIS2 et BSIG pour réduire les coûts ?

Oui. L’article 30, paragraphe 1 du BSIG (Bundesamt für Sicherheit in der Informationstechnik-Gesetz, loi allemande sur la sécurité des systèmes d’information) mentionne explicitement les coûts de mise en œuvre comme critère de proportionnalité. Cependant, les économies réalisées ne doivent pas entraîner la suppression d’une fonction obligatoire. Les mesures doivent rester efficaces, et cette efficacité doit être prouvée.

Quels contrôles de l’article 30 du BSIG sont liés à un outil spécifique ?

Aucun. La loi définit des mesures, pas des produits. L’authentification multifactorielle (MFA), la journalisation (logging), les sauvegardes (backup) et la gestion des vulnérabilités doivent fonctionner. Le choix du fournisseur relève de la mise en œuvre.

Que deviennent nos preuves d’audit si nous remplaçons notre SIEM ou notre plateforme GRC ?

Les preuves historiques doivent être archivées. À partir de la consolidation, de nouvelles preuves d’efficacité seront générées par l’outil cible. Une rupture dans cette chaîne posera problème lors de la présentation des preuves aux autorités de contrôle.

La réglementation DORA s’applique-t-elle à la place de NIS2 si nous sommes une entreprise financière ?

Pour la gestion des risques liés aux technologies de l’information et de la communication (TIC) et la notification des incidents majeurs, DORA (Digital Operational Resilience Act) prime en tant que droit spécial. Une consolidation des outils doit continuer à respecter les exigences du cadre de risque TIC.

Suggestions de lecture

Lecture recommandée
Le risque dans la chaîne d’approvisionnement : un programme, pas une liste d’audit

Lecture recommandée
NIS2 après l’échéance : le début du contrôle par le BSI

Lecture recommandée
Conformité NIS2 pour les PME : étapes réalisables et erreurs à éviter

Autres contenus du réseau MBF Media

Digital Chiefs
Géopolitique et feuille de route des datacenters : ce que les DSI doivent sécuriser dès maintenant

À propos de l'auteur Alec Chizhik

Alec est Chief Digital Officer chez Evernine et écrit sur les architectures cloud, la sécurité informatique et la pratique des opérations numériques.

Tous les articles →

Pour aller plus loin

Actualités · 21 juillet 2026

Un magazine d'Evernine Media GmbH