Pendant des années, la question de la cybersécurité a toujours été posée à l’organisation :
« Les mesures de sécurité sont-elles suffisantes ?
La loi sur la cyber-résilience (CRA) élargit le champ d’action. Désormais, la question porte également sur le produit :
« Le logiciel ou le dispositif que nous développons, distribuons ou commercialisons a-t-il été conçu pour être sécurisé et le restera-t-il tout au long de sa durée de vie ?
Il ne s’agit pas d’une nuance mineure. Il s’agit d’un changement de paradigme qui affecte les fabricants, les développeurs, les distributeurs et les fournisseurs de technologie dans toute l’Europe.
Qu’est-ce que l’ARC ?
La loi sur la cyber-résilience est un règlement européen qui établit des exigences obligatoires en matière de cybersécurité pour tout produit contenant des éléments numériques et commercialisé dans l’Union européenne.
Leur logique est claire : trop de produits arrivent sur le marché avec des vulnérabilités connues, sans mises à jour planifiées et sans processus formel de gestion des incidents. L’ARC veut changer cela.
À cette fin, elle introduit des concepts qui étaient jusqu’à présent des recommandations ou des bonnes pratiques et les convertit en obligations :
- Sécurité dès la conception : la sécurité n’est pas ajoutée à la fin, elle est planifiée dès le début.
- Sécurité par défaut : la configuration initiale doit être sécurisée, sans que l’utilisateur n’ait à faire quoi que ce soit.
- Gestion continue des vulnérabilités : identifier, hiérarchiser, remédier et documenter tout au long du cycle de vie du produit.
- Obligations de notification : si vous détectez une vulnérabilité activement exploitée, vous disposez de 24 heures pour émettre une alerte rapide.
- Transparence en matière d’assistance : vous devez indiquer clairement pendant combien de temps le produit recevra des mises à jour de sécurité.
Il ne s’agit pas de réussir un audit ponctuel. L’ARC fait de la sécurité un processus vivant et démontrable.
Qui est concerné : plus qu’il n’y paraît
C’est là que de nombreuses organisations sont surprises. L’ARC n’affecte pas seulement les fabricants de matériel ou les grandes plateformes. Elle affecte :
- Logiciels d’entreprise et applications SaaS
- Dispositifs IoT et matériel connecté
- Applications mobiles
- Plateformes en nuage
- Systèmes industriels connectés
Cela s’applique non seulement aux développeurs, mais aussi à ceux qui distribuent ou importent des produits numériques en Europe.
Si votre entreprise développe des logiciels, vend des licences, offre des services en tant que SaaS ou intègre des produits tiers dans vos solutions, l’ARC s’applique probablement à vous.
Le calendrier : moins de temps qu’il n’y paraît
La mise en œuvre complète du règlement est prévue pour décembre 2027, mais il y a une date antérieure qu’il ne faut pas perdre de vue :
11 septembre 2026 – Entrée en vigueur des obligations de déclaration des vulnérabilités activement exploitées et des incidents graves.
Et ce, en un peu plus d’un an. Et la préparation de processus de notification robustes fonctionnant dans les 24 heures n’est pas quelque chose qui se met en place en quelques semaines.
Les trois implications les plus marquantes de la vie quotidienne
1) Développer un logiciel ne suffit plus : il faut le prouver.
L’ARC ne demande pas si votre produit est sûr. Elle vous demande de prouver qu’il l’est. Cela signifie que vous disposez d’une documentation technique, de journaux de vulnérabilité, d’un historique des mises à jour, de processus formalisés de réponse aux incidents… et que vous êtes en mesure de les présenter à un régulateur ou à un client à n’importe quel moment.
2. La chaîne d’approvisionnement devient sa propre responsabilité
Une vulnérabilité peut apparaître par le biais d’une bibliothèque open source, d’une API tierce, d’un composant SaaS intégré ou d’un fournisseur tiers. L’ARC étend la responsabilité au-delà de votre propre code. Si votre produit intègre des composants tiers, vous devez savoir quel risque chacun d’entre eux représente.
3. Les temps de réponse sont considérablement réduits.
24 heures pour émettre une alerte rapide sur une vulnérabilité activement exploitée. Si votre processus de gestion des incidents repose sur des courriels, des appels et des feuilles de calcul, ce délai peut devenir impossible à respecter.
Quelles sont les capacités dont vous devez disposer (ou que vous devez développer) ?
L’ARC ne prescrit pas d’outils spécifiques, mais précise les processus à mettre en place. D’après notre expérience de travail avec des organisations technologiques, il s’agit là des éléments de base :
Gestion des risques et des actifs Inventaire actualisé des produits et des composants, identification des menaces, évaluation de l’impact et surveillance des risques résiduels. Sans cela, vous ne pouvez pas savoir quelles vulnérabilités vous affectent et avec quelle urgence. –> Risk Manager
Gestion de la chaîne d’approvisionnement Approbation des fournisseurs, évaluations régulières, questionnaires de sécurité, preuves documentées. Un fournisseur non évalué est un risque non mesuré. –> Gestionnaire des tiers
Gestion des vulnérabilités Identification, hiérarchisation, remédiation et tenue d’un historique vérifiable. L’autorité de régulation peut demander un tel historique. –> Gestionnaire d’incidents
Gestion des incidents Enregistrement, classification, attribution des responsabilités, plans d’intervention et traçabilité. Il ne s’agit pas d’un document rangé dans un tiroir, mais d’un processus actif fonctionnant sous pression. –> Gestionnaire d’incidents
Documentation technique et politiques Politiques, procédures, enregistrements, acceptations, preuves. La documentation n’est pas de la bureaucratie : c’est la preuve que vous faites les choses correctement. –> Policy Manager.
Communiquer la sécurité aux clients De plus en plus de clients demandent comment vous gérez la sécurité avant de signer un contrat. Une réponse claire, centralisée et actualisée – certifications, politiques, preuves – peut faire toute la différence dans un processus commercial. –> Trust Center
L’ARC n’est pas seulement un coût de mise en conformité
Vu de l’extérieur, l’ARC peut sembler n’être qu’un fardeau réglementaire de plus. Mais il y a une autre façon de la lire.
Les organisations capables de démontrer qu’elles gèrent la sécurité des produits de manière rigoureuse – avec des processus documentés, des temps de réponse rapides et une transparence vis-à-vis de leurs clients – auront un réel avantage sur leurs concurrents qui continuent à s’appuyer sur des processus informels.
Sur un marché où la confiance numérique est de plus en plus un critère d’achat, la conformité à l’ARC peut devenir un argument commercial.
La question n’est pas seulement de savoir si vous vous conformerez à l’ARC. Il s’agit de savoir si vous serez en mesure de le démontrer efficacement lorsque quelqu’un vous le demandera.
Chez ithikios, nous avons développé différents modules pour vous aider à vous conformer à l’ARC et à démontrer votre conformité avec le Trust Center, l’Incident Manager, le Third Party Manager, le Risk Manager et le Policy Manager.
