Le 11 septembre 2026, un premier volet du Cyber Resilience Act européen devient applicable : les fabricants de produits comportant des éléments numériques devront signaler sous 24 heures les vulnérabilités activement exploitées. Derrière ce calendrier réglementaire se cache une question très concrète pour les PME, les associations et les collectivités : qui maintient réellement vos logiciels, jusqu'à quelle date, et que se passe-t-il le jour où une faille est exploitée ?

Ce qui devient obligatoire le 11 septembre 2026

Le Cyber Resilience Act, ou règlement (UE) 2024/2847, est entré en vigueur le 10 décembre 2024. L'essentiel de ses obligations ne s'appliquera qu'au 11 décembre 2027, mais les obligations de signalement prévues à son article 14 s'appliquent, elles, dès le 11 septembre 2026. C'est la première échéance réellement contraignante du texte.

À partir de cette date, le fabricant d'un produit comportant des éléments numériques doit signaler deux choses : toute vulnérabilité activement exploitée affectant son produit, et tout incident grave ayant un impact sur la sécurité de ce produit. Le calendrier est serré :

  • une alerte précoce dans les 24 heures suivant la prise de connaissance ;
  • une notification complète dans les 72 heures ;
  • un rapport final au plus tard 14 jours après la mise à disposition d'une mesure corrective pour une vulnérabilité exploitée, ou dans un délai d'un mois pour un incident grave.

Le signalement passe par la plateforme unique mise en place par l'ENISA, avec transmission au CSIRT de l'État membre où le fabricant a son établissement principal. Un point est souvent négligé : ces obligations couvrent aussi les produits déjà mis à disposition sur le marché avant le 11 décembre 2027. Une application publiée il y a quatre ans est concernée au même titre qu'une nouveauté.

Êtes-vous « fabricant » au sens du règlement ?

C'est la première question à trancher, et la réponse est plus rassurante que ne le laissent penser les titres alarmistes. La Commission européenne l'écrit noir sur blanc : les produits qui ne sont pas mis à disposition sur le marché, c'est-à-dire qui ne sont pas fournis dans le cadre d'une activité commerciale, ne relèvent pas du CRA.

Concrètement, une application métier développée pour votre usage interne (suivi des interventions, portail RH, tableau de bord de production) et qui n'est ni vendue ni distribuée n'entre pas dans le périmètre du règlement. Vous restez responsable de sa sécurité, mais vous n'êtes pas soumis aux obligations du fabricant.

À l'inverse, vous devenez fabricant si vous mettez un logiciel à disposition sous votre nom ou votre marque, y compris gratuitement : un module que vous commercialisez, une application mobile publiée sur un store pour vos clients, un équipement connecté que vous vendez, ou un service distant sans lequel votre produit ne remplirait plus l'une de ses fonctions. Le cas du mode service reste discuté : un SaaS totalement autonome relève plutôt de la directive NIS2, alors qu'un traitement de données à distance nécessaire au fonctionnement d'un produit est traité comme une partie de ce produit. En cas de doute, faites qualifier votre situation par un conseil juridique spécialisé.

La période de support devient une information contractuelle

Au-delà du signalement, le CRA introduit une notion qui va durablement changer les achats de logiciel : la période de support. Le fabricant doit la déterminer, s'engager à traiter effectivement les vulnérabilités pendant toute sa durée, et en indiquer clairement la date de fin, mois et année compris, au moment de l'achat.

Pour un acheteur, c'est un changement de culture : on cesse d'acheter implicitement un logiciel « à vie » pour acheter un produit dont la fin de maintenance de sécurité est datée, comme une garantie. La question à poser à chaque fournisseur devient simple : jusqu'à quelle date recevrai-je des correctifs de sécurité, et à quelles conditions ?

Cette question fait vite apparaître une réalité technique : la durée de support d'une application dépend surtout de celle de ses briques. Deux repères vérifiables pour 2026 : Node.js 20 est sorti du support le 30 avril 2026, et PHP 8.2 atteint sa fin de vie le 31 décembre 2026. Une application posée sur ces socles n'a aucune période de support crédible au-delà, quelle que soit la qualité du contrat de maintenance. C'est d'ailleurs le meilleur argument pour arbitrer une montée de version ou une modernisation avant qu'elle ne devienne une urgence.

