Depuis le 11 septembre 2026, une nouvelle obligation européenne est entrée en application : le signalement, sous 24 heures, des vulnérabilités activement exploitées sur les logiciels et produits connectés commercialisés dans l'Union. C'est la première échéance concrète du Cyber Resilience Act (règlement européen 2024/2847), un texte qui va redéfinir la manière dont les logiciels doivent être conçus, maintenus et documentés. Pour les éditeurs de SaaS, les e-commerçants équipés de modules sur mesure ou les PME dotées d'un ERP, c'est le moment de comprendre ce qui arrive avant que les échéances suivantes ne tombent.

Le Cyber Resilience Act, en clair

Le CRA impose aux "produits comportant des éléments numériques" — logiciels, plugins, modules, objets connectés — des exigences de sécurité dès la conception ("security by design") et pendant toute leur durée de vie commerciale : gestion documentée des vulnérabilités, mises à jour de sécurité, information claire de l'utilisateur. Le texte vise en priorité les logiciels et composants mis sur le marché comme produits : un plugin WooCommerce vendu, un module métier distribué, une application packagée. Les SaaS purs, proposés uniquement comme service en ligne, bénéficient d'un régime plus nuancé, mais dès qu'un service cloud s'appuie sur un composant logiciel distribué ou qu'il traite des données à caractère critique pour le fonctionnement d'un produit, la vigilance reste de mise.

Les échéances à retenir

  • 11 septembre 2026 : obligation de signalement des incidents de sécurité et des vulnérabilités activement exploitées, déjà en vigueur.
  • 11 décembre 2027 : application pleine et entière des exigences de conformité (marquage CE, documentation technique, obligations de maintenance sécuritaire).

Entre ces deux dates, la marge de manœuvre se réduit chaque mois. Attendre la dernière ligne droite pour auditer son code, ses dépendances et ses process de mise à jour revient à s'exposer à des refontes dans l'urgence, plus coûteuses et plus risquées qu'une mise en conformité progressive.

Ce que "sécurité by design" implique concrètement

Un inventaire réel de vos dépendances

Impossible de corriger une vulnérabilité dans une bibliothèque tierce si personne ne sait qu'elle est utilisée. Un inventaire des composants (SBOM) devient la base de toute démarche sérieuse, qu'il s'agisse d'un logiciel SaaS construit sur un framework moderne ou d'un module Dolibarr développé sur mesure.

Un processus de correction, pas seulement un correctif

Le règlement attend un vrai processus : détection, qualification, correction, notification. Cela suppose des environnements de test fiables et une chaîne de déploiement maîtrisée, du type de celle utilisée pour livrer sans casser la production.

Une maintenance planifiée, pas subie

Un logiciel laissé à l'abandon pendant deux ans, qu'il s'agisse d'un plugin WooCommerce ou d'une application interne, est le profil type du risque que le CRA cherche à éliminer. La maintenance régulière cesse d'être une option de confort pour devenir une exigence réglementaire.

Pourquoi les PME et éditeurs de niche sont concernés

Contrairement à une idée reçue, la taille de l'entreprise ne dispense pas de l'essentiel des obligations : le CRA cible le produit mis sur le marché, pas le chiffre d'affaires de celui qui le commercialise. Une TPE qui vend un module métier ou un plugin à d'autres entreprises est donc concernée au même titre qu'un grand éditeur, avec moins de ressources internes pour absorber le changement. C'est précisément dans ces cas que l'accompagnement par un prestataire technique habitué aux audits de code et à la automatisation des tâches de supervision fait la différence.

Se préparer sans tout refondre

La mise en conformité ne signifie pas repartir de zéro. Elle commence par un état des lieux : quels logiciels sont concernés, quelles dépendances posent problème, quel est le niveau actuel de suivi des mises à jour. Sur cette base, les actions prioritaires peuvent être hiérarchisées : sécurisation des accès, mise à jour des bibliothèques obsolètes, mise en place d'un canal de signalement des failles, documentation technique minimale. Pour les projets développés sans suivi structuré, repartir d'un développement web sur mesure audité est souvent plus rentable qu'une accumulation de correctifs ponctuels.

Passer à l'action

Le CRA ne tombera pas d'un coup en 2027 : il s'applique déjà partiellement, et les entreprises qui commencent dès maintenant à documenter leurs logiciels et à planifier leur maintenance aborderont les prochaines échéances sereinement. Un audit technique de vos applications, SaaS ou modules métier permet d'identifier concrètement ce qui doit évoluer, et dans quel ordre. Nos équipes peuvent réaliser cet état des lieux avec vous : contactez-nous pour en discuter.

Questions fréquentes

Oui si vous développez, vendez ou distribuez un logiciel, un plugin ou un module considéré comme un produit mis sur le marché européen. Le règlement s'applique au produit, pas à la taille de l'entreprise qui le commercialise, même si des mesures d'accompagnement existent pour les plus petites structures.

Les services SaaS purs bénéficient d'un traitement plus nuancé que les logiciels packagés, mais dès qu'un composant logiciel distribuable ou un module tiers entre dans votre chaîne technique, la vigilance reste nécessaire. Un audit au cas par cas de votre architecture est le meilleur moyen de clarifier votre situation.

Par un inventaire de vos dépendances logicielles et un état des lieux de votre processus de mise à jour et de gestion des failles. C'est cette cartographie qui permet ensuite de prioriser les corrections les plus urgentes avant les échéances de 2027.