La plupart des entreprises qui collectent des données web n’ont aucune règle écrite pour le faire. Un développeur construit un scraper pour un projet de tarification, une autre équipe le copie pour de la recherche de prospects, un prestataire en ajoute un troisième, et personne ne peut dire quels sites sont collectés, quelles données personnelles sont stockées, ou qui répondrait à une plainte d’un propriétaire de site. Le travail est généralement correct. Le problème est que personne ne peut prouver qu’il l’est.
Une courte politique interne règle cela. Elle donne aux ingénieurs des défauts clairs, donne aux équipes juridiques et sécurité quelque chose à examiner une fois plutôt qu’à chaque fois, et donne à l’entreprise une réponse quand un client, un auditeur ou un site web demande comment elle collecte des données. Ce guide explique ce qu’une telle politique doit couvrir et propose un modèle adaptable.
Points clés
- Une politique de collecte doit être assez courte pour que les ingénieurs la lisent : périmètre, une étape d’approbation, des règles pour les sources, des règles pour les données personnelles, et ce qui se passe quand quelqu’un s’y oppose.
- Faites du chemin sûr le défaut. Les pages publiques et accessibles sans connexion, une identification honnête, un rythme modéré et le respect du robots.txt ne nécessitent aucune approbation spéciale ; tout le reste en nécessite une.
- Traitez les objections comme des objections. L’autorité française de protection des données, notamment, attend des collecteurs qu’ils excluent les sites qui s’opposent via le robots.txt ou les CAPTCHA.
- Les données personnelles changent tout : définissez ce que vous pouvez collecter, minimisez-les dès la collecte, fixez une durée de conservation, et rendez la suppression possible.
- Nommez un responsable et un processus de retrait. La première plainte n’est pas le bon moment pour décider qui y répond.
- Ce modèle est un point de départ, pas un conseil juridique ; faites-le examiner par un juriste au regard de vos juridictions et contrats.
Pourquoi une politique écrite est importante
Il y a trois raisons pratiques.
Cohérence. Sans règles écrites, chaque projet prend ses propres décisions sur le robots.txt, le rythme, les données personnelles et la conservation. Certains seront prudents, d’autres non, et l’entreprise porte le risque du moins prudent d’entre eux.
Rapidité. Une politique avec des défauts clairs permet à la plupart des projets de démarrer sans réunion. Le juridique et la sécurité examinent la politique une fois, puis seulement les exceptions.
Preuve. Les autorités de protection des données attendent des responsables de traitement qu’ils puissent démontrer quelles garanties ils appliquent. L’autorité française de protection des données, la CNIL, par exemple, a publié des recommandations sur la collecte de données personnelles par web scraping qui listent des mesures telles que définir les critères de collecte à l’avance, exclure les sites qui s’y opposent clairement, y compris via le robots.txt ou les CAPTCHA, filtrer les données non nécessaires, et supprimer les données sensibles dès qu’elles sont identifiées. Une politique écrite est la manière de démontrer que ces mesures existent.
Ce que la politique doit couvrir
| Section | La question à laquelle elle répond |
|---|---|
| Objet et périmètre | Quelles activités et équipes cela concerne-t-il ? |
| Rôles | Qui est responsable de la politique, qui approuve les projets, qui répond aux plaintes ? |
| Règles par défaut | Que peut faire n’importe quel projet sans demander d’autorisation ? |
| Approbation | Qu’est-ce qui nécessite une validation, de qui, avec quelles informations ? |
| Sources | Quels sites et pages sont dans le périmètre autorisé, et comment traitons-nous leurs signaux ? |
| Données personnelles | Que pouvons-nous collecter sur des personnes, et comment les minimiser et les protéger ? |
| Conduite technique | Comment les collecteurs s’identifient-ils, rythment-ils leurs requêtes et gèrent-ils les identifiants ? |
| Prestataires | Qu’exigeons-nous des fournisseurs de proxies et de données ? |
| Stockage et conservation | Où vivent les données collectées, qui peut y accéder, combien de temps les conservons-nous ? |
| Objections et retraits | Que se passe-t-il quand un propriétaire de site, une personne ou un régulateur s’y oppose ? |
| Registres et révision | Que consignons-nous, et quand révisons-nous la politique ? |
Le modèle
Adaptez le texte à votre entreprise, supprimez ce qui ne s’applique pas, et gardez-le court. Le texte entre crochets est à compléter par vos soins.
1. Objet et périmètre
Cette politique régit la collecte automatisée de données sur des sites web et services en ligne par [Entreprise], ses employés et ses prestataires, y compris les scrapers, crawlers, l’automatisation de navigateur, et les données achetées à des tiers qui les collectent pour notre compte. Elle ne couvre pas les données que nos propres utilisateurs nous fournissent, ni les API officielles utilisées selon leurs propres conditions, sauf lorsque la section 6 s’applique.
2. Rôles
- Responsable de la politique : [rôle, par exemple Head of Data] maintient cette politique et le registre des projets de collecte.
- Approbateurs : [contact juridique] et [contact sécurité] approuvent les projets nécessitant une approbation au titre de la section 4.
- Responsable de projet : chaque projet de collecte nomme une personne responsable du respect de cette politique.
- Contact retrait : [rôle et boîte mail partagée] reçoit et répond aux objections au titre de la section 10.
3. Règles par défaut pour tout projet
Tout projet peut avancer sans approbation supplémentaire s’il :
- ne collecte que des pages accessibles publiquement, que tout visiteur peut voir sans se connecter ;
- respecte le robots.txt et les autres mécanismes de refus lisibles par machine qui s’appliquent au collecteur ;
- identifie le collecteur honnêtement et ne déguise pas le trafic automatisé en une personne en particulier ;
- rythme les requêtes de façon à ne placer aucune charge notable sur la cible ;
- ne collecte aucune donnée personnelle au-delà de ce que la section 6 autorise ;
- est consigné dans le registre de projets avant son démarrage.
4. Projets nécessitant une approbation
Un projet nécessite une approbation écrite des approbateurs avant de démarrer s’il :
- collecte des données personnelles au-delà des coordonnées professionnelles publiées à des fins professionnelles ;
- collecte toute donnée de catégorie spéciale, telle que la santé, la religion ou les opinions politiques ;
- collecte sur des pages situées derrière une connexion, un paywall ou tout autre contrôle d’accès ;
- continue après qu’un site a montré son opposition, y compris via le robots.txt, un CAPTCHA, un blocage, une clause contractuelle ou une demande directe ;
- collecte pour l’entraînement, l’affinage ou l’évaluation de modèles d’apprentissage automatique ;
- vend, licencie ou partage les données collectées en dehors de [Entreprise].
La demande précise l’objet, les sources, les champs de données, toute donnée personnelle et sa base légale, le volume attendu, la durée de conservation et le responsable de projet.
5. Sources et leurs signaux
- Privilégier une API officielle, un flux de données ou une licence lorsqu’elle existe et couvre le besoin.
- Lire et consigner les conditions pertinentes de chaque source avant le démarrage de la collecte.
- Traiter le robots.txt, les limites de débit, les CAPTCHA, les blocages et les réservations publiées comme des signaux des souhaits du site, et non comme des obstacles à contourner.
- Ne pas contourner les contrôles d’accès, les mesures techniques de protection ou l’authentification.
- Arrêter rapidement la collecte sur une source lorsqu’elle s’y oppose, et consigner l’arrêt dans le registre.
6. Données personnelles
- Ne collecter que les données personnelles nécessaires à l’objet déclaré, et filtrer les autres données personnelles dès la collecte lorsque c’est possible.
- Ne jamais collecter de données de catégorie spéciale sans approbation au titre de la section 4 ; si elles sont collectées par accident, les supprimer dès qu’elles sont identifiées.
- Pseudonymiser les identifiants lorsque l’analyse n’a pas besoin de l’identité elle-même.
- Ne pas combiner les données collectées avec d’autres sources pour identifier des individus sauf approbation.
- Rendre possible de trouver et supprimer les données d’une personne sur demande.
7. Conduite technique
- Stocker les identifiants pour les proxies, les API et les comptes cibles dans le gestionnaire de secrets approuvé, jamais dans le code.
- N’utiliser que des fournisseurs de proxies et de données répondant à la section 8.
- Consigner, pour chaque exécution de collecte, l’heure, la source, le lieu de collecte et la configuration utilisée.
- Surveiller les volumes de requêtes et les taux d’erreur, et mettre la collecte en pause automatiquement lorsqu’une source commence à refuser des requêtes.
8. Prestataires
Les fournisseurs de proxies et de données doivent pouvoir démontrer comment leur réseau ou leurs données sont obtenus et avec quel consentement, exploiter un processus de connaissance du client, faire respecter une politique d’utilisation acceptable, et signer des conditions compatibles avec cette politique. Le responsable de la politique conserve une liste de fournisseurs approuvés.
9. Stockage et conservation
- Stocker les données collectées uniquement dans [systèmes approuvés], avec un accès limité aux personnes qui en ont besoin.
- Conserver les pages collectées brutes pendant au plus [période] et les données extraites pendant au plus [période], sauf si une approbation fixe une durée différente.
- Supprimer les données à la fin de leur durée de conservation, et consigner la suppression.
10. Objections et retraits
- Toute objection d’un propriétaire de site, d’une personne ou d’une autorité est transmise au contact retrait dans un délai de [un jour ouvré].
- La collecte concernée est mise en pause pendant l’examen de l’objection, sauf avis contraire du juridique.
- Le contact retrait répond sous [période] et consigne l’objection, la décision et toute donnée supprimée.
- Des objections répétées concernant le même projet déclenchent une révision de l’approbation de ce projet.
11. Registres et révision
Le responsable de la politique conserve le registre des projets, les approbations, la liste des fournisseurs et le journal des retraits, et révise cette politique au moins [annuellement] et chaque fois que la loi ou les activités de l’entreprise changent de manière significative.
La faire vivre
Une politique qui reste dans un drive partagé ne change rien. Quelques habitudes la rendent réelle :
- Placez le registre là où les projets démarrent. Un court formulaire dans l’outil que les ingénieurs utilisent déjà, avec les règles par défaut sous forme de cases à cocher, repère les projets avant qu’ils n’existent plutôt qu’après.
- Intégrez les défauts dans le code. Une bibliothèque de collecte partagée qui respecte le robots.txt, définit un User-Agent honnête, rythme les requêtes et consigne le contexte de collecte fait de la politique le chemin facile, pas une étape supplémentaire. Respecter le robots.txt et les refus d’IA détaille quels signaux lire.
- Consignez où les données ont été observées. Journaliser l’heure, le lieu et la configuration par exécution est ce qui rend les données collectées défendables par la suite, comme le soutient l’argument en faveur d’une norme de point d’observation.
- Vérifiez vos fournisseurs. Demandez aux fournisseurs de proxies comment ils obtiennent leurs IP, et consultez comment les fournisseurs obtiennent des IP résidentielles de manière éthique et l’économie des malwares derrière les proxies bon marché pour comprendre pourquoi c’est important.
- Gardez les secrets hors du code. Exécuter des scrapers en CI/CD montre comment gérer les identifiants de proxy en toute sécurité.
- Lisez les signaux avant de construire. Une vérification rapide de ce qui protège une source, comme dans notre outil de détection de la pile anti-bot, vous indique tôt si un projet relève des règles par défaut ou nécessite une approbation.
Pour une vue d’ensemble juridique, voir le web scraping est-il légal et les proxies résidentiels et le RGPD ; pour la pratique quotidienne, les bonnes pratiques du web scraping.
En résumé
Une politique de collecte de données n’a pas besoin d’être longue. Elle a besoin d’un périmètre clair, de défauts sûrs qui laissent la plupart des travaux avancer, d’une étape d’approbation pour les cas à risque, de règles fermes pour les données personnelles, et d’une personne nommée qui répond quand quelqu’un s’y oppose.
Écrivez-la une fois, intégrez ses défauts dans les outils que les ingénieurs utilisent, et gardez le registre à jour. Alors, la prochaine fois que quelqu’un demandera comment votre entreprise collecte des données web, la réponse sera un document plutôt qu’une improvisation. Adaptez le modèle à votre situation, et faites-le examiner par un juriste avant de l’adopter.