Cyberrésilience : préparer les produits au CRA

Le travail lié au règlement sur la cyberrésilience (CRA) ne s’achève pas lorsqu’une exigence est ajoutée à un tableur. L’équipe produit doit savoir à quel produit elle s’applique, qui est responsable du travail, quelle est l’échéance, pourquoi une décision a été prise et où trouver les preuves.

Les obligations de signalement du CRA s’appliquent depuis le 11 septembre 2026. L’essentiel du règlement s’appliquera à partir du 11 décembre 2027. Une partie du fonctionnement opérationnel doit donc être en place dès maintenant. Le reste doit être préparé assez tôt pour éviter de reconstituer la documentation technique à la fin.

Dates clés du CRA

Date	Ce qui change
11 septembre 2026	Application des obligations de signalement de l’article 14
11 décembre 2027	Application des principales obligations du CRA

Pour les événements à signaler, le délai commence lorsque le fabricant en prend connaissance. La Commission prévoit une alerte précoce dans les 24 heures et une notification complète dans les 72 heures. Le délai du rapport final diffère selon qu’il s’agit d’une vulnérabilité activement exploitée ou d’un incident grave.

Consultez le processus pratique de signalement CRA à 24/72 heures

Le CRA concerne un produit, pas un score abstrait de conformité de l’entreprise

La première question utile est : quel produit précis comportant des éléments numériques évaluons-nous ?

Le règlement couvre les produits logiciels et matériels ainsi que, sous certaines conditions, leurs solutions de traitement de données à distance. Le rôle de l’organisation compte également : fabricant, mandataire, importateur, distributeur ou acteur réalisant une modification substantielle.

Commencez par une fiche pour un produit :

nom du produit et identifiant unique ;
version ou famille de versions ;
fabricant et marque sous laquelle le produit est mis à disposition ;
modalités de mise à disposition sur le marché de l’UE ;
destination et fonctions principales ;
composants et dépendances ;
services à distance nécessaires aux fonctions du produit ;
période d’assistance ;
personnes responsables de la sécurité du produit, des vulnérabilités et des versions publiées.

Découvrez comment évaluer le champ d’application du CRA pour un produit

Sept domaines à relier

1. Champ d’application

Déterminez si le produit et le rôle de l’organisation relèvent du CRA. Une étiquette comme « SaaS », « IoT » ou « logiciel » ne constitue pas une évaluation du champ d’application.

2. Risques du produit

Les exigences du CRA sont liées à une évaluation des risques de cybersécurité du produit. Cette évaluation doit rester rattachée à une version et être revue lorsque l’architecture, la destination ou les risques changent.

3. Sécurité dès la conception et par défaut

Une exigence doit devenir un travail d’ingénierie : décision de conception, action, responsable, test, revue et preuve.

Consultez le guide de sécurité dès la conception dans le CRA

4. Vulnérabilités et SBOM

Le CRA impose aux fabricants de recenser et de documenter les vulnérabilités et les composants du produit, notamment en établissant une nomenclature logicielle (SBOM) dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau.

Découvrez pourquoi la SBOM est une donnée d’entrée du processus, pas son résultat final

5. Signalement

La plateforme unique de signalement CRA (SRP) est opérationnelle depuis le 11 septembre 2026. En pratique, un fabricant a besoin de plus qu’un accès au portail : un T0 clair, des critères d’escalade, un responsable désigné, des remplaçants disponibles et les informations nécessaires pour transmettre une notification.

6. Documentation technique

La documentation technique ne doit pas être une archive de fichiers sans liens entre eux. Elle doit permettre de retracer le produit, la version, l’architecture, l’évaluation des risques, le traitement des vulnérabilités, les tests, les décisions et les fondements de la période d’assistance.

Consultez une structure pratique de documentation technique CRA

7. Période d’assistance

Le fabricant détermine la période d’assistance en fonction de l’utilisation prévue et des critères définis dans le CRA. En règle générale, elle est d’au moins cinq ans, sauf si la durée d’utilisation attendue du produit est plus courte.

Découvrez comment documenter la période d’assistance

Les difficultés à vérifier dans votre propre organisation

