Modification substantielle CRA : quand refaire l'évaluation

C’est la question qui bloque le plus de projets de conformité au Cyber Résilience Act dans les entreprises que je conseille : « si nous livrons une version toutes les deux semaines, faut-il refaire une évaluation de conformité toutes les deux semaines ? » La réponse tient dans une définition de trois lignes — l’article 3, point 30 du règlement (UE) 2024/2847 — et dans les orientations que la Commission a approuvées le 27 juillet 2026. Elle est plus favorable qu’on ne le craint, mais elle impose une discipline documentaire que presque personne n’a encore mise en place.

Pourquoi la modification substantielle commande tout le reste

La notion de modification substantielle n’est pas un détail technique du CRA. Elle est le point de bascule de trois régimes juridiques distincts.

Premier enjeu : le sort de votre parc existant. L’article 69(2) du règlement pose une règle de droit transitoire d’une grande simplicité : « Les produits comportant des éléments numériques qui ont été mis sur le marché avant le 11 décembre 2027 ne sont soumis aux exigences du présent règlement que si, à compter de cette date, ces produits font l’objet d’une modification substantielle. » Autrement dit, tout ce que vous avez livré avant le 11 décembre 2027 échappe aux exigences essentielles de l’annexe I et aux obligations de l’article 13 — jusqu’au jour où vous poussez une modification substantielle. Ce jour-là, et seulement ce jour-là, le produit entre dans le régime plein.

Deuxième enjeu : la réitération de l’évaluation de conformité. Un produit substantiellement modifié est traité comme s’il était nouvellement mis sur le marché. Il faut donc reprendre la chaîne complète : évaluation de conformité selon le module applicable, mise à jour de la documentation technique, nouvelle déclaration UE de conformité (art. 28), apposition du marquage CE au titre de la version modifiée. Pour un produit important de classe II ou un produit critique, cela signifie un retour devant l’organisme notifié — avec les délais et les coûts correspondants.

Troisième enjeu : le changement de débiteur de l’obligation. Celui qui réalise la modification substantielle devient fabricant au sens du règlement, même s’il n’a pas écrit une ligne du produit d’origine. C’est l’objet des articles 21 et 22, sur lesquels je reviens plus bas.

Ces trois enjeux se traduisent en euros. Le premier palier de sanctions du CRA — manquement aux exigences essentielles de l’annexe I ou aux procédures d’évaluation de la conformité — plafonne à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Se tromper sur la qualification d’une release n’est donc pas une erreur de procédure interne.

Le test juridique : deux branches alternatives

L’article 3, point 30 définit la modification substantielle comme :

« une modification du produit comportant des éléments numériques, après sa mise sur le marché, qui affecte la conformité du produit comportant des éléments numériques aux exigences essentielles de cybersécurité énoncées à l’annexe I, partie I, ou qui entraîne une modification de la destination pour laquelle le produit comportant des éléments numériques a été évalué ».

Trois observations de lecture, dans l’ordre où elles comptent.

La conjonction est un « ou », pas un « et ». Le test comporte deux branches alternatives. Il suffit qu’une seule soit remplie. Une modification qui ne touche pas la destination du produit peut être substantielle si elle affecte la conformité aux exigences essentielles ; une modification techniquement anodine peut être substantielle si elle change la destination.

La première branche vise l’annexe I, partie I uniquement. C’est-à-dire les exigences essentielles de cybersécurité applicables au produit : absence de vulnérabilité exploitable connue à la livraison, configuration sécurisée par défaut, contrôle d’accès, chiffrement, minimisation de la surface d’attaque, journalisation, etc. La partie II de l’annexe I — les exigences relatives aux processus de traitement des vulnérabilités — n’est pas visée par le test. C’est logique : ces processus ne sont pas une caractéristique du produit livré, ils sont une obligation continue pendant toute la période de support.

La seconde branche renvoie à la « destination » au sens de l’article 3, point 23, c’est-à-dire l’usage prévu par le fabricant, « y compris le contexte et les conditions d’utilisation spécifiques », tel qu’il ressort de la notice, des supports commerciaux et de la documentation technique. La destination n’est donc pas ce que vous pensez de votre produit : c’est ce que vous en avez écrit. Un produit dont la documentation technique décrit un fonctionnement strictement local et qui se met à remonter des données vers un service cloud a changé de destination, même si le code applicatif n’a pratiquement pas bougé.

Ce que tranchent les considérants 38, 39 et 40

Les considérants du règlement sont, en la matière, plus opérationnels que le dispositif. Trois d’entre eux méritent d’être lus mot à mot.

Le considérant 38 pose le critère général : est substantielle la modification, physique ou numérique, réalisée « d’une manière qui n’était pas prévue par le fabricant dans l’évaluation initiale des risques et qui peut impliquer qu’ils ne satisfont plus aux exigences essentielles de cybersécurité applicables ». La référence à l’évaluation initiale des risques est décisive : le périmètre de ce que vous avez anticipé au moment de la mise sur le marché détermine ce qui sera considéré comme substantiel ensuite. Une analyse de risques large et bien documentée réduit mécaniquement le nombre de releases qualifiables de substantielles.

Le considérant 39 transpose ce raisonnement aux mises à jour logicielles :

Type de changement	Qualification	Fondement
Correctif de sécurité fermant une vulnérabilité connue	Non substantiel	Cons. 39 : finalité exclusive de réduction du risque
Mise à jour mineure de fonctionnalité (habillage visuel, pictogrammes, nouvelle langue d’interface)	Non substantiel	Cons. 39, en principe
Correctif de sécurité qui modifie aussi la destination	Substantiel	Cons. 39, a contrario
Mise à jour ajoutant une fonctionnalité qui élargit la surface d’attaque	Substantiel	Cons. 39 : nouvel élément d’entrée, validation à assurer
Fonctionnalité livrée conjointement à un correctif de sécurité	Substantiel si la fonctionnalité l’est	Cons. 39 : le mode de livraison est indifférent

Ce dernier point est celui que les équipes produit sous-estiment le plus. Le considérant 39 précise expressément que, pour apprécier si une mise à jour de fonctionnalité constitue une modification substantielle, « le fait qu’elle soit fournie sous la forme d’une mise à jour distincte ou combinée à une mise à jour de sécurité n’est pas pertinent ». Emballer une nouvelle fonctionnalité dans un patch de sécurité ne la neutralise pas juridiquement.

Le considérant 40 règle enfin le cas du logiciel à versions successives : le fabricant qui a mis sur le marché des versions successivement modifiées de façon substantielle peut ne fournir les mises à jour de sécurité que pour la dernière version mise sur le marché — à condition que les utilisateurs des versions antérieures y accèdent gratuitement et sans coût d’adaptation de leur environnement matériel ou logiciel. C’est la règle codifiée à l’article 13(10). Elle est précieuse pour les éditeurs, mais elle ne dispense pas des autres obligations de traitement des vulnérabilités (politique de divulgation coordonnée, notamment) pour toutes les versions substantiellement modifiées mises sur le marché.

Les orientations de la Commission du 27 juillet 2026

L’article 26(1)(d) du CRA impose expressément à la Commission de publier des orientations portant sur « la notion de modification substantielle ». Elle s’en est acquittée le 27 juillet 2026 : la communication C(2026) 5252 et son annexe — environ 80 pages, construites autour de 67 exemples pratiques, de cas d’usage et de logigrammes, avec les TPE et PME comme public prioritaire.

Deux précautions de méthode avant d’en tirer parti.

D’abord, ces orientations ne sont pas contraignantes. Seule la Cour de justice de l’Union européenne peut donner une interprétation faisant autorité, et seule une norme harmonisée citée au Journal officiel ouvre la présomption de conformité de l’article 27. Ensuite, la Commission a approuvé le contenu du document ; son adoption formelle interviendra lorsque toutes les versions linguistiques seront disponibles. Le fond ne devrait plus évoluer, mais la date d’adoption reste à venir.

Cela dit, les autorités de surveillance du marché et les organismes notifiés s’y référeront pour une lecture harmonisée. Sur la modification substantielle, les orientations apportent trois clarifications utiles :

Le test porte sur le risque, pas sur la taille du changement. Ce qui compte, c’est l’impact du changement sur le profil de risque cyber du produit — nouveaux vecteurs de menace, nouveaux scénarios d’attaque, modification de la vraisemblance ou de l’impact — et non le volume de code modifié. Une refonte massive de l’interface graphique peut n’être pas substantielle ; l’ajout de trois lignes ouvrant un port réseau peut l’être.

