Le 11 septembre 2026 est passé, mais pour beaucoup d'éditeurs de logiciels et de SaaS français, l'échéance vient à peine d'être comprise. Ce jour-là, le Cyber Resilience Act (règlement européen 2024/2847) est entré dans sa première phase contraignante : l'obligation de signaler certaines failles de sécurité dans des délais très courts. Une nouvelle étape arrive ensuite en décembre 2027, avec cette fois l'ensemble des exigences de sécurité applicables. Pour une PME qui développe une application métier, un SaaS ou un module vendu à des clients, ce n'est plus un sujet de veille juridique : c'est un chantier technique à préparer dès maintenant.

Ce qui change concrètement depuis septembre

Ce 11 septembre 2026, l'article 14 du Cyber Resilience Act entre en application. Ce règlement impose désormais aux fabricants de produits et solutions comportant des éléments numériques de signaler les vulnérabilités activement exploitées et les incidents graves affectant leur sécurité dans les 24 h. Puis, une autre notification plus détaillée devra être émise dans les 72 h. Ces signalements passent par une plateforme centralisée : les fabricants devront alors signaler certaines vulnérabilités activement exploitées ainsi que des incidents de sécurité via la plateforme européenne de notification opérée par l'Agence de l'Union européenne pour la cybersécurité, l'Enisa.

Beaucoup de dirigeants pensent que ce texte ne concerne que les grands éditeurs. C'est une erreur coûteuse : le texte ne prévoit aucun seuil d'exonération, les obligations s'appliquent aussi bien aux grands groupes qu'aux start-up et PME. Un cabinet spécialisé le formule sans détour : contrairement à NIS2, il n'y a pas de seuil de taille, une PME de 5 personnes qui édite un logiciel distribué est dans le périmètre. Autrement dit, si vous éditez un SaaS, un plugin ou une application vendue à des clients externes, vous êtes probablement concerné, même à petite échelle.

Sécurité dès la conception : le vrai changement de logique

Le CRA ne se limite pas à une obligation de signalement. Il change la manière dont un logiciel doit être pensé et maintenu : tout matériel ou logiciel comportant des éléments numériques mis sur le marché européen devra être conçu, développé et maintenu selon des exigences de cybersécurité vérifiables, avec marquage CE à la clé, et la sécurité du produit devient une condition d'accès au marché, au même titre que la sécurité électrique d'un appareil. Concrètement, cela implique de documenter ses choix techniques, de suivre ses dépendances open source et de savoir réagir vite en cas de faille découverte dans une librairie tierce.

Sur le plan opérationnel, les éditeurs concernés doivent structurer trois briques avant toute mise en conformité complète : les PME éditrices doivent établir un contact de sécurité, un circuit de tri et une nomenclature logicielle (SBOM) avant cette échéance. Le SBOM (Software Bill of Materials) est l'inventaire précis de tous les composants et dépendances utilisés dans une application : sans lui, impossible de savoir rapidement si une vulnérabilité découverte dans une librairie tierce vous concerne. C'est un exercice que l'on retrouve dans les projets de développement SaaS bien architecturés, où la traçabilité des dépendances fait partie intégrante du cycle de vie du produit.

Un cadre encore mouvant, mais des repères officiels

Consciente que beaucoup de petites structures découvrent le sujet tardivement, la Commission européenne a publié fin juillet 2026 un premier guide pratique : la Commission européenne a publié une nouvelle ligne directrice pour accompagner une mise en œuvre dans les temps du Cyber Resilience Act, qui clarifie le périmètre des produits concernés, les modifications substantielles, les périodes de support et les obligations de signalement, avec 67 exemples pratiques, cas d'usage, diagrammes et arbres de décision. Ce document est une bonne base pour cadrer un premier diagnostic, avant de faire intervenir un prestataire ou un juriste spécialisé si votre produit entre dans une catégorie à risque plus élevée.

Les sanctions ne sont pas symboliques : les amendes peuvent atteindre 2,5 % du chiffre d'affaires mondial pour non-conformité aux exigences essentielles ou obligations de fabricant. Un montant qui justifie de traiter le sujet en amont plutôt qu'en réaction à un incident.

Par où commencer quand on développe ou fait développer son logiciel

Pour une PME qui édite ou fait éditer un logiciel, quelques chantiers concrets permettent d'avancer sans tout bloquer :

  • Cartographier les dépendances de votre application (librairies, frameworks, API tierces) pour amorcer un SBOM, même simplifié.
  • Désigner un point de contact sécurité interne ou chez votre prestataire, capable de faire remonter une alerte en quelques heures.
  • Revoir les processus de mise à jour : un correctif de sécurité doit pouvoir être déployé rapidement, ce qui suppose une architecture propre et des tests automatisés fiables.
  • Documenter les choix d'hébergement et d'authentification, en particulier pour les applications en mode SaaS ou les applications développées sur mesure exposées sur internet.

C'est aussi l'occasion de revoir des projets anciens dont la maintenance a été négligée. Un développement web sur mesure conçu il y a plusieurs années sans documentation ni suivi des dépendances sera plus coûteux à mettre en conformité qu'une application maintenue en continu. De la même manière, certaines tâches de veille et de remontée d'alertes peuvent être en partie prises en charge par de l'automatisation des tâches : surveillance des versions de dépendances, alertes automatiques en cas de faille publiée, journalisation centralisée des incidents.

En résumé

Le Cyber Resilience Act ne va pas disparaître d'ici décembre 2027 : ses obligations vont au contraire se durcir. Plutôt que d'attendre la prochaine échéance, il est plus sûr de profiter des prochains mois pour auditer son logiciel, structurer sa nomenclature de dépendances et clarifier qui, dans votre organisation ou chez votre prestataire, portera la responsabilité du signalement. Découvrez nos expertises développement ou contactez-nous pour évaluer où en est votre application sur ces sujets de sécurité et de conformité.

Questions fréquentes

Le règlement vise avant tout les produits numériques mis sur le marché européen, c'est-à-dire vendus, distribués ou fournis à des tiers. Un outil strictement interne, non commercialisé, est en principe hors du périmètre direct du CRA, mais il reste soumis aux exigences de sécurité du RGPD. Dès qu'un logiciel ou un module est vendu, mis à disposition de clients ou distribué même gratuitement, la question doit être posée sérieusement.

Un SBOM (Software Bill of Materials) est la liste détaillée de tous les composants, librairies et dépendances utilisés dans une application. Il permet de savoir rapidement si une vulnérabilité annoncée sur une librairie tierce touche votre produit, plutôt que de devoir l'auditer en urgence. C'est un prérequis de plus en plus attendu dans le cadre du Cyber Resilience Act, et une bonne pratique de développement en général.

Les sanctions prévues par le règlement peuvent aller jusqu'à un pourcentage significatif du chiffre d'affaires mondial en cas de non-conformité aux exigences essentielles, en plus de possibles restrictions de commercialisation. Au-delà de l'aspect financier, l'absence de processus clair de gestion des vulnérabilités expose surtout à une réaction lente et mal maîtrisée en cas d'incident réel.