Règlement UE sur l'IA : Exigences en matière de tests de robustesse expliquées

Le Règlement UE sur l'IA impose que les systèmes d'IA à haut risque subissent des tests de robustesse rigoureux pour garantir des performances fiables en cas d'erreurs, de défaillances ou de conditions inattendues. Cette exigence, détaillée dans l'Article 15, s'applique aux systèmes des secteurs critiques tels que la santé, les transports et l'application de la loi. Voici ce que vous devez savoir :

• Définition de la robustesse : Capacité des systèmes d'IA à maintenir des performances constantes malgré des perturbations, comme indiqué dans la norme ISO/IEC 25059:2023.
• Systèmes d'IA à haut risque : Inclut les systèmes d'IA utilisés en biométrie, infrastructures critiques, éducation, emploi, et plus, comme énuméré à l'Annexe III. Leur application commence le 2 août 2026.
• Protocoles de test : Comprend les tests adversariaux, les tests de résistance et le red teaming pour identifier les vulnérabilités.
• Documentation : Les fournisseurs doivent préparer des dossiers techniques détaillés, réaliser des évaluations de conformité et conserver les enregistrements pendant 10 ans.
• Surveillance post-déploiement : Suivi continu des performances et protection contre les boucles de rétroaction nuisibles.

Le non-respect de la liste de vérification de conformité au Règlement UE sur l'IA peut entraîner des amendes pouvant aller jusqu'à 38 millions d'euros ou 7 % du chiffre d'affaires annuel mondial. Commencez dès maintenant à vous préparer pour respecter ces exigences avant la date limite d'application.

