Le web scraping et l’IA générative ont désormais leurs lignes directrices européennes. Le 7 juillet 2026, le Comité européen de la protection des données (CEPD) a adopté les lignes directrices 03/2026 sur le web scraping dans le contexte de l’IA générative. Le texte est soumis à consultation publique jusqu’au 30 octobre 2026.
Le CEPD n’interdit pas le scraping. Il rappelle toutefois une règle simple : dès que la collecte, l’extraction, le nettoyage ou le stockage portent sur des informations qui identifient une personne, directement ou indirectement, le RGPD s’applique.
Beaucoup d’équipes raisonnent encore ainsi : « les données étaient accessibles sur Internet, nous pouvions donc les utiliser ». Or cette phrase décrit seulement l’accès aux données. Elle ne démontre ni la licéité de leur réutilisation, ni leur nécessité pour le projet, ni la maîtrise du dataset obtenu.
Le RGPD s’applique au scraping de données dès la collecte
Concrètement, le web scraping consiste à extraire et conserver, avec des outils automatisés, des informations publiées en ligne. Réseaux sociaux, forums, blogs, sites d’actualité, registres publics, annuaires ou sites personnels contiennent des noms, des photos, des coordonnées et des opinions.
Le RGPD s’applique dès que le traitement porte sur des données personnelles, même mélangées à des données non personnelles dans un même dataset. Son application commence donc bien avant l’entraînement du modèle : extraction, nettoyage, structuration, stockage et réutilisation du jeu de données entrent dans le champ.
Les lignes directrices visent également l’organisation qui récupère un jeu de données déjà scrapé pour entraîner ou affiner un modèle. De plus, confier la collecte à un prestataire ne fait pas disparaître ces obligations.
Web scraping et IA : une donnée publique n’est pas une donnée libre
Le caractère public d’une donnée ne la rend pas réutilisable pour toute finalité. Par exemple, une personne publie un message pour participer à une discussion ou présenter son activité. Elle n’accepte pas pour autant son extraction à grande échelle, son regroupement avec d’autres sources et son usage pour entraîner un modèle.
Le contexte de publication compte donc. Le CEPD demande de tenir compte de la nature du site et de l’accessibilité réelle du contenu. Il cite aussi les restrictions de la plateforme, la nature des données, la situation des personnes et leur relation éventuelle avec le responsable du traitement.
| Source | Lecture recommandée |
|---|---|
| Blog ouvert | Analyse possible selon la finalité, la nécessité et les attentes raisonnables des auteurs. |
| Réseau social | Risque renforcé lorsque le contenu n’est visible qu’après connexion. |
| Espace fermé | Exclusion par principe : groupe privé, contenu protégé par un CAPTCHA ou une authentification. |
| Site pour mineurs | Exclusion par défaut. |
| Forum de santé | Source qui contient par nature des données sensibles : exclusion ou analyse renforcée. |
| Site opposé | Restriction posée par robots.txt ou les conditions d’utilisation, à intégrer dans la décision. |
| Dataset opaque | Usage suspendu tant que la provenance n’est pas démontrée. |
Publier en ligne ne vaut pas consentement
La publication d’un contenu sur Internet ne vaut pas consentement à son usage pour entraîner une IA. Au sens du RGPD, le consentement est libre, spécifique, éclairé et univoque. Ainsi, une publication faite pour une autre raison ne remplit aucune de ces conditions.
De même, l’absence de fichier robots.txt ne constitue ni un consentement ni une base légale. Autrement dit, « le site ne bloquait pas notre robot » ne démontre rien.
Les restrictions techniques à documenter
Les fichiers robots.txt et ai.txt, les CAPTCHA ou l’authentification ne sont pas des bases légales. Ils révèlent en revanche l’opposition d’un site à la collecte automatisée. Intégrez-les donc dans l’analyse des attentes raisonnables.
Pour chaque source, conservez l’adresse, la date du contrôle, les restrictions constatées, les conditions d’utilisation lues et la décision prise, avec sa justification. Refaites ce contrôle régulièrement, car les sites changent leurs règles.
Scraping de données : minimiser avant de collecter
Le scraping ciblé repose sur des critères fixés à l’avance : domaines, langue, sujet, période, type de page. L’organisation connaît alors le périmètre de son traitement.
Le crawling non ciblé suit au contraire les liens de page en page. Quelques adresses de départ mènent vite à un ensemble beaucoup plus vaste. Bientôt, l’organisation ne sait plus quels sites son robot a visités, ni quelles données il a extraites. Les paramètres du robot relèvent donc de la conformité : domaines autorisés, exclusions, profondeur, fréquence, métadonnées conservées et critères d’arrêt.
C’est pourquoi collecter largement puis nettoyer ne suffit pas. Le principe de minimisation exige des données adéquates, pertinentes et limitées à la finalité, dès la collecte. Avant le lancement, excluez les sites destinés aux mineurs et les sources qui contiennent par nature des données sensibles. Pendant la collecte, filtrez les adresses électroniques et les numéros de téléphone, fixez des limites de volume et journalisez les adresses parcourues. Ensuite, supprimez, dédupliquez, pseudonymisez, et anonymisez seulement si c’est réellement possible.
En pratique, un filtre appliqué après coup ne répare pas une collecte qui n’aurait pas dû avoir lieu.
Les données sensibles dans un projet de web scraping et d’IA
Un robot peut ramasser des données de santé, des opinions politiques, des convictions religieuses, une orientation sexuelle ou des données sur des mineurs. Pour ces catégories particulières, une base légale de l’article 6 ne suffit pas. Il faut en plus une condition de l’article 9, paragraphe 2.
La difficulté tient au calendrier : l’organisation découvre souvent ces données après leur extraction, alors que le traitement a déjà commencé. Le CEPD admet une appréciation particulière lorsque la collecte de données sensibles est incidente ou résiduelle. Il pose toutefois une condition, tirée de l’arrêt C-136/17 de la Cour de justice. Le responsable agit dans le cadre de ses responsabilités, de ses compétences et de ses possibilités, avec des mesures techniques et organisationnelles appropriées.
Pour autant, cette souplesse n’est pas une exemption générale. Dire que des données sensibles sont arrivées « par accident » ne vaut rien si aucun filtre n’était prévu. Les forums de patients, groupes de soutien, réseaux militants ou sites religieux se traitent donc avant la collecte.
Prestataires de scraping de données et datasets achetés
Le prestataire de scraping est sous-traitant lorsqu’il collecte selon vos instructions précises : sources, catégories, critères, finalité et conservation. En revanche, il devient responsable autonome s’il choisit lui-même ses sources et constitue un dataset pour le vendre. Enfin, une responsabilité conjointe existe lorsque les acteurs décident ensemble des finalités et des moyens essentiels. Le contrat ne tranche pas seul : le fonctionnement réel prime.
De même, acheter un dataset ne revient pas à acheter sa conformité. Une attestation « conforme au RGPD » ne suffit pas. Obtenez du fournisseur l’origine des données, les catégories de sources, les périodes de collecte, les exclusions, le traitement des données sensibles et les opérations de nettoyage. Demandez ensuite les modalités d’exercice des droits, les durées de conservation et un droit d’audit.
Un fournisseur qui refuse toute explication vous signale ainsi le niveau de risque. En effet, l’organisation qui réutilise le dataset reste responsable de son propre traitement. Pour les chaînes de prestataires, notre analyse de la sous-traitance en cascade donne la méthode de contrôle.
Base légale, information des personnes et chaîne de preuve
L’intérêt légitime se démontre
L’intérêt légitime peut fonder un scraping. Il n’est pas automatique. « Développer une IA » reste trop vague : précisez l’objectif, par exemple un assistant spécialisé, la détection de fraude ou l’adaptation d’un modèle à un secteur. Démontrez ensuite la nécessité de la collecte, faute de solution aussi efficace et moins intrusive.
La mise en balance tient compte de la nature et du volume des données, du nombre de personnes, de la présence de mineurs et des difficultés d’exercice des droits. Elle intègre aussi les risques de profilage, de mémorisation, de restitution et de réidentification. Certes, les mesures d’atténuation réduisent le risque. Elles ne rendent pas pour autant licite un traitement disproportionné. Sur ce point, voir aussi notre article sur l’intérêt légitime et le droit d’opposition en IA.
Informer les personnes, même sans les contacter
Les données ne viennent pas des personnes elles-mêmes : l’article 14 du RGPD s’applique donc en principe. Pour un scraping massif, l’information individuelle peut se révéler impossible ou exiger des efforts disproportionnés. Toutefois, cette exception se justifie au cas par cas.
Sans information individuelle, publiez donc une information accessible. Elle précise les finalités, la base légale, les catégories de données et de sources, les caractéristiques du robot, la période de collecte et la manière de s’opposer. Par exemple, la formule « nous pouvons utiliser des données publiques pour améliorer nos services » reste trop générale.
La chaîne de preuve à conserver
Une politique de confidentialité, un contrat ou la garantie d’un fournisseur ne suffisent pas. L’organisation doit donc reconstituer la chaîne complète, de la source jusqu’à la version du modèle.
| Élément | Preuve à conserver |
|---|---|
| Finalité | Note de cadrage du projet. |
| Sources | Domaines, adresses et catégories de sites, avec la décision d’inclusion ou d’exclusion. |
| Restrictions | Journal des contrôles de robots.txt, ai.txt, CAPTCHA et conditions d’utilisation, daté. |
| Paramètres | Configuration du robot : profondeur, fréquence, exclusions, critères d’arrêt. |
| Nettoyage | Règles appliquées et rapport de filtrage. |
| Dataset | Identifiant, date et version. |
| Modèle | Version du modèle et date d’entraînement, rattachées au dataset. |
| Prestataire | Contrat, instructions et contrôles réalisés. |
| Droits | Procédure d’opposition, d’accès et d’effacement. |
Au final, un dataset sans version ni provenance exploitable rend la conformité très difficile à démontrer.
Web scraping et IA : le plan d’action du DPO
Le DPO ne configure pas le robot et ne décide pas seul de la stratégie du modèle. Il pilote en revanche la démonstration de conformité, avec les équipes data, la DSI, le RSSI, le service juridique et les achats. Nous recommandons cet ordre de travail :
- Recensez les projets qui utilisent des données scrapées, des datasets achetés ou du fine-tuning.
- Identifiez qui choisit les sources, collecte, nettoie, entraîne et répond aux personnes.
- Tenez un registre des sources avec les restrictions constatées et les décisions d’inclusion ou d’exclusion.
- Revoyez les paramètres du robot et les exclusions : mineurs, données sensibles, espaces fermés, sites opposés.
- Documentez la base légale, la nécessité, la mise en balance et, si ses conditions sont réunies, l’analyse d’impact (AIPD).
- Versionnez les datasets et testez le modèle : mémorisation, restitution exacte, réidentification.
La consultation publique reste ouverte jusqu’au 30 octobre 2026. Vos projets d’IA tournent pourtant déjà : commencez donc par le registre des sources.
Sources
Le CEPD publie le texte soumis à consultation : Guidelines 03/2026 on web scraping in the context of generative AI.
Son communiqué présente l’adoption : EDPB sheds light on anonymisation and web scraping for generative AI and adopts final version of guidelines on blockchain.
La CNIL en propose une version française : Le CEPD met en lumière l’anonymisation et le moissonnage pour l’IA générative et adopte la version finale des lignes directrices sur la chaîne de blocs.
