Réglementation IA et Cybersécurité : Guide Complet pour

La réglementation IA et cybersécurité en 2026 ressemble à un chantier ouvert sur plusieurs fronts simultanément. Les directions juridiques et les RSSI doivent désormais maîtriser des cadres qui se superposent, interagissent et parfois se contredisent : l'AI Act (Règlement UE 2024/1689, entré en vigueur août 2024), DORA (Règlement UE 2022/2554, applicable depuis janvier 2025 pour le secteur financier), la directive NIS2 (2022/2555, dont la transposition française accuse du retard), le RGPD qui existait déjà mais dont l'article 22 sur les décisions automatisées prend une nouvelle dimension avec les LLMs, et le Cyber Resilience Act (CRA), adopté en octobre 2024, qui impose des exigences cybersécurité sur les produits contenant des composants numériques. L'texte complet de l'AI Act est disponible sur EUR-Lex. Selon une étude de l'ENISA Threat Landscape 2024, les systèmes IA sont devenus une surface d'attaque prioritaire pour les acteurs malveillants, ce qui renforce l'argument réglementaire. La bonne nouvelle : naviguer dans ce millefeuille est possible si l'on comprend qui est concerné par quoi et dans quel ordre de priorité agir.

L'AI Act : qui est concerné et depuis quand ?

L'AI Act s'applique à toute organisation qui place sur le marché européen, met en service ou utilise des systèmes d'IA, quel que soit le pays d'établissement du développeur. Une startup californienne qui vend un outil IA de recrutement à une entreprise française est soumise à l'AI Act. L'entreprise française qui déploie cet outil l'est aussi — en tant que déployeur.

Le calendrier d'application est progressif mais inexorable. Les pratiques d'IA interdites (Art. 5 : manipulation psychologique, scoring social, scraping biométrique) sont prohibées depuis le 2 février 2025. Les obligations sur les modèles d'IA à usage général (GPAI) — y compris les LLMs comme GPT-4o, Claude, Gemini, Llama — s'appliquent depuis août 2025. Les obligations pour les systèmes à haut risque (Annexe III) s'appliquent depuis le 2 août 2026 pour les nouvelles mises sur le marché et auront une période de transition jusqu'en 2027 pour les systèmes existants.

Qui sont les acteurs de la chaîne de valeur ? Les fournisseurs (développeurs du système IA), les déployeurs (organisations qui utilisent le système IA dans un contexte professionnel), les importateurs et les distributeurs. Les obligations varient selon le rôle. En pratique, la plupart des entreprises sont des déployeurs — elles utilisent des LLMs ou des outils IA développés par des tiers dans leurs processus métier. Les obligations des déployeurs de systèmes HR incluent : assurer une supervision humaine effective, garantir que les utilisateurs sont informés de l'utilisation d'un système IA, mettre en place une gestion des risques, et tenir un registre de surveillance post-marché.

Voyons sur l'guide de conformité AI Act pour les systèmes à haut risque comment appliquer ces obligations concrètement.

DORA : quelles obligations pour le secteur financier en 2026 ?

DORA — le Digital Operational Resilience Act — est pleinement applicable depuis janvier 2025. Les premiers contrôles de l'ACPR et de l'AMF sont en cours. Le bilan DORA 2026 montre que les institutions financières françaises sont en retard sur plusieurs points, notamment la cartographie des prestataires ICT critiques et les tests de résilience.

Pour les outils IA dans le secteur financier, DORA crée un cadre spécifique via son cadre de gestion des risques ICT (Art. 4-6). Tout système IA utilisé dans un processus métier critique — détection de fraude, scoring de crédit, gestion de portefeuille, gestion des risques opérationnels — doit être cartographié, soumis à une analyse de risque et couvert par des plans de continuité.