Les mises à jour de sécurité ne sont, en principe, pas des modifications substantielles. Leur finalité étant de réduire le risque, un correctif qui ne change ni la destination ni le profil de risque ne déclenche pas, à lui seul, de nouvelle évaluation. C’est la confirmation attendue par tous ceux qui pratiquent la gestion des correctifs en flux continu.

La conséquence est une nouvelle mise sur le marché. Le produit substantiellement modifié est traité comme nouvellement mis sur le marché, et lorsque la modification est le fait d’un tiers, celui-ci endosse les obligations du fabricant pour la partie affectée.

Un mot sur le contexte normatif, parce qu’il change la charge de travail : à ce jour, aucune norme harmonisée CRA n’a été citée au Journal officiel. La demande de normalisation M/606, acceptée par le CEN, le CENELEC et l’ETSI en 2025, porte sur une quarantaine de normes ; les deux normes horizontales structurantes (développement sécurisé et traitement des vulnérabilités) sont attendues pour le 30 août 2026, les normes produit verticales pour le 30 octobre 2026. Tant qu’elles ne sont pas citées, la présomption de conformité n’est disponible pour aucune catégorie de produits — ce qui, pour les produits importants de classe I, fait basculer l’évaluation vers le module B+C ou le module H (art. 32(2)) au lieu du contrôle interne. Refaire une évaluation après modification substantielle coûte, dans ce contexte, sensiblement plus cher qu’en régime de croisière.

Grille de qualification : dix cas concrets

Voici la grille que j’utilise en atelier avec les équipes produit et juridique. Elle n’a évidemment pas valeur d’avis sur un cas particulier, mais elle donne le sens de la pente.

Changement livré	Qualification probable	Raisonnement
Correctif fermant une CVE, sans changement de modèle de confiance	Non substantielle	Réduction pure du risque (cons. 39)
Ajout d’une langue d’interface	Non substantielle	Mise à jour mineure de fonctionnalité (cons. 39)
Refonte de l’UI sans nouvelle entrée utilisateur	Non substantielle	Pas de surface d’attaque nouvelle
Montée de version d’une dépendance tierce, périmètre fonctionnel constant	Non substantielle en principe	Maintenance ; à documenter au SBOM
Ajout d’une API publique ou d’un webhook entrant	Substantielle	Nouvelle surface d’attaque, validation d’entrée à assurer
Activation d’une synchronisation cloud sur un produit évalué en local	Substantielle	Modification de la destination (art. 3(23))
Suppression ou affaiblissement d’une authentification mutuelle	Substantielle	Atteinte directe à l’annexe I, partie I
Ajout d’une interface radio ou d’un protocole réseau	Substantielle	Nouveau vecteur de menace
Traitement de nouvelles catégories de données (paiement, santé)	Substantielle	Destination et exigences de confidentialité modifiées
Ajout d’un module d’IA générative appelant un service tiers	Substantielle	Destination, surface d’attaque et double conformité CRA / AI Act

Deux cas méritent une nuance. La montée de version d’une dépendance tierce est en principe de la maintenance, mais elle cesse de l’être si la nouvelle version introduit des fonctions activées par défaut que votre évaluation initiale n’avait pas envisagées — situation fréquente avec les bibliothèques de télémétrie. Et l’ajout d’un module d’IA appelle une analyse croisée : si le produit devient un système d’IA à haut risque, la procédure d’évaluation obéit aux articles 12 et 32(3) du CRA combinés à l’article 43 du règlement (UE) 2024/1689, comme je l’expose dans l’article consacré au marquage CE des systèmes d’IA.

Qui devient fabricant : les articles 21 et 22

Le CRA fait produire à la modification substantielle un effet que beaucoup d’intégrateurs découvrent tardivement : elle transfère la qualité de fabricant.

L’article 21 vise les importateurs et distributeurs : « Un importateur ou un distributeur est considéré comme un fabricant aux fins du présent règlement et est soumis aux articles 13 et 14 lorsqu’il met sur le marché un produit comportant des éléments numériques sous son propre nom ou sa propre marque ou qu’il procède à une modification substantielle d’un produit comportant des éléments numériques déjà mis sur le marché. » C’est le prolongement direct des responsabilités des importateurs et distributeurs.

