Règlement européen sur l’IA : classez vos cas d’usage et planifiez les preuves

La gouvernance de l’IA commence par savoir quels systèmes l’organisation fournit, déploie ou met à disposition d’une autre manière. Une liste de noms de modèles ne suffit pas : la destination, le contexte de déploiement et votre rôle déterminent les obligations à examiner.

Pour la direction, la classification est une décision d’allocation des ressources autant qu’une évaluation juridique. Elle détermine quels projets nécessitent une revue spécialisée, ce que les fournisseurs doivent démontrer et quelles preuves doivent exister avant la mise en service. Un outil de recrutement et un assistant de rédaction interne peuvent utiliser le même modèle tout en exigeant des évaluations très différentes.

Le résultat utile est un registre des cas d’usage revu, relié aux responsables, aux exigences, aux preuves et aux décisions de changement, et non une étiquette appliquée à toute l’entreprise affirmant « IA à faible risque ».

Établir le champ d’application et les responsabilités avant d’attribuer un niveau de risque

Le règlement européen sur l’intelligence artificielle est un règlement dont les obligations dépendent de l’activité, du système et de l’opérateur. Son champ d’application territorial couvre les fournisseurs qui mettent des systèmes sur le marché de l’Union ou les mettent en service, les déployeurs établis ou situés dans l’Union, ainsi que certains fournisseurs et déployeurs de pays tiers lorsque les sorties des systèmes sont utilisées dans l’Union. La nationalité n’est pas le critère.

Faites établir par des réviseurs juridiques et techniques si l’application répond à la définition d’un système d’IA au sens du règlement et si des exclusions du champ d’application pertinentes s’appliquent. Ne supposez pas que tout script d’automatisation relève de l’IA, ni qu’un service hébergé à l’extérieur échappe à vos responsabilités.

Consignez ensuite votre rôle :

• Fournisseur : développe un système, ou le fait développer, et le met sur le marché ou le met en service sous son propre nom ou sa propre marque.
• Déployeur : utilise sous sa propre autorité un système dans un cadre professionnel.
• Importateur ou distributeur : introduit des systèmes pertinents sur le marché de l’Union ou les met à disposition dans la chaîne d’approvisionnement, avec les obligations de vérification associées.
• Fabricant de produits ou mandataire : a des responsabilités découlant de l’organisation particulière du produit ou d’un mandat écrit.

Une organisation peut occuper des rôles différents selon les éléments de son portefeuille. L’achat d’une API ne tranche pas le rôle relatif à l’application finale. Un changement de marque, une modification substantielle ou un changement de destination peuvent déclencher des responsabilités de fournisseur dans les conditions applicables. L’ajustement fin (fine-tuning) est donc un déclencheur de revue, et non une conclusion juridique automatique.

Distinguez le modèle d’IA à usage général du système construit autour de lui. Les obligations des fournisseurs de modèles et celles relatives aux systèmes en aval sont liées, mais pas interchangeables.

Construire un inventaire des cas d’usage qui éclaire les décisions

Inventoriez les fonctions métier, et pas seulement les fournisseurs. Interrogez les achats, les RH, le produit, les opérations et l’informatique : l’IA peut arriver par une nouvelle fonctionnalité d’un fournisseur existant plutôt que par un achat dédié.

Pour chaque cas d’usage, consignez :

Consignez les processus réels à côté de la destination prévue. Un outil présenté comme une « aide aux recruteurs » peut en pratique écarter des candidats si le personnel n’examine que sa liste restreinte. Une politique écrite exigeant une revue humaine ne prouve pas que cette revue a lieu.

Le livrable est un enregistrement versionné par cas d’usage. Les classifications non tranchées doivent rester visiblement non tranchées, avec un responsable et une date limite de décision, plutôt que de basculer par défaut dans la catégorie la moins exigeante.

Évaluer séparément les interdictions, les voies vers le haut risque et la transparence

La description familière en quatre niveaux (pratiques interdites, haut risque, obligations de transparence et risque plus faible) est une introduction utile. Ce n’est pas un arbre de décision complet. Les obligations de transparence peuvent se cumuler avec les obligations applicables au haut risque, et les obligations de maîtrise de l’IA ne se limitent pas aux systèmes à haut risque.