Quatre chantiers utiles, même si vous n'êtes pas fabricant

  1. L'inventaire des composants. Le règlement impose aux fabricants d'identifier et de documenter les composants de leurs produits, sous la forme d'une nomenclature logicielle exploitable par machine. Sans cet inventaire, personne ne sait répondre en 24 heures à la seule question qui compte le jour d'une faille : sommes-nous touchés, et où ?
  2. Un point de contact pour la divulgation. Une adresse dédiée, publiée, relevée, et une politique simple indiquant comment un chercheur ou un client peut vous signaler une vulnérabilité. Beaucoup d'organisations découvrent leurs failles par un message perdu dans un formulaire générique.
  3. Une chaîne d'alerte qui tient debout. Qui qualifie, qui décide, qui notifie, et que se passe-t-il un vendredi soir ou un 14 août ? Un délai de 24 heures ne se tient pas sans astreinte ni procédure écrite, même très courte.
  4. Vos clauses contractuelles. Durée de support, délai de correction selon la criticité, obligation d'information sur les vulnérabilités connues, réversibilité et accès au code source. Ces clauses coûtent peu à la signature et beaucoup après coup.

Ce que cela change dans vos consultations et vos achats

Si vous lancez une consultation pour un logiciel, une application mobile ou un objet connecté, trois questions méritent désormais d'y figurer explicitement : la date de fin de la période de support, la procédure de signalement des vulnérabilités du fournisseur, et les versions des socles techniques utilisés avec leurs propres échéances de fin de vie. Un fournisseur incapable d'y répondre en 2026 vous renseigne déjà sur la maintenance que vous obtiendrez en 2029.

Côté sanctions, le règlement prévoit des amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial pour les manquements aux obligations essentielles, les montants étant fixés au niveau national. Un aménagement existe pour les plus petites structures : les micro et petites entreprises ne peuvent pas être sanctionnées pour le seul dépassement du délai de 24 heures.

Notre lecture

Le CRA ne transforme pas une PME en éditeur de logiciel. Il rend visible et opposable ce que le secteur pratiquait de façon très inégale : la maintenance de sécurité a une durée, un coût et un responsable identifié. Pour s'y préparer sans y passer un trimestre, classez vos applications en trois familles : celles qui sont hors périmètre mais critiques pour votre activité, celles que vous mettez à disposition de tiers et qui demandent un vrai chantier de conformité avant décembre 2027, et celles de vos fournisseurs, où tout se joue dans le contrat.

Questions fréquentes

Mon application métier interne est-elle concernée par le Cyber Resilience Act ?

Non, si elle n'est pas mise à disposition sur le marché dans le cadre d'une activité commerciale. La Commission européenne précise que les produits non fournis sur le marché ne relèvent pas du CRA. Vous restez toutefois responsable de sa sécurité et de sa maintenance.

Que faut-il signaler à partir du 11 septembre 2026 ?

Les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leur produit, avec une alerte précoce sous 24 heures, une notification complète sous 72 heures et un rapport final ensuite.

Qu'est-ce que la période de support imposée par le règlement ?

C'est la durée pendant laquelle le fabricant s'engage à traiter effectivement les vulnérabilités de son produit. Sa date de fin, mois et année, doit être indiquée clairement à l'acheteur au moment de l'achat.

Les logiciels déjà installés avant 2027 sont-ils concernés ?

Oui pour les obligations de signalement : elles s'appliquent à tous les produits mis à disposition sur le marché de l'Union, y compris ceux commercialisés avant le 11 décembre 2027.

Par où commencer si nous vendons une application à nos clients ?

Par l'inventaire des composants et de leurs versions, puis par un point de contact de divulgation et une procédure d'alerte écrite.

Vous vous demandez si vos applications entrent dans le périmètre, ou jusqu'à quelle date leurs socles techniques resteront maintenables ? Nous réalisons cet état des lieux avec vous, sans jargon et avec des échéances datées. Parlons de votre projet.