Gouvernance des données et EU AI Act : ce que l’Article 10 exige de vos datasets
ℹ️ TLDR; que faut-il retenir
- L’Article 10 du règlement européen sur l’IA (EU AI Act) fait de la qualité des datasets une exigence légale pour les systèmes d’IA à haut risque. Il impose huit pratiques de gouvernance des données — couvrant la collecte, l’annotation, la détection des biais et l’analyse des lacunes — ainsi que des critères de qualité explicites pour les données d’entraînement, de validation et de test.
- L’Omnibus numérique adopté en juin 2026 a reporté l’échéance « haut risque » au 2 décembre 2027, mais les exigences elles-mêmes n’ont pas changé d’un mot.
- Les organisations qui passeront leurs évaluations de conformité en 2027 sont celles qui construisent dès maintenant leur gouvernance de datasets et leur inventaire de données d’entraînement.
- Cet article explique ce que l’Article 10 exige, comment l’opérationnaliser, et comment Innovatiana aborde la création et la gouvernance de datasets — y compris avec Dataset Finder, notre outil de gouvernance de datasets qui sera lancé d’ici la fin de l’année.
Introduction
Toute discussion sérieuse sur la conformité de l’IA en Europe finit par arriver au même endroit : les données.
Système de gestion des risques, documentation technique, supervision humaine — ce sont les couches visibles de l’EU AI Act. Mais sous chacune d’elles se trouve une question plus simple, que régulateurs, auditeurs et organismes notifiés poseront en premier : sur quelles données ce système a-t-il été entraîné, d’où viennent-elles, qui les a manipulées, et comment savez-vous qu’elles sont adaptées à l’usage prévu ?
Cette question est codifiée dans l’Article 10 de l’EU AI Act, intitulé "Données et gouvernance des données". C’est l’obligation la plus prescriptive de tout le chapitre « haut risque », et celle qui descend le plus profondément dans la chaîne d’approvisionnement de l’IA — jusqu’à la collecte de données, jusqu’aux partenaires d’annotation et de labellisation, jusqu’à quiconque prépare des données d’entraînement pour le compte d’un fournisseur.
💡 Chez Innovatiana, construire des datasets est notre métier. Nous avons passé des années à développer les pratiques de traçabilité, de documentation et de qualité que l’Article 10 rend aujourd’hui obligatoires — et nous avons construit un outil interne, Dataset Finder, pour gouverner nos datasets et maintenir un inventaire de données d’entraînement à grande échelle. Ce guide partage ce que nous avons appris : ce que la loi exige, ce que cela signifie opérationnellement, et comment prendre de l’avance.
Qu’est-ce que l’EU AI Act ? (Rappel en 90 secondes)
L’EU AI Act (Règlement (UE) 2024/1689) est entré en vigueur le 1er août 2024. C’est la première réglementation complète de l’IA au monde, et elle ne régule pas l’IA en tant que technologie — elle régule les applications de l’IA selon leur niveau de risque :
- Risque inacceptable — interdit purement et simplement (notation sociale, moissonnage non ciblé d’images faciales, reconnaissance des émotions au travail). Applicable depuis février 2025, avec de nouvelles interdictions visant la génération d’images intimes non consenties à partir de décembre 2026.
- Haut risque — fortement encadré. L’IA dans le recrutement, le scoring de crédit, l’éducation, la biométrie, les infrastructures critiques, les services publics et les dispositifs médicaux. C’est là que vit l’Article 10.
- Risque limité — obligations de transparence au titre de l’Article 50 (les chatbots doivent révéler qu’ils sont des IA ; les contenus synthétiques doivent être marqués de façon lisible par machine). Applicables dès le 2 août 2026.
- Risque minimal — pas d’obligation spécifique (filtres anti-spam, moteurs de recommandation, la majorité de l’IA en production aujourd’hui).
Le règlement a une portée extraterritoriale : si les sorties de votre système d’IA sont utilisées par des personnes dans l’UE, vous êtes concerné, quel que soit le lieu où se trouvent votre société — ou vos serveurs. Les sanctions atteignent 35 millions d’euros ou 7 % du chiffre d’affaires annuel mondial pour les violations les plus graves, et 15 millions d’euros ou 3 % pour la non-conformité aux exigences « haut risque », dont l’Article 10.
Si votre système relève du haut risque, la gouvernance des données n’est pas une exigence parmi d’autres. C’est la fondation sur laquelle reposent toutes les autres : votre gestion des risques (Article 9), votre documentation technique (Article 11) et vos garanties de précision (Article 15) dépendent toutes de votre capacité à démontrer ce que sont vos données et comment elles ont été fabriquées.
Pourquoi la gouvernance des données est le cœur de l’EU AI Act
Ce n’est pas un hasard si le législateur a placé l’article sur les données juste après la gestion des risques et avant tout le reste. La plupart des défaillances documentées de l’IA — outils de recrutement discriminants, modèles de crédit biaisés, systèmes médicaux qui sous-performent sur les populations sous-représentées — ne s’expliquent pas par l’architecture du modèle, mais par les données sur lesquelles le modèle a appris.
L’EU AI Act intègre cette réalité. Les clauses 66 à 70 en explicitent la logique : les datasets de haute qualité sont traités comme une condition préalable à une IA digne de confiance, et une gouvernance des données défaillante comme une source de risque pour la santé, la sécurité et les droits fondamentaux.
La conséquence pratique : les données d’entraînement cessent d’être un artefact d’ingénierie interne et deviennent un actif réglementé et auditable. « On a scrapé, nettoyé, et ça marche sur le benchmark » n’est pas une posture de conformité. Un régulateur ou un organisme notifié attendra une réponse documentée sur l’origine de chaque dataset, les raisons de son choix, la façon dont il a été préparé et annoté, les biais qui ont été examinés, et les lacunes qui subsistent.
💡 C’est cela, la « gouvernance des données au sens de l’EU AI Act » — et c’est précisément la discipline que la plupart des équipes IA n’ont jamais eu à formaliser.
Que demande l’Article 10 de l’EU AI Act ?
L’Article 10 s’applique aux datasets d’entraînement, de validation et de test utilisés pour développer des systèmes d’IA à haut risque. Il comporte trois étages : des pratiques de gouvernance, des critères de qualité, et une exception encadrée pour les données sensibles. (Un cas limite utile figure au paragraphe 6 : même les systèmes à haut risque qui n’impliquent pas d’entraînement de modèle — les systèmes à base de règles, par exemple — doivent appliquer ces exigences à leurs données de test.)
Les 8 pratiques de gouvernance des données obligatoires — Article 10(2)
Les datasets doivent être soumis à des pratiques de gouvernance et de gestion appropriées à la destination du système. L’article énumère huit domaines que ces pratiques doivent couvrir :
1. Les choix de conception — documenter les décisions pertinentes derrière le dataset : quelles données, dans quelles proportions, structurées comment, et pourquoi.
2. La collecte et l’origine des données — d’où viennent les données, comment elles ont été collectées et — pour les données personnelles — la finalité initiale de leur collecte. C’est la provenance des données, inscrite dans la loi.
3. Les opérations de préparation — annotation, labellisation, nettoyage, mise à jour, enrichissement et agrégation. Le règlement nomme explicitement l’annotation et la labellisation : vos workflows de labellisation, vos guidelines et vos contrôles qualité entrent désormais dans le périmètre réglementaire.
4. La formulation des hypothèses — ce que les données sont censées mesurer et représenter. Si vos variables proxy ne mesurent pas ce que vous croyez, c’est ici que cela ressort.
5. L’évaluation de la disponibilité, de la quantité et de l’adéquation — un jugement documenté, avant le développement, sur le fait de disposer réellement des données que votre destination exige.
6. L’examen des biais — passer les datasets en revue à la recherche de biais susceptibles d’affecter la santé et la sécurité, de porter atteinte aux droits fondamentaux ou de conduire à des discriminations interdites — avec une attention particulière aux boucles de rétroaction où les sorties influencent les entrées futures.
7. La prévention et l’atténuation des biais — des mesures appropriées pour détecter, prévenir et atténuer les biais identifiés au point 6. Examiner ne suffit pas ; il faut agir, et documenter l’action.
8. L’identification des lacunes — repérer les manques de données qui empêchent la conformité, et la façon dont vous comptez les combler.
Notez la constante : chaque pratique implique des preuves. Pas un PDF de politique interne qui dort dans un drive, mais des enregistrements rattachés à des datasets précis — une piste d’audit pour vos données.
Les critères de qualité — Article 10(3) et 10(4)
Au-delà de la gouvernance, les datasets eux-mêmes doivent satisfaire des standards de qualité. Les données d’entraînement, de validation et de test doivent être :
- Pertinentes au regard de la destination du système ;
- Suffisamment représentatives des personnes et des situations que le système rencontrera ;
- Exemptes d’erreurs et complètes — dans la mesure du possible, au regard de la destination (le règlement est pragmatique : il n’exige pas la perfection, mais l’effort documenté) ;
- Statistiquement appropriées pour les personnes ou groupes de personnes sur lesquels le système sera utilisé — un critère qui peut être satisfait au niveau de datasets individuels ou de leur combinaison ;
- Ancrées dans le contexte — reflétant le cadre géographique, contextuel, comportemental ou fonctionnel du déploiement. Un modèle de détection de piétons entraîné uniquement sur des images californiennes en plein jour ne satisfait pas l’Article 10 pour un déploiement sur les routes hivernales d’Europe du Nord.
L’exception « données sensibles » — Article 10(5)
Ici, le règlement fait quelque chose d’inhabituel : il autorise ce que le RGPD interdit normalement. Pour détecter et corriger les biais, les fournisseurs de systèmes à haut risque peuvent, à titre exceptionnel, traiter des catégories particulières de données personnelles (origine ethnique, données de santé, orientation sexuelle et autres catégories de l’article 9 du RGPD) — mais uniquement sous six conditions cumulatives : impossibilité d’atteindre l’objectif avec d’autres données (y compris synthétiques ou anonymisées), pseudonymisation et mesures de sécurité de pointe, contrôles d’accès stricts, interdiction de transmission à des tiers, suppression une fois le biais corrigé, et justification documentée dans les registres de traitement.
L’Omnibus numérique étend cette base légale au-delà des fournisseurs à haut risque (via un nouvel Article 4 bis) aux déployeurs, aux fournisseurs de systèmes non à haut risque et aux fournisseurs de modèles d’IA à usage général. Cela lève un vrai verrou juridique sur les tests d’équité — mais c’est une permission enveloppée d’obligations, pas un blanc-seing...
Le calendrier mis à jour : ce que l’Omnibus numérique a changé (et ce qu’il n’a pas changé)
Le calendrier de conformité a bougé en 2026, et il a le mérite d’être précis : des titres de presse mal compris (« l’UE reporte l’AI Act ») ont endormi certaines équipes dans un faux sentiment de sécurité.
L’Omnibus numérique sur l’IA — accord provisoire du 7 mai 2026, approbation du Parlement le 16 juin, feu vert final du Conseil le 29 juin 2026 — modifie les dates d’application du règlement :
Trois choses à intégrer :
Les exigences n’ont pas changé — seule la date a bougé. L’Omnibus a déplacé des échéances et allégé certaines formalités documentaires pour les PME ; il n’a pas adouci l’Article 10. Chaque pratique de gouvernance et chaque critère de qualité décrits ci-dessus s’appliquent intégralement à partir de décembre 2027.
Seize mois, c’est moins qu’il n’y paraît. Construire un inventaire de datasets, reconstituer la provenance de données collectées il y a des années, formaliser la gouvernance de l’annotation, mener des évaluations de biais et produire une documentation prête pour l’évaluation de conformité est un programme de plusieurs trimestres. Les organisations qui ont traité les deux ans de préavis du RGPD comme un bouton "snooze" ont passé le printemps 2018 en mode urgence. Le même film est déjà programmé pour l’automne 2027.
Les décisions data prises aujourd’hui seront réglementées demain. Tout dataset que vous collectez, annotez ou achetez en 2026 sera encore dans votre corpus d’entraînement au moment où l’application commencera. Reconstituer a posteriori la provenance de données dont personne n’a noté l’origine est quelque part entre le douloureux et l’impossible. Le moment le moins cher pour se conformer à l’Article 10, c’est le moment où le dataset est créé.
Du texte juridique à la réalité d’ingénierie : opérationnaliser l’Article 10
À quoi ressemble concrètement une opération data prête pour l’Article 10 ? D’après notre expérience de création de datasets pour des équipes IA en computer vision, NLP, fine-tuning de LLM et RLHF, la conformité se décompose en cinq capacités opérationnelles.
1. Un inventaire des données d’entraînement
On ne peut pas gouverner ce qu’on ne peut pas énumérer. Le point de départ — et l’étape dont la plupart des organisations découvrent qu’elle leur manque — est un inventaire complet de chaque dataset utilisé pour entraîner, valider et tester chaque système d’IA : données internes, données achetées, datasets ouverts, corpus scrapés, données synthétiques, et les couches annotées construites par-dessus. Chaque entrée a besoin d’un propriétaire, d’une version, d’une licence, d’un enregistrement de provenance et d’un lien vers les systèmes qu’elle alimente. Sans cela, toutes les autres pratiques de l’Article 10 ne sont pas pertinentes.
2. Des enregistrements de provenance et de lignage
L’Article 10(2)(b) exige l’histoire d’origine de vos données. Cela signifie enregistrer, par dataset : la source, la méthode de collecte, la date, la finalité initiale (pour les données personnelles), les conditions de licence, et chaque transformation appliquée depuis — avec la capacité de retracer n’importe quel exemple d’entraînement à travers le nettoyage, le filtrage, l’enrichissement et l’annotation jusqu’à sa source. C’est du lignage de données, mais avec un standard de preuve juridique attaché.
3. Une gouvernance documentée de l’annotation et de la labellisation
Parce que le règlement nomme explicitement l’annotation et la labellisation comme des opérations de préparation réglementées, votre pipeline de labellisation devient une pièce à conviction. Les auditeurs attendront : des guidelines d’annotation écrites et leur historique de versions, des dossiers de formation et de qualification des annotateurs, des procédures d’assurance qualité, des métriques d’accord inter-annotateurs (IAA), et des workflows de revue et d’escalade. Le crowdsourcing anonyme — où personne ne peut dire qui a labellisé quoi, selon quelles instructions, avec quel contrôle qualité — est structurellement difficile à réconcilier avec cette exigence.
4. Des workflows d’évaluation et d’atténuation des biais
Les points (f) et (g) exigent un processus répétable : définir les groupes protégés et les modes de défaillance pertinents pour votre destination, mesurer la représentation et la performance sur chacun, documenter les constats, appliquer des mesures correctives (rééquilibrage, collecte ciblée, ré-annotation), et re-mesurer. Un audit d’équité ponctuel ne satisfait pas une obligation de cycle de vie ; ce processus doit tourner à chaque évolution du dataset ou du contexte de déploiement.
5. Une analyse des lacunes et une feuille de route data vivante
Enfin, l’Article 10 vous demande d’être honnête sur ce que vos données ne couvrent pas — les géographies, démographies, cas limites et contextes où elles sont insuffisantes — et de documenter comment vous comblerez ces manques. Bien menée, cette analyse cesse d’être un exercice de conformité et devient votre feuille de route d’acquisition de données.
Le recadrage qui compte : aucune de ces cinq capacités n’est du poids mort réglementaire. Les équipes dotées d’inventaires propres, de processus d’annotation documentés et de workflows de biais systématiques livrent de meilleurs modèles, avec moins de mauvaises surprises en fin de projet. L’Article 10 est, au fond, de l’hygiène d’ingénierie ML rendue obligatoire. Pour les équipes qui opèrent déjà sur des fondations data solides, la conformité revient à formaliser l’existant ; pour les autres, elle fait d’une pierre deux coups avec la réduction de la dette technique.
L’Article 10 descend la chaîne d’approvisionnement — choisissez vos partenaires data en conséquence
Voici la partie de l’Article 10 qui n’est pas écrite dans l’article lui-même mais qui en découle inévitablement : les fournisseurs ne peuvent pas produire ces preuves seuls.
Si un tiers collecte vos données, construit vos datasets ou réalise votre annotation, les enregistrements de provenance, les guidelines d’annotation, les qualifications des annotateurs et les métriques QA que l’Article 10 exige résident — au moins en partie — chez ce partenaire.
Les fournisseurs vont donc répercuter ces exigences en aval, contractuellement. Les prestataires de données et d’annotation incapables de fournir une documentation prête pour l’audit deviendront des passifs de conformité, et les équipes achats commencent déjà à poser les questions :
- Pouvez-vous documenter précisément qui a annoté chaque élément, selon quelle version de guideline ?
- Pouvez-vous fournir la provenance des données collectées ou sourcées, licences comprises ?
- Pouvez-vous produire des rapports QA et d’accord inter-annotateurs par lot ?
- Pouvez-vous démontrer que vos équipes sont formées, qualifiées et travaillent dans des conditions traçables ?
💡 Si votre fournisseur data actuel répond par le silence — ou par « nous utilisons une foule mondiale d’annotateurs » — vous venez de trouver une lacune Article 10 !
Comment Innovatiana construit des datasets prêts pour la conformité
C’est précisément le modèle sur lequel Innovatiana s’est construite — des années avant que l’AI Act n’en fasse une attente réglementaire.
Nous sommes une société française qui fabrique des datasets pour les équipes IA : annotation computer vision, NLP, traitement de documents, IA générative et fine-tuning de LLM, modération et RLHF. Et nous le faisons d’une manière qui répond directement aux exigences de l’Article 10 :
Des équipes internes et formées — pas de crowdsourcing anonyme. Nous recrutons et formons nos propres Data Labelers et experts métier. Chaque annotation est attribuable à un professionnel identifié et qualifié, travaillant selon des guidelines documentées. C’est un choix éthique — salaires justes, vraies perspectives de carrière, conditions de travail dignes — et c’est aussi, il se trouve, exactement ce que la traçabilité réglementaire exige. L’éthique by design et la conformité by design convergent.
Une traçabilité complète du processus d’annotation. Versions de guidelines, affectation des annotateurs, couches de revue, métriques QA, résolution des désaccords : nous documentons les opérations de préparation que l’Article 10(2)(c) réglemente, pour que nos clients puissent verser ces preuves directement dans leur documentation technique au titre de l’Article 11 et de l’Annexe IV.
Un sourcing de données transparent. Lorsque nous collectons ou sourçons des données pour un dataset, nous divulguons leur origine et leurs conditions d’utilisation — l’enregistrement de provenance qu’attend l’Article 10(2)(b).
La qualité comme propriété mesurable. Représentativité, taux d’erreur, couverture des cas limites et des contextes de déploiement : nous traitons les critères de qualité de l’Article 10(3) comme des cibles d’ingénierie avec des seuils d’acceptation, pas comme des vœux pieux. Le tout dans un cadre de sécurité et de confidentialité des données aligné sur le RGPD.
En résumé : quand un client entraîne un système à haut risque sur un dataset que nous avons fabriqué, la piste d’audit Article 10 de ce dataset existe déjà. Découvrez comment nous travaillons à travers nos études de cas.
Voici Dataset Finder : la gouvernance de datasets et l’inventaire de données d’entraînement, en produit
Construire des centaines de datasets nous a appris autre chose : le plus difficile dans la gouvernance des données au sens de l’EU AI Act, ce n’est pas un dataset isolé — c’est l'inventaire. La plupart des équipes IA n’ont pas un dataset ; elles en ont des dizaines ou des centaines, éparpillés entre buckets, drives et livraisons de prestataires, avec une provenance qui vit dans la tête des gens.
Nous avons donc construit un outil pour résoudre ce problème chez nous. Il s’appelle Dataset Finder, et c’est avec lui que nous gouvernons nos datasets aujourd’hui :
- Inventaire des données d’entraînement — un catalogue unique de chaque dataset, avec propriétaire, versioning, et les systèmes d’IA que chaque dataset alimente. Le point de départ de l’Article 10, automatisé.
- Suivi de la provenance et du data lineage — source, licence, contexte de collecte, et chaque étape de préparation (nettoyage, enrichissement, annotation) enregistrée par version de dataset.
- Métadonnées de gouvernance alignées sur l’Article 10 — choix de conception, hypothèses, évaluations d’adéquation, examens de biais et lacunes identifiées, capturés sous forme d’enregistrements structurés plutôt que de documents dispersés — prêts à alimenter votre documentation technique Annexe IV.
- Exports prêts pour l’audit — parce que le vrai test d’un système de gouvernance, c’est sa capacité à répondre à la question d’un régulateur en minutes, pas en semaines.
💡 Dataset Finder sera lancé publiquement d’ici la fin de l’année — un calendrier délibérément choisi pour laisser aux équipes une vraie piste d’envol avant l’échéance « haut risque » de décembre 2027. Pour un accès anticipé, ou pour construire votre inventaire de données d’entraînement avec un accompagnement expert plutôt qu’en partant de zéro, contactez-nous.
Nos recommandations : un plan d’action gouvernance des données pour l’EU AI Act
Que vous travailliez avec nous ou non, voici la séquence que nous recommandons à toute équipe IA qui se prépare à l’Article 10. Soyons réalistes : c’est un programme de 12 à 18 mois — soit exactement la piste qui reste avant décembre 2027.
1. Classifiez d’abord vos systèmes. Déterminez lesquels de vos systèmes d’IA sont à haut risque au titre de l’Annexe III (ou de l’Annexe I). Tout le reste de ce plan dépend de cette réponse — et une erreur de classification, dans un sens comme dans l’autre, coûte cher.
2. Construisez votre inventaire de données d’entraînement maintenant. Énumérez chaque dataset d’entraînement, de validation et de test par système. Prévoyez plus de temps que vous ne l’imaginez ; prévoyez de trouver des datasets dont personne ne se souvient.
3. Reconstituez la provenance tant que c’est encore possible. Pour chaque dataset : source, méthode de collecte, licence, finalité initiale. Les personnes qui détiennent cette connaissance quittent les entreprises ; documentez avant qu’elles ne partent.
4. Formalisez la gouvernance de l’annotation. Guidelines écrites, versioning, dossiers de qualification des annotateurs, métriques QA. Si vous externalisez la labellisation, exigez ces preuves contractuellement — dès aujourd’hui, pour chaque nouveau projet.
5. Établissez une base de référence biais et représentativité. Mesurez vos datasets par rapport à votre contexte réel de déploiement (géographie, démographie, conditions). Documentez constats et mesures correctives. Faites-en un processus récurrent, pas un événement.
6. Écrivez vos hypothèses et vos lacunes. Que chaque dataset est-il censé représenter ? Où est-il insuffisant ? Transformez la liste des lacunes en feuille de route data, avec des responsables et des dates.
7. Auditez votre chaîne d’approvisionnement data. Envoyez vos questions Article 10 à chaque prestataire de données et d’annotation. Remplacez ceux qui ne peuvent pas répondre.
8. Connectez la gouvernance des données au reste de votre dispositif de conformité. Les preuves Article 10 alimentent la documentation technique de l’Article 11, la gestion des risques de l’Article 9 et votre évaluation de conformité. Concevez les enregistrements une fois, réutilisez-les partout.
9. N’attendez pas décembre 2027. Les obligations de transparence tombent en août 2026, les questionnaires achats circulent déjà, et chaque dataset créé sans gouvernance est du retravail futur. Le report est une piste d’envol, pas une pause.
👉 Prenez de l’avance sur l’Article 10 avec Innovatiana
L’EU AI Act a fait des données d’entraînement un actif réglementé — et de la gouvernance des datasets un avantage compétitif. Innovatiana fabrique des datasets de haute qualité, entièrement traçables, avec des équipes expertes internes ; et Dataset Finder apporte cette même discipline de gouvernance à l’ensemble de votre patrimoine data.
Demandez un devis gratuit → ou parlez à un expert → pour discuter de vos datasets, de votre préparation à l’Article 10, ou d’un accès anticipé à Dataset Finder.
________________________________________
Cet article est fourni à titre d’information générale et ne constitue pas un conseil juridique. Pour toute question sur vos obligations au titre du Règlement (UE) 2024/1689, consultez un conseil juridique qualifié.
