IA générative : pouvez-vous retrouver d’où vient une donnée après son ingestion ?

Une entreprise collecte des millions de pages publiques pour alimenter un système d’intelligence artificielle.

Six mois plus tard, une personne lui demande quelles données la concernant ont été utilisées. L’équipe connaît le modèle, le dataset et le pipeline d’entraînement. Mais peut-elle encore répondre à une question beaucoup plus simple : d’où venait précisément cette donnée ?

Le problème du web scraping appliqué à l’IA générative n’est pas uniquement juridique. C’est également un problème de traçabilité des données.

En juillet 2026, le Comité européen de la protection des données (CEPD) a publié ses Guidelines 03/2026 sur le web scraping dans le contexte de l’IA générative. Au 21 septembre 2026, le texte est toujours ouvert aux commentaires, avec une consultation annoncée jusqu’au 30 octobre 2026.1

Il fournit l’occasion de regarder le scraping depuis l’architecture du système. Car entre une page web et un modèle, une donnée peut connaître une longue succession de transformations.

« Nous avons utilisé des données publiques » ne décrit pas un pipeline

Une organisation peut expliquer que son modèle a été entraîné à partir d’informations disponibles publiquement. Cette description reste très éloignée de la réalité technique.

Le parcours peut ressembler à :

source web → crawler → stockage brut → filtrage → nettoyage → déduplication → dataset → entraînement → modèle

Dans un système RAG, une autre chaîne peut exister :

source → collecte → transformation → embeddings → base vectorielle → recherche → prompt → modèle → réponse

À chaque étape, la donnée peut être transformée, copiée, enrichie ou combinée. Connaître le dataset final ne signifie donc pas nécessairement connaître son origine.

La provenance est une relation, pas seulement un champ

Ajouter une colonne source dans un dataset peut être utile. Mais une provenance exploitable doit parfois permettre de reconstruire plusieurs relations :

donnée → document source → URL → date de collecte → méthode de collecte → transformations → dataset → système utilisant le dataset

Une même information peut être présente dans plusieurs sources. Une page peut évoluer après sa collecte. Une donnée peut avoir été normalisée. Plusieurs documents peuvent être fusionnés. La provenance décrit donc l’histoire de la donnée dans le système.

Le web public n’est pas une zone sans RGPD

Le fait qu’une information soit accessible publiquement ne signifie pas qu’elle cesse automatiquement d’être une donnée personnelle. Les Guidelines 03/2026 examinent précisément l’application des principes du RGPD au scraping réalisé dans le contexte de l’IA générative.1

Le CEPD avait déjà consacré son Opinion 28/2024 à plusieurs questions liées aux données personnelles et aux modèles d’IA.2

Pour les équipes techniques, il ne suffit donc pas de se demander « Avions-nous le droit de collecter cette source ? » Il faut aussi pouvoir comprendre « Qu’est devenue l’information après sa collecte ? »

Cartographier le pipeline de données

Une représentation utile commence avant le modèle :

source → collecte → stockage brut → transformation → dataset → modèle → application → usage

Pour chaque étape, plusieurs attributs peuvent être associés : nature des données, finalité, responsable, système concerné, localisation, durée de conservation, transformation appliquée et systèmes en aval.

Cette représentation permet de répondre à une question fondamentale : si une donnée pose problème à la source, où faut-il intervenir dans le système ?

Le cas d’une demande individuelle

Prenons une entreprise qui collecte des profils professionnels publics, des sites d’entreprises et des forums afin de constituer un corpus utilisé par un assistant spécialisé.

Une personne découvre que certaines informations la concernant semblent apparaître dans le service. L’équipe doit alors investiguer : la donnée apparaît-elle dans les sources collectées ? La source brute existe-t-elle toujours ? Dans quels datasets transformés l’information a-t-elle été intégrée ? Ces datasets ont-ils servi à un entraînement, un fine-tuning, une indexation ou un système RAG ? Quelles applications utilisent encore ces artefacts ?

