Le Cyber Resilience Act devient un sujet urgent pour les entreprises qui fabriquent, distribuent, intègrent ou achètent des produits numériques. Les recherches Google le confirment : cyber resilience act et cyber résilience act atteignent chacun 1 900 recherches mensuelles en France, avec une concurrence faible et un CPC haut à 5,28 euros. Le signal est net : les dirigeants, DSI, éditeurs, distributeurs et acheteurs commencent à chercher ce que le règlement change concrètement.

L’actualité est liée à une première échéance proche. Les obligations de signalement de certaines vulnérabilités exploitées et incidents graves commencent le 11 septembre 2026. L’application complète du règlement est prévue le 11 décembre 2027, mais attendre cette date serait une erreur. Les contrats signés en 2026 peuvent déjà créer des engagements de conformité, de notification, de support, de mise à jour et de responsabilité. Un avocat en droit des affaires à Paris peut donc intervenir dès maintenant sur les contrats fournisseurs, SaaS, intégrateurs, distributeurs et fabricants.

Cyber Resilience Act : de quoi parle-t-on exactement ?

Le Cyber Resilience Act, ou CRA, est le règlement européen 2024/2847. Il crée un cadre horizontal de cybersécurité pour les produits comportant des éléments numériques mis sur le marché de l’Union européenne. Le texte vise les matériels et logiciels, avec une logique de sécurité dès la conception, de suivi des vulnérabilités et de documentation de conformité.

Le point important est le suivant : le CRA n’est pas seulement une règle informatique. C’est une règle de mise sur le marché. Elle se rapproche donc des logiques de conformité produit, de marquage CE, de responsabilité du fabricant, d’information du distributeur et de retrait ou correction en cas de non-conformité.

Sont potentiellement concernés les fabricants, importateurs, distributeurs, éditeurs, intégrateurs et entreprises qui commercialisent des produits avec éléments numériques. Un logiciel embarqué, un objet connecté, un outil industriel connecté, un équipement réseau, une solution vendue avec composant logiciel ou certains produits numériques peuvent entrer dans le champ.

Pourquoi l’échéance du 11 septembre 2026 change déjà les contrats

La Commission européenne rappelle que les obligations de signalement prévues par le CRA commenceront le 11 septembre 2026 pour les fabricants, notamment en cas de vulnérabilités activement exploitées et d’incidents graves affectant la sécurité de produits avec éléments numériques.

Cette date paraît technique. Elle ne l’est pas. À partir du moment où un fabricant doit pouvoir signaler un incident ou une vulnérabilité dans un délai court, il doit déjà avoir organisé sa chaîne d’information :

• qui détecte la vulnérabilité ;
• qui la qualifie ;
• qui décide qu’elle est activement exploitée ;
• qui informe le fabricant si l’alerte vient d’un distributeur, d’un intégrateur ou d’un client ;
• qui conserve les preuves ;
• qui corrige le produit ;
• qui informe les utilisateurs ;
• qui documente la décision.

Un contrat signé en 2026 avec un fournisseur logiciel, un fabricant d’objet connecté ou un intégrateur doit donc prévoir ces circuits. Sinon, au premier incident, chacun risque de soutenir que l’autre était responsable de l’alerte.

Fabricant, distributeur, importateur : qui doit faire quoi ?

Le fabricant est au centre du CRA. Il doit concevoir et développer le produit avec des exigences de cybersécurité, gérer les vulnérabilités, conserver une documentation technique, assurer un support de sécurité et traiter les incidents.

Mais les autres acteurs ne sont pas neutres. L’importateur et le distributeur doivent vérifier certains éléments avant de mettre le produit à disposition. Ils doivent aussi réagir si un produit paraît non conforme ou présente un risque. Dans une chaîne commerciale, le contentieux peut donc naître entre plusieurs professionnels : fabricant étranger, importateur français, distributeur, intégrateur, revendeur, client final.

La difficulté vient souvent du contrat. Un distributeur peut vendre un produit dont il ne maîtrise pas le code. Un intégrateur peut installer une solution qu’il n’a pas développée. Un client peut reprocher à son fournisseur un défaut de mise à jour alors que la vulnérabilité vient d’un composant tiers.

Il faut donc préciser les responsabilités par écrit. Les contrats doivent indiquer qui fournit la documentation, qui annonce les mises à jour, qui supporte les correctifs, qui répond aux autorités de surveillance, qui indemnise en cas de retrait du marché et qui prend en charge les coûts de remédiation.

