Vous pensiez avoir jusqu’à fin 2027 pour vous préoccuper du Cyber Resilience Act ? Mauvaise nouvelle pour les équipes produit, les agences et les éditeurs qui mettent encore un plugin, un thème ou un connecteur à disposition dans l’Union européenne. Depuis le 11 septembre 2026, une obligation très concrète est déjà en vigueur : signaler, dans un délai de 24 heures, toute vulnérabilité activement exploitée. Le champ d’application est plus large qu’il n’y paraît. La gratuité n’exonère personne. Et un simple nom de marque apposé sur un livrable numérique peut suffire à vous qualifier de fabricant.

Cette règle n’est pas un détail administratif destiné aux seuls industriels de l’électronique. Elle concerne aussi les startups marketing, les studios qui publient des extensions, les intégrateurs qui packagent un connecteur CRM, les éditeurs de thèmes et, dans certains cas, des acteurs qui croyaient n’être « que » des prestataires. Voici, sans jargon inutile, ce que le règlement change réellement, ce qui s’applique déjà et ce qui peut encore attendre.

Ce Que Le Texte Change Vraiment Pour Les Éditeurs

Le règlement UE 2024/2847, plus connu sous le nom de Cyber Resilience Act (CRA), vise les produits comportant des éléments numériques : logiciels, matériels connectés, combinaisons des deux, et certaines fonctions distantes indispensables au fonctionnement du produit. L’idée politique est simple : trop de failles circulent trop longtemps, trop de correctifs arrivent trop tard, trop de maillons de la chaîne d’approvisionnement restent opaques.

Le législateur européen a donc fixé deux couches d’obligations. D’un côté, des exigences essentielles de sécurité, de documentation et de marquage, qui entreront pleinement en application le 11 décembre 2027. De l’autre, une procédure de signalement des vulnérabilités activement exploitées et des incidents graves, déjà applicable depuis le 11 septembre 2026. Confondre les deux dates est l’erreur la plus fréquente dans les feuilles de route internes.

Le règlement est en vigueur depuis décembre 2024. Ce qui a basculé en septembre 2026, ce n’est pas le texte lui-même, c’est l’obligation de déclarer.

– Synthèse opérationnelle du calendrier CRA

Autrement dit : vous pouvez encore travailler votre dossier technique et votre stratégie de marquage. Vous ne pouvez plus improviser la détection, la qualification et la déclaration d’un incident. Si un exploit circule demain matin sur un connecteur publié sous votre marque, le compteur de 24 heures démarre dès que vous en avez connaissance.

Le Calendrier À Ne Plus Compactifier En Une Seule Date

Beaucoup de présentations internes réduisent encore le CRA à « décembre 2027 ». C’est confortable. C’est incomplet. Le texte s’articule autour de plusieurs jalons, qui ne concernent pas les mêmes acteurs ni les mêmes livrables.

Le 10 décembre 2024, le règlement entre en vigueur : le délai légal commence à courir, sans créer d’obligation opérationnelle immédiate pour les fabricants. Le 11 juin 2026, les États membres et les organismes notifiés doivent avancer sur la notification des organismes d’évaluation de la conformité. Le 11 septembre 2026, l’article 14 s’applique : signalement des vulnérabilités activement exploitées et des incidents graves, y compris pour des produits déjà commercialisés. Le 11 décembre 2027, arrivent les exigences essentielles, le marquage, la documentation technique et le régime plus large impliquant fabricants, importateurs, distributeurs et certains gestionnaires de logiciels libres.

• 10 décembre 2024 : entrée en vigueur du règlement, horloge juridique lancée.
• 11 juin 2026 : volet organismes d’évaluation et États membres.
• 11 septembre 2026 : obligations de signalement déjà opposables.
• 11 décembre 2027 : exigences essentielles, CE, dossier technique.

Si votre plan de conformité ne contient qu’une ligne « projet CRA 2027 », il manque au minimum un runbook d’alerte, un inventaire des produits déjà distribués et une personne habilitée à déposer une déclaration sur la plateforme unique.

