Exigences relatives aux données d’entraînement : article 10

S’il est une disposition du règlement sur l’IA qui forcera les organisations à changer la façon dont elles construisent des systèmes d’IA, c’est l’article 10. Pas parce qu’il interdit quoi que ce soit. Pas parce qu’il inflige une amende. Mais parce qu’il entre dans la chaîne d’apprentissage automatique elle-même et prescrit comment les données d’entraînement doivent être collectées, préparées, documentées et gouvernées, avant même que le système n’arrive sur le marché. Pour les fournisseurs de systèmes d’IA à haut risque, l’article 10 transforme la gouvernance des données d’une bonne pratique interne en obligation juridique. Pour les fournisseurs de modèles d’IA à usage général (GPAI), un régime de transparence parallèle au titre de l’article 53 exige des résumés détaillés des données d’entraînement. Ce guide décortique chaque exigence, explique à quoi ressemble la conformité en pratique, et vous donne les étapes pour y parvenir avant l’échéance du 2 décembre 2027.

L’essentiel, les points clés des exigences relatives aux données d’entraînement

• Qui : tout fournisseur d’un système d’IA à haut risque (classé au titre de l’annexe III ou d’une législation sectorielle) et tout fournisseur d’un modèle GPAI.
• Quoi : l’article 10, intitulé « Données et gouvernance des données », impose des pratiques de gouvernance et de gestion des données couvrant tout le cycle de vie des données : conception, collecte, préparation, étiquetage, nettoyage, enrichissement, agrégation, examen des biais, identification des lacunes, et documentation.
• Quand : les obligations des systèmes d’IA à haut risque s’appliquent à compter du 2 décembre 2027 (reportées du 2 août 2026 par le Digital Omnibus, règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). Pour l’annexe I, l’échéance est le 2 août 2028. L’article 50 reste au 2 août 2026. Les obligations GPAI s’appliquent déjà depuis le 2 août 2025, avec une échéance transitoire au 2 août 2027 pour les modèles déjà sur le marché.
• Jeux couverts : jeux de données d’entraînement, de validation et de test, les trois.
• Obligation relative aux biais : les jeux doivent être examinés pour d’éventuels biais, et les fournisseurs doivent prendre des mesures appropriées pour les détecter, les prévenir et les atténuer.
• Catégories particulières de données : l’article 10, paragraphe 5, crée une base juridique pour traiter des données à caractère personnel autrement interdites (origine raciale, sexe, santé, etc.) lorsque c’est strictement nécessaire au suivi des biais, sous de strictes garanties.
• Transparence GPAI : l’article 53, paragraphe 1, point d), exige des fournisseurs de GPAI qu’ils publient un résumé suffisamment détaillé du contenu utilisé pour l’entraînement, selon le modèle normalisé de l’Union publié en juillet 2025.
• Documentation : toutes les pratiques de gouvernance des données doivent être consignées dans la documentation technique de l’annexe IV, rubrique 2.

Pourquoi la gouvernance des données est le fondement de la conformité

Tout système d’IA apprend à partir de données. La qualité, la représentativité et l’équité de ces données déterminent si le système fonctionne correctement, échoue en silence, ou nuit activement aux personnes. Le législateur de l’Union l’a compris en rédigeant le règlement, et a fait de la gouvernance des données l’une des exigences les plus détaillées et les plus prescriptives de tout le texte.

Le principe est simple : données médiocres, sorties médiocres. Une IA de recrutement entraînée sur des données d’embauche historiques teintées de biais de genre reproduira ce biais à grande échelle. Un système de diagnostic médical entraîné sur des jeux qui sous-représentent certains groupes ethniques produira des diagnostics moins exacts pour ces populations. Un modèle d’évaluation de la solvabilité entraîné sur des données qui confondent géographie et solvabilité désavantagera systématiquement les demandeurs de certains codes postaux. Dans chaque cas, le préjudice naît dans les données.

L’article 10 se situe au centre de l’architecture d’exigences du règlement. Il se relie directement à :

• Article 9 (système de gestion des risques) : les risques liés aux données doivent être identifiés et atténués dans le système de gestion des risques.
• Article 11 (documentation technique) : les pratiques de gouvernance des données doivent être consignées à l’annexe IV, rubrique 2.
• Article 13 (transparence) : les déployeurs doivent être informés des données sur lesquelles le système a été entraîné.
• Article 15 (exactitude, robustesse, cybersécurité) : les indicateurs d’exactitude n’ont de sens que s’ils sont calculés sur des données représentatives, correctement étiquetées.
• Article 72 (surveillance après mise sur le marché) : le suivi continu doit détecter la dérive des données et la dégradation dans le temps.

Vous ne pouvez donc pas satisfaire le règlement sur l’IA sans satisfaire l’article 10. Ce n’est pas une exigence parmi d’autres ; c’est le fondement sur lequel chaque autre exigence technique repose.

