Approche par risques et taxonomie — AI Act — comprendre et appliquer le règlement européen sur l'IA

Le cœur du règlement européen sur l'IA repose sur une classification à quatre niveaux qui détermine les obligations applicables à chaque système. Ce chapitre détaille les critères de classification, les cas limites et la méthode pour cartographier un inventaire de cas d'usage.

Ch. 3/11 Intermédiaire

Table des matières

Pourquoi une classification par risques

Le règlement européen sur l'intelligence artificielle ne définit pas d'obligations générales applicables à « l'IA » en tant que catégorie technique. Il construit un système gradué où l'intensité de la contrainte dépend de la finalité du système et du contexte dans lequel il est déployé. Un même algorithme de classification d'images peut relever de trois régimes différents selon qu'il trie des colis dans un entrepôt, filtre des candidatures à l'embauche ou identifie des personnes dans l'espace public.

Cette logique surprend souvent les équipes techniques habituées à raisonner par architecture (modèle de langage, réseau de neurones convolutif, système de règles). L'AI Act raisonne par finalité déclarée et usage réel. Deux déploiements du même modèle peuvent donc se voir appliquer des obligations totalement différentes.

La classification n'est pas figée au moment de la conception. Un système initialement classé à risque minimal peut basculer en haut risque si son usage évolue — par exemple un outil d'analyse de texte générique repris pour évaluer des candidatures. La responsabilité de réévaluer la classification incombe au déployeur autant qu'au fournisseur initial.

La pyramide à quatre niveaux

Pyramide des quatre niveaux de risque de l'AI Act — Du sommet interdit à la base libre : quatre régimes d'obligations distincts selon la finalité du système.

La pyramide se lit du sommet vers la base : plus on descend, plus le nombre de systèmes concernés augmente, et plus les contraintes s'allègent.

Niveau 1 — Risque inacceptable (interdiction)

L'article 5 du règlement liste huit catégories de pratiques purement et simplement interdites sur le marché européen, quel que soit le fournisseur :

Techniques de manipulation subliminale ou délibérément trompeuses altérant le comportement d'une personne au point de causer un préjudice significatif
Exploitation des vulnérabilités liées à l'âge, au handicap ou à la situation sociale ou économique
Notation sociale généralisée par des autorités publiques ou en leur nom, conduisant à un traitement défavorable injustifié
Évaluation ou prédiction du risque de commettre une infraction pénale fondée uniquement sur le profilage ou des traits de personnalité
Constitution de bases de données de reconnaissance faciale par extraction non ciblée d'images (internet, vidéosurveillance)
Reconnaissance des émotions sur le lieu de travail et dans les établissements d'enseignement (hors exceptions médicales ou de sécurité)
Catégorisation biométrique déduisant des données sensibles (opinions politiques, orientation sexuelle, appartenance syndicale, etc.)
Identification biométrique à distance « en temps réel » dans des espaces accessibles au public à des fins répressives, sauf exceptions strictement encadrées (recherche de victimes, prévention d'une menace imminente pour la vie, poursuite d'infractions graves listées)

La dernière catégorie — identification biométrique en temps réel — comporte des dérogations qui font l'objet d'un encadrement procédural lourd (autorisation judiciaire ou administrative préalable, limitation temporelle et géographique). Ne pas confondre « dérogation possible » avec « autorisation par défaut » : le régime reste celui de l'interdiction, l'exception doit être justifiée au cas par cas.

Niveau 2 — Haut risque (Annexe III)

C'est le niveau qui concentre l'essentiel des obligations opérationnelles du règlement : gestion des risques, gouvernance des données, documentation technique, journalisation, supervision humaine, robustesse et cybersécurité, enregistrement dans une base de données européenne. L'Annexe III liste huit domaines dans lesquels un système est présumé à haut risque dès lors qu'il joue un rôle déterminant dans une décision affectant une personne :

