Scraping de données pour la prospection : construire un dispositif utile et responsable

Le mot « scraping » décrit une technique, pas une autorisation ni une stratégie. Une page librement accessible peut contenir des informations protégées, inexactes ou publiées dans un contexte incompatible avec la réutilisation envisagée. À l’inverse, une source publique bien documentée peut fournir d’excellents signaux sans qu’il soit nécessaire de constituer un répertoire nominatif.

La collecte n’est pas encore de la prospection

Supposons qu’une entreprise veuille repérer les sociétés qui ouvrent un nouvel établissement. L’événement « ouverture d’établissement » peut être pertinent. Il ne dit toutefois ni quelle personne joindre, ni si une offre est adaptée, ni si un canal de contact est licite, ni si l’organisation souhaite être sollicitée. Transformer directement cet événement en séquence d’e-mails ferait disparaître toutes ces décisions intermédiaires.

Une chaîne mieux conçue produit d’abord une fiche d’organisation : identifiant public, événement observé, date, source, extrait factuel et niveau de confiance. Une règle métier détermine ensuite si cet événement correspond réellement à la cible. L’identification éventuelle d’un interlocuteur et le choix du canal viennent en dernier, avec leurs propres contrôles.

Cette distinction est aussi juridique. Obligation : lorsqu’une collecte porte sur des données personnelles, les principes du RGPD restent applicables même si les données sont publiquement accessibles. La CNIL rappelle notamment les exigences de licéité, de minimisation, de transparence et de respect des droits. L’article 14 du RGPD prévoit une information spécifique lorsque les données n’ont pas été obtenues directement auprès de la personne, sous réserve des conditions et exceptions du texte.

Interprétation à valider pour chaque dispositif : un intérêt commercial peut parfois participer à une analyse d’intérêt légitime, mais il ne suffit pas à lui seul. Les lignes directrices 1/2024 du Comité européen de la protection des données décrivent un examen en trois temps : intérêt poursuivi, nécessité du traitement, puis mise en balance avec les droits et attentes raisonnables des personnes.

Recommandation opérationnelle : concevoir la première version autour de données d’organisation et de signaux non nominatifs. Le passage à une donnée de personne doit être justifié champ par champ, et non accepté par défaut parce qu’un outil sait l’extraire.

Le contrat de collecte en sept questions

Avant d’écrire un collecteur, rédigez un contrat de collecte d’une page. Il ne s’agit pas des conditions du site source, mais du document interne qui rend le projet contestable et vérifiable.

1. Quelle décision doit être améliorée ? Par exemple : choisir quelles organisations méritent une recherche manuelle cette semaine. « Remplir le CRM » n’est pas une décision.
2. Quel signal observable soutient cette décision ? Une création d’établissement, une offre d’emploi technique ou une modification de site sont des observations ; « forte intention d’achat » est déjà une interprétation.
3. Pourquoi cette source ? Consignez son producteur, sa finalité, ses conditions de réutilisation, sa fréquence de mise à jour et ses restrictions techniques.
4. Quels champs sont indispensables ? Si l’identifiant de l’entreprise, l’URL de preuve et la date suffisent pour qualifier, ne collectez pas les noms présents ailleurs sur la page.
5. Combien de temps le signal reste-t-il utile ? Une information de recrutement peut devenir obsolète en quelques semaines. Une durée de conservation n’est pas seulement une règle de conformité ; c’est une propriété de qualité.
6. Qu’est-ce qui interdit l’activation ? Opposition connue, source non traçable, signal trop ancien, organisation hors cible ou ambiguïté sur l’identité doivent produire un refus explicite.
7. Qui peut arrêter le système ? Nommez la personne responsable des sources, celle qui valide les règles et celle qui traite les demandes relatives aux données.

