Article 10 du règlement européen sur l'IA : les exigences de gouvernance des données expliquées

Mise à jour du 2 octobre 2026 — correction. Les versions précédentes citaient les mauvais paragraphes de l'article 10, affirmaient que le règlement exige que les données de test soient tenues distinctes des données d'entraînement, et que les systèmes déjà en production doivent être conformes d'ici au 2 décembre 2027. Le guide cite désormais l'article 10, paragraphe 2, pour la gouvernance et l'examen des biais et l'article 10, paragraphe 3, pour la qualité des données, et suit l'article 111, paragraphe 2, tel que modifié par le Digital Omnibus, pour les systèmes déjà mis sur le marché.

Mise à jour du 31 juillet 2026 — échéance modifiée. Le Digital Omnibus (adopté par le Parlement européen le 16 juin 2026 et par le Conseil le 29 juin 2026) a reporté les obligations relatives aux systèmes à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027. Les obligations de transparence de l'article 50 n'ont pas été reportées et s'appliquent toujours à partir du 2 août 2026. Cet article a été corrigé en conséquence. Si votre système d'IA est classé à haut risque au titre du règlement européen sur l'IA, l'article 10 n'est pas négociable. Il impose des pratiques précises de gouvernance des données pour les jeux de données d'entraînement, de validation et de test — et ces obligations s'appliquent à partir du 2 décembre 2027. Le plafond légal est de 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu — et, pour les PME, le montant le plus faible.

La plupart des équipes supposent que « nous avons une traçabilité des données » équivaut à la conformité. Ce n'est pas le cas. L'article 10 exige des choix de conception documentés, des mesures d'atténuation des biais et les propriétés statistiques de chaque jeu de données servant à entraîner ou à valider un système à haut risque.

Ce guide détaille ce qu'exige réellement l'article 10, quels systèmes sont concernés et comment documenter la conformité avant l'échéance.

Ce qu'exige l'article 10

L'article 10 s'applique aux systèmes d'IA à haut risque énumérés à l'annexe III (outils de présélection RH, notation de crédit, identification biométrique, gestion d'infrastructures critiques, etc.), ainsi qu'à ceux classés à haut risque au titre de l'annexe I. Il impose que les données d'entraînement, de validation et de test répondent à des critères de qualité précis (règlement (UE) 2024/1689, article 10) :

Exigence	Ce que cela signifie	Documentation nécessaire
Pertinentes, suffisamment représentatives, exemptes d'erreurs et complètes — ces deux derniers critères « dans toute la mesure possible » (article 10, paragraphe 3)	Les données doivent refléter le cas d'usage réel, sans lacunes systématiques	Rapport de composition du jeu de données montrant la couverture démographique et géographique
Propriétés statistiques appropriées (article 10, paragraphe 3)	Les données doivent présenter un volume, une variance et un équilibre suffisants pour la tâche	Synthèse statistique : taille de l'échantillon, distribution des classes, mesures de variance
Examen des biais (article 10, paragraphe 2, points f) et g))	Vous devez rechercher activement et documenter les biais susceptibles d'entraîner des résultats discriminatoires	Rapport d'audit des biais assorti des mesures d'atténuation (rééchantillonnage, contraintes d'équité, etc.)
Gouvernance et gestion des données (article 10, paragraphe 2)	Des processus formels de collecte, d'annotation, de stockage et de gestion des versions	Document de politique de gouvernance des données + piste d'audit des versions du jeu de données

L'article 10 ne prescrit pas de tests statistiques ni de métriques de biais précis. C'est délibéré : le règlement est neutre sur le plan technologique. Mais il exige que vous documentiez vos choix et expliquiez en quoi ils sont adaptés au profil de risque de votre système.

À qui s'applique l'article 10

Les obligations de l'article 10 pèsent sur les fournisseurs de systèmes d'IA à haut risque — l'entité qui développe le système ou le fait développer et le met sur le marché de l'UE sous son nom ou sa marque.

Si vous êtes déployeur (une organisation qui utilise un système à haut risque développé par un tiers), la conformité à l'article 10 relève du fournisseur. Votre propre obligation est plus restreinte : dans la mesure où vous exercez un contrôle sur les données d'entrée, vous devez veiller à ce qu'elles soient pertinentes et suffisamment représentatives au regard de la destination du système (article 26, paragraphe 4). Il reste utile de demander au fournisseur des éléments attestant son travail au titre de l'article 10, en particulier dans un secteur réglementé (finance, santé, services publics).

Si vous êtes une jeune pousse ou une entreprise en croissance qui construit sa propre IA, vous êtes le fournisseur. L'article 10 s'applique intégralement.

Les cinq pratiques de gouvernance des données exigées par l'article 10

1. Les choix de conception du jeu de données doivent être documentés

Pourquoi avoir retenu ce jeu de données ? Quelle population ou quel scénario réel représente-t-il ? Quelles sont ses limites connues ?

