Le Web Scraping Est-il Légal pour Votre Produit IA ? Ce que les Fondateurs Doivent Évaluer Avant de Construire

Le web scraping n'est pas illégal par défaut, mais ce n'est pas non plus un repas gratuit. L'exposition juridique d'un produit IA construit sur des données scrapées dépend de trois éléments : si les données sont publiques ou nécessitent une connexion, si elles contiennent des données personnelles, et si vous les republiez ou si vous les utilisez seulement en interne. Réglez bien ces trois points dès la conception, et la majeure partie du risque disparaît avant même qu'un avocat ne voie le produit.

Ceci est un guide pour fondateurs, pas un conseil juridique. L'objectif est de vous aider à poser les bonnes questions avant de dépenser un budget de développement sur une fonctionnalité que la conformité pourrait vous forcer à retirer.

Où se situe réellement le risque

Les fondateurs ont tendance à s'inquiéter de la mauvaise chose. La peur est une responsabilité de type « piratage ». En pratique, les litiges liés au scraping se répartissent dans quatre catégories.

1. Contrat : les conditions générales d'utilisation du site

La plupart des sites commerciaux interdisent l'accès automatisé dans leurs conditions. Que ces conditions vous engagent dépend fortement de la façon dont vous y avez consenti. Les conditions de type « browse-wrap » (un lien en pied de page que personne ne clique) sont plus faibles que les conditions « click-wrap » que vous avez acceptées en créant un compte. La règle pratique : scraper derrière une connexion que vous avez créée signifie que vous avez accepté les conditions, et vous vous trouvez désormais en territoire de rupture de contrat. Scraper des pages publiques sans compte constitue une accusation beaucoup plus faible contre vous.

2. Lois sur l'abus informatique

Des lois comme le Computer Fraud and Abuse Act américain (18 U.S.C. § 1030) concernent l'accès non autorisé. La jurisprudence américaine récente a réduit la portée de cette loi pour les pages publiquement accessibles, mais contourner l'authentification, les bannissements d'IP ou les blocages techniques vous remet dans le champ d'application. Si vous devez vaincre un blocage pour continuer à scraper, considérez cela comme un signal d'arrêt, pas comme un défi d'ingénierie.

3. Données personnelles : RGPD et ses cousins

C'est la catégorie qui mord le plus fort les produits IA. Si vous scrapez des noms, des e-mails, des titres de poste ou tout élément identifiant une personne, vous traitez des données personnelles et avez besoin d'une base légale au titre de l'Article 6 du RGPD, ainsi que d'obligations de transparence et de suppression. « C'était public » n'est pas une base légale en soi. Scraper des données personnelles à grande échelle puis les enrichir avec un LLM aggrave la situation, car vous êtes alors en train de profiler.

4. Droit d'auteur et droits sur les bases de données

