Provenance et traçabilité des données

Votre système d'IA a pris une décision. Pouvez-vous tracer les données qui la sous-tendent ?

La traçabilité des données constitue l'infrastructure qui permet de répondre aux interrogations sur les données d'IA — non pas un tableau de bord ou une entrée de catalogue, mais un système consignant l'origine des données d'entraînement, les transformations qu'elles ont subies, les modèles qui les ont consommées et la possibilité de vérifier cette chaîne de manière cryptographique (voir nos recherches sur la conception d'architectures d'IA vérifiables pour l'entreprise post-confiance).

Un tribunal vient d'ordonner à OpenAI de produire 78 millions de journaux de sorties de ChatGPT parce que les plaignants devaient retracer l'influence des données d'entraînement protégées par le droit d'auteur sur le comportement du modèle. C'est un exemple extrême. La version quotidienne est plus discrète mais tout aussi lourde de conséquences :

• Un régulateur demandant quelles données ont servi à entraîner votre modèle d'octroi de crédit.
• Une demande de suppression au titre du RGPD ayant atteint vos tables sources mais pas les six modèles en aval qui ont consommé les enregistrements supprimés.
• Un incident d'empoisonnement de données où vous ne pouvez pas identifier les lots d'entraînement compromis parce que rien dans votre pipeline n'a consigné la réponse.

Notre approche consiste à bâtir cette couche de traçabilité au sein des outils de pipeline déjà exécutés par les entreprises : Spark, dbt, Airflow, Dagster et les ETL sur mesure.

Pourquoi le lignage de catalogue diffère de la traçabilité des données d'entraînement

La plupart des entreprises possèdent déjà un catalogue de métadonnées. Collibra, Alation, Atlan ou DataHub couvre le lignage au niveau des tables, utile pour l'analyse d'impact des changements de schéma. Il ne répond pas aux questions que les régulateurs, auditeurs et juristes posent sur les systèmes d'IA. L'écart apparaît sur trois plans :

Notre approche s'articule avec le catalogue que vous possédez déjà. La couche de traçabilité est conçue pour se placer en dessous, instrumentant l'exécution réelle du pipeline afin de capturer les détails au niveau de l'enregistrement et de la transformation que les catalogues n'ont pas été conçus pour fournir.

Ce que nous instrumentons et comment

Le défi central consiste à capturer la traçabilité à la granularité requise par les régulateurs sans pénaliser le débit du pipeline. Le hachage SHA-256 par enregistrement sur un job Spark traitant 500 millions de lignes ajoute une surcharge de 15 à 40 % — ce qui est rarement acceptable en production. Notre approche calibre la granularité de la traçabilité en fonction du profil de risque réel.

Instrumentation des pipelines avec OpenLineage

L'instrumentation utilise OpenLineage comme standard d'émission là où les intégrations existent (Spark, Airflow, dbt et Dagster disposent tous de niveaux de prise en charge variables), avec des facettes personnalisées capturant les métadonnées spécifiques au ML : paramètres d'ingénierie des caractéristiques, configurations d'augmentation des données, stratégies d'échantillonnage et critères de découpage entraînement/validation/test. Lorsque l'intégration OpenLineage est incomplète ou omet des événements — le listener Spark étant connu pour perdre silencieusement des facettes personnalisées sous un grand nombre de partitions —, l'approche ajoute une instrumentation complémentaire conçue pour capturer ce qui échappe à l'intégration standard, comme détaillé dans notre livre blanc technique sur la sécurisation de la chaîne logistique ML tout au long du cycle de vie.

Traçabilité pour les données non structurées

