Mercredi, 9h30. Le RSSI reçoit deux demandes dans la même matinée. La première vient d'un développeur senior, qui demande quel référentiel suivre pour sécuriser une nouvelle API avant sa mise en production. La seconde vient de la direction juridique, qui demande si l'entreprise est en mesure de démontrer sa conformité à NIS2 avant le prochain contrôle de l'ANSSI.

Deux questions qui contiennent le mot référentiel, et qui pourtant n'appellent pas la même réponse. La première porte sur une méthode technique pour construire quelque chose de sécurisé. La seconde porte sur une obligation réglementaire qu'il faut pouvoir prouver. Confondre les deux familles de référentiels, ou pire, essayer de répondre à l'une avec l'outil prévu pour l'autre, est l'une des sources de confusion les plus fréquentes dans la gestion d'un programme de cybersécurité.

Un référentiel cybersécurité est un cadre de référence structuré qui sert soit à guider concrètement la sécurisation d'un système (référentiel technique), soit à encadrer et à prouver une conformité réglementaire (référentiel de conformité). Distinguer ces deux familles est la condition pour piloter correctement un programme de cybersécurité.

• Les référentiels cyber se répartissent en deux familles distinctes : les référentiels techniques et méthodologiques (OWASP, MITRE ATT&CK, CIS Controls, NIST CSF, PTES), et les référentiels de conformité réglementaire (NIS2, DORA, ISO 27001, RGPD).

• Les premiers répondent à la question « comment sécuriser concrètement », les seconds répondent à la question « comment prouver qu'on est sécurisé ».

• Un référentiel technique guide une action (corriger une faille, durcir une configuration). Un référentiel de conformité exige une preuve (documentation, traçabilité, audit).

• L'automatisation est puissante sur la collecte de preuves et le suivi continu des écarts, mais reste limitée sur l'interprétation contextuelle et la décision de gouvernance.

• Combiner les deux familles dans une même démarche, plutôt que les traiter séparément, est ce qui transforme la conformité en sous-produit d'une bonne maîtrise opérationnelle.

Les référentiels techniques répondent à une question d'ingénieur : comment faire, précisément, pour qu'un système, une application ou une organisation résiste à une attaque donnée. Ce sont des référentiels qui décrivent des mécanismes, des contrôles ou des méthodologies, indépendamment de toute obligation légale.

OWASP structure la sécurité applicative autour de risques identifiés et documentés, comme on l'a détaillé dans notre article sur le Top 10 OWASP:2025. OWASP s'utilise au moment de concevoir, développer ou auditer une application : un développeur qui code une fonctionnalité d'authentification consulte directement les recommandations OWASP sur ce risque précis.

MITRE ATT&CK cartographie les tactiques, techniques et procédures réellement observées chez les attaquants, organisées en matrice. MITRE ATT&CK s'utilise pour structurer une démarche de détection ou de threat intelligence : un analyste SOC qui investigue un comportement suspect peut le rattacher à une technique ATT&CK précise pour comprendre où l'attaquant se situe dans sa progression.

