Le Cyber Resilience Act (CRA) change la donne pour les agences web qui conçoivent, intègrent ou maintiennent des solutions numériques livrées à des clients européens. Même si l’on pense spontanément au matériel, le règlement vise les « products with digital elements » : des produits combinant matériel et logiciel, y compris des composants mis sur le marché séparément, avec une exigence de cybersécurité sur tout le cycle de vie.
Pour une agence, se préparer au CRA revient à transformer des “bonnes pratiques” (secure by design, gestion des vulnérabilités, suivi des dépendances) en processus auditables, planifiés et contractualisés. Les dates clés à intégrer dans la roadmap sont déjà connues : entrée en vigueur le 10/12/2024, obligations de reporting à partir du 11/09/2026, et applicabilité complète le 11/12/2027.
1) Comprendre le CRA : périmètre et impacts concrets pour une agence web
Le CRA est un règlement européen (EU) 2024/2847, publié au Journal officiel le 20/11/2024. En tant que règlement, il s’applique de manière directe et harmonisée dans l’UE, ce qui implique que les exigences de cybersécurité deviennent une base commune pour la mise sur le marché de nombreux produits numériques.
La Commission rappelle que le texte cible les « products with digital elements » : cela peut englober des logiciels, des applications, des équipements connectés, mais aussi des composants livrés séparément. Pour une agence web, le risque est de sous-estimer le périmètre : un plugin, un module packagé, un thème, un SDK ou un composant distribué à plusieurs clients peut entrer dans un cadre “produit” plutôt que “prestation”.
Le point structurant est l’exigence de gestion de la cybersécurité sur tout le cycle de vie : conception, développement, production, livraison et maintenance. Cela oblige l’agence à penser au-delà du go-live : support, correctifs, suivi des vulnérabilités et communication aux utilisateurs deviennent des éléments centraux de la conformité.
2) Intégrer les dates CRA dans une roadmap réaliste
Les jalons officiels à inscrire dans votre plan sont : entrée en vigueur le 10/12/2024, obligations de reporting à partir du 11/09/2026, et applicabilité complète le 11/12/2027. Cette séquence est essentielle pour prioriser : d’abord structurer, ensuite roder les mécanismes de notification, puis industrialiser la conformité.
Entre 2024 et 2026, l’objectif pragmatique pour une agence est d’installer l’outillage et les procédures : gouvernance sécurité, inventaire des produits et composants concernés, modèle de documentation, et chaîne de traitement des vulnérabilités. C’est aussi la bonne fenêtre pour revoir vos contrats (support, SLA, responsabilités, escalades) afin qu’ils reflètent la réalité opérationnelle attendue.
À partir du 11/09/2026, vous devez être capable de reporter rapidement certaines vulnérabilités exploitées et incidents sévères. Pour éviter de subir cette échéance, il est pertinent de simuler des exercices de notification et de tester la qualité de vos données (horodatage, versioning, SBOM, périmètre client) bien avant 2026.
3) Secure by design / secure by default : transformer l’Annexe I en standards d’agence
L’Annexe I (extraits publiés et commentés) met en avant des exigences « secure by design » et « secure by default » : limiter la surface d’attaque, fournir une configuration sécurisée par défaut, prévoir des mécanismes de mitigation d’exploitation, etc. Pour une agence, le gain est double : conformité et réduction des coûts de correctifs tardifs.
Concrètement, cela peut se traduire en “standards internes” : durcissement systématique des environnements, politiques de secrets (rotation, stockage), principes de moindre privilège, sécurisation des endpoints, désactivation des fonctions inutiles, et exigences minimales de journalisation. L’idée est de rendre ces points non négociables, au même titre que des critères de performance ou d’accessibilité.
Pour rester opérationnel, formalisez ces exigences dans des checklists de livraison (pré-prod et prod), des templates d’architecture, et des “Definition of Done” sécurité par typologie de projet (site vitrine, e-commerce, SaaS, API). Plusieurs checklists d’actions typiques dérivées de l’Annexe I (SBOM, vuln handling, support, correctifs) peuvent servir de base pour standardiser vos pratiques.
4) Analyse de risque cybersécurité : l’intégrer au cycle de delivery
Le CRA impose une « cybersecurity risk assessment » à intégrer dans la conception, le développement, la production, la livraison et la maintenance. Pour une agence, la difficulté est moins la méthode que la répétabilité : il faut un format léger mais systématique, compatible avec des cycles projet parfois courts.
Une approche efficace consiste à packager l’analyse de risque en trois niveaux : (1) cadrage (données, exposition, utilisateurs, dépendances), (2) modélisation des menaces (par exemple autour des parcours et API), (3) plan de traitement (mesures, tests, monitoring, exigences de support). Le livrable doit être versionné et mis à jour à chaque changement significatif.
Cette analyse doit aussi vivre après la mise en production : nouvelles menaces, nouvelles dépendances, changement de contexte client (ex. ajout de paiement, nouvelles intégrations) peuvent modifier le risque. En l’intégrant aux rituels (revues d’architecture, change management, post-mortems), l’agence prouve une maîtrise continue plutôt qu’un audit ponctuel.
5) Dépendances, supply chain et SBOM : la “due diligence” devient obligatoire
Le CRA souligne la nécessité d’une “due diligence” sur les composants tiers afin d’éviter qu’ils ne compromettent la cybersécurité du produit final. Pour une agence web, c’est souvent le point le plus sensible : frameworks, librairies, plugins, images Docker, services SaaS, et même snippets copiés deviennent des éléments de la chaîne d’approvisionnement.
L’Annexe I, Partie II rend la SBOM (software bill of materials) obligatoire : elle doit être dans un format couramment utilisé et lisible machine, et couvrir au minimum les dépendances de premier niveau. Cela implique d’outiller la génération (CI/CD), l’archivage par version livrée, et la capacité à répondre rapidement à la question : « quels clients utilisent la dépendance X en version Y ? »
Au-delà de la SBOM, mettez en place des règles : politiques de mise à jour, revue de dépendances “à risque”, inventaire des composants publiés par l’agence (packages internes), et critères d’acceptation (maintenance active, correctifs disponibles, réputation). Cette discipline aligne sécurité, qualité et capacité de support, tout en réduisant l’exposition aux vulnérabilités en cascade.
6) Processus de gestion des vulnérabilités et reporting : se préparer au SRP
À partir du 11/09/2026, le CRA encadre des délais de reporting : « early warning » sous 24h, notification sous 72h, puis rapport final sous 14 jours (vulnérabilités exploitées) ou sous 1 mois (incidents sévères). Une agence doit donc être capable de détecter, qualifier, décider et notifier rapidement, ce qui suppose des rôles clairs et une astreinte réaliste.
Le règlement prévoit une « Single Reporting Platform (SRP) » opérée/maintenue par l’ENISA, avec une architecture permettant des endpoints nationaux. L’ENISA a d’ailleurs lancé un appel d’offres pour l’implémentation de cette plateforme (réf. ENISA/2025/OP/0001) avec un budget maximal de 11 M€ sur 4 ans, signe que l’écosystème de notification est en cours de structuration.
Sur le plan pratique, préparez des playbooks : triage de vulnérabilité, preuve d’exploitation, évaluation de sévérité, communication client, et collecte des éléments nécessaires au reporting. La FAQ CRA (Commission services, 2025) rappelle qu’une « exploitable vulnerability » s’apprécie au cas par cas selon les conditions opérationnelles : cela renforce l’importance de documenter le contexte, l’exposition réelle et les hypothèses, pour justifier vos décisions.
7) Conformité, mise sur le marché, marquage CE : où l’agence intervient
Le CRA couvre la conformité et la mise sur le marché : procédure d’évaluation de conformité, déclaration UE de conformité, et marquage CE. Une agence web n’est pas toujours le “fabricant” au sens juridique, mais elle peut être un acteur clé : elle conçoit, assemble, intègre et maintient des composants qui conditionnent la conformité du produit final.
Il est utile de clarifier contractuellement qui porte quelle obligation : qui est responsable de l’évaluation de conformité, qui maintient la documentation technique, qui gère le support et les correctifs, qui assure le reporting, et qui répond aux demandes d’autorités ou de clients. Sans cette clarification, l’agence risque d’hériter d’obligations implicites sans moyens ni visibilité suffisants.
Enfin, le CRA impose aussi des informations à fournir à l’utilisateur, incluant la date de fin de période de support (mois et année), communiquée au moment de l’achat. Pour une agence, cela se traduit par des engagements de maintenance explicites, une politique de fin de vie (EOL), et une capacité de livrer des mises à jour de sécurité dans des délais compatibles avec les risques.
8) Anticiper les interactions : certification, DORA et évolution du cadre UE
Pour démontrer la conformité, la question de la certification peut devenir stratégique. ENISA a lancé (16/05/2025) une série de webinaires sur l’articulation entre EUCC (Common Criteria) et CRA, basée sur une étude de mapping : l’objectif est d’aider les acteurs à comprendre comment la certification peut soutenir une démarche de conformité.
En parallèle, le contexte réglementaire adjacent compte : ENISA rappelle que DORA est devenu applicable le 17/01/2025, ce qui concerne directement les entités financières. Une agence travaillant avec des acteurs bancaires/assurance/fintech peut voir des exigences de résilience et de supply chain remonter dans les cahiers des charges, même pour des composants qui ne semblent pas “réglementaires” à première vue.
Enfin, une tendance 2026 à surveiller est la proposition de révision de l’EU Cybersecurity Act visant à accélérer/simplifier la certification et renforcer l’approche “cyber-secure by design”. Pour une agence, cela signifie qu’il faut construire une stratégie adaptable : combiner exigences CRA (produit), attentes clients (secteur), et options de certification (preuve), sans multiplier inutilement les coûts de conformité.
Se préparer au CRA, pour une agence web, ce n’est pas seulement “ajouter de la sécurité” : c’est industrialiser une capacité de conception sécurisée, de maîtrise des dépendances, de support et de réaction rapide aux vulnérabilités. Les jalons (2026 pour le reporting, 2027 pour la pleine application) laissent le temps de construire, mais pas celui d’improviser.
La trajectoire la plus robuste consiste à démarrer par une cartographie des produits et composants concernés, puis à déployer un socle commun : standards secure by design/default, analyse de risque intégrée au delivery, SBOM et gouvernance supply chain, et playbooks de notification compatibles avec la SRP. En clarifiant aussi les responsabilités contractuelles et les engagements de support, l’agence se met en position de livrer des produits conformes , et surtout durables , dans un marché qui rend la cyber-résilience non négociable.