Le calendrier du Cyber Resilience Act se précise. Pour les entreprises qui commercialisent des logiciels, équipements connectés ou solutions numériques sous leur propre nom, le premier changement opérationnel n’attendra pas 2027 : certaines failles et certains incidents devront être signalés dès septembre 2026.
Ce qui vient de se passer
Le 27 juillet 2026, la Commission européenne a publié « Commission publishes new guidance to support timely Cyber Resilience Act implementation ». Ces orientations non contraignantes précisent notamment le périmètre des produits concernés, la notion de modification substantielle, les périodes de support et les obligations de signalement. Le document comprend 67 exemples pratiques, cas d’usage, schémas et arbres de décision destinés notamment aux petites structures. Les obligations générales de conformité s’appliqueront le 11 décembre 2027, mais le signalement des vulnérabilités activement exploitées et des incidents graves commencera le 11 septembre 2026. La plateforme unique de signalement gérée par l’ENISA doit être opérationnelle à cette date, avec une phase de test annoncée en amont.
Pourquoi cela concerne votre entreprise — ou pas
Le Cyber Resilience Act, ou CRA, ne s’adresse pas à toutes les entreprises qui utilisent un ordinateur, un ERP ou un service cloud. Il vise principalement les acteurs qui mettent sur le marché européen un « produit comportant des éléments numériques » : logiciel, application, équipement connecté ou composant matériel capable de communiquer directement ou indirectement avec un appareil ou un réseau.
Le point déterminant n’est donc pas la taille de l’entreprise, mais son rôle dans la chaîne de valeur. Le règlement européen sur la cyberrésilience considère notamment comme fabricant l’organisation qui développe — ou fait développer — un produit numérique et le commercialise sous son nom ou sa marque. Les obligations peuvent également basculer vers un importateur ou un distributeur qui appose sa propre marque ou réalise une modification substantielle avant de remettre le produit sur le marché.
| Votre situation | Obligation directe au 11 septembre 2026 | Décision à prendre |
|---|---|---|
| Vous éditez un logiciel vendu ou fourni sous votre marque | Oui, si le logiciel entre dans le champ du CRA | Identifier les versions en circulation et organiser le signalement |
| Vous commercialisez un objet connecté ou une machine intégrant un logiciel | Oui, si la connexion numérique fait partie du produit | Relier le suivi matériel, logiciel et sécurité |
| Vous distribuez une solution tierce en marque blanche | Probablement, car vous pouvez être considéré comme fabricant | Vérifier immédiatement la répartition contractuelle des responsabilités |
| Vous modifiez fortement un produit tiers avant de le commercialiser | Potentiellement, si la modification affecte sa finalité ou son niveau de risque | Documenter la modification et faire qualifier votre rôle |
| Vous revendez sans modification un produit portant la marque du fabricant | Pas au titre de l’article 14 comme fabricant | Identifier le canal d’escalade vers le fabricant |
| Vous utilisez simplement des logiciels et équipements achetés | Non, sauf changement de rôle ou remise sur le marché | Renforcer les clauses fournisseurs et la gestion des alertes |
| Vous développez un outil uniquement pour votre usage interne | En principe non, s’il n’est pas mis sur le marché | Maintenir vos contrôles cyber habituels |
Un service SaaS ou cloud générique n’entre pas automatiquement dans le CRA. En revanche, un traitement distant indispensable au fonctionnement d’un produit numérique, conçu sous la responsabilité de son fabricant, peut être inclus dans le périmètre. Cette distinction doit être rapprochée de votre architecture et de vos contrats cloud ; notre checklist de migration vers le cloud fournit une base utile pour inventorier les services, dépendances et responsabilités.
Ce que cela change, concrètement
L’échéance de septembre ne demande pas encore de finaliser l’ensemble du dossier technique, du marquage CE et de l’évaluation de conformité prévus pour décembre 2027. Elle impose toutefois aux fabricants concernés d’être capables de reconnaître, qualifier et déclarer rapidement deux catégories d’événements :
- une vulnérabilité contenue dans un produit et effectivement exploitée par un acteur malveillant ;
- un incident grave affectant la sécurité du produit, notamment sa disponibilité, son intégrité, son authenticité ou la confidentialité des données et fonctions sensibles.
Selon les règles de signalement présentées par la Commission européenne, une alerte initiale doit être transmise dans les 24 heures suivant la prise de connaissance, puis une notification complétée dans les 72 heures. Pour une vulnérabilité exploitée, le rapport final est attendu au plus tard 14 jours après la disponibilité d’une mesure corrective ; pour un incident grave, il doit être transmis dans le mois suivant la notification principale.
Cela modifie plusieurs tâches très concrètes.
Le support client ne peut plus traiter une alerte comme un simple ticket
Un message tel que « notre antivirus détecte une activité étrange dans votre application » ou « un accès non autorisé semble exploiter votre équipement » doit pouvoir quitter immédiatement la file du support standard. Le support doit disposer d’un motif d’escalade explicite, d’un contact IT ou sécurité nommé et d’un moyen de conserver le message initial, les pièces jointes et l’heure exacte de réception.
L’IT doit démarrer le chronomètre sur un fait vérifiable
Le délai réglementaire commence lorsque le fabricant prend connaissance de l’événement, et non lorsque l’analyse technique est terminée. L’IT ou le RSSI doit donc enregistrer l’heure de découverte, le produit et la version concernés, les premiers indices d’exploitation, les pays dans lesquels le produit a été commercialisé et les mesures déjà engagées.
Une entreprise qui attend un rapport d’expertise définitif avant d’escalader risque de perdre l’essentiel de la fenêtre de signalement. Le processus doit permettre une déclaration initiale incomplète, puis son enrichissement.
Le responsable produit doit connaître les versions encore en circulation
Le reporting s’applique aussi aux produits concernés déjà mis sur le marché avant le 11 décembre 2027. Une ancienne version toujours utilisée chez des clients ne peut donc pas être ignorée au seul motif qu’elle n’est plus vendue.
Le registre produit doit relier au minimum le nom commercial, les versions diffusées, le responsable interne, les composants critiques connus, les territoires de distribution et le statut de support. Cette cartographie complète utilement les principes de gouvernance présentés dans notre article sur la stratégie numérique des PME et ETI en 2026.
Les contrats avec les développeurs et hébergeurs deviennent une dépendance réglementaire
Si une partie du produit est développée, supervisée ou hébergée par un prestataire, celui-ci peut découvrir la faille avant vous. Le contrat doit imposer une notification immédiate vers un canal identifié, la conservation des journaux techniques, la participation à l’analyse et la transmission des informations nécessaires au rapport final.
Cette clause ne transfère pas automatiquement la responsabilité du fabricant. Elle évite que l’information reste bloquée dans le système de tickets d’un sous-traitant pendant que le délai réglementaire court.
La direction doit attribuer le pouvoir de déclarer
Une procédure qui exige successivement l’accord du développeur, du juridique, du directeur commercial puis du dirigeant est incompatible avec une alerte initiale urgente. La direction doit nommer un titulaire et un suppléant autorisés à saisir la plateforme de l’ENISA, tout en définissant les informations qui nécessitent une validation juridique avant diffusion.
Ce type d’organisation dépasse la seule cybersécurité : c’est un sujet de gouvernance, de responsabilités et de continuité. Si l’entreprise ne dispose pas d’un DSI permanent, le cadre proposé dans notre analyse du DSI à temps partagé peut aider à attribuer ces rôles sans créer une fonction interne supplémentaire.
Ce qu’il faut faire d’ici le 11 septembre 2026
- D’ici le 7 août — Dirigeant et DSI/RSSI : signer une note de périmètre recensant les logiciels, équipements et composants commercialisés, le nom sous lequel ils sont vendus, les pays de distribution et le rôle juridique de l’entreprise. Le livrable attendu est un registre produit avec un responsable désigné pour chaque ligne.
- D’ici le 21 août — IT et responsables produit : rédiger une fiche réflexe CRA distinguant vulnérabilité exploitée, incident grave et événement hors périmètre. Elle doit indiquer le canal de réception, l’heure de prise de connaissance, les éléments techniques à conserver, le décideur et les informations nécessaires aux notifications réglementaires.
- D’ici le 28 août — Juridique, achats et IT : vérifier les contrats des développeurs, mainteneurs, hébergeurs et fournisseurs de composants. Produire un avenant type imposant l’escalade immédiate des incidents, l’accès aux journaux utiles, la coopération technique et l’identification d’un contact joignable.
- D’ici le 4 septembre — IT, support et communication : exécuter un exercice à blanc à partir d’une alerte fictive clairement identifiée comme telle. Le livrable doit comprendre le journal chronologique, le brouillon de notification, la décision de qualification et un modèle de message destiné aux utilisateurs.
- À compter du 11 septembre — Dirigeant et IT : activer la permanence de décision, contrôler l’accès à la plateforme unique de signalement de l’ENISA et intégrer les délais officiels dans l’outil de gestion des incidents.
Le pilotage peut être intégré à un chantier plus large de conformité produit. Notre offre de Direction de projet IT permet de cadrer le périmètre, construire le registre, attribuer les responsabilités et organiser la recette du processus de signalement.
Ce que vous pouvez ignorer pour l’instant
Vous n’avez pas à transformer chaque alerte de sécurité en déclaration réglementaire. Les vulnérabilités simplement théoriques, non exploitées, ne relèvent pas automatiquement du signalement obligatoire prévu en septembre. Elles doivent néanmoins continuer à être analysées et corrigées selon votre processus de gestion des vulnérabilités.
Vous n’avez pas non plus à achever d’ici septembre l’ensemble du dossier de conformité prévu pour le 11 décembre 2027. L’évaluation des risques, la documentation technique complète, la déclaration européenne de conformité et les obligations associées au marquage CE suivent ce second calendrier. La priorité immédiate est le circuit de détection et de notification.
Enfin, une simple mise à jour de sécurité destinée à réduire le risque ne constitue généralement pas une modification substantielle. Une nouvelle fonction modifiant l’usage prévu ou élargissant la surface d’attaque peut, en revanche, imposer une nouvelle analyse. Il n’est donc pas nécessaire de bloquer toutes les mises à jour : il faut ajouter un critère CRA dans la validation des changements.
Notre lecture chez D1 Consulting
Le risque principal n’est pas de manquer un document juridique : c’est de découvrir, lors du premier incident, que personne ne sait précisément quand l’entreprise a été informée, qui peut qualifier l’événement et qui est autorisé à le déclarer.
Le guide du 27 juillet réduit l’incertitude, mais il ne remplace pas un processus interne exécutable. Pour les éditeurs, intégrateurs en marque blanche et fabricants d’équipements connectés, le bon objectif d’ici septembre est donc un circuit court : une entrée identifiable, une qualification documentée, un décideur disponible et une trace complète.
Ce chantier doit ensuite alimenter la préparation de décembre 2027, notamment le registre des produits, la gestion des versions, la documentation des risques et les exigences imposées aux fournisseurs. Pour renforcer parallèlement votre capacité de détection et de réaction, consultez également notre guide pour protéger votre entreprise contre les attaques informatiques exploitant l’IA.
👉 Réservez un diagnostic gratuit de 30 minutes pour vérifier votre périmètre CRA et repartir avec une liste datée des documents, rôles et workflows à mettre en place.
