ReCyF : ce que le référentiel cyber de l'ANSSI change pour votre site web

Depuis le 17 mars 2026, l'ANSSI diffuse le Référentiel Cyber France, le ReCyF. Ce document traduit les obligations de la directive NIS2 en objectifs de sécurité opérationnels. La loi qui les rendra contraignantes n'est pas encore promulguée, mais deux de ces objectifs visent directement les prestataires numériques et le cycle de vie des applications. Autrement dit : votre site web et le contrat qui le maintient.

Le ReCyF, en une page

Le Référentiel Cyber France est le document par lequel l'ANSSI transforme les exigences générales de NIS2 en objectifs de sécurité vérifiables. Publié le 17 mars 2026 en version de travail (v2.5) sur la plateforme MesServicesCyber, il compte 20 objectifs répartis en quatre blocs. Il correspond au référentiel prévu par l'article 14 du projet de loi Résilience, le texte français de transposition.

Sa mécanique mérite d'être comprise avant tout le reste, parce qu'elle change la façon dont une entreprise doit se préparer. Chaque exigence est écrite sous la forme d'un objectif de sécurité, c'est-à-dire du résultat attendu, et non d'une mesure technique imposée. À cet objectif l'ANSSI associe des moyens acceptables de conformité : des mesures qu'une entité peut adopter telles quelles et dont elle pourra se prévaloir en cas de contrôle. Rien n'interdit de démontrer autrement que l'objectif est atteint, mais la charge de la preuve bascule alors sur l'entité.

Le référentiel intègre également un principe de proportionnalité assumé : le niveau d'effort attendu s'ajuste à la taille, à la maturité et aux moyens de l'organisation. L'ANSSI écrit viser la protection contre la menace cybercriminelle de masse, celle qui frappe indistinctement des milliers d'organisations avec des outils automatisés, et non un niveau de résistance à une attaque étatique ciblée. Pour une PME de 80 salariés, cela signifie que la conformité passe par des mesures bornées et documentées, pas par un centre de supervision interne.

Un dernier point structure tout le reste : le ReCyF fonctionne par démonstration. Pour chaque objectif, il faut pouvoir présenter la mesure en place, la preuve qui l'atteste et la date de cette preuve. Un site web maintenu sans journal d'intervention, sans registre des mises à jour et sans restauration testée ne produit aucune preuve datée, quel que soit le sérieux réel du travail effectué.

Où en est la loi Résilience au 24 août 2026

Le texte n'est pas promulgué. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité a été adopté par le Sénat en mars 2025, puis examiné en commission à l'Assemblée nationale en septembre 2025. Son passage en séance publique était attendu à l'été 2026 et n'a pas eu lieu. Aucune obligation NIS2 n'est donc opposable en France à cette date.

Ce retard a un coût politique déjà constaté : la France a manqué l'échéance de transposition du 17 octobre 2024 fixée par l'article 41 de la directive (UE) 2022/2555, ce qui lui a valu l'ouverture d'une procédure d'infraction par la Commission européenne fin novembre 2024. Le blocage porte notamment sur des dispositions relatives au chiffrement, sur un texte par ailleurs jugé consensuel. La Commission supérieure du numérique et des postes a publiquement pressé le Parlement d'examiner le texte sans délai.

Le texte transpose trois directives d'un coup : NIS2 pour la cybersécurité, REC (directive (UE) 2022/2557) pour la résilience des entités critiques, et le volet DORA pour le secteur financier. Cette architecture explique en partie sa lenteur : chaque volet a ses opposants, et l'ensemble avance au rythme du plus contesté.

La séquence probable, telle qu'elle se lit dans les travaux parlementaires, tient en quatre temps : promulgation, puis décrets et arrêtés d'application, puis notification et enregistrement des entités régulées, puis premiers contrôles. Entre la promulgation et les premiers contrôles ciblés, la fenêtre est courte. Or l'essentiel du travail attendu, à savoir l'inventaire des systèmes, la gouvernance et la constitution des preuves techniques, se compte en mois et non en semaines.

Voilà la lecture utile de la situation d'août 2026 : l'absence d'obligation n'est pas un répit, c'est la seule période où le travail peut être fait sans pression de calendrier. Les organisations qui attendront les décrets démarreront avec un handicap qu'aucun budget ne rattrape rapidement.

Entité essentielle, entité importante, ou hors périmètre

NIS2 fait passer le périmètre français d'environ 500 opérateurs de services essentiels sous NIS1 à près de 15 000 entités selon l'ANSSI, réparties dans 18 secteurs. Deux statuts coexistent : entité essentielle (EE) et entité importante (EI). Le statut se déduit du croisement entre le secteur d'activité et la taille de l'organisation, avec des exceptions sectorielles qui ramènent certaines petites structures dans le périmètre.

