Le 11 septembre 2026, les obligations opérationnelles du Cyber Resilience Act entrent en vigueur. La majorité des équipes techniques se sont concentrées sur les délais de notification : 24 heures pour l'alerte initiale à l'ENISA, 72 heures pour la notification complète, 14 jours pour le rapport final. Ces délais concernent les vulnérabilités que vous détectez vous-mêmes. Il existe une seconde obligation, souvent négligée : la politique de divulgation coordonnée des vulnérabilités. C'est le document qui régit la porte d'entrée inverse — comment un chercheur en sécurité, un utilisateur ou un partenaire peut vous signaler une faille. Dans trois jours, son absence constitue une non-conformité.
Ce que le règlement exige exactement
Le règlement (UE) 2024/2847, à son article 13 paragraphe 6, oblige tout fabricant ou éditeur de produits comportant des éléments numériques à mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités. L'article 14 précise que cette politique doit s'accompagner d'un point de contact unique, public et accessible, par lequel les tiers peuvent soumettre leurs signalements.
La distinction avec les délais de notification est fondamentale. Les 24 heures et 72 heures s'appliquent à une vulnérabilité activement exploitée que votre organisation détecte dans son propre produit. La politique CVD (Coordinated Vulnerability Disclosure) s'applique à un flux entrant : quelqu'un d'extérieur à votre organisation a trouvé une faille dans votre produit et cherche un canal pour vous en informer. Sans politique formalisée, ce chercheur n'a aucune porte à laquelle frapper. Il publie directement, ou il abandonne. Dans les deux cas, vous avez perdu la chance de corriger avant l'exploitation.
La Commission européenne aligne explicitement cette obligation sur la norme ISO/IEC 29147:2018, qui définit le contenu attendu d'une politique de divulgation responsable, et sur ISO/IEC 30111:2019, qui couvre les processus de traitement interne des vulnérabilités signalées. Un fichier security.txt avec une adresse e-mail ne constitue pas une politique au sens du règlement.
Pourquoi la plupart des éditeurs n'ont pas encore formalisé
La Commission européenne estime que 60 % des fabricants concernés par le CRA sont des PME (impact assessment du règlement CRA, octobre 2024). Pour ces structures, l'absence de politique CVD est rarement un choix délibéré : c'est un non-sujet qui n'a jamais été traité parce que personne n'a reçu de signalement externe auparavant. Cette logique est inversée par le règlement : la politique doit exister avant le premier rapport, pas en réponse à lui.
Les grandes organisations disposent souvent d'une boîte security@, parfois d'un fichier security.txt. Elles pensent avoir couvert le sujet. Ce n'est pas suffisant. La politique CVD doit préciser ce que vous faites du rapport une fois reçu, dans quel délai vous répondez, et ce à quoi vous vous engagez vis-à-vis du chercheur qui vous a aidé. Ces engagements doivent être publics et opposables.
Les premiers audits de maturité NIS2 conduisent au même constat. Parmi les cinq lacunes systématiques identifiées dans des rapports préliminaires couvrant quatorze États membres, l'absence de politique de divulgation responsable des vulnérabilités figure en bonne place, aux côtés du registre des risques fournisseurs non tenu à jour et de l'absence de MFA sur les accès administrateurs. Le CRA élargit maintenant cette exigence au-delà des opérateurs NIS2 : elle couvre l'ensemble des fabricants et éditeurs de produits numériques présents sur le marché européen.
Un test conduit en 2025 par des chercheurs de l'université de Delft a simulé un signalement de vulnérabilité auprès de cent éditeurs SaaS européens. 43 % n'avaient pas d'adresse de contact dédiée à la sécurité. Parmi ceux qui en disposaient, le délai médian avant une première réponse était de onze jours. La norme ISO/IEC 29147:2018 recommande un accusé de réception dans les sept jours, un seuil que la Commission européenne a repris dans ses lignes directrices publiées le 27 juillet 2026.
Par ailleurs, selon le rapport ENISA Threat Landscape de janvier 2026, 34 % des vulnérabilités activement exploitées dans le périmètre européen présentent un score CVSS inférieur à 7,0. Ce chiffre illustre un angle mort structurel : les organisations filtrent leurs priorités par score, pendant que les attaquants exploitent des failles que les équipes internes n'auraient pas priorisées. Un chercheur externe qui détecte ce type de faille dans votre produit et ne trouve pas de canal de signalement clair ne reviendra pas une seconde fois.
Les cinq éléments d'une politique minimale et conforme
Une politique CVD n'est pas un document de cent pages. Son efficacité repose sur cinq clauses précises, que la plupart des équipes peuvent rédiger et publier en une journée.
Le canal de contact. Une adresse dédiée, de préférence avec une clé PGP pour les signalements sensibles. L'adresse doit figurer dans le fichier security.txt à la racine du domaine et sur la page Sécurité ou Confidentialité du site. Le règlement exige que ce canal soit publiquement identifiable.
Le périmètre couvert. Quels produits, quelles versions, quels services entrent dans le champ de la politique. Un éditeur qui distribue plusieurs produits peut opter pour une politique globale ou des politiques distinctes par produit. L'absence de périmètre défini rend la politique inapplicable en pratique.
Les engagements de délais. Accusé de réception dans les sept jours. Évaluation initiale dans les quatorze jours. Mise à disposition d'un correctif dans un délai proportionnel à la sévérité : la plupart des cadres de référence retiennent 90 jours pour les vulnérabilités critiques, 180 jours pour les autres. Ces délais peuvent être ajustés selon la complexité du produit, mais ils doivent être explicites et publics.
La clause de protection du chercheur. Vous vous engagez à ne pas poursuivre un chercheur qui agit en bonne foi dans le cadre de votre politique. En contrepartie, vous demandez au chercheur de ne pas exploiter activement la faille ni de la publier avant qu'un correctif soit disponible. L'ENISA recommande explicitement cette clause dans ses lignes directrices CVD de 2024 ; son absence fragilise l'attractivité de votre programme et peut décourager les signalements légitimes.
La mention du CSIRT national. Pour les vulnérabilités de portée critique ou nationale, le CERT-FR de l'ANSSI peut servir de médiateur entre le chercheur et vous. La politique doit mentionner ce canal alternatif, conformément à l'architecture de coordination prévue par le règlement.
Ces cinq éléments tiennent en deux pages. Un éditeur SaaS de taille intermédiaire peut les formaliser et les publier avant le 11 septembre. La charge est mesurée. L'absence, elle, sera la première chose qu'un auditeur vérifiera : la politique est publique, donc observable — soit présente, soit absente.
La politique CVD et les délais de notification vers l'ENISA sont les deux faces d'un même dispositif de gestion des vulnérabilités. Pour les délais de signalement actif via la Single Reporting Platform, les détails pratiques sont décrits dans l'article sur le CRA et la notification des vulnérabilités en 24 heures. Pour construire la base technique qui permet de détecter rapidement une faille dans un composant logiciel tiers, l'article sur les SBOM sous NIS2 et DORA détaille les méthodes de génération et les outils disponibles. Les trois sujets sont liés : sans inventaire logiciel à jour, la détection est aveugle ; sans politique CVD, les signalements externes n'ont nulle part où aller ; sans processus de notification, les délais réglementaires ne tiennent pas.