Dans une fiche publiée le 19 juin 2025, spécifiquement consacrée au moissonnage de données pour le développement de systèmes d’IA, la CNIL indique que les attentes raisonnables dépendent notamment de la nature du site, du contexte de publication et des restrictions exprimées, dont robots.txt ou les CAPTCHA. Cette fiche ne tranche pas à elle seule un dispositif de prospection. En complément des recommandations générales publiées par la CNIL en 2024 pour la réutilisation de données accessibles en ligne, Forge Labs retient une règle opérationnelle prudente : ne pas traiter un obstacle technique comme un défi à contourner, mais comme une information sur les attentes de la source.

Une architecture qui conserve la preuve

Le collecteur n’est qu’un composant. Le système complet peut rester simple, mais il doit isoler les responsabilités :

1. Registre des sources. URL ou jeu de données, producteur, licence ou conditions, finalité permise, données exclues, fréquence autorisée, responsable et date de revue.
2. Collecteur limité. Il récupère seulement les champs prévus, s’identifie lorsque c’est approprié, respecte les limites de fréquence et s’arrête sur les erreurs d’accès au lieu de les masquer.
3. Zone brute horodatée. Elle conserve la preuve minimale nécessaire pour comprendre l’observation, avec une empreinte du contenu. Ce n’est pas une archive illimitée du site.
4. Normalisation. Elle transforme dates, identifiants et catégories sans écraser la valeur d’origine. Toute correction reste explicable.
5. Moteur d’éligibilité. Des règles versionnées produisent « à examiner », « éligible » ou « rejeté », avec des motifs lisibles.
6. File de revue. Une personne confirme les correspondances ambiguës, la pertinence du signal et l’adéquation de l’approche.
7. Passerelle d’activation. Elle vérifie la base de contact, l’information requise, le canal, les oppositions et la pression commerciale avant tout export vers le CRM.

Cette architecture reprend un principe utile pour toute automatisation : un événement doit avoir des états et une preuve, pas seulement déclencher une action. Le canevas proposé dans notre guide de documentation des workflows aide à définir les entrées, sorties, exceptions et responsabilités avant le code.

Le modèle minimal d’un signal

Un signal n’est pas une personne. Le schéma suivant garde cette distinction visible :

Champ	Rôle	Contrôle
organization_id	Identifiant stable de l’organisation	Source et règle de rapprochement
signal_type	Événement factuel observé	Vocabulaire fermé et versionné
observed_at	Date de l’observation	Ne pas la confondre avec la date de l’événement
source_url	Adresse précise de la preuve	Accessible, autorisée et datée
source_excerpt	Extrait strictement nécessaire	Pas de copie intégrale par confort
source_policy_version	Version des conditions examinées	Revue planifiée
confidence	Fiabilité du rapprochement	Méthode documentée, pas une impression
expires_at	Fin d’utilité du signal	Suppression ou réévaluation automatique
eligibility_reason	Motif d’inclusion ou de rejet	Lisible par une personne non technique

Si des coordonnées nominatives deviennent nécessaires, elles appartiennent à un objet séparé, avec la source exacte, la date de collecte, le fondement analysé, la date d’information, l’opposition et la durée de conservation. Cette séparation empêche la base de signaux de devenir silencieusement un fichier de personnes.

Les contrôles avant activation

La conformité ne peut pas être réduite à une case « RGPD ». Chaque canal et chaque contexte modifient l’analyse. L’article L. 34-5 du Code des postes et des communications électroniques encadre notamment la prospection directe par courrier électronique et exige dans tous les cas une identité non dissimulée ainsi qu’un moyen valable de faire cesser les communications. Son application concrète dépend du destinataire, du canal et des circonstances.

Avant d’envoyer un signal dans un outil commercial, la passerelle doit répondre à des questions binaires :

• l’organisation et le signal sont-ils identifiés sans ambiguïté ?
• la donnée est-elle encore exacte et pertinente ?
• la source et sa date sont-elles disponibles pour l’information de la personne ?
• le message envisagé est-il directement lié à l’activité professionnelle observée ?
• le canal et le fondement ont-ils été validés pour ce segment ?
• une opposition, une restriction de diffusion ou une exclusion sectorielle existe-t-elle ?
• le volume et la fréquence respectent-ils les règles internes de pression commerciale ?

La CNIL recommande une liste repoussoir afin de ne pas resolliciter une personne opposée. Cette liste doit elle-même être minimisée et protégée : elle sert à empêcher un contact, non à conserver un profil commercial caché. Pour les durées, la CNIL indique comme référence que les données d’un prospect utilisées à des fins de prospection peuvent être conservées trois ans à compter de leur collecte ou du dernier contact émanant du prospect ; une organisation doit néanmoins déterminer et documenter la durée adaptée à son propre traitement.

Un pilote de dix jours

Un pilote n’a pas besoin de collecter à grande échelle. Il doit prouver que le signal améliore une décision.

• Jours 1 et 2 : écrire la cible, la décision, les exclusions et les critères de réussite ; faire valider le registre de la source.
• Jours 3 et 4 : collecter un petit échantillon borné, sans coordonnées personnelles, puis vérifier manuellement la provenance et l’exactitude.
• Jours 5 et 6 : tester le rapprochement des organisations, les doublons, l’expiration et les cas ambigus.
• Jour 7 : exécuter à blanc les règles d’éligibilité ; aucune activation commerciale n’est nécessaire pour mesurer leur sélectivité.
• Jour 8 : faire relire les faux positifs par l’équipe commerciale et les risques par la personne chargée de la protection des données ou le conseil compétent.
• Jour 9 : tester l’effacement, l’opposition, la suspension d’une source et la reconstruction d’une décision depuis le journal.
• Jour 10 : décider de poursuivre, modifier ou arrêter selon des seuils écrits avant le test.

Cette approche évite de confondre volume collecté et valeur. Une centaine de signaux vérifiables peut apprendre davantage qu’un million de lignes dont personne ne connaît la date, la source ou le droit d’usage.

Les métriques et critères d’arrêt

Mesurez la qualité du système avant les performances commerciales :

• taux de signaux confirmés : part des observations dont la réalité et la date ont été vérifiées ;
• taux de rapprochements ambigus : part des signaux impossibles à attribuer automatiquement à une organisation ;
• fraîcheur : délai entre l’événement, sa publication et sa détection ;
• traçabilité : part des champs activables accompagnés d’une source et d’une date ;
• sélectivité : part des observations rejetées par les règles avant revue humaine ;
• charge de revue : temps nécessaire pour confirmer une fiche utile ;
• incidents de droits : oppositions non appliquées, informations impossibles à fournir ou suppressions incomplètes.

Arrêtez le pilote si la source interdit clairement la collecte, si les restrictions techniques doivent être contournées, si la provenance ne peut pas être conservée, si les données personnelles deviennent le produit principal sans justification, ou si la précision reste insuffisante pour une décision humaine. La méthode de mesure de la fiabilité d’une automatisation fournit des indicateurs complémentaires sur les erreurs silencieuses et la reprise.

Le scraping peut soutenir une acquisition précise lorsqu’il donne une meilleure preuve au bon moment. Il ne remplace pas une stratégie d’acquisition rentable ni la compréhension d’un marché ; il devient contre-productif dès qu’il fabrique du volume opaque. Si votre enjeu est d’évaluer une chaîne de détection, de qualification et d’activation, Forge Labs étudie ponctuellement des collaborations stratégiques ; le premier échange peut porter sur le système de décision, avant tout choix d’outil.

Sources

• CNIL — Recommandations pour les réutilisateurs de données publiées sur Internet, fiches publiées en 2024.
• CNIL — Intérêt légitime : mesures à prendre en cas de collecte par moissonnage, fiche du 19 juin 2025 consacrée au développement de systèmes d’IA.
• CNIL — RGPD, chapitre III, notamment article 14.
• Légifrance — Code des postes et des communications électroniques, article L. 34-5, version consultée le 27 septembre 2026.
• CEPD — Guidelines 1/2024 on legitimate interests.
• CNIL — Questions-réponses sur la gestion des activités commerciales.