Exemple : si vous construisez un outil de présélection de CV assisté par IA (annexe III, catégorie 4), vos données d'entraînement doivent représenter la population de candidats que vous rencontrerez réellement. Si votre jeu de données est constitué à 80 % de CV masculins issus de métiers technologiques et que vous déployez le système pour trier des candidatures dans la santé, le jeu de données ne semble pas satisfaire à l'article 10, paragraphes 3 et 4, qui exigent des données suffisamment représentatives et tenant compte du cadre dans lequel le système est destiné à être utilisé.

Ce qu'il faut documenter :

• Source et méthodologie de collecte du jeu de données
• Couverture géographique, démographique et sectorielle
• Lacunes connues ou groupes sous-représentés
• Justification du choix du jeu de données

2. Les propriétés statistiques doivent être appropriées

« Approprié » signifie suffisant au regard du niveau de risque et de la complexité de la tâche. Un modèle de notation de crédit à haut risque exige une validation statistique plus rigoureuse qu'un moteur de recommandation de contenus à faible risque.

Ce qu'il faut documenter :

• Taille de l'échantillon et méthode de détermination
• Distribution des classes (par exemple 60 % de prêts accordés, 40 % de refus)
• Analyse de la variance et de la corrélation des variables
• Ratios et méthodologie de répartition entraînement/validation/test

Si votre jeu de données est déséquilibré (par exemple 95 % de classe négative), documentez pourquoi cela reflète la réalité et quelles mesures vous avez prises pour empêcher le modèle d'ignorer la classe minoritaire (échantillonnage stratifié, pondération des classes, SMOTE, etc.).

3. L'examen des biais est obligatoire

L'article 10, paragraphe 2, point f), impose expressément « un examen permettant de repérer d'éventuels biais » susceptibles de porter atteinte à la santé et à la sécurité, d'avoir une incidence négative sur les droits fondamentaux ou de se traduire par une discrimination interdite par le droit de l'Union (fondée par exemple sur l'origine ethnique, le sexe, l'âge ou le handicap). L'article 10, paragraphe 2, point g), exige ensuite des mesures appropriées visant à détecter, prévenir et atténuer les biais ainsi repérés.

Ce n'est pas facultatif. Vous devez rechercher activement les biais, documenter vos constats et expliquer votre stratégie d'atténuation.

Étapes pratiques :