L’article 22 vise tous les autres : toute personne physique ou morale, autre que le fabricant, l’importateur ou le distributeur, qui réalise une modification substantielle et met le produit à disposition sur le marché est considérée comme fabricant. Son paragraphe 2 délimite l’étendue de la charge : elle est soumise aux articles 13 et 14 « pour la partie du produit comportant des éléments numériques qui est affectée par la modification substantielle ou, si la modification substantielle a une incidence sur la cybersécurité du produit comportant des éléments numériques dans son ensemble, pour l’ensemble du produit ».

Les situations concrètes sont plus nombreuses qu’il n’y paraît :

• L’intégrateur qui reprend un produit du commerce, y ajoute un connecteur métier et le revend sous contrat de projet.
• L’ESN qui exploite un progiciel pour le compte d’un client et y greffe des développements spécifiques modifiant la surface d’attaque.
• Le revendeur en marque blanche, déjà couvert par l’article 21 du seul fait de la marque apposée.
• Celui qui forke un composant open source et le distribue modifié dans le cadre d’une activité commerciale — le régime allégé du steward, décrit dans mon article sur le CRA et l’open source, ne s’étend pas à qui fait de la version modifiée un produit commercial.

Conséquence contractuelle immédiate : les clauses fournisseurs doivent désormais nommer la modification substantielle, en attribuer la charge et organiser la circulation des informations nécessaires (documentation technique, SBOM, évaluation de risques initiale). Je détaille ces clauses dans l’article consacré aux obligations CRA dans la chaîne d’approvisionnement.

Construire la porte de décision dans votre cycle de release

La vraie difficulté du sujet n’est pas juridique, elle est organisationnelle. Le règlement ne prescrit aucune procédure de qualification. Mais en cas de contrôle, c’est vous qui devez démontrer que le produit n’a pas été substantiellement modifié — et l’absence de traçabilité retourne la charge de la preuve contre vous. Voici l’architecture que je recommande.

Six questions à poser à chaque release

Une porte de décision, insérée dans le processus de livraison, entre la revue technique et la mise en production :

1. La destination du produit change-t-elle ? Nouveau contexte d’usage, nouveau type d’utilisateur, nouvelle catégorie de données traitées, nouvel environnement d’exploitation ?
2. La surface d’attaque s’élargit-elle ? Nouvelle interface réseau, nouveau point d’entrée utilisateur, nouveau protocole, nouveau service exposé, nouvelle dépendance externe appelée à l’exécution ?
3. Le modèle de confiance est-il modifié ? Authentification, autorisations, chiffrement, gestion des secrets, isolation des composants — cf. la logique de la gestion des habilitations.
4. Le changement était-il couvert par l’évaluation de risques initiale ? Si oui, argumentez-le par référence au document ; si non, la présomption penche vers la modification substantielle.
5. La documentation utilisateur (annexe II) doit-elle être modifiée ? Un besoin de réécriture de la notice est un signal fort de changement de destination.
6. Le changement affecte-t-il une exigence de l’annexe I, partie I ? Passez la liste point par point ; c’est la branche « technique » du test.

Une réponse positive aux questions 1, 2, 3 ou 6 fait basculer le dossier vers l’analyse approfondie et la validation conjointe produit/juridique.

Ce qu’il faut consigner

Élément	Contenu attendu	Où le conserver
Journal des modifications	Version, date, périmètre fonctionnel, réponses aux six questions	Documentation technique (annexe VII)
Qualification retenue	Substantielle / non substantielle, motivation en trois à cinq lignes	Journal des modifications
Validation	Signature produit + juridique, horodatée	Journal des modifications
Mise à jour de l’évaluation de risques	Obligatoire dès que le profil de risque évolue (art. 13(3) et 13(7))	Documentation technique
Réexamen de la période de support	Ne se réinitialise pas automatiquement ; à réapprécier selon les mêmes critères (art. 13(8))	Documentation technique
Date de première mise sur le marché par unité ou par version	Preuve du bénéfice de l’art. 69(2)	Système d’information produit

Ce dernier point est celui que je vois le plus souvent manquer. La mise sur le marché s’entend, aux termes de l’article 3, point 21, de la « première mise à disposition » du produit sur le marché de l’Union. Pour un fabricant de matériel, elle s’apprécie unité par unité, au moment de la première fourniture commerciale — pas au moment de la vente au détail. Sans registre d’expédition daté, le bénéfice de l’antériorité du 11 décembre 2027 devient indémontrable.

Tenir ce registre à jour manuellement, produit par produit et version par version, est exactement le type de travail documentaire répétitif qu’un outil de conformité automatise — c’est ce que Legiscope fait pour le registre RGPD et la documentation associée.

