Gouvernance des données : des piliers aux preuves

L’essentiel

• La gouvernance des données désigne le modèle opérationnel qui fixe les règles, désigne les responsables, organise les processus et outille le tout. Sur ce point, tous les guides disponibles convergent.
• Ce qui a changé, c’est la finalité. Dès qu’un système d’IA entre dans le périmètre, la gouvernance des données doit produire des preuves documentaires et non plus seulement des décisions.
• L’article 10 du règlement européen sur l’IA impose huit exigences précises aux jeux de données d’entraînement, de validation et de test.
• Le DAMA-DMBOK, le DCAM, le DGI et COBIT sont antérieurs à la réglementation des données d’entraînement. Ils restent des ossatures utiles, mais aucun ne dit quoi archiver.
• Un seul test tranche : votre dispositif sait-il produire, pour n’importe quel modèle en production, une fiche de jeu de données, un relevé de traçabilité et un rapport d’examen des biais ?

Ce que recouvre réellement la gouvernance des données

La gouvernance des données est le modèle opérationnel qui détermine la manière dont une organisation collecte, conserve, protège et exploite ses données. Elle repose sur quatre composantes récurrentes : des politiques et des normes qui posent les règles, des rôles et des responsabilités qui portent la redevabilité, des processus qui transforment les règles en routine, et une technologie qui conserve la trace de ce qui s’est produit.

Ce consensus est exact, mais il reste incomplet. Il décrit une structure de décision et ne dit presque rien de ce que cette structure doit produire. Pendant vingt ans, l’omission était sans conséquence : le destinataire du dispositif était l’organisation elle-même, sous la forme d’un tableau de bord qualité, d’un comité de pilotage et d’un catalogue destiné aux analystes.

Cette époque est révolue. Lorsque les données alimentent un système d’IA, le destinataire de votre gouvernance des données peut être un organisme notifié, une autorité de surveillance du marché ou un grand compte qui conduit sa due diligence fournisseur. Ces lecteurs n’acceptent pas un modèle opérationnel en guise de réponse : ils demandent des pièces. Un dispositif incapable de les fournir relève du récit de conformité, ce qui est tout autre chose. Le sujet s’inscrit dans la question plus large de la gouvernance de l’IA comme discipline opérationnelle.

Gouvernance des données et gestion des données

La distinction est plus simple que ne le suggèrent la plupart des guides. La gestion des données relève de l’exécution : les flux, le stockage, les règles qualité, les données de référence, l’intégration. La gouvernance des données constitue la couche d’autorité au-dessus : qui a le droit de décider, quelle est la norme applicable, et comment l’organisation démontre que la norme a été respectée.

Une formulation commode consiste à dire que la gestion répond au comment, et la gouvernance à la question de savoir qui l’a décidé et où se trouve la preuve. Un dispositif qui ne produit que de la documentation de processus a décrit de la gestion et l’a baptisée gouvernance.

Les quatre modèles de référence et leur vocation d’origine

Toutes les pages qui traitent du sujet citent la même liste. Ces modèles ne sont pas concurrents : ils ont été conçus pour des usages différents.

Modèle	Origine	Vocation	Usage recommandé
DAMA-DMBOK	DAMA International	Définir la pratique de la gestion des données sur onze domaines de connaissance	Le référentiel de pratique et le vocabulaire
DCAM	EDM Council	Évaluer la maturité des capacités par rapport à un étalon	L’instrument de mesure
Cadre DGI	Data Governance Institute	Organiser les droits de décision et la redevabilité	La couche organisationnelle
COBIT	ISACA	Gouverner le système d’information et le risque technologique	Le vocabulaire d’audit et de contrôle

La combinaison la plus répandue en 2026 consiste à s’appuyer sur le DAMA-DMBOK pour définir la pratique et sur le DCAM pour mesurer l’écart. La version 3.0 du DMBOK, en cours d’élaboration, étend son périmètre à la gestion des données d’apprentissage automatique, ce qui indique clairement la direction prise par la profession.

Pourquoi aucun n’a été conçu pour les systèmes d’IA

Tous quatre ont été pensés pour gouverner la donnée comme un actif de l’organisation. Aucun n’a été pensé pour la gouverner comme un composant d’un produit réglementé. Le glissement n’a rien de cosmétique.