• Segmentez votre jeu de données par attributs protégés (lorsqu'ils sont disponibles) et mesurez les écarts de performance
• Utilisez des mesures d'équité (parité démographique, égalité des chances, calibrage) adaptées à votre cas d'usage
• Documentez les écarts constatés et les mesures correctives prises (rééquilibrage, contraintes d'équité, post-traitement)
• Si les attributs protégés ne figurent pas dans votre jeu de données, documentez une analyse par variables indirectes (par exemple le code postal comme approximation de l'origine ethnique dans les données de crédit américaines)
• Si la détection et la correction des biais exigent des catégories particulières de données à caractère personnel (comme l'origine ethnique ou la santé), le règlement n'en autorise le traitement qu'à titre exceptionnel, lorsque c'est strictement nécessaire et sous des conditions strictes. Cette règle figurait à l'article 10, paragraphe 5 ; depuis le Digital Omnibus, elle figure à l'article 4 bis, paragraphe 1 (règlement (UE) 2026/1744)

Exemple : une IA de recrutement entraînée sur des données historiques peut apprendre que les « interruptions de carrière » sont corrélées au rejet — mais si les femmes sont plus susceptibles de connaître de telles interruptions en raison des congés parentaux, le modèle encode un biais de genre. L'article 10 vous impose de le détecter et de l'atténuer.

4. Les processus de gouvernance des données doivent être formalisés

L'article 10, paragraphe 2, exige des « pratiques en matière de gouvernance et de gestion des données » adaptées à la destination du système — pas de simples bonnes intentions, mais des processus documentés. Il énumère ce qu'elles doivent couvrir, des choix de conception, de la collecte et de la préparation des données jusqu'à l'identification des lacunes dans les données.

Documentation minimale :

• Politique de collecte des données (qui peut ajouter des données, et à quelles conditions)
• Lignes directrices d'annotation et contrôle qualité (scores d'accord inter-annotateurs, audits d'annotations)
• Gestion des versions et traçabilité des données (quelle version de modèle a été entraînée sur quelle version de jeu de données)
• Contrôles d'accès et journaux d'audit (qui a accédé aux données d'entraînement, quand et pourquoi)

Si vous réentraînez votre modèle sur de nouvelles données, vous devez répéter l'analyse au titre de l'article 10 pour le jeu de données mis à jour. Une conformité ponctuelle ne suffit pas.

5. Les données de test doivent être représentatives — et devraient être indépendantes

Les critères de qualité de l'article 10, paragraphe 3 — pertinentes, suffisamment représentatives et, dans toute la mesure possible, exemptes d'erreurs et complètes — s'appliquent aux jeux de données de test comme aux jeux de données d'entraînement et de validation. Pour un système qui n'est pas entraîné sur des données, l'article 10, paragraphe 6, n'applique les exigences relatives aux données qu'aux jeux de données de test.

L'article 10 n'exige pas lui-même que les données de test soient tenues distinctes des données d'entraînement. Mais le règlement définit les données de test comme des données utilisées pour fournir une « évaluation indépendante » du système avant sa mise sur le marché (article 3, point 32). Un modèle évalué sur les données qui ont servi à l'entraîner n'a pas fait l'objet de cette évaluation indépendante : tenir les deux séparées relève donc à la fois de l'hygiène élémentaire en apprentissage automatique et de la lecture que la définition appuie.

Ce qu'il faut documenter :

• Comment vous avez garanti l'indépendance des données de test (découpage temporel, échantillon de validation stratifié, etc.)
• En quoi votre jeu de test représente les conditions réelles de déploiement
• La performance sur le jeu de test ventilée par sous-groupes (afin de détecter les impacts disparates)

Lacunes de conformité courantes à l'article 10

La plupart des équipes qui construisent une IA à haut risque disposent de certaines pratiques de gouvernance des données. Mais peu disposent de la documentation exigée par l'article 10. Voici les lacunes les plus fréquentes :

• Aucune documentation de l'examen des biais — les équipes calculent des mesures d'équité mais ne documentent ni leurs constats ni leurs mesures d'atténuation
• Aucune justification de la conception du jeu de données — les équipes utilisent « les données dont elles disposaient » sans documenter en quoi elles sont appropriées
• Aucune gestion des versions ni traçabilité — les équipes réentraînent des modèles sans pouvoir retracer quelle version de jeu de données a produit quelle version de modèle
• Aucune justification statistique — les équipes ne documentent pas pourquoi la taille de leur échantillon, l'équilibre des classes ou l'ensemble des variables est suffisant au regard du niveau de risque
• Aucune politique de gouvernance formelle — les pratiques existent de manière informelle mais ne sont ni écrites ni auditables

Comment documenter la conformité à l'article 10

La conformité à l'article 10 se démontre par la documentation technique (exigée par l'article 11, avec les fiches techniques sur les données énumérées à l'annexe IV, point 2 d)). Au minimum, il vous faut :

1. Un document de spécification du jeu de données — pour chaque jeu (entraînement, validation, test) :

   • Source, date et méthodologie de collecte
   • Taille, structure et propriétés statistiques
   • Limites et lacunes connues
   • Résultats de l'examen des biais et mesures d'atténuation

2. Une politique de gouvernance des données — à l'échelle de l'organisation :

   • Normes de collecte et d'annotation des données
   • Suivi des versions et de la traçabilité
   • Contrôles d'accès et procédures d'audit
   • Déclencheurs de réentraînement et de réévaluation

3. Une fiche de modèle ou une documentation technique — pour chaque modèle :

   • Quels jeux de données ont été utilisés (avec les empreintes de version)
   • Pourquoi ces jeux de données conviennent au cas d'usage
   • La performance sur le jeu de test, globale et par sous-groupe
   • Les risques résiduels et le plan de surveillance

Ces documents doivent être tenus à jour tout au long du cycle de vie du système. Si vous réentraînez, vous mettez la documentation à jour. Si vous découvrez un nouveau biais, vous le documentez ainsi que votre réponse.

L'article 10 et l'échéance de décembre 2027

Les obligations de l'article 10 s'appliquent à partir du 2 décembre 2027 pour les systèmes d'IA à haut risque de l'annexe III, et à partir du 2 août 2028 pour ceux classés à haut risque au titre de l'annexe I.

Un système déjà mis sur le marché ou mis en service avant cette date n'est soumis aux exigences applicables aux systèmes à haut risque que si sa conception subit des modifications importantes à compter de cette date (article 111, paragraphe 2, tel que remplacé par le Digital Omnibus). Une modification importante de la conception entraîne l'application de l'article 10. Les systèmes destinés à être utilisés par des autorités publiques font exception : leurs fournisseurs et déployeurs doivent se mettre en conformité d'ici à une échéance distincte fixée à l'article 111, paragraphe 2, que la conception change ou non.

Si vous lancez un nouveau système à haut risque après le 2 décembre 2027, la conformité à l'article 10 est requise avant sa mise sur le marché.

La date opérante est le 2 décembre 2027. Le plafond légal en cas de manquement aux obligations des opérateurs de systèmes à haut risque est de 15 millions d'euros ou 3 % du chiffre d'affaires mondial au titre de l'article 99, paragraphe 4 — et, pour les PME, le montant le plus faible. Le niveau de 35 millions d'euros / 7 % prévu à l'article 99, paragraphe 3, ne s'applique qu'aux pratiques interdites de l'article 5, ce qui est tout autre chose.

---

Cet article est fourni à titre d'information uniquement et ne constitue pas un conseil juridique. Consultez un avocat qualifié en droit du règlement européen sur l'IA pour obtenir des orientations de conformité propres à votre système.