AI Act : cadre européen de l'intelligence artificielle — AI Act — comprendre et appliquer le règlement européen sur l'IA

Table des matières

Pourquoi ce règlement existe

L'AI Act (règlement UE 2024/1689) n'est pas un texte sur l'éthique de l'intelligence artificielle au sens abstrait. C'est un règlement de marché intérieur, au même titre que ceux qui encadrent les dispositifs médicaux ou les jouets pour enfants. Son objectif premier est de fixer des conditions harmonisées pour la mise sur le marché et la mise en service de systèmes d'IA dans l'Union européenne, afin d'éviter que chaque État membre légifère séparément et fragmente le marché.

Cette origine explique la structure du texte : au lieu d'interdire ou d'autoriser l'IA en bloc, il classe les usages selon leur potentiel de nuisance et gradue les obligations en conséquence. Un système de recommandation de contenu et un système utilisé pour trier des candidatures à l'embauche ne portent pas le même niveau de risque pour les personnes concernées — ils ne sont donc pas soumis aux mêmes contraintes.

L'AI Act s'applique en fonction de l'usage du système, pas de sa technologie. Un même modèle de langage peut être un système à risque minimal dans un cas (assistant de rédaction générique) et un système à haut risque dans un autre (évaluation de dossiers de crédit). Le classement se fait au cas par cas, à l'échelle du cas d'usage déployé.

Le calendrier d'application

Le règlement est entré en vigueur le 1er août 2024, mais son application est échelonnée sur plusieurs années — un point souvent mal compris, qui conduit certaines organisations à croire que "l'AI Act n'est pas encore applicable" alors que des obligations sont déjà en vigueur.

Pyramide des niveaux de risque de l'AI Act et calendrier d'application — La pyramide des risques structure les obligations ; le calendrier en étale l'entrée en vigueur jusqu'en 2027.

Les jalons principaux :

1er août 2024 — entrée en vigueur du règlement.
2 février 2025 — interdiction des pratiques d'IA jugées inacceptables (notation sociale généralisée, manipulation subliminale, certains usages de reconnaissance des émotions au travail, etc.) et obligations de culture générale en IA pour le personnel qui utilise ou développe ces systèmes.
2 août 2025 — règles de gouvernance, désignation des autorités nationales compétentes, et obligations spécifiques aux modèles d'IA à usage général (dont les grands modèles de langage).
2 août 2026 — application de la majorité des obligations relatives aux systèmes à haut risque listés en annexe III (RH, éducation, accès aux services essentiels, application de la loi, etc.).
2 août 2027 — application des obligations pour les systèmes à haut risque intégrés dans des produits déjà couverts par une réglementation sectorielle (dispositifs médicaux, machines, jouets, ascenseurs).

Attendre 2026 pour commencer la mise en conformité est une erreur de calendrier fréquente. Les obligations de documentation, de gouvernance des données et de traçabilité prennent plusieurs mois à mettre en place correctement. Une entreprise qui démarre son inventaire de systèmes d'IA en 2026 arrive structurellement en retard.

L'approche par les risques

Le règlement distingue quatre niveaux, illustrés par la pyramide ci-dessus :

Risque inacceptable — pratiques interdites sans exception : notation sociale par les autorités publiques, exploitation de vulnérabilités d'un groupe de personnes, manipulation comportementale subliminale, certains usages de la reconnaissance faciale en temps réel dans l'espace public.
Haut risque — systèmes listés en annexe III (recrutement, notation de crédit, éducation, gestion des infrastructures critiques, application de la loi, migration) ou intégrés dans des produits déjà soumis à évaluation de conformité (annexe I). Ces systèmes doivent répondre à un ensemble d'exigences avant mise sur le marché : gestion des risques, gouvernance des données d'entraînement, documentation technique, journalisation, supervision humaine, robustesse et cybersécurité.
Risque limité — obligations de transparence : informer les utilisateurs qu'ils interagissent avec une IA (chatbot), signaler qu'un contenu est généré ou manipulé artificiellement (deepfake).
Risque minimal — la grande majorité des systèmes d'IA actuellement déployés (filtres anti-spam, IA dans les jeux vidéo, outils de gestion de stock). Aucune obligation spécifique, sinon les codes de conduite volontaires encouragés par le texte.