Le seuil de taille de référence est celui de l'entreprise moyenne au sens européen : plus de 50 salariés ou plus de 10 millions d'euros de chiffre d'affaires. Beaucoup de dirigeants de PME industrielles, de collectivités, d'établissements de santé ou de sociétés de transport découvrent à cette occasion qu'ils entrent dans le champ, alors qu'ils n'ont jamais eu affaire à l'ANSSI.

La conséquence pratique du statut porte sur le nombre d'objectifs applicables. Les entités importantes relèvent des objectifs 1 à 15. Les entités essentielles ajoutent les objectifs 16 à 20, qui constituent le bloc de maturité avancée : approche formalisée par les risques, audits réguliers, durcissement des configurations, administration depuis des ressources dédiées, supervision active de la sécurité. Le régime de supervision diffère aussi : réactif pour les EI, proactif pour les EE.

L'ANSSI met à disposition un test d'éligibilité sur son espace MonEspaceNIS2. C'est le point de départ raisonnable, avant toute dépense. Un point mérite d'être signalé aux directions qui hésitent : se déclarer hors périmètre sans avoir tracé le raisonnement est un pari. En cas de contrôle, l'analyse d'éligibilité datée et argumentée fait elle aussi partie du dossier.

Les 20 objectifs, relus depuis votre site web

Les 20 objectifs du ReCyF s'organisent en quatre blocs. Le bloc Fondation (objectifs 1 à 5) couvre l'inventaire, la gouvernance, la maîtrise de l'écosystème, la sécurité RH et le cycle de vie des systèmes. Le bloc Protection technique (6 à 11) traite des accès, de l'architecture, des codes malveillants et de l'administration. Le bloc Résilience (12 à 15) porte sur les incidents, la continuité, la crise et les exercices. Le bloc Excellence (16 à 20) ne vise que les entités essentielles.

Un site vitrine ou un portail public n'est jamais l'actif le plus sensible d'une organisation. Il est en revanche presque toujours l'actif le plus exposé : accessible depuis internet en permanence, indexé, souvent construit sur un CMS dont le code est public, et fréquemment maintenu par un tiers. Dans une démarche ReCyF, il concentre donc un nombre d'objectifs disproportionné par rapport à sa valeur métier.

Concrètement, six objectifs le touchent directement. L'objectif 1 (recensement des systèmes d'information) impose de le faire figurer à l'inventaire, avec son hébergeur, son CMS, sa version et son responsable. L'objectif 3 (maîtrise de l'écosystème) porte sur son prestataire. L'objectif 5 (cycle de vie) porte sur ses versions et ses fins de support. L'objectif 7 (sécurisation de l'architecture) et l'objectif 8 (accès distants) portent sur son exposition et sur les accès d'administration. Les objectifs 12 à 14 portent sur ce qui se passe quand il tombe ou quand il est compromis.

Cette lecture a une vertu : elle sort le site web du périmètre marketing, où il est souvent rangé, pour le replacer dans le périmètre système d'information. Dans beaucoup d'organisations, personne n'a jamais tranché la question de savoir qui, de la direction de la communication ou de la direction des systèmes d'information, répond du site. Le ReCyF force cet arbitrage, parce que l'objectif 2 (cadre de gouvernance) demande un responsable nommé.

Objectif 3 : votre prestataire web devient un tiers à contrôler

L'objectif 3 du ReCyF porte sur la maîtrise de l'écosystème, c'est-à-dire des tiers et de la chaîne d'approvisionnement. Il prolonge l'article 21 de la directive NIS2, qui impose aux entités de prendre en compte la sécurité de leurs fournisseurs directs. Une agence web qui détient les accès d'administration, les clés FTP ou SSH et les sauvegardes d'un site entre sans ambiguïté dans ce périmètre.

C'est le point le plus mal anticipé du référentiel, parce qu'il déplace la conformité vers un endroit que les entreprises ne regardent pas : leurs contrats de prestation. Une organisation peut avoir une politique de mots de passe irréprochable en interne et confier, dans le même temps, un accès administrateur permanent à un prestataire qui l'utilise depuis un poste partagé, sans double authentification, et qui conserve ces accès des années après la fin du projet.

Dans les faits, voici ce que l'objectif 3 rend difficile à maintenir en l'état :

