EU AI Act : du règlement à la preuve technique

Qu'est-ce que l'EU AI Act ?

L'EU AI Act, officiellement le Règlement (UE) 2024/1689, est le cadre juridique européen fondé sur le risque pour l'intelligence artificielle. Il est entré en vigueur le 1er août 2024 et, plutôt que de réglementer « l'IA » comme un bloc unique, il classe les systèmes et modèles d'IA en niveaux de risque et attache à chacun des obligations différentes.

Il s'agit d'un cadre juridique européen horizontal qui établit des règles fondées sur le risque pour l'intelligence artificielle. Le règlement s'applique dans plusieurs situations, notamment à certains fournisseurs et déployeurs établis dans l'UE ainsi qu'à certains fournisseurs de pays tiers dont le résultat du système d'IA est utilisé dans l'Union, sous réserve des conditions spécifiques fixées par le règlement, et non comme une règle générale couvrant toute organisation ayant un lien quelconque avec l'IA. Les obligations entrent en application de façon échelonnée sur plusieurs années plutôt que d'un seul coup, et cet échelonnement a lui-même été ajusté depuis l'adoption initiale du règlement, ce qui explique en partie pourquoi cette page porte une date de révision plutôt que de présenter un résumé figé comme définitif.

À qui l'EU AI Act s'applique-t-il ?

L'applicabilité n'est pas uniforme, et l'une des erreurs les plus fréquentes que je constate consiste, pour une organisation, à supposer que le règlement s'applique intégralement ou pas du tout. En pratique, cela dépend de plusieurs facteurs qui se combinent.

Rôle dans la chaîne de valeur de l'IA. Un fournisseur développe un système ou un modèle d'IA et le met sur le marché ou le met en service. Un déployeur utilise un système d'IA sous sa propre autorité. Les deux rôles portent des obligations différentes, et une même organisation peut être les deux à la fois pour des systèmes différents.

Finalité prévue et classification du risque. Un même modèle sous-jacent peut relever de niveaux de risque différents selon son usage. Un modèle de langage à usage général utilisé pour la rédaction interne porte un ensemble d'obligations très différent du même modèle intégré dans un outil de tri de CV.

Si le système est un modèle d'IA à usage général. Les modèles GPAI suivent leur propre régime d'obligations, traité séparément plus bas, qui s'ajoute au rôle et à la classification du risque par ailleurs applicables.

Rien de tout cela ne remplace une évaluation juridique au cas par cas d'un système donné. C'est le cadre dont une équipe d'ingénierie ou d'architecture a besoin avant même de pouvoir cadrer correctement cette évaluation.

Quelles sont les catégories de risque de l'EU AI Act ?

Le règlement adopte une approche fondée sur le risque plutôt que de réglementer tous les systèmes d'IA de la même façon. Quatre grandes catégories sont couramment utilisées pour expliquer cette approche en pratique ; elles constituent un cadre explicatif donné à titre de repère, et non un test universel d'auto-classification juridique, et les repères ci-dessous ne doivent pas être considérés comme un substitut à une évaluation juridique propre à chaque cas.

Qu'est-ce qu'un système d'IA à haut risque ?

Le statut à haut risque s'applique de deux façons. L'annexe III liste des domaines d'usage spécifiques : infrastructures critiques, éducation et formation professionnelle, emploi et gestion des travailleurs, accès à des services privés et publics essentiels (y compris la notation de crédit et l'assurance), application de la loi, migration et contrôle des frontières, administration de la justice et des processus démocratiques, et certains usages d'identification et de catégorisation biométriques. L'annexe I couvre l'IA utilisée comme composant de sécurité dans des produits déjà réglementés par le droit européen de la sécurité des produits, tels que les machines, les dispositifs médicaux et les jouets. Relever de l'un de ces domaines ne constitue pas, en soi, un test de classification complet : le fait qu'un système donné soit effectivement à haut risque dépend des critères juridiques applicables à ce domaine, et non du secteur seul, et tous les systèmes d'IA utilisés dans la santé, l'emploi, l'éducation, la finance ou les services publics ne sont pas automatiquement à haut risque.

