ReCyF : lecture opérationnelle

Pourquoi ce chapitre est le plus utile pour vos équipes

Savoir que NIS2 impose une liste de dix domaines de mesures à l'article 21 ne dit rien sur la manière de les mettre en œuvre un lundi matin, avec les effectifs et le budget dont dispose réellement une PME industrielle ou une collectivité de taille moyenne. C'est exactement le trou que ReCyF vient combler : il ne s'agit pas d'un texte de loi supplémentaire, mais d'un outil de traduction opérationnelle.

Ce chapitre part du principe que vous connaissez déjà le contenu de l'article 21 de NIS2 (couvert au chapitre précédent) et vous montre comment le lire à travers la grille ReCyF pour produire un plan d'action réaliste, ordonné, et défendable devant une direction qui demande « par quoi on commence ? ».

Qu'est-ce que ReCyF, concrètement

ReCyF est un référentiel de contrôles diffusé pour aider les entités concernées par NIS2 à structurer leur mise en conformité sur le terrain français. Il ne crée pas d'obligation juridique autonome : il organise les mesures déjà exigées par le texte européen en domaines opérationnels cohérents avec la doctrine déjà connue des équipes sécurité françaises — la même logique de découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire que l'on retrouve dans EBIOS RM ou dans les référentiels d'exigences applicables aux prestataires qualifiés.

ReCyF n'est pas une certification et ne délivre aucun label. C'est une grille de lecture destinée à faciliter l'auto-évaluation et le dialogue avec l'autorité de contrôle. Confondre « appliquer ReCyF » avec « être certifié conforme » est l'erreur la plus fréquente observée chez les entités qui découvrent le référentiel.

La structure retenue distingue six domaines qui reprennent la logique classique d'un cycle de gestion du risque cyber :

1. Identifier — cartographie des systèmes essentiels, des dépendances et des actifs critiques.
2. Protéger — durcissement, contrôle d'accès, gestion des vulnérabilités.
3. Détecter — supervision, journalisation, détection d'anomalies.
4. Répondre — procédures d'incident, notification, communication de crise.
5. Rétablir — continuité d'activité, sauvegardes, plans de reprise.
6. Gouverner — pilotage, formation, gestion des tiers et de la chaîne d'approvisionnement.

Chaque domaine se décline en contrôles élémentaires, eux-mêmes assortis d'indicateurs de maturité sur une échelle simple (inexistant, initié, structuré, maîtrisé, optimisé). C'est cette granularité qui permet de transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire un texte juridique abstrait en check-list vérifiable.

Cette échelle de maturité mérite d'être prise au sérieux plutôt que remplie à la va-vite. « Inexistant » signifie qu'aucune mesure n'a été mise en place, ni même envisagée. « Initié » correspond à une action ponctuelle, souvent portée par une personne plutôt que par un processus documenté — typiquement une sauvegarde lancée manuellement de temps en temps. « Structuré » implique une procédure écrite, connue de plusieurs personnes, et appliquée de façon répétable. « Maîtrisé » ajoute un contrôle régulier de l'efficacité de la mesure, avec des indicateurs suivis dans le temps. « Optimisé » suppose une amélioration continue, avec des retours d'expérience intégrés après chaque incident ou exercice. Dans la pratique, viser « optimisé » sur l'ensemble des contrôles n'a aucun sens économique : l'objectif réaliste est d'atteindre « structuré » ou « maîtrisé » sur les contrôles associés aux systèmes essentiels, et de tolérer un niveau plus bas sur les systèmes périphériques, à condition que ce choix soit documenté et assumé plutôt que subi.

Le mapping avec les mesures de l'article 21

L'article 21 de NIS2 énumère dix catégories de mesures que les entités essentielles et importantes doivent mettre en œuvre de façon proportionnée à leur exposition au risque. Le tableau suivant donne une correspondance indicative entre ces catégories et les domaines ReCyF — indicative, car plusieurs mesures de l'article 21 recoupent plusieurs domaines à la fois. Ce mapping n'a pas vocation à être appliqué mécaniquement : il sert de point de départ pour construire, avec les équipes juridiques et sécurité, une cartographie propre à l'entité, qui tienne compte de son secteur d'activité et des contrôles déjà en place issus d'autres démarches (RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire, ISO 27001, référentiels sectoriels).

Commencez toujours l'analyse d'écart par le domaine « Identifier ». Sans cartographie fiable des systèmes essentiels, tout contrôle mis en œuvre ailleurs repose sur un périmètre incertain — vous risquez de bien protéger ce qui compte peu et de laisser exposé ce qui compte vraiment.

Une méthode de priorisation pensée pour des moyens limités

La plupart des entités qui découvrent NIS2 ont un point commun : une liste d'exigences qui dépasse largement leur capacité d'exécution sur l'année en cours. ReCyF ne résout pas ce problème par magie, mais son découpage en domaines et en indicateurs de maturité permet d'appliquer une méthode de priorisation simple, croisant deux axes :

• Le niveau de risque associé à chaque contrôle manquant, évalué à partir de la criticité du système concerné et de la probabilité d'exploitation.
• La maturité actuelle de l'organisation sur ce contrôle, mesurée via l'échelle ReCyF.