Dans une logique d’actif, la question posée à un jeu de données porte sur son exactitude, sa disponibilité, sa sécurité et son propriétaire. Dans une logique de produit, la question devient tout autre : ce jeu d’entraînement précis était-il pertinent et suffisamment représentatif au regard de la finalité pour laquelle le modèle a été mis sur le marché, et savez-vous le démontrer ? Une gouvernance des données bâtie sur la logique d’actif répondra sans peine à la première question et pas du tout à la seconde.

Ce que l’arrivée de l’IA change dans le patrimoine informationnel

Trois évolutions se produisent simultanément.

D’abord, les données d’entraînement, de validation et de test deviennent un objet réglementé assorti de critères de qualité légaux. Elles ne sont plus de simples intrants analytiques : elles constituent le fondement probatoire d’une affirmation de conformité portant sur un produit.

Ensuite, chaque jeu de données acquiert un responsable qui doit répondre de sa représentativité, et non seulement de son exactitude. Ces deux propriétés sont distinctes : un jeu de données peut être parfaitement exact au sujet de la mauvaise population.

Enfin, l’inventaire dont dépend votre gouvernance des données cesse d’être fiable. Le principe même du dispositif suppose que l’on sache quels systèmes consomment quelles données. Les outils non déclarés brisent silencieusement cette hypothèse, raison pour laquelle le shadow AI constitue d’abord un problème de données avant d’être un problème de sécurité. Lorsqu’une équipe verse des dossiers clients dans un assistant non homologué, aucun registre n’enregistre ce flux et aucune politique ne s’y applique.

Article 10 du règlement IA : les obligations à satisfaire

L’article 10 est la disposition qui fait passer la gouvernance des données du statut de bonne pratique à celui d’obligation juridique pour les systèmes d’IA à haut risque. Aux termes de l’article 10, paragraphe 1, les systèmes à haut risque développés à partir de techniques d’entraînement doivent reposer sur des jeux de données d’entraînement, de validation et de test répondant aux critères de qualité énoncés par l’article.

Le paragraphe 2 précise que ces jeux de données doivent faire l’objet de pratiques de gouvernance et de gestion appropriées à la finalité prévue, puis énumère huit points à couvrir. Lus comme un cahier des charges, ils imposent de documenter :

1. Les choix de conception, formalisés plutôt que supposés.
2. Les processus de collecte et l’origine des données, ainsi que, pour les données à caractère personnel, la finalité initiale de la collecte.
3. Les opérations de préparation : annotation, étiquetage, nettoyage, mise à jour, enrichissement et agrégation.
4. Les hypothèses relatives à ce que les données sont censées mesurer et représenter.
5. L’évaluation de la disponibilité, de la quantité et de l’adéquation des jeux de données nécessaires.
6. L’examen des biais susceptibles de porter atteinte à la santé, à la sécurité ou aux droits fondamentaux, y compris les effets discriminatoires.
7. Les mesures appropriées de détection, de prévention et d’atténuation de ces biais.
8. L’identification des lacunes ou insuffisances qui empêchent la conformité, et la manière d’y remédier.

Le paragraphe 3 fixe le niveau d’exigence : les jeux de données doivent être pertinents, suffisamment représentatifs et, dans toute la mesure du possible, exempts d’erreurs et complets au regard de la finalité prévue, avec des propriétés statistiques appropriées aux populations concernées. Le paragraphe 4 impose de tenir compte des caractéristiques propres au cadre géographique, contextuel, comportemental ou fonctionnel d’utilisation. Un modèle de recrutement validé sur un marché du travail national n’emporte pas cette validation lorsqu’il franchit une frontière.

Le paragraphe 5 contient une permission étroite et souvent mal lue : le fournisseur peut, à titre exceptionnel, traiter des catégories particulières de données à caractère personnel lorsque cela est strictement nécessaire à la détection et à la correction des biais, sous réserve de garanties appropriées et faute d’alternative efficace. Il s’agit d’une dérogation encadrée, non d’une autorisation de collecte routinière : la CNIL a d’ailleurs constamment rappelé que la minimisation reste le principe directeur. Le paragraphe 6 referme le dispositif pour les systèmes qui n’apprennent pas à partir de données, seuls les jeux de test étant alors visés. L’architecture d’ensemble de ces obligations est détaillée dans notre guide opérationnel du règlement IA.

L’annexe IV et l’obligation de fiche descriptive

