← Tous les articles

Lignes directrices de l'EDPB sur le web scraping : les scrapers ciblés gagnent

Le projet de lignes directrices de l'EDPB sur le web scraping cible l'entraînement de l'IA, mais il avantage tout scraper capable de démontrer ce qu'il a collecté, depuis quels sites et à quelle date.

L'EDPB vient de rédiger une spécification pour les scrapers

Les autorités européennes de protection des données se sont largement exprimées sur les modèles d'IA. Jusqu'à cet été, rien n'indiquait concrètement à un ingénieur ce qu'un scraper doit faire avant de récupérer sa première page.

Les Lignes directrices 03/2026 sur le web scraping dans le cadre de l'IA générative ont changé la donne. L'European Data Protection Board a adopté le projet le 7 juillet 2026, et sa consultation publique se termine le 30 octobre 2026. Sur le papier, le périmètre est restreint: les entreprises privées qui scrapent des données personnelles pour entraîner ou affiner des modèles d'IA générative. En pratique, il s'agit de la description la plus détaillée jamais publiée par un régulateur sur la façon de concevoir un job de scraping défendable, depuis les critères définis avant la première requête jusqu'au timestamp du dernier enregistrement.

Notre analyse, après lecture intégrale des 23 pages: le projet ne se préoccupe pas des outils utilisés. Il s'intéresse à votre capacité à déclarer ce que vous avez collecté, depuis quelle source et à quel moment. Les scrapers capables de répondre à cela en une seule requête s'en sortiront sans problème. Les crawls ouverts sans cible précise se heurteront à presque chaque paragraphe.

(Avertissement: ceci ne constitue pas un conseil juridique. D'une part, nous nous basons sur un projet de texte, et d'autre part, nous sommes des ingénieurs qui l'analysent sous l'angle du code.)

Ciblé ou non ciblé, la distinction essentielle

Le paragraphe 8 divise le scraping en deux catégories selon le niveau de précision et de restriction de la collecte, "et non selon les outils techniques utilisés". Le scraping ciblé repose sur des critères de collecte: un domaine, une langue, une thématique. Le scraping non ciblé désigne un crawler qui suit chaque lien rencontré. L'inquiétude du régulateur est claire: à mesure que la file d'attente s'allonge, le responsable de traitement "a une connaissance limitée des données à caractère personnel collectées et traitées."

Cette distinction traverse tout le document. La minimisation des données exige de "définir des critères précis de collecte" et de mener un "processus de cartographie et d'inventaire des données" avant le début de la collecte (paragraphe 37). Le test de nécessité lié à l'intérêt légitime précise que restreindre les critères, "plutôt que de scraper une large partie d'Internet", peut être précisément ce qui rend le traitement nécessaire (paragraphe 52). La transparence impose de publier une liste des sources, idéalement avec les noms de domaine, les URL et les dates de collecte (paragraphes 30 et 31).

Un comparateur de prix s'appuyant sur une liste fixe de pages produits réparties sur une douzaine de sites marchands peut générer chacun de ces éléments directement depuis son fichier de configuration. Un crawl en largeur en est incapable. La critique du projet par Privacy World résume bien cette contradiction: les obligations sont écrites pour un responsable de traitement qui sait ce qu'il collecte, juste après que l'EDPB a admis qu'un crawl non ciblé peut contenir des données personnelles impossibles à inventorier.

Ce que cela implique : si vous scrapez des donnees liees a des personnes physiques (avis avec noms d'utilisateurs, annonces avec nom et numero de telephone d'un agent, fils de discussion de forums), vos criteres de collecte deviennent un artefact de conformite. Conservez-les dans votre systeme de controle de version aux cotes du scraper, et non dans la memoire d'un collaborateur.

Le refus d'un site joue desormais contre vous

C'est la partie qui modifiera le plus les pipelines de donnees. Le projet liste les mesures techniques demontrant l'opposition claire d'un site au scraping : robots.txt, ai.txt, « robots authentication to view content », ainsi que les controles qui « imposent une action ne pouvant etre realisee que par un etre humain » (paragraphe 37). Pour les donnees d'entrainement, il recommande d'exclure ces sites.

Ces memes signaux interviennent dans la mise en balance des interets. Lorsque les utilisateurs savent qu'un site emploie ces mesures et que le site est malgre tout scrape, le document precise qu'ils s'attendent moins a ce traitement (paragraphe 64). L'exemple 5 l'illustre clairement : une plateforme combinant une exclusion par robots.txt, un controle reserve aux humains et une interdiction explicite pour l'entrainement de modeles d'IA signifie que ses utilisateurs « ne peuvent raisonnablement pas s'attendre » a ce que des tiers scrapent leurs donnees a cette fin. La reciproque n'est pas vraie. L'absence de robots.txt ne vaut pas consentement (paragraphe 45).

La CNIL francaise avait anticipe cette position. Sa fiche thematique sur l'interet legitime et le web scraping, publiee initialement en juin 2025, indique que le traitement « ne saurait relever des attentes raisonnables des personnes concernees » lorsque le responsable de traitement n'exclut pas les sites qui s'y opposent via robots.txt ou par un controle reserve aux humains.

Deux points moins evidents figurent parmi les mesures d'attenuation (paragraphe 66c). Le premier exclut les donnees personnelles accessibles uniquement apres connexion. Le second vise les sites retournant une reponse differente selon qu'il s'agisse de l'User-Agent d'un scraper ou d'un navigateur standard, « en particulier lorsque le service de scraping recoit plus de donnees » qu'un internaute lambda n'en verrait. Si votre scraper interroge une API interne fournissant des donnees plus riches que ce qu'affiche la page, vous etes directement vise.