L’échéance du 2 décembre 2027 s’applique à toutes les obligations des systèmes d’IA à haut risque, y compris l’article 10, reportée du 2 août 2026 par le Digital Omnibus (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). Si vous construisez un système qui entre dans l’annexe III, identification biométrique, infrastructures critiques, éducation, emploi, accès à des services essentiels, services répressifs, migration ou administration de la justice, vos pratiques relatives aux données d’entraînement doivent satisfaire ces exigences avant cette date. Pour les systèmes de l’annexe I, l’échéance est le 2 août 2028. Commencez maintenant. Une documentation après coup prend deux à trois fois plus longtemps qu’une documentation au fil de l’eau.

L’article 10, les exigences juridiques expliquées

L’article 10 porte le titre « Données et gouvernance des données ». Il s’applique aux systèmes d’IA à haut risque qui font appel à des techniques impliquant l’entraînement de modèles d’IA au moyen de données. C’est l’un des articles les plus longs et les plus détaillés du règlement, en cinq paragraphes qui vont des choix de conception aux catégories particulières de données à caractère personnel. Voici ce que chaque paragraphe exige.

Pratiques de gouvernance et de gestion des données (article 10, paragraphe 2)

L’article 10, paragraphe 2, est la disposition centrale. Il dispose que les jeux de données d’entraînement, de validation et de test sont soumis à des pratiques en matière de gouvernance et de gestion des données appropriées à la destination du système d’IA à haut risque. Ces pratiques concernent en particulier les éléments énumérés aux points a) à h).

Le mot « appropriées » compte. Le règlement ne prescrit pas une gestion des données unique. Ce qui est approprié dépend de la destination, du niveau de risque, de l’état de la technique et des caractéristiques propres aux données. Un système de reconnaissance faciale entraîné sur des données biométriques exige une gouvernance différente d’un système de contrôle qualité industriel entraîné sur des images de produits. Mais les deux doivent démontrer que des pratiques de gouvernance existent, sont documentées, et sont proportionnées.

Les huit éléments obligatoires (article 10, paragraphe 2, points a) à h))

(a) Les choix de conception pertinents : Cela couvre les décisions fondatrices sur vos jeux : quelles données inclure, lesquelles exclure, ce que la variable cible représente, quelles sont les caractéristiques d’entrée, comment les données sont structurées. Chaque choix de conception doit être documenté et justifié. Si vous avez décidé d’exclure certaines sources, expliquez pourquoi. Si vous avez choisi une taxonomie d’étiquetage particulière, consignez-la.

(b) Les processus de collecte de données et l’origine des données, ainsi que, dans le cas des données à caractère personnel, la finalité initiale de la collecte : Vous devez savoir d’où viennent vos données. Pour chaque jeu, consignez la source, la méthode de collecte et la période. Pour les données à caractère personnel, vous devez en outre consigner la finalité initiale de la collecte, ce qui a des implications directes pour l’appréciation de la base juridique au titre du RGPD.

(c) Les opérations de traitement pertinentes pour la préparation des données : L’article vise notamment l’annotation, l’étiquetage, le nettoyage, la mise à jour, l’enrichissement et l’agrégation, ainsi que toute autre transformation appliquée aux données brutes (normalisation, encodage, ingénierie des caractéristiques, augmentation, imputation). Chaque opération doit être documentée, y compris le motif du choix et son effet sur le jeu.

(d) La formulation d’hypothèses : Toute hypothèse sous-jacente aux jeux doit être rendue explicite, notamment en ce qui concerne les informations que les données sont censées mesurer et représenter. Si vous supposez que des données historiques sont représentatives des conditions futures, consignez cette hypothèse. Si vous supposez qu’une variable par procuration est corrélée à la variable d’intérêt, consignez cette hypothèse et les preuves qui la soutiennent.

(e) Une évaluation de la disponibilité, de la quantité et de l’adéquation des jeux de données nécessaires : Vous devez évaluer si vous avez assez de données, si ces données conviennent à la destination, et s’il existe des lacunes. Ce n’est pas un contrôle unique ; il doit être réévalué lorsque le système ou ses conditions d’exploitation changent.

(f) Un examen permettant de repérer d’éventuels biais : Examen des jeux, pas seulement des sorties du modèle, pour des biais susceptibles de porter atteinte à la santé et à la sécurité des personnes, d’avoir une incidence négative sur les droits fondamentaux, ou de se traduire par une discrimination interdite par le droit de l’Union.

(g) Les mesures appropriées visant à détecter, prévenir et atténuer les éventuels biais repérés conformément au point f). Pour un guide détaillé de mise en œuvre, voir notre article sur les essais de biais au titre du règlement sur l’IA.

(h) La détection de lacunes ou déficiences pertinentes dans les données qui empêchent l’application du règlement, et la manière dont ces lacunes ou déficiences peuvent être comblées.

Pertinents, représentatifs et, dans toute la mesure possible, exempts d’erreurs (article 10, paragraphe 3)