::: @figure {Exigences en matière de tests de robustesse et échéances de conformité du Règlement UE sur l'IA} :::

Systèmes d'IA à haut risque et applicabilité

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

Le Règlement UE sur l'IA définit les systèmes d'IA à haut risque selon deux approches principales. Tout d'abord, il inclut les systèmes d'IA qui agissent comme des composants de sécurité dans des produits régis par les lois d'harmonisation de l'UE (listés à l'Annexe I). Parmi les exemples figurent les machines, les dispositifs médicaux et les systèmes automobiles, où une défaillance pourrait présenter des risques pour la santé ou la sécurité [7]. Ensuite, il couvre les systèmes énumérés à l'Annexe III, couvrant huit domaines pouvant impacter les droits fondamentaux [7][8].

Ces huit catégories de l'Annexe III sont :

• Biométrie : Systèmes comme l'identification à distance et la reconnaissance des émotions.
• Infrastructures critiques : Outils de gestion du trafic routier ou des services publics (par exemple, eau, gaz, électricité).
• Éducation : IA utilisée dans les décisions d'admission ou la surveillance des examens.
• Emploi : Applications telles que le tri des CV, les décisions de promotion et la surveillance des employés.
• Services essentiels : Systèmes d'évaluation de crédit ou de tarification de l'assurance.
• Application de la loi : Outils comme les polygraphe ou les modèles de prédiction de récidive.
• Migration et contrôle aux frontières : IA utilisée dans le traitement des visas.
• Justice et démocratie : Systèmes développés pour assister les autorités judiciaires [7][8].

Cependant, tous les systèmes de ces catégories ne sont pas automatiquement considérés comme à haut risque. L'Article 6 prévoit des exemptions si un système effectue des tâches strictement définies ou soutient des activités menées par des humains sans influencer significativement les décisions, à condition qu'il n'y ait pas de profilage. Pour revendiquer cette exemption, les organisations doivent documenter leur évaluation à l'aide d'un assistant de politique et enregistrer le système dans la base de données de l'UE avant sa mise sur le marché [8]. En revanche, si un système d'IA effectue un profilage d'individus dans un domaine de l'Annexe III, il reste classé comme à haut risque [8].

Pour tous les systèmes à haut risque, l'Article 15 impose des tests de robustesse pour garantir des performances fiables tout au long de leur cycle de vie [4]. L'application de ces exigences pour les systèmes de l'Annexe III commence le 2 août 2026 [8].

Ce cadre de classification sous-tend les normes strictes de robustesse requises par le Règlement UE sur l'IA.

IA à usage général et risque systémique

Le Règlement aborde également les modèles d'IA à usage général (GPAI), qui ne sont pas intrinsèquement à haut risque. Cependant, lorsque ces modèles sont intégrés dans des systèmes à haut risque - comme l'utilisation d'un grand modèle de langage dans le recrutement ou les infrastructures critiques - ils doivent se conformer aux normes des systèmes à haut risque [9][8]. De plus, les modèles GPAI identifiés comme présentant un « risque systémique » sont soumis à des exigences spécifiques de robustesse, y compris des tests adversariaux [9].

Pour être qualifié de risque systémique, la puissance de calcul cumulée d'entraînement du modèle doit dépasser 10^25 FLOPs [9]. Comme pour les autres systèmes à haut risque, ces modèles doivent subir des évaluations détaillées et des tests adversariaux pour détecter les vulnérabilités [6]. Les règles pour les modèles GPAI entrent en vigueur le 2 août 2025, soit un an plus tôt que les exigences plus larges pour les systèmes à haut risque [9].

Mesures techniques et organisationnelles pour la robustesse

Renforcement technique

L'Article 15 du Règlement UE sur l'IA souligne l'importance de la résilience dans les systèmes d'IA à haut risque, garantissant qu'ils peuvent résister aux perturbations opérationnelles. Ces systèmes doivent gérer les erreurs, les défaillances ou les incohérences dans leur environnement, même en cas de défaillances matérielles, d'entrées corrompues ou de comportements inattendus des utilisateurs [1].

Une approche clé pour atteindre la résilience est la redondance technique. Par exemple, la conteneurisation peut isoler les opérations du système, maintenant la fiabilité même en cas de problèmes d'infrastructure [2]. Dans des contextes critiques, concevoir une dégradation contrôlée - où le système passe en mode manuel ou sur des systèmes de secours au lieu de s'arrêter complètement - ajoute une couche supplémentaire de fiabilité.

Les vulnérabilités spécifiques à l'IA nécessitent également une attention particulière. Les menaces telles que l'empoisonnement des données (altération des données d'entraînement), l'empoisonnement des modèles (intégration de code malveillant pendant l'entraînement) et les exemples adversariaux (entrées conçues pour tromper l'IA) nécessitent des défenses solides [2]. Le cadre MITRE ATLAS fournit des outils pour tester et atténuer ces risques [2]. De plus, des systèmes de surveillance et d'alerte automatisés peuvent identifier les problèmes de performance ou de disponibilité en temps réel. Des outils spécialisés comme ISMS Copilot One peuvent aider à automatiser ces flux de travail complexes de conformité.

Pour les systèmes d'IA qui continuent d'apprendre après leur déploiement, les boucles de rétroaction posent des défis uniques. Si des sorties biaisées alimentent les données d'entraînement ultérieures, ces biais peuvent s'aggraver. Pour y remédier, des mesures telles que la curation sélective des données et la limitation de l'intégration des retours du monde réel sont essentielles [1]. La journalisation des événements, requise par l'Article 12, aide à suivre les changements de performance et à détecter les problèmes potentiels [8].

Ces mesures techniques de sauvegarde fonctionnent de concert avec les mesures organisationnelles pour garantir que les systèmes restent équitables et non biaisés.

Traitement des biais et équité

L'atténuation des biais n'est pas seulement une responsabilité éthique, mais aussi une obligation légale selon le Règlement. Les systèmes d'IA à haut risque doivent fonctionner équitablement entre tous les groupes démographiques, en particulier dans des domaines sensibles comme l'emploi, l'éducation ou l'accès aux services essentiels [8].

Des audits réguliers d'équité sont essentiels. Par exemple, si un outil de tri de CV ne tient pas compte des parcours professionnels ou des antécédents éducatifs divers, il pourrait désavantager injustement certains groupes. De telles violations pourraient entraîner des pénalités pouvant aller jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial [10].

La supervision humaine, comme le prévoit l'Article 14, est un autre composant essentiel. Les humains doivent comprendre les limites du système, éviter de faire aveuglément confiance à ses sorties (biais d'automatisation) et intervenir si nécessaire [8]. Une approche efficace consiste à concevoir un système uniquement consultatif, où les sorties de l'IA sont revues par des humains avant toute action.

Pour traiter les biais de manière systématique, établissez un Système de Management de la Qualité (SMQ) selon l'Article 17. Celui-ci doit inclure des politiques écrites pour identifier et corriger les biais, ainsi qu'une gestion continue des risques tout au long du cycle de vie du système d'IA. La surveillance post-commercialisation est essentielle pour évaluer les performances réelles, tandis que les journaux automatisés - conservés pendant au moins six mois - créent une piste d'audit pour les investigations en cas d'incident [8].

Tests et validation pour la robustesse

Protocoles de tests de robustesse

Pour garantir que les systèmes d'IA sont prêts pour le déploiement, le Règlement UE sur l'IA impose des tests rigoureux avant la mise en service, en particulier pour les systèmes à haut risque. Ces tests sont conçus pour confirmer la résilience face aux erreurs, aux défaillances et aux attaques potentielles [1].

Les tests adversariaux sont une exigence clé pour les systèmes d'IA à usage général présentant des risques systémiques, ainsi que pour les systèmes à haut risque. Cette approche consiste à simuler des attaques telles que l'injection de prompts, l'empoisonnement des données et l'évasion de modèle pour évaluer la capacité du système à résister à de telles menaces [10][11]. Une autre méthode essentielle est le red teaming, où des experts internes ou externes tentent activement de pirater le système, fournissant une évaluation complète de la sécurité [10].

Les tests de résistance évaluent comment les systèmes gèrent des scénarios extrêmes ou inhabituels, tels que des cas limites ou des injections de défaillances intentionnelles, garantissant que les échecs se produisent de manière contrôlée et prévisible [10][11].

Méthode de test	Description	Vulnérabilités ciblées
Tests adversariaux	Simule des attaques pour manipuler les entrées ou les données d'entraînement	Injection de prompts, empoisonnement des données/modèles, évasion de modèle [10][3]
Tests de résistance	Évalue le comportement dans des conditions extrêmes ou inhabituelles	Échecs de cas limites, incohérences environnementales [11][8]
Tests de biais	Analyse les résultats entre différents groupes démographiques	Schémas discriminatoires, boucles de rétroaction [11]
Red teaming	Évaluation de la sécurité par des équipes internes ou externes	Accès non autorisé, extraction de modèle, risques systémiques [10]

Pour minimiser les biais dans les sorties, les ensembles de données de test doivent être soigneusement sélectionnés pour être pertinents, représentatifs et aussi exempts d'erreurs que possible [1][11]. De plus, les fournisseurs doivent déclarer des seuils spécifiques de précision et de résilience dans leurs instructions d'utilisation, conformément aux normes de la Commission européenne [1][3].

« L'assurance qualité n'est plus facultative - c'est la base de la conformité réglementaire. Les organisations doivent prouver que leurs systèmes d'IA sont sûrs, équitables et fiables avant de pouvoir entrer sur le marché de l'UE. »

• Igor Kovalenko, Responsable QA, TestFort [11]

Une fois ces protocoles de pré-déploiement terminés, la surveillance continue garantit que les systèmes restent robustes après leur déploiement.

Surveillance continue après le déploiement

Les tests ne s'arrêtent pas une fois qu'un système d'IA est déployé. Selon l'Article 72, les fournisseurs doivent mettre en place des systèmes de surveillance post-commercialisation qui recueillent, documentent et analysent en continu les données de performance tout au long du cycle de vie du système [4][12]. Cela garantit que le système s'adapte aux conditions réelles évolutives tout en maintenant son intégrité.

Les systèmes d'IA à haut risque doivent enregistrer les événements pendant au moins six mois. Ces journaux aident à suivre les performances, à identifier les risques potentiels et à documenter les changements significatifs [6][8][12]. Des outils comme la détection d'anomalies peuvent signaler des changements inattendus de données ou du bruit qui pourraient compromettre la robustesse du système [2][5].

Pour les systèmes qui apprennent en continu, des mesures de sauvegarde doivent être mises en place pour éviter les boucles de rétroaction, où des sorties biaisées pourraient influencer les futures données d'entraînement [4][2][1]. Les outils de surveillance suivent la détérioration des performances au fil du temps, tandis que la conteneurisation garantit des environnements stables et reproductibles pour l'exécution du système [2].

Les fournisseurs et les utilisateurs doivent signaler les incidents [6][12]. De plus, des mécanismes de supervision humaine, tels que des procédures de « bouton d'arrêt », permettent une intervention immédiate en cas de problème [8].

« Le Règlement UE sur l'IA exige une surveillance continue après le déploiement, et pas seulement des tests ponctuels. Les systèmes d'IA à haut risque ont besoin de journaux automatisés et de réponses aux incidents intégrés dès le départ. »

• Oleg Sivograkov, Vice-président des opérations informatiques, TestFort [11]

La date d'application de ces exigences est fixée au 2 août 2026 [8]. Le non-respect de ces exigences pourrait entraîner des pénalités sévères, y compris des amendes pouvant aller jusqu'à 38 millions d'euros ou 7 % du chiffre d'affaires annuel mondial [10].

Partie 2 : Naviguer dans le Règlement UE sur l'IA : Les essentiels de la conformité pour les systèmes d'IA à haut risque

::: @iframe https://www.youtube.com/embed/wsr6d6WG5Uo :::

Documentation et reporting de conformité

Après des tests rigoureux et une surveillance continue, une documentation appropriée est essentielle pour garantir que la conformité est maintenue.

Normes de documentation technique

Avant d'introduire un produit sur le marché, vous devez préparer un dossier technique conforme aux normes de l'Annexe IV. Ce dossier doit démontrer clairement la conformité aux exigences de robustesse de l'Article 15 [13]. Le dossier doit inclure neuf sections, la Section 4 se concentrant spécifiquement sur les métriques de performance. Il doit détailler les résultats des tests de robustesse, les méthodes de validation et le raisonnement derrière les métriques choisies [13].

La création de cette documentation peut prendre entre 40 et 80 heures, à condition que les données de conformité soient déjà intégrées dans le processus de développement à l'aide d'un assistant d'implémentation IA [13]. Des outils comme MLflow peuvent rationaliser ce processus en capturant les journaux, les pistes d'audit et les décisions de conception directement dans votre flux de travail.

Votre dossier technique doit également inclure :

• Documentation de la gestion des risques (Article 9)
• Enregistrements de gouvernance des données (Article 10) expliquant comment les ensembles de données ont été utilisés pour évaluer les biais
• Un plan de surveillance post-commercialisation (Article 72)
• Des instructions détaillant les niveaux de robustesse et les limitations [1]

Toute la documentation technique doit être conservée pendant 10 ans après l'entrée du produit sur le marché. Le non-respect de cette obligation peut entraîner des pénalités pouvant aller jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial [13].

Évaluations de conformité et marquage CE

Une fois le dossier technique terminé, l'étape suivante consiste à prouver la conformité par une évaluation de conformité. La plupart des systèmes d'IA à haut risque peuvent être auto-évalués dans le cadre du processus de contrôle interne décrit à l'Annexe VI [15]. Cependant, les systèmes utilisés dans des domaines sensibles comme la biométrie, les infrastructures critiques ou l'application de la loi nécessitent une évaluation externe par un organisme notifié. Ces évaluateurs tiers sont autorisés à examiner votre documentation et à vérifier la conformité [14].

Les organismes notifiés peuvent demander des preuves supplémentaires ou effectuer des tests indépendants s'ils estiment que vos tests de robustesse sont insuffisants [14]. Ils vérifieront que des mesures telles que la redondance, les plans de secours et les dispositifs de sécurité sont documentées et mises en œuvre [1]. Pour les systèmes d'IA qui continuent d'apprendre après leur déploiement, ils vérifieront également les mesures de protection contre les boucles de rétroaction qui pourraient introduire des biais dans les futures données d'entraînement [1].

Type d'évaluation	Qui la réalise	Quand est-elle requise	Certificat délivré
Contrôle interne (Annexe VI)	Fournisseur (auto-évaluation)	La plupart des systèmes à haut risque (Annexe III, points 2-8)	Déclaration UE de conformité
Organisme notifié (Annexe VII/VIII)	Évaluateur tiers	Biométries, infrastructures critiques, application de la loi	Certificat d'évaluation technique de la documentation de l'Union

Étant donné que les évaluations par des organismes notifiés peuvent prendre de 6 à 18 mois, les fournisseurs de systèmes critiques pour la sécurité ou biométriques doivent initier le processus bien avant la date limite du 2 août 2026 [16]. Soyez prêt à fournir un accès aux ensembles de données d'entraînement, de validation et de test via une API ou d'autres moyens techniques si nécessaire [14].

Une fois l'évaluation terminée avec succès, vous devez émettre une Déclaration UE de conformité et apposer le marquage CE sur votre système ou sa documentation [15]. Ce marquage sert de preuve légale que votre système répond aux normes de robustesse. Si des modifications significatives sont apportées - telles que des changements affectant la conformité ou l'objectif prévu du système - vous devrez mettre à jour la documentation et éventuellement subir une nouvelle évaluation de conformité [13].

« Le dossier technique doit être établi de manière à démontrer que le système d'IA à haut risque est conforme aux exigences [...] et à fournir aux autorités nationales compétentes et aux organismes notifiés les informations nécessaires sous une forme claire et complète pour évaluer la conformité. »

• Article 11, Règlement (UE) 2024/1689 [13]

Les évaluations de conformité, associées à une surveillance continue, forment un cadre de conformité complet, garantissant que les systèmes d'IA à haut risque répondent aux normes de robustesse tout au long de leur cycle de vie.

Robustesse vs. Cybersécurité : Différences clés

Examinons comment le Règlement UE sur l'IA différencie la robustesse de la cybersécurité - deux concepts qui peuvent sembler similaires mais servent des objectifs très différents.

La distinction réside dans l'intention. La robustesse, telle que définie dans l'Article 15 [1], traite des perturbations non intentionnelles. Il peut s'agir d'erreurs naturelles, de défaillances ou d'incohérences qui surviennent lors du fonctionnement normal du système. En revanche, la cybersécurité, abordée dans l'Article 15 [3], se concentre sur les attaques malveillantes intentionnelles. Cela inclut des scénarios où des tiers non autorisés tentent activement de manipuler ou de compromettre les performances du système. Alors que les sections précédentes couvraient comment tester la robustesse, cette partie met en lumière la séparation entre la résilience interne et les menaces externes.

Sur le plan technique, la robustesse en apprentissage automatique fait référence à la résilience non adversariale. Cela implique de tester la capacité d'un système d'IA à gérer des défis tels que des décalages de distribution, des changements environnementaux ou des boucles de rétroaction - où les sorties du modèle influencent les futures données d'entraînement. La cybersécurité, en revanche, se concentre sur la résilience adversariale, protégeant contre des menaces comme l'empoisonnement des données, les attaques d'évasion ou même les violations qui compromettent la confidentialité du modèle, comme le vol.

Henrik Nolte de l'Université de Tübingen explique clairement cette distinction :

« Le Règlement IA divise artificiellement le concept de cybersécurité du CSA en désignant les causes non intentionnelles comme une question de robustesse et en restreignant la cybersécurité aux actions intentionnelles. »

Pour la conformité, la robustesse et la cybersécurité nécessitent des stratégies différentes. Les organisations peuvent former des assistants de conformité IA pour gérer ces complexités. La robustesse repose sur des mesures telles que la redondance technique et la surveillance continue pour garantir que les systèmes peuvent gérer les perturbations non intentionnelles. La cybersécurité, quant à elle, exige des défenses actives comme la détection des menaces, le chiffrement et l'entraînement adversarial pour contrer les attaques délibérées. Le maintien des deux tout au long du cycle de vie d'un système d'IA implique d'évaluer chaque composant individuellement pour garantir une protection complète.

Conclusion et points clés à retenir

Pour conclure, mettons en avant les étapes essentielles pour garantir que vos systèmes d'IA sont fiables et conformes aux réglementations à venir.

Les tests de robustesse sont un pilier pour garantir que les systèmes d'IA à haut risque fonctionnent de manière cohérente dans des conditions pratiques. Avec l'application des exigences de l'Annexe III fixée au 2 août 2026 [8], les organisations doivent agir dès maintenant pour établir des repères de performance, intégrer des mécanismes de redondance et mettre en œuvre une surveillance continue tout au long du cycle de vie de l'IA.

Le concept de robustesse dépend fortement du contexte. Vous devrez définir des métriques de performance qui correspondent à l'objectif spécifique de votre système et anticiper les perturbations telles que la dérive des données, les changements environnementaux ou les boucles de rétroaction. Les protocoles de test doivent être adaptés à l'utilisation spécifique, aux propriétés des données et à l'environnement de déploiement de chaque système d'IA.

Commencez par établir des bases de performance claires dans des conditions normales. Ensuite, testez méthodiquement comment votre système réagit à divers défis ou perturbations. Incorporez des mesures de redondance - telles que des systèmes de secours et des dispositifs de sécurité - et assurez-vous que des mécanismes de supervision humaine sont en place pour intervenir en cas d'anomalies. De plus, vos systèmes de journalisation doivent soutenir la conformité en fournissant des pistes d'audit infalsifiables et immuables.

Selon l'Article 11, les fournisseurs sont principalement responsables de la réalisation des évaluations de conformité et de la préparation de la documentation technique, tandis que les utilisateurs doivent gérer la supervision humaine et maintenir des pratiques rigoureuses de conservation des journaux. Les deux rôles partagent la responsabilité de maintenir la robustesse du système tout au long de son cycle de vie.

Rationaliser la conformité avec ISMS Copilot

Des outils de conformité avancés comme ISMS Copilot peuvent simplifier ces étapes critiques.

ISMS Copilot est conçu pour aider à la conformité avec le Règlement UE sur l'IA en analysant votre documentation technique existante et vos évaluations d'impact pour identifier les lacunes dans les exigences de robustesse. La plateforme aide à rédiger la documentation technique détaillée de l'Article 11 que les régulateurs examineront, couvrant tout, des descriptions des systèmes aux protocoles de surveillance.

Pour les tâches réglementaires liées au Règlement UE sur l'IA, la plateforme utilise les modèles de Mistral, spécialement formés sur les réglementations européennes. Ces modèles fournissent des informations détaillées sur les exigences du Règlement. Vous pouvez créer des espaces de travail individuels pour chaque système d'IA, garantissant des pistes d'audit claires et des efforts de conformité organisés. Lors de l'utilisation de la plateforme, incluez des détails tels que l'utilisation prévue de votre système, les types de données et la classification des risques pour recevoir des conseils adaptés à vos besoins de conformité.

Une fonctionnalité phare d'ISMS Copilot est son outil d'analyse des écarts, particulièrement utile pour les tests de robustesse. En téléchargeant vos évaluations des risques actuelles et vos protocoles de test, la plateforme identifie les composants manquants et propose un plan de remédiation priorisé. Cela vous aide à allouer efficacement les ressources et à combler les lacunes critiques de conformité avant la date limite d