Le cas particulier des éditeurs en livraison continue

Les éditeurs SaaS et logiciels posent une question spécifique : que devient le test quand on livre plusieurs fois par semaine ?

Trois éléments de réponse.

Le périmètre du CRA d’abord. Les orientations de la Commission confirment que le lieu d’exécution du logiciel est déterminant. Un logiciel qui s’exécute sur le poste de l’utilisateur — application téléchargée, extension de navigateur, client installé — est un produit comportant des éléments numériques. Une application web utilisée uniquement au travers d’un navigateur n’en est pas un de ce seul fait : elle ne relève du CRA que si elle constitue une solution de traitement de données à distance nécessaire au fonctionnement d’un produit (art. 3(2)). Beaucoup d’éditeurs purement web se croient concernés à tort ; beaucoup d’éditeurs d’agents installés se croient hors périmètre à tort.

La règle du considérant 40 et de l’article 13(10) ensuite. Le fabricant qui enchaîne les versions substantiellement modifiées n’a pas à maintenir indéfiniment toutes les versions : il peut concentrer les mises à jour de sécurité sur la dernière version, si les utilisateurs des versions antérieures y accèdent gratuitement et sans coût d’adaptation. C’est le cadre juridique du « rolling release » — mais il suppose une politique de mise à niveau réellement gratuite et sans friction technique.

La discipline de release enfin. Une organisation en livraison continue qui documente correctement son évaluation de risques initiale, qui sépare dans son suivi les correctifs de sécurité, les évolutions mineures et les évolutions fonctionnelles, et qui journalise ses qualifications, se retrouvera avec un nombre très faible de modifications substantielles par an. Une organisation qui ne fait rien de tout cela devra présumer que chaque release majeure en est une.

Cinq erreurs qui reviennent systématiquement

1. Croire que l’antériorité au 11 décembre 2027 est acquise. L’article 69(2) protège, mais il faut prouver la date de première mise sur le marché et l’absence de modification substantielle depuis. Sans registre, la protection est théorique.

2. Oublier la dérogation de l’article 69(3). Les obligations de signalement de l’article 14 s’appliquent à tous les produits dans le champ du règlement mis sur le marché avant le 11 décembre 2027, et ce depuis le 11 septembre 2026. Un produit livré en 2022 et jamais modifié doit néanmoins entrer dans votre dispositif de signalement des vulnérabilités — alerte précoce à 24 heures, notification à 72 heures, rapport final à 14 jours.

3. Confondre modification substantielle et changement majeur de version. La numérotation sémantique de vos releases n’a aucune valeur juridique. Une version 3.0 peut n’être qu’une refonte visuelle ; une version 2.4.1 peut ouvrir un port réseau.

4. Traiter la question au niveau de l’entreprise plutôt que du produit. Le test s’applique produit par produit, et parfois composant par composant lorsque l’article 22(2) limite la charge à la partie affectée. Une doctrine unique valable pour tout le catalogue n’existe pas.

5. Ne pas rejouer les obligations connexes. Une modification substantielle réinterroge aussi l’appréciation de la période de support, la mise à jour du SBOM, la déclaration UE de conformité et — lorsque le produit traite des données personnelles — l’analyse de sécurité au titre de l’article 32 du RGPD, dont je décris l’articulation avec le CRA dans l’article sur l’intersection CRA / RGPD.

Ce qu’il faut retenir

• Le test de l’article 3(30) a deux branches alternatives : une modification est substantielle si elle affecte la conformité aux exigences essentielles de l’annexe I, partie I, ou si elle modifie la destination pour laquelle le produit a été évalué.
• Les correctifs de sécurité ne sont pas des modifications substantielles, dès lors qu’ils ne changent ni la destination ni le profil de risque (considérant 39). Les ajouts de fonctionnalités qui élargissent la surface d’attaque, si — y compris livrés en même temps qu’un correctif.
• La qualification se joue sur le risque, pas sur le volume de code, et par référence à ce que votre évaluation de risques initiale avait anticipé (considérant 38). Une évaluation initiale large et bien documentée réduit le nombre de releases substantielles.
• Une modification substantielle vaut nouvelle mise sur le marché : nouvelle évaluation de conformité, documentation technique mise à jour, nouvelle déclaration UE de conformité, perte du bénéfice de l’antériorité de l’article 69(2). Le premier palier de sanctions atteint 15 M€ ou 2,5 % du chiffre d’affaires mondial.
• Celui qui modifie devient fabricant (art. 21 et 22), pour la partie affectée ou pour l’ensemble du produit selon l’incidence de la modification. Intégrateurs, ESN et revendeurs en marque blanche sont directement exposés.
• Sans journal de qualification daté et signé, vous ne pourrez rien démontrer. La procédure interne — six questions, une décision motivée, une double validation — est le vrai livrable du sujet.