Un système de tri automatisé de CV utilisé par une entreprise de 300 salariés relève de l'annexe III (accès à l'emploi) : c'est un système à haut risque. La même entreprise qui utilise un chatbot pour répondre aux questions fréquentes de ses clients sur son site est en revanche dans le registre "risque limité" — elle doit simplement informer l'utilisateur qu'il échange avec une IA, sans obligation de conformité lourde.

Qui porte les obligations

L'AI Act, comme le RGPD avant lui, répartit les responsabilités entre plusieurs rôles selon la chaîne de valeur :

Rôle	Définition	Exemple d'obligation
Fournisseur	Développe le système ou le fait développer, le met sur le marché sous son nom	Documentation technique, évaluation de conformité, marquage CE
Déployeur	Utilise le système dans le cadre de son activité professionnelle	Supervision humaine, information des personnes concernées, surveillance des dérives
Importateur	Met sur le marché de l'UE un système développé hors UE	Vérification de la conformité du fournisseur avant mise sur le marché
Distributeur	Met à disposition un système sans le développer ni l'importer	Vérification du marquage CE et de la documentation d'accompagnement

Cette distinction compte particulièrement pour les entreprises qui pensaient n'être que de simples "utilisatrices" d'outils d'IA achetés sur étagère. Une organisation qui déploie une solution RH intégrant un module de tri de candidatures endosse, en tant que déployeur, des obligations propres — elle ne peut pas se contenter de reporter la responsabilité sur l'éditeur du logiciel.

Le premier réflexe pratique en entreprise consiste à établir un inventaire des systèmes d'IA utilisés ou développés, puis à qualifier pour chacun le rôle occupé (fournisseur ou déployeur, parfois les deux) et le niveau de risque. Cet inventaire, souvent appelé "registre des systèmes d'IA", est le socle sur lequel repose toute démarche de conformité — il est traité en détail dans un chapitre ultérieur de cette formation.

Articulation avec le RGPD

L'AI Act ne remplace pas le RGPD, il s'y ajoute. Les deux textes se recoupent largement dès qu'un système d'IA traite des données personnelles — ce qui est le cas de la majorité des systèmes à haut risque (recrutement, crédit, santé).

Les points de recoupement les plus fréquents :

Un système d'IA à haut risque qui traite des données personnelles nécessite généralement une analyse d'impact relative à la protection des données (AIPD) au titre du RGPD, en complément de l'évaluation de conformité AI Act.
Les exigences de gouvernance des données de l'AI Act (qualité, pertinence, représentativité des jeux d'entraînement) recoupent le principe de minimisation du RGPD, sans s'y substituer.
Le droit à une explication et l'exigence de supervision humaine de l'AI Act complètent l'article 22 du RGPD sur les décisions individuelles automatisées.

Ces deux règlements ne partagent ni la même autorité de contrôle par défaut, ni le même objet : le RGPD protège les données personnelles, l'AI Act encadre la mise sur le marché de systèmes technologiques quel que soit le type de données traitées, y compris lorsqu'aucune donnée personnelle n'est en jeu (contrôle qualité industriel, par exemple).

Ce que l'AI Act ne couvre pas

Une confusion fréquente consiste à assimiler l'AI Act à un texte de cybersécurité. Ce n'est pas son objet principal. La directive NIS2, entrée en application en 2024 dans les États membres, encadre la résilience et la sécurité des réseaux et systèmes d'information pour les entités jugées essentielles ou importantes — un périmètre largement disjoint de celui de l'AI Act, même si les deux textes se croisent sur les exigences de robustesse des systèmes à haut risque.

De la même manière, l'AI Act n'est pas un référentiel de management : c'est un texte de loi contraignant, assorti de sanctions. La norme ISO/IEC 42001, elle, propose un cadre de système de management de l'IA (SMIA) sur le modèle de l'ISO 27001 pour la sécurité de l'information. Se certifier ISO 42001 n'exempte pas des obligations légales de l'AI Act, mais la démarche de management qu'elle impose — politique IA, gestion des risques, amélioration continue — recoupe largement les exigences documentaires attendues par le règlement. De nombreuses organisations s'appuient sur l'un pour structurer leur réponse à l'autre.