CIS Controls propose une liste hiérarchisée de mesures de sécurité concrètes, des plus basiques (inventaire des actifs) aux plus avancées (tests d'intrusion réguliers), avec des niveaux de maturité progressifs. CIS Controls s'utilise pour bâtir ou auditer un programme de sécurité dans son ensemble, en particulier pour une organisation qui démarre et a besoin de prioriser.

NIST Cybersecurity Framework structure une démarche de sécurité autour de fonctions (identifier, protéger, détecter, répondre, restaurer) plutôt que de contrôles isolés. Le NIST CSF s'utilise pour donner une vision d'ensemble cohérente à un programme de sécurité, en particulier pour le communiquer à une direction non technique.

PTES et OSSTMM encadrent spécifiquement la méthodologie d'un test d'intrusion : ce qu'il faut couvrir, dans quel ordre, avec quelle rigueur. Ces deux méthodologies s'utilisent au moment de cadrer ou d'évaluer la qualité d'un pentest, qu'il soit interne ou réalisé par un prestataire.

Le point commun entre tous ces référentiels techniques : aucun n'a de valeur légale en soi. Personne ne vous sanctionne pour ne pas avoir suivi le Top 10 OWASP. Leur valeur est opérationnelle, pas juridique.

Les référentiels de conformité répondent à une question différente : comment démontrer, face à un régulateur, un auditeur ou un assureur, que l'organisation respecte un ensemble d'exigences fixées en dehors d'elle-même.

NIS2 (directive UE 2022/2555) impose aux entités essentielles et importantes des exigences sur la gestion des incidents, la gestion des risques, les tests de sécurité et la sécurité de la chaîne d'approvisionnement, avec un dispositif de notification des incidents majeurs à l'ANSSI (alerte précoce sous 24 heures, notification sous 72 heures). Attention à une confusion fréquente sur le calendrier : l'échéance européenne de transposition était fixée au 17 octobre 2024, mais la France ne l'a pas respectée. La transposition passe par la loi relative à la résilience des infrastructures critiques et au renforcement de la cybersécurité (dite « loi Résilience »), adoptée au Sénat en mars 2025, dont la promulgation est attendue courant 2026. Tant que la loi n'est pas promulguée, les obligations ne sont pas juridiquement opposables — mais l'ANSSI a publié en mars 2026 une version de travail du Référentiel Cyber France (ReCyF), qui détaille les mesures attendues et sert déjà de grille d'auto-évaluation. Les sanctions prévues peuvent atteindre plusieurs millions d'euros ou un pourcentage du chiffre d'affaires annuel mondial selon le type d'entité.

DORA, applicable depuis janvier 2025 pour le secteur financier européen, impose une approche structurée de la résilience opérationnelle numérique : gestion des risques TIC, tests de résilience réguliers, gestion du risque lié aux prestataires tiers, et obligations de notification d'incident comparables à celles de NIS2.

ISO 27001 certifie qu'une organisation dispose d'un système de management de la sécurité de l'information structuré et audité, avec un cycle d'amélioration continue. Contrairement à NIS2 et DORA, ISO 27001 n'est pas une obligation légale en soi, mais une certification volontaire de plus en plus exigée contractuellement par les clients ou partenaires.

RGPD encadre la protection des données personnelles, avec des obligations de sécurité technique et organisationnelle directement liées à la cybersécurité, et des sanctions qui peuvent être substantielles. La sanction CNIL de janvier 2026 contre Free Mobile et Free l'illustre : 42 millions d'euros au total (27 et 15 millions), prononcés après une intrusion d'octobre 2024 ayant exposé les données de 24 millions de contrats d'abonnés, dont des IBAN. La CNIL a retenu, au titre de l'article 32 du RGPD, des mesures de sécurité insuffisantes — notamment une authentification VPN trop faible et une détection des accès anormaux défaillante.

Le point commun entre ces référentiels de conformité : ils exigent une preuve documentée, traçable et souvent datée, pas seulement une bonne pratique appliquée silencieusement. Une organisation peut être réellement bien sécurisée et pourtant non conforme, simplement parce qu'elle n'a pas documenté ce qu'elle fait.

Le choix ne se fait jamais dans l'absolu. Il dépend de la question concrète à laquelle vous devez répondre.

Vous développez ou auditez une application. Référentiels techniques : OWASP pour les risques applicatifs, PTES ou OSSTMM si un pentest est prévu pour valider le résultat.

Vous structurez un programme de sécurité de zéro. CIS Controls pour prioriser les mesures par ordre de maturité, NIST CSF pour donner une structure de communication à la direction.

Vous investiguez un incident ou structurez votre détection. MITRE ATT&CK pour qualifier précisément ce qui s'est passé et où l'attaquant se situait dans sa progression.

Vous devez démontrer une conformité réglementaire. NIS2 ou DORA selon votre secteur et votre taille, RGPD si des données personnelles sont en jeu, ISO 27001 si un client ou un appel d'offres l'exige contractuellement.

Vous gérez une chaîne de sous-traitants ou de fournisseurs. Les deux familles s'articulent : NIS2 et DORA imposent désormais explicitement une surveillance de la sécurité de la chaîne d'approvisionnement, ce qui rejoint directement les enjeux qu'on développe dans notre article sur le risque fournisseur cloud et le TPRM.

Dans la pratique, ces deux familles ne s'excluent jamais : NIS2 exige des audits de sécurité réguliers, qui eux-mêmes s'appuient sur des référentiels techniques comme OWASP ou des méthodologies comme PTES pour être menés sérieusement. Le référentiel réglementaire fixe l'obligation, le référentiel technique fournit la méthode pour la remplir.

La réponse honnête tient en deux parties, et elles ne sont pas symétriques.

Ce qui s'automatise bien : la collecte de preuves et le suivi continu des écarts. Une plateforme de gestion des risques et de la conformité (GRC) peut centraliser les obligations réglementaires, détecter automatiquement un écart de configuration par rapport à un contrôle CIS donné, ou déclencher une alerte dès qu'un actif sort de la conformité attendue. Une cartographie de surface d'attaque externe peut vérifier en continu qu'un référentiel comme OWASP reste respecté sur un périmètre qui change chaque semaine, plutôt que de se contenter d'un audit annuel figé. Les workflows de remédiation eux-mêmes s'automatisent largement : transformation automatique d'une vulnérabilité détectée en ticket exploitable dans un outil ITSM, avec champs préremplis et recommandations générées, plutôt qu'une saisie manuelle répétée à chaque incident.

Ce qui résiste à l'automatisation : l'interprétation contextuelle et la décision de gouvernance. Un référentiel comme NIS2 ne fournit pas une liste de cases à cocher mécaniquement : il demande d'évaluer si les mesures mises en place sont proportionnées au risque réel de l'organisation, ce qui suppose un jugement humain que la réglementation elle-même ne dispense jamais. De même, qualifier la criticité réelle d'un écart détecté automatiquement — par exemple décider si une configuration non conforme constitue un risque opérationnel sérieux ou une exception justifiée — reste une tâche qui appelle l'expertise d'un analyste plutôt qu'une règle automatique.

La nuance la plus importante à retenir : l'automatisation efficace ne remplace pas le référentiel, elle l'opérationnalise. Un outil ne décide pas qu'une organisation est conforme à NIS2 ; il collecte en continu les preuves qui permettront à un humain, interne ou auditeur, de l'affirmer avec un dossier solide plutôt qu'une reconstruction de dernière minute avant un contrôle.

« Sur le terrain, ce qu'on automatise vraiment bien, c'est la fraîcheur de la preuve. Avant, un audit de conformité partait d'un inventaire reconstitué à la main, souvent daté. Avec une surveillance continue de la surface d'attaque, la preuve existe déjà au moment où l'auditeur la demande. »
— Florent Montel, cofondateur de Patrowl

Cette logique de preuve continue plutôt que reconstituée recoupe directement ce qu'on développe dans notre article sur les enjeux RSSI 2026 : les auditeurs attendent désormais des preuves horodatées et vérifiables en continu, pas une conformité déclarative validée une fois par an.

Ce que Patrowl automatise concrètement dans cette logique : découverte continue des actifs exposés sur l'ensemble du périmètre, détection des vulnérabilités référencées et non référencées avec qualification par des experts avant remontée, génération automatique de tickets de remédiation enrichis dans les outils ITSM existants, et maintien d'un historique centralisé des actions correctives directement exploitable pour la documentation exigée par NIS2, DORA ou le RGPD.

Au-delà du principe général, voici comment cette distinction se traduit dans une plateforme comme Patrowl, référentiel par référentiel.

Côté méthodologique et technique, Patrowl s'appuie sur trois référentiels pour structurer ses propres tests et qualifications. OWASP sert de base à la détection des vulnérabilités applicatives, qu'elles soient référencées (CVE) ou non référencées : c'est le référentiel qui guide directement ce que le moteur de pentest automatisé recherche sur une application exposée. PTES (Penetration Testing Execution Standard) et OSSTMM encadrent la méthodologie des tests d'intrusion eux-mêmes, qu'ils soient menés par le moteur automatisé ou par les pentesters internes lors de la validation manuelle des findings critiques. Ces trois référentiels n'ont aucune valeur réglementaire : ils garantissent que la méthode de test est rigoureuse et reproductible, pas qu'une obligation légale est remplie.

Côté réglementaire et conformité, Patrowl couvre quatre référentiels distincts. NIS2 et DORA sont les deux textes les plus structurants actuellement, avec des pages et des fonctionnalités dédiées à la démonstration de conformité pour les entités concernées. Le RGPD intervient dès qu'une exposition détectée concerne des données personnelles, ce qui recoupe directement la dimension juridique du risque. Le Programme CaRE (Cybersécurité Accélération et Résilience des Établissements), piloté par l'Agence du Numérique en Santé pour le secteur de la santé en France, illustre qu'un référentiel de conformité peut aussi être sectoriel plutôt que transversal.

Ce qui distingue concrètement ces deux colonnes dans l'usage quotidien : les référentiels méthodologiques déterminent ce que Patrowl teste et comment, en coulisses, sans jamais apparaître directement dans un rapport d'audit réglementaire. Les référentiels de conformité déterminent, eux, comment les résultats de ces tests sont présentés, documentés et historisés pour servir de preuve face à un régulateur, un auditeur ISO ou un assureur cyber.

Un référentiel technique et un référentiel de conformité ne sont pas deux variantes d'un même outil : ils répondent à deux questions différentes, et confondre les deux conduit soit à une sécurité techniquement solide mais non démontrable, soit à une conformité documentaire qui ne correspond à aucune réalité opérationnelle.

L'automatisation change la donne, mais sur un point précis : elle transforme la collecte de preuves d'un exercice ponctuel et reconstitué en un flux continu et daté. Elle ne remplace jamais le jugement qui consiste à interpréter un référentiel face à un contexte réel, ni la décision de gouvernance qui en découle. La meilleure combinaison reste celle où les deux familles de référentiels se nourrissent mutuellement, et où l'automatisation sert la preuve plutôt que de prétendre se substituer au jugement.

Quelle est la différence entre un référentiel technique et un référentiel de conformité ? Un référentiel technique (OWASP, MITRE ATT&CK, CIS Controls) guide une action concrète de sécurisation, sans valeur légale en soi. Un référentiel de conformité (NIS2, DORA, ISO 27001) impose une obligation réglementaire ou contractuelle qui doit être démontrée par une preuve documentée et traçable.

Faut-il choisir entre les référentiels techniques et les référentiels de conformité ? Non, ils sont complémentaires. Les référentiels de conformité fixent souvent l'obligation d'auditer ou de sécuriser un périmètre, sans préciser la méthode. Les référentiels techniques fournissent cette méthode.

Peut-on automatiser entièrement la conformité à NIS2 ou DORA ? Non. La collecte de preuves, le suivi continu des écarts et la génération de documentation peuvent être largement automatisés. L'interprétation de la proportionnalité des mesures au risque réel et la décision de gouvernance restent des tâches humaines que la réglementation elle-même suppose.

Quel référentiel utiliser pour sécuriser une application avant sa mise en production ? OWASP pour les risques applicatifs spécifiques, complété si besoin par un pentest structuré selon une méthodologie comme PTES ou OSSTMM pour valider le résultat de façon indépendante.

Pourquoi une organisation peut-elle être bien sécurisée mais non conforme ? Parce que la conformité réglementaire exige une preuve documentée et traçable de ce qui est fait, pas seulement une bonne pratique appliquée silencieusement. Une mesure de sécurité efficace mais non documentée ne constitue pas une preuve de conformité.

NIS2 est-elle déjà applicable en France ? Pas encore au moment de la rédaction. L'échéance européenne de transposition (17 octobre 2024) n'a pas été respectée par la France ; la loi Résilience qui transpose la directive a été adoptée au Sénat en mars 2025 et sa promulgation est attendue courant 2026. L'ANSSI met toutefois déjà à disposition le Référentiel Cyber France (ReCyF) comme grille d'anticipation.

Sources : ANSSI, Panorama de la cybermenace 2025 et Référentiel Cyber France (ReCyF, mars 2026) · Patrowl, pages produit Conformité NIS2/DORA et Intégrations · OWASP Top 10:2025 · CNIL, délibérations SAN-2026-001 et SAN-2026-002 (sanction Free Mobile / Free, janvier 2026) · Directive NIS2 (UE 2022/2555) · Règlement DORA (UE 2022/2554) · Agence du Numérique en Santé, programme CaRE.