Failles signalées en 24 h : ce que le CRA change pour votre site

Depuis le 11 septembre 2026, les failles ont une horloge de 24 heures

Depuis le 11 septembre 2026, tout éditeur qui vend un logiciel dans l'Union européenne, y compris une extension WordPress, un template Joomla ou un module Drupal commercial, doit signaler toute faille activement exploitée dans un délai de 24 heures. C'est la première obligation du Cyber Resilience Act à entrer en application. Votre site n'est pas directement visé, mais tout ce qui le compose l'est.

Le Cyber Resilience Act, ou CRA, est le règlement (UE) 2024/2847. Il est entré en vigueur le 10 décembre 2024 et s'applique par étapes. La Commission européenne le rappelle sur sa page consacrée aux obligations de signalement : depuis le 11 septembre 2026, les fabricants doivent notifier les vulnérabilités activement exploitées et les incidents graves qui touchent la sécurité de leurs produits. Le calendrier est précis : une alerte précoce sous 24 heures, une notification complète sous 72 heures, puis un rapport final au plus tard 14 jours après la mise à disposition d'un correctif.

Ces notifications passent par une plateforme unique gérée par l'ENISA, l'agence européenne de cybersécurité, et sont transmises au CSIRT coordinateur du pays où l'éditeur est établi. Pour la France, il s'agit du CERT-FR de l'ANSSI. L'application complète du règlement, avec le marquage CE des logiciels, les exigences de conception sécurisée et les contrôles des autorités de surveillance du marché, interviendra le 11 décembre 2027.

Pour une direction marketing ou une DSI qui gère un site vitrine sous WordPress, Joomla ou Drupal, la question n'est donc pas « devons-nous signaler quelque chose ? », mais plutôt « que change ce nouveau rythme pour la sécurité de notre site, et notre maintenance est-elle capable de suivre ? ». C'est l'objet de ce billet.

Votre site vitrine est-il concerné par le CRA ?

Une entreprise qui exploite son propre site vitrine n'est en règle générale pas « fabricant » au sens du Cyber Resilience Act : elle utilise des logiciels, elle ne les met pas sur le marché. Le règlement vise les produits comportant des éléments numériques fournis dans le cadre d'une activité commerciale, donc les éditeurs de CMS, d'extensions et de thèmes. Votre site est concerné indirectement, par sa chaîne d'approvisionnement logicielle.

La définition est large. Selon le résumé publié par la Commission, un « produit comportant des éléments numériques » est un produit logiciel ou matériel, y compris ses composants mis sur le marché séparément. Un fabricant est la personne qui développe un tel produit et le commercialise sous son nom, que ce soit contre paiement, par monétisation ou gratuitement. Une extension premium vendue sur un marketplace, un template Joomla commercial ou un module Drupal proposé avec une offre payante entrent donc dans le champ.

Le cas des logiciels libres est traité à part. Un projet open source publié sans activité commerciale n'est pas « mis sur le marché » au sens du texte. En revanche, le règlement crée la figure de l'intendant de logiciel libre (open-source software steward) : une personne morale qui soutient de façon durable le développement d'un logiciel libre destiné à un usage commercial. Ces intendants ont des obligations allégées, ne sont pas passibles d'amendes au titre du CRA, et leurs obligations de signalement ne s'appliquent qu'à partir du 11 décembre 2027. Les organisations qui portent les grands CMS libres pourraient relever de ce régime ; c'est à elles de le déterminer.

Trois situations méritent tout de même votre attention :

• Vous distribuez un logiciel : si votre entreprise commercialise une application, un plugin ou un objet connecté, même accessoirement à votre site, vous pouvez être fabricant. Le sujet sort alors du périmètre de la maintenance web et relève d'une analyse juridique dédiée.
• Votre site s'appuie sur des développements spécifiques : une extension écrite sur mesure par une agence pour votre seul usage ne se traite pas comme une extension vendue à des milliers de clients. La qualification dépend des contrats et de l'usage ; les lignes directrices de la Commission détaillent ces cas.
• Vous êtes vous-même soumis à NIS2 : dans ce cas, vos propres obligations de gestion des risques et de notification d'incidents à l'ANSSI s'ajoutent à celles que le CRA fait peser sur vos fournisseurs. Nous avons détaillé ce cadre dans notre billet sur NIS2 et la loi Résilience.

