Le Cyber Resilience Act (CRA), publié sous la référence Règlement (UE) 2024/2847, est entré en vigueur le 10 décembre 2024. Pour la première fois, l’Union européenne impose des exigences de cybersécurité contraignantes aux fabricants de “produits à éléments numériques”, logiciels ERP compris. Les premières obligations de signalement s’appliquent dès septembre 2026, la conformité complète étant requise en décembre 2027.
Pour les DSI et RSSI d’ETI européennes, ce règlement change la donne : il transforme la cybersécurité d’un sujet contractuel bilatéral en une obligation réglementaire vérifiable, avec marquage CE à la clé.
Le CRA en bref : pourquoi l’Europe réglemente les produits numériques
Après NIS2 et DORA, le CRA cible les produits eux-mêmes
L’architecture réglementaire européenne en cybersécurité repose désormais sur trois piliers complémentaires :
- NIS2 cible les opérateurs de services essentiels et importants (la demande)
- DORA encadre la résilience numérique du secteur financier (un secteur spécifique)
- Le CRA réglemente les produits numériques eux-mêmes (l’offre)
Cette distinction est fondamentale. NIS2 dit “vous devez sécuriser vos systèmes”. Le CRA dit “les produits que vous achetez doivent être sécurisés par conception”. Pour un DSI, cela signifie que la conformité ne repose plus uniquement sur ses épaules : l’éditeur de l’ERP a désormais des obligations légales propres.
Calendrier : trois dates à retenir
Le CRA s’applique progressivement selon un calendrier précis (source : Commission européenne) :
| Date | Obligation |
|---|---|
| 11 juin 2026 | Mise en place des organismes d’évaluation de conformité par les États membres |
| 11 septembre 2026 | Entrée en vigueur des obligations de signalement des vulnérabilités et incidents graves |
| 11 décembre 2027 | Conformité complète exigée : exigences de sécurité, documentation technique, marquage CE |
Le point critique pour les entreprises : dès septembre 2026, tout éditeur qui découvre une vulnérabilité activement exploitée dans son ERP devra la signaler à l’ENISA sous 24 heures via la plateforme unique de signalement (CRA Reporting Platform).
Qui est concerné : fabricants, importateurs, distributeurs
Le CRA s’applique à toute la chaîne de distribution des produits à éléments numériques :
- Fabricants (éditeurs ERP) : responsabilité principale, de la conception à la fin de vie du produit
- Importateurs : doivent vérifier que les produits non-UE sont conformes avant mise sur le marché
- Distributeurs : doivent s’assurer du marquage CE et de la conformité déclarée
Un intégrateur qui distribue un ERP non-européen sur le marché de l’UE (un revendeur de NetSuite ou d’un ERP indien, par exemple) devient importateur au sens du CRA, avec les obligations associées.
Ce que le CRA impose aux éditeurs d’ERP
Sécurité par conception et par défaut
Le CRA introduit le principe de “security by design, security by default” comme obligation légale. Concrètement, un éditeur ERP doit :
- Intégrer la cybersécurité dès la phase de conception du produit
- Livrer le produit dans une configuration sécurisée par défaut (pas de mots de passe par défaut, chiffrement activé, ports inutiles fermés)
- Réaliser une évaluation des risques de cybersécurité documentée
- Exercer une diligence raisonnable sur les composants tiers intégrés
Pour les DSI, c’est un levier contractuel puissant : un éditeur qui livre un ERP avec des paramètres de sécurité laxistes par défaut sera en infraction.
Mises à jour de sécurité pendant toute la durée de vie
L’éditeur doit garantir des mises à jour de sécurité pendant toute la “durée de support” qu’il déclare pour son produit. Cette durée doit être clairement communiquée avant l’achat. Les mises à jour de sécurité doivent être gratuites et séparées des mises à jour fonctionnelles.
C’est un changement majeur pour les éditeurs qui conditionnent les correctifs de sécurité à un contrat de maintenance payant ou qui cessent le support de versions “en fin de vie” sans préavis suffisant.
Signalement des vulnérabilités sous 24 heures
Dès septembre 2026, les fabricants devront signaler les vulnérabilités activement exploitées via la plateforme unique de l’ENISA, selon un protocole en trois temps (source) :
- Alerte précoce sous 24 heures : notification initiale au CSIRT national et à l’ENISA
- Notification complète sous 72 heures : détail de la vulnérabilité, périmètre d’impact, mesures prises
- Rapport final sous 14 jours (vulnérabilités) ou 1 mois (incidents graves) : analyse complète et correctifs déployés
Ce calendrier de signalement est contraignant. Un éditeur ERP qui découvre un lundi matin qu’une faille de son module comptable est exploitée doit avoir notifié l’ENISA avant le mardi matin.
Documentation technique et marquage CE logiciel
Le CRA étend le marquage CE, historiquement réservé aux produits physiques, aux logiciels. Un ERP commercialisé dans l’UE après décembre 2027 devra porter le marquage CE attestant de sa conformité aux exigences de cybersécurité.
La procédure d’évaluation de conformité dépend de la catégorie du produit :
| Catégorie | Procédure | Exemples ERP |
|---|---|---|
| Produit standard | Auto-évaluation (Module A) | Petit ERP métier sans composant réseau critique |
| Important Classe I | Auto-évaluation si normes harmonisées appliquées | ERP standard du marché |
| Important Classe II | Évaluation par un organisme tiers | ERP gérant des données sensibles ou critiques |
| Critique | Évaluation par un organisme tiers obligatoire | ERP pour infrastructures critiques |
La documentation technique doit inclure un SBOM (Software Bill of Materials), inventaire machine-lisible de tous les composants logiciels, au minimum les dépendances de premier niveau, dans un format standardisé comme CycloneDX ou SPDX (source : FOSSA). Ce SBOM n’est pas rendu public mais doit être disponible pour les autorités de surveillance du marché.
Open source : les éditeurs commerciaux sont bien concernés
Le CRA distingue deux cas de figure pour le logiciel open source :
- Open source non commercial (projet communautaire bénévole, sans monétisation) : exclu du périmètre du CRA
- Open source distribué commercialement : pleinement soumis aux obligations du CRA
Un éditeur comme Odoo (qui vend du support, de l’hébergement et des modules propriétaires autour d’un noyau open source) est un fabricant au sens du CRA, avec toutes les obligations associées. De même pour toute entreprise qui distribue ERPNext dans le cadre d’une offre commerciale.
Le CRA crée aussi la notion d‘“open source software steward” : une entité qui soutient systématiquement le développement d’un logiciel open source destiné à un usage commercial, sans le distribuer elle-même. Les stewards ont des obligations allégées (politique de cybersécurité, signalement des vulnérabilités) et ne sont pas soumis aux amendes administratives (source : Commission européenne).
Impact concret pour les DSI qui achètent un ERP
Nouvelles clauses à exiger dans les contrats éditeurs
Le CRA vous donne un socle réglementaire pour exiger de votre éditeur ERP des engagements qui relevaient auparavant de la négociation commerciale :
Clauses devenues non négociables post-CRA :
- Durée de support de sécurité garantie (avec date de fin explicite)
- Délai maximal de déploiement des correctifs de sécurité (SLA patch)
- Fourniture du SBOM et notification en cas de composant vulnérable
- Engagement de conformité au CRA avec production de la déclaration de conformité UE
- Processus documenté de gestion des vulnérabilités
Clause recommandée :
- Droit d’audit sur la documentation technique CRA (ou attestation par un tiers de confiance)
Que vérifier lors d’un appel d’offres ERP post-CRA
Lors d’un appel d’offres ERP lancé après septembre 2026, intégrez ces critères d’évaluation :
- Marquage CE : l’éditeur peut-il fournir (ou s’engager à fournir avant décembre 2027) une déclaration de conformité UE ?
- SBOM : l’éditeur maintient-il un SBOM à jour et peut-il le communiquer ?
- Politique de patch : quel est le SLA de correction pour les vulnérabilités critiques ? (la norme implicite du CRA : 24h de signalement, donc correction rapide attendue)
- Durée de support : quelle est la durée de support de sécurité garantie après achat ?
- Historique de signalement : l’éditeur a-t-il déjà signalé des vulnérabilités de manière transparente ?
ERP SaaS vs on-premise : le CRA s’applique-t-il différemment ?
C’est une question essentielle, et la réponse est nuancée :
- ERP on-premise (installé chez le client) : clairement un “produit à éléments numériques” au sens du CRA. Pleinement soumis.
- ERP SaaS pur (100 % cloud, rien installé localement) : en principe exclu du périmètre du CRA, car il s’agit d’un service, pas d’un produit. Il relève plutôt de NIS2.
- ERP hybride (SaaS avec composants locaux, agents, connecteurs) : les composants installés localement tombent sous le CRA. Le “remote data processing” essentiel au fonctionnement du produit est également couvert.
En pratique, la plupart des ERP du marché combinent composants locaux et cloud. Un ERP comme SAP S/4HANA (qui a des composants on-premise même en version cloud) ou un Odoo auto-hébergé sont dans le périmètre du CRA. Un ERP 100 % SaaS comme certaines offres de Sage Business Cloud relèverait de NIS2 (analyse DLA Piper).
CRA, NIS2 et DORA : comment ces trois règlements s’articulent
Tableau de synthèse : qui cible quoi
| CRA | NIS2 | DORA | |
|---|---|---|---|
| Cible | Produits numériques (l’offre) | Opérateurs de services (la demande) | Secteur financier |
| Qui est responsable | Fabricants, importateurs, distributeurs | Entités essentielles et importantes | Entités financières et leurs prestataires TIC |
| Type d’obligation | Sécurité produit, marquage CE, SBOM | Gestion des risques, signalement d’incidents | Résilience opérationnelle, tests de pénétration |
| Sanctions max | 15 M€ ou 2,5 % du CA mondial | 10 M€ ou 2 % du CA | Selon réglementation financière nationale |
| Entrée en application | Sept. 2026 (signalement), déc. 2027 (complet) | Octobre 2024 (transposition) | Janvier 2025 |
Risque de cumul réglementaire pour les ETI
Une ETI du secteur financier qui utilise un ERP on-premise est potentiellement soumise aux trois règlements simultanément :
- En tant qu’utilisatrice : NIS2 (si entité essentielle/importante) et DORA (si secteur financier)
- Son éditeur ERP : CRA (en tant que fabricant)
Le CRA allège la charge du côté utilisateur en transférant la responsabilité de la sécurité produit vers l’éditeur. Mais il crée un nouveau travail de vérification : s’assurer que l’éditeur est bien conforme au CRA, documenter cette vérification dans sa propre démarche NIS2/DORA.
Les sanctions sont à la mesure des ambitions : jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial pour les infractions aux exigences essentielles de cybersécurité, 10 millions ou 2 % pour les manquements documentaires, et 5 millions ou 1 % pour les informations trompeuses (Article 64 du CRA). Au-delà des amendes, les autorités peuvent ordonner le retrait du marché d’un produit non conforme.
Checklist DSI : se préparer au CRA en 5 actions
Le CRA entre progressivement en application. Voici les actions prioritaires pour un DSI d’ETI :
1. Auditer les composants logiciels de son ERP (SBOM)
Demandez à votre éditeur son SBOM ou, à défaut, la liste des composants tiers intégrés à votre ERP. Identifiez les composants open source et vérifiez leur statut de maintenance. C’est un exercice révélateur : beaucoup d’éditeurs découvriront des dépendances obsolètes en faisant cet inventaire.
2. Exiger la conformité CRA dans les renouvellements de contrat
Lors de chaque renouvellement de contrat éditeur, ajoutez une clause de conformité CRA avec un calendrier aligné sur les échéances réglementaires (signalement dès septembre 2026, conformité complète décembre 2027). Si l’éditeur ne peut pas s’engager, documentez-le dans votre registre de risques.
3. Vérifier la politique de patch de son éditeur
Quel est le délai moyen de correction d’une vulnérabilité critique chez votre éditeur ? Si la réponse est “ça dépend” ou “dans la prochaine version majeure”, vous avez un problème de conformité CRA en approche. Le règlement impose des correctifs pendant toute la durée de support, gratuits et séparés des mises à jour fonctionnelles.
4. Former l’équipe sécurité au signalement CRA
Le protocole de signalement du CRA (24h, 72h, 14 jours) s’applique aux fabricants, mais en tant qu’utilisateur, vous devez savoir quoi attendre de votre éditeur et comment réagir quand il vous notifie une vulnérabilité. Intégrez ce scénario dans vos exercices de gestion de crise.
5. Anticiper le marquage CE sur les futures acquisitions
À partir de décembre 2027, tout nouvel ERP mis sur le marché européen devra porter le marquage CE. Intégrez ce critère dans vos grilles d’évaluation dès maintenant, non comme un filtre éliminatoire (la date n’est pas encore passée), mais comme un indicateur de maturité : un éditeur qui prépare déjà son marquage CE est un éditeur qui prend la cybersécurité au sérieux.
Pour approfondir le cadre réglementaire européen en cybersécurité, lisez notre guide NIS2 et ERP pour les ETI, notre décryptage de DORA pour le secteur financier et notre guide complet cybersécurité ERP.
