Pourquoi la gouvernance des données est-elle si importante ?
Parce qu'un système d'IA apprend des données qu'on lui fournit. Si ces données reflètent des inégalités historiques, des sous-représentations ou des erreurs, le système les reproduira — voire les amplifiera. Un outil de recrutement entraîné sur des décisions passées biaisées perpétuera ces biais ; un modèle de scoring alimenté par des données non représentatives discriminera certaines populations. L'article 10 attaque le problème à la racine : les données.
Quels critères de qualité les données doivent-elles respecter ?
L'article 10 énonce plusieurs exigences pour les jeux de données d'entraînement, de validation et de test :
- des choix de conception documentés (origine, collecte, préparation des données) ;
- une pertinence et une représentativité suffisantes au regard de la finalité du système ;
- l'absence, dans la mesure du possible, d'erreurs et un caractère complet approprié ;
- la prise en compte des spécificités propres au contexte géographique, comportemental ou fonctionnel d'utilisation ;
- un examen des biais possibles susceptibles de porter atteinte à la santé, à la sécurité ou aux droits fondamentaux, ou d'entraîner une discrimination.
Comment l'article 10 traite-t-il les biais ?
Le règlement ne se contente pas d'interdire les biais : il impose de les rechercher activement et de prendre des mesures pour les prévenir et les atténuer. C'est une obligation de moyens renforcée, qui suppose une démarche méthodique tout au long du cycle de vie des données.
L'article 4 bis : la détection des biais sort du haut risque
Jusqu'à l'été 2026, la permission de traiter des données sensibles pour débusquer un biais se limitait aux fournisseurs de systèmes à haut risque, au titre de l'article 10 § 5. Une entreprise qui voulait tester l'équité d'un outil non classé à haut risque se retrouvait dans une impasse : le RGPD lui interdisait de traiter l'origine ethnique ou l'orientation sexuelle, et sans ces données elle ne pouvait pas mesurer la discrimination qu'elle cherchait précisément à éviter.
Le règlement (UE) 2026/1744 insère un article 4 bis qui lève cette impasse. Son paragraphe 2 étend la faculté aux fournisseurs et [déployeurs](/ressources/fournisseur-ou-deployeur) d'autres systèmes et modèles d'IA, ainsi qu'aux déployeurs de systèmes à haut risque — à condition que le traitement soit strictement nécessaire pour détecter et corriger des biais susceptibles de porter atteinte à la santé et à la sécurité, d'affecter négativement les droits fondamentaux ou de conduire à une discrimination interdite par le droit de l'Union. Le texte vise en particulier le cas où les données de sortie influencent les entrées des opérations futures, c'est-à-dire les boucles de rétroaction qui amplifient un biais au fil du temps.
Les six conditions cumulatives
Qu'on relève du paragraphe 1 ou du paragraphe 2, les mêmes garanties s'imposent, en plus de celles du RGPD. Elles sont cumulatives : il suffit qu'une seule manque pour que le traitement redevienne illicite.
- Subsidiarité — la détection ne peut être obtenue efficacement en traitant d'autres données, y compris synthétiques ou anonymisées. C'est la première question à documenter, et souvent la plus discriminante.
- Limitation technique et état de l'art — restrictions à la réutilisation, mesures les plus avancées de sécurité et de protection de la vie privée, dont la pseudonymisation.
- Contrôle d'accès — accès strictement contrôlé et documenté, réservé aux personnes autorisées, assorti d'obligations de confidentialité.
- Cloisonnement — les données ne sont ni transmises, ni transférées, ni consultées d'une autre manière par des tiers.
- Suppression — effacement dès que le biais est corrigé ou à l'expiration de la durée de conservation, selon ce qui arrive en premier.
- Traçabilité du raisonnement — le registre des activités de traitement doit consigner pourquoi le traitement était strictement nécessaire et pourquoi l'objectif ne pouvait être atteint avec d'autres données.
Qui est concerné par l'article 10 ?
L'exigence pèse sur le fournisseur du système à haut risque, qui conçoit et entraîne le modèle. Le déployeur, de son côté, a une obligation complémentaire (article 26) : veiller à la pertinence des données d'entrée qu'il maîtrise et fournit au système en exploitation. Une donnée d'entrée inadaptée peut en effet dégrader les performances d'un système par ailleurs conforme.
| Type de données | Responsable | Exigence |
|---|---|---|
| Entraînement, validation, test | Fournisseur | Qualité, représentativité, examen des biais (art. 10) |
| Données d'entrée en exploitation | Déployeur | Pertinence au regard de la finalité (art. 26) |
| Données sensibles (détection de biais), haut risque | Fournisseur | Traitement exceptionnel sous garanties (art. 10 § 5 et 4 bis § 1) |
| Données sensibles (détection de biais), autres systèmes | Fournisseur ou déployeur | Faculté sous les mêmes garanties (art. 4 bis § 2) |
Comment se mettre en conformité ?
- 01
Documenter la provenance des données
Tracez l'origine, la collecte et la préparation des jeux de données : c'est le socle de la gouvernance.
- 02
Évaluer la représentativité
Vérifiez que les données couvrent les populations et situations réelles d'utilisation, sans sous-représentation problématique.
- 03
Rechercher et mesurer les biais
Mettez en place des tests de biais réguliers, avec des métriques adaptées à la finalité du système.
- 04
Corriger et réévaluer
Appliquez des mesures d'atténuation et documentez-les. La démarche est continue, pas ponctuelle.
Questions fréquentes
L'article 10 s'applique-t-il à tous les systèmes d'IA ?
Non, uniquement aux systèmes à haut risque. Les systèmes à risque limité ou minimal n'y sont pas soumis. Cela dit, la qualité des données reste une bonne pratique universelle, y compris hors du champ du haut risque.
Peut-on traiter des données sensibles pour corriger un biais ?
Oui, à titre exceptionnel et sous conditions strictes : uniquement aux fins de détection et de correction des biais, avec des garanties techniques et organisationnelles fortes, et lorsque cet objectif ne peut être atteint autrement — y compris avec des données synthétiques ou anonymisées. Cette faculté vient de l'article 10 § 5 et de l'article 4 bis, et s'articule avec le RGPD sans s'y substituer.
Mon système n'est pas à haut risque. Puis-je quand même tester l'équité de mon modèle ?
Oui, depuis l'article 4 bis inséré par le règlement (UE) 2026/1744. Son paragraphe 2 ouvre la faculté aux fournisseurs et déployeurs de systèmes et modèles qui ne sont pas à haut risque, dès lors que le traitement est strictement nécessaire pour détecter des biais susceptibles de nuire à la santé et à la sécurité, d'affecter les droits fondamentaux ou de conduire à une discrimination interdite. Les six garanties du paragraphe 1 s'appliquent intégralement — c'est une faculté encadrée, pas une autorisation générale.
L'article 4 bis m'oblige-t-il à faire des tests de biais ?
Non. Le texte précise explicitement qu'il ne crée aucune obligation de procéder à cette détection. Il fournit une base juridique à ceux qui veulent le faire. L'obligation de rechercher les biais, elle, existe bel et bien pour les systèmes à haut risque — mais elle découle de l'article 10, indépendamment de l'article 4 bis.
Le déployeur a-t-il des obligations sur les données ?
Oui. Au titre de l'article 26, il doit veiller à ce que les données d'entrée qu'il maîtrise soient pertinentes au regard de la finalité du système. Il ne refait pas l'entraînement, mais il est responsable de la qualité des données qu'il injecte en exploitation.
Comment prouver la conformité à l'article 10 ?
Par la documentation : choix de conception, provenance des données, analyses de représentativité, tests de biais et mesures correctives. Ces éléments intègrent la documentation technique (annexe IV) et constituent la preuve opposable de la démarche.