ReCyF : le référentiel de cybersécurité de l'ANSSI pour NIS 2, objectif
par objectif

"Les entités [importantes ou essentielles] disposent d'au moins une cartographie de leurs systèmes d'information suffisamment détaillée pour faciliter : 1° Le maintien en condition opérationnelle et de sécurité de leurs systèmes d'information ; et 2° L'amélioration de la réactivité de ces entités en cas d'incident de sécurité affectant leurs systèmes d'information." C'est l'énoncé de l'objectif de sécurité numéro 5 du ReCyF, le Référentiel Cyber France que l'ANSSI a rendu public le 17 mars 2026 en version 2.5. Lu vite, il demande un schéma réseau. Lu avec la mesure qui l'accompagne, il demande autre chose : être capable, à la publication d'un bulletin d'alerte, de nommer les ressources vulnérables, et à la survenue d'un incident, de nommer celles qui sont touchées. Un schéma Visio de 2021 ne répond pas à cette question. Un inventaire daté, versionné et confronté à ce qui est exposé de fait, oui.

Tout le référentiel fonctionne sur ce mode : un objectif court, dont l'atteinte sera obligatoire, puis des moyens acceptables de conformité qui disent comment l'ANSSI s'attend à le voir atteint. Vingt objectifs, quarante-sept pages, et entre eux une différence de nature que la numérotation ne laisse pas deviner : certains se démontrent en tendant un document signé, d'autres supposent d'aller mesurer. Le champ d'application, les sanctions et le calendrier de NIS 2 sont traités dans le guide de la directive NIS2.

Le ReCyF, un référentiel publié avant la loi qu'il applique

Le document se présente lui-même sans ambiguïté. Sa page de garde porte la mention "version de travail", un filigrane "document de travail" le barre en diagonale, et sa présentation ouvre ainsi : "RECYF constitue le référentiel de cybersécurité mentionné au 6ème alinéa de l'article 14 du projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité (PJL)." La page NIS 2 de l'ANSSI le met à disposition depuis le 17 mars 2026 et renvoie vers le PDF de la version 2.5, 47 pages, ainsi que vers un outil de comparaison de référentiels hébergé sur MesServicesCyber.

Le mot "projet" compte. Au moment de la rédaction (septembre 2026), la loi de transposition n'est pas promulguée : le dossier législatif du Sénat s'arrête au texte n° 78 adopté par le Sénat le 12 mars 2025, transmis à l'Assemblée nationale le lendemain, puis au texte de la commission spéciale déposé le 10 septembre 2025. Le ReCyF décrit donc des obligations qu'un décret fixera, sur le fondement d'une loi que le Parlement n'a pas fini de voter. Il cite d'ailleurs "l'article 17 de la loi XXX" pour les incidents importants, le numéro n'existant pas encore. La rédaction anticipe parce que l'état du droit l'y oblige, et il vaut mieux le savoir avant de bâtir un plan de mise en conformité sur une numérotation provisoire.

Les 20 objectifs de sécurité du ReCyF, pilier par pilier

Le référentiel range ses objectifs dans un modèle à quatre piliers, gouvernance, protection, défense et résilience, que son tableau de correspondance final explicite. Les objectifs 1 à 15 s'appliquent par défaut aux entités importantes (EI), aux entités essentielles (EE) et aux opérateurs d'importance vitale sur leurs systèmes autres que leurs SIIV. Les objectifs 16 à 20, "en application du principe de proportionnalité", ne concernent que les entités essentielles. Voici les intitulés exacts, tels qu'ils figurent dans le document.

Le partage entre entités importantes et entités essentielles ne s'arrête pas au seizième objectif. Dans les quinze premiers, chaque moyen acceptable de conformité porte deux colonnes, "attendu d'une EI" et "attendu d'une EE", et beaucoup de lignes sont à "Non / Oui". L'objectif 7 en est l'exemple le plus net : une entité importante cloisonne l'ensemble de ses systèmes vis-à-vis des tiers (7.A.1-EI/EE), une entité essentielle cloisonne chaque système des autres (7.A.2-EE) et met en place des passerelles entrante et sortante (7.A.5-EE, 7.A.6-EE), pour un intitulé rigoureusement identique. Le classement en piliers réserve une autre surprise : l'audit (objectif 17) est rangé en "gouvernance" et non en "défense", ce qui se comprend quand on voit que son résultat alimente l'analyse de risques, dont la mesure 16.2-EE cite "les audits" parmi ses sources, et sert à vérifier l'atteinte des autres objectifs.

Objectif, moyen acceptable de conformité, mesure alternative : la mécanique

