Le scraping web selon l'EDPB place le RGPD au cœur des données d'entraînement des IA

Sophie Laurent Responsable Juridique & Conformité, YuSMP Group · Conseille les équipes américaines et européennes sur le RGPD, le règlement européen sur l'IA et les flux de données transfrontaliers

La réponse courte

Qu'a réellement publié l'EDPB ?

L'EDPB — l'organe qui coordonne les autorités nationales de protection des données de l'UE — a adopté les lignes directrices 03/2026 sur le scraping web dans le contexte de l'IA générative lors de sa plénière de juillet 2026 à Bruxelles, en publiant la version 1.0 pour consultation publique. C'est la première fois que le Comité traite, dans un seul document, la pratique au cœur de l'IA moderne : extraire des données personnelles d'Internet ouvert pour entraîner de grands modèles de langage et d'autres systèmes génératifs.

Le constat central est trompeusement simple. Le RGPD s'applique dès que le scraping web implique des opérations de traitement de données personnelles — « collecte, stockage, organisation et extraction » — et il n'existe aucune exemption spéciale au motif que la finalité serait l'entraînement d'IA. Pendant des années, certains laboratoires ont traité le web ouvert comme une matière première en libre-service. Les lignes directrices ferment cette porte : si les pages que vous scrapez contiennent des données personnelles de personnes situées dans l'UE, chacune de ces étapes de traitement est réglementée, que vous soyez de la taille d'OpenAI ou une jeune pousse affinant un modèle ouvert sur un corpus de domaine.

Cela n'est pas arrivé dans le vide. Les autorités italienne, irlandaise, néerlandaise et française avaient déjà pris des mesures d'exécution contre des entreprises d'IA — sanctionnant des fournisseurs, empêchant un chatbot de s'entraîner sur des publications de l'UE, et poursuivant de plus petits développeurs pour scraping sans base légale — mais chacune agissait selon sa propre lecture de la loi. Les lignes directrices 03/2026 remettent aux 27 régulateurs nationaux un corpus de règles unique, ce qui explique précisément leur importance pour les équipes qui conçoivent ou commanditent des produits IA et data : la norme est désormais cohérente dans toute l'Union.

Pourquoi le consentement ne fonctionne-t-il pas pour le scraping ?

La clarification la plus lourde de conséquences porte sur la base légale. En vertu du RGPD, tout traitement de données personnelles requiert l'une des six bases légales, et pour le scraping les deux candidates sont le consentement et l'intérêt légitime. L'EDPB affirme sans détour que le consentement « ne servira très probablement pas de base légale exploitable pour le scraping ». Le raisonnement est pratique : un responsable de traitement qui scrape des millions de pages n'a aucune relation directe avec les individus derrière ces données, et ne peut raisonnablement obtenir de chacun un consentement valide, éclairé et libre.

Le Comité écarte également un raccourci commode. Comme il l'énonce, « une personne qui rend ses données disponibles sur une page web librement accessible n'a pas pour autant consenti à ce que ces données soient scrapées à une fin spécifique telle que l'entraînement d'une IA ». La visibilité publique n'est pas une autorisation. Cette seule phrase démonte la justification informelle sur laquelle reposaient beaucoup des premiers jeux de données — « c'était sur le web ouvert, donc c'était de bonne guerre » — et elle s'applique aussi bien à un laboratoire de pointe qu'à une équipe assemblant un corpus de recherche à partir de pages scrapées.

Le consentement étant de fait écarté pour le scraping à grande échelle, l'intérêt légitime devient la base réaliste. Mais ce n'est pas un blanc-seing — il s'accompagne d'un test que vous devez réussir et documenter.

L'intérêt légitime et son test en trois volets

Les lignes directrices présentent l'intérêt légitime comme un test à trois conditions, et les trois doivent être réunies. Premièrement, il doit exister un intérêt légitime poursuivi par le responsable de traitement ou un tiers — l'EDPB donne des exemples tels que développer des agents conversationnels, détecter des contenus frauduleux ou améliorer la détection des menaces. Deuxièmement, le traitement doit être nécessaire pour atteindre cet intérêt, c'est-à-dire que vous ne pouvez pas atteindre le même objectif avec moins de données personnelles. Troisièmement, un test de mise en balance doit confirmer que les droits et libertés des personnes concernées ne prévalent pas sur l'intérêt du responsable.