L’article 10 dit ce que les données doivent être. L’annexe IV dit ce qui doit être écrit. Le point 2 d) de l’annexe IV exige que la documentation technique comprenne, le cas échéant, des fiches décrivant les méthodes et techniques d’entraînement ainsi que les jeux de données utilisés : description générale, provenance, portée et principales caractéristiques, modalités d’obtention et de sélection des données, procédures d’étiquetage et méthodes de nettoyage. Le point 2 g) étend la même discipline aux données de validation et de test et aux métriques d’exactitude et de robustesse.

C’est cette phrase qui modifie la nature du travail attendu. La traçabilité cesse d’être un confort pour les analystes et devient un livrable documentaire au format imposé. La référence académique sous-jacente est l’article de Gebru et ses coauteurs, Datasheets for Datasets, qui proposait exactement cette forme : motivation, composition, processus de collecte, prétraitement, usages, diffusion et maintenance. Notre guide de la documentation des systèmes d’IA couvre le reste du dossier.

Ce que l’article 26, paragraphe 4, impose au déployeur

La littérature sur le sujet s’adresse presque toujours au propriétaire des données. Le règlement lie aussi l’organisation qui se contente d’acheter le système. Aux termes de l’article 26, paragraphe 4, le déployeur qui exerce un contrôle sur les données d’entrée doit veiller à ce que celles-ci soient pertinentes et suffisamment représentatives au regard de la finalité prévue. Le paragraphe 6 impose la conservation des journaux générés automatiquement pendant six mois au minimum.

Autrement dit, si vous exploitez sous licence un modèle de scoring que vous alimentez avec vos propres dossiers, votre gouvernance des données porte une obligation légale sur ces dossiers. Acheter le modèle n’externalise pas l’obligation portant sur la donnée.

Aligner les piliers sur l’ISO 42001 et le NIST AI RMF

La bonne démarche ne consiste pas à remplacer le dispositif existant, mais à redéfinir la sortie attendue de chaque pilier. Le tableau ci-dessous en donne la version condensée.

Pilier classique	ISO/IEC 42001 annexe A	NIST AI RMF	Livrable attendu
Politiques et normes	A.7.2 données de développement, A.7.4 qualité des données	MAP 2.3	Critères de qualité écrits par finalité
Rôles et responsabilités	A.7.3 acquisition des données	MAP 4.1, MAP 4.2	Responsable nommé et revue des données tierces
Processus	A.7.6 préparation des données	MAP 2.3	Protocole d’étiquetage, rapport d’examen des biais
Technologie	A.7.5 provenance des données	MEASURE 2.2	Relevé de traçabilité de la source à l’entrée du modèle

La norme ISO/IEC 42001 regroupe ses exigences relatives aux données dans le contrôle A.7 de l’annexe A, décliné en A.7.2 données pour le développement et l’amélioration des systèmes d’IA, A.7.3 acquisition des données, A.7.4 qualité des données, A.7.5 provenance des données et A.7.6 préparation des données. Si vous visez la certification, c’est cette liste que votre gouvernance des données devra satisfaire, et elle s’articule avec l’article 10 sans le dupliquer. Nous avons expliqué ailleurs pourquoi l’ISO 42001 seule ne suffit pas à la conformité au règlement IA.

Le NIST AI RMF fournit quant à lui un vocabulaire de risque plutôt qu’une cible de certification. La sous-catégorie MAP 2.3 traite de l’intégrité scientifique et des activités de test, d’évaluation, de vérification et de validation, en incluant explicitement la conception expérimentale ainsi que la collecte et la sélection des données. Les sous-catégories MAP 4.1 et 4.2 portent sur le risque lié aux données de tiers et sur l’obligation d’examiner les ressources externes sous l’angle des biais, de la confidentialité et de la sécurité avant toute homologation. Ce dernier point pèse chaque année davantage, la plupart des organisations entraînant désormais leurs modèles sur des données qu’elles n’ont pas collectées. Le croisement complet des référentiels figure dans notre comparaison NIST AI RMF, ISO 42001, règlement IA et principes de l’OCDE.

La liste des pièces à produire

Voici la traduction opérationnelle. Une gouvernance des données couvrant des systèmes d’IA doit pouvoir produire, sur demande et par système, les neuf pièces suivantes.

