Depuis le 11 septembre 2026, certaines obligations de signalement du Cyber Resilience Act s’appliquent aux fabricants de produits comportant des éléments numériques. Pour les éditeurs de logiciels et les équipes qui commercialisent des produits intégrant de l’IA, le sujet ne se limite plus à une préparation pour 2027 : il faut pouvoir qualifier un événement, identifier le responsable de la notification et transmettre les informations attendues dans les délais.
Cette analyse distingue le calendrier réglementaire, les événements concernés et l’organisation à préparer. Les exemples sont des scénarios fictifs de gestion de produit. L’applicabilité à un produit particulier dépend de son rôle, de sa mise sur le marché et des dispositions du règlement ; utiliser un modèle d’IA ne suffit pas à déterminer cette qualification.
Quelles obligations commencent le 11 septembre 2026 ?
Les obligations de signalement de l’article 14 du Cyber Resilience Act commencent le 11 septembre 2026, avant l’application générale du règlement prévue le 11 décembre 2027. La Commission européenne distingue ces échéances dans sa présentation du calendrier et du périmètre du CRA.
L’enjeu immédiat consiste à ne pas reporter toute la préparation au chantier de conformité final. Une équipe peut avoir prévu de traiter la documentation, le suivi des composants et les processus de maintenance sur plusieurs trimestres. Un événement qui relève des obligations déjà applicables exige pourtant une organisation opérationnelle maintenant.
Notre recommandation est d’isoler cette capacité de réaction dans le plan de travail : désigner les responsables, vérifier leur accès au canal de notification, préparer les informations disponibles et organiser une relève. Une procédure connue d’une seule personne peut échouer un jour d’absence. Le contrôle utile porte autant sur les personnes joignables et les preuves récupérables que sur l’existence d’une politique écrite.
Qui doit examiner son exposition au CRA ?
Les fabricants qui mettent à disposition sur le marché européen des produits matériels ou logiciels comportant des éléments numériques doivent examiner le périmètre du CRA. La synthèse de la Commission mentionne les produits finaux ainsi que les composants commercialisés séparément. La qualification exige donc de regarder le produit et le rôle de l’entreprise, pas seulement le langage de programmation ou le modèle utilisé.
Prenons un éditeur qui distribue un outil d’analyse documentaire intégrant un composant d’IA. Son dossier de qualification devrait décrire ce qui est livré, comment le logiciel fonctionne, les composants inclus, les mises à jour et les responsabilités contractuelles. Un intégrateur qui configure une solution tierce doit, de son côté, clarifier son rôle réel au lieu de reprendre automatiquement celui du fournisseur initial.
Le CRA et l’AI Act répondent à des objets différents. Une revue des obligations d’un déployeur de système d’IA ne remplace pas une qualification du rôle de fabricant au titre du CRA. Une même organisation peut devoir cartographier plusieurs responsabilités, avec des responsables internes différents. Le bon livrable est une note de périmètre argumentée, révisable lorsque le produit ou sa commercialisation change.
Quels événements faut-il signaler ?
Le CRA vise notamment les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit. La page officielle consacrée aux notifications, mise à jour le 11 septembre 2026, expose ces catégories et les délais associés.
Une alerte provenant d’un outil de surveillance n’est pas automatiquement une qualification réglementaire. L’équipe doit établir ce qui est connu : produit affecté, version, comportement observé, éléments indiquant une exploitation, effets sur la sécurité et incertitudes restantes. Une qualification initiale peut évoluer à mesure que l’enquête progresse ; conserver cette chronologie aide à expliquer les décisions prises.
Pour un produit intégrant un agent IA, un incident peut concerner un connecteur, un mécanisme d’autorisation ou un composant logiciel classique. Évitez de concentrer le dispositif uniquement sur les réponses du modèle. Les contrôles de sécurité des agents et des flux de données apportent un point de départ technique, mais le circuit de notification doit couvrir le produit dans son ensemble.
Quels délais distinguer pour les notifications ?
Le calendrier de signalement comporte une alerte précoce sous 24 heures et une notification sous 72 heures à compter de la prise de connaissance, selon les règles applicables à l’événement. La Commission précise également deux échéances distinctes pour le rapport final : au plus tard 14 jours après la disponibilité d’une mesure corrective pour une vulnérabilité activement exploitée ; dans le mois suivant la notification de 72 heures pour un incident grave.
Ces repères ne signifient pas qu’une équipe doit attendre d’avoir terminé son analyse pour organiser le signalement. La difficulté pratique est souvent de retrouver les informations, de réunir les décideurs et de distinguer les faits établis des hypothèses. Le dossier de suivi doit rendre ces catégories visibles, avec une personne responsable de leur mise à jour.
Le délai se calcule selon les dispositions applicables et la prise de connaissance. Le rapport final suit une échéance différente selon qu’il s’agit d’une vulnérabilité activement exploitée ou d’un incident grave ; il n’existe pas un délai final unique.
Dans une simulation, relevez le temps nécessaire pour identifier la bonne version du produit, contacter le responsable et constituer une première note. Le but n’est pas de produire une vitesse moyenne flatteuse : il est de découvrir les dépendances qui rendent le circuit fragile avant un événement réel.
Où les fabricants doivent-ils envoyer leur signalement ?
La Single Reporting Platform, ou SRP, de l’ENISA constitue le canal de notification prévu pour les fabricants à partir du 11 septembre 2026. La page officielle de l’ENISA présente la plateforme, ses guides et les démarches destinées aux représentants chargés de transmettre les notifications.
La préparation devrait comprendre la lecture des guides actuels, l’identification des représentants et la vérification de leur capacité à utiliser le service. Il ne suffit pas de ranger l’adresse de la plateforme dans un document. L’entreprise doit aussi savoir qui remplace un représentant indisponible et comment les informations validées arrivent jusqu’à lui.
Un exercice peut être réalisé sans envoyer de faux signalement. Préparez un dossier fictif hors de la plateforme, faites circuler les informations entre les personnes désignées et relevez les décisions qui bloquent. La procédure doit préciser quels éléments sont transmis, qui les valide et comment les versions successives du dossier sont conservées. Les modalités techniques de la SRP peuvent évoluer : utilisez les ressources de l’ENISA au moment de préparer l’accès.
Comment préparer une équipe produit sans immobiliser le développement ?
Une équipe produit peut préparer le signalement CRA avec un exercice limité à un produit et à un scénario représentatif. Nous proposons de relier le processus aux outils déjà utilisés pour les incidents, les versions et les composants, plutôt que de créer un registre parallèle que personne ne maintiendra.
Le dossier d’exercice peut comprendre :
- Une fiche du produit, des versions distribuées et du responsable de maintenance.
- Un événement fictif avec faits établis, hypothèses et questions ouvertes.
- Un circuit de qualification associant sécurité, produit et expertise juridique appropriée.
- Une liste des informations récupérables immédiatement et de celles qui demandent une investigation.
- Une décision de correction, un responsable et la preuve du suivi.
Ajoutez une vérification de continuité : que se passe-t-il si le responsable principal est absent, si un fournisseur ne répond pas ou si les journaux sont incomplets ? Les réponses permettent de prioriser des changements concrets. Cette organisation s’intègre à une gouvernance de l’IA et des responsabilités numériques, mais doit conserver ses propres critères de qualification réglementaire.
L’open source appelle aussi une lecture précise. La Commission indique que les obligations spécifiques des gestionnaires de logiciels ouverts prévues à l’article 24, paragraphe 3, commencent le 11 décembre 2027. Cette échéance distincte ne permet pas de conclure qu’un fabricant est exempté simplement parce que son produit embarque un composant ouvert. Documentez le rôle de chaque acteur et faites vérifier les cas limites.
Quelle décision prendre maintenant ?
Le premier objectif est de disposer d’un circuit de signalement utilisable pour les produits concernés, tout en poursuivant le chantier de conformité à l’échéance générale. Commencez par la qualification du périmètre, puis testez une chaîne complète allant de l’alerte à la préparation de la notification.
La preuve d’avancement est un dossier que l’équipe sait constituer, des responsabilités acceptées et des points de blocage traités. Une présentation générale du règlement ne remplace pas cet exercice. Les dates réglementaires donnent un cadre ; la capacité de l’organisation à réagir dépend du travail préparatoire sur ses produits, ses composants et ses décisions.
Sources et périmètre
Cette analyse est datée du 11 septembre 2026. Les pages de la Commission et de l’ENISA documentent les échéances et les canaux ; les scénarios et exercices proposés constituent une méthode de préparation, à adapter après qualification du produit.