Sanctions et enjeu réel

Le régime de sanctions de l'AI Act est calqué sur celui du RGPD, en plus sévère sur le haut de la fourchette : jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel pour les pratiques interdites, jusqu'à 15 millions d'euros ou 3 % pour les manquements aux obligations relatives aux systèmes à haut risque et aux modèles à usage général, et des montants réduits pour la fourniture d'informations inexactes aux autorités.

Ces montants ne doivent pas éclipser l'enjeu opérationnel réel : au-delà du risque de sanction, un système à haut risque non conforme peut être retiré du marché ou voir sa mise en service suspendue par une autorité de surveillance, avec un impact direct sur l'activité qui en dépend.

Promesses marketing contre obligations réelles

Certains éditeurs de logiciels communiquent sur une conformité "AI Act ready" ou "certifié conforme" alors que le règlement ne prévoit pas de certification générale de ce type — seule une évaluation de conformité par système et par usage a un sens juridique. Une plateforme peut fournir des garanties contractuelles utiles, mais elle ne peut pas transférer à elle seule la responsabilité de conformité qui pèse sur le déployeur pour son cas d'usage spécifique.

À l'inverse, il est tentant de résumer l'AI Act à une contrainte bureaucratique déconnectée de la réalité technique. Ce n'est pas non plus exact : les exigences de documentation, de traçabilité et de supervision humaine recoupent des pratiques d'ingénierie déjà recommandées pour tout système critique, indépendamment du droit applicable.

Autorités compétentes et mise en œuvre nationale

Chaque État membre désigne une ou plusieurs autorités nationales compétentes chargées de la surveillance du marché et, le cas échéant, de l'évaluation de conformité pour les systèmes à haut risque qui l'exigent. En France, cette architecture s'appuie notamment sur la CNIL pour les aspects liés aux données personnelles et sur des autorités sectorielles selon le domaine concerné (santé, finance, transport). Au niveau européen, le Bureau de l'IA (AI Office), rattaché à la Commission, coordonne l'application des règles relatives aux modèles à usage général et facilite la cohérence entre les autorités nationales.

Cette architecture à double niveau — national pour la plupart des systèmes à haut risque, européen pour les modèles à usage général les plus puissants — a une conséquence pratique directe : une organisation qui déploie un système à haut risque doit identifier l'autorité nationale compétente pour son secteur d'activité, qui n'est pas nécessairement la même que celle qui traite ses obligations RGPD.

Checklist de premier repérage

Avant d'entrer dans le détail technique des chapitres suivants, une organisation peut se positionner rapidement à l'aide de quelques questions simples :

Utilisons-nous, en interne ou via un prestataire, un système automatisé qui influence une décision concernant des personnes (recrutement, crédit, accès à un service, évaluation) ?
Ce système interagit-il directement avec des utilisateurs finaux sans que ceux-ci soient informés qu'il s'agit d'une IA ?
Développons-nous un système d'IA que nous mettons ensuite à disposition d'un tiers, sous notre nom ou notre marque ?
Avons-nous un inventaire à jour des systèmes d'IA utilisés dans l'organisation, avec leur finalité et leur fournisseur ?
Existe-t-il déjà une personne ou une équipe responsable de la conformité IA, distincte ou non du délégué à la protection des données ?

Une réponse positive aux deux premières questions signale une exposition probable aux obligations de transparence ou de haut risque ; l'absence de réponse aux deux dernières signale un chantier de gouvernance à ouvrir sans attendre l'échéance réglementaire.

Ce premier tri ne doit pas être confondu avec l'évaluation de conformité formelle exigée pour les systèmes à haut risque : il s'agit ici d'un simple outil de priorisation, pas d'un livrable réglementaire.

Ce que couvre cette formation

Les chapitres suivants détaillent successivement : la classification précise des systèmes à haut risque et les exclusions, le régime spécifique des modèles d'IA à usage général, les obligations documentaires (documentation technique, journalisation, transparence), la gouvernance interne et le registre des systèmes d'IA, l'articulation opérationnelle avec un système de management ISO 42001, la conduite d'une analyse d'impact, et enfin les démarches pratiques d'audit et de mise en conformité pour une organisation qui découvre son périmètre d'exposition.

