Le Cyber Resilience Act entre dans sa phase opérationnelle. À partir du 11 septembre 2026, les fabricants de produits comportant des éléments numériques devront signaler les vulnérabilités activement exploitées et les incidents graves de sécurité via la plateforme européenne de notification.
Cette échéance ne concerne pas seulement les grands fabricants d’objets connectés. Elle peut aussi toucher un éditeur SaaS, un intégrateur qui commercialise un logiciel, un distributeur de produits connectés, un importateur de matériel numérique, ou une entreprise qui met sur le marché un produit associant logiciel, matériel et traitement de données à distance.
Le risque est simple : découvrir trop tard que le produit est dans le périmètre du règlement, que la documentation de conformité n’existe pas, que les contrats fournisseurs ne permettent pas de remonter les vulnérabilités, ou que l’entreprise ne sait pas qui doit notifier l’incident lorsqu’une faille est exploitée.
Qui est concerné par le Cyber Resilience Act ?
Le règlement vise les produits comportant des éléments numériques. L’ANSSI les présente comme des produits logiciels ou matériels, ainsi que leurs solutions de traitement de données à distance, y compris les composants mis sur le marché séparément.
En pratique, plusieurs profils d’entreprises doivent se poser la question :
- l’éditeur qui met sur le marché un logiciel, une application, un module, un composant ou une solution embarquée ;
- le fabricant d’un objet connecté, d’un équipement réseau, d’un équipement industriel ou d’un dispositif comportant une couche logicielle ;
- l’importateur qui fait entrer dans l’Union européenne un produit numérique conçu hors UE ;
- le distributeur qui commercialise un produit numérique sous sa marque, ou qui intervient suffisamment dans sa mise sur le marché pour être exposé ;
- l’intégrateur qui assemble une solution matérielle et logicielle et la vend comme un produit.
Le règlement distingue plusieurs catégories de produits. Les produits de base entrent dans la catégorie par défaut. D’autres produits sont qualifiés d’importants ou de critiques, notamment certains systèmes d’exploitation, routeurs, navigateurs, gestionnaires de mots de passe, pare-feux, hyperviseurs, microprocesseurs ou dispositifs matériels de sécurité.
La première étape n’est donc pas de rédiger une politique cybersécurité générale. Elle consiste à qualifier précisément le produit vendu, le rôle de l’entreprise dans la chaîne de mise sur le marché et la catégorie applicable.
Ce qui change le 11 septembre 2026
Le 11 septembre 2026 marque une échéance concrète : les fabricants devront notifier les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit.
La notification passera par la plateforme européenne de signalement. Pour les fabricants établis en France, l’information sera transmise au CERT-FR de l’ANSSI, qui intervient comme CSIRT coordinateur national.
Une entreprise exposée doit donc être capable de répondre à quatre questions avant cette date :
- quel produit est concerné ;
- quelle vulnérabilité ou quel incident doit être notifié ;
- qui, en interne, décide de notifier ;
- quelles informations peuvent être transmises sans aggraver le risque technique, contractuel ou réputationnel.
L’erreur fréquente consiste à traiter le sujet comme un simple formulaire administratif. Une notification mal préparée peut révéler que l’entreprise n’a pas cartographié ses composants, ne sait pas joindre son fournisseur critique, ou ne peut pas démontrer les mesures prises après la découverte de la faille.
Fabricant, importateur, distributeur : ne pas confondre les responsabilités
Le CRA impose des obligations aux fabricants, mais aussi aux importateurs et distributeurs. Le bon réflexe est de relire la chaîne contractuelle.
Le fabricant doit organiser la cybersécurité du produit dès la conception et pendant son cycle de vie. Il doit aussi gérer les vulnérabilités, préparer l’évaluation de conformité et documenter ce qui a été fait.
L’importateur doit vérifier que le produit qu’il fait entrer sur le marché européen respecte les exigences applicables. Il ne peut pas se contenter de dire que le fabricant étranger a promis une conformité. Il doit conserver les bons documents, obtenir les garanties utiles et prévoir les conséquences d’un retrait ou d’une non-conformité.
Le distributeur doit éviter de commercialiser un produit dont il sait, ou devrait savoir, qu’il ne respecte pas les exigences. Plus il intervient dans la présentation, la marque, la documentation ou la configuration du produit, plus le risque de responsabilité augmente.
Dans les groupes de sociétés, les contrats intra-groupe doivent aussi être relus. Une filiale française qui vend une solution conçue par une société étrangère ne doit pas découvrir après incident qu’aucune clause ne l’autorise à obtenir les logs, rapports de vulnérabilité, correctifs, nomenclatures logicielles ou preuves de conformité.
Les clauses à vérifier dans les contrats SaaS, OEM et distribution
Le Cyber Resilience Act doit se traduire dans les contrats. Les clauses les plus sensibles sont souvent déjà présentes, mais trop générales.
Il faut vérifier notamment :
- la définition du produit et de ses composants logiciels ;
- les obligations de sécurité by design et de mise à jour ;
- la durée de support et de correction des vulnérabilités ;
- la procédure de remontée d’incident ;
- les délais d’alerte entre fournisseur, fabricant, intégrateur, distributeur et client ;
- l’accès aux informations techniques nécessaires à la notification ;
- la répartition des coûts de correction, rappel, retrait, audit ou communication client ;
- les garanties données en cas de contrôle ou de demande d’une autorité ;
- la responsabilité en cas de retard de correctif ou de documentation incomplète.
Une clause de confidentialité trop rigide peut devenir un problème si elle empêche de notifier ou de partager les informations indispensables avec les autorités compétentes. À l’inverse, une clause de notification trop large peut exposer l’entreprise à communiquer trop vite, sans qualification technique suffisante.
Le bon équilibre consiste à prévoir une procédure courte, des interlocuteurs identifiés, une obligation de coopération technique et une réserve pour les notifications légalement obligatoires.
Quelles preuves préparer avant un incident ?
Le contentieux arrive rarement au moment de la mise en conformité théorique. Il arrive après un incident, un retrait du marché, une rupture de contrat, une notification client ou une demande de réparation.
L’entreprise doit donc conserver des preuves utiles avant la crise :
- cartographie des produits concernés ;
- qualification du rôle de l’entreprise : fabricant, importateur, distributeur, intégrateur ;
- liste des composants logiciels critiques ;
- contrats fournisseurs et annexes de sécurité ;
- procédures de gestion des vulnérabilités ;
- registre des incidents et décisions de notification ;
- preuves de correction, tests, versions déployées et dates de diffusion ;
- échanges avec clients, fournisseurs et autorités ;
- éléments d’évaluation de conformité.
Ces documents ne servent pas seulement à répondre à l’ANSSI, à l’ANFR ou à un client. Ils servent aussi à trancher une question contractuelle : qui devait faire quoi, dans quel délai, avec quelles informations ?
Que risque l’entreprise en cas de non-conformité ?
L’ANSSI indique que le dispositif français de surveillance du marché sera assuré par l’ANFR. En cas de non-respect des obligations, les sanctions peuvent aller jusqu’au retrait du marché du produit ou à des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial du fabricant.
Ce plafond ne signifie pas que chaque manquement donnera lieu à une telle sanction. Mais il montre que le sujet dépasse la simple conformité informatique.
Les conséquences peuvent aussi être commerciales :
- suspension d’un référencement ;
- refus d’un client professionnel de déployer la solution ;
- résiliation pour manquement de sécurité ;
- demande d’indemnisation après incident ;
- blocage d’un appel d’offres ;
- retrait d’un produit ou interruption de commercialisation ;
- conflit entre fabricant, importateur, distributeur et intégrateur.
Le dirigeant doit donc traiter le CRA comme un sujet de gouvernance, de contrat et de preuve, pas seulement comme un chantier technique.
Que faire si un client exige une garantie CRA dès maintenant ?
Un client peut demander une attestation de conformité, une clause de garantie ou une preuve de préparation avant même l’application complète du règlement.
Il faut éviter deux réponses dangereuses.
La première consiste à garantir sans réserve que le produit est conforme, alors que la qualification du périmètre, la catégorie du produit et la procédure d’évaluation n’ont pas été documentées.
La seconde consiste à refuser toute réponse, ce qui peut bloquer la vente ou fragiliser une relation commerciale.
La réponse utile est intermédiaire : indiquer l’état de qualification du produit, les travaux déjà réalisés, les limites de l’analyse, les engagements réalistes de sécurité et de notification, ainsi que les éléments qui restent dépendants de fournisseurs ou de textes d’application.
Dans les négociations importantes, la clause doit préciser que la conformité CRA ne se réduit pas à une promesse générale. Elle dépend du produit, de sa version, de ses composants, de son usage prévu, des mises à jour, du rôle exact de chaque partie et des informations effectivement transmises.
Paris et Île-de-France : un enjeu fort pour les éditeurs, intégrateurs et importateurs
À Paris et en Île-de-France, le sujet concerne directement les éditeurs SaaS, intégrateurs informatiques, distributeurs de solutions connectées, prestataires industriels, importateurs de matériel numérique et sociétés qui répondent à des appels d’offres privés ou publics.
En cas de litige commercial, les questions seront souvent très concrètes : le client peut-il suspendre le contrat ? Le fournisseur devait-il notifier plus vite ? L’importateur peut-il se retourner contre le fabricant étranger ? Le distributeur avait-il connaissance d’un défaut de sécurité ? Le contrat permet-il d’obtenir les preuves techniques ?
Le dossier doit être préparé avant la rupture ou le contentieux. Les pièces essentielles sont les contrats, annexes de sécurité, bons de commande, échanges de qualification, tickets d’incident, rapports techniques, versions du produit, preuves de correctif et notifications envoyées.
Plan d’action en 7 étapes
Une entreprise concernée peut avancer rapidement si elle suit un ordre simple.
- Lister les produits numériques commercialisés, importés ou distribués.
- Qualifier le rôle de l’entreprise pour chaque produit.
- Identifier les produits par défaut, importants ou critiques.
- Relire les contrats fournisseurs, SaaS, OEM, distribution et intégration.
- Mettre en place une procédure interne de notification des vulnérabilités et incidents graves.
- Préparer les preuves techniques et contractuelles utiles.
- Adapter les clauses de garantie, responsabilité, support, correctif et coopération.
La priorité n’est pas de produire un document long. Elle est d’éviter qu’un incident révèle un vide : aucun responsable identifié, aucun délai interne, aucun accès aux informations fournisseur, aucune preuve de correction.
Sources officielles utiles
- ANSSI, Cyber Resilience Act.
- EUR-Lex, règlement (UE) 2024/2847 du 23 octobre 2024.
- Entreprises.gouv.fr, Cyber Resilience Act : êtes-vous concerné ?.
Besoin d’un avis rapide sur votre dossier.
Vous commercialisez, importez ou distribuez un produit numérique et vous devez sécuriser vos contrats avant l’échéance CRA.
Le cabinet peut analyser vos clauses, vos responsabilités et les pièces à préparer lors d’une consultation téléphonique sous 48 heures avec un avocat du cabinet.
Appelez le 06 46 60 58 22 ou utilisez le formulaire de contact.
Transmettez les pièces de votre dossier au cabinet. Maître Reda KOHEN vous répond personnellement sous 24 heures avec une première analyse stratégique.