CRA et règlement IA : chevauchement cybersécurité pour l'IA à haut risque

Vous construisez un contrôleur de sécurité IA pour un réseau électrique. C'est un produit comportant des éléments numériques, donc le règlement sur la cyberrésilience (CRA) s'applique. C'est aussi un système d'IA à haut risque, donc le règlement IA s'applique. Deux règlements, deux évaluations de la conformité, deux déclarations ? Pas pour la partie cybersécurité.

À l'issue de cette lecture, vous saurez trois choses : si le chevauchement concerne votre produit, quels éléments probants de cybersécurité vous pouvez réutiliser entre les deux textes, et ce qui nécessite encore un traitement propre au règlement IA. En résumé : l'article 12 du CRA vous permet de réutiliser les preuves de cybersécurité dans les deux régimes, sous conditions. Il ne fusionne pas la conformité CRA et la conformité au règlement IA en un régime unique.

Résumé

• Le chevauchement est étroit. Il ne concerne que les produits qui sont à la fois dans le champ du CRA et des systèmes d'IA à haut risque au titre du règlement IA.
• Le CRA offre un pont à sens unique, sous conditions. Satisfaire aux exigences de cybersécurité du CRA et montrer ce niveau de protection dans votre déclaration UE de conformité CRA permet au produit d'être réputé conforme à l'exigence de cybersécurité du règlement IA.
• Le pont couvre uniquement la cybersécurité. La précision et la robustesse au titre du règlement IA restent hors champ et demeurent du côté du règlement IA.
• Pour la plupart des produits, vous réalisez une seule évaluation de la conformité, maintenez un seul ensemble de documentation technique et apposez un seul marquage CE. Les produits CRA importants et critiques font exception.
• Tout le reste reste distinct. La gouvernance des données, la journalisation et la surveillance humaine restent du côté du règlement IA. Le SBOM, la gestion des vulnérabilités, la période d'assistance et le signalement sous 24 heures restent du côté du CRA.

Êtes-vous dans la zone de chevauchement ?

La plupart des IA ne sont pas dans le champ du CRA, et la plupart des produits CRA ne sont pas des IA. Trois questions tranchent.

• S'agit-il d'un produit comportant des éléments numériques ? Le CRA couvre les matériels et logiciels qui se connectent à un appareil ou à un réseau. Un processus entièrement papier ou un outil totalement hors connexion est hors champ.
• Est-ce aussi un système d'IA à haut risque ? Au titre du règlement IA, un système est à haut risque lorsqu'il est un composant de sécurité d'un produit qui nécessite déjà des tests indépendants, ou lorsqu'il réalise l'un des usages à haut risque que le règlement IA énumère, comme l'identification biométrique à distance. La liste est précise, et certains usages sont filtrés comme étant à risque moindre. Un chatbot d'usage général n'est généralement pas à haut risque.
• Est-il écarté par une législation sectorielle ? Le CRA s'efface pour les produits déjà régis par leurs propres règles : dispositifs médicaux, diagnostics in vitro, véhicules à moteur homologués, aéronefs certifiés et équipements marins. Un dispositif médical IA gère sa sécurité sous les règles des dispositifs médicaux, et non sous le CRA.

Si l'une des portes échoue, le pont ne s'applique pas. C'est utile aussi : vous pouvez cesser d'essayer de réutiliser les preuves de cybersécurité CRA pour le règlement IA et planifier les deux chantiers séparément.

La réponse courte : prouvez la cybersécurité une fois

Lorsque les trois portes sont franchies, le pont accomplit le travail, sous trois conditions. Le produit satisfait aux exigences de cybersécurité du CRA, les processus du fabricant satisfont aux obligations de gestion des vulnérabilités du CRA, et la déclaration UE de conformité CRA indique le niveau de protection de cybersécurité que le règlement IA exige. Remplissez ces conditions et le produit est réputé satisfaire à l'exigence de cybersécurité du règlement IA. Vous construisez les preuves de sécurité une fois pour le CRA, et elles valent aussi pour le règlement IA.

Cette dernière condition compte. La présomption n'est pas automatique. Elle repose sur une déclaration qui indique réellement le niveau de protection, et non sur une case cochée.

Ce que le pont ne couvre pas

Le pont transporte la cybersécurité et rien d'autre. Le règlement IA exige aussi la précision et la robustesse, et le CRA n'y contribue pas. Il n'aborde pas non plus les obligations plus larges liées aux systèmes d'IA à haut risque : données et gouvernance des données, tenue de registres et journalisation, surveillance humaine, et information claire pour les personnes qui utilisent le système. Si vous avez déjà traité le CRA, cette liste représente ce qui reste pour le règlement IA. Planifiez le travail lié au règlement IA autour de ces points, pas autour de la répétition des travaux de sécurité achevés pour le CRA.

