Le Cyber Resilience Act n'a pas une date : il en a quatre, et une seule s'ouvre le 11 septembre

Le Cyber Resilience Act est en vigueur depuis décembre 2024.

Il n'oblige pourtant presque personne à quoi que ce soit avant le 11 décembre 2027.

Ces deux phrases sont vraies en même temps, et c'est précisément ce qui rend le sujet illisible. On lit « en vigueur » et on croit devoir agir. On lit « 2027 » et on range le dossier. Entre les deux, une seule obligation s'ouvre le 11 septembre 2026 — et ce n'est aucune de celles auxquelles on pense.

Nous avons fait le tri pour nos propres produits. Voici le résultat, date par date, avec les passages du texte officiel qui les portent.

Ce que dit l'article qui commande tout le calendrier

Le règlement fixe sa propre application à son article 71. Il pose une règle générale, puis deux exceptions, dans la même phrase :

« Toutefois, l'article 14 est applicable à partir du 11 septembre 2026 et le chapitre IV (articles 35 à 51) à partir du 11 juin 2026. »

Et la règle générale, juste avant : le règlement « est applicable à partir du 11 décembre 2027 ».

Trois dates dans deux phrases. Une quatrième les précède — l'entrée en vigueur de décembre 2024, qui ne déclenche aucune obligation pour un fabricant. Ce qui donne le tableau suivant.

« La deadline CRA » n'existe pas. Il y a quatre dates, chacune rattachée à son article, et elles ne concernent pas les mêmes personnes.

Ce qui n'est PAS dû le 11 septembre

C'est la partie que l'on nous a le plus souvent demandé de vérifier, alors autant l'écrire en clair. Les obligations suivantes relèvent de l'article 13, donc du 11 décembre 2027 :

• le marquage CE et la déclaration de conformité ;
• la documentation technique et l'évaluation de conformité ;
• la période de support — au moins cinq ans sauf durée d'usage attendue plus courte, et son affichage au moment de l'achat.

Rien de tout cela ne bloque une mise en ligne aujourd'hui. Le seul régime qui s'ouvre le 11 septembre 2026 est celui du signalement.

Nous insistons parce que la confusion la plus fréquente porte sur la nomenclature logicielle — le SBOM. Elle relève de l'annexe I, donc de décembre 2027. Quinze mois séparent le signalement de la nomenclature. Les confondre, c'est se préparer quinze mois trop tôt à une obligation, et rater celle qui arrive dans cinq semaines.

Deux effets de calendrier qui surprennent

La guidance publiée par la Commission le 27 juillet 2026 — 84 pages, écrite explicitement pour répondre aux questions des entreprises, avec une attention affichée aux micro-entreprises et aux PME — en établit deux, à son point 210.

Premier effet : sortir avant ne dispense pas de signaler. L'obligation du 11 septembre 2026 s'applique à tout produit en périmètre, « including products with digital elements placed on the market before 11 December 2027 ». Un logiciel publié en 2025 y est soumis comme un logiciel publié demain.

Second effet, en sens inverse : un produit mis sur le marché avant le 11 décembre 2027 n'est pas tenu aux obligations de traitement des vulnérabilités de l'annexe I, partie II. Le texte est explicite — « the manufacturer is not required to comply ».

Nous signalons ce second point parce qu'il est vrai, et nous ajoutons immédiatement ce qu'il ne doit pas devenir : une stratégie de calendrier. Décider d'une date de sortie pour se placer du bon côté d'une échéance serait une décision, pas un effet de bord — et elle mériterait d'être écrite et assumée comme telle.

Troisième point du même paragraphe, moins commenté : l'obligation de signalement survit à la fin du support. Un produit qu'on ne maintient plus reste un produit dont on signale les exploitations.

Sommes-nous concernés ? Le raisonnement, pas la conclusion

Le CRA vise un « produit avec éléments numériques » mis à disposition sur le marché de l'Union dans le cadre d'une activité commerciale — que ce soit à titre onéreux ou gratuit. La gratuité n'exonère pas.

La guidance tranche le cas du logiciel à son point 20 : un logiciel « téléchargé, installé ou autrement fourni à l'utilisateur et qui s'exécute sur son système » est dans le périmètre. Son exemple 4 est littéral :

« a desktop application built using web technologies but packaged for local installation is supplied to the user and executes on the user's device, and is therefore a product with digital elements »

À l'inverse, un site ou une application accessibles uniquement par navigateur n'en sont pas — sauf s'ils supportent une fonctionnalité d'un produit installable, auquel cas ils rentrent par la porte du traitement de données à distance.

Dernier point, et il compte pour beaucoup de nos lecteurs : le fabricant peut être une personne physique. La forme auto-entrepreneur n'écarte rien.

Appliqué à nous, sans arrondi : notre application de bureau tombe sous l'exemple 4, littéralement. Notre annuaire en ligne n'est pas concerné — le point 194 pose qu'« il ne suffit pas qu'un site web contienne des informations sur un produit » pour entrer dans le périmètre.

