Depuis février, nous accompagnons trois éditeurs français — un logiciel de gestion pour cabinets comptables, une solution de supervision industrielle, un fournisseur de boîtiers connectés pour la logistique. Tous les trois mettent sur le marché européen des produits comportant des éléments numériques. Tous les trois sont donc fabricants au sens du Cyber Resilience Act.
Aucun des trois n'avait mesuré ce que représentait l'échéance du 11 septembre 2026 avant que nous ne déroulions le scénario minute par minute. Deux d'entre eux pensaient avoir jusqu'à décembre 2027. C'est l'erreur de lecture la plus répandue, et elle coûte cher parce qu'elle fait rater la seule échéance qui exige une capacité opérationnelle plutôt qu'un dossier documentaire.
Voici les sept étapes que nous déroulons désormais systématiquement, dans l'ordre où elles auraient dû être engagées.
Les deux dates qu'il faut cesser de confondre
Le règlement s'applique par paliers. Ce découpage est la source de la quasi-totalité des malentendus que nous rencontrons :
| Échéance | Ce qui devient exigible | Nature de l'effort |
|---|---|---|
| 11 septembre 2026 | Notification des vulnérabilités activement exploitées et des incidents graves, via la plateforme opérée par l'ENISA | Capacité opérationnelle : astreinte, procédure, accès |
| 11 décembre 2027 | Exigences essentielles de cybersécurité, documentation technique complète incluant la nomenclature logicielle, marquage de conformité | Effort produit et documentaire |
Retenez la distinction ainsi : 2027 vous demande de prouver que votre produit est sûr. 2026 vous demande d'être joignable et réactif quand il ne l'est pas. La seconde obligation est beaucoup plus proche, et beaucoup moins coûteuse à préparer — à condition de s'y mettre maintenant.
Étape 1 : Déterminer si vous êtes fabricant, et pour quels produits
Le CRA ne prévoit pas d'exemption générale fondée sur la taille de l'entreprise. Ce qui détermine votre statut, c'est le rôle que vous jouez dans la mise sur le marché et la nature du produit — pas votre effectif ni votre chiffre d'affaires.
Si vous mettez sur le marché de l'Union un produit comportant des éléments numériques sous votre nom ou votre marque, vous êtes fabricant. Cela inclut des cas que nos clients n'avaient pas anticipés : un module que vous distribuez à des intégrateurs, une application mobile compagnon d'un matériel, un firmware que vous maintenez pour un équipement fabriqué par un tiers.
L'inventaire à produire tient en trois colonnes : le produit, votre rôle (fabricant, importateur, distributeur), et la date de mise sur le marché. Chez l'éditeur de supervision industrielle, cet exercice a fait apparaître quatre produits là où la direction en comptait deux — deux briques historiques encore déployées chez des clients n'étaient plus suivies par personne en interne.
Étape 2 : Produire un SBOM exploitable, pas décoratif
La nomenclature logicielle relève formellement des exigences de 2027. Traiter cette échéance comme une autorisation d'attendre est le piège le plus coûteux du dispositif.
Raison simple : lorsqu'une vulnérabilité activement exploitée est publiée sur un composant tiers, vous disposez de 24 heures pour déterminer si votre produit est affecté. Sans inventaire au niveau des composants, cette question se traite à la main, par sondage dans le code, un dimanche — et la réponse arrive trop tard.
Un SBOM utile se distingue d'un SBOM décoratif sur trois points : il est généré automatiquement à chaque build et non produit une fois par an ; il couvre les dépendances transitives et pas seulement les dépendances directes ; il est interrogeable, c'est-à-dire que quelqu'un peut répondre en quelques minutes à « sommes-nous exposés à cette CVE, et dans quelles versions livrées ». Si ces trois conditions ne sont pas réunies, vous avez un fichier, pas une capacité.
Étape 3 : Définir précisément ce qui déclenche le compteur
Le délai de 24 heures court à partir du moment où vous prenez connaissance de la vulnérabilité activement exploitée. Cette formulation paraît anodine, elle est en réalité la question la plus délicate du dispositif.
Que se passe-t-il si un client mentionne un comportement anormal dans un ticket de support un mardi, et que l'équipe sécurité ne l'analyse que le jeudi ? La prise de connaissance date-t-elle du mardi ? Nous recommandons de trancher cette question par écrit, en amont, plutôt que de la découvrir en situation.
Concrètement : définissez les canaux par lesquels une information de sécurité peut arriver (support, bug bounty, veille CVE, signalement chercheur, remontée client), et pour chacun, le circuit et le délai maximal de qualification. Un ticket de support contenant les mots-clés d'un incident de sécurité doit être escaladé en heures, pas en jours.
Vous ne savez pas si le CRA vous qualifie comme fabricant ?
Nous qualifions votre périmètre produit et votre chaîne de notification en une demi-journée. Vous repartez avec l'inventaire, le circuit d'escalade et la liste des trous à combler avant le 11 septembre.
Discutons-en 30 minutesÉtape 4 : Monter une astreinte qui tient réellement 24 h / 72 h / 14 jours
C'est ici que nos trois clients ont buté, et sur un point qu'aucun d'eux n'avait anticipé : la délégation de signature.
Le scénario type : une vulnérabilité activement exploitée est confirmée un vendredi à 21 h. Le responsable technique d'astreinte a la compétence pour rédiger la notification, mais pas le mandat pour déclarer au nom de l'entreprise. Le dirigeant est injoignable jusqu'au lundi. Le délai de 24 heures expire samedi soir.
Quatre éléments doivent exister avant l'échéance, et aucun ne s'improvise :
- une chaîne d'astreinte nommée, avec un titulaire et un suppléant joignables hors heures ouvrées ;
- un accès pré-enregistré et testé à la plateforme de signalement — créer un compte dans l'urgence est une perte de temps garantie ;
- des modèles de notification pré-rédigés pour l'alerte à 24 h et la notification à 72 h, avec les champs à compléter ;
- une délégation de signature écrite autorisant explicitement la personne d'astreinte à déclarer sans validation hiérarchique préalable.
Ce dernier point relève du juridique et non de la technique, ce qui explique qu'il soit systématiquement oublié par les équipes sécurité. Faites-le signer maintenant.
Étape 5 : Cartographier vos dépendances en fin de vie
Une dépendance qui n'est plus maintenue en amont ne recevra jamais de correctif. Si elle est touchée par une vulnérabilité activement exploitée, vous restez tenu de notifier — puis de fournir vous-même une mesure corrective, que ce soit par contournement, remplacement du composant ou fork.
Sortez de votre SBOM la liste des composants dont le support amont est terminé ou annoncé comme tel dans les dix-huit mois. Pour chacun, tranchez maintenant entre trois options : remplacer, internaliser la maintenance, ou documenter un plan de contournement. Chez l'éditeur pour cabinets comptables, cet exercice a identifié onze composants en fin de vie, dont deux dans le chemin d'authentification.
Étape 6 : Répercuter les obligations dans vos contrats fournisseurs
Vos délais de notification dépendent de la réactivité de vos propres fournisseurs. Si un composant sous licence commerciale est vulnérable et que votre éditeur amont met une semaine à vous répondre, votre compteur de 24 heures a expiré depuis longtemps.
Introduisez dans vos contrats de fourniture logicielle une clause d'information de sécurité : délai maximal de notification vers vous, point de contact nommé, engagement de fourniture d'un SBOM à jour. Pour les composants open source, cette clause n'existe évidemment pas — d'où l'importance de l'étape 5, qui est votre seul filet.
Le sujet recoupe directement la gestion des risques fournisseurs que nous détaillons dans notre série sur la conformité, et il rejoint les logiques d'audit de périmètre que les équipes produit connaissent déjà.
Étape 7 : Répéter la procédure à blanc avant l'échéance
Une procédure jamais testée est une hypothèse. Organisez au moins un exercice complet avant le 11 septembre, de préférence deux, dont un déclenché en dehors des heures ouvrées.
Le scénario que nous utilisons : une CVE critique est publiée sur un composant que vous embarquez, avec preuve d'exploitation active. Chronométrez trois choses — le temps pour déterminer si vous êtes affecté (c'est le test réel de votre SBOM), le temps pour joindre la personne habilitée, et le temps pour produire une notification complète.
Chez notre client industriel, le premier exercice a donné 9 heures pour la seule question « sommes-nous affectés ». Après reprise du SBOM et automatisation de la requête, le second exercice est descendu à 25 minutes. C'est exactement l'écart entre une conformité tenable et une conformité théorique.
Ce que je referais différemment
Sur ces trois accompagnements, l'erreur commune n'a pas été technique. Elle a été de traiter le CRA comme un dossier de conformité à constituer, alors que l'échéance de septembre 2026 exige une capacité à réagir. Les deux ne se préparent pas de la même façon et ne mobilisent pas les mêmes personnes.
Si je reprenais depuis le début, j'inverserais l'ordre : la délégation de signature et l'accès à la plateforme d'abord — deux tâches administratives qui prennent une semaine et débloquent tout le reste — puis le SBOM, puis la documentation. Nous avons fait l'inverse chez le premier client, et nous avons perdu deux mois.
Pour les équipes qui exploitent des composants d'IA générative dans leurs produits, le périmètre se complique encore : l'inventaire doit inclure les modèles et leurs dépendances. Nos confrères de Plug-Tech documentent le volet gouvernance de ces briques, et d-open.org traite la question côté organisation des équipes de développement.
Questions fréquentes
Que se passe-t-il exactement le 11 septembre 2026 ?
Les obligations de signalement deviennent applicables. Toute vulnérabilité activement exploitée et tout incident grave affectant la sécurité de votre produit doivent être notifiés sans retard injustifié : alerte précoce sous 24 heures, notification complète sous 72 heures, rapport final au plus tard 14 jours après la mise à disposition d'une mesure corrective (un mois pour un incident grave). Les notifications passent par la plateforme de signalement unique opérée par l'ENISA.
Le SBOM est-il obligatoire dès septembre 2026 ?
Son exigibilité formelle relève de l'échéance de décembre 2027. Mais sans visibilité au niveau des composants, il est matériellement impossible de dire en 24 heures si une vulnérabilité vous affecte. Le SBOM est donc un prérequis opérationnel de 2026, quelle que soit sa date d'exigibilité juridique.
Une PME éditrice de logiciel est-elle concernée ?
Il n'existe pas d'exemption générale liée à la taille. Ce sont votre rôle et la nature du produit qui déterminent votre statut. Des aménagements existent pour certaines catégories, notamment autour des micro-entreprises et de l'open source non commercial, mais ils portent sur les modalités et non sur le principe. Faites qualifier votre cas.
Que faire si on découvre une vulnérabilité exploitée un vendredi soir ?
Le délai court sans considération pour les horaires ouvrés. Il vous faut une astreinte nommée avec suppléant, un accès pré-enregistré et testé à la plateforme, des modèles de notification prêts, et une délégation de signature explicite. Ces quatre éléments se préparent en amont.
Conclusion : cinq semaines, et deux d'entre elles sont administratives
Le CRA n'est pas un mur technique. C'est une exigence de réactivité qui met à nu les organisations dont la chaîne de décision s'arrête le vendredi soir. La bonne nouvelle, c'est que l'essentiel de ce qui manque se règle par des décisions écrites plutôt que par du développement.
Il reste cinq semaines avant le 11 septembre 2026. Si vous n'avez pas encore d'inventaire produit ni de délégation de signature, commencez par ces deux-là. Parlons-en — nous cadrons votre périmètre en une demi-journée, et vous repartez avec la liste des trous à combler, même si vous menez le chantier sans nous.