Trois frontières méritent d'être fixées. Un certificat européen de cybersécurité peut aussi satisfaire à l'exigence de cybersécurité du règlement IA, dans la mesure où il la couvre, ce qui en fait une deuxième voie vers le même objectif. Un modèle d'IA à usage général pris isolément n'est pas dans la zone de chevauchement, mais un produit, une application ou un dispositif construit sur ce modèle peut tout de même être un produit CRA s'il satisfait au test du champ d'application. Et si votre IA est intégrée dans une machine, surveillez cette interface : le Digital Omnibus acheminerait les règles de santé et de sécurité IA pour les machines via le règlement sur les machines, avec des actes délégués attendus au plus tard le 2 août 2028.

Quels éléments probants passent d'un régime à l'autre

Le pont porte sur la réutilisation. Voici ce que vous construisez pour le CRA et ce à quoi cela répond du côté du règlement IA.

La troisième ligne est celle que les équipes manquent le plus souvent. L'évaluation des risques CRA doit prendre en compte les attaques qui ciblent le modèle lui-même, et pas seulement le logiciel qui l'entoure. L'empoisonnement des données cible les données d'entraînement, et les entrées adversariales ciblent ce que le modèle perçoit au moment de l'exécution : les deux appartiennent donc à la même évaluation. Ce même travail est ce que l'exigence de cybersécurité du règlement IA attend, ce qui permet de traiter les deux en une seule fois.

Une évaluation, un dossier technique, un marquage CE

Pour la plupart des produits dans la zone de chevauchement, vous réalisez une seule évaluation de la conformité selon la voie du règlement IA, et un organisme notifié qui évalue le système d'IA peut couvrir la vérification de cybersécurité CRA en même temps, à condition qu'il soit compétent sur le volet CRA. Vous maintenez un seul ensemble de documentation technique qui sert les deux textes, et le produit fini porte un seul marquage CE. Le règlement IA est conçu pour cela : vous établissez une seule déclaration UE de conformité couvrant chaque loi applicable, et l'unique marquage CE signale que vous satisfaites aussi à cet autre texte.

Deux points modifient ce tableau. Les produits CRA importants et critiques conservent la voie d'évaluation propre au CRA pour la partie sécurité lorsque le règlement IA autoriserait par ailleurs une auto-évaluation du système d'IA, ce qui maintient un organisme notifié compétent en matière de CRA dans la boucle. Et la voie à évaluation unique couvre la cybersécurité, pas le reste du règlement IA. Voir les voies d'évaluation de la conformité pour le volet CRA.

Ce que le CRA continue d'exiger en propre

Le pont fonctionne dans un sens et ne couvre que la sécurité. Vos obligations CRA ne diminuent pas parce que le produit est aussi de l'IA. Pour le produit, vous devez toujours assurer :

• un inventaire logiciel et un registre des composants qu'il contient
• la gestion et le signalement des vulnérabilités, y compris l'alerte précoce de 24 heures pour les failles activement exploitées
• une période d'assistance définie avec mises à jour de sécurité
• une configuration sécurisée par défaut et les autres propriétés produit CRA

Le règlement IA ajoute une instruction que le CRA ne précise pas en propre. Votre évaluation des risques de sécurité doit couvrir les attaques propres à l'IA, telles que l'empoisonnement des données et les entrées adversariales. La réutilisation de ce travail ne vous dispense pas de les traiter. Il s'agit de les intégrer dans le même travail d'évaluation des risques.

Deux obligations de signalement, pas une

Le pont réutilise vos preuves de sécurité. Il ne fusionne pas le signalement des incidents. Un produit dans la zone de chevauchement peut porter deux obligations de signalement distinctes qui ne se fondent pas l'une dans l'autre. Une note de vocabulaire : le CRA vous appelle fabricant et le règlement IA vous appelle fournisseur. Pour un produit que vous construisez et vendez sous votre propre nom, c'est la même entreprise, pas deux parties.

• L'obligation CRA. Vous signalez une vulnérabilité activement exploitée ou un incident de sécurité grave à votre CSIRT coordinateur et à l'ENISA, via la plateforme unique de signalement. Le délai est court : une alerte précoce de 24 heures, une mise à jour sous 72 heures, puis un rapport final.
• L'obligation du règlement IA. Le fournisseur signale un incident grave, comme une atteinte grave à la santé, une violation de droits fondamentaux ou une perturbation grave d'infrastructures critiques, à l'autorité de surveillance du marché du lieu où il s'est produit. Le délai court jusqu'à 15 jours, et aussi vite que 2 jours pour les cas les plus graves.