Examiner d’abord les pratiques interdites

L’article 5 interdit certaines pratiques, sous réserve des conditions et exceptions détaillées de la disposition. Les questions d’examen pertinentes consistent notamment à déterminer si un système recourt à une manipulation préjudiciable ou exploite des vulnérabilités, procède à une notation sociale interdite, constitue des bases de données de reconnaissance faciale par moissonnage non ciblé ou réalise une catégorisation biométrique interdite.

L’inférence des émotions par l’IA à partir de données biométriques sur le lieu de travail et dans les établissements d’enseignement est également interdite, sauf pour des raisons médicales ou de sécurité déterminées. Une analyse de sentiment portant uniquement sur du texte ne relève pas de cette interdiction au seul motif qu’elle évalue la tonalité émotionnelle. Certains usages biométriques à des fins répressives obéissent à des règles étroitement encadrées ; « toute reconnaissance faciale est interdite » ne remplace pas exactement une évaluation.

Escaladez toute pratique potentiellement interdite avant l’achat ou le déploiement. Les preuves doivent décrire la fonctionnalité et le raisonnement juridique, et non se contenter de reprendre une déclaration d’« IA éthique » du fournisseur.

Tester les deux voies menant à la classification à haut risque

La voie des produits réglementés, article 6, paragraphe 1 : examinez si l’IA est elle-même un produit, ou un composant de sécurité d’un produit, couvert par la législation pertinente de l’annexe I, et si ce produit doit faire l’objet d’une évaluation de la conformité par un tiers. Les deux conditions comptent. Utilisez le texte juridique modifié pour le régime de produits concerné ; l’intégration d’IA ne suffit pas à elle seule à établir le statut de haut risque.

La voie de l’annexe III, article 6, paragraphe 2 : examinez si la fonction prévue correspond à un cas d’usage répertorié. Les huit domaines sont des intitulés larges, et non des règles qui rendraient à haut risque toute application d’un secteur.

Lisez les entrées détaillées et leurs exclusions. Par exemple, la détection de la fraude financière est distinguée de l’usage répertorié relatif à la solvabilité, et la vérification des documents de voyage est exclue de l’entrée pertinente relative à l’identification en matière de migration. L’organisation administrative d’une campagne n’équivaut pas à influencer les électeurs.

Évaluer la transparence même lorsque les règles du haut risque ne s’appliquent pas

L’article 50 vise certaines interactions et certaines sorties. Selon le rôle et les circonstances, les obligations portent sur l’information des personnes indiquant qu’elles interagissent avec une IA, le marquage lisible par machine des contenus synthétiques, la divulgation des hypertrucages et certains textes générés par l’IA publiés dans l’intérêt public. Les usages de reconnaissance des émotions et de catégorisation biométrique, lorsqu’ils sont autorisés, comportent aussi des dispositions d’information.

Ne réduisez pas cela à « étiqueter chaque document produit avec l’aide de l’IA ». Déterminez quelle disposition s’applique, qui doit agir et si une exception est pertinente. Conservez comme preuves la formulation des avis, leur emplacement, les dispositifs de marquage des sorties et les résultats des tests.

Traiter l’exception de l’article 6, paragraphe 3, comme une évaluation documentée

Certains systèmes de l’annexe III peuvent échapper à la classification à haut risque en vertu de l’article 6, paragraphe 3. Il ne s’agit pas d’une exemption générale pour les outils comportant un humain quelque part dans le processus.

L’évaluation doit établir si le système présente un risque important de préjudice pour la santé, la sécurité ou les droits fondamentaux, notamment s’il influence de manière significative le résultat de la prise de décision. La disposition identifie des situations portant sur des tâches procédurales étroites, l’amélioration du résultat d’une activité humaine préalablement réalisée, la détection de schémas décisionnels ou d’écarts dans des conditions de revue déterminées, et des tâches préparatoires. Le recours à l’exception exige de remplir au moins l’une de ces conditions et d’établir que le système ne présente pas le risque important visé.