En pratique, la criticité d'un système s'apprécie à partir de trois questions simples : que se passe-t-il pour l'activité si ce système est indisponible pendant 24 heures, quelles donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles ou réglementées transitent par lui, et quel serait l'impact sur des tiers (clients, partenaires, usagers) en cas de compromission. La probabilité d'exploitation, elle, s'estime à partir de l'exposition du système — accessible depuis Internet, ouvert à des prestataires externes, reposant sur des composants obsolètes — plutôt qu'à partir d'une intuition générale du niveau de menace. Ce sont ces deux estimations, combinées, qui alimentent la matrice plutôt qu'un jugement global du type « on est plutôt bien protégés ».

Ce croisement produit quatre zones d'action :

• Urgent (risque élevéhaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire, maturité faible) — traité en premier, souvent sous 3 à 6 mois.
• Planifier (risque élevé, maturité déjà correcte) — consolidation à horizon 12 mois.
• Surveiller (risque faible, maturité faible) — accepté temporairement si documenté, revu à échéance régulière.
• Maintenir (risque faible, maturité correcte) — simple suivi, pas d'investissement supplémentaire.

Une entreprise de logistique de 180 salariés, identifiée comme entité importante, a cartographié 40 contrôles ReCyF applicables à son périmètre. L'analyse a fait ressortir 6 contrôles en zone « Urgent » : absence d'authentification forte sur l'accès distant au TMS (système de gestion du transport), pas de procédure formalisée de notification d'incident, sauvegardes non testées depuis 18 mois. Ces six chantiers ont été traités en quatre mois, avant même de démarrer les zones « Planifier », qui représentaient pourtant deux fois plus de contrôles.

Pièges observés dans les premières mises en œuvre

Ne traitez pas ReCyF comme une checklist à cocher indépendamment du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire métier. Un contrôle « maîtrisé » sur un système périphérique n'a aucune valeur si le système essentiel identifié au domaine « Identifier » reste en zone « Urgent ». La proportionnalité prévue par NIS2 s'apprécie au niveau de l'entité, pas contrôle par contrôle.

Ces écueils ne sont pas propres aux petites structures : des entités disposant déjà d'une fonction sécurité mature les reproduisent, souvent parce qu'elles transposent des réflexes hérités d'autres démarches de conformité (RGPD, ISO 27001) sans les adapter à la logique de proportionnalité au risque qui structure NIS2 et, par extension, ReCyF. Parmi les erreurs récurrentes constatées lors des premiers audits d'écart :

• Cartographie incomplète des systèmes essentiels — beaucoup d'entités listent leurs applications métier connues mais oublient les systèmes OT, les prestataires d'infogérance et le shadow IT, alors que ces derniers concentrent une part disproportionnée du risque.
• Confusion entre référentiel et obligation contractuelle — certaines équipes présentent ReCyF à leurs clients comme une certification obtenue, ce qui expose à un risque réputationnel en cas de contrôle.
• Priorisation uniquement technique — le croisement risque/maturité perd sa valeur si le « risque » est estimé sans consulter les métiers qui savent réellement quels systèmes sont critiques pour la continuité d'activité.
• Absence de revue périodique — un état des lieux figé au moment de l'analyse initiale devient rapidement obsolète ; ReCyF est pensé comme une boucle, pas comme un livrable one-shot.

Les domaines et indicateurs ReCyF sont amenés à évoluer avec les retours d'expérience des entités assujetties et les ajustements réglementaires nationaux de transposition de NIS2. Une entité qui a mené son analyse d'écart il y a plus d'un an devrait la rejouer avant toute échéance de notification à l'autorité compétente.

Checklist opérationnelle pour démarrer

Pour engager une première analyse d'écart avec ReCyF, l'ordre suivant limite les faux départs :

1. Identifier le statut de l'entité (essentielle ou importante) et le périmètre de systèmes concerné — cette qualification a déjà dû être établie en amont de ce chapitre.
2. Cartographier les systèmes essentiels avec les métiers, pas seulement avec l'IT.
3. Dérouler les six domaines ReCyF et noter la maturité actuelle de chaque contrôle applicable, en s'appuyant sur des preuves (configuration, procédure écrite, journal d'audit) plutôt que sur une déclaration orale — une maturité auto-déclarée sans preuve associée se dégonfle systématiquement au premier contrôle externe.
4. Estimer le risque associé à chaque écart avec les propriétaires métier des systèmes concernés, en documentant le raisonnement plutôt que la seule conclusion, pour pouvoir la réexaminer lors de la revue suivante.
5. Construire la matrice risque/maturité et isoler la zone « Urgent ».
6. Rédiger un plan d'action avec responsables nommés, échéances datées et budget chiffré pour la zone « Urgent », puis pour la zone « Planifier » — un plan sans responsable nommé reste, en pratique, un vœu pieux.
7. Documenter les décisions d'acceptation temporaire pour la zone « Surveiller », avec date de revue.
8. Planifier la prochaine revue complète, au minimum annuelle, ou dès qu'un changement significatif de système intervient.

Ce qu'il faut retenir

ReCyF ne remplace ni la loi ni le jugement professionnel : il donne une structure commune pour transformer une obligation légale en plan d'action daté, chiffré et défendable. Sa valeur tient moins à la liste des contrôles qu'à la méthode de priorisation qu'il rend possible — sans elle, une équipe sécurité sous contrainte de ressources traite les sujets dans l'ordre où ils sont arrivés plutôt que dans l'ordre où ils comptent. Le chapitre suivant s'appuie sur ce plan d'action priorisé pour aborder la question de la notification d'incident et des délais imposés par NIS2.