Comment Fonctionne Le Signalement En Pratique

Le mécanisme a été conçu pour éviter la multiplication des canaux. Une déclaration part via la plateforme unique opérée par l’ENISA, ouverte depuis le 11 septembre 2026. L’information est destinée au CSIRT de l’État membre où se trouve votre établissement principal, et elle est mise à disposition de l’ENISA au même moment. Une seule déclaration. Plusieurs destinataires institutionnels.

Le rythme n’est pas celui d’un ticket support classique. Dès que le fabricant a connaissance d’une vulnérabilité activement exploitée ou d’un incident grave affectant la sécurité du produit, trois échéances s’enchaînent.

• Alerte précoce sous 24 heures.
• Notification principale sous 72 heures.
• Rapport final au plus tard 14 jours après la mise à disposition d’une mesure corrective pour une vulnérabilité exploitée, ou dans le mois suivant la notification à 72 heures pour un incident grave.

Ces délais ne sont pas décoratifs. Ils imposent d’avoir déjà tranché, en interne, deux questions que beaucoup d’équipes laissent encore flotter : qui décide qu’une faille est « activement exploitée » plutôt qu’une simple faiblesse signalée ? Qui a le droit de cliquer sur « envoyer » dans la plateforme ? Sans ces deux réponses, le délai de 24 heures se transforme en improvisation de weekend.

Une nuance utile pour les structures de petite taille : les fabricants relevant des microentreprises ou des petites entreprises ne peuvent pas se voir infliger une sanction financière pour le seul non-respect du délai de 24 heures. L’obligation de signaler demeure. Seule la pénalité liée à ce délai précis est écartée. Les gestionnaires de logiciels libres, de leur côté, ne sont pas exposés à des sanctions en cas de manquement au règlement. Cela ne signifie pas que le sujet n’existe pas pour un projet open source largement redistribué : cela signifie que le régime répressif n’est pas le même.

Qui Est Fabricant, Même Sans Usine Ni Catalogue Payant

La définition retenue par le texte est volontairement large. Est fabricant toute personne physique ou morale qui développe ou fait développer un produit comportant des éléments numériques et le met sur le marché sous son nom ou sa marque. Contre paiement. Via une monétisation indirecte. Ou gratuitement.

C’est ce dernier point qui surprend encore les agences. Publier un plugin WordPress sous sa marque pour générer de la notoriété, offrir un thème pour capter des leads, distribuer un connecteur « gratuit » qui pousse vers une offre premium : autant de situations qui méritent un examen juridique, pas un réflexe du type « ce n’est pas un produit, donc ce n’est pas pour nous ».

La mise à disposition sur le marché suit la même logique. Il s’agit de fournir un produit pour distribution ou utilisation dans l’Union, dans le cadre d’une activité commerciale, payante ou non. Le critère n’est pas le prix affiché. C’est le fait de placer un livrable numérique dans le circuit économique européen sous une identité identifiable.

La gratuité ne vous sort pas du règlement. C’est souvent elle qui crée le faux sentiment de sécurité.

– Lecture opérationnelle de la notion de fabricant

Les distributeurs ne sont pas spectateurs. Ils doivent notamment vérifier le marquage lorsque celui-ci s’appliquera, et informer le fabricant dès qu’ils ont connaissance d’une vulnérabilité. Les précédents du web le montrent sans détour : une extension largement installée peut exposer des millions de sites en quelques heures. Une faille dans un slider populaire a déjà illustré la vitesse à laquelle un composant « annexe » devient un risque de chaîne d’approvisionnement.

Le Cas Du SaaS Reste Une Zone Grise À Qualifier

Tous les modèles numériques ne tombent pas aussi clairement dans le texte. Un SaaS pur, accessible uniquement depuis un navigateur, sans composant logiciel distribué chez le client, n’est pas tranché de façon aussi nette que un firmware, une application installable ou un plugin. Le règlement vise les produits logiciels et matériels, ainsi que certaines solutions de traitement de données à distance dont l’absence empêcherait le produit d’assurer l’une de ses fonctions.