Les clauses à revoir dans les contrats de logiciel et produit connecté

La clause de conformité doit être précise. Une phrase du type « le produit respecte la réglementation applicable » ne suffit plus. Il faut viser les obligations réellement pertinentes : sécurité dès la conception, gestion des vulnérabilités, documentation technique, mises à jour de sécurité, durée de support, assistance à la notification, coopération avec les autorités et correction des non-conformités.

La clause de notification est tout aussi importante. Elle doit prévoir un délai d’alerte interne beaucoup plus court que le délai légal final. Si un distributeur découvre une faille exploitée, il ne peut pas attendre plusieurs jours avant d’avertir le fabricant. Le contrat doit imposer un canal dédié, des interlocuteurs identifiés et une obligation de transmettre les informations techniques disponibles.

La clause de mise à jour doit distinguer les mises à jour fonctionnelles et les mises à jour de sécurité. Une entreprise qui achète un produit numérique doit savoir pendant combien de temps elle recevra les correctifs de sécurité, sous quelle forme, avec quelle priorité et à quel coût.

La clause de preuve doit prévoir l’accès aux documents utiles : rapports de vulnérabilité, versions corrigées, notes de release, journaux, attestations, documentation technique, justificatifs de marquage CE, correspondances avec le fabricant, historique des correctifs et alertes de sécurité.

Enfin, la clause de responsabilité doit être adaptée. Un plafond trop faible peut être inacceptable pour un produit critique. Une responsabilité illimitée peut être impossible à assurer. L’équilibre doit tenir compte du prix, du rôle de chaque partie, du risque de marché, de la dépendance du client et de l’assurance disponible.

Acheteur professionnel : ce qu’il faut demander avant de signer

Une entreprise qui achète un produit numérique ne doit pas se contenter d’un prix et d’une fiche technique. Elle doit demander des garanties contractuelles simples :

• le produit entre-t-il dans le champ du CRA ;
• qui est le fabricant au sens du règlement ;
• le produit est-il déjà documenté pour le marquage CE ;
• quelle est la durée de support de sécurité ;
• comment les vulnérabilités seront-elles notifiées ;
• dans quel délai les correctifs seront-ils fournis ;
• les composants tiers sont-ils suivis ;
• une nomenclature logicielle ou une documentation équivalente existe-t-elle ;
• que se passe-t-il en cas de retrait, rappel, suspension ou non-conformité ;
• le contrat prévoit-il une réversibilité ou un remplacement.

Ces questions sont utiles même si l’application complète intervient en 2027. Un produit acheté en 2026 peut rester exploité plusieurs années. Si le fournisseur ne prévoit aucune mise à jour, aucune documentation et aucune coopération, le client supportera une dépendance dangereuse.

Éditeur SaaS, intégrateur, agence web : attention au faux sentiment de sécurité

Le CRA ne couvre pas toutes les prestations numériques de la même façon. Certaines offres purement SaaS peuvent relever d’autres cadres, selon leur structure et leur mise à disposition. Mais cette nuance ne doit pas rassurer trop vite les prestataires.

D’abord, un éditeur ou intégrateur peut fournir un composant logiciel, un agent, une extension, un firmware, un connecteur, une application embarquée ou un outil installé chez le client. Ensuite, les clients peuvent reprendre les exigences CRA dans leurs appels d’offres, même lorsque le prestataire estime ne pas être directement concerné. Enfin, la frontière entre produit, service et composant peut devenir litigieuse.

Le prestataire doit donc éviter deux erreurs. La première est de garantir une conformité CRA sans avoir vérifié son périmètre. La seconde est de refuser toute discussion, alors que le client a besoin d’une réponse contractuelle exploitable.

Une bonne clause peut dire ce qui est inclus, ce qui est exclu, ce qui dépend du client, ce qui dépend d’un tiers, et quelles informations seront fournies en cas de vulnérabilité.

Que faire si un produit livré n’est pas conforme ?

Le litige peut apparaître de plusieurs façons. Le client découvre que le produit ne reçoit plus de mises à jour. Un distributeur apprend qu’un fabricant étranger ne fournit pas la documentation. Un incident révèle une faille ancienne. Un appel d’offres impose une conformité que le produit ne peut pas démontrer. Un assureur demande des preuves que personne n’a conservées.