Pour les équipes d'ingénierie et produit, le mot opérationnel est documenté. Une évaluation de l'intérêt légitime (LIA) n'est pas quelque chose que l'on reconstitue après une plainte ; elle doit exister avant que le scraping ne commence, et elle doit montrer votre raisonnement — quel intérêt, pourquoi ces données, quelles alternatives avez-vous écartées, quelles garanties avez-vous ajoutées, et comment la balance penche en faveur de la poursuite. La nécessité, en particulier, pousse à la minimisation des données : collecter de façon ciblée pour une finalité définie est plus facile à défendre que d'aspirer tout « au cas où ça servirait plus tard », ce qui constitue aussi un signal d'alerte au regard du principe de limitation des finalités que les lignes directrices soulignent.

La transparence l'accompagne. Le Comité reconnaît qu'informer individuellement chaque personne scrapée peut être impossible ou exiger un effort disproportionné — mais lorsque cette exemption s'applique, une notice de confidentialité accessible au public est décrite comme une mesure que le responsable « doit toujours prendre », exposant les catégories de données, la base légale et les sources. Autrement dit, l'exemption d'information individuelle n'est pas une exemption de transparence.

Qu'en est-il des données de santé et financières ?

Le scraping à grande échelle ramasse inévitablement du matériel sensible, et ici les lignes directrices sont strictes. Les catégories particulières de données — y compris les données de santé et celles révélant d'autres attributs protégés — sont en principe interdites de traitement au titre de l'article 9, et lever cette interdiction requiert à la fois une base légale au titre de l'article 6 et une exception spécifique de l'article 9(2). Pour le scraping du web ouvert, peu de ces exceptions s'appliquent réellement, ce qui rend la collecte indiscriminée de données sensibles très difficile à justifier.

S'appuyant sur le raisonnement de la Cour de justice dans l'affaire GC et autres (C‑136/17), l'EDPB admet qu'une certaine collecte incidente ou résiduelle de données à caractère particulier peut être tolérée lorsqu'un responsable ne peut réellement pas la détecter à l'avance — mais uniquement si des garanties appropriées sont en place et que les données sont supprimées une fois identifiées. En pratique, l'obligation est un travail d'ingénierie : des classificateurs et des filtres qui écartent les contenus sensibles d'un jeu d'entraînement, plus une voie de suppression pour tout ce qui passe entre les mailles. Pour des domaines réglementés comme la HealthTech et la FinTech, « c'était disponible publiquement » est loin d'être une défense — la présomption joue en sens inverse, et l'on attend de vous que vous teniez activement ces données à l'écart.

Pourquoi « effacez mes données » ne marche plus après l'entraînement

Le point le plus significatif sur le plan technique, pour ceux qui construisent, concerne l'effacement. L'EDPB observe qu'une fois un modèle entraîné, les données personnelles ne peuvent pas en être aisément supprimées. Les poids ne sont pas une ligne de base de données que l'on peut effacer ; l'information d'une personne, une fois apprise, est diffuse à travers les paramètres d'une manière qui résiste à toute suppression ciblée. Cela entre de plein fouet en collision avec des droits du RGPD comme l'effacement et la rectification, qui supposent que les données puissent être localisées et traitées après coup.

La conséquence en matière de conformité est incontournable : vous ne pouvez pas corriger un problème de données d'entraînement une fois le modèle livré, donc la gouvernance doit remonter en amont. Curer, minimiser et documenter le jeu de données avant l'entraînement, car les alternatives — réentraîner à partir d'un corpus propre, ou défendre un modèle que l'on ne peut pas remédier proprement — sont coûteuses et lentes. C'est là que la conformité cesse d'être une formalité juridique pour devenir une décision d'architecture, et elle rejoint directement les obligations de gestion des risques et de documentation auxquelles les équipes font déjà face au titre du règlement européen sur l'IA. Les deux régimes convergent vers la même exigence : savoir ce qui est entré dans votre modèle, et pouvoir le prouver.