Pour les données d'entraînement non structurées — documents, images, audio et vidéo utilisés dans les pipelines de fine-tuning ou RAG —, l'approche applique une empreinte de contenu avec hachage perceptuel (pHash pour les images, chromaprint pour l'audio) aux côtés de hachages cryptographiques, permettant le suivi de la traçabilité même lorsque le contenu subit une transformation avec perte — voir une démonstration fonctionnelle du suivi de la traçabilité audio.

Le problème de l'effacement selon le RGPD que personne n'a résolu proprement

Le RGPD, en son Article 17 , accorde le droit à l'effacement. Pour les bases de données traditionnelles, il suffit de supprimer et de confirmer. Pour les systèmes d'IA, il s'agit d'un problème non résolu déguisé en case à cocher de conformité. Les grands modèles de langage ne stockent pas les données sous forme d'enregistrements discrets — ils stockent des motifs statistiques dérivés des données d'entraînement, répartis sur des milliards de paramètres. La suppression des données d'une personne dans la table source n'élimine pas leur influence sur les poids du modèle, et le RGPD n'offre aucun cadre pour interpréter ce que signifie « effacement » une fois que les données ont été absorbées dans l'architecture décisionnelle d'un modèle.

La recherche sur le désapprentissage automatique progresse. En septembre 2025, des chercheurs de l'UC Riverside ont fait la démonstration du « source-free unlearning », une méthode certifiée qui fonctionne sans les données d'entraînement d'origine, à l'aide de jeux de données de substitution et d'un ajustement des paramètres fondé sur des mises à jour de Newton. Mais aucune méthode de désapprentissage n'est prête pour la production à l'échelle de l'entreprise. Les approches pratiques actuelles combinent trois niveaux :

• Prévention — écarter les données personnelles des données d'entraînement via des barrières de prétraitement.
• Remédiation rapide — suppression dans les index de recherche, les caches et les journaux.
• Documentation opposable — registres de traçabilité prouvant quelles données sont entrées dans quels modèles, facilitant les décisions de réentraînement lorsque le désapprentissage ne suffit pas.

L'infrastructure de traçabilité est conçue pour établir le prérequis indispensable à toute stratégie d'effacement : une cartographie interrogeable reliant l'identifiant d'une personne concernée à chaque modèle, pipeline et artefact ayant consommé ses données. Grâce à elle, vous répondez à la question « quels modèles doivent être réentraînés ? » quelques minutes après une demande de suppression, au lieu de découvrir des mois plus tard qu'une session de fine-tuning oubliée a utilisé les données concernées.

Article 10 de l'EU AI Act : des documents de politique aux preuves de pipeline

L'article 10 de l'EU AI Act exige que les données d'entraînement, de validation et de test fassent l'objet de « pratiques de gouvernance et de gestion des données appropriées à la finalité visée ». L'application commence le 2 août 2026. L'exigence pratique n'est pas un document de politique de gouvernance. Il s'agit d'une preuve vérifiable et horodatée attestant que la gouvernance a été appliquée au moment où les données sont entrées dans le pipeline.

L'écart est bien réel : seulement 3 % des institutions financières ont déployé efficacement l'IA en production (rapport Ataccama 2025 sur la confiance dans les données). Les politiques de gouvernance existent, mais les preuves d'adhésion au niveau du pipeline font défaut.

Notre approche fait de la conformité à l'article 10 une capacité intégrée au pipeline. Chaque exécution est conçue pour produire un registre de traçabilité consignant : les sources de données avec leurs métadonnées d'origine, les résultats de validation de la qualité, les paramètres de transformation, la méthodologie d'échantillonnage, les propriétés statistiques du jeu de données (représentativité, complétude, taux d'erreur) et les politiques de gouvernance actives. C'est le livrable qu'examine un auditeur — généré automatiquement et non reconstitué a posteriori.

Pour les organisations également soumises à l' article 30 du RGPD (registre des activités de traitement), le système de traçabilité est conçu pour produire les deux livrables de conformité à partir d'une seule couche d'instrumentation. Les exigences se recoupent sans être identiques : l'article 30 se concentre sur les finalités du traitement et les bases juridiques, tandis que l'article 10 met l'accent sur la qualité et la représentativité des données. Un système unifié élimine les doublons qui pénalisent les organisations gérant des filières de conformité distinctes.

Attribution des données d'entraînement et détection de l'empoisonnement

Les régulateurs commencent à demander quels exemples d'entraînement ont influencé une prédiction spécifique. Les fonctions d'influence, cadre mathématique adapté à cette fin, ont historiquement été trop coûteuses pour la production. Les avancées récentes — la projection de gradient LoGra et l' algorithme ASTRA — portent le calcul d'influence à une échelle opérationnelle. Notre approche implémente l'attribution comme une capacité criminalistique : des scores d'influence précalculés pour les comportements critiques du modèle, mis en cache pour être consultés lorsqu'un auditeur ou un juriste a besoin du lien entre une sortie spécifique et les données qui la sous-tendent.

La traçabilité sert également de défense principale contre l'empoisonnement des données d'entraînement (nos recherches sur la protection des modèles d'entreprise contre l'empoisonnement). Des recherches ont confirmé en 2025 que l'empoisonnement ne nécessite qu'un nombre constant d'échantillons quelle que soit la taille du modèle, et même 0,001 % de données contradictoires peut dégrader la précision de 30 %. Lorsque chaque élément de données dispose d'une chaîne de traçabilité vérifiée, les schémas de provenance anormaux deviennent détectables :

• Des données provenant de sources non vérifiées.
• Des enregistrements présentant des chaînes de hachage rompues.
• Des exemples contournant le pipeline d'ingestion standard.

En surplomb du graphe de traçabilité, l'approche ajoute des couches de détection conçues pour signaler ces schémas avant que les données contaminées n'atteignent l'entraînement du modèle.

Quand cet investissement s'impose

Vous avez besoin d'une infrastructure de traçabilité lorsque vos systèmes d'IA consomment des données comportant un risque juridique, réglementaire ou de sécurité :

• Entreprises de services financiers confrontées à l' article 10 de l'EU AI Act.
• Santé régie par la norme FDA 21 CFR Part 11.
• Entreprises exposées au RGPD s'entraînant sur les données des utilisateurs.
• Organisations dont l'approvisionnement en données d'entraînement fait l'objet d'un examen juridique.

Vous n'en avez pas besoin si votre IA ne consomme que des données internes non réglementées avec un pipeline simple. Si le graphe de lignage de dbt combiné à une instance DataHub couvre vos besoins, utilisez ces solutions — nous vous le dirons dès le premier échange.