1. Un registre des jeux de données relié à l’inventaire des systèmes d’IA, afin que tout modèle puisse être rattaché aux données qu’il a consommées.
2. Une fiche descriptive pour chaque jeu d’entraînement, de validation et de test, au format de l’annexe IV.
3. Un relevé de traçabilité allant du système source à l’entrée du modèle, transformations comprises.
4. Un rapport d’examen des biais précisant les caractéristiques protégées examinées et la méthode retenue.
5. Un journal des décisions d’atténuation, y compris les décisions d’accepter un biais résiduel et l’identité de leur auteur.
6. Un registre des lacunes et insuffisances avec responsables et échéances, qui donne corps au point h) du paragraphe 2.
7. Un protocole d’annotation, assorti d’une mesure d’accord inter-annotateurs lorsque les étiquettes comportent une part de jugement.
8. Un relevé de conservation et de base légale, articulé avec l’analyse d’impact relative à la protection des données lorsque des données personnelles sont concernées.
9. Une validation nominative par version de jeu de données, faute de quoi la pièce reste une affirmation et non un contrôle.

Les points quatre et cinq sont ceux où les programmes sont les plus fragiles, et ce sont précisément ceux qu’un auditeur réclame en premier. Notre guide des biais de l’IA détaille les méthodes d’examen.

Le registre des données critiques, étendu à l’IA

Les entités régulées tiennent déjà un registre des données critiques. Vous n’avez pas besoin d’un second registre, mais d’une clé étrangère.

Ajoutez une relation entre chaque donnée critique et les systèmes d’IA qui la consomment, et le registre cesse d’être un artefact de qualité pour répondre à des questions de conformité : quels modèles sont affectés si cette donnée se dégrade, quels jeux de données ont hérité de ses défauts connus, et quels responsables de modèles doivent être prévenus lorsque sa définition change. Cette jointure convertit un travail déjà réalisé en preuve réglementaire pour un coût marginal, et c’est le geste au meilleur rendement pour un dispositif existant.

Un déploiement en quatre-vingt-dix jours

Voici une séquence réaliste pour une organisation disposant déjà d’une gouvernance des données et devant l’étendre à l’IA.

1. Semaines 1 et 2, périmètre et déclencheur juridique. Déterminez quels systèmes relèvent du haut risque, lesquels sont des modèles à usage général que vous déployez seulement, et lesquels sont hors champ. Les obligations diffèrent nettement et les erreurs de qualification coûtent cher.
2. Semaines 3 et 4, inventaire. Recensez les systèmes d’IA et les jeux de données consommés. Attendez-vous à une liste incomplète au premier passage et prévoyez une campagne de détection des outils non déclarés.
3. Semaine 5, classification. Qualifiez chaque jeu selon sa sensibilité, sa base légale, son origine (interne, tiers, synthétique, moissonnée) et sa nature d’entraînement, de validation ou de test.
4. Semaine 6, responsabilités. Désignez un responsable nommé par jeu de données. Une personne, pas une équipe : une responsabilité partagée est une responsabilité absente.
5. Semaines 7 à 9, documentation. Rédigez les fiches au format de l’annexe IV, en commençant par le système le plus exposé, car c’est là que le format sera réellement éprouvé.
6. Semaines 10 et 11, test de représentativité. Comparez les propriétés statistiques des jeux de données à la population visée et au cadre de déploiement. Consignez les écarts constatés au lieu de les corriger en silence.
7. Semaine 12, validation et cadence. Obtenez l’approbation nominative, puis fixez le déclencheur de revue. Rattachez-le aux réentraînements et non au calendrier.

C’est sur ce dernier point que les programmes échouent le plus souvent. Si votre cadre de gouvernance de l’IA revoit les données une fois par an alors que les modèles sont réentraînés chaque semaine, la documentation décrit un système qui n’existe plus.

Les cinq échecs récurrents

La maturité de façade. Le programme s’auto-évalue au regard d’un modèle de capacités et annonce des progrès sans aucune preuve derrière la note. La déclaration du management ne constitue pas un élément probant.

L’outil avant la règle. Un catalogue est acquis avant que la politique qu’il doit appliquer ait été écrite. L’outil encode alors les conventions du prestataire qui l’a paramétré.

L’absence de responsable des données d’entraînement. Les systèmes sources ont des propriétaires. Le jeu d’entraînement dérivé, constitué à partir de quatre d’entre eux, filtré, réétiqueté puis figé pour une version de modèle, n’en a généralement aucun.

Les registres jamais joints. Le catalogue de données et l’inventaire des systèmes d’IA vivent dans des outils distincts tenus par des équipes distinctes, si bien qu’aucune requête ne peut établir quel modèle a utilisé quelles données. C’est la première cause d’un audit IA qui ne trouve rien d’exploitable.

Un périmètre limité aux données personnelles. Les programmes de protection des données couvrent bien le personnel. L’article 10 couvre l’ensemble des données d’entraînement, y compris opérationnelles, issues de capteurs ou synthétiques, sans aucune composante personnelle.