Les déclencheurs se recoupent à peine. Le signalement CRA porte sur la sécurité du produit. Le signalement du règlement IA porte sur les atteintes à la sécurité des personnes et aux droits. Un même événement peut déclencher les deux, donc acheminez chaque type d'incident vers le bon canal avant qu'un problème ne survienne. Le règlement IA réduit les doublons de signalement dans un cas : pour un système à haut risque autonome dont le fournisseur est déjà soumis à un signalement équivalent au titre d'une autre législation de l'Union, le signalement au titre du règlement IA se réduit aux incidents liés aux droits fondamentaux.

Les équipes construisent couramment le signalement CRA de 24 heures et considèrent que le volet règlement IA est couvert. Ce n'est pas le cas. Le signalement d'incident grave à l'autorité de surveillance du marché est un travail distinct, qui nécessite son propre responsable et son propre plan de réponse.

Si votre organisation est aussi une entité essentielle ou importante au titre de NIS2, cela ajoute un troisième canal de signalement au niveau de l'entreprise, pas du produit. Voir comment le CRA et NIS2 se chevauchent pour ce volet.

Comment les échéances s'articulent

Un point de calendrier mérite un suivi attentif. La date initiale du règlement IA pour les systèmes à haut risque intégrés à des produits était le 2 août 2027. Le Digital Omnibus sur l'IA déplacerait les systèmes à haut risque autonomes au 2 décembre 2027 et ceux intégrés à des produits au 2 août 2028. Les co-législateurs ont acté ce changement le 7 mai 2026, et le Parlement européen l'a approuvé le 16 juin 2026. Au 24 juin 2026, ce n'est pas encore du droit contraignant. Il doit encore faire l'objet d'une adoption par le Conseil et d'une publication au Journal officiel. Les orientations de la Commission sur la classification à haut risque sont également encore en projet, avec des lignes directrices définitives attendues d'ici fin 2026. Traitez les nouvelles dates comme l'issue probable, pas comme du droit établi.

Pour un produit dans la zone de chevauchement, le CRA entre en vigueur en premier, avec le signalement à partir de septembre 2026 et l'application complète en décembre 2027. Les obligations à haut risque du règlement IA s'appliquent aux alentours de décembre 2027 pour les systèmes autonomes et en août 2028 pour les systèmes intégrés à des produits, selon le calendrier proposé.

Points de vigilance

Quelques éléments modifient la version simple de ce tableau.

• La présomption est conditionnelle. Elle ne tient que si votre déclaration UE de conformité CRA indique réellement le niveau de protection de cybersécurité du règlement IA. Une déclaration trop succincte rompt le pont.
• Les produits importants et critiques sont différents. Lorsque le règlement IA leur permettrait par ailleurs une auto-évaluation, la voie d'évaluation propre au CRA régit la partie sécurité, ce qui maintient un organisme notifié CRA dans la boucle.
• Une seule autorité de surveillance du marché. Pour un produit dans la zone de chevauchement, l'autorité qui supervise votre système d'IA supervise aussi le volet CRA, et elle travaille avec les CSIRT et l'ENISA sur le signalement CRA.
• Le pont ne couvre que la sécurité. Il ne fait rien pour la précision, la robustesse, la gouvernance des données, la journalisation ou la surveillance humaine. Prévoyez ces éléments comme du travail distinct au titre du règlement IA.
• Les dates ne sont pas arrêtées. Les dates à haut risque de 2027 et 2028 sont en attente d'adoption par le Conseil du Digital Omnibus.
• Les machines ont leur propre voie. Les machines à capacités IA s'orientent vers le règlement sur les machines pour leurs règles de santé et de sécurité IA.

Notre point de vue

Le pont est réel et utile, mais traitez « évalué une fois » comme un objectif de planification, pas comme une garantie. Le gain est la réutilisation des preuves. Construisez un dossier de sécurité CRA solide et un seul ensemble de documentation technique, puis orientez les deux régimes vers ce dossier.

Le piège que nous observons est celui des équipes qui lisent le pont comme signifiant que « la case sécurité du règlement IA est cochée » et qui omettent le travail sur les menaces propres à l'IA que l'évaluation CRA doit encore couvrir. L'empoisonnement des données et les entrées adversariales sont là où un produit IA est réellement vulnérable, et c'est ce que les deux textes attendent que vous traitiez.

Notre conseil est simple. Délimitez d'abord le produit, construisez le dossier de sécurité CRA à un niveau élevé, rédigez une déclaration qui indique le niveau de protection, et réalisez les travaux sur la précision, la robustesse et la surveillance du règlement IA sur une piste distincte. En procédant ainsi, le chevauchement vous épargne une vraie duplication. Lisez-le comme un raccourci et il se retourne contre vous à l'évaluation.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié.