Le Cyber Resilience Act ou la fin du logiciel livré puis oublié

Le CRA fait de la cybersécurité une responsabilité continue : les entreprises doivent sécuriser leurs produits tout au long de leur vie et démontrer leur capacité à gérer les risques.

La cybersécurité a longtemps été traitée comme un sujet essentiellement technique. Un sujet de DSI, de RSSI, parfois de développeurs. Le produit était conçu, mis sur le marché, puis maintenu au gré des mises à jour et des correctifs.

Le Cyber Resilience Act (CRA) dynamite cette logique. Raisonner ainsi est désormais obsolète.

On présente souvent ce texte comme un nouveau règlement européen de cybersécurité imposant des exigences supplémentaires aux fabricants de logiciels, d'objets connectés ou d'équipements numériques. C'est vrai. Mais en partie seulement, et se cantonner à cette lecture passe à côté de l'essentiel.

Le CRA ne modifie pas seulement ce que les entreprises doivent faire. Il modifie ce dont elles deviennent responsables.

Jusqu'à présent, la conformité était principalement pensée comme une condition d'accès au marché. Avec le CRA, elle devient une exigence qui accompagne le produit tout au long de son cycle de vie. Le fabricant doit non seulement démontrer que son produit satisfait à certaines exigences de cybersécurité, mais aussi qu'il est capable d'identifier les vulnérabilités qui apparaissent après sa commercialisation, d'y remédier, de suivre leur traitement et, selon l’hypothèse considérée, de les notifier aux autorités compétentes.

L’évolution peut sembler évidente. Après tout, quel éditeur sérieux attendrait aujourd'hui qu'une faille de sécurité soit exploitée pour s'en préoccuper ?

Pourtant, le changement est loin d'être anodin. Car le sujet porte autant sur l'existence de processus de sécurité que sur la capacité à les démontrer. Le CRA n'interroge pas seulement les pratiques de développement. Il interroge la gouvernance du produit. Qui détecte les vulnérabilités ? Qui les qualifie ? Qui décide d'une notification ? Qui conserve la traçabilité des correctifs déployés ? Qui peut démontrer, plusieurs mois plus tard, ce qui a été fait et pourquoi ?

C'est souvent à cet endroit que les difficultés apparaissent.

Dans de nombreuses organisations, le produit, la cybersécurité, la conformité et le juridique continuent à fonctionner selon des logiques distinctes. Chacun maîtrise son périmètre. Chacun dispose de ses outils, de ses procédures et de ses indicateurs. Le CRA oblige au contraire à regarder le produit comme un objet unique dont la sécurité devient une dimension structurante, au même titre que sa performance ou sa qualité.

Les nouvelles obligations de notification illustrent parfaitement cette réalité. Lorsqu'une vulnérabilité activement exploitée ou un incident grave est découvert, la question n'est pas uniquement de savoir s'il faut effectuer une déclaration au titre du CRA. Le même événement peut également soulever des problématiques relevant du RGPD, de NIS2, de DORA ou encore d'obligations contractuelles vis-à-vis des clients. Le risque n'est alors plus seulement cyber. Il devient organisationnel.

À force d'accumuler les dispositifs de signalement, les entreprises peuvent être tentées de construire autant de procédures qu'il existe de réglementations. Ce serait probablement une erreur. La véritable difficulté n'est pas la notification elle-même. Elle réside dans la capacité à qualifier rapidement un incident, à partager une même analyse entre les différentes fonctions concernées et à garantir la cohérence des informations communiquées aux diverses parties prenantes. C'est d'ailleurs peut-être là que se situe l'apport le plus intéressant du CRA.

Contrairement à certaines idées reçues, le texte ne cherche pas à imposer un produit parfait ni à éliminer tout risque de vulnérabilité. Aucun régulateur ne peut sérieusement poursuivre un tel objectif. En revanche, il exige que les entreprises soient en mesure de démontrer qu'elles maîtrisent leurs processus de gestion des risques et qu'elles sont capables d'apporter une réponse structurée lorsqu'un incident survient.

En cela, le CRA dit quelque chose de plus large sur l'évolution du droit du numérique européen. Les régulateurs ne s'intéressent plus uniquement aux résultats. Ils s'intéressent de plus en plus à l'organisation qui produit ces résultats. Ils cherchent moins à vérifier qu'un produit est conforme à un instant donné qu'à s'assurer qu'il existe, derrière ce produit, une capacité durable à gérer les risques qu'il génère.

Pour les fabricants, les éditeurs et plus largement tous les acteurs du numérique, le véritable enjeu n'est donc probablement pas de se conformer à un texte supplémentaire. Il consiste à intégrer une nouvelle réalité : dans une économie de logiciels, de services connectés et de mises à jour permanentes, la sécurité ne s'arrête plus au lancement du produit. Elle devient une responsabilité continue.

Le CRA étend aux produits comportant des éléments numériques la logique qui présida au développement de la responsabilité du fait de produits défectueux il y a plus de 40 ans. De la société de consommation de produits à une société de consommation de produits numériques…