L’article 10, paragraphe 3, pose trois standards de qualité pour les jeux d’entraînement, de validation et de test :

1. Pertinents : les données doivent être pertinentes au regard de la destination. Un système conçu pour évaluer le risque de crédit doit être entraîné sur des données qui se rapportent réellement à la solvabilité, pas sur des procurations seulement tangentes.

2. Suffisamment représentatifs : les jeux doivent être représentatifs des personnes ou des conditions à l’égard desquelles le système est destiné à être utilisé. Un outil d’embauche déployé dans toute l’Union doit être entraîné sur des données qui représentent la diversité du marché du travail de l’Union, pas sur les données d’un seul pays ou d’un seul groupe démographique.

3. Dans toute la mesure possible, exempts d’erreurs et complets : le règlement utilise un langage réaliste, « dans toute la mesure possible », et reconnaît que des données parfaites n’existent pas. Mais il exige un effort démontrable et documenté pour identifier et corriger les erreurs, traiter les valeurs manquantes, et assurer la complétude.

Ces trois standards créent une obligation continue. Si le contexte d’exploitation change, par exemple si un système entraîné sur des données de santé néerlandaises est déployé en Roumanie, l’appréciation de la représentativité doit être mise à jour.

Prise en compte du cadre géographique, contextuel et comportemental (article 10, paragraphe 4)

L’article 10, paragraphe 4, exige que les jeux tiennent compte, dans la mesure requise par la destination, des caractéristiques ou éléments propres au cadre géographique, contextuel, comportemental ou fonctionnel spécifique dans lequel le système est destiné à être utilisé. Cette disposition vise un mode de défaillance fréquent : des systèmes qui fonctionnent bien dans l’environnement où ils ont été développés, et échouent une fois déployés ailleurs.

Exemple concret : un système de détection de fraude entraîné sur des schémas de transactions des marchés bancaires d’Europe du Nord peut ne pas être exact une fois déployé sur des marchés d’Europe du Sud, où les comportements de paiement, les volumes de transactions et les schémas de fraude diffèrent nettement. L’article 10, paragraphe 4, exige du fournisseur qu’il tienne compte de ces différences dans les données d’entraînement.

Cela s’applique autant au contexte linguistique (un système doit traiter les langues et dialectes de son marché de déploiement), au contexte temporel (des données de 2019 peuvent ne pas représenter les comportements d’après pandémie) et au contexte démographique.

Traitement de catégories particulières de données à caractère personnel (article 10, paragraphe 5)

L’article 10, paragraphe 5, traite l’une des intersections les plus sensibles de la régulation de l’IA : le besoin de traiter des données sur l’origine raciale, l’origine ethnique, le sexe, la santé, la religion, l’orientation sexuelle et d’autres caractéristiques protégées pour détecter et corriger les biais, alors même que ce traitement est en principe interdit par l’article 9 du RGPD.

Le règlement résout cette tension en créant une base juridique spécifique pour traiter des catégories particulières de données, mais seulement lorsque toutes les conditions suivantes sont réunies :

• Le traitement est strictement nécessaire aux fins de la détection et de la correction des biais.
• La détection et la correction des biais ne peuvent être satisfaites de manière efficace en traitant d’autres données, y compris des données synthétiques ou anonymisées.
• Les données sont soumises à des limitations techniques relatives à la réutilisation et aux mesures les plus avancées en matière de sécurité et de protection de la vie privée, y compris la pseudonymisation.
• Des mesures visent à garantir que les données sont sécurisées, protégées et soumises à des garanties appropriées, y compris des contrôles stricts et une documentation de l’accès.
• Les données ne doivent pas être transmises, transférées ou consultées d’une autre manière par d’autres parties.
• Les données sont supprimées une fois que le biais a été corrigé ou que la période de conservation a expiré, selon celle de ces deux échéances qui arrive en premier.
• Les registres des activités de traitement comprennent les raisons pour lesquelles le traitement était strictement nécessaire, et pourquoi l’objectif n’a pas pu être atteint par le traitement d’autres données.

C’est important pour les équipes de conformité. Cela signifie que vous pouvez, et dans bien des cas devriez, collecter des données démographiques aux fins d’essais de biais. Mais les garanties ne se négocient pas. Les données doivent être pseudonymisées, à accès contrôlé, limitées à la finalité, et supprimées lorsqu’elles ne sont plus nécessaires. Voir notre guide sur l’interaction entre le règlement sur l’IA et le RGPD pour une analyse plus profonde de ce recouvrement.

Synthèse des exigences de l’article 10

Jeux d’entraînement, de validation et de test, ce que vous devez documenter

L’article 10 n’existe pas isolément. Ses exigences alimentent directement la documentation technique de l’annexe IV, en particulier la rubrique 2 (informations détaillées sur le processus de développement, y compris les données). Voici ce que vous devez documenter pour chaque type de jeu.