Un fournisseur qui invoque cette exception doit documenter l’évaluation avant de mettre le système sur le marché ou de le mettre en service, et satisfaire à l’obligation d’enregistrement applicable. Point essentiel : un système de l’annexe III qui effectue un profilage de personnes physiques reste à haut risque ; cela ne signifie pas pour autant que tout système de profilage, dans tout contexte, devient automatiquement à haut risque.

Les preuves doivent expliquer quelles informations le système utilise, comment ses sorties influencent les réviseurs et si la tâche prétendument préparatoire détermine qui bénéficie d’un examen sur le fond. Incluez des observations du processus et des sorties représentatives. Une phrase du type « un humain prend la décision finale » est insuffisante si le classement, le filtrage ou les recommandations déterminent de fait cette décision.

Planifier en fonction des dates d’application actuelles

D’après la vérification effectuée le 7 octobre 2026, la présentation actuelle du règlement sur l’IA et de son calendrier par la Commission européenne mentionne les jalons suivants :

Vérifiez le texte juridique modifié et les dispositions transitoires qui vous concernent. Les systèmes existants, les dates de mise sur le marché des modèles, les modifications et certaines configurations d’opérateurs peuvent exiger une analyse supplémentaire. Des guides plus anciens peuvent encore indiquer des dates antérieures pour le haut risque.

N’interprétez pas le calendrier mis à jour pour le haut risque comme un report de l’ensemble du règlement. Budgétez séparément les obligations déjà applicables et la préparation au régime du haut risque pertinent. Votre registre doit indiquer le jalon applicable et la source utilisée pour l’établir.

Transformer la classification en plan de preuves

Les responsabilités du fournisseur et du déployeur sont différentes. La direction doit exiger un plan propre à chaque rôle plutôt que d’attribuer chaque obligation à chaque équipe.

Si vous fournissez un système à haut risque

Les exigences applicables au haut risque et les obligations des fournisseurs couvrent la gestion des risques, la gouvernance des données, la documentation technique, la tenue de registres, l’information des déployeurs, le contrôle humain, l’exactitude, la robustesse, la cybersécurité et la gestion de la qualité. Les procédures applicables d’évaluation de la conformité, de déclaration, de marquage, d’enregistrement, de surveillance après commercialisation et de gestion des incidents doivent également être planifiées.

Traduisez-les en livrables :

• Une évaluation des risques sur l’ensemble du cycle de vie, avec mesures d’atténuation, risques résiduels et décisions d’approbation.
• Des enregistrements sur la provenance, l’adéquation et la qualité des données lorsqu’ils sont pertinents pour le système.
• Une documentation technique précisant la destination, la conception, les dépendances, les limites et les méthodes d’évaluation.
• Des résultats de tests rattachés à des critères d’acceptation et au contexte de déploiement.
• Des instructions de contrôle humain expliquant l’intervention, la neutralisation et l’escalade.
• Des spécifications de journalisation, des dispositifs de surveillance et des procédures de gestion des incidents.
• Un plan de travail de mise en conformité identifiant la procédure applicable et les enregistrements requis.

Tous les systèmes à haut risque ne suivent pas la même procédure d’évaluation. Ne budgétez pas un audit tiers universel et ne considérez pas une certification de sécurité comme une preuve de conformité au règlement sur l’IA.

Si vous déployez un système à haut risque

Concentrez-vous sur l’utilisation du système conformément aux instructions, l’attribution d’un contrôle humain à des personnes compétentes, la surveillance de son utilisation et la tenue des registres requis. Traitez l’adéquation des données d’entrée lorsque vous les maîtrisez, ainsi que les exigences applicables d’information des travailleurs ou des personnes concernées.

Demandez aux fournisseurs les instructions, limites, exigences de contrôle humain et informations de conformité pertinentes. Identifiez ce qu’ils ne peuvent pas fournir et qui comblera l’écart. Une déclaration d’assurance d’un fournisseur n’établit pas que votre configuration locale est appropriée.

Évaluez si une analyse d’impact sur les droits fondamentaux est requise pour votre catégorie de déployeur et votre cas d’usage. Elle n’est pas universelle pour tous les déploiements. Lorsque des données à caractère personnel sont concernées, évaluez séparément les exigences du RGPD ; une analyse d’impact relative à la protection des données et une évaluation au titre du règlement sur l’IA poursuivent des finalités juridiques différentes, même lorsque les preuves se recoupent.

