Le règlement (UE) 2024/2847, connu sous le nom de Cyber Resilience Act (CRA), est entré en vigueur le 10 décembre 2024. Il n'impose rien d'un coup : il déploie ses obligations par phases, et la plus urgente pour toute équipe qui développe ou commercialise un logiciel avec éléments numériques arrive le 11 septembre 2026, date à laquelle la notification des vulnérabilités activement exploitées devient exigible. Quiconque fabrique, intègre ou distribue un logiciel capable de se connecter à un réseau ou à un autre appareil devrait avoir déterminé avant cette date qui est son interlocuteur (CSIRT/ENISA) et comment déclencher une alerte en 24 heures.
Qu'est-ce que le Cyber Resilience Act et à qui s'applique-t-il
Le CRA régit les exigences de cybersécurité des « produits comportant des éléments numériques » : matériel et logiciel qui se connecte, directement ou indirectement, à un autre appareil ou à un réseau. Le règlement définit trois rôles avec des obligations distinctes :
- Fabricant : la personne physique ou morale qui développe ou fabrique le produit, qu'elle le commercialise de façon payante, monétisée ou gratuite. C'est le rôle avec le plus d'obligations : évaluation de conformité, gestion des vulnérabilités pendant tout le cycle de support et notification aux autorités.
- Importateur : celui qui introduit sur le marché de l'UE un produit d'un fabricant situé en dehors de l'Union. Il doit vérifier que le fabricant a rempli ses obligations avant de le commercialiser.
- Distributeur : celui qui met le produit à disposition sur le marché sans être fabricant ni importateur. Son obligation principale est de vérifier le marquage CE et la documentation avant de distribuer.
Pour une entreprise de logiciels, il est habituel d'agir en tant que fabricant : celui qui écrit le code et le met sur le marché — aussi bien en tant que SaaS packagé, application mobile ou composant intégré dans un autre produit — assume les obligations les plus exigeantes du règlement, indépendamment du fait qu'il facture la licence ou la distribue gratuitement avec un modèle de monétisation indirecte.
Le calendrier réel : quatre dates, pas une seule
L'erreur la plus courante est de traiter le CRA comme une obligation qui « commence en 2027 ». En réalité, il déploie ses exigences en quatre moments distincts, et le deuxième est déjà pratiquement arrivé :
| Date | Ce qui entre en vigueur |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du règlement (UE) 2024/2847 |
| 11 juin 2026 | Obligations relatives à la notification des organismes d'évaluation de la conformité |
| 11 septembre 2026 | Obligations d'information des fabricants : notification des vulnérabilités activement exploitées et des incidents graves |
| 11 décembre 2027 | Application pleine du règlement : exigences essentielles de l'annexe I et marquage CE |
Ces quatre dates sont confirmées de façon concordante dans le résumé officiel de la Commission européenne et dans la note d'information de l'INCIBE sur la version en espagnol du règlement. La même chronologie est celle utilisée par la fiche de service de Summum Consultoría sur le CRA, de sorte qu'une équipe peut croiser l'une ou l'autre de ces deux sources sans trouver de divergence.
La date qui doit marquer l'agenda de toute équipe de développement n'est pas celle de l'application pleine (2027), mais celle du 11 septembre 2026 : à partir de ce jour, un fabricant qui détecte qu'une vulnérabilité de son produit est activement exploitée dispose de 24 heures pour une alerte précoce et de 72 heures pour une notification complète au CSIRT national (en Espagne, l'INCIBE-CERT) et à l'ENISA, conformément à l'article 14 du règlement.
Ce qu'un fabricant de logiciels doit avoir préparé avant septembre 2026
L'obligation de notifier en 24 heures ne s'improvise pas le jour où apparaît la vulnérabilité. Elle exige d'avoir résolu au préalable :
- Canal de notification identifié : qui est le CSIRT compétent (INCIBE-CERT pour l'Espagne) et comment le contacter en dehors des heures de travail.
- Processus interne de tri : qui décide si une vulnérabilité signalée est activement exploitée et qui autorise la notification.
- Inventaire des composants (SBOM) : sans une liste à jour des dépendances tierces utilisées par le produit, il est difficile de savoir si une vulnérabilité publiée dans une bibliothèque affecte réellement le logiciel propre.
- Politique de gestion des vulnérabilités documentée : comment sont reçus les signalements externes, comment ils sont corrigés et dans quel délai sont publiées les mises à jour de sécurité.
- Traçabilité du cycle de support : le règlement exige de maintenir la gestion des vulnérabilités pendant toute la période de support déclarée du produit, pas seulement au moment de la vente.
Rien de tout cela n'exige le marquage CE ni l'évaluation complète de conformité — cela arrive en 2027 —, mais sans ce processus minimal en place, la première vulnérabilité critique reçue après le 11 septembre 2026 sera gérée dans l'urgence et sans procédure.
Tous les produits ne sont pas traités de la même façon : classes de risque
Le règlement n'applique pas la même rigueur à tous les produits comportant des éléments numériques. L'annexe III distingue deux classes de « produits importants » avec des obligations renforcées par rapport au reste du marché :
- Classe I (auto-évaluation possible) : gestionnaires d'identité, navigateurs, gestionnaires de mots de passe, VPN, systèmes de gestion de réseau, SIEM, systèmes d'exploitation, routeurs et commutateurs domestiques, parmi 19 autres catégories listées dans l'annexe.
- Classe II (nécessite l'intervention d'un organisme externe dans certains cas) : hyperviseurs et systèmes de conteneurs, pare-feux, systèmes de détection et de prévention d'intrusion, microprocesseurs et microcontrôleurs résistants à la manipulation.
Au-dessus de ces deux classes, l'annexe IV regroupe un ensemble restreint de produits considérés comme critiques — modules de sécurité matériels (HSM), passerelles de compteurs intelligents, cartes à puce — pour lesquels un certificat européen de cybersécurité ou l'intervention d'un organisme notifié peut être exigé, sans possibilité d'auto-évaluation.
La majorité des logiciels de gestion d'entreprise, ERP, CRM ou outils verticaux n'apparaît pas dans ces listes et suit le régime général de l'annexe I, avec auto-évaluation de conformité. Mais si le produit intègre des fonctions qui recoupent ces catégories — par exemple, un module propre de gestion d'identité ou un SIEM intégré —, il convient de vérifier l'adéquation précise avant d'assumer le régime général par défaut.
Logiciel libre : une exemption réelle, mais avec des nuances
Le règlement exclut de la notion d'« activité commerciale » la fourniture de logiciels libres et open source que le fabricant ne monétise pas. La Commission européenne elle-même le confirme : la fourniture de produits qualifiés de logiciels libres et open source et non monétisés par leurs fabricants ne doit pas être considérée comme une activité commerciale aux fins du règlement.
Cela ne signifie pas qu'un projet de logiciel libre reste totalement en dehors du champ. Les « stewards » de logiciel libre — entités qui apportent un soutien structurel à un projet open source — ont des obligations plus légères (article 24) : ils doivent maintenir une politique de cybersécurité, coopérer avec les autorités et notifier les vulnérabilités à partir du 11 septembre 2026, mais ne sont pas soumis aux sanctions financières de l'article 64.10. La nuance à ne pas perdre de vue est celle d'un steward qui maintient un support commercial soutenu à des tiers : là, l'adéquation cesse d'être automatique et exige un examen au cas par cas, ce que la norme elle-même ne quantifie pas avec un seuil précis.
Erreurs fréquentes dans la lecture du CRA
- Penser que 2027 est la seule date pertinente et négliger l'obligation de notification des vulnérabilités de septembre 2026.
- Supposer que « gratuit » équivaut automatiquement à exempté, sans vérifier s'il existe une monétisation indirecte (support payant, publicité, version premium).
- Ne pas distinguer le rôle de fabricant, d'importateur ou de distributeur lorsque l'entreprise intègre un logiciel tiers dans son propre produit.
- Ne pas avoir identifié le CSIRT de contact ni un processus de tri avant l'apparition de la première vulnérabilité critique.
- Ignorer si le produit correspond à une catégorie de l'annexe III ou IV, qui exige un traitement différent du régime général.
Il existe des situations que le règlement ne résout pas par une règle simple : un produit à cheval entre deux catégories de l'annexe III, un modèle économique mixte entre code source ouvert et support commercial, ou un composant intégré au produit d'un autre fabricant sous marque blanche. Dans ces cas, la bonne réponse n'est pas de forcer une classification, mais de les traiter comme des cas nécessitant une analyse individuelle avec un conseil technique et juridique spécifique.
Comment savoir dans quelle situation se trouve votre produit
Avant de commander un audit complet de conformité, il est logique de résoudre d'abord trois questions : quel rôle occupe votre entreprise (fabricant, importateur ou distributeur), si votre produit relève du régime général ou d'une catégorie renforcée de l'annexe III/IV, et si l'exemption pour logiciel libre non commercial vous concerne. Le vérificateur CRA pour fabricants de logiciels de Summum Sistemas répond à ces trois questions en moins de deux minutes et retourne les dates et obligations applicables à votre cas concret, en marquant comme « nécessite une analyse individuelle » les cas que la norme ne résout pas automatiquement.
Questions fréquentes
Le Cyber Resilience Act s'applique-t-il à toute entreprise qui développe des logiciels ?
Il s'applique à quiconque fabrique, importe ou distribue des produits comportant des éléments numériques commercialisés dans l'Union européenne, en entendant « commercialiser » au sens large (paiement, monétisation indirecte ou distribution gratuite avec un modèle commercial). Le logiciel libre non monétisé par son fabricant est exclu de la notion d'activité commerciale.
Que se passe-t-il si mon entreprise ne respecte pas l'échéance du 11 septembre 2026 ?
Cette date active l'obligation de notifier les vulnérabilités activement exploitées en 24 heures et les notifications complètes en 72 heures. Ne pas avoir résolu le canal et le processus interne avant cette date expose l'entreprise à gérer le premier incident sans procédure, avec le risque réputationnel et de conformité que cela implique.
Le Cyber Resilience Act est-il la même chose que l'AI Act ou l'ENS ?
Non. Le CRA régit la cybersécurité des produits comportant des éléments numériques commercialisés sur le marché unique ; l'ENS régit la sécurité des systèmes des administrations publiques et de ceux qui leur fournissent des services en Espagne. Ce sont des cadres distincts, bien qu'une entreprise puisse être soumise aux deux si elle vend des logiciels aux administrations publiques.
Ai-je besoin du marquage CE dès maintenant ?
Pas encore. L'application pleine du règlement, y compris les exigences essentielles de l'annexe I et le marquage CE, est exigible à partir du 11 décembre 2027. Avant cette date, l'obligation urgente est la notification des vulnérabilités à partir de septembre 2026.
Sources officielles consultées
- INCIBE : note d'information sur le règlement de cyber-résilience (Cyber Resilience Act), consultée le 16 juillet 2026.
- Commission européenne : résumé officiel du Cyber Resilience Act, consultée le 16 juillet 2026.
- Commission européenne : exemption pour les logiciels libres et open source dans le CRA, consultée le 16 juillet 2026.
- Règlement (UE) 2024/2847 (Cyber Resilience Act), Journal officiel de l'Union européenne.
Summum Sistemas accompagne les fabricants de logiciels dans la gestion des vulnérabilités, l'inventaire des composants et la préparation technique face au CRA. La qualification de votre produit et les obligations légales exactes doivent être validées avec un conseil compétent ; le vérificateur et ce guide constituent un point de départ indicatif, et non un conseil professionnel.