Un outil marketing 100 % web se situe donc dans une zone d’interprétation. Si votre service n’existe que comme interface distante, il serait imprudent de conclure seul à une exclusion définitive, tout autant que d’affirmer une inclusion automatique. La bonne pratique, ici, est de faire qualifier le cas : architecture, présence ou non d’un client lourd, d’un SDK, d’un agent, d’une application mobile, d’un connecteur installable, d’une brique indispensable hébergée à distance.

Pour les startups product-led, cette qualification n’est pas un luxe juridique. Elle conditionne le niveau de process à mettre en place dès maintenant. Un connecteur installé chez le client et un tableau de bord 100 % cloud ne déclenchent pas le même réflexe opérationnel, même si les deux portent la même marque.

Les Produits Anciens Sont Déjà Dans Le Périmètre De Déclaration

Autre malentendu fréquent : « on s’occupera du CRA sur la prochaine version majeure ». Sur le volet signalement, cette phrase est fausse. Les obligations de déclaration concernent les produits comportant des éléments numériques mis à disposition sur le marché de l’Union, y compris ceux commercialisés bien avant décembre 2027.

Un connecteur publié en 2021, encore téléchargeable, encore maintenu de façon minimale, encore présenté sur une page de ressources, peut déjà entrer dans le périmètre. Il n’est pas nécessaire d’attendre le marquage de 2027 pour savoir quoi déclarer si un exploit apparaît. Il est en revanche indispensable de savoir quels livrables existent encore sous votre nom.

Pour un éditeur qui a empilé des intégrations au fil des années, l’inventaire n’est plus un exercice de gouvernance optionnel. C’est le prérequis du signalement. Sans liste, pas de qualification rapide. Sans qualification rapide, le délai de 24 heures devient un sprint dans le brouillard.

• Recenser les plugins, thèmes, SDK, connecteurs et applications encore distribués.
• Noter la marque sous laquelle chaque livrable circule.
• Identifier le niveau de maintenance réel, même s’il est minimal.
• Repérer les forks, les versions « legacy » et les pages de téléchargement oubliées.

Pourquoi Les Agences Marketing Sont Plus Exposées Qu’elles Ne Le Croient

Dans l’écosystème digital, le mot « produit » évoque souvent une application vendue en self-serve. Or une agence peut se retrouver fabricant sans avoir jamais ouvert une boutique en ligne. Elle développe un module sous son nom. Elle le fait développer par un freelance. Elle le met en téléchargement pour nourrir l’inbound. Elle l’installe chez plusieurs clients tout en le présentant comme un actif maison.

Le risque n’est pas seulement réglementaire. Il est commercial. Les questionnaires de sécurité des grands comptes intègrent déjà des questions sur la gestion des vulnérabilités, les délais de notification et l’existence d’une procédure écrite. Répondre « on verra en 2027 » devient de plus en plus difficile à défendre. À l’inverse, une procédure datée, nominative, testée une fois par an, devient un argument de confiance.

Le CRA s’inscrit aussi dans une tendance plus large : le durcissement des règles sur les données, la sécurité des chaînes logicielles et la responsabilité des acteurs qui mettent un composant en circulation. Les équipes juridiques le suivent. Les équipes commerciales commencent à le croiser dans les appels d’offres. Les équipes produit n’ont plus le luxe de le traiter comme un sujet parallèle.

Construire Une Procédure De Signalement Qui Tient Le Weekend

Une procédure utile n’est pas un mémo de trois pages oublié dans un drive. C’est une chaîne de décisions qui fonctionne un dimanche soir, quand le premier signal arrive via un chercheur, un client ou un fil public. Cinq rôles doivent être clarifiés à l’avance.