Ce que cela signifie pour les équipes logicielles US & UE

Ôtez le détail juridique et il reste trois signaux pratiques. Premièrement, le champ d'application est large et extraterritorial : si vous concevez ou commanditez de l'IA générative qui touche les données personnelles de personnes situées dans l'UE — y compris des entreprises américaines desservant des utilisateurs de l'UE — ces attentes vous concernent, où que se trouvent vos serveurs. « Nous l'avons scrapé aux États-Unis » ne place pas un jeu de données à destination de l'UE hors du RGPD.

Deuxièmement, le travail est désormais amont et documentaire. Avant un entraînement ou un fine-tuning, il vous faut une base légale consignée (en pratique, une évaluation de l'intérêt légitime), une justification de minimisation des données, une notice de transparence publique, et des filtres qui écartent les catégories particulières de données avec une voie de suppression pour ce qui passe au travers. Rien de tout cela n'est exotique — c'est la même discipline « connaissez vos données » que valorise déjà une bonne ingénierie IA et data — mais elle doit désormais être prouvée, non présumée. Les équipes qui traitent un corpus scrapé comme une boîte noire peineront ; celles qui peuvent produire une traçabilité du jeu de données, non.

Troisièmement, c'est le sens de l'histoire, même si ce n'est qu'un projet. La consultation court jusqu'au 30 octobre 2026 et la formulation peut évoluer, mais les positions centrales — le RGPD s'applique, le consentement fonctionne rarement, l'intérêt légitime exige un test, les données sensibles sont quasi interdites, on ne peut pas « désentraîner » un modèle — sont cohérentes avec la façon dont les régulateurs européens agissent déjà. Le mouvement pragmatique consiste à s'y préparer dès maintenant plutôt qu'à attendre le texte final, pour qu'une « règle future » ne devienne pas un obstacle au lancement. Rattachez le jeu de données à une base défendable, conservez la traçabilité, et faites de la conformité une donnée d'entrée de la conception plutôt qu'une surprise d'audit — le même principe que nous appliquons à nos missions de fine-tuning de LLM.

Une check-list de conformité concrète

Rien ici n'est une nouvelle échéance légale. C'est le travail qui transforme un paysage IA-données en mouvement rapide en une revue de routine plutôt qu'en surprise à l'audit :

1. Choisissez et documentez une base légale. Pour les données scrapées, menez et consignez une évaluation de l'intérêt légitime — intérêt, nécessité, mise en balance — avant le début de la collecte. Ne comptez pas sur le consentement.
2. Minimisez à la source. Collectez de façon ciblée pour une finalité définie ; le scraping large « au cas où » échoue aux tests de nécessité et de limitation des finalités.
3. Filtrez les catégories particulières de données. Ajoutez des classificateurs pour écarter les contenus de santé, financiers et autres contenus sensibles, plus une voie de suppression pour tout ce qui est détecté plus tard.
4. Publiez une notice de transparence. Lorsque l'information individuelle est impraticable, une notice de confidentialité publique listant les catégories de données, la base légale et les sources reste obligatoire.
5. Consignez la traçabilité du jeu de données. Suivez ce qui a été collecté, d'où, quand et sous quelle base — horodatages et validation compris — afin de répondre à un auditeur sans avoir à tout reconstituer.
6. Gouvernez avant d'entraîner. Partez du principe que vous ne pourrez pas effacer une personne d'un modèle entraîné ; constituez correctement le corpus en amont et conservez la capacité de réentraîner à partir d'un jeu de données propre et documenté.

Ceci n'est pas un conseil juridique, et la bonne approche dépend de vos données, de vos marchés et de votre modèle. Mais le signal des lignes directrices 03/2026 est clair : l'ère du scraping du web ouvert comme entrée non réglementée touche à sa fin en Europe, et les équipes qui avanceront le plus vite sont celles qui rendent leurs données d'entraînement défendables dès la conception.

Questions fréquentes

Sources

EDPB — EDPB sheds light on anonymisation and web scraping for generative AI (July 2026)
EDPB — Guidelines 03/2026 on web scraping in the context of generative AI (public consultation to 30 October 2026)
PPC Land — EDPB blocks AI firms from using consent as an excuse to scrape