En pratique, pour la grande majorité des PME et des grands comptes qui nous confient leur site, le CRA ne crée pas d'obligation déclarative nouvelle. Il change la qualité, la quantité et la vitesse des informations de sécurité qui arrivent à l'équipe qui maintient le site.

Ce que le CRA impose aux éditeurs d'extensions, de thèmes et de CMS

Le CRA impose aux éditeurs de logiciels vendus en Europe de gérer leurs vulnérabilités tout au long d'une période de support annoncée, de publier les correctifs gratuitement et sans retard, de documenter leurs composants dans une nomenclature logicielle et, depuis septembre 2026, de signaler les failles exploitées. Pour un site, cela signifie plus d'avis de sécurité, publiés plus vite.

L'ANSSI détaille ces exigences sur sa page consacrée au cadre réglementaire du CRA. Côté gestion des vulnérabilités, les fabricants doivent notamment :

• identifier et documenter les composants de leur produit, via une nomenclature logicielle (SBOM) lisible par machine couvrant au moins les dépendances de premier niveau ;
• corriger sans délai les vulnérabilités identifiées, si possible avec des mises à jour de sécurité séparées des mises à jour fonctionnelles ;
• publier des informations sur les failles corrigées : description, versions affectées, impact, mesures de remédiation ;
• mettre en place une politique de divulgation coordonnée des vulnérabilités, c'est-à-dire un canal documenté pour recevoir et traiter les signalements des chercheurs ;
• distribuer les correctifs de manière sécurisée, gratuitement, accompagnés d'avis utiles aux utilisateurs.

Le règlement ajoute une obligation qui intéresse directement les acheteurs : la date de fin de la période de support, avec le mois et l'année, doit être indiquée clairement au moment de l'achat. Pendant cette période, l'éditeur s'engage à traiter les vulnérabilités. C'est une information que les sites n'avaient presque jamais pour leurs extensions commerciales.

Les sanctions sont dissuasives. En France, la surveillance du marché est confiée à l'Agence nationale des fréquences (ANFR), qui pourra imposer le retrait d'un produit du marché ou des amendes allant jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial du fabricant. Deux tempéraments existent : les micro et petites entreprises ne peuvent pas être sanctionnées pour un simple dépassement du délai de 24 heures, et les intendants de logiciels libres ne sont pas passibles d'amendes.

Conséquence attendue dans l'écosystème des CMS : une partie des éditeurs d'extensions va structurer sa gestion des failles, souvent en la confiant à des plateformes spécialisées. Patchstack indique déjà gérer les signalements de vulnérabilités pour plus de 1 000 éditeurs d'extensions WordPress. D'autres, en particulier de petits éditeurs hors Union européenne, pourraient au contraire cesser de commercialiser leurs produits en Europe ou les laisser vieillir. Pour un site, c'est un risque de composant orphelin à anticiper.

Pourquoi le signalement en 24 heures ne protège pas votre site à lui seul

Le signalement en 24 heures accélère la circulation de l'information, mais il ne corrige rien sur votre serveur. Les attaques automatisées démarrent souvent quelques heures après la publication d'une faille, et près de la moitié des vulnérabilités sont rendues publiques avant qu'un correctif n'existe. La protection réelle dépend donc du délai entre l'avis de sécurité et l'action sur votre site.

Les chiffres du rapport State of WordPress Security in 2026 de Patchstack, publié le 25 février 2026 sur les données de 2025, illustrent l'écart :

• 11 334 nouvelles vulnérabilités recensées dans l'écosystème WordPress en 2025, soit 42 % de plus qu'en 2024 ;
• 91 % d'entre elles concernaient des extensions, 9 % des thèmes, et seulement 6 vulnérabilités, de faible priorité, le cœur de WordPress ;
• 46 % des vulnérabilités n'avaient pas reçu de correctif de l'éditeur au moment de leur divulgation publique ;
• pour les failles les plus exploitées, le délai médian pondéré avant la première exploitation de masse était de 5 heures ;
• les composants premium présentaient trois fois plus de vulnérabilités exploitées en conditions réelles que les composants gratuits ;
• lors de tests menés chez des hébergeurs, les protections réseau classiques (pare-feu applicatifs génériques, CDN) n'ont bloqué que 26 % des attaques visant des vulnérabilités.

