# Modèle d'avis de vulnérabilité CRA (DOCX & PDF gratuits)

Modèle gratuit d'avis de vulnérabilité CRA avec champs CVE/EUVD, notation CVSS v4.0, e-mail de notification aux abonnés et un exemple d'avis rempli. Sans inscription.


Un **modèle d'avis de vulnérabilité CRA** donne à votre équipe sécurité une structure reproductible pour les divulgations publiques que le Cyber Resilience Act exige dès que vous corrigez une vulnérabilité. À partir du **11 septembre 2026**, les fabricants de produits comportant des éléments numériques sont soumis à des obligations de notification contraignantes au titre du [règlement (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) — et à partir de l'application complète en décembre 2027, la publication d'informations sur les vulnérabilités corrigées cesse d'être une bonne pratique pour devenir une condition d'accès au marché. Ce modèle gratuit d'avis de sécurité est livré en DOCX, PDF et en fichier Markdown lisible par un agent IA (les fichiers téléchargeables sont disponibles en français), avec tous les champs nécessaires à un avis conforme plus un exemple entièrement rempli.

**Un avis de vulnérabilité conforme au CRA doit décrire la vulnérabilité corrigée, identifier le produit et les versions affectés, et indiquer aux utilisateurs les mesures à prendre (annexe I, partie II, points 4 et 8 du règlement (UE) 2024/2847). Un avis complet ajoute un identifiant CVE ou EUVD, un score et un vecteur CVSS v4.0, les versions corrigées, les mesures d'atténuation ou de contournement, le statut d'exploitation, une chronologie de divulgation, un journal de mises à jour et un contact sécurité. Si la vulnérabilité est activement exploitée, une horloge réglementaire distincte court en parallèle : alerte précoce à l'ENISA et à votre CSIRT coordinateur sous 24 heures, notification sous 72 heures et rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective (article 14).**

## À retenir

- Les exigences de gestion des vulnérabilités du CRA figurent à l'**annexe I, partie II** ; l'article 13 en fait une obligation centrale du fabricant, et l'article 14 ajoute la notification réglementaire des vulnérabilités activement exploitées.
- **Deux horloges différentes :** l'avis public est dû dès qu'une mise à jour de sécurité est disponible ; la notification de l'article 14 (24 h / 72 h / 14 jours via la plateforme unique de notification de l'ENISA) ne se déclenche que pour les vulnérabilités activement exploitées.
- Les avis devraient porter à la fois un **identifiant CVE** et un **identifiant EUVD** — la [base de données européenne des vulnérabilités](https://euvd.enisa.europa.eu) de l'ENISA est désormais la référence native de l'UE pour les clients comme pour les CSIRT.
- L'article 14(8) vous impose d'informer les utilisateurs concernés, « le cas échéant dans un format structuré et lisible par machine » — les champs de ce modèle correspondent à **CSAF 2.0**, le standard OASIS d'avis lisibles par machine.
- Les amendes pour violation des articles 13/14 ou de l'annexe I atteignent **15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial**, le montant le plus élevé étant retenu.

## Ce que contient le modèle

Le modèle reprend le jeu de champs utilisé par les équipes de sécurité produit matures et couvre tout ce que l'annexe I, partie II attend, dans l'ordre dont vos lecteurs ont besoin :

| Champ | Ce qu'il capture | Pourquoi il compte |
|---|---|---|
| Identifiant de l'avis | Votre identifiant interne (p. ex. `ACME-SA-2026-001`) | Référence stable à travers les mises à jour, les e-mails et les documents CSAF |
| Titre | Résumé d'une ligne nommant le produit et la classe de faille | La première chose que clients et agrégateurs indexent |
| Identifiant CVE / EUVD | `CVE-YYYY-NNNNN` et `EUVD-YYYY-NNNNN` | Références croisées vers le NVD et l'EUVD de l'ENISA |
| Score + vecteur CVSS v4.0 | Score numérique, niveau de gravité, chaîne de vecteur complète | Gravité objective ; pilote les SLA de correctifs des clients |
| Produits & versions affectés | Noms de produits, plages de versions, modèles de déploiement | L'annexe I, partie II exige que les utilisateurs puissent identifier les produits affectés |
| Versions corrigées | Première version corrigée par ligne affectée | La cible d'action de tout l'avis |
| Atténuations & contournements | Mesures provisoires lorsque le correctif est retardé | Les « mesures que les utilisateurs peuvent prendre » requises (annexe I, partie II, point 8) |
| Impact | Ce qu'un attaquant peut obtenir, préconditions | Permet aux clients de mener leur propre analyse de risque |
| Statut d'exploitation | Aucune connue / PoC publié / exploitée dans la nature | Détermine si la notification de l'article 14 est déclenchée |
| Chronologie | Signalement reçu → triage → correctif → dates de divulgation | Preuve d'un traitement « sans retard » ; renforce la confiance des chercheurs |
| Journal de mises à jour | Historique daté des révisions de l'avis | Montre que l'avis est maintenu, et non publié puis oublié |
| Contact & clé PGP | Adresse du contact sécurité et clé de chiffrement | L'annexe I, partie II exige une adresse de contact pour les signalements de vulnérabilités |

La variante Markdown inclut en outre les définitions de champs, une échelle de gravité, une énumération des statuts d'exploitation, les états du cycle de vie d'un avis, une variante e-mail de notification aux abonnés et un exemple fictif entièrement rempli — pour que votre équipe comme vos outils d'IA puissent rédiger un avis complet à partir d'un seul fichier.

## Comment utiliser le modèle

1. **Triez le signalement.** Consignez la date de réception, confirmez la vulnérabilité et attribuez votre identifiant d'avis interne. Demandez un identifiant CVE (via votre CNA ou MITRE) et notez l'identifiant EUVD dès son attribution.
2. **Notez-la.** Calculez le score de base CVSS v4.0 et enregistrez la chaîne de vecteur complète, puis renseignez honnêtement le champ statut d'exploitation — il conditionne tout ce qui suit.
3. **Vérifiez le déclencheur réglementaire.** Si la vulnérabilité est **activement exploitée**, les obligations de l'article 14 démarrent immédiatement : alerte précoce sous 24 heures via la plateforme unique de notification, notification sous 72 heures, rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective. L'avis public est un livrable distinct, sur une horloge distincte.
4. **Corrigez, puis rédigez.** Préparez l'avis pendant que le correctif est en cours, mais ne publiez qu'une fois la mise à jour de sécurité disponible — c'est le point de divulgation auquel l'annexe I, partie II s'ancre. Coordonnez l'embargo avec le rapporteur dans le cadre de votre politique de divulgation coordonnée des vulnérabilités (CVD).
5. **Notifiez les abonnés, puis publiez.** Envoyez l'e-mail de notification aux abonnés (inclus dans le modèle) aux contacts sécurité et aux abonnés du Trust Center au moment de la publication ou juste avant, puis publiez l'avis. L'article 14(8) impose par ailleurs d'informer les utilisateurs concernés des vulnérabilités activement exploitées et des mesures d'atténuation — le CSIRT peut le faire à votre place, publiquement, si vous y manquez.
6. **Tenez le journal de mises à jour.** Chaque changement matériel — nouvelles versions affectées, exploitation observée, atténuations révisées — reçoit une entrée datée. Ne clôturez l'avis que lorsque toutes les lignes supportées sont corrigées.

### Obligation de notification vs avis public — la distinction qui piège les équipes

La plupart des vulnérabilités que vous corrigez ne toucheront jamais la plateforme de l'ENISA. L'article 14 couvre les **vulnérabilités activement exploitées** (et les incidents graves) ; l'annexe I, partie II couvre **chaque vulnérabilité corrigée**. Construisez votre processus de sorte que le modèle d'avis soit le chemin par défaut, avec l'escalade de l'article 14 greffée dessus lorsque des preuves d'exploitation apparaissent — et non l'inverse.

## Base juridique

- **[Règlement (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) (Cyber Resilience Act), article 13** — les fabricants doivent gérer les vulnérabilités « conformément aux exigences de gestion des vulnérabilités énoncées à l'annexe I, partie II » pendant toute la période de support, et doivent opérer une politique de divulgation coordonnée des vulnérabilités.
- **Annexe I, partie II** — les exigences de gestion des vulnérabilités : identifier et documenter les vulnérabilités (y compris un SBOM couvrant au moins les dépendances de premier niveau, point 1) ; dès qu'une mise à jour de sécurité est disponible, partager et divulguer publiquement des informations sur les vulnérabilités corrigées, y compris une description et des informations permettant aux utilisateurs d'identifier le produit affecté (point 4) ; appliquer une politique CVD (point 5) ; fournir une adresse de contact pour les signalements de vulnérabilités ; et diffuser sans retard des mises à jour de sécurité gratuites, accompagnées de messages d'avis contenant les informations pertinentes et les mesures que les utilisateurs peuvent prendre (point 8).
- **Article 14** — notification des vulnérabilités activement exploitées au CSIRT désigné comme coordinateur et à l'ENISA via la **plateforme unique de notification** établie par l'article 16 : alerte précoce sous 24 heures, notification sous 72 heures, rapport final au plus tard 14 jours après la disponibilité d'une mesure corrective. L'article 14(8) impose d'informer les utilisateurs concernés, le cas échéant dans un format structuré et lisible par machine. Ces obligations s'appliquent à partir du **11 septembre 2026** ; les obligations principales du CRA à partir du **11 décembre 2027**.
- **Avis lisibles par machine** — le CRA ne nomme aucun format, mais **CSAF 2.0** (Common Security Advisory Framework, un [standard OASIS](https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html)) est le standard établi pour les avis structurés, utilisé par la CISA et les grands éditeurs. Les champs de ce modèle correspondent aux propriétés de document CSAF, ce qui rend une migration ultérieure vers CSAF mécanique.
- **Sanctions** — le non-respect des exigences essentielles de l'annexe I ou des articles 13/14 est passible d'amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total (article 64).

Pour la vue d'ensemble des obligations du fabricant, consultez nos guides sur le [Cyber Resilience Act](/fr/reglementations-ue/cyber-resilience-act) et les [articles 13 et 14 du CRA](/fr/reglementations-ue/cyber-resilience-act-articles-13-14) — et pour situer votre produit sur la classification, la voie de conformité et l'ensemble des exigences de l'annexe I, utilisez le classeur compagnon d'[auto-évaluation de conformité CRA](/fr/modeles/modele-auto-evaluation-conformite-cra).

## Royaume-Uni et Norvège/EEE

**Royaume-Uni :** le régime du Product Security and Telecommunications Infrastructure (PSTI) Act 2022, en vigueur depuis le **29 avril 2024**, impose aux fabricants de produits connectables grand public vendus au Royaume-Uni de publier une politique de divulgation des vulnérabilités avec un contact de signalement — les champs contact, chronologie et journal de mises à jour de ce modèle y font double emploi, même si le PSTI exige aussi le document de politique et une période de mises à jour de sécurité déclarée. **Norvège/EEE :** le CRA est marqué comme pertinent pour l'EEE et devrait être incorporé dans l'accord sur l'EEE ; les fabricants norvégiens, islandais et liechtensteinois vendant sur le marché unique de l'UE sont de toute façon concernés en pratique, puisque le CRA s'attache aux produits mis sur le marché de l'UE.

## Publiez vos avis là où vos clients regardent déjà

Un avis que personne ne voit manque son but. [Orbiq Trust Updates](/fr/plateforme/trust-updates) publie vos avis de sécurité et notifications d'incident directement sur votre Trust Center, notifie automatiquement les clients abonnés et tient le journal de mises à jour daté que le CRA attend — transformant une obligation de conformité en signal de confiance visible. À lire aussi : [ce qu'est un Trust Center](/fr/trust-center/qu-est-ce-qu-un-trust-center) et comment les [obligations de notification d'incidents NIS2](/fr/reglementations-ue/notification-incidents-chaine-approvisionnement-nis2-articles-21-23) interagissent avec la notification des clients.

---

## Sources et références

1. [Règlement (UE) 2024/2847 (Cyber Resilience Act) — texte intégral](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) — Journal officiel de l'Union européenne.
2. [Commission européenne — obligations de notification du CRA](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) — la plateforme unique de notification et les délais de l'article 14.
3. [Commission européenne — page politique du Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) — entrée en vigueur et dates d'application.
4. [ENISA — Base de données européenne des vulnérabilités (EUVD)](https://euvd.enisa.europa.eu) — enregistrements de vulnérabilités de l'UE et identifiants EUVD.
5. [Directive (UE) 2022/2555 (NIS2), article 12](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) — base juridique de la base de données européenne des vulnérabilités.
6. [OASIS — Common Security Advisory Framework (CSAF) v2.0](https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html) — standard d'avis de sécurité lisibles par machine.
7. [FIRST — spécification CVSS v4.0](https://www.first.org/cvss/v4.0/) — notation et niveaux de gravité.
8. [UK Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents) — régime britannique de sécurité des produits.
9. [ENISA — Cyber Resilience Act Requirements Standards Mapping](https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping) — correspondance entre les exigences du CRA et les standards existants.