• les comptes d'administration nominatifs d'anciens intervenants jamais désactivés, situation extrêmement courante sur les sites qui ont changé d'agence ;
• les accès partagés entre plusieurs personnes d'un même prestataire, qui rendent toute traçabilité impossible ;
• l'absence de clause de sécurité dans le contrat de maintenance, alors que le prestataire dispose d'un accès privilégié ;
• l'absence de procédure de réversibilité, qui interdit de récupérer rapidement le contrôle en cas de défaillance du tiers ;
• les sauvegardes stockées uniquement chez le prestataire, sans copie détenue par le client.

Le dernier point est celui qui surprend le plus les directions. Une sauvegarde qui n'existe que sur l'infrastructure du prestataire n'est pas une sauvegarde au sens de l'objectif 13 : elle disparaît avec lui, qu'il s'agisse d'un litige, d'une liquidation judiciaire ou d'une compromission de sa propre infrastructure. Les attaques par la chaîne d'approvisionnement visant des prestataires numériques ont précisément cette mécanique : compromettre un intervenant pour atteindre ses dizaines de clients d'un coup.

La réponse opérationnelle tient en trois éléments vérifiables : des accès nominatifs et révocables, une clause de sécurité et de réversibilité dans le contrat, et une copie des sauvegardes détenue par le client sur une infrastructure qu'il contrôle. Ces trois éléments se négocient au renouvellement du contrat de maintenance et ne coûtent rien d'autre que la volonté de les écrire.

Objectif 5 : le cycle de vie, là où les sites vitrines décrochent

L'objectif 5 porte sur la maîtrise du cycle de vie des systèmes d'information. Traduit pour un site web, il demande de savoir sur quelle version de CMS, de langage et de composants le site tourne, quelles sont les dates de fin de support de ces briques, et quel plan couvre leur remplacement. C'est l'objectif le plus simple à formuler et celui que les sites d'entreprise échouent le plus souvent à satisfaire.

Les échéances ne sont pas théoriques. PHP 8.1 est en fin de vie depuis le 31 décembre 2025 : plus aucun correctif, y compris de sécurité, n'est publié. PHP 8.2 voit son support sécurité s'arrêter le 31 décembre 2026, son support actif ayant pris fin le 31 décembre 2024. Un site qui tourne aujourd'hui sur PHP 8.1 est déjà hors support ; un site sur PHP 8.2 le sera dans un peu plus de quatre mois.

La difficulté pratique n'est jamais la version de PHP elle-même : c'est la dépendance qui bloque la montée. Un composant abandonné, un thème sur mesure écrit pour une version antérieure, une extension commerciale dont la licence a expiré. Sur les sites que nous reprenons, le point de blocage est presque toujours un composant unique, souvent installé pour une fonctionnalité marginale, et jamais remplacé parce que personne n'a fait le lien entre lui et l'impossibilité de mettre à jour l'ensemble.

Un plan de cycle de vie utile tient sur une page : la liste des briques, leur version, leur date de fin de support, et pour chacune une décision datée (mettre à jour, remplacer, retirer, accepter le risque en le documentant). Cette page est exactement ce qu'un contrôle attend. Elle se construit en une demi-journée d'audit de site web et se met à jour au fil des interventions.

Objectifs 12 à 15 : incident, continuité, crise et exercices

Le bloc Résilience regroupe quatre objectifs applicables aux entités importantes comme aux entités essentielles : identification et réaction aux incidents (12), continuité et reprise d'activité (13), réaction aux crises cyber (14), exercices, tests et entraînements (15). Ce sont les objectifs qui produisent les preuves les plus lisibles, et ceux sur lesquels un contrat de maintenance de site web pèse le plus directement.

L'objectif 12 suppose de savoir qu'un incident a lieu. Un site vitrine sans supervision externe est découvert en panne par un client, un commercial ou un moteur de recherche, avec plusieurs heures de retard. La supervision indépendante de l'hébergement, avec alerte et horodatage, transforme une découverte fortuite en événement daté et traçable. Cette datation est ce qui permet, ensuite, de respecter les délais de notification prévus par NIS2.

L'objectif 13 impose des sauvegardes et une capacité de reprise. La question qui compte n'est pas de savoir si des sauvegardes existent, mais quand la dernière restauration a été testée. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Sur un site sous CMS, les causes classiques d'échec sont connues : base de données exportée sans les fichiers, fichiers sauvegardés sans la base, absence de la configuration serveur, ou archive complète mais illisible parce que le format a changé de version.

L'objectif 14 demande de savoir qui fait quoi pendant une crise. Pour un site web, la question tient en trois lignes : qui décide de couper le site, qui prévient les utilisateurs, qui parle à l'hébergeur. Écrire ces trois lignes coûte une heure et évite les deux journées de flottement qui suivent habituellement un défacement ou une compromission.