Le même rapport observe que les dépôts de fichiers malveillants ont presque triplé en novembre et décembre 2025, période où le trafic est fort et les équipes réduites. Nous entrons dans cette fenêtre.

Le CRA devrait améliorer le troisième chiffre, celui des failles sans correctif, puisque les éditeurs concernés doivent désormais traiter les vulnérabilités sans délai pendant leur période de support. Il ne change rien au quatrième : un avis publié à 9 heures peut être exploité à 14 heures. Entre les deux, seule l'équipe qui maintient votre site peut agir : appliquer le correctif, désactiver le composant, poser une règle de filtrage ciblée ou mettre une fonctionnalité hors ligne le temps de la correction.

C'est pour cette raison que la cadence de maintenance mensuelle, encore courante, n'est plus adaptée aux composants exposés. Le cœur de WordPress l'a d'ailleurs rappelé cet automne : la version 7.1.4, publiée le 28 octobre 2026, est une version de sécurité corrigeant plusieurs problèmes, après la 7.1.3 d'octobre et la 7.1.2 de septembre, qui corrigeait une vulnérabilité de gravité critique. Le détail est consultable sur la page des versions de WordPress.

L'inventaire des composants : la nomenclature logicielle de votre site

Pour profiter des avis de sécurité que le CRA va multiplier, il faut savoir précisément ce qui tourne sur votre site : version du CMS, de PHP, de chaque extension, de chaque thème et de chaque bibliothèque, avec leur éditeur et leur date de fin de support. Sans cet inventaire, un avis du CERT-FR ou d'un éditeur ne peut pas être rapproché de votre site.

Le CRA demande aux fabricants de produire une nomenclature logicielle, la SBOM (Software Bill of Materials). Rien n'oblige l'exploitant d'un site à faire de même, mais le principe est directement utile. Un inventaire exploitable tient en un tableau, tenu à jour à chaque intervention :

• Socle : CMS et version exacte (par exemple WordPress 7.1.4, Joomla 5.4.10 ou 6.2.0, Drupal 11.x), version de PHP, base de données, serveur web.
• Extensions et thèmes : nom, version installée, éditeur, type de licence (libre, freemium, premium), source d'installation (répertoire officiel, marketplace, développement spécifique), date de la dernière mise à jour publiée.
• Bibliothèques embarquées : dépendances Composer ou npm des développements spécifiques, souvent oubliées alors qu'elles reçoivent elles aussi des avis de sécurité.
• Informations CRA : date de fin de support annoncée par l'éditeur quand elle existe, présence d'une politique de divulgation des vulnérabilités, canal de publication des avis.
• Criticité : rôle du composant sur le site (formulaire de contact, paiement, espace membre, simple affichage), exposition publique, données traitées.

Cet inventaire a un second intérêt : il fait apparaître les composants inutiles. Sur les sites que nous reprenons, il n'est pas rare de trouver des extensions désactivées mais toujours présentes, des thèmes par défaut jamais supprimés ou des modules installés pour un besoin ponctuel il y a plusieurs années. Chaque composant supprimé est un avis de sécurité de moins à surveiller.

Si vous ne disposez d'aucun inventaire fiable, ou si plusieurs prestataires sont intervenus sur le site, un audit de site web permet de l'établir et de prioriser les écarts avant de fixer une cadence de maintenance.

Choisir ses extensions à l'ère du CRA

À partir de maintenant, une extension se choisit autant sur la qualité de sa gestion des failles que sur ses fonctionnalités : éditeur identifiable, période de support annoncée, canal de signalement documenté, historique de correctifs rapides. Une extension sans éditeur clairement responsable devient un risque de continuité, pas seulement de sécurité.

Voici la grille que nous appliquons lors de l'ajout ou de la revue d'un composant :

1. L'éditeur est-il identifiable et joignable ? Raison sociale, adresse, contact sécurité. Le CRA impose ces informations aux fabricants ; leur absence en 2027 sera un signal d'alerte.
2. Une période de support est-elle annoncée ? Une date de fin de support exprimée en mois et année permet d'anticiper un remplacement plutôt que de le subir.
3. Existe-t-il une politique de divulgation des vulnérabilités ? Une page « Security » ou un programme de divulgation géré par un tiers montre que les signalements ont un circuit de traitement.
4. Quel est l'historique de correction ? Le délai entre la divulgation d'une faille passée et la publication du correctif est le meilleur indicateur du comportement futur de l'éditeur.
5. Le composant est-il remplaçable ? Une extension qui stocke vos contenus dans un format propriétaire coûte cher à abandonner. À fonctionnalité égale, préférez celle dont la sortie est simple.
6. Le besoin justifie-t-il un composant ? Une fonctionnalité réalisable proprement avec le cœur du CMS ou quelques lignes de code maintenues réduit la surface d'attaque.