Les prestataires de services ICT tiers fournissant des outils IA aux entités financières doivent également se conformer à DORA — notamment les hyperscalers (Azure OpenAI Service, Google Vertex AI, AWS Bedrock) qui sont désignés comme prestataires critiques potentiels. Les contrats avec ces prestataires doivent inclure des clauses spécifiques sur la résilience, les droits d'audit et les niveaux de service.

Le calendrier DORA 2026 comprend des tests de résilience opérationnelle numérique avancés (TLPT — Threat Led Penetration Testing) pour les entités d'importance significative. Ces tests, basés sur TIBER-EU, doivent couvrir les systèmes critiques y compris les agents IA. L'IA générative dans les processus de détection de fraude est un cas d'usage particulièrement scruté.

NIS2 : un périmètre élargi, une transposition française en retard

NIS2 concerne 18 secteurs d'activité — soit un périmètre trois fois plus large que NIS1. La transposition en droit français accuse du retard (le délai officiel était octobre 2024), mais le projet de loi est en cours de finalisation au moment de la rédaction de cet article. L'ANSSI a cependant publié ses orientations et les entreprises concernées sont invitées à se préparer dès maintenant.

Les entités essentielles (grande taille dans les secteurs prioritaires) et les entités importantes (taille intermédiaire ou dans des secteurs secondaires) ont des obligations différenciées. Les mesures imposées par l'article 21 couvrent dix domaines : politique de sécurité et analyse de risque, gestion des incidents, continuité d'activité, sécurité de la chaîne d'approvisionnement, sécurité des réseaux et systèmes, politiques de contrôle d'accès, chiffrement, ressources humaines, authentification multi-facteur, et communication sécurisée. Pour les systèmes IA qui participent à ces processus, les exigences NIS2 s'appliquent de plein droit.

Consultez le guide complet sur la directive NIS2 pour les obligations détaillées par secteur.

La question de la notification d'incidents impliquant des systèmes IA est particulièrement sensible. Si un agent IA prend une décision incorrecte qui entraîne une interruption de service significative, cela peut déclencher l'obligation de notification à l'ANSSI sous 24 heures (alerte précoce), 72 heures (notification d'incident) et un mois (rapport final). Les procédures de réponse aux incidents doivent être adaptées pour couvrir ce scénario.

RGPD et IA : les interactions critiques en 2026

Le RGPD n'est pas nouveau, mais son application aux systèmes IA prend une nouvelle dimension avec la prolifération des LLMs. Trois articles méritent une attention particulière.

L'article 22 sur les décisions automatisées est le plus cité. Il interdit les décisions fondées uniquement sur un traitement automatisé produisant des effets juridiques ou affectant significativement une personne. Pour les agents IA décisionnels, trois exceptions permettent ce traitement : le consentement explicite de la personne, la nécessité contractuelle, ou une autorisation légale. Dans tous les cas, la personne doit avoir le droit d'obtenir une intervention humaine, d'exprimer son point de vue et de contester la décision. Ces droits doivent être concrètement accessibles — pas juste mentionnés dans les CGU. Voir les obligations RGPD 2026 et les contrôles CNIL pour les dernières orientations.

L'article 25 (Privacy by Design) impose que les systèmes IA soient conçus dès le départ avec des mesures de protection des données. Pour les déployeurs, cela signifie que le choix d'un LLM externe doit intégrer la question de la résidence des données et des garanties de confidentialité — et que l'on ne peut pas corriger les problèmes de confidentialité a posteriori sur un système déjà déployé.

L'article 35 (DPIA) impose une analyse d'impact avant tout traitement susceptible d'engendrer un risque élevé. La liste indicative inclut explicitement l'évaluation systématique de personnes, le traitement à grande échelle de données sensibles et le recours à de nouvelles technologies. Les systèmes IA cochent souvent plusieurs de ces cases simultanément.

Le Cyber Resilience Act (CRA) : ce qui arrive en 2027

Le CRA, adopté en octobre 2024 et progressivement applicable jusqu'en 2027, impose des exigences de cybersécurité sur les produits contenant des composants numériques. Concrètement, cela couvre les appareils IoT, les logiciels, le firmware — et tout produit intégrant de l'IA.