La première étape consiste à reprendre le contrat et les documents commerciaux : bon de commande, cahier des charges, documentation technique, promesses de sécurité, échanges précontractuels, notices, conditions générales, garanties, durée de support et clauses de responsabilité.

La deuxième étape consiste à qualifier le rôle de chaque acteur. Le vendeur n’est pas toujours le fabricant. L’intégrateur n’est pas toujours l’éditeur. Le distributeur peut avoir des obligations propres, mais il ne maîtrise pas toujours la correction technique.

La troisième étape consiste à sécuriser la preuve. Il faut conserver les versions, les alertes, les tickets, les journaux, les courriels, les captures, les rapports d’audit et les réponses du fournisseur. En droit commercial, une facture ou une promesse générale ne suffit pas toujours. Le dossier se gagne souvent sur les documents concrets.

Sanctions et risques : au-delà de l’amende

Le CRA prévoit des sanctions administratives importantes. Mais l’entreprise doit surtout regarder les conséquences pratiques :

• retrait ou blocage de mise sur le marché ;
• rappel ou correction d’un produit ;
• perte d’un appel d’offres ;
• rupture d’un contrat par un client ;
• conflit avec le fournisseur étranger ;
• coûts de correctifs ;
• atteinte à la réputation ;
• mise en cause de l’importateur ou du distributeur ;
• refus d’assurance ou franchise élevée après incident.

Le risque commercial peut donc dépasser le risque réglementaire. Un produit non conforme peut bloquer une vente, retarder un déploiement ou déclencher une demande d’indemnisation.

Paris et Île-de-France : les entreprises les plus exposées

À Paris et en Île-de-France, le sujet concerne notamment les éditeurs logiciels, agences digitales, intégrateurs, distributeurs de matériel connecté, revendeurs informatiques, startups hardware, fabricants de solutions IoT, prestataires industriels, fintech, healthtech, legaltech, proptech et entreprises qui achètent des outils numériques critiques.

Les contrats sont souvent signés vite : devis, conditions générales, bon de commande, licence, abonnement, annexe sécurité, DPA, SLA, conditions d’hébergement. Le CRA impose de ralentir sur les points qui engagent la responsabilité. Une clause mal relue peut transférer à une PME une obligation qu’elle ne peut pas techniquement assumer.

La revue utile n’est pas forcément longue. Elle consiste à identifier le produit, le rôle de chaque partie, les obligations de sécurité, la durée de support, le circuit d’incident, les preuves et les conséquences d’une non-conformité.

Checklist avant de signer un contrat concerné par le Cyber Resilience Act

Avant de signer, vérifiez au minimum :

• le produit comporte-t-il des éléments numériques ;
• le produit est-il mis sur le marché de l’Union européenne ;
• qui est fabricant, importateur, distributeur, intégrateur et client final ;
• quelles obligations CRA sont garanties ;
• quelle documentation technique sera fournie ;
• quelle est la durée de support de sécurité ;
• comment les vulnérabilités seront-elles signalées ;
• quel délai d’alerte interne est prévu avant le délai réglementaire ;
• qui paie les correctifs, audits et remédiations ;
• quelle responsabilité est plafonnée ou exclue ;
• que se passe-t-il si le produit doit être retiré, corrigé ou remplacé.

Si ces points ne sont pas écrits, ils seront discutés après l’incident. C’est le pire moment pour découvrir le contrat.

Sources utiles

• Commission européenne, Cyber Resilience Act – résumé du texte législatif.
• Commission européenne, Cyber Resilience Act – reporting obligations.
• ANSSI, Cyber Resilience Act.
• EUR-Lex, règlement (UE) 2024/2847.

Besoin d’un avis rapide sur votre dossier

Le cabinet peut relire un contrat logiciel, un contrat SaaS, un contrat de distribution, un contrat d’intégration, une clause de sécurité ou une mise en cause liée au Cyber Resilience Act.

Consultation téléphonique en 48 heures avec un avocat du cabinet.

Préparez le contrat, les conditions générales, le devis, la documentation technique, les échanges avec le fournisseur, les clauses de support, les preuves de mise à jour et les alertes de sécurité reçues.

Appelez le cabinet au 06 46 60 58 22 ou utilisez le formulaire de contact du cabinet.