Cette grille vaut pour les trois CMS que nous maintenons le plus. Sous Joomla, la branche 5 n'est plus qu'en correctifs de sécurité depuis le 13 octobre 2026 et jusqu'au 12 octobre 2027, selon la feuille de route officielle ; les extensions qui n'ont pas annoncé leur compatibilité avec Joomla 6 doivent déjà être identifiées. Sous Drupal, la fin de vie de Drupal 10 le 9 décembre 2026 provoque le même tri parmi les modules contribués. Sous WordPress, l'enjeu porte surtout sur les extensions premium achetées sur des marketplaces, dont le rapport Patchstack souligne la moindre visibilité pour les chercheurs.

Ce que votre contrat de maintenance doit prévoir en 2027

Un contrat de maintenance adapté au rythme du CRA doit fixer un délai d'application des correctifs de sécurité selon leur gravité, prévoir une veille active sur les composants réellement installés, autoriser des mesures d'atténuation immédiates quand aucun correctif n'existe, et rendre compte de ces actions. Une simple mention « mises à jour mensuelles » ne suffit plus.

Concrètement, voici les clauses que nous recommandons de vérifier lors de la reconduction de votre contrat :

• Délai d'application par niveau de gravité : par exemple sous 24 heures ouvrées pour une faille critique exploitée sur un composant installé, sous quelques jours pour une faille élevée, au cycle normal pour le reste. Ce délai doit courir à partir de la publication de l'avis, pas de la prochaine intervention planifiée.
• Veille ciblée : rapprochement automatique des avis de sécurité (éditeurs, bases de vulnérabilités, avis du CERT-FR) avec l'inventaire du site, et non lecture générale de l'actualité.
• Mesures d'atténuation : droit pour le prestataire de désactiver temporairement une extension, de bloquer une route d'API ou de poser une règle de filtrage ciblée (virtual patching) quand le correctif n'existe pas encore, avec information immédiate du client.
• Préproduction et sauvegarde : test des correctifs majeurs sur un environnement de préproduction, sauvegarde vérifiée avant chaque mise à jour, restauration possible en moins d'une heure.
• Traçabilité : rapport mensuel listant les versions mises à jour, les avis traités, les délais réels d'application et les composants à remplacer. En cas d'incident, ce journal sert aussi vis-à-vis d'un assureur ou d'un auditeur NIS2.
• Revue annuelle des composants : passage en revue de l'inventaire avec la grille de choix ci-dessus, et plan de remplacement des composants orphelins ou en fin de support.

Ces exigences correspondent à ce que nous intégrons dans nos contrats de maintenance web. Pour les sites les plus exposés, la couche de sécurité de site web ajoute la surveillance continue et le filtrage ciblé.

Un point mérite d'être précisé au moment de signer : le prestataire de maintenance n'est pas responsable des failles des logiciels tiers, mais il est responsable du délai dans lequel il les traite. C'est ce délai, et non une promesse générale de « sécurité », qui doit figurer au contrat.

Le calendrier à retenir, de novembre 2026 à décembre 2027

Les quatorze prochains mois concentrent plusieurs échéances qui se cumulent sur un même site : fin de vie de Drupal 10 le 9 décembre 2026, fin du support de sécurité de PHP 8.2 le 31 décembre 2026, fin du support de Joomla 5 le 12 octobre 2027 et application complète du CRA le 11 décembre 2027. Les planifier ensemble coûte moins cher que de les traiter une à une.