Chaque fiche du ReCyF suit le même plan. D'abord un "rappel de l'objectif de sécurité", en deux ou trois alinéas, qui répond à la question "quoi ?". Puis un tableau de moyens acceptables de conformité, numérotés à la façon 5.B.4-EI/EE (objectif, éventuelle sous-section, rang, entités concernées), qui répondent à "comment ?". Ce tableau est parfois précédé d'un paragraphe indiquant qu'une certification ou une prestation qualifiée par l'ANSSI vaut démonstration : un SMSI certifié ISO/IEC 27001:2022 pour les objectifs 2 et 16, une prestation PACS pour la préparation de la gestion des incidents (12), des crises (14), des exercices (15) et de l'analyse de risques (16), une prestation PASSI pour l'audit (17), une prestation PAMS pour la plus grande partie de l'administration sécurisée (les mesures 19.2 à 19.7 et 19.10 à 19.12, pas l'objectif 19 entier) et une prestation PDIS pour la supervision (20). Toutes ces qualifications renvoient au décret n° 2015-350 du 27 mars 2015 modifié.

Une clause revient une dizaine de fois dans les tableaux, toujours sous la même forme : "Lorsque des raisons techniques ou opérationnelles ne permettent pas [de faire X], l'entité met en oeuvre des mesures permettant de réduire le risque associé." On la trouve pour les correctifs (5.B.6), l'authentification multifacteur (8.4-EE), les comptes partagés (10.A.3), les logiciels qu'on ne peut pas désinstaller (18.2-EE) ou les postes d'administration non dédiés (19.6-EE). Le référentiel admet donc partout l'exception, contre une mesure de compensation. Un système industriel qu'on ne peut pas patcher est prévu par le texte ; un système qu'on ne patche pas et qu'on n'isole pas non plus ne l'est pas.

Les résumés du référentiel passent en général sous silence la porte de sortie de l'objectif 1. Il autorise à écarter certains systèmes du périmètre, à condition de justifier qu'ils ne sont exposés à aucun des trois risques listés (interruption, divulgation, altération), puis il verrouille aussitôt l'argument le plus tentant : "La mise en oeuvre de mesures de sécurité sur ces systèmes d'information ne permet pas de justifier qu'ils ne sont exposés à aucun des risques précités." On n'exclut pas un système parce qu'il est bien protégé, on l'exclut parce que sa compromission n'aurait pas d'effet ; l'annexe cite le site du comité d'entreprise.

Les périodicités que le ReCyF fixe

Les référentiels de conformité aiment le mot "régulièrement". Celui-ci chiffre, au moins en partie. Une lecture ligne à ligne des tableaux donne les échéances suivantes, avec leur numéro de mesure pour qu'on puisse les retrouver.

La revue annuelle est le rythme par défaut du texte, et elle touche presque toujours une liste : systèmes, comptes, droits, règles de filtrage. Ce que le référentiel veut voir revenir chaque année, c'est une vérification que l'inventaire correspond encore au réel. Le seul délai court du document, les 24 heures ouvrées de prise en compte des événements, ne concerne que la supervision des entités essentielles. Quant à la mesure 5.B.4 sur les correctifs, elle ne fixe aucun nombre de jours, mais elle vise en priorité "un serveur Web, un pare-feu exposé sur Internet, un serveur de messagerie". C'est la définition d'une surface d'attaque externe, sans employer le mot.

ReCyF et l'article 21(2) de NIS 2 : des objectifs rattachés aux points a à j

L'article 21, paragraphe 2, de la directive (UE) 2022/2555 énumère dix familles de mesures, de a) "les politiques relatives à l'analyse des risques et à la sécurité des systèmes d'information" à j) "l'utilisation de solutions d'authentification à plusieurs facteurs". Le ReCyF ne les recopie pas. Il se termine par deux tableaux de correspondance, "communiqués uniquement à des fins pédagogiques", et le rattachement s'y fait au niveau de l'objectif, jamais de la mesure. Quelques exemples lus dans la table :