Les obligations CRA incluent la sécurité dès la conception (security by design), un processus de gestion des vulnérabilités pendant toute la durée de vie du produit, une documentation technique, une déclaration de conformité CE, et une obligation de signalement des vulnérabilités activement exploitées sous 24 heures et des incidents sous 72 heures à l'ENISA et à l'autorité nationale. Pour les éditeurs de logiciels français qui intègrent des fonctionnalités IA dans leurs produits, c'est un chantier de conformité majeur.

Les catégories de produits à risque important (Annexe I CRA) incluent les systèmes d'exploitation, les hyperviseurs, les VPN, les gestionnaires de mots de passe, les microprocesseurs — et potentiellement les systèmes IA embarqués dans ces catégories. Les systèmes IA dans les équipements critiques (dispositifs médicaux, véhicules, automatismes industriels) se retrouvent à la confluence CRA, AI Act et directives sectorielles.

Guide pratique par type d'entreprise

Calendrier de mise en conformité 2025-2027

Voici comment j'organiserais la mise en conformité si j'accompagnais une organisation à partir de juillet 2026. L'ordre de priorité dépend du profil de risque — secteur financier, opérateur NIS2 ou autres — mais cette progression logique s'applique à la majorité des cas.

T3 2026 (immédiat) : Inventaire des outils IA déployés. Classification de risque AI Act pour les systèmes identifiés. Vérification des usages à risque élevé déjà en production. Politique d'usage IA formelle si elle n'existe pas. Revue des contrats fournisseurs IA pour inclure les clauses réglementaires.

T4 2026 : Pour les systèmes HR identifiés — constitution de la documentation technique Art. 11. Mise en place ou formalisation de la supervision humaine. Revue des DPIA existantes pour y intégrer les systèmes IA. Formation des équipes concernées (notamment les DPO, RSSI, et équipes IT qui déploient les outils IA).

T1 2027 : Pour les entités financières sous DORA — premiers TLPT si entité d'importance significative. Revue du registre des tiers ICT pour inclure les fournisseurs d'IA. Pour tous — préparation aux premières inspections AI Act attendues courant 2027. Mise en place du registre de surveillance post-marché pour les systèmes HR en production.

T2-T4 2027 : Mise en conformité CRA pour les éditeurs de logiciels. Revue annuelle de la politique IA. Adaptation aux premières jurisprudences AI Act qui commenceront à émerger des décisions d'autorités nationales.

Les interactions entre les cadres : comment éviter le double emploi ?

La bonne nouvelle dans ce millefeuille réglementaire : les cadres partagent des fondations communes qu'on peut mutualiser. La cartographie des actifs (systèmes IA, données traitées, tiers impliqués) sert à la fois l'AI Act, DORA, NIS2 et le RGPD. Le registre des traitements RGPD peut être étendu pour couvrir les systèmes IA et servir de base au registre de surveillance post-marché AI Act. L'analyse de risque ISO 27001 / NIS2 peut intégrer les dimensions spécifiques de l'AI Act (biais, explicabilité, robustesse).

La tentation d'avoir des silos séparés — un projet AI Act, un projet DORA, un projet NIS2 — est coûteuse et contre-productive. L'approche intégrée, portée par le RSSI avec support du DPO et de la direction juridique, permet de réutiliser les livrables communs et d'éviter les incohérences entre politiques.

Questions fréquentes

L'AI Act s'applique-t-il aux organisations qui n'utilisent que des LLMs grand public ?

Oui, si ces LLMs sont utilisés dans des processus qui tombent dans les catégories à haut risque de l'Annexe III. Utiliser ChatGPT pour filtrer des CV ou aider à noter des salariés est un usage HR à haut risque selon l'AI Act, même si OpenAI est le fournisseur du modèle. L'organisation qui déploie cet usage est le déployeur au sens réglementaire et supporte les obligations correspondantes.