Questions fréquentes

Quels sont les quatre piliers de la gouvernance des données ?

Les politiques et normes, les rôles et responsabilités, les processus et la technologie. Certains éditeurs les déclinent en cinq, sept ou dix composantes, mais les ajouts relèvent de la subdivision plutôt que de la nouveauté : la qualité, la gestion des métadonnées et la traçabilité s’inscrivent dans les processus et la technologie. Dès lors que des systèmes d’IA sont concernés, traitez une cinquième préoccupation comme obligatoire bien qu’elle soit rarement citée : les preuves produites, c’est-à-dire les fiches, les relevés de traçabilité et les rapports de biais qu’un régulateur peut effectivement lire.

Quels sont les principes clés de la gouvernance des données ?

La redevabilité avec un responsable nommé par jeu de données, la transparence sur l’origine et les transformations, une qualité définie au regard d’une finalité déclarée plutôt que dans l’abstrait, une protection proportionnée à la sensibilité et à la base légale, et la traçabilité de la source jusqu’à la consommation. Sous l’empire du règlement IA, la qualité et la traçabilité pèsent le plus lourd, l’article 10, paragraphe 3, imposant un test relatif à la finalité et non une exigence générale.

Quelle différence entre gouvernance des données et gouvernance de l’IA ?

La première gouverne la donnée. La seconde gouverne les systèmes bâtis sur elle, ainsi que les modèles, les décisions de déploiement, la supervision humaine et la gestion des incidents. Elles se recouvrent en un point exactement, les données d’entraînement, et c’est précisément là que le règlement IA place ses obligations documentaires les plus lourdes. En pratique, les deux doivent partager un inventaire et une taxonomie de risque tout en conservant des responsables et des cadences de revue distincts.

Quel référentiel adopter : DAMA-DMBOK, DCAM ou DGI ?

La question du choix exclusif se pose rarement. Le DAMA-DMBOK fournit la définition de la pratique et le vocabulaire, le DCAM la mesure de maturité, le DGI la conception des droits de décision. La combinaison courante associe le premier pour la pratique et le second pour mesurer la progression. Si des systèmes d’IA entrent dans le périmètre, aucun des trois ne suffit isolément, puisqu’aucun ne spécifie les pièces exigées par l’annexe IV : il faut y superposer l’annexe A.7 de l’ISO/IEC 42001.

Le règlement IA impose-t-il une gouvernance des données ?

Pour les systèmes à haut risque, en pratique oui. L’article 10, paragraphe 2, impose que les jeux d’entraînement, de validation et de test fassent l’objet de pratiques de gouvernance et de gestion appropriées, puis énumère huit points à couvrir. Le texte ne désigne aucun référentiel et n’impose aucun modèle particulier, de sorte qu’un dispositif existant adapté peut suffire. Ce qu’il impose en revanche, c’est la production documentaire, par le canal de l’annexe IV.

Qui porte la responsabilité du dispositif ?

Elle revient généralement au directeur des données ou à un responsable équivalent, assisté d’une instance de pilotage pour les arbitrages transverses. Le titre importe moins que deux conditions : que la responsabilité au niveau du jeu de données soit individuelle, et que son titulaire ait le pouvoir de bloquer une mise en production. Lorsque des systèmes d’IA sont concernés, le responsable de la gouvernance des données et celui de la gouvernance de l’IA doivent décider conjointement du sort des données d’entraînement, aucun des deux ne pouvant approuver seul.

Conclusion

La littérature disponible vous dira que la gouvernance des données repose sur quatre piliers et qu’il convient de choisir un référentiel. C’est exact, et c’est là que s’arrête l’essentiel des conseils. La question difficile est ailleurs : que remettez-vous lorsqu’une partie extérieure à votre organisation demande comment le jeu d’entraînement d’un modèle a été constitué, s’il représentait les personnes auxquelles le modèle allait être appliqué, et qui l’a validé.

Si la réponse honnête se limite aujourd’hui à une politique et à une capture d’écran de catalogue, la faiblesse ne tient pas aux piliers. Elle tient aux pièces qu’on ne leur a jamais demandé de produire. Commencez par le registre des jeux de données relié à l’inventaire des systèmes d’IA : le reste de la chaîne probatoire trouvera où s’accrocher.

Découvrez comment AI Sigil transforme vos obligations de gouvernance des données en preuves opposables.