Les données factuelles (prix, horaires d'ouverture, spécifications produit) sont faiblement protégées. Les articles, images, descriptions et jeux de données organisés ne le sont pas. Dans l'UE, la Directive 96/9/CE sur les bases de données ajoute un droit distinct sur l'extraction substantielle à partir de collections structurées. La Directive 2019 sur le marché unique numérique a introduit une exception pour l'exploration de textes et de données à usage commercial, mais les titulaires de droits peuvent s'y opposer par des moyens lisibles par machine. C'est pourquoi robots.txt et les signaux similaires comptent davantage en Europe que leur statut informel ne le suggère.

L'échelle de risque, du sûr à l'arrêt

Utilisez ceci pour situer votre fonctionnalité avant d'en estimer la portée :

• Risque faible : pages publiques, pas de connexion, données factuelles ou au niveau de l'entreprise, utilisées en interne pour générer votre propre résultat (un résumé, un score, un brouillon). Débit limité, respecte le robots.txt.
• Risque moyen : pages publiques mais vous stockez et affichez des extraits du contenu original aux utilisateurs, ou vous construisez un index consultable du catalogue d'un concurrent.
• Risque élevé : données personnelles à grande échelle (profils, coordonnées), données derrière toute authentification, ou republication de contenu protégé par droit d'auteur comme votre propre produit.
• Arrêt : contourner des blocages, scraper des données de santé ou financières sur des individus, ou scraper des plateformes dont vous avez accepté les conditions qui l'interdisent explicitement.

Si votre fonctionnalité est « moyenne » ou au-delà, ce n'est pas un refus automatique. Cela signifie que la revue juridique et la conception des données doivent avoir lieu avant le sprint, et que l'estimation de coûts de votre budget de pipeline de scraping devrait les inclure.

Choix de conception qui réduisent l'exposition

Le risque juridique en matière de scraping est surtout une décision d'architecture. Quelques schémas font descendre une fonctionnalité sur l'échelle sans la tuer.

Extraire les faits, abandonner la source

Le levier le plus important est la rétention. Si vous récupérez une page, extrayez la poignée de faits dont vous avez besoin et jetez le HTML brut, vous détenez presque aucun matériel protégeable par droit d'auteur et une empreinte minimale de tout élément personnel. Si vous stockez des copies complètes de pages « au cas où nous en aurions besoin plus tard », vous avez construit une copie du site d'autrui.

Nous appliquons ce schéma dans notre propre moteur de prospection (outreach engine). Il récupère le site public de chaque prospect avec une instance Firecrawl auto-hébergée et transmet le contenu à un LLM local en un seul appel qui à la fois extrait ce que fait l'entreprise et rédige un e-mail personnalisé unique. Le contenu brut de la page est jeté après l'appel. Nous avons initialement essayé une chaîne multi-étapes (crawl, résumé, classification, rédaction) et la version en appel unique était à la fois moins chère et produisait de meilleurs e-mails, ce qui constitue un rappel utile que les pipelines plus simples gagnent souvent aussi en conformité, car il y a moins d'endroits où les données traînent.

Scraper l'entreprise, pas les personnes

Pour les cas d'usage de vente et de veille marché, presque tout ce dont vous avez besoin se situe au niveau de l'entreprise : ce qu'elle vend, à qui elle vend, quelle stack elle annonce, ce qu'elle a récemment lancé. Cadrez votre prompt d'extraction sur cela et donnez explicitement l'instruction au modèle d'ignorer les noms de personnes et les coordonnées personnelles. Dans notre moteur de prospection, le prompt d'extraction demande exactement une chose, ce que fait l'entreprise, et le seul champ au niveau personnel dans tout le pipeline est l'unique adresse à laquelle l'e-mail est envoyé. Cette seule adresse nécessite toujours une base légale, mais il n'y a pas de base de données fantôme d'individus à défendre, car le pipeline n'a jamais eu d'endroit où en placer une.

Respecter les signaux, consigner que vous l'avez fait

Honorez robots.txt, identifiez votre crawler avec un véritable user agent et une URL de contact, limitez le débit par domaine, et tenez un journal des pages récupérées et à quel moment. Rien de tout cela n'est strictement requis partout, mais lorsqu'un propriétaire de site se plaint, « nous avons honoré votre robots.txt et exploré à raison d'une requête toutes les quelques secondes » est une conversation très différente de « nous avons fait tourner des proxys résidentiels pour contourner votre blocage ».

Préférer les données officielles lorsqu'elles existent

De nombreux sites que vous scraperiez publient aussi des flux, des sitemaps, des API ou des données structurées. Une API dont vous acceptez les conditions est plus lente à intégrer mais vous donne un contrat sur lequel vous appuyer. Si un fournisseur de données licencie déjà ce dont vous avez besoin, comparez son prix au coût de construction et de défense d'un scraper. C'est une véritable décision de construire-ou-acheter, pas une préférence d'ingénierie.

Auto-héberger ou utiliser une API de scraping ?

Si les données scrapées sont un élément central de votre produit, l'auto-hébergement d'un crawler open-source tel que Firecrawl est généralement le bon choix. La raison pour laquelle nous l'auto-hébergeons pour notre moteur de prospection n'est pas le coût, c'est que chaque réponse aux questions de revue ci-dessus devient la nôtre à donner : la limite de débit est définie dans notre config, la gestion de robots.txt est notre code, la page récupérée vit en mémoire sur notre machine pour un seul appel au LLM puis disparaît, et rien ne quitte notre infrastructure car le modèle est local aussi. C'est une histoire courte et vérifiable à raconter à un délégué à la protection des données. Pour une fonctionnalité à faible volume ou expérimentale, une API de scraping hébergée vous donne un signal plus rapidement, et vous pouvez migrer une fois que la fonctionnalité fait ses preuves.

Dans tous les cas, vérifiez ce que le fournisseur fait du contenu qu'il récupère pour vous. Certains services hébergés mettent en cache les pages ou les utilisent pour améliorer leurs propres systèmes, ce qui rend votre politique de rétention seulement aussi bonne que la leur. Si vous avez promis « nous jetons la page brute après extraction » et que votre fournisseur en conserve une copie, cette promesse est déjà rompue.

Questions à régler avant de briefer une agence

• Qu'extrayons-nous exactement, et que supprimons-nous immédiatement après ?
• Y a-t-il dans ces données quelque chose qui identifie une personne ? Si oui, quelle est notre base légale et notre voie de suppression ?
• Les utilisateurs verront-ils jamais le contenu original, ou seulement notre résultat dérivé ?
• Y a-t-il quelque chose derrière une connexion ou un blocage que nous devrions contourner ?
• Dans quelles juridictions se trouvent les sites et nos utilisateurs ?
• Existe-t-il une API ou une source sous licence qui rendrait tout cela sans objet ?

Apportez des réponses à ces questions à votre premier appel de cadrage et l'estimation que vous recevrez sera bien plus précise. Si la fonctionnalité concerne la prospection, lisez également nos notes sur la délivrabilité des e-mails à froid, car un scraper techniquement propre associé à un pipeline d'envoi relevant du spam finit malgré tout mal.

En résumé

Scraper des données publiques, factuelles, au niveau de l'entreprise, et les transformer en votre propre résultat est une voie bien établie et défendable. Scraper des personnes, scraper derrière des connexions, ou republier ce que vous avez scrapé, c'est là que les produits se font retirer. Décidez de quel côté de cette ligne se situe votre fonctionnalité avant de construire, concevez le pipeline pour conserver le moins possible, et traitez les blocages comme un panneau stop.

Si vous évaluez un produit IA qui dépend de données web externes et souhaitez un deuxième avis sur l'architecture et l'échelle de risque, parlons-en.