Quand la transposition française de NIS2 sera-t-elle effective ?

Le calendrier est incertain. La transposition aurait dû être complète en octobre 2024 — ce délai n'a pas été respecté. Le projet de loi est en cours de finalisation. L'ANSSI recommande aux organisations concernées de se préparer sans attendre la transposition, en s'appuyant sur la directive européenne directement applicable dans ses grandes lignes. La transposition devrait intervenir courant 2026.

Les systèmes IA développés avant l'AI Act bénéficient-ils d'une exemption ?

Partiellement. Les systèmes à haut risque mis sur le marché avant le 2 août 2026 ont une période de transition jusqu'au 2 août 2027, à condition qu'ils ne subissent pas de modifications significatives. Mais tout changement substantiel (nouveau cas d'usage, nouveau modèle sous-jacent, extension du périmètre de déploiement) peut faire tomber cette exemption et imposer une conformité immédiate.

Le CRA concerne-t-il les logiciels SaaS ?

Le CRA cible principalement les produits — logiciels packagés, appareils IoT, firmware. Les services SaaS purs (sans produit tangible associé) sont en principe hors scope du CRA. Cependant, si un éditeur SaaS fournit aussi une version on-premise ou des agents installables chez le client, ces composants entrent dans le périmètre CRA. La frontière SaaS/produit est un sujet de débat en cours de clarification au niveau européen.

Comment prouver la conformité AI Act lors d'un contrôle ?

La documentation est la clé. Un contrôleur AI Act demandera : le registre des systèmes IA déployés et leur classification de risque, la documentation technique des systèmes à haut risque (Art. 11), les preuves de supervision humaine effective, les résultats des analyses de risque, les formations dispensées aux utilisateurs, et les procédures de gestion des incidents. Sans ces documents, prouver la conformité est impossible même si les pratiques sont réellement en place.

Les premiers contrôles AI Act : ce que les autorités regarderont en priorité

Les premières inspections AI Act par les autorités nationales sont attendues courant 2027, après la désignation formelle des autorités compétentes dans chaque État membre. Il est utile d'anticiper ce que ces contrôles vont prioritairement examiner — à défaut de jurisprudence établie, on peut s'appuyer sur les pratiques des régulateurs sectoriels comme la CNIL, l'ACPR et l'ANSSI qui serviront de modèle.

Le registre des systèmes IA sera probablement le premier document demandé. Son absence ou son caractère incomplet est le signal le plus clair d'une gouvernance IA inexistante. Ce registre doit lister tous les systèmes IA utilisés dans l'organisation, leur classification de risque selon l'AI Act, leur domaine d'application, les mesures de supervision humaine en place et la documentation technique disponible. Pour les systèmes à haut risque, la documentation Art. 11 sera demandée intégralement. Les contrôles porteront aussi sur les mécanismes de supervision humaine : des journaux d'interventions, des procédures de validation documentées et des formations dispensées aux superviseurs sont les éléments de preuve attendus. Un système à haut risque sans aucune trace d'intervention humaine dans ses logs est immédiatement suspect.

La gestion des incidents liés aux systèmes IA sera également scrutée. L'AI Act impose (Art. 73) la notification des incidents graves impliquant des systèmes à haut risque aux autorités de surveillance du marché. Avez-vous une procédure de détection et de qualification des incidents IA ? Un seuil de gravité défini pour la notification ? Un registre des incidents historiques ? Ces questions doivent trouver des réponses documentées.

Construire un programme de conformité IA structuré sur 18 mois

Plutôt que de s'épuiser à courir après chaque cadre réglementaire séparément, l'approche la plus efficace est de construire un programme de conformité IA unifié qui adresse simultanément AI Act, RGPD, DORA si applicable et NIS2 si applicable, en capitalisant sur les éléments communs.

Mois 1-3 — Foundation : Constitution du groupe de travail (RSSI, DPO, DSI, Juridique, représentants métiers), inventaire complet des systèmes IA déployés et en cours de déploiement, cartographie des processus métier utilisant de l'IA, première analyse de classification AI Act pour les systèmes identifiés, et identification des lacunes les plus critiques. Le livrable de cette phase est un rapport de gap analysis qui sert de base à tout le reste.

Mois 4-6 — Gouvernance : Rédaction et validation de la politique d'usage IA, création du registre des systèmes IA, désignation d'un responsable gouvernance IA, lancement du programme de formation utilisateurs, revue des contrats fournisseurs IA. Mois 7-12 — Conformité opérationnelle : Pour les systèmes à haut risque identifiés — constitution des dossiers techniques Art. 11, formalisation des mécanismes de supervision humaine, mise en place du logging Art. 12, réalisation des DPIAs RGPD nécessaires. Pour les entités DORA — intégration des systèmes IA dans le registre ICT et les plans de continuité. Mois 13-18 — Vérification et amélioration : Audit interne du programme de conformité IA, simulation d'inspection par un tiers externe, correction des lacunes identifiées, première revue annuelle du registre.

Ressources et outils pour la mise en conformité IA

La mise en conformité réglementaire IA bénéficie d'un écosystème de ressources en développement rapide. Les guides officiels publiés par les autorités sont gratuits et font autorité : la CNIL a publié des recommandations sur l'IA générative et des guides sur les DPIAs pour les systèmes IA ; l'ANSSI a publié un guide de recommandations pour sécuriser les systèmes IA ; l'ENISA publie régulièrement des analyses sur les risques de cybersécurité liés à l'IA. Ces ressources doivent constituer la base documentaire de tout programme de conformité IA.

Les outils de self-assessment : la Commission européenne a publié un outil d'auto-évaluation pour déterminer si un système IA est à haut risque selon l'AI Act, accessible sur le portail officiel de l'AI Act. Plusieurs cabinets de conseil proposent des frameworks de conformité AI Act téléchargeables. Les normes en développement : ISO/IEC 42001 (Système de Management IA, déjà publiée) fournit un cadre de gouvernance IA complémentaire à ISO 27001 pour les organisations qui développent ou utilisent des systèmes IA. La norme ISO/IEC 23894 sur la gestion des risques IA et CEN/CENELEC JTC 21 produisent des normes harmonisées qui faciliteront la démonstration de conformité une fois publiées.

Questions à se poser avant de déployer un nouvel outil IA

Pour ancrer la gouvernance IA dans le quotidien des équipes, proposer une liste de questions à se poser systématiquement avant tout nouveau déploiement d'outil IA est plus efficace qu'un long document de politique. Ces questions peuvent être intégrées dans un formulaire de demande d'approbation ou dans une checklist pré-déploiement.

Questions sur la classification de risque : quelle est la catégorie de cet outil IA selon l'AI Act (interdit, haut risque, risque limité, risque minimal) ? L'outil traite-t-il des données personnelles ? Des décisions ayant un effet sur des personnes seront-elles prises sur la base des outputs de cet outil ? Questions sur les données : quelles données seront saisies dans cet outil ? Certaines de ces données sont-elles couvertes par les catégories interdites de la politique d'usage IA ? Où sont stockées et traitées les données par l'éditeur (résidence, transferts hors UE) ? Questions sur la supervision : qui supervisera les outputs de cet outil ? Quelle procédure de validation humaine est prévue avant utilisation des résultats ? Comment les erreurs ou hallucinations seront-elles détectées et corrigées ? La réponse documentée à ces questions constitue la base minimale d'une DPIA légère et d'une analyse de risque AI Act pour chaque nouvel outil.

Conclusion

La conformité réglementaire n'est pas une destination mais un état à maintenir. Chaque évolution du SI, chaque nouveau fournisseur peut modifier le périmètre. Documentation, audits réguliers et formation des équipes en sont les piliers.