L’enquête CRA de l’ENISA auprès des PME en 2026 illustre l’écart entre connaissance et mise en œuvre. Dans un échantillon volontaire de 194 réponses, 66% connaissaient le CRA, tandis que 54% déclaraient connaître peu ou pas du tout l’évaluation de la conformité et 42% connaître peu ou pas du tout la documentation requise. Une aide à la documentation technique était demandée par 73% des répondants.

Cette enquête ne doit pas être considérée comme une estimation représentative de l’ensemble du marché de l’UE : son échantillon est petit et volontaire. Elle reste un signal utile montrant que la difficulté ne se limite pas à « savoir que le CRA existe ». Les équipes ont besoin de processus opérationnels reproductibles.

Identifiez les décisions sans responsable, les versions sans documentation et les rapports dont la preuve de transmission manque. Ce diagnostic porte sur vos dossiers ; il ne nécessite pas de supposer un niveau de préparation du marché.

Le rôle de Pulsar GRC

Pulsar GRC relie le travail souvent dispersé entre documents, tableurs, tickets et e-mails :

exigence → risque → contrôle ou action → responsable → échéance → document ou preuve → revue → historique des décisions.

Pulsar relie audits, contrôles, risques, documents, preuves, rapports, CAPA, fournisseurs et tâches. Cela permet d’exécuter un processus et d’en apporter la preuve, sans prétendre que le logiciel détermine le statut juridique du client.

Pulsar ne certifie pas la conformité au CRA, ne remplace pas une analyse juridique et ne décide pas de manière autonome si un événement doit être signalé. Les décisions de périmètre, la qualification réglementaire et la décision de transmission restent sous la responsabilité des personnes désignées.

Commencez par un produit

Ne commencez pas par un programme intitulé « mettre en œuvre le CRA dans toute l’entreprise ». Choisissez un produit réel. Définissez son périmètre, ses responsables, ses risques actuels, son processus de traitement des vulnérabilités, sa documentation et sa période d’assistance. C’est ainsi que les écarts sur lesquels agir deviennent visibles.

Découvrez Pulsar GRC dans un processus opérationnel

Organiser le travail sans attendre un dossier parfait

La première semaine peut commencer avec des informations incomplètes, à condition que les inconnues soient visibles. Réunissez un responsable produit, une personne connaissant l’architecture et une personne chargée de la conformité. Choisissez un produit et une version. Évitez de mélanger plusieurs offres sous une seule fiche parce qu’elles utilisent la même marque. Les fonctions, les composants et les rôles économiques peuvent être différents ; la décision de périmètre doit donc rester attachée à ce qui a réellement été examiné.

Le résultat de cette réunion est une liste de décisions à prendre, avec leur propriétaire. Une question juridique n’est pas fermée parce qu’un ingénieur a décrit le système. Une question technique n’est pas résolue parce qu’un document commercial affirme que le produit est sécurisé. Enregistrez les informations nécessaires à chacune et la date prévue pour leur revue. Cette séparation permet de poursuivre les tâches opérationnelles sans transformer les hypothèses en conclusions acquises.

Une progression proposée pour une petite équipe

Commencez par la fiche produit et la liste des versions encore prises en charge. Ensuite, vérifiez où arrivent les signalements, qui peut les lire et comment une absence du responsable est gérée. Le délai de signalement existe indépendamment de la disponibilité d’un dossier de conformité complet. Une équipe qui attend la fin de l’analyse documentaire avant de définir les responsabilités conserve donc un risque immédiat sur le traitement d’un événement.

Examinez ensuite une version publiée. Retrouvez son architecture, les composants utilisés, les résultats de tests et la décision de mise à disposition. Choisissez enfin un incident ou une vulnérabilité passée et essayez d’en reconstituer la chronologie. Ce parcours révèle les écarts concrets : version inconnue, test sans résultat archivé, décision sans auteur ou correctif sans preuve de distribution. Les exemples sont une méthode de diagnostic, pas une liste exhaustive des obligations CRA.

Construire un registre des écarts utilisable

Un écart doit décrire le fait manquant et son effet sur une décision. « Documentation insuffisante » donne peu de prise au responsable. « Le dossier de la version publiée ne contient pas le résultat du test qui justifie l’acceptation de la configuration par défaut » indique une recherche et une revue précises. Ajoutez la source de l’exigence, la pièce attendue, la personne responsable et le critère qui permettra de considérer l’écart traité.