L'objectif 15 demande de tester. Une restauration annuelle documentée, avec sa date, sa durée et son résultat, est la preuve la plus économique du référentiel. Elle rend simultanément vérifiables les objectifs 13 et 15. Beaucoup d'organisations dépensent des sommes considérables en outils de sécurité sans jamais avoir mesuré combien de temps prend la remise en ligne de leur site à partir d'une sauvegarde.

Les preuves qu'un contrat de maintenance doit produire

Le ReCyF ne demande pas des intentions, il demande des preuves datées. Un contrat de maintenance de site web bien construit en produit naturellement cinq ou six, à condition que les livrables soient écrits dans le contrat et non laissés à l'appréciation du prestataire. C'est le déplacement principal que le référentiel impose aux acheteurs : passer d'un contrat de moyens à un contrat de traces.

Les preuves qu'un contrat sérieux doit produire, et qu'un contrôle ANSSI saura lire :

• le registre des mises à jour : quelle brique, quelle version, quelle date, quel intervenant. Il alimente les objectifs 5 et 9 ;
• le rapport de supervision : disponibilité mesurée, incidents détectés, heure de détection et heure de rétablissement. Objectifs 12 et 13 ;
• le test de restauration daté : périmètre restauré, durée, écarts constatés. Objectifs 13 et 15 ;
• la revue des accès : liste nominative des comptes disposant d'un accès privilégié, avec les désactivations effectuées. Objectifs 3, 10 et 11 ;
• le plan de cycle de vie : versions, dates de fin de support, décisions datées. Objectif 5 ;
• le journal des incidents : qualification, actions, clôture. Objectifs 12 et 14.

Aucun de ces livrables n'est exotique. Ce sont les sous-produits normaux d'une maintenance faite correctement. La différence entre une organisation prête et une organisation en difficulté ne tient presque jamais à la qualité technique du travail : elle tient à sa traçabilité. Un prestataire qui met à jour consciencieusement sans jamais rien consigner met son client en défaut sur un référentiel qui fonctionne par démonstration.

Pour une organisation qui gère plusieurs sites, souvent hérités de directions ou d'entités différentes, la difficulté change de nature : elle devient un problème d'inventaire avant d'être un problème de sécurité. C'est le sens de l'objectif 1, et c'est la raison pour laquelle l'infogérance d'un parc digital commence toujours par un recensement exhaustif, y compris des sites que plus personne ne revendique.

Hors périmètre ? L'effet ruissellement va vous atteindre

Une PME de 30 salariés dans un secteur non listé n'est ni entité essentielle ni entité importante. Elle n'a aucune obligation directe. Elle recevra pourtant, dans les prochains mois, des questionnaires de sécurité de la part de ses clients régulés, parce que l'objectif 3 oblige ces derniers à contrôler leurs fournisseurs. C'est le mécanisme par lequel NIS2 dépasse largement les 15 000 entités officiellement visées.

Ce phénomène est déjà documenté sur d'autres réglementations : le RGPD a diffusé ses exigences par les clauses de sous-traitance bien au-delà des responsables de traitement, et la CSRD diffuse aujourd'hui ses demandes de données environnementales à des fournisseurs qui n'y sont pas soumis. NIS2 suivra le même chemin, avec une différence : le questionnaire de sécurité arrive souvent au moment du renouvellement d'un contrat, donc avec un enjeu commercial immédiat.

Pour une agence, une ESN, un éditeur ou un hébergeur, la conséquence est directe : la capacité à répondre à ces questionnaires devient un actif commercial. Pour une entreprise cliente, elle devient un critère de sélection. Nous constatons déjà, dans les consultations de marchés publics, l'apparition de questions sur la gestion des accès prestataires et sur la localisation des sauvegardes, là où le cahier des charges se limitait auparavant à un engagement de disponibilité.

Le calcul est simple : les mesures qui répondent à ces questionnaires sont les mêmes que celles qui protègent réellement le site. Renforcer la sécurité d'un site web pour satisfaire un client régulé produit exactement le même résultat que la renforcer pour soi.

Six mois pour se mettre en position

La fenêtre entre aujourd'hui et les premiers contrôles est courte mais suffisante, à condition de traiter les objectifs dans l'ordre où ils produisent des preuves. Voici la séquence que nous appliquons chez nos clients, et qui tient dans un semestre sans budget exceptionnel.

Mois 1 : vérifier le statut et inventorier. Passer le test d'éligibilité MonEspaceNIS2 et consigner le résultat, quel qu'il soit. Puis établir l'inventaire des actifs exposés : sites, sous-domaines, environnements de préproduction oubliés, formulaires, API. Cet inventaire est l'objectif 1 et conditionne tout le reste.