Notre espace client, lui, a demandé un véritable arbitrage. Il est accessible par navigateur, donc hors périmètre en soi. Mais il émet le jeton de licence sans lequel l'application ne démarre pas, et il lui distribue ses mises à jour de règles. Le point 194 vise exactement cette situation :

« a website may be within the scope of RDPS if it enables or supports a function of a product with digital elements. For example, an authentication portal that issues credentials or tokens required for the product with digital elements to operate would be considered RDPS »

Nous avons donc tranché : oui, mais pour un périmètre restreint et nommable — les routes qui délivrent la licence et celles qui distribuent les règles. Deux familles d'appels, pas davantage. Le reste de l'espace client — les rapports archivés, la facturation — n'en fait pas partie, parce que l'application n'interagit pas directement avec lui. Le point 205 l'écrit ainsi : le périmètre doit être « limité aux modules logiciels responsables de la fonctionnalité du produit », et les systèmes situés plus en arrière « ne sont pas considérés » comme en relevant.

Ce découpage n'est pas une subtilité de rédaction. Déclarer « tout l'espace client » aurait été plus rapide à écrire — et faux, dans le sens qui nous aurait coûté le plus cher : celui qui gonfle un périmètre pour avoir l'air prudent. Le texte demande l'inverse. Le mode hors ligne n'y change rien non plus : le point 191 précise que pouvoir exécuter une fonction manuellement « n'exclut pas la qualification » du traitement distant correspondant.

Une réserve, parce qu'elle est réelle : cette liste vaut pour les appels réseau que notre application passe aujourd'hui. Elle doit être revérifiée à chaque appel ajouté, et non supposée stable.

Le geste qui ne se rattrape pas

Le CRA raisonne produit par produit, et tout part d'une date. La guidance situe la mise sur le marché d'un logiciel autonome « au moment de la première offre de distribution ou d'usage », et considère que toutes les copies sont mises sur le marché en même temps.

Cette date décide du régime applicable, du point de départ de la période de support, et de ce qu'on pourra prouver en cas de contrôle.

Une date reconstruite après coup n'est pas une preuve, c'est un souvenir.

C'est le seul geste de tout ce dossier qui ne se rattrape pas : il se pose le jour de la publication, ou il est perdu. Nous tenons pour nos propres produits un registre qui consigne, à chaque mise à disposition, le produit, la variante, la version, l'empreinte du binaire réellement servi, l'URL publique et l'horodatage. Cinq entrées au 5 août 2026, dont la plus ancienne remonte au 13 juin.

Nous ajoutons ceci, parce que le taire serait précisément la faute que ce paragraphe dénonce : la cinquième a été inscrite deux jours après la mise à disposition qu'elle consigne. Nous n'avons pas reconstruit sa date de mémoire — elle est attestée par trois traces contemporaines de l'événement, dont l'horodatage de l'objet publié lui-même. Mais l'inscription, elle, était en retard. Un registre tenu par une personne seule dérive à la première semaine chargée, et c'est exactement ce qui s'est passé.

Où l'on dépose, et ce qui n'existe pas encore

Le destinataire n'est pas au choix : le CSIRT de l'État membre d'établissement principal — la France pour nous — et l'ENISA simultanément. Le canal est la Single Reporting Platform, annoncée opérationnelle pour le 11 septembre 2026.

Elle n'est pas encore ouverte. Son parcours, lui, est publié : l'authentification passe par EU Login, le CSIRT se choisit dans un menu déroulant à l'inscription, et l'adresse du fabricant est un champ obligatoire. Une période de test est annoncée avant le 11 septembre.

Deux réserves, parce qu'elles limitent ce que nous pouvons affirmer. Les pages publiées à ce jour décrivent le parcours du mandataire, pas celui du fabricant établi dans l'Union — la documentation du second n'est pas parue. Et nous n'avons pas encore déposé sur cette plateforme, pour une raison simple : personne ne l'a fait, elle n'est pas ouverte.

Ce que nous avons fait, en revanche, c'est créer le compte EU Login. Il est requis dans tous les cas, il ne dépend d'aucune ouverture, et un compte à créer un jour d'incident est un compte qu'on n'a pas.

Ce que ce texte ne dit pas

Il ne dit pas ce qui déclenche un signalement. C'est une autre question, et elle est plus contre-intuitive que celle du calendrier : une faille, même critique, ne suffit pas. Nous l'avons traitée séparément — le lien est en fin d'article.

Il ne dit pas non plus si vous êtes en règle. Nous documentons, nous ne certifions jamais, et la qualification définitive d'un produit au regard du CRA relève d'un juriste. Ce qui précède est notre diligence, appliquée d'abord à nous-mêmes, publiée pour que vous puissiez la rejouer sur vos propres produits.

Toutes les sources sont citées en tête de cet article, avec leurs dates de relevé. Un texte réglementaire se modifie : allez les vérifier vous-même.