Sans traçabilité, chacune de ces questions devient une investigation distincte.

Le dataset n’est qu’un nœud du système

Plusieurs versions peuvent exister :

raw dataset → cleaned dataset → filtered dataset → training dataset → evaluation dataset

À cela peuvent s’ajouter snapshots, sauvegardes, caches, index, embeddings, exports et copies utilisées par des prestataires. Une information supprimée du dataset principal peut donc continuer à exister ailleurs.

RAG et entraînement posent des problèmes de traçabilité différents

Dans un système RAG, les documents ou leurs représentations restent généralement associés à un mécanisme de récupération. Il peut donc être possible de relier une réponse à certains documents récupérés.

Dans un modèle entraîné ou ajusté à partir d’un corpus, la relation entre une information source et le comportement du modèle devient beaucoup moins directe.

La question n’est donc pas seulement « Quel modèle utilisons-nous ? », mais également « Comment les données sont-elles injectées dans ce système ? »

La provenance doit survivre aux transformations

Une architecture de traçabilité utile ne nécessite pas de conserver toutes les données indéfiniment. Elle nécessite de réfléchir à ce qui doit permettre de reconstruire l’origine et le parcours d’une information pendant la durée pertinente.

Cela peut passer par des identifiants de lots, métadonnées de collecte, versions de datasets, journaux de pipeline ou relations entre artefacts.

Le principe est simple : une transformation ne devrait pas nécessairement casser la chaîne de provenance.

La provenance aide aussi la cybersécurité

Supposons qu’une source collectée soit découverte comme compromise, qu’un dataset ait été empoisonné ou qu’un fournisseur de données annonce une erreur.

La question devient immédiatement : quels systèmes ont été contaminés par cette donnée ?

Une cartographie de provenance permet alors une analyse d’impact :

source compromise → datasets concernés → modèles/index concernés → applications concernées → utilisateurs exposés

AI-BOM et provenance répondent à deux questions différentes

Un AI-BOM cherche notamment à identifier modèles, bibliothèques, services et applications. La provenance répond à d’autres questions : d’où viennent les informations ? Comment ont-elles été transformées ? Dans quels artefacts ont-elles été incorporées ? Où sont-elles utilisées aujourd’hui ?

AI-BOM : de quoi mon système IA dépend-il ?

Data lineage : d’où viennent les données qui l’alimentent et où sont-elles allées ?

Sept relations à pouvoir reconstruire

1. Source → collecte : savons-nous quelles sources ont alimenté chaque lot ?
2. Collecte → données brutes : pouvons-nous identifier les données réellement récupérées ?
3. Données brutes → transformation : savons-nous quels filtres et traitements ont été appliqués ?
4. Transformation → dataset : pouvons-nous identifier les versions produites ?
5. Dataset → modèle ou index : savons-nous quels artefacts IA ont utilisé quelles versions ?
6. Modèle ou index → application : pouvons-nous identifier les services exposant ces artefacts ?
7. Modification en amont → impact en aval : savons-nous quels composants examiner ?

Si plusieurs de ces relations sont impossibles à reconstruire, l’organisation connaît probablement son architecture IA mieux que l’histoire des données qui la traversent.

Cartographier avant d’avoir besoin de remonter la chaîne

Le web scraping à destination de l’IA générative pose des questions juridiques complexes, que les Guidelines 03/2026 du CEPD cherchent précisément à encadrer.

Mais la conformité dépend aussi de capacités très concrètes. Une organisation ne peut examiner correctement l’origine et les usages d’une donnée que si elle sait où cette donnée est passée.

Le problème apparaît rarement le jour de la collecte. Il apparaît plusieurs mois plus tard, lorsqu’il faut reconstruire le chemin.

La bonne question à poser au moment de concevoir le pipeline est donc peut-être : « Si nous devions retrouver cette donnée dans un an, saurions-nous remonter jusqu’à sa source ? »