Provenance et origine des données

Pour chaque jeu utilisé en entraînement, validation ou essai, vous devez pouvoir répondre :

• D’où viennent les données ? Identifiez chaque source : bases internes, fournisseurs de données tiers, jeux publics, moissonnage du web, contenus générés par des personnes, génération synthétique, ou autres origines.
• Quand les données ont-elles été collectées ? Précisez la période et toute limitation temporelle.
• Qui a collecté les données ? Identifiez l’entité responsable de la collecte.
• Sur quelle base juridique ? Pour les données à caractère personnel, précisez la base juridique du RGPD au titre de l’article 6 et, pour les catégories particulières, l’exception de l’article 9 invoquée.
• Quelles licences ou conditions régissent les données ? Pour les jeux tiers ou publics, consignez les conditions de licence et toute restriction d’usage.

La provenance n’est pas qu’un exercice documentaire ; c’est un bouclier de responsabilité. Si une erreur en aval est retracée jusqu’à une source précise, les enregistrements de provenance permettent d’isoler le problème et de démontrer la diligence.

Méthodologie de collecte

Documentez la méthodologie utilisée pour collecter chaque jeu :

• Stratégie d’échantillonnage : aléatoire, stratifié, de convenance, ou raisonné ? Quel était le cadre d’échantillonnage ?
• Critères d’inclusion et d’exclusion : quels critères ont déterminé quels points de données étaient inclus ou exclus ?
• Processus d’annotation et d’étiquetage : qui a étiqueté les données ? Quelles consignes ont-ils suivies ? Quel était le taux d’accord inter-annotateurs ?
• Contrôle de qualité pendant la collecte : quels contrôles ont été appliqués pendant la collecte pour assurer l’exactitude ?

Propriétés statistiques et représentativité

L’article 10, paragraphe 3, exige des jeux « suffisamment représentatifs ». Pour le démontrer, vous devez documenter :

• Distributions des variables clés : statistiques descriptives, histogrammes et analyses de distribution pour toutes les caractéristiques pertinentes au regard de la destination.
• Composition démographique : pour les systèmes qui touchent des personnes physiques, la ventilation démographique du jeu comparée à la population cible.
• Équilibre des classes : pour les tâches de classification, la distribution des classes cibles et tout déséquilibre.
• Distribution temporelle : comment les données se répartissent dans le temps, et s’il existe des tendances temporelles.
• Distribution géographique : où se situent les personnes concernées ou les points de données, et comment cela se superpose à la géographie de déploiement prévue.

Exemple concret : un fournisseur d’une IA d’embauche à haut risque déployée en Allemagne, en France et en Espagne doit documenter que ses données d’entraînement incluent des candidats des trois pays, dans des proportions qui reflètent la population de déploiement. Si 80 % des données d’entraînement viennent d’Allemagne mais que 40 % de l’usage de déploiement a lieu en France, le fournisseur doit expliquer cet écart et décrire les mesures d’atténuation (par exemple suréchantillonnage, adaptation de domaine, ou réglage séparé du modèle).

Étapes d’identification et d’atténuation des biais

C’est là que l’article 10, paragraphe 2, points f) et g), rencontre la documentation de l’annexe IV. Vous devez documenter :

• Quels biais ont été examinés : les types précis appréciés (historique, représentation, mesure, agrégation, évaluation, déploiement).
• La méthodologie utilisée : quels outils, indicateurs et essais ont été appliqués. Exemples : analyse de parité démographique, essais de cotes égalisées, ratios d’impact disparate, comparaisons de performance par sous-groupe.
• Les résultats : quels biais ont été détectés, leur gravité, et quels groupes ont été affectés.
• Les mesures d’atténuation : ce qui a été fait pour traiter chaque biais détecté : rééchantillonnage, repondération, débiaisage adverse, ajustement de seuil, augmentation des données, ou autres techniques.
• Le risque résiduel : quel biais demeure après atténuation, et pourquoi il est jugé acceptable au vu de la destination et du niveau de risque du système.

Pour une méthode pas à pas, voir notre guide sur les essais de biais et l’équité.

Identification et comblement des lacunes

L’article 10, paragraphe 2, points e) et h), exige d’évaluer si les données disponibles sont suffisantes et adaptées, et de détecter les lacunes. Si des lacunes sont identifiées, vous devez documenter :

• Quelles lacunes existent : sous-groupes sous-représentés, périodes manquantes, angles morts géographiques, cas limites insuffisants.
• Comment les lacunes ont été identifiées : par analyse statistique, revue d’experts de domaine, comparaison à la population cible, ou d’autres méthodes.
• Comment les lacunes ont été traitées : augmentation des données, génération de données synthétiques, collecte supplémentaire, apprentissage par transfert, ou, si les lacunes ne peuvent pas être comblées, restrictions du périmètre de déploiement du système.
• Lacunes résiduelles : ce qui reste après remédiation, et comment cela affecte la performance et l’équité du système.