Les fournisseurs de systèmes à haut risque portent l'ensemble d'obligations le plus lourd : un système de gestion des risques maintenu tout au long du cycle de vie du système, une gouvernance des données d'entraînement, de validation et de test, une documentation technique, des capacités de journalisation automatique, des instructions claires permettant la surveillance humaine, et une exactitude, une robustesse et une cybersécurité démontrées. Les déployeurs de systèmes à haut risque portent un ensemble plus restreint, centré sur l'utilisation du système conformément à ses instructions, l'exercice effectif d'une surveillance humaine, et le suivi de son fonctionnement, avec des obligations supplémentaires telles qu'une analyse d'impact sur les droits fondamentaux pour certains déployeurs (y compris les organismes publics et certains usages dans les services financiers).

Quelles sont les obligations applicables aux modèles GPAI ?

Le règlement définit un modèle d'IA à usage général (GPAI) à l'article 3 ; la portée exacte de cette définition juridique doit être vérifiée au regard du texte du règlement lui-même ou des lignes directrices officielles de la Commission, et non de ce résumé. En termes pratiques, et uniquement à titre de description explicative plutôt que de reformulation de ce texte juridique, cela recouvre généralement des modèles aux capacités larges, capables d'exécuter un large éventail de tâches et d'être intégrés dans des systèmes d'IA en aval. Les modèles GPAI portent, pour leurs fournisseurs, un ensemble distinct d'obligations au titre du règlement, et des exigences supplémentaires peuvent s'appliquer selon la façon dont un modèle GPAI est incorporé dans un système d'IA en aval ou utilisé au sein de celui-ci ; les obligations d'un fournisseur de GPAI et celles d'un système en aval ne sont donc pas automatiquement les mêmes.

Tout fournisseur de GPAI est tenu de maintenir une documentation technique, de mettre certaines informations à la disposition des fournisseurs qui intègrent le modèle en aval, et de publier un résumé suffisamment détaillé des contenus utilisés pour l'entraînement, afin de soutenir les obligations liées au droit d'auteur.

Un modèle GPAI est présumé, au titre de l'article 51, porter un risque systémique lorsque la puissance de calcul cumulée utilisée pour son entraînement dépasse un seuil défini (exprimé en opérations en virgule flottante), et la Commission peut également désigner un modèle comme porteur d'un risque systémique sur d'autres fondements. Les fournisseurs de tels modèles font face à des obligations supplémentaires : évaluation du modèle incluant des tests adverses, évaluation et atténuation du risque systémique, suivi et signalement des incidents graves, et maintien d'un niveau adéquat de protection en cybersécurité. L'Office européen de l'IA, établi au sein de la Commission européenne, détient l'autorité de supervision principale sur les modèles GPAI et maintient un code de bonne pratique volontaire pour les fournisseurs de GPAI couvrant la transparence, le droit d'auteur et la sûreté et la sécurité ; il s'agit d'un outil volontaire destiné à aider les fournisseurs à démontrer leur conformité, et non d'une détermination qu'un fournisseur donné est effectivement conforme.

Calendrier : ce qui s'applique, et quand

Les obligations du règlement entrent en application de façon échelonnée, et cet échelonnement a déjà été ajusté une fois depuis l'adoption. À la date de dernière révision de cette page, le calendrier d'application est le suivant :

En 2026, le « Digital Omnibus sur l'IA » de la Commission européenne (en vigueur depuis le 27 juillet 2026) a modifié le règlement pour prolonger le calendrier de mise en conformité pour les systèmes à haut risque et simplifier certaines obligations administratives, tout en laissant intacte la structure fondée sur le risque et les garanties du règlement. Considérez tout calendrier relatif à l'EU AI Act, y compris celui-ci, comme susceptible d'évoluer avec de nouvelles lignes directrices ou des amendements, et vérifiez les dates en vigueur sur la page officielle de la Commission européenne avant de considérer une date donnée comme définitive pour un système particulier.

Que se passe-t-il en cas de non-conformité ?