• Objectif 2 (cadre de gouvernance) est rattaché à l'article 20 sur la responsabilité des organes de direction, et aux points a, f, h et i du 21(2). C'est l'objectif le plus transversal du référentiel.
• Objectif 5 (maîtrise des SI) répond aux points e (sécurité de l'acquisition, du développement et de la maintenance, "y compris le traitement et la divulgation des vulnérabilités") et i (gestion des actifs).
• Objectif 17 (audit) est rattaché au seul point f, "des politiques et des procédures pour évaluer l'efficacité des mesures de gestion des risques". Le point f est le seul de la liste qui parle de preuve d'efficacité, et le ReCyF y répond par l'audit, réservé aux entités essentielles.
• Objectifs 12 et 20 (incidents, supervision) répondent au point b, la gestion des incidents ; objectif 13 au point c, la continuité ; objectif 16 au point a, l'analyse des risques.

Conséquence pratique pour qui prépare un dossier : inutile de chercher dans le ReCyF "la mesure qui correspond au 21(2)(f)". Il n'y en a pas. Il y a un objectif, le 17, et cinq mesures sous lui, de 17.1-EE à 17.5-EE. Pour une entité importante, qui n'a pas l'objectif 17, la preuve d'efficacité repose sur l'analyse de conformité de l'objectif 2 (2.C.1), tenue à jour. Le point f de la directive continue pourtant de s'appliquer à elle ; comment prouver l'efficacité sans audit reste, pour une EI, une question que le ReCyF laisse ouverte.

Ce qui se prouve techniquement, et ce qui reste documentaire

Vu depuis le métier de l'audit technique, les vingt objectifs se répartissent en deux tas très inégaux. La majorité se démontre avec des documents : une PSSI approuvée par le dirigeant (2.B.3), une charte opposable aux utilisateurs (4.1), une cartographie de l'écosystème avec un contact par prestataire (3.A.2), une liste imprimée des personnes mobilisables en crise (14.2), une stratégie de communication de crise (14.9-EE). Ces livrables sont sérieux et ils prennent du temps, mais un contrôleur les vérifie en les lisant. Le détail de ces livrables est ailleurs, dans l'article sur la structure d'une PSSI et ce qu'un auditeur y cherche, et l'objectif 16 renvoie explicitement à la méthode EBIOS RM, "qui peut être utilisée" sans être imposée.

Restent quelques objectifs qu'aucune lecture ne suffit à valider, parce qu'ils portent sur des états observables et datables.

Objectif 5 : la cartographie et les correctifs sur ce qui est exposé

La mesure 5.A.1 demande une cartographie assez fine pour "identifier les ressources matérielles ou logicielles vulnérables suite à la publication d'un bulletin d'alerte". La mesure 5.B.3 demande une veille sur les vulnérabilités, en citant le CERT-FR. La 5.B.4 demande les correctifs sans retard injustifié sur les ressources exposées à des systèmes tiers. Bout à bout, ces trois mesures décrivent une surface d'attaque tenue à jour, et elles ont une propriété que les autres n'ont pas : leur résultat est observable de l'extérieur. Un serveur de messagerie qui annonce une version visée par un bulletin CERT-FR fournit lui-même sa preuve, et il la fournit au premier venu. C'est le rôle d'un EASM : reconstruire depuis Internet la liste de ce qui est exposé, la comparer à la cartographie déclarée, et dater l'écart. Le raisonnement mesure par mesure est dans l'article sur l'inventaire de l'exposé comme obligation de l'article 21.

Objectifs 7 et 18 : le filtrage et la configuration, revus chaque année

La 7.B.5 impose une revue annuelle de la mise en oeuvre technique des règles de filtrage. La 18.4-EE va plus loin et nomme l'outil : une revue annuelle de configuration qu'il est "recommandé" d'appuyer sur des outils automatisés, "par exemple : scan de port et de vulnérabilité, revue (manuel ou automatique) des configurations des pares-feux par rapport aux matrices de flux". Le référentiel écrit donc lui-même que la preuve attendue est un scan confronté à la matrice de flux. Un port ouvert que la matrice n'autorise pas est une non-conformité au sens du texte, et elle se constate en une commande.

Objectif 17 : l'audit, et ce que 17.3-EE dit du test d'intrusion

La mesure 17.3-EE mérite d'être citée en entier, parce qu'elle est souvent résumée en "le ReCyF impose un pentest", ce qui est faux : "Sans préjudice d'autres obligations légales et réglementaires, l'audit de sécurité comprend au minimum une activité parmi les suivantes : un test d'intrusion (couvrant au minimum les interfaces exposées à des systèmes sous la responsabilité de l'entité pour lesquels elle a décidé de ne pas appliquer les objectifs de sécurité ainsi qu'à des systèmes d'information tiers), un audit de configuration, un audit d'architecture, un audit organisationnel et physique et, lorsque cela est pertinent, un audit de code." Le test d'intrusion est une option parmi cinq, mais c'est la seule dont le périmètre minimal est précisé, et ce périmètre est l'exposé : les interfaces tournées vers les systèmes tiers et vers les systèmes hors périmètre. La 17.4-EE fixe ensuite le contenu du rapport (synthèse de conformité, non-conformités et vulnérabilités, recommandations) et la 17.5-EE exige un plan d'action avec une échéance et un responsable par action.

Sur cet objectif, own2pwn doit être explicite, à deux endroits. L'objectif 17 ne concerne que les entités essentielles ; une entité importante peut faire tester ses interfaces exposées, l'objectif 5 lui en donne une raison, mais le référentiel ne le lui demande pas. Et l'introduction de l'objectif indique qu'une entité essentielle peut se prévaloir d'une prestation PASSI qualifiée par l'ANSSI "dont le périmètre de la prestation couvre l'application des mesures correctives". own2pwn ne détient pas cette qualification. Un test d'intrusion own2pwn produit un rapport au format de 17.4-EE et un retest des corrections, ce qui couvre le contenu attendu par la mesure, mais une entité essentielle qui veut en plus l'argument "prestataire qualifié" devra s'adresser à un PASSI. Le détail du déroulé, des livrables et de la place du test dans le dossier est dans l'article sur l'audit NIS2 et pourquoi le papier ne suffit pas.

Objectif 20 : la supervision, c'est-à-dire un SOC

Celui-là appelle une mise au point, parce qu'il est le plus mal vendu du référentiel. L'objectif 20 décrit une activité de supervision : collecte des journaux, prise en compte sous 24 heures ouvrées, conservation trois mois, couverture des scénarios de menace de l'analyse de risques. C'est un SOC, interne ou externalisé, et la voie qualifiée est la prestation PDIS. Un EASM comme celui d'own2pwn n'en fait pas partie : il observe la surface externe depuis Internet, il ne collecte pas vos journaux et ne détecte pas vos incidents. Son terrain est l'objectif 5, et quiconque vend un scanner externe comme réponse à l'objectif 20 lit mal le texte.

Par où commencer, côté entité importante et côté entité essentielle

L'ordre des objectifs n'est pas un ordre de mise en oeuvre, mais les renvois internes du référentiel en dessinent un : l'analyse de conformité (2.C.1) suppose la liste des systèmes (1.1) et leur cartographie (5.A.1), l'analyse de risques (16.2) s'appuie sur l'écosystème, la maîtrise du SI et les audits, et la supervision (20) se calibre sur les scénarios de l'objectif 16.

Le pivot est le même des deux côtés : une cartographie qui dit vrai. Tout le reste du référentiel la présuppose, de l'analyse de conformité au programme d'audit, et c'est le livrable qu'on peut le plus facilement vérifier sans croire personne sur parole, en regardant ce qu'Internet voit de vous.

À retenir

• Le ReCyF v2.5 (17 mars 2026) est le référentiel de l'article 14 du projet de loi Résilience, publié en version de travail ; au moment de la rédaction (septembre 2026), la loi n'est pas promulguée et rien n'est encore opposable.
• 20 objectifs de sécurité, 15 pour les entités importantes, les objectifs 16 à 20 réservés aux entités essentielles, répartis en quatre piliers : gouvernance, protection, défense, résilience.
• L'objectif sera obligatoire ; le moyen acceptable de conformité ne l'est pas, mais l'entité qui l'applique peut s'en prévaloir lors d'un contrôle, et une mesure alternative doit être justifiée dans l'analyse de conformité.
• Les périodicités écrites sont la revue annuelle (listes, PSSI, filtrage, comptes, sauvegardes, configuration), le réexamen triennal de l'analyse de risques, 24 h ouvrées et 3 mois pour la supervision.
• Le rattachement à l'article 21(2) se fait objectif par objectif, pas mesure par mesure ; le point f (efficacité) tombe sur l'objectif 17, que les entités importantes n'ont pas.
• Se prouvent techniquement : la cartographie de l'exposé (5), la revue de configuration et le scan (18), l'audit et le test d'intrusion sur les interfaces exposées (17). La supervision (20) est un SOC, pas un scanner.

Un dossier ReCyF finit toujours par buter sur la partie qui ne se rédige pas, celle des objectifs 5, 17 et 18. own2pwn produit ces preuves-là sur un périmètre défini : inventaire de ce que vous exposez confronté à votre cartographie, test d'intrusion des interfaces exposées avec rapport au format attendu et retest, matrice de couverture par objectif. Le détail et les tarifs sont sur la page du volet technique d'un audit NIS2. Pour la prestation qualifiée PASSI, l'analyse de risques ou la rédaction de la PSSI, il faudra frapper à d'autres portes.

Questions fréquentes sur le ReCyF