Transparence des données d’entraînement des modèles GPAI

Le règlement impose un régime distinct mais lié pour les modèles d’IA à usage général au titre de l’article 53. L’article 10 gouverne la gouvernance des données des systèmes à haut risque ; l’article 53 gouverne la transparence des données d’entraînement des modèles GPAI ; les deux régimes se recoupent lorsqu’un modèle GPAI est intégré dans un système à haut risque.

Article 53, paragraphe 1, point d), obligation de résumé des données d’entraînement

L’article 53, paragraphe 1, point d) exige de tout fournisseur d’un modèle GPAI qu’il établisse et mette à la disposition du public un résumé suffisamment détaillé du contenu utilisé pour l’entraînement du modèle d’IA à usage général. Ce résumé doit être préparé conformément à un modèle fourni par le Bureau de l’IA.

La finalité est double : permettre aux fournisseurs en aval de comprendre les fondations de données du modèle, et permettre aux titulaires de droits d’identifier si leur contenu a été utilisé à l’entraînement.

Le modèle de transparence de l’Union sur les données d’entraînement (publié en juillet 2025)

Le Bureau de l’IA a publié le modèle normalisé de résumé des données d’entraînement en juillet 2025, après consultation publique. C’est un document structuré que les fournisseurs de GPAI doivent remplir et publier. Il est conçu pour être lisible par machine autant que par des personnes, ce qui permet une analyse systématique par les régulateurs et les chercheurs.

Ce que le modèle exige

Le modèle de transparence s’organise en trois grandes parties :

1. Métadonnées générales :

• Nom du modèle, version et date de publication
• Nom du fournisseur et coordonnées
• Type de modèle (modèle de fondation, affiné, augmenté par récupération, etc.)
• Modalités prises en charge (texte, image, audio, vidéo, code, multimodal)
• Usages en aval prévus et limites connues

2. Catégories de sources de données et descriptions :

• Liste catégorisée des sources (par exemple crawl du web, jeux sous licence, œuvres du domaine public, données publiques, données apportées par des personnes, données synthétiques)
• Pour chaque catégorie : une description du type de contenu, le volume approximatif, les langues représentées, l’origine géographique et la période
• Indication de l’inclusion d’œuvres protégées par le droit d’auteur et, le cas échéant, de quelles catégories (livres, articles de presse, travaux universitaires, musique, images, dépôts de code, etc.)
• Toute source explicitement exclue et le motif de l’exclusion

3. Traitement des données et gouvernance :

• Procédures de filtrage et de nettoyage appliquées
• Méthodologie de déduplication
• Filtrage de sécurité des contenus (retrait des contenus d’abus sexuels sur mineurs, des contenus toxiques, des données à caractère personnel)
• Mécanismes de sélection ou de notation de la qualité
• Traitement des données à caractère personnel : si des données à caractère personnel sont incluses, et le cas échéant quelles catégories et quelles garanties
• Mécanismes de retrait offerts aux personnes concernées ou aux titulaires de droits

Le modèle n’exige pas la divulgation des données d’entraînement elles-mêmes, ni des URL ou documents précis utilisés. Il exige un résumé, assez détaillé pour être utile, mais pas assez granulaire pour révéler des secrets d’affaires.

Échéance transitoire : 2 août 2027 pour les modèles existants

Les obligations GPAI de l’article 53 s’appliquent à compter du 2 août 2025 pour les nouveaux modèles mis sur le marché après cette date. Pour les modèles GPAI déjà sur le marché avant le 2 août 2025, une période transitoire s’applique : les fournisseurs doivent se conformer au plus tard le 2 août 2027.

Cela donne aux fournisseurs de GPAI existants deux ans pour reconstruire ou compiler des résumés de données d’entraînement pour des modèles qui ont pu être entraînés avant que les exigences de transparence soient connues.

Biais dans les données d’entraînement, détection et atténuation

L’article 10, paragraphe 2, points f) et g), exige des fournisseurs qu’ils examinent les jeux pour des biais et prennent des mesures appropriées pour les traiter. Cette section donne un aperçu des types de biais pertinents pour la conformité, des méthodes d’essai disponibles, et de la documentation requise. Pour un guide technique complet, voir notre article dédié aux essais de biais.

Types de biais

Méthodes d’essai

Les essais de biais au titre de l’article 10 doivent être menés au niveau des données (examen des jeux avant et pendant l’entraînement) et au niveau du modèle (évaluation des sorties par sous-groupe). Approches clés :