L'article 99 fixe trois niveaux de sanctions, applicables depuis le 2 août 2025 : jusqu'à €35 millions ou 7 % du chiffre d'affaires annuel mondial total pour violation des pratiques interdites ; jusqu'à €15 millions ou 3 % pour non-respect des obligations applicables aux systèmes à haut risque ou des obligations de transparence de l'article 50 ; et jusqu'à €7,5 millions ou 1 % pour la fourniture d'informations inexactes, incomplètes ou trompeuses aux autorités. Pour les grandes organisations, le montant le plus élevé des deux s'applique ; il s'agit de plafonds légaux maximums, non de montants automatiques ou fixes, et le montant réel de l'amende dans un cas donné dépend des faits propres à ce cas et de l'appréciation de l'autorité chargée de l'application. L'article 99 lui-même prévoit un traitement plus favorable pour les PME, y compris les jeunes pousses, auxquelles s'applique à la place le montant le plus bas des deux, et le Digital Omnibus de 2026 a étendu un traitement comparable aux petites entreprises à moyenne capitalisation pour les deux niveaux de sanctions inférieurs.

Pourquoi l'EU AI Act compte pour les dirigeants technologiques

Mettons un instant de côté les montants des sanctions, car ce n'est pas réellement la raison la plus utile de s'intéresser à ce règlement.

Le règlement codifie en réalité un ensemble de pratiques d'ingénierie et de gouvernance dont l'IA de qualité production avait de toute façon besoin : une évaluation des risques documentée, une traçabilité des données, une journalisation suffisante pour reconstituer ce qu'un système a fait et pourquoi, une surveillance humaine réellement exerçable et non simplement nominale, et un suivi capable de détecter une dérive avant qu'un client ou un régulateur ne le fasse. Les organisations qui exploitent déjà leurs systèmes d'IA de cette manière disposent d'une avance qui n'a rien à voir avec une stratégie juridique. Celles qui ne le font pas découvrent, souvent au pire moment, que « on documentera plus tard » ne tient plus dès qu'un système traite des décisions qui affectent des personnes réelles.

Cela ne signifie pas que chaque entreprise ou chaque système d'IA porte les mêmes obligations, et il vaut la peine de résister aux deux extrêmes ici : considérer le règlement comme sans objet parce que « nous ne sommes pas dans un secteur réglementé », et le traiter comme une menace existentielle exigeant un programme de mise en conformité dans l'urgence, quel que soit l'usage réel que l'organisation fait de l'IA. La réponse appropriée est proportionnée au rôle réel et à la classification du risque du système, ce qui explique précisément pourquoi la question de l'applicabilité abordée plus haut vient avant tout le reste.

La conformité IA est plus qu'une simple checklist

C'est là que la plupart des discussions sur la conformité échouent. Un document de politique qu'on ne peut rattacher à aucun contrôle réellement en fonctionnement ne constitue la preuve de rien, et un contrôle qui n'a jamais été testé ne diffère pas vraiment de l'absence totale de contrôle.

Cette chaîne est aussi, ce n'est pas un hasard, la conversation d'architecture que j'ai avec les équipes d'ingénierie indépendamment de toute réglementation : l'IA de qualité production exige un comportement mesurable, des contrôles de sécurité, de l'observabilité et des preuves de gouvernance, pas seulement un document de politique rangé dans un lecteur partagé. Je ne prétendrai pas savoir exactement ce qu'un régulateur donné acceptera comme preuve suffisante dans chaque cas, car cette détermination relève du régulateur et des faits propres à chaque situation. Ce que je peux dire, c'est qu'une organisation sans comportement mesurable ni piste de preuves n'a rien à apporter à cette conversation le jour où elle survient.

Qu'est-ce que l'assurance IA ? L'évaluation technique des systèmes d'IA

L'assurance IA est la pratique technique consistant à évaluer ce qu'un système d'IA fait réellement, par opposition à ce qu'une politique indique qu'il devrait faire. C'est la couche d'ingénierie qui produit les preuves dont dépend la chaîne de gouvernance décrite plus haut, et il vaut la peine de préciser que l'évaluation technique ne constitue pas en soi une détermination de conformité légale. Elle en est un élément d'entrée.