Biométrie (identification, catégorisation, reconnaissance d'émotions non interdites)
Gestion des infrastructures critiques (énergie, eau, transport numérique)
Éducation et formation professionnelle (accès, évaluation, orientation)
Emploi, gestion des travailleurs et accès à l'indépendance professionnelle (recrutement, évaluation de performance, promotion, licenciement)
Accès aux services essentiels privés et publics (crédit, assurance, prestations sociales)
Répression pénale (dans les limites compatibles avec les droits fondamentaux)
Migration, asile et gestion des frontières
Administration de la justice et processus démocratiques

À cette liste s'ajoutent les systèmes qui constituent un composant de sécurité d'un produit déjà soumis à une législation d'harmonisation européenne — dispositifs médicaux, jouets, ascenseurs, machines — dès lors qu'une évaluation de conformité par tierce partie est déjà requise pour ce produit.

Un système classé dans une catégorie de l'Annexe III peut échapper au régime haut risque s'il ne fait qu'une tâche procédurale étroite, améliore un résultat produit par une personne physique en amont, détecte des écarts sans se substituer à l'évaluation humaine, ou remplit une tâche préparatoire. Cette exception doit être documentée et justifiée par le fournisseur — elle ne se présume pas.

Niveau 3 — Risque limité (transparence)

Ce niveau ne repose pas sur un domaine d'application mais sur une caractéristique du système : sa capacité à interagir avec des personnes ou à produire du contenu qui pourrait être pris pour une production humaine ou factuelle. Les obligations sont des obligations d'information, pas de contrôle technique préalable :

Un système conversationnel doit signaler à l'utilisateur qu'il interagit avec une IA, sauf évidence du contexte
Un contenu de synthèse (image, audio, vidéo, texte) généré ou manipulé par IA doit être identifié comme tel, notamment lorsqu'il ressemble à un contenu authentique
Un système de reconnaissance d'émotions ou de catégorisation biométrique (non interdit) doit informer les personnes exposées
Un deepfake doit être divulgué comme contenu généré ou manipulé, sauf usages artistiques ou satiriques encadrés par des garanties appropriées de transparence

Une entreprise déploie un chatbot de support client fondé sur un modèle de langage. Le système n'entre dans aucune catégorie de l'Annexe III : il ne prend pas de décision affectant l'accès à un service essentiel, il aiguille et répond à des questions. L'obligation qui s'applique est simple mais non négociable : indiquer clairement, dès le début de la conversation, qu'il s'agit d'un système automatisé. L'absence de cette mention constitue un manquement, même en l'absence de tout préjudice démontré.

Niveau 4 — Risque minimal ou nul

La grande majorité des systèmes d'IA déployés en entreprise relève de ce niveau : filtres anti-spam, systèmes de recommandation non liés à un service essentiel, IA dans les jeux vidéo, outils de traduction interne, correcteurs orthographiques. Aucune obligation légale spécifique ne s'applique au titre de l'AI Act. Le règlement encourage l'adhésion volontaire à des codes de conduite, mais rien n'est contraignant.

Ne pas confondre « risque minimal au titre de l'AI Act » et « absence de risque tout court ». Le RGPD continue de s'appliquer intégralement dès qu'il y a traitement de données personnelles, quel que soit le niveau de risque IA. Un chatbot RH sans aucune obligation AI Act spécifique reste pleinement soumis aux exigences de licéité, de minimisation et de sécurité du RGPD.

Le cas des modèles à usage général (GPAI)

Un système fondé sur un modèle à usage général — un grand modèle de langage par exemple — pose une difficulté propre : le modèle lui-même n'a pas de finalité unique, mais le déploiement en a une. Le règlement distingue deux niveaux d'obligations :

Les fournisseurs de modèles à usage général doivent tenir une documentation technique, une politique de respect du droit d'auteur et un résumé du contenu d'entraînement, indépendamment de l'usage final
Les modèles présentant un « risque systémique » (au-delà d'un seuil de capacité de calcul d'entraînement, actuellement fixé à 10^25 FLOPs, ou désignés comme tels par la Commission) sont soumis à des obligations renforcées : évaluation contradictoire, notification d'incidents graves, cybersécurité renforcée

Cette couche s'ajoute à la classification par cas d'usage, elle ne la remplace pas. Une entreprise qui construit un produit de scoring RH sur une API de modèle de langage hérite des obligations « haut risque » liées à son usage, indépendamment des obligations que porte déjà le fournisseur du modèle sous-jacent au titre de GPAI.

Méthode d'inventaire des cas d'usage

Classer un système isolé est simple une fois les critères connus. La difficulté opérationnelle réside dans l'inventaire exhaustif des systèmes IA effectivement utilisés dans une organisation, souvent introduits par des équipes métier sans validation centrale.

Étape	Objectif	Piège fréquent
1. Recensement	Lister tous les systèmes IA en production ou en test, y compris les fonctionnalités IA embarquées dans des outils SaaS existants	Oublier les fonctionnalités IA activées par défaut dans des logiciels déjà déployés (suites bureautiques, CRM)
2. Qualification	Déterminer si le système entre dans la définition d'« système d'IA » au sens du règlement	Sur-qualifier des systèmes à base de règles simples qui n'impliquent aucune inférence
3. Finalité déclarée	Identifier l'usage prévu par le fournisseur	Confondre la documentation marketing avec la fiche technique réglementaire
4. Usage réel	Vérifier que l'usage effectif correspond à la finalité déclarée	Ignorer les détournements d'usage réalisés en interne (« shadow AI »)
5. Classification	Appliquer la grille des quatre niveaux, en croisant Annexe III et exceptions	Classer par analogie technique plutôt que par activité couverte
6. Traçabilité	Documenter la décision de classification, y compris pour les cas classés « minimal »	Absence de trace écrite, rendant impossible la démonstration de diligence en cas de contrôle

Le « shadow AI » — usage non déclaré d'outils d'IA générative par les collaborateurs — constitue un angle mort fréquent. Un salarié qui utilise un assistant de rédaction externe pour produire des évaluations de performance introduit, sans que l'organisation le sache, un système potentiellement haut risque (catégorie emploi) dans un processus RH. L'inventaire ne peut pas se limiter aux systèmes achetés ou développés officiellement.

Cas limites fréquents

Certaines situations résistent à une classification mécanique et nécessitent une analyse au cas par cas :

Outil d'aide à la décision vs décision automatisée : un système qui présente un score à un recruteur humain, qui reste libre de l'ignorer, peut sortir du régime haut risque si la supervision humaine est réelle et documentée — pas seulement formelle. Un taux de suivi du score de 98 % par les recruteurs affaiblit sérieusement l'argument d'une supervision effective.
Systèmes multi-usages : un même moteur de scoring vendu à la fois pour du crédit à la consommation (haut risque) et pour de la segmentation marketing (risque minimal) impose deux classifications distinctes selon le déploiement, avec une documentation technique adaptée à chacun.
Composants tiers intégrés : intégrer une API de reconnaissance faciale d'un fournisseur externe dans une application de contrôle d'accès aux locaux ne dispense pas l'intégrateur de qualifier son propre produit final au regard de l'Annexe III.
Prototypes et phases de test : un système en phase pilote reste soumis au règlement dès lors qu'il traite des données réelles affectant des personnes réelles, même en l'absence de déploiement à grande échelle.

Ce que ce chapitre ne couvre pas

La classification par risques détermine quelles obligations s'appliquent, pas comment les remplir. Les exigences détaillées pour les systèmes à haut risque — système de gestion des risques, gouvernance des données d'entraînement, documentation technique, supervision humaine, robustesse — font l'objet des chapitres suivants. De même, l'articulation précise avec le RGPD et avec ISO 42001 est traitée séparément : la classification AI Act ne se substitue à aucune de ces obligations, elle s'y ajoute.

Points de vigilance pour la mise en pratique

Documenter par écrit la logique de classification retenue pour chaque système, y compris ceux classés « risque minimal » — l'absence de trace est elle-même un risque en cas de contrôle
Revoir la classification à chaque changement significatif de finalité ou de périmètre de déploiement, pas seulement à la mise en production initiale
Ne pas se fier uniquement à la documentation du fournisseur : l'usage réel prime sur l'usage déclaré
Traiter l'inventaire comme un processus vivant, avec un point de contrôle récurrent, et non comme un audit ponctuel
Associer les équipes métier à l'inventaire : elles connaissent les usages réels mieux que les équipes conformité

L'essentiel à retenir

L'AI Act ne réglemente pas une technologie mais des usages, classés selon quatre niveaux de risque : inacceptable (interdit), haut risque (encadrement strict via l'Annexe III), risque limité (obligations de transparence) et risque minimal (aucune contrainte spécifique). Ce chapitre explique les critères qui déterminent la finalité d'un système, détaille les huit catégories de pratiques interdites et les huit domaines de haut risque de l'Annexe III, et propose une méthode d'inventaire pour classer les cas d'usage réels d'une organisation, y compris les situations ambiguës comme les systèmes à finalité générale intégrés dans un produit à haut risque.