Classez les actions selon leur dépendance et leur risque, sans supposer qu’une priorité graphique constitue une analyse. Un canal de signalement inaccessible exige une décision différente d’une illustration technique à mettre à jour. Si une action dépend d’un fournisseur, identifiez cette dépendance et le contrôle provisoire. La direction doit savoir ce qui reste exposé pendant l’attente et qui accepte la situation. Un report d’échéance ne remplace pas cette décision.

Relier les travaux d’ingénierie et les preuves de conformité

Les outils de développement conservent les modifications de code et les résultats techniques. Le dossier de conformité doit les replacer dans le périmètre du produit et de la version. Référencez le changement, le test et la décision correspondants au lieu de copier des fichiers sans contexte. Vérifiez que le lecteur autorisé peut accéder aux pièces et comprendre ce qu’elles démontrent. Une capture d’écran du statut « terminé » ne suffit pas à établir le résultat d’un test.

La même logique s’applique aux fournisseurs. Une dépendance logicielle peut avoir une version maintenue, une fin d’assistance annoncée ou une vulnérabilité connue. Conservez la source de cette information, sa date et l’effet sur votre produit. Une déclaration du fournisseur ne supprime pas la nécessité d’une évaluation du fabricant. Lorsqu’une conclusion repose sur une hypothèse non vérifiée, indiquez-la dans la décision afin que la prochaine revue puisse la reprendre.

Préparer la décision de mise à disposition

Avant une publication, le responsable doit pouvoir distinguer les écarts corrigés, les limites connues et les travaux encore ouverts. Définissez les éléments à présenter pour ce produit : périmètre examiné, risques, essais, traitement des vulnérabilités, informations aux utilisateurs et période d’assistance. Le contenu exact dépend du texte applicable et de votre rôle. Le modèle proposé organise la revue ; il ne constitue pas une procédure officielle d’évaluation de la conformité.

Conservez la décision avec l’identité du réviseur et la version des pièces utilisées. Une approbation ne signifie pas que tous les risques ont disparu. Elle montre qui a évalué le résultat et sur quelle base. Si une nouvelle information arrive après publication, créez un lien vers cette décision et ouvrez la revue nécessaire. Il faut pouvoir expliquer ce qui était connu lors de la publication, puis comment l’organisation a réagi à l’information nouvelle.

Suivre des indicateurs qui révèlent un problème

Compter les documents importés ne montre pas la préparation du produit. Des indicateurs plus utiles portent sur les décisions sans base identifiable, les versions sans dossier associé et les actions bloquées par une pièce absente. Examinez les exceptions une par une. Un pourcentage agrégé peut masquer un seul produit important dépourvu de responsable de signalement. Reliez donc chaque résultat à la liste des dossiers et à la date de calcul.

Pour le traitement des événements, observez la capacité à retrouver le moment de prise de connaissance et la preuve de transmission. Pour la documentation, vérifiez si un autre membre de l’équipe reconstitue une décision sans interroger son auteur. Ces observations décrivent votre fonctionnement. Elles ne sont ni un score juridique de conformité ni une comparaison représentative avec d’autres entreprises. Définissez les améliorations à partir de vos propres données.

Tester l’organisation sur un seul parcours

Une démonstration utile suit le produit depuis sa fiche jusqu’à un risque, une action et une preuve examinée. Préparez des données fictives pour la première évaluation et gardez les documents confidentiels dans leur espace autorisé. Demandez qui crée la fiche, qui valide les informations et qui peut exporter le résultat. La disponibilité d’une fonction ne dispense pas de définir ces responsabilités dans votre organisation.

Pulsar GRC peut structurer les documents, tâches et décisions de ce parcours. L’IA prépare des propositions à examiner ; elle ne certifie pas le produit et ne décide pas d’une notification. L’essai de quatorze jours nécessite un moyen de paiement selon l’offre actuelle. Le signal recherché est concret : un dossier que les personnes responsables peuvent comprendre, compléter et revoir, y compris lorsque son premier auteur est absent.

Sources

État documentaire du guide : 2 octobre 2026. Vérifiez les instructions opérationnelles actuelles avant toute notification.