L'interprétabilité mécaniste comme source de preuve

L'interprétabilité mécaniste est un domaine de recherche actif qui cherche à comprendre ce qui se passe à l'intérieur d'un modèle, pas seulement ce qu'il produit en sortie, à l'aide de techniques telles que l'analyse des activations, l'attribution de caractéristiques, le patching d'activations, les autoencodeurs parcimonieux et les interventions causales, afin d'identifier des circuits candidats qui semblent piloter un comportement donné.

Il vaut la peine de dire clairement ce que cela offre, et n'offre pas, à l'heure actuelle. Ces méthodes peuvent faire apparaître des représentations internes mesurables et constituer des éléments de preuve pour une hypothèse sur ce qui influence le résultat d'un modèle. Elles ne fournissent pas, à l'heure actuelle, une connaissance exacte des « pensées » d'un modèle, une reconstruction complète de son raisonnement, une explication causale garantie, ni l'identification d'un neurone unique définitivement responsable d'un résultat. La terminologie du domaine lui-même en témoigne : les constats sont décrits comme de l'attribution, une influence causale candidate, et des éléments de preuve à l'appui d'une hypothèse, et non comme des preuves définitives.

Présentée avec exactitude, l'interprétabilité est une source de preuve technique possible parmi d'autres, utile aux côtés de l'évaluation comportementale et du suivi, mais ne s'y substitue pas et ne constitue pas, à elle seule, un mécanisme de conformité.

Construire un moteur de conformité et de preuves pour l'EU AI Act

L'idée centrale : relier l'évaluation de l'IA, la preuve technique et l'évaluation des risques à une cartographie des contrôles réglementaires, afin que ce soit le comportement réel et testé du système d'une organisation, et non un simple document de politique, qui soit mis en correspondance avec les exigences de l'EU AI Act.

À un niveau général, le pipeline se présente ainsi :

Les capacités prévues incluent l'enregistrement des modèles, des tests comportementaux et de sécurité automatisés, des indicateurs de risque fondés sur l'interprétabilité, la collecte de preuves, la mise en correspondance du comportement testé avec des contrôles spécifiques de l'EU AI Act, une piste d'audit, un reporting, et des cadres de gouvernance configurables afin que le même pipeline de preuves puisse, au fil du temps, être mis en correspondance avec plus d'une norme réglementaire ou interne.

Une chose que ce moteur ne fera pas, par conception : déterminer la conformité légale au nom d'une organisation. Son résultat est une évaluation technique et une cartographie de preuves, la matière première dont une fonction conformité ou juridique a besoin, pas un substitut au jugement de cette fonction.

Ce que cela signifie pour les dirigeants IA

À qui s'adresse ce contenu

Ce contenu s'adresse en priorité aux organisations et aux rôles qui construisent, déploient ou gouvernent activement des systèmes d'IA exposés au marché européen :

Toutes les organisations de ces catégories ne sont pas légalement tenues par chaque disposition du règlement. Les obligations qui s'appliquent réellement dépendent des facteurs spécifiques décrits plus haut.

FAQ

Pour aller plus loin

Ce sujet est directement lié à AI Security, Agentic AI Security et Production AI, ainsi qu'aux questions d'économie et d'architecture traitées dans The Economics of Autonomous AI et The Agent Card Problem.

Sources et lectures complémentaires

Règlement (UE) 2024/1689 (loi sur l'intelligence artificielle), texte officiel, EUR-Lex.
Cadre réglementaire de l'AI Act, Commission européenne, Digital Strategy.
Office européen de l'IA, Commission européenne.
L'AI Omnibus entre en vigueur, Commission européenne, juillet 2026.

Ce contenu fournit des orientations techniques et pédagogiques et ne constitue ni un conseil juridique, ni une certification réglementaire, ni une garantie de conformité. Il n'établit pas l'auteur comme évaluateur certifié par l'UE, comme avocat, ni comme organisme officiel de l'UE ou partenaire de celle-ci. L'applicabilité de l'EU AI Act à une organisation ou un système spécifique doit être évaluée avec un conseil juridique qualifié.