• Analyse par sous-groupe : ventiler les indicateurs de performance (exactitude, précision, rappel, F1) selon les attributs protégés (sexe, origine ethnique, âge, situation de handicap).
• Ratio d’impact disparate : comparer les taux de résultat d’un groupe à l’autre. Un ratio inférieur à 0,8 (règle des quatre cinquièmes) est un indicateur fréquent d’impact défavorable.
• Cotes égalisées : tester si le modèle a des taux de vrais positifs et de faux positifs égaux d’un groupe à l’autre.
• Équité contrefactuelle : modifier les attributs protégés dans l’entrée et tester si la sortie change.
• Analyse intersectionnelle : tester le biais à l’intersection de plusieurs attributs (par exemple femmes de plus de 50 ans, jeunes hommes issus de minorités ethniques).

Exigences de documentation de l’annexe IV pour les biais

La rubrique 2 de l’annexe IV exige que la documentation technique comprenne :

• Une description des mesures d’examen des données entreprises
• Les biais précis testés et pourquoi ils ont été retenus
• Les indicateurs et seuils utilisés
• Les résultats des essais de biais, y compris les constats quantitatifs
• Les mesures d’atténuation appliquées et leur efficacité
• Tout biais résiduel et la justification de son acceptabilité
• Le plan de suivi continu des biais en production

Exemple concret, évaluation de la solvabilité : Un fournisseur d’un système d’évaluation de la solvabilité à haut risque, entraîné sur des données historiques de demandes de crédit, mène l’appréciation suivante :

1. Contrôle du biais de sélection : comparer la composition démographique des données d’entraînement aux statistiques de population d’Eurostat pour les pays de déploiement cibles. Constat : les femmes de 18 à 25 ans sont sous-représentées de 12 %. Atténuation : suréchantillonnage stratifié et augmentation par données synthétiques pour ce sous-groupe.
2. Contrôle du biais historique : analyser les taux d’approbation historiques par origine ethnique. Constat : les demandeurs aux noms à consonance non européenne avaient des taux d’approbation inférieurs de 15 %, même après contrôle des indicateurs financiers. Atténuation : retirer les caractéristiques dérivées du nom ; réentraîner le modèle ; valider que l’écart tombe sous 3 %.
3. Contrôle du biais de mesure : vérifier la cohérence de la déclaration des revenus d’une source à l’autre. Constat : le revenu des indépendants est mesuré différemment chez trois fournisseurs de données. Atténuation : standardiser la méthodologie de calcul du revenu et documenter les hypothèses.

Catégories particulières de données à caractère personnel

L’article 10, paragraphe 5, traite le paradoxe au cœur de l’équité de l’IA : pour détecter un biais contre des groupes protégés, vous avez besoin de données sur ces groupes, mais traiter ces données est en principe interdit.

Quand le traitement est permis au titre de l’article 10, paragraphe 5

Le traitement de catégories particulières de données est permis au titre de l’article 10, paragraphe 5, lorsque :

1. Le biais ne peut pas être suivi par d’autres moyens : si vous pouvez détecter et corriger le biais en utilisant des données anonymisées ou non sensibles, vous devez le faire. L’article 10, paragraphe 5, est un dernier recours, pas une option par défaut.
2. Le traitement est strictement nécessaire : pas seulement utile ou commode, mais strictement nécessaire aux fins du suivi, de la détection ou de la correction des biais.
3. Des garanties appropriées sont en place : des mesures techniques et organisationnelles doivent protéger les données tout au long de leur cycle de vie.

Interaction avec l’article 9 du RGPD

L’article 10, paragraphe 5, du règlement sur l’IA crée une exception sectorielle qui interagit avec l’article 9, paragraphe 2, point g), du RGPD (intérêt public important). Les deux régimes imposent toutefois des obligations cumulatives, pas alternatives. Les fournisseurs doivent satisfaire aux deux :

• Les exigences de garanties de l’article 10, paragraphe 5, du règlement sur l’IA
• Les principes de protection des données du RGPD (licéité, limitation des finalités, minimisation des données, limitation de la conservation, intégrité et confidentialité)
• Les exigences de responsabilité du RGPD (AIPD, registres des traitements, consultation du DPD)

Vous avez donc besoin à la fois d’une base juridique conforme au RGPD et de garanties conformes au règlement sur l’IA. Une analyse d’impact relative à la protection des données (AIPD) au titre de l’article 35 du RGPD est en pratique obligatoire, puisque le traitement de catégories particulières aux fins de détection des biais atteindra presque toujours le seuil d’un traitement « à haut risque » au titre du RGPD.

Pour une analyse complète, voir notre article règlement sur l’IA et RGPD : différences et recouvrement.

Garanties et limitations

Au minimum, les garanties suivantes doivent être mises en œuvre :