Questions fréquentes

Un système classé « risque minimal » peut-il changer de catégorie plus tard ?

Oui. La classification suit l'usage réel, pas seulement la conception initiale. Si un outil générique est repris pour un usage relevant de l'Annexe III — par exemple un outil d'analyse de texte détourné pour évaluer des candidatures — il doit être reclassé et se conformer aux obligations correspondantes. La réévaluation incombe autant au déployeur qu'au fournisseur d'origine.

Qui décide de la classification d'un système : le fournisseur ou l'organisation qui le déploie ?

Les deux, à des titres différents. Le fournisseur documente la finalité prévue et fournit les informations nécessaires à la classification. Mais le déployeur reste responsable de vérifier que l'usage réel correspond à cette finalité déclarée et de requalifier le système si l'usage effectif diverge de la documentation fournisseur.

Un prototype en phase de test interne est-il concerné par le règlement ?

Oui, dès lors qu'il traite des données réelles affectant des personnes réelles, même à petite échelle. L'absence de déploiement massif ne dispense pas des obligations liées au niveau de risque identifié. Un pilote RH testé sur vingt candidats reste soumis aux mêmes règles de classification qu'un déploiement complet.

Comment traiter une fonctionnalité IA activée par défaut dans un logiciel SaaS déjà utilisé par l'entreprise ?

