Systèmes d'IA à haut risque

Pourquoi cette catégorie structure tout le règlement

L'AI ActAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire n'impose pas les mêmes obligations à tous les systèmes d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire. Il retient une approche fondée sur le risque, avec quatre niveaux : risque inacceptable (interdit), haut risquehaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire (encadré strictement), risque limité (transparence) et risque minimal (pas d'obligation spécifique). La catégorie haut risque est celle qui concentre l'essentiel de la charge de conformité — évaluation de conformité, documentation technique, système de gestion des risques, surveillance humaine, enregistrement dans une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire européenne.

Savoir si un système entre ou non dans cette catégorie n'est donc pas un exercice académique. C'est la question qui détermine si un projet nécessite six mois de mise en conformité ou une simple notice d'information. Se tromper dans un sens crée un risque juridique et des sanctions potentielles ; se tromper dans l'autre immobilise inutilement des ressources sur un système qui n'en avait pas besoin.

La classification haut risque ne dépend pas de la performance technique du modèle ni de son degré d'autonomie perçu. Elle dépend uniquement de la finalité déclarée du système et du domaine d'usage dans lequel il est mis sur le marché. Un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire générique n'est pas haut risque en soi ; un chatbot construit sur ce même modèle pour filtrer des candidatures à l'embauche l'est presque certainement.

Le test de classification en deux étapes

L'article 6 de l'AI Act organise la qualification haut risque en deux voies distinctes, puis un filtre correctif.

Première voie — composant de sécurité. Un système d'IA est haut risque s'il est un composant de sécurité d'un produit couvert par une législation d'harmonisation de l'Union (dispositifs médicaux, machines, jouets, ascenseurs, aviation civile, etc.) et que ce produit doit faire l'objet d'une évaluation de conformité par un tiers avant mise sur le marché.

Seconde voie — Annexe III. Un système d'IA est haut risque s'il figure, par sa finalité, dans l'un des huit domaines listés à l'Annexe III du règlement. C'est cette seconde voie qui concerne la grande majorité des éditeurs de logiciels et des organisations qui déploient de l'IA en interne.

Le filtre correctif — article 6(3). Même lorsqu'un système relève d'un domaine de l'Annexe III, il peut être exclu de la catégorie haut risque s'il remplit l'une des conditions d'exception prévues. Cette exclusion n'est pas automatique : elle doit être documentée et justifiée par le fournisseur, qui reste responsable de sa propre analyse.

Les huit domaines de l'Annexe III

L'Annexe III énumère des cas d'usage, pas des technologies. Un même modèle peut être haut risque dans un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire et anodin dans un autre : la finalité prime sur l'architecture.

Cette liste n'est pas figée. La Commission européenne peut la faire évoluer par actes délégués, à la hausse comme à la baisse, en fonction de l'évolution des usages et des risques observés. Un système non concerné aujourd'hui peut le devenir lors d'une révision — la classification doit donc être revue périodiquement, pas figée au moment du lancement.

L'exclusion de l'article 6(3) : quand l'Annexe III ne suffit pas

L'article 6(3) prévoit qu'un système relevant formellement d'un domaine de l'Annexe III échappe à la qualification haut risque s'il ne présente pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux. Quatre situations types sont citées par le règlement :

1. Tâche procédurale étroite — le système exécute une tâche purement administrative et n'influence pas le fond de la décision (par exemple, un outil qui reformate des données de candidature sans en évaluer le contenu).
2. Amélioration du résultat d'une activité humaine déjà réalisée — le système intervient après qu'une personne a produit le résultat, pour l'affiner sans le remplacer.
3. Détection de déviation par rapport à des schémas de décision antérieurs, sans remplacer ni influencer l'évaluation humaine faite précédemment, à condition qu'un contrôle humain approprié existe.
4. Tâche préparatoire à une évaluation — le système prépare des éléments (extraction, classement documentaire) qui seront ensuite évalués par un humain, sans se substituer à cette évaluation.

Ces exclusions ne s'appliquent jamais lorsque le système effectue du profilage de personnes physiques au sens du RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire. Un fournisseur qui invoque l'article 6(3) pour un outil de scoring individualisé prend un risque de requalification a posteriori, avec les sanctions associées. En cas de doute, l'analyse documentée doit pouvoir résister à un contrôle de l'autorité de surveillance nationale.

Le fournisseur qui s'appuie sur une exclusion doit documenter son analyse avant la mise sur le marché et l'enregistrer dans la base de données européenne prévue par le règlement, même si le système n'est finalement pas classé haut risque. Cette documentation n'est pas optionnelle : elle constitue la preuve de diligence en cas de contrôle.

Une entreprise édite un logiciel RH qui extrait automatiquement les compétences mentionnées dans un CV pour les afficher sous forme de tags à un recruteur, sans note ni classement. Le système relève du domaine « emploi » de l'Annexe III, mais peut être exclu au titre de la tâche préparatoire : il ne score pas, ne classe pas, et le recruteur garde l'intégralité de la décision. Si la même entreprise ajoute un score de pertinence qui ordonne automatiquement les candidatures, l'exclusion tombe : le système influence désormais le résultat, il devient haut risque.

Fournisseur, déployeur : qui classe et qui répond ?

La classification incombe en premier lieu au fournisseur — celui qui développe le système ou le fait développer sous son nom en vue de sa mise sur le marché. C'est lui qui conduit l'analyse de l'Annexe III et documente, le cas échéant, l'exclusion de l'article 6(3).

Le déployeur — l'organisation qui utilise le système dans son activité — n'est pas dispensé d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire pour autant. S'il modifie substantiellement la finalité déclarée par le fournisseur (par exemple en réutilisant un outil d'analyse documentaire générique pour évaluer des candidatures à l'embauche), il peut endosser lui-même les obligations de fournisseur pour ce nouvel usage. C'est un point souvent négligé par les équipes qui adaptent un outil interne ou un modèle open source à un cas d'usage RH ou financier sans repasser par une analyse de classification.

Documentez systématiquement la finalité prévue (« intended purpose ») de chaque système d'IA déployé, même interne, et revoyez cette fiche à chaque changement de cas d'usage. C'est le socle de toute analyse de classification et l'élément le plus souvent absent lors d'un audit — beaucoup d'organisations savent quels modèles elles utilisent, mais pas pour quelle finalité déclarée initiale.

Construire un registre de classification pour un portefeuille produit

Pour une organisation qui exploite plusieurs systèmes d'IA — internes ou commercialisés — l'enjeu n'est pas de classer un système isolé mais de couvrir un portefeuille entier de manière homogène et traçable. Une méthode opérationnelle en cinq étapes :

1. Inventorier tous les systèmes d'IA en production ou en développement avancé, y compris les fonctionnalités embarquées dans des logiciels tiers reconfigurés en interne.
2. Qualifier la finalité de chaque système en une phrase précise, orientée usage et non technologie (« aide à la décision de recrutement » plutôt que « modèle de classification de texte »).
3. Appliquer le test en deux étapes — vérification article 5, puis Annexe III — et documenter le raisonnement, pas seulement la conclusion.
4. Évaluer les exclusions de l'article 6(3) lorsqu'applicable, avec une justification écrite et datée.
5. Planifier une revue périodique, a minima annuelle, pour tenir compte des évolutions de la liste de l'Annexe III et des changements de finalité des systèmes eux-mêmes.

Ce registre devient la pièce centrale d'un dossier de conformité et sert de point d'entrée pour les chapitres suivants sur les obligations concrètes — gestion des risques, documentation technique, surveillance humaine — qui ne s'appliquent qu'aux systèmes effectivement classés haut risque.

Pièges fréquents observés en pratique

Quelques erreurs de classification reviennent systématiquement lors des audits de portefeuille et méritent une attention particulière.

Confondre le domaine d'application et le secteur d'activité de l'entreprise. Une société qui vend des logiciels de gestion pour établissements scolaires n'a pas automatiquement des systèmes haut risque : seule la fonctionnalité qui touche à l'évaluation des acquis, à l'orientation ou à l'admission relève de l'Annexe III. Un module de facturation ou de gestion des emplois du temps reste hors champ, même vendu au même client final.

Négliger les fonctionnalités ajoutées en cours de vie du produit. Un logiciel lancé avec une finalité neutre peut glisser vers le haut risque au fil des versions, lorsqu'une équipe produit ajoute une fonctionnalité de scoring ou de priorisation automatique sans repasser par une revue de classification. La checklist de classification doit faire partie du processus de revue des nouvelles fonctionnalités, au même titre qu'une revue de sécurité ou de protection des données.

Traiter la classification comme un exercice juridique isolé du produit. Une analyse rédigée par un service juridique sans échange avec les équipes qui connaissent le fonctionnement réel du système aboutit souvent à une classification théorique, déconnectée de l'usage effectif. La description technique du système — ce qu'il calcule, ce qu'il affiche, ce qu'un humain peut ou non modifier avant la décision finale — doit nourrir directement l'analyse de l'article 6(3).

Oublier les systèmes fournis par des tiers et intégrés sans modification apparente. Un module de scoring de crédit acheté à un éditeur externe et simplement branché à un système d'information interne reste soumis à l'analyse de classification, y compris pour le déployeur qui l'intègre. L'absence de développement interne ne dispense pas de vérifier la documentation de conformité fournie par l'éditeur, ni de s'assurer qu'elle correspond réellement à l'usage qui en est fait.

Considérer qu'une exclusion validée une fois reste valable indéfiniment. Une exclusion de l'article 6(3) documentée à un instant donné doit être revue chaque fois que le système évolue de façon substantielle, mais aussi lors des révisions périodiques prévues par le registre de classification. Un système exclu aujourd'hui parce qu'il ne fait que préparer des données pour un humain peut perdre cette exclusion si l'automatisation du poste de travail réduit progressivement la marge d'appréciation de l'opérateur humain — un phénomène courant lorsque les équipes cherchent à gagner en productivité sans revoir la gouvernance du système.

Ce qu'il faut retenir avant le chapitre suivant

La classification haut risque conditionne l'intégralité de la charge réglementaire qui suit. Une analyse bâclée à ce stade produit deux types d'erreurs coûteuses : sous-classifier un système qui aurait dû être encadré, avec un risque de sanction et de retrait du marché ; ou sur-classifier par excès de prudence, en imposant des processus lourds à des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire qui n'en avaient pas besoin, au détriment de la vitesse de mise sur le marché. La méthode en deux étapes, appuyée sur une documentation rigoureuse des exclusions, reste l'outil le plus fiable pour arbitrer ces deux écueils.

Le chapitre suivant détaille les obligations concrètes qui s'appliquent une fois qu'un système est confirmé haut risque, à commencer par le système de gestion des risques et la documentation technique exigée avant mise sur le marché.