• Pseudonymisation : remplacer les identifiants directs par des pseudonymes. Une véritable anonymisation est préférable lorsqu’elle ne compromet pas la finalité de détection des biais.
• Chiffrement : appliquer le chiffrement au repos et en transit pour toutes les catégories particulières.
• Contrôles d’accès : restreindre l’accès à un groupe défini de personnes autorisées, avec un besoin documenté.
• Limitation des finalités : les catégories particulières ne doivent servir qu’au suivi, à la détection et à la correction des biais, jamais à l’entraînement du modèle ni à une autre finalité.
• Limites de conservation : supprimer les catégories particulières une fois l’analyse des biais achevée ou la période de conservation expirée, selon ce qui arrive en premier.
• Journalisation et pistes d’audit : tenir des enregistrements de tous les accès et de tous les traitements de catégories particulières.
• Limitations techniques de la réutilisation : mettre en œuvre des contrôles techniques (pas seulement des politiques) qui empêchent la réutilisation à d’autres fins.

Guide de mise en œuvre, satisfaire l’article 10

La conformité à l’article 10 n’est pas un livrable unique. C’est un ensemble de pratiques continues, ancrées dans le cycle de vie de développement de l’IA. Le guide pas à pas ci-dessous offre une démarche structurée.

Étape 1 : inventorier vos jeux de données

Avant de gouverner vos données, il faut savoir ce que vous avez. Créez un inventaire complet de tous les jeux utilisés en entraînement, validation et essai pour chaque système d’IA à haut risque.

Liste de contrôle :

• Lister tous les jeux d’entraînement avec source, taille, format et date d’acquisition
• Lister tous les jeux de validation avec les mêmes informations
• Lister tous les jeux de test avec les mêmes informations
• Identifier quels jeux contiennent des données à caractère personnel et lesquels contiennent des catégories particulières
• Cartographier les flux de données de la source jusqu’au modèle

Étape 2 : établir des politiques de gouvernance des données

Définissez et documentez des politiques qui couvrent les exigences de l’article 10, paragraphe 2.

Liste de contrôle :

• Politique de qualité des données (nettoyage, correction des erreurs, contrôles de complétude)
• Politique de collecte (sources, méthodes, consentement / base juridique)
• Politique d’étiquetage (consignes, formation des annotateurs, assurance qualité)
• Politique de conservation et de suppression
• Politique de contrôle d’accès aux données
• Politique de versionnage des données et de gestion des changements

Étape 3 : apprécier la représentativité

Comparez vos jeux à la population de déploiement cible, sur toutes les dimensions pertinentes.

Liste de contrôle :

• Identifier la population cible pour chaque système à haut risque
• Comparer la démographie du jeu à celle de la population cible
• Comparer la distribution géographique du jeu à la géographie de déploiement
• Comparer la distribution temporelle du jeu à la période d’exploitation prévue
• Documenter les lacunes et définir un plan de remédiation

Étape 4 : mener l’examen des biais

Effectuez l’examen exigé par l’article 10, paragraphe 2, points f) et g).

Liste de contrôle :

• Sélectionner les types de biais à tester selon le contexte du système et le profil de risque
• Choisir des indicateurs d’équité et des seuils appropriés
• Mener une analyse des biais au niveau des données (analyse de distribution, contrôles de représentation)
• Mener une analyse des biais au niveau du modèle (performance par sous-groupe, impact disparate, cotes égalisées)
• Documenter tous les constats, y compris les résultats négatifs (aucun biais trouvé)
• Mettre en œuvre des mesures d’atténuation pour les biais identifiés
• Valider que les mesures d’atténuation sont effectives
• Documenter le biais résiduel et sa justification

Étape 5 : tout documenter au format de l’annexe IV

Compilez tout ce qui précède dans la documentation technique de l’annexe IV, rubrique 2.

Liste de contrôle :

• Choix de conception documentés et justifiés
• Provenance consignée pour tous les jeux
• Opérations de préparation des données documentées
• Hypothèses rendues explicites
• Évaluation de la disponibilité et de l’adéquation achevée
• Résultats de l’examen des biais et atténuation documentés
• Propriétés statistiques et analyse de représentativité incluses
• Traitement des catégories particulières documenté, avec garanties

Étape 6 : établir un suivi continu

La conformité à l’article 10 n’est pas une porte unique. La qualité et la représentativité des données doivent être suivies tout au long du cycle de vie du système, comme l’exigent les obligations de surveillance après mise sur le marché de l’article 72.

Liste de contrôle :

• Définir des indicateurs de qualité des données et une fréquence de suivi
• Mettre en œuvre une détection de dérive des données pour les données de production
• Planifier un réexamen périodique des biais (au moins annuel, ou lors de changements matériels)
• Définir des déclencheurs de revalidation du jeu (nouvelle géographie de déploiement, changement réglementaire, dégradation de performance)
• Intégrer le suivi de la gouvernance des données dans le programme de conformité d’ensemble

Questions fréquentes

L’article 10 s’applique-t-il si j’utilise un modèle préentraîné ou un modèle de fondation ?

Oui. Si vous affinez, adaptez ou intégrez un modèle préentraîné ou un modèle de fondation dans un système d’IA à haut risque, vous êtes le fournisseur de ce système et l’article 10 s’applique aux données que vous utilisez pour l’affinage, la validation et les essais. Pour les données d’entraînement de base, les obligations de transparence GPAI de l’article 53 s’appliquent au fournisseur du modèle GPAI. Vous devriez demander le résumé des données d’entraînement du fournisseur GPAI et évaluer si les données de préentraînement conviennent à votre destination.