Mois 2 : reprendre le contrôle des accès. Lister nominativement tous les comptes disposant d'un accès privilégié, y compris ceux des prestataires actuels et passés. Désactiver ce qui ne se justifie plus. Activer la double authentification sur les administrations et sur les accès distants. Objectifs 8, 10 et 11, pour un coût quasi nul.

Mois 3 : sécuriser la chaîne de sauvegarde. Vérifier que le périmètre sauvegardé comprend la base, les fichiers et la configuration. Obtenir une copie détenue par l'entreprise, sur une infrastructure distincte de celle du prestataire. Documenter la fréquence et la durée de rétention.

Mois 4 : établir le plan de cycle de vie. Recenser versions et dates de fin de support, décider pour chaque brique, dater la décision. C'est le moment où les migrations lourdes, PHP en tête, doivent être budgétées et non découvertes.

Mois 5 : tester la reprise. Restaurer réellement, sur un environnement séparé, et chronométrer. Consigner la durée, les écarts et les correctifs apportés à la procédure. Ce document unique couvre les objectifs 13 et 15.

Mois 6 : écrire la gouvernance. Nommer le responsable du site, écrire la procédure de crise en trois lignes, formaliser la clause de sécurité et de réversibilité dans le contrat de maintenance. Objectifs 2, 3 et 14.

À l'issue de ce semestre, une organisation dispose d'un dossier au format attendu par le ReCyF : pour chaque objectif applicable, une mesure, une preuve, une date. Ce dossier ne garantit pas l'absence d'incident. Il garantit que l'incident sera détecté, tracé, notifié dans les délais et réparé à partir d'une sauvegarde éprouvée. C'est exactement ce que le référentiel demande.

Questions fréquentes sur le ReCyF et NIS2

Le ReCyF est-il obligatoire aujourd'hui ?

Non. Il s'agit d'une version de travail publiée le 17 mars 2026, sans portée contraignante tant que la loi Résilience n'est pas promulguée et que ses textes d'application ne sont pas parus. Les objectifs qu'il décline ont vocation à devenir l'obligation réglementaire française, et une entité qui les applique par anticipation pourra s'en prévaloir lors d'un contrôle.

Mon site vitrine me fait-il entrer dans le périmètre NIS2 ?

Non. L'éligibilité se détermine par le secteur d'activité et la taille de l'organisation, jamais par la nature d'un actif informatique. Un site web ne rend personne entité essentielle. En revanche, dès lors qu'une organisation est dans le périmètre, son site web y entre avec elle, au titre de l'inventaire des systèmes d'information et de l'exposition sur internet.

Mon agence web doit-elle être conforme à NIS2 ?

Pas nécessairement à titre personnel. Mais si elle intervient pour une entité régulée, celle-ci devra démontrer qu'elle maîtrise ce fournisseur au titre de l'objectif 3. Concrètement, l'agence devra fournir des accès nominatifs et révocables, accepter une clause de sécurité et de réversibilité, et permettre au client de détenir sa propre copie des sauvegardes.

Quel est le lien entre le ReCyF et l'ISO 27001 ?

Les deux se renforcent. L'ISO/IEC 27001:2022 est une norme certifiable de système de management, le ReCyF un référentiel réglementaire adossé à NIS2. Les recouvrements sont larges sur la gouvernance, les accès, les incidents et la continuité. L'ANSSI publie sur MesServicesCyber un comparateur officiel qui met chaque objectif du ReCyF en correspondance avec les référentiels existants.

Par quoi commencer avec un budget limité ?

Par l'inventaire et la revue des accès. Ces deux chantiers ne coûtent que du temps, produisent des preuves immédiatement présentables et conditionnent la valeur de tout ce qui viendra ensuite. Le test de restauration arrive juste après : c'est la mesure au meilleur rapport entre effort consenti et risque réellement écarté.

Faire l'inventaire avant que la loi ne le demande

Pulsar Agency maintient des sites web d'entreprises et de collectivités depuis 2005, en Île-de-France et dans les Hauts-de-France. Nos contrats produisent déjà l'essentiel des preuves attendues par le ReCyF : registre des mises à jour, supervision horodatée, restauration testée, revue des accès. Si votre organisation entre dans le périmètre NIS2, ou si vos clients commencent à vous interroger sur vos prestataires, le point de départ est un état des lieux daté de vos sites et de leurs accès. C'est l'objet de notre audit de site web, et le meilleur usage possible des mois qui précèdent la promulgation.