• Depuis le 11 septembre 2026 : signalement obligatoire des failles exploitées par les fabricants, via la plateforme de l'ENISA et le CERT-FR pour les éditeurs établis en France.
• Novembre et décembre 2026 : période de pic d'attaques observée en 2025 par Monarx et Patchstack ; c'est le moment de vérifier les sauvegardes et la réactivité de la maintenance.
• 9 décembre 2026 : fin de vie de Drupal 10. Les sites qui n'ont pas migré vers Drupal 11 ne recevront plus de correctifs de sécurité. Nous avons détaillé les options dans notre billet consacré à cette échéance.
• 31 décembre 2026 : fin du support de sécurité de PHP 8.2, selon le calendrier officiel de PHP. PHP 8.3 reste couvert jusqu'au 31 décembre 2027, PHP 8.4 jusqu'au 31 décembre 2028 et PHP 8.5 jusqu'au 31 décembre 2029.
• 12 octobre 2027 : fin du support de sécurité de Joomla 5. Joomla 6.2 est disponible depuis le 13 octobre 2026.
• 11 décembre 2027 : application complète du CRA. Les produits mis sur le marché doivent être conformes, porter le marquage CE et indiquer leur période de support ; l'ANFR peut contrôler. Les obligations de signalement des intendants de logiciels libres démarrent à la même date.

Si vous gérez plusieurs sites, ces échéances ne tombent pas au même moment sur chacun d'eux selon leur CMS et leur version de PHP. Un tableau de bord commun évite de découvrir une fin de support la semaine où elle s'applique ; c'est le principe de l'infogérance de parc digital.

Ce que coûte une maintenance qui suit ce rythme

En France en 2026, une maintenance de site vitrine limitée aux mises à jour mensuelles et aux sauvegardes se situe généralement entre 60 et 150 euros HT par mois. Dès qu'on ajoute une veille ciblée, un délai d'application garanti, de la surveillance et quelques heures d'évolution, les grilles publiées montent plutôt entre 250 et 600 euros HT par mois.

Ces fourchettes proviennent de grilles d'agences publiées en 2026, en particulier celles de Kolonell pour plusieurs villes françaises. Elles restent indicatives : il n'existe pas d'enquête de marché indépendante sur ce sujet, et le prix dépend du CMS, du nombre de composants, des développements spécifiques et du niveau d'engagement. Quelques repères relevés dans ces grilles :

• un rattrapage initial de 400 à 900 euros HT est fréquemment facturé avant le démarrage d'un forfait lorsque le site accuse un retard de mises à jour ;
• les formules de niveau supérieur affichent des mises à jour de sécurité appliquées dès la publication du correctif, là où les formules d'entrée de gamme les regroupent une fois par mois ;
• un délai maximal d'environ 72 heures après une faille critique est présenté comme un minimum raisonnable, alors que les données de Patchstack montrent que l'exploitation de masse peut commencer en quelques heures.

Le bon calcul n'oppose pas le prix du forfait à zéro, mais au coût d'un incident. Un site piraté, c'est une intervention de nettoyage et de remise en service en urgence, souvent une perte de référencement si des pages de spam ont été injectées, parfois une notification à la CNIL si des données personnelles ont fuité. Si cela arrive, notre service de dépannage intervient, mais l'objectif d'un contrat bien construit est précisément de ne pas en arriver là.

Pour cadrer votre budget 2027, partez de l'inventaire : un site avec dix extensions maintenues par des éditeurs solides ne demande pas le même effort qu'un site avec quarante composants, dont un tiers d'origine incertaine. Réduire le nombre de composants est souvent l'économie la plus durable.

Passer à une maintenance au rythme du CRA avec Pulsar Agency

Le Cyber Resilience Act ne vous demande pas de devenir expert en réglementation européenne : il demande à vos fournisseurs de logiciels de mieux gérer leurs failles. Votre part consiste à savoir ce qui compose votre site et à confier sa maintenance à une équipe capable d'agir dans les heures qui suivent un avis de sécurité.

Depuis 2005, Pulsar Agency maintient des sites existants sous WordPress, Joomla, Drupal et PrestaShop pour des PME et des grands comptes, depuis Luzarches en Île-de-France et Lamorlaye dans les Hauts-de-France. Concrètement, nous vous proposons de :

• dresser l'inventaire complet des composants de votre site, avec leur éditeur, leur période de support et leur criticité ;
• supprimer ou remplacer les composants inutiles, orphelins ou en fin de support ;
• fixer contractuellement des délais d'application des correctifs adaptés à la gravité des failles ;
• planifier en un seul calendrier les échéances de PHP, de votre CMS et du CRA.

Pour faire le point sur votre site avant la fin de l'année, découvrez notre contrat de maintenance web et contactez-nous : nous commencerons par l'inventaire, qui est la base de tout le reste.

Questions fréquentes sur le Cyber Resilience Act et votre site web