Que se passe-t-il si mes données d’entraînement sont entièrement synthétiques ?

Les données synthétiques ne sont pas exemptées de l’article 10. Les exigences de gouvernance des données s’appliquent que les données soient réelles, synthétiques, ou un mélange. Vous devez documenter la méthodologie de génération, vérifier que les données synthétiques n’introduisent ni n’amplifient de biais, et évaluer si elles sont représentatives des conditions réelles. Les données synthétiques peuvent aider à combler des lacunes de représentation, mais elles introduisent de nouveaux risques, comme l’effondrement de mode ou l’amplification des schémas des données de départ, qui doivent être documentés et maîtrisés.

Comment l’article 10 interagit-il avec la minimisation des données du RGPD ?

Il existe une tension inhérente. L’article 5, paragraphe 1, point c), du RGPD exige la minimisation des données, ne collecter que ce qui est nécessaire. L’article 10 exige des jeux suffisamment représentatifs et complets. Le règlement sur l’IA tranche cela au considérant 67 en clarifiant que les fournisseurs peuvent traiter des données à caractère personnel dans la mesure nécessaire pour assurer le suivi, la détection et la correction des biais, sous réserve de garanties appropriées. La clé est la spécification de la finalité : vous devez articuler clairement quelles données sont nécessaires à quelle finalité, et vous ne pouvez pas utiliser « l’entraînement de l’IA » comme justification fourre-tout d’une collecte illimitée. Une AIPD correctement menée aidera à trouver cet équilibre.

Quel niveau de qualité des données est « assez bon » pour la conformité ?

L’article 10, paragraphe 3, utilise la formule « dans toute la mesure possible, exempts d’erreurs et complets ». C’est un standard de raisonnabilité, pas de perfection. Vous devez démontrer que vous avez pris des mesures appropriées et documentées pour identifier et corriger les erreurs, traiter les valeurs manquantes, et assurer la qualité des données. Ce qui est « approprié » dépend du niveau de risque : un système qui classifie des images générées par IA a une barre de qualité plus basse qu’un système qui détermine l’éligibilité à des prestations sociales. Documentez vos processus de qualité, vos taux d’erreur, et vos motifs pour considérer le niveau de qualité restant comme acceptable.

Dois-je réexaminer mes données d’entraînement pour les biais à chaque réentraînement ?

Oui. Chaque cycle de réentraînement peut introduire de nouvelles données, changer les distributions, ou modifier le rapport du modèle aux groupes protégés. L’article 10, paragraphe 2, points f) et g), et les obligations de gestion des risques de l’article 9 exigent un examen continu. En pratique, vous devriez intégrer l’examen des biais dans votre pipeline CI/CD pour qu’il s’exécute automatiquement à chaque cycle de réentraînement, et mener des revues manuelles plus profondes à des intervalles définis ou lorsque des alertes de suivi les déclenchent.

Que se passe-t-il si je ne peux pas obtenir de données représentatives pour ma population de déploiement ?

Si des données représentatives ne sont pas disponibles pour un contexte de déploiement précis, par exemple si vous n’avez pas de données d’entraînement d’un État membre de l’Union où le système sera déployé, vous avez plusieurs options : (1) restreindre le déploiement aux contextes pour lesquels vous avez des données représentatives et documenter ces restrictions dans la notice d’utilisation ; (2) utiliser l’apprentissage par transfert ou l’adaptation de domaine et valider la performance dans le contexte cible ; (3) générer des données synthétiques qui comblent l’écart de représentativité ; ou (4) collecter des données supplémentaires. Ce que vous ne pouvez pas faire, c’est déployer le système dans des contextes où vous savez que les données ne sont pas représentatives, sans divulguer cette limitation aux déployeurs et aux personnes concernées.

Prochaines étapes

La gouvernance des données de l’article 10 est un composant d’une obligation de conformité plus large. Pour construire un programme complet, relisez :

• Liste de contrôle 2026 du règlement sur l’IA, une liste structurée couvrant toutes les obligations du fournisseur.
• Obligations des modèles GPAI, transparence des données d’entraînement et autres exigences GPAI.
• Guide des essais de biais, mise en œuvre technique de la détection et de l’atténuation des biais.
• Documentation technique de l’annexe IV, comment structurer votre documentation, y compris la rubrique 2 sur les données.
• Règlement sur l’IA et RGPD, naviguer le recouvrement entre protection des données et régulation de l’IA.
• Surveillance après mise sur le marché, obligations de suivi continu qui incluent la qualité des données et les biais.

Pas sûr que votre système d’IA soit à haut risque ? Lancez notre évaluation gratuite des risques au titre du règlement sur l’IA pour le savoir en cinq minutes.