Le Cyber Resilience Act entre dans sa phase opérationnelle. Pour les logiciels qui embarquent des modèles d'IA, les obligations de sécurité se superposent désormais à celles de l'AI Act, avec des échéances précises jusqu'en 2027.
Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, n'est pas un texte à venir : il structure déjà les feuilles de route de conformité des éditeurs logiciels. Le règlement est en vigueur depuis la fin de l'année 2024, mais ses obligations s'appliquent par étapes jusqu'à décembre 2027. Trois dates jalonnent ce calendrier : entrée en vigueur le 10 décembre 2024, puis à partir du 11 juin 2026 les règles relatives aux organismes d'évaluation de la conformité (chapitre IV, articles 35 à 51).
La deuxième échéance, souvent sous-estimée, concerne directement les éditeurs de logiciels avec ou sans IA. Depuis le 11 septembre 2026, une nouvelle obligation européenne est entrée en application : tout fabricant d'un produit comportant des éléments numériques doit signaler sous 24 heures toute vulnérabilité activement exploitée. Cette obligation de signalement ne concerne pas uniquement les nouveaux produits. Le stade de septembre 2026 couvre aussi les produits qui sont sur le marché depuis des années : selon l'article 69(3), le signalement s'applique à tous les produits dans le champ, même ceux mis sur le marché avant décembre 2027.
Les délais de notification sont serrés. Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents de sécurité graves, avec un avertissement précoce sous 24 heures à l'ENISA et au CSIRT national compétent, puis une notification complète sous 72 heures, et un rapport final une fois le correctif disponible. Pour une organisation qui n'a jamais structuré de PSIRT ou de canal de divulgation coordonnée des vulnérabilités, quatre mois ne suffisent pas, d'autant que l'obligation de signalement s'applique dès septembre 2026 indépendamment de la pleine application du règlement en décembre 2027.
La troisième date clôt le dispositif. La pleine application, incluant les exigences essentielles et le marquage CE, s'applique à compter du 11 décembre 2027. À partir de cette date, les produits placés sur le marché avant le 11 décembre 2027 ne sont pas rétroactivement soumis aux exigences principales du CRA, sauf exceptions prévues par le texte, ce qui crée une fenêtre de mise en conformité pour les produits déjà commercialisés.
Le périmètre du CRA est large. Les obligations s'appliquent à un large éventail d'acteurs, notamment les fabricants de hardware et de logiciels, les représentants autorisés au sein de l'UE, les importateurs et les distributeurs, ainsi que les développeurs d'applications, de SDK et de systèmes d'exploitation, et les start-ups qui développent des appareils intelligents ou des outils numériques. Les outils d'intelligence artificielle n'échappent pas à la règle. Dès lors qu'un outil d'intelligence artificielle constitue un produit logiciel comportant des éléments numériques commercialisé dans l'Union européenne, il entre dans le champ d'application du texte selon les mêmes principes de sécurité par conception et de gestion des vulnérabilités que les autres catégories de produits numériques.
Concrètement, cela signifie que les entreprises qui achètent des solutions SaaS ou des assistants d'IA héritent d'une partie du risque de leurs fournisseurs. Une entreprise qui déploie un outil logiciel, qu'il s'agisse d'un ERP, d'une solution de gestion RH ou d'un assistant IA de réunion, hérite en partie du niveau de sécurité de ses fournisseurs. Cette dépendance aux tiers impose de cartographier précisément la chaîne logicielle : l'analyse doit distinguer les actifs exploités directement de ceux fournis par des tiers, car un outil SaaS peut reposer sur un hébergeur, un fournisseur de modèles d'intelligence artificielle, une passerelle de paiement, un service d'envoi d'e-mails et de nombreuses bibliothèques externes.
Le cœur technique du CRA réside dans son annexe I. La partie I comporte une exigence chapeau, la sécurité appropriée au risque, puis 13 exigences détaillées. Le point 1 impose que les produits soient conçus, développés et fabriqués de manière à garantir un niveau approprié de cybersécurité en fonction des risques, sans aucune clause de non-applicabilité : il n'existe pas de produit dispensé de cette exigence.
Pour un produit logiciel intégrant un modèle d'IA, ces exigences prennent une coloration spécifique. Le CRA impose des exigences de cybersécurité qui s'appliquent intégralement aux produits IA : sécurité dès la conception, protection contre les accès non autorisés, protection des données, mises à jour de sécurité, gestion des vulnérabilités, et configuration sécurisée par défaut. Mais l'application à l'IA ne se limite pas à une transposition mécanique. La sécurité dès la conception doit intégrer la protection du modèle d'IA contre les attaques adversariales : empoisonnement des données, évasion, extraction de modèle. La protection des données couvre les données d'entraînement, les données d'inférence et les paramètres du modèle. La gestion des vulnérabilités doit inclure les vulnérabilités spécifiques aux systèmes d'IA.
Un cabinet d'avocats spécialisé souligne que cette exigence élargie distingue nettement les produits à IA des autres produits numériques : le fabricant doit structurer son analyse de manière à identifier non seulement les vulnérabilités techniques classiques (failles logicielles, défauts de configuration, absence de chiffrement), mais également les vulnérabilités spécifiques aux algorithmes d'apprentissage automatique et aux modèles d'IA embarqués. L'évaluation des risques doit aller plus loin que la cybersécurité traditionnelle : elle doit notamment intégrer les risques pour la cyberrésilience du système d'IA en cas de tentatives par des tiers non autorisés de modifier son utilisation, son comportement ou ses performances.
Sur le plan documentaire, la nomenclature logicielle devient un pilier incontournable. La documentation doit notamment couvrir l'analyse de risques et ses justifications, la nomenclature logicielle (SBOM), les plans de mise à jour, l'historique de gestion des vulnérabilités ainsi que la déclaration de conformité. Pour les produits à IA, cette nomenclature doit intégrer les composants spécifiques au pipeline d'apprentissage : jeux de données, bibliothèques de machine learning, poids de modèles tiers.
Les équipes qui pilotent des produits intégrant des systèmes d'IA à haut risque au sens de l'AI Act font face à une double conformité réglementaire. Lorsqu'un produit numérique incorpore un système d'intelligence artificielle qualifié comme étant à haut risque au sens de l'article 6 du RIA, il relève simultanément des exigences de cybersécurité du CRA et des obligations de l'AI Act, une convergence dont les modalités précises sont définies par l'article 12 et le considérant 51 du CRA.
Le législateur a toutefois prévu un mécanisme pour éviter la duplication des démonstrations de conformité. L'article 12 du CRA établit le principe selon lequel les produits comportant des éléments numériques classés comme systèmes d'IA à haut risque conformément à l'article 6 du RIA sont réputés conformes aux exigences de cybersécurité énoncées à l'article 15 du RIA lorsque trois conditions cumulatives sont remplies. Ces conditions portent sur le respect des exigences essentielles de l'annexe I : les produits doivent satisfaire aux exigences essentielles de cybersécurité énoncées à l'annexe I, partie I, du CRA, qui détaille les caractéristiques techniques que doivent présenter les produits en matière de sécurité dès la conception, de minimisation de la surface d'attaque, de protection contre les accès non autorisés, de confidentialité, d'intégrité et de disponibilité des données. Elles portent également sur les processus : les processus mis en place par le fabricant doivent être conformes aux exigences essentielles énoncées à l'annexe I, partie II, du CRA, qui vise les obligations processuelles tout au long du cycle de vie du produit, notamment en matière de gestion des vulnérabilités, de fourniture de mises à jour de sécurité, et de traitement des incidents.
Concrètement, ce mécanisme de présomption de conformité évite aux équipes d'avoir à constituer deux dossiers techniques distincts. Si l'entreprise respecte l'annexe I parties I et II du CRA et le déclare dans sa déclaration UE de conformité, elle est présumée satisfaire aux exigences de cybersécurité de l'article 15 de l'AI Act, sans démonstration de conformité distincte : un seul dossier technique, un seul jeu de preuves, une seule déclaration couvrant la cybersécurité pour les deux régimes. Un système de gestion des risques unique peut d'ailleurs être mis en place : le CRA et l'AI Act imposent tous deux un système de gestion des risques, et pour les produits IA, un système unique peut couvrir simultanément les risques de cybersécurité et les risques liés à la sécurité fonctionnelle du modèle.
Les catégories de produits les plus directement exposées à cette double conformité ne manquent pas dans le monde professionnel. Les catégories les plus fréquemment concernées incluent les systèmes de surveillance et de détection d'intrusion utilisant du machine learning, les dispositifs IoT équipés d'assistants vocaux ou de systèmes de reconnaissance, les logiciels de cybersécurité intégrant de l'IA, les équipements domotiques et industriels connectés, et les robots industriels et collaboratifs.
Les équipes qui construisent ou achètent des logiciels à composant IA ont intérêt à traiter la mise en conformité comme un chantier transverse, et non comme une simple case juridique à cocher. La cartographie des produits et des responsabilités est la première étape : identifier, pour chaque brique logicielle, le niveau de dépendance à des tiers, qu'il s'agisse d'un fournisseur de modèle de fondation, d'un hébergeur ou d'une bibliothèque open source. Sur ce dernier point, la responsabilité reste clairement positionnée sur l'éditeur commercial : les fabricants de produits commerciaux conservent l'entière responsabilité de fabricant pour les composants open source intégrés ; les mainteneurs en amont ne portent pas cette responsabilité.
Deuxième priorité : outiller la gestion du cycle de vie des vulnérabilités avant l'échéance de signalement. Les organisations sont invitées à exploiter les boîtes à outils et les modèles existants pour les piliers de la conformité, tels que la nomenclature logicielle, le développement sécurisé et la gestion des vulnérabilités, l'ENISA et les autorités nationales devant mettre à disposition des orientations officielles, des modèles et des listes de contrôle.
Troisième priorité, spécifique aux produits à IA : documenter les menaces propres aux modèles dans l'analyse de risques (TARA). Cela suppose de formaliser des scénarios d'empoisonnement de données d'entraînement, d'extraction de modèle ou d'attaques adversariales, et de les intégrer au même dossier technique que l'analyse de risques classique exigée par le CRA, plutôt que de produire une documentation parallèle propre à l'IA.
Enfin, l'absence de normes harmonisées stabilisées complique encore l'exercice pour les équipes qui veulent sécuriser leur conformité par la présomption prévue à l'article 27 du CRA. Aucune norme harmonisée CRA n'est encore citée au Journal officiel de l'Union européenne : la présomption de conformité de l'article 27 est indisponible, et la charge de la démonstration repose entièrement sur l'analyse de risque de l'entreprise elle-même. Dans ce contexte, structurer en interne une documentation robuste, alignée sur l'annexe I et capable de démontrer une approche méthodique du risque, devient le meilleur levier de conformité disponible dès aujourd'hui.
Pour les organisations qui pilotent plusieurs produits ou services embarquant de l'IA, l'enjeu dépasse la seule conformité réglementaire : il s'agit de bâtir une gouvernance data et sécurité cohérente, intégrée dès la conception des systèmes. C'est un chantier que les équipes accompagnement et formation de Dataistudio traitent avec les directions data et sécurité, en lien avec les équipes juridiques, pour transformer ces obligations en processus opérationnels durables plutôt qu'en exercice ponctuel de mise en conformité.
Le calendrier du CRA ne laisse plus de place à l'attentisme : l'obligation de signalement des vulnérabilités est effective depuis septembre 2026, et l'échéance de décembre 2027 pour la pleine application approche rapidement. Pour les logiciels à composant IA, la difficulté n'est pas seulement de respecter un texte supplémentaire, mais d'articuler deux cadres réglementaires, CRA et AI Act, dont la cohérence technique repose sur une documentation unique et une analyse de risque qui couvre explicitement les vulnérabilités propres aux modèles d'intelligence artificielle. Les organisations qui structurent dès maintenant leur gestion des vulnérabilités, leur SBOM et leur analyse de risque IA aborderont les prochaines échéances sans précipitation. Pour approfondir les implications sectorielles de cette réglementation, consultez notre page secteurs.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus