Web scraping et IA générative : ce que le RGPD impose concrètement à votre PME
La plupart des PME françaises qui déploient des outils d'IA générative se concentrent sur la performance des modèles, la qualité des prompts, la fiabilité des intégrations. Ce qu'elles ne regardent pas, c'est la provenance des données qui alimentent ces outils. Or le RGPD ne distingue pas entre données collectées manuellement et données aspirées automatiquement depuis des sources externes. Dès lors que votre pipeline d'automatisation ingère des données personnelles, vous êtes responsable de traitement, avec toutes les obligations que cela implique. Ce n'est pas une interprétation conservatrice du texte. C'est la position consolidée des autorités de contrôle européennes, confirmée par plusieurs décisions récentes.
Ce que « alimenter un outil IA » signifie juridiquement pour votre organisation
Le périmètre du RGPD s'applique dès qu'une donnée à caractère personnel est traitée, quelle que soit la technique utilisée pour la collecter. Un scraper qui extrait des profils LinkedIn, des adresses email depuis des annuaires professionnels, ou des avis clients depuis des plateformes tierces, réalise un traitement de données au sens de l'article 4 du règlement. L'automatisation ne change pas la nature juridique de l'opération, elle en accélère simplement l'échelle.
Ce qui change avec l'IA générative, c'est que ces données ne servent plus seulement à alimenter un CRM ou un tableau de bord. Elles entrent dans des pipelines de fine-tuning, d'enrichissement de prompts, ou de construction de bases de connaissances vectorielles. Chaque étape de ce processus constitue un traitement distinct, potentiellement soumis à une base légale spécifique. On observe chez les PME qui démarrent ces projets une confusion fréquente : elles assimilent « données publiquement accessibles » à « données librement exploitables ». Ce n'est pas la même chose.
Pourquoi « la donnée est publique » n'est pas une base légale suffisante
C'est l'argument qu'on entend le plus souvent pour justifier une collecte par scraping. La donnée est sur un site public, donc elle est disponible. Cette logique est incorrecte au regard du RGPD. Une donnée accessible publiquement reste une donnée personnelle si elle permet d'identifier une personne physique, directement ou indirectement. Sa publicité ne crée pas de droit à la réutiliser pour n'importe quelle finalité.
La Cnil a précisé sa doctrine sur ce point : la base légale d'un traitement doit être établie indépendamment du canal de collecte. Pour un traitement à des fins commerciales ou d'entraînement de modèles, l'intérêt légitime (article 6.1.f) est la base invoquée par défaut. Mais elle nécessite une mise en balance formalisée entre vos intérêts et les droits des personnes concernées. Ce test de mise en balance, quasiment aucune PME ne le documente avant de lancer son projet.
La CJUE a par ailleurs rappelé dans plusieurs arrêts récents que la réutilisation de données collectées dans un contexte donné pour une finalité différente exige une compatibilité de finalité vérifiable. Alimenter un LLM avec des données scrapées à des fins d'enrichissement commercial ne va pas de soi, même si la source initiale était publique.
Les trois obligations concrètes que votre projet d'automatisation doit intégrer dès la phase de conception
Ces obligations ne sont pas des formalités administratives à cocher en fin de projet. Elles conditionnent la légalité du traitement et, donc, l'exploitabilité des outputs que vous allez produire.
- Cartographier les flux de données personnelles dès le début du projet : identifier quelles données entrent dans le pipeline, depuis quelle source, avec quelle finalité déclarée, et pendant combien de temps elles sont conservées.
- Établir la base légale pour chaque traitement distinct : collecte, stockage, enrichissement, inférence. Un seul projet peut en mobiliser trois ou quatre différentes.
- Réaliser une Analyse d'Impact relative à la Protection des Données (AIPD) si le traitement est susceptible d'engendrer un risque élevé pour les droits des personnes, ce qui est souvent le cas dès lors qu'on croise des données issues de sources multiples pour établir des profils.
Chez Lumivi, nous intégrons systématiquement cette cartographie en amont de tout projet d'automatisation impliquant des données externes. Non pas parce que c'est une obligation formelle, mais parce qu'un pipeline mal qualifié juridiquement produit des outputs que vous ne pouvez pas utiliser sans risque.
Ce que les autorités de contrôle ont déjà sanctionné, et ce que cela préfigure
La Cnil n'a pas attendu l'AI Act pour se positionner sur ces sujets. Dès 2022, elle a publié ses premières recommandations sur l'IA et la protection des données. En 2023 et 2024, plusieurs autorités européennes ont ouvert des enquêtes sur des acteurs qui utilisaient du scraping massif pour entraîner des modèles, dont des enquêtes coordonnées au niveau du Comité européen de la protection des données.
Les sanctions ne visent pas encore principalement les PME, mais la logique de diffusion réglementaire suit toujours le même schéma : les grandes entreprises essuient les premières décisions, les standards se fixent, puis les contrôles descendent en cascade vers les acteurs plus petits. On a vu ce mécanisme se déployer sur les cookies, sur le transfert de données vers les États-Unis, sur le droit à l'effacement. Il n'y a aucune raison que l'IA échappe à cette trajectoire.
Par ailleurs, l'AI Act introduit des exigences de transparence sur les données d'entraînement pour les modèles à usage général, avec des obligations qui commencent à s'appliquer en 2025. Si votre PME utilise ou adapte un modèle avec des données propriétaires issues de scraping, vous entrez dans un périmètre réglementaire qui croise RGPD et AI Act simultanément.
La vraie question que votre DSI doit poser avant de valider le prochain pipeline
Ce n'est pas « est-ce que notre scraper fonctionne ? » ni même « est-ce que la donnée est utile ? ». C'est : quel traitement de données personnelles ce pipeline réalise-t-il, sur quelle base légale, et comment en traçons-nous la conformité ?
Cette question doit être posée avant le développement, pas après le déploiement. Un pipeline construit sans réponse documentée à ces trois points est un actif à risque, pas un actif opérationnel. Les DSI qui l'intègrent dans leur processus de validation projets ne ralentissent pas les déploiements, ils évitent des reprises coûteuses et des expositions réglementaires que personne ne voit venir jusqu'au contrôle.
Nous accompagnons régulièrement des PME qui découvrent en phase de validation qu'un outil déjà déployé depuis plusieurs mois traite des données personnelles sans base légale établie. Le coût de mise en conformité a posteriori est systématiquement supérieur à celui d'une intégration dès la conception, sans même compter le risque de devoir interrompre un service qui a déjà été intégré dans les processus opérationnels.
Ce que cela change pour votre roadmap IA en 2025
La conformité RGPD sur les projets IA n'est pas un frein à l'automatisation. C'est une contrainte de conception qui, bien intégrée, renforce la robustesse de vos outils. Les PME qui traitent ces questions sérieusement en amont se donnent un avantage concurrentiel réel : leurs outils sont exploitables sans réserve, leurs données sont traçables, et elles sont en mesure de répondre à un audit sans improviser.
La question que nous posons aux dirigeants qui nous consultent sur ces sujets est la suivante : si la Cnil vous demandait demain de présenter le registre des traitements de vos outils IA et la base légale associée à chaque flux de données externe, combien de temps vous faudrait-il pour produire ce document ? La réponse à cette question dit tout sur le niveau de risque réel auquel votre organisation est exposée.