Vous suivez le calendrier CRA ?

Les échéances s’enchaînent : signalement des vulnérabilités depuis le 11 septembre 2026, normes harmonisées attendues fin 2026, application générale au 11 décembre 2027. Je publie chaque semaine une analyse des textes européens de conformité numérique — CRA, NIS2, AI Act, RGPD — avec ce qu’ils changent concrètement pour les entreprises françaises. Recevez la newsletter.

FAQ

Une mise à jour de sécurité déclenche-t-elle une nouvelle évaluation de conformité CRA ?

Non, en principe. Le considérant 39 du règlement (UE) 2024/2847 précise qu’une mise à jour de sécurité destinée à réduire le niveau de risque cyber, qui ne modifie pas la destination du produit, n’est pas une modification substantielle. Cela vise typiquement le correctif fermant une vulnérabilité connue par des ajustements mineurs du code source. En revanche, si le correctif s’accompagne d’une évolution fonctionnelle élargissant la surface d’attaque, cette évolution s’apprécie pour elle-même : le fait qu’elle soit livrée avec un patch de sécurité est expressément indifférent.

Mes produits vendus avant décembre 2027 sont-ils soumis au CRA ?

Partiellement. L’article 69(2) prévoit qu’ils ne sont soumis aux exigences du règlement que s’ils font l’objet d’une modification substantielle à compter du 11 décembre 2027. Mais l’article 69(3) apporte une dérogation majeure : les obligations de signalement de l’article 14 s’appliquent à tous les produits dans le champ du règlement mis sur le marché avant cette date, et ce depuis le 11 septembre 2026. Concrètement, votre parc historique échappe à l’annexe I et à l’article 13, mais pas au signalement des vulnérabilités activement exploitées.

Qui doit refaire l’évaluation lorsqu’un intégrateur modifie un produit du commerce ?

L’intégrateur, s’il réalise une modification substantielle et met le produit modifié à disposition sur le marché. L’article 22 le considère alors comme fabricant et le soumet aux articles 13 et 14, pour la partie du produit affectée par la modification ou, si la modification a une incidence sur la cybersécurité de l’ensemble, pour le produit entier. Le fabricant d’origine reste responsable de la version qu’il a lui-même mise sur le marché.

La période de support repart-elle à zéro après une modification substantielle ?

Non, elle ne se réinitialise pas automatiquement. Les orientations de la Commission invitent à réapprécier la période au regard des mêmes critères que ceux de l’article 13(8) : durée d’utilisation raisonnablement attendue du produit, attentes des utilisateurs, nature du produit, droit de l’Union applicable. Le plancher de cinq ans s’applique, sauf si le produit est censé être utilisé moins longtemps. La motivation retenue doit figurer dans la documentation technique.

Les orientations de la Commission du 27 juillet 2026 sont-elles contraignantes ?

Non. La communication C(2026) 5252 et son annexe sont prises sur le fondement de l’article 26 du CRA et n’ont aucune valeur normative : seule la Cour de justice de l’Union européenne peut délivrer une interprétation faisant autorité, et seule une norme harmonisée citée au Journal officiel ouvre la présomption de conformité de l’article 27. Les orientations restent néanmoins la référence de lecture des autorités de surveillance du marché et des organismes notifiés, ce qui en fait un document qu’il est imprudent d’ignorer.

Comment articuler ce test avec les autres réglementations produit ?

Le CRA se combine avec les régimes sectoriels et transversaux existants. Une modification substantielle peut simultanément déclencher une réévaluation au titre de l’AI Act pour un produit intégrant un système d’IA à haut risque, faire évoluer les obligations de sécurité au titre de NIS2 pour l’entité qui exploite le produit, et engager la responsabilité du fait des produits défectueux dans sa version applicable aux logiciels depuis décembre 2026. La cartographie des textes applicables doit être refaite à chaque changement de destination.