Qui détecte ? Désignez la personne ou l’équipe qui reçoit les signalements externes. Une adresse de contact identifiable, surveillée, documentée. Pas une boîte générique que personne n’ouvre pendant les congés.

Qui qualifie ? La distinction entre faille signalée et vulnérabilité activement exploitée déclenche le délai. Cette qualification ne peut pas être improvisée par la première personne disponible sur Slack. Définissez des critères, un second regard, un seuil de déclenchement.

Qui déclare ? Identifiez la personne habilitée à déposer le dossier sur la plateforme ENISA, plus un suppléant. Vérifiez les accès avant l’incident, pas pendant.

Quel CSIRT ? Le destinataire dépend de l’État membre de l’établissement principal. Cette information doit figurer dans la procédure, pas dans un fil de discussion ouvert à 23 heures.

Qui informe les clients ? Le signalement réglementaire ne remplace ni les clauses contractuelles, ni, le cas échéant, les notifications prévues par le RGPD lorsqu’une violation de données personnelles est en jeu. Deux horloges peuvent tourner en parallèle. Les confondre crée des angles morts.

• Adresse de contact unique et surveillée.
• Critères écrits de qualification « activement exploitée ».
• Déclarant principal et remplaçant nommés.
• CSIRT compétent identifié selon l’établissement principal.
• Parcours client et parcours RGPD distincts du dépôt réglementaire.

Ce Que Les Équipes Produit Peuvent Faire Cette Semaine

Inutile d’attendre un programme de conformité de dix-huit mois pour poser les bases. Deux actions suffisent à sortir du déni opérationnel. La première : lister tout ce qui circule sous votre nom ou votre marque dans l’Union, y compris les livrables gratuits. La seconde : écrire qui signale quoi, à qui, dans quels délais.

Ensuite seulement vient le travail de fond prévu pour 2027 : exigences essentielles, dossier technique, marquage, relations avec importateurs et distributeurs, arbitrages open source. Ce second étage est réel. Il n’efface pas le premier. Traiter 2027 sans traiter 2026, c’est construire une documentation pendant que l’obligation de déclarer est déjà là.

Les startups qui vendent de la confiance — et c’est le cas de presque toutes celles qui touchent aux données, au marketing automation, au e-commerce ou aux intégrations — ont intérêt à transformer cette contrainte en preuve de maturité. Une procédure courte, testée, attribuée, vaut mieux qu’un discours général sur la sécurité.

Incidents, Correctifs Et Communication : Trois Relais Distincts

Le CRA force à séparer ce que beaucoup d’organisations mélangent encore. Le dépôt réglementaire n’est pas un communiqué de presse. L’information client n’est pas un post-mortem technique. La notification données personnelles n’est pas un ticket de patch. Chacun de ces relais a son destinataire, son délai, son niveau de détail.

En interne, cela suppose un langage commun. « On a une CVE » n’est pas équivalent à « on a une exploitation en cours ». « On a poussé un correctif » n’est pas équivalent à « le rapport final peut partir ». « On a prévenu le CSIRT » n’est pas équivalent à « les clients contractuellement concernés ont été informés ». Plus le vocabulaire est flou, plus le risque de rater une échéance augmente.

Les équipes communication digitale, souvent sollicitées trop tard, doivent être dans la boucle sans devenir le canal de déclaration. Leur rôle est de préparer des messages factuels, de ne pas divulguer d’informations exploitables, et de rester alignées avec ce qui a été déposé. Une communication trop bavarde peut aggraver l’exposition. Une communication trop tardive peut casser la confiance.

Open Source, Marques Blanches Et Prestataires : Les Zones De Friction

Le logiciel libre occupe une place particulière. Les gestionnaires de projets open source ne sont pas soumis au même régime de sanctions. Cela n’autorise pas une entreprise qui reprend un composant libre, le package, le revend ou le distribue sous sa marque à considérer qu’elle hérite de cette clémence. Le point de bascule, encore une fois, est souvent la mise sur le marché sous une identité commerciale.