Nous avons examine la dimension interpretable par les machines (extensions du robots.txt, agents signes, signaux de contenu) dans Search, Agent, Training: The Web's New Bot Rules, ainsi que le cas des editeurs preferant facturer plutot que refuser dans Pay-Per-Crawl Is Splitting the Web in Two. Ce projet du CEPD marque la premiere fois qu'un regulateur considere ces signaux comme des preuves des attentes raisonnables des personnes.

Ce que cela implique : enregistrez l'etat du fichier robots.txt (et du ai.txt, lorsqu'un site en propose un) par domaine au moment exact de la collecte, a cote des donnees. Si l'on vous demande dans un an pourquoi une source a integre un jeu de donnees d'entrainement, repondre que « c'etait autorise le jour de l'extraction » ne sera valable que si vous en avez conserve la preuve ecrite.

Le scraper peut avoir le statut de sous-traitant

La section 3.2.1 est courte et facile à ignorer. Elle ne devrait pas l'être, surtout si vous développez des scrapers pour des clients. Si vous créez un jeu de données d'entraînement pour le compte du développeur "conformément à ses instructions documentées", vous pouvez être considéré comme sous-traitant et le développeur comme responsable du traitement (paragraphe 18). Si vous et le client définissez ensemble les critères de collecte, vous pouvez être coresponsables du traitement (paragraphe 20, exemple 1). Si vous avez scrapé un jeu de données de votre propre initiative et qu'un tiers le réutilise, chacun de vous répond de ses propres traitements (paragraphe 19).

La tribune de Brian Hengesbaugh pour l'IAPP sur le projet soulève le point commercial. Lorsqu'un contrat désigne le prestataire comme sous-traitant, le client assume le travail de conformité décrit par les lignes directrices, et les obligations directes du prestataire "pourraient être plus limitées et moins sécurisantes qu'on ne le pensait". Cela fonctionne dans les deux sens. Un client ne peut pas déléguer la conformité au freelance qui a écrit le scraper, et un freelance qui improvise la liste des sources peut devenir responsable du traitement par inadvertance.

Ce que les équipes data doivent changer dès maintenant

La majorité du scraping commercial n'est pas concernée. Les prix, les niveaux de stock, les spécifications techniques de produits et les horaires ne sont généralement pas des données personnelles, le RGPD ne s'applique donc pas à eux. Le projet précise explicitement que dans un jeu de données "mixte", il s'applique à la partie personnelle (paragraphe 13). Ainsi, une annonce comportant le nom d'un vendeur, ou un avis comportant un nom d'utilisateur, fait entrer cette composante dans le champ d'application.

Pour les tâches qui collectent effectivement des données sur les personnes, voici comment les exigences du projet se traduisent dans un pipeline:

Exigence du projet Dans votre pipeline
Critères de collecte Motifs d'URL par tâche
Filtrage basé sur la syntaxe Suppression par regex au parsing
Enregistrements horodatés fetched_at sur chaque ligne
Liste des sources Domaines dans la configuration
Respect des opt-outs État robots.txt journalisé

Deux de ces lignes méritent plus qu'une cellule de tableau.

Filtrez au moment du parsing, pas dans une tâche de nettoyage plusieurs semaines plus tard. Le paragraphe 38 mentionne des expressions régulières pour des formats tels que les numéros de sécurité sociale et de téléphone, appliquées pendant la collecte. Les données que vous n'avez jamais stockées sont des données que vous n'avez jamais à justifier, et le paragraphe 60 est direct sur les raisons pour lesquelles cela importe pour l'IA: une fois qu'un modèle est entraîné, les données personnelles "ne peuvent pas être facilement supprimées" de celui-ci.

Conservez l'URL source et l'heure de récupération sur chaque enregistrement. Le paragraphe 42 demande des horodatages pour des raisons d'exactitude, mais ces deux mêmes champs permettent de répondre ultérieurement à toute question sur l'origine d'une information. Les règles relatives aux données d'entraînement se durcissaient déjà sous l'AI Act (nous avons écrit sur ce sujet en avril), et elles reviennent constamment à cette même question.

Si vous développez pour des clients, vous devez formaliser les instructions par écrit: sources, champs, exclusions. Le projet considère que les instructions documentées sont ce qui vous qualifie de sous-traitant plutôt que de coresponsable, et une spécification d'une page évite tout litige ultérieur sur les rôles.

Ce qui se passe après le 30 octobre

Le texte final évoluera, et le changement le plus important pourrait venir de Bruxelles plutôt que du Comité. Le 21 octobre 2026, le Conseil a arrêté sa position de négociation sur le paquet Omnibus numérique, qui modifierait le RGPD. Selon le rapport de l'IAPP sur ce mandat, les États membres ont ajouté des « clarifications sur la base légale du traitement des données à caractère personnel et la nécessité de maintenir des garanties appropriées » pour les données d'entraînement d'IA. Les négociations avec le Parlement européen suivront. Quelle que soit la formulation retenue, les États membres souhaitent maintenir ces garanties, ce qui laisse présager un test de mise en balance très proche de celui de ce projet.

Nous pensons que la distinction entre collecte ciblée et non ciblée survivra à ces deux processus, car c'est la seule partie du projet qui relève de l'ingénierie plutôt que du droit. Un régulateur ne lira pas le code de votre crawler. Il peut en revanche exiger vos critères de collecte, votre liste de sources et vos horodatages, et une équipe capable de les fournir dans l'après-midi même n'aura plus grand-chose à débattre.

Ainsi, la prochaine question qu'un régulateur de la protection des données posera à un scraper ne sera pas « comment il fonctionne », mais plutôt : « qu'avait-il pour consigne de collecter ? ».