Pour chaque livrable, précisez un responsable, un réviseur, une échéance, l’emplacement de la source et un critère d’acceptation. « Politique téléversée » n’équivaut pas à « mesure démontrée ».

Exemple concret : un modèle, deux décisions métier

Hypothèses illustratives : un employeur de l’Union utilise un modèle de langage tiers pour un assistant de rédaction interne et pour une application de recrutement distincte. L’application de recrutement note les candidats au regard des critères du poste et présente une liste restreinte classée. L’employeur utilise les deux en interne ; ses rôles précis d’opérateur doivent être examinés.

Pour l’assistant de rédaction, consignez les tâches de rédaction autorisées, les restrictions sur les données, la revue des sorties et les éventuelles exigences de transparence applicables. Une rédaction interne ordinaire ne devient pas à haut risque au seul motif qu’elle utilise l’IA. Une extension à l’évaluation en matière d’emploi déclencherait une réévaluation.

Pour le recrutement, l’entrée de l’annexe III relative à l’emploi est directement pertinente. Examinez la notation et le profilage des candidats, et pas seulement la description de l’interface. Si les recruteurs n’examinent que les candidats de la liste restreinte, le système façonne de manière significative l’accès à l’emploi. L’approbation humaine de l’embauche finale ne supprime pas cette influence.

La décision de la direction diffère donc pour chaque application. L’assistant de rédaction peut être poursuivi avec des mesures proportionnées après revue. Le projet de recrutement nécessite un plan de préparation au haut risque, des preuves du fournisseur, un contrôle humain formé, une évaluation de l’usage local et une décision de mise en service documentée.

Si l’équipe propose de transformer la fonction de recrutement en planification des entretiens, évaluez à nouveau cette nouvelle finalité et ce nouveau processus. La planification peut constituer une tâche procédurale étroite, mais conserver en arrière-plan la notation des candidats saperait la nouvelle justification. Versionnez la décision plutôt que d’écraser l’enregistrement d’origine.

Rendre la responsabilité visible dans les décisions opérationnelles

Désignez un responsable métier capable d’expliquer la finalité et d’approuver les ressources, un responsable technique capable d’étayer le comportement du système et un réviseur juridique ou conformité capable de contester la classification. L’approbation de la direction doit trancher le financement, les restrictions de mise en service et les risques non résolus, et non remplacer l’analyse des spécialistes.

À titre de recommandation pratique, revoyez la classification lorsque la finalité, les utilisateurs, les données, les intégrations, le degré d’autonomie ou l’influence sur des décisions lourdes de conséquences changent. Rattachez cette revue aux renouvellements d’achats et aux mises en production. Une mise à jour du modèle ne modifie pas forcément à elle seule la classification, mais elle peut invalider des preuves d’évaluation ou des hypothèses d’exploitation.

Parmi les erreurs courantes figurent l’acceptation des classifications générales des fournisseurs, l’idée qu’une revue humaine crée automatiquement une exemption, l’oubli des obligations de maîtrise de l’IA et de transparence déjà applicables, et la collecte de documents sans tester le fonctionnement local. Un système de management ISO/IEC 42001 peut soutenir la gouvernance, mais une certification n’établit pas automatiquement la conformité au règlement sur l’IA.

Secani peut soutenir le processus de preuves en reliant les exigences, les mesures, les sources, les responsables, les tâches et les décisions revues. Commencez par un processus, rattachez les preuves à ce qu’elles démontrent et conservez les commentaires, validations et horodatages avec les conclusions significatives. Traitez les suggestions assistées par l’IA comme des brouillons soumis à une revue humaine, et non comme des déterminations juridiques. Notre guide de gouvernance des agents d’IA propose des mesures pratiques en matière d’autorisations et de revue.

La prochaine étape utile est un atelier de classification ciblé : sélectionnez les cas d’usage en production aux conséquences les plus importantes, réunissez leurs responsables métier et techniques et produisez des enregistrements revus, avec les questions non résolues et les tâches de collecte de preuves. La direction dispose ainsi d’une base défendable pour décider de ce qui peut avancer, de ce qui doit être assorti de conditions et de ce qui nécessite une évaluation complémentaire.