L'objectif n'est pas de transformer chaque lecteur en juriste spécialisé, mais de donner les repères nécessaires pour dialoguer efficacement avec les équipes juridiques, identifier les situations à risque avant qu'elles ne deviennent des projets bloqués, et structurer une démarche de conformité qui tienne dans le temps plutôt qu'un exercice ponctuel avant une échéance réglementaire.

L'essentiel à retenir

Ce chapitre pose le cadre général du règlement européen sur l'intelligence artificielle (AI Act), entré en vigueur en août 2024 avec une application échelonnée jusqu'en 2027. Il explique la logique de classification par niveau de risque qui structure l'ensemble du texte, distingue les rôles de fournisseur, déployeur, importateur et distributeur, et situe le règlement par rapport au RGPD et à la norme ISO 42001. Il clarifie aussi ce que l'AI Act ne couvre pas, notamment la cybersécurité des systèmes d'information relevant de NIS2, pour éviter les confusions fréquentes entre ces cadres.

Questions fréquentes

L'AI Act s'applique-t-il aux entreprises situées hors de l'Union européenne ?

Oui, dès lors que le système d'IA est mis sur le marché de l'UE ou que sa sortie affecte des personnes situées dans l'UE. Le règlement a une portée extraterritoriale comparable à celle du RGPD : une entreprise américaine ou asiatique qui vend un système d'IA à des clients européens, ou dont le système produit des effets sur des personnes dans l'UE, entre dans le champ d'application.

Une PME qui utilise seulement des outils d'IA du commerce est-elle concernée ?

Oui, si l'usage relève d'une catégorie à risque limité ou à haut risque. Le rôle de déployeur s'applique dès qu'une organisation utilise professionnellement un système d'IA, quelle que soit sa taille. La charge d'obligations reste toutefois proportionnée : une PME n'a pas les mêmes exigences documentaires qu'un fournisseur qui développe le système.

Est-ce que tous les modèles de langage type ChatGPT sont classés à haut risque ?

Non. Les modèles d'IA à usage général relèvent d'un régime distinct, avec des obligations de transparence et, pour les modèles présentant un risque systémique (au-delà d'un seuil de puissance de calcul d'entraînement), des obligations renforcées. Le classement à haut risque dépend de l'usage final déployé, pas du modèle en tant que tel.

Que se passe-t-il si mon organisation ne se conforme pas à temps ?

Les autorités de surveillance du marché peuvent exiger une mise en conformité, restreindre voire interdire la mise à disposition du système sur le marché, en plus des sanctions financières prévues (jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires mondial selon la gravité du manquement).

Le RGPD suffit-il à couvrir les obligations de l'AI Act si mon système traite des données personnelles ?

Non. Le RGPD couvre la protection des données personnelles, tandis que l'AI Act impose des exigences propres au système lui-même — gestion des risques, robustesse technique, supervision humaine, documentation de conformité — indépendamment de la nature des données traitées. Les deux démarches sont complémentaires et doivent être menées en parallèle.

Quelle est la différence pratique entre fournisseur et déployeur si mon entreprise fait les deux ?

Une entreprise peut cumuler les deux rôles, par exemple si elle développe un outil interne d'aide à la décision RH puis l'utilise elle-même. Dans ce cas, elle doit répondre à l'ensemble des obligations de fournisseur (documentation technique, évaluation de conformité) et de déployeur (supervision humaine, information des personnes concernées) pour ce même système.

L'AI Act interdit-il l'usage de la reconnaissance faciale ?

Il interdit certains usages spécifiques, notamment la reconnaissance faciale biométrique en temps réel dans l'espace public à des fins répressives, sauf exceptions strictement encadrées (recherche de victimes, prévention d'une menace terroriste imminente). D'autres usages de biométrie restent possibles mais classés à haut risque, avec des obligations de conformité renforcées.

Progression sauvegardée dans votre navigateur.

Quiz de validation

Quiz indisponible (données invalides).

De la formation à l'action Nos experts peuvent auditer, tester ou certifier votre organisation.

Devis gratuit