Les schémas de marque blanche créent une autre friction. Qui est fabricant si une agence développe, un éditeur revend et un intégrateur installe ? La réponse dépend de qui commercialise sous son nom. Les contrats devraient désormais le dire noir sur blanc : qui déclare, qui corrige, qui informe, qui conserve les preuves de connaissance de l’incident. Sans clause, le premier réflexe en crise sera de se renvoyer la responsabilité pendant que le délai de 24 heures continue de courir.

Les prestataires qui « font développer » un produit pour le commercialiser ensuite sous leur marque restent dans le viseur. Déléguer le code n’est pas déléguer la qualification juridique de fabricant. C’est même l’un des scénarios explicitement couverts par la définition.

Ce Que Le CRA Dit De La Maturité Des Entreprises Digitales

Au-delà du droit, le texte envoie un signal culturel. L’époque où l’on pouvait publier un composant, le laisser vivre sans maintenance claire et traiter les failles comme des accidents isolés touche à sa fin sur le marché européen. La sécurité n’est plus seulement une qualité interne. C’est une condition de circulation du produit.

Pour les entreprises de la tech marketing, cela rejoint d’autres exigences déjà familières : traçabilité, consentement, documentation, responsabilité de la chaîne. Le CRA n’invente pas la prudence. Il la rend opposable, avec des délais courts et une plateforme unique qui réduit les excuses organisationnelles.

Les organisations qui s’en sortiront le mieux ne seront pas forcément les plus grandes. Ce seront celles qui savent encore ce qu’elles ont publié, qui nomment des responsables, et qui acceptent qu’un plugin « offert » n’est pas un objet juridiquement neutre.

Points De Vigilance Avant La Vague De 2027

Le signalement n’épuise pas le sujet. À l’horizon décembre 2027, d’autres couches arriveront : exigences essentielles de sécurité, documentation technique, marquage, obligations propres aux importateurs et distributeurs. Anticiper ces couches sans bloquer l’activité est possible si l’on sépare clairement l’urgent et l’important.

Urgent : inventaire, qualification fabricant, procédure de déclaration, accès à la plateforme, identification du CSIRT, articulation avec le RGPD et les contrats clients. Important : conception sécurisée, gestion des mises à jour, preuves de conformité, relations avec les organismes d’évaluation, stratégie de marquage, arbitrage sur les produits legacy trop coûteux à maintenir.

Certaines équipes choisiront d’arrêter un vieux connecteur plutôt que de le faire entrer dans un régime plus lourd. D’autres investiront pour le conserver, parce qu’il reste un levier commercial. Dans les deux cas, la décision doit être consciente. Laisser un livrable en téléchargement « au cas où » n’est plus une stratégie neutre.

Une Lecture Utile Pour Les Fondateurs Et Les CMO

Si vous dirigez une startup ou une équipe marketing qui publie des assets techniques, posez-vous trois questions brutales. Qu’est-ce qui circule encore sous notre marque dans l’Union ? Qui saurait déclarer une exploitation active avant-demain matin ? Que promettons-nous déjà à nos clients en matière d’information incident, au-delà du règlement ?

Ces questions valent mieux qu’un débat abstrait sur « est-ce que le CRA nous concerne ». Dans beaucoup de cas, la réponse n’est pas binaire. Elle dépend du livrable, du canal de distribution, de la marque affichée, de la présence d’un composant installable. Plus vous documentez tôt, moins vous subirez la qualification dans l’urgence.

Le Cyber Resilience Act n’est pas un sujet à repousser à 2027 pour quiconque distribue un logiciel dans l’Union européenne, y compris gratuitement. Les obligations de signalement sont déjà applicables. Elles concernent aussi les produits existants. Recenser ce qui circule sous votre nom et formaliser qui doit signaler quoi, dans quels délais, reste le moyen le plus simple de poser les bases. Le reste du règlement viendra. Le compteur de 24 heures, lui, a déjà démarré.