Elle doit être intégrée à l'inventaire au même titre qu'un système développé en interne. Ces fonctionnalités échappent souvent à la vigilance parce qu'elles n'ont pas fait l'objet d'un projet dédié, ce qui en fait un point aveugle fréquent dans les démarches de conformité.

L'interdiction de la reconnaissance d'émotions au travail comporte-t-elle des exceptions ?

Oui, deux exceptions strictes existent : les usages liés à la sécurité (par exemple détecter la fatigue d'un conducteur professionnel) et les usages médicaux encadrés. En dehors de ces cas précis, le déploiement de reconnaissance d'émotions sur le lieu de travail ou en milieu scolaire reste interdit, quelle que soit la finalité invoquée par l'employeur.

Un modèle de langage à usage général est-il automatiquement classé haut risque ?

Non. Le modèle en lui-même relève d'un régime distinct (obligations GPAI liées à la documentation et, au-delà d'un certain seuil de capacité, au risque systémique). C'est le produit ou service construit à partir de ce modèle, et son usage concret, qui détermine le niveau de risque au sens de la classification par cas d'usage.

Faut-il documenter la classification même pour un système jugé à risque minimal ?

C'est fortement recommandé, même si le règlement n'impose pas de formalisme spécifique à ce niveau. En cas de contrôle ou de litige, l'absence de toute trace écrite sur le raisonnement de classification est elle-même un facteur de risque, car elle empêche de démontrer une diligence raisonnable.

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