Nourrir les scrapers d’IA avec des « données X » : une défense de blog qui détourne les filtres d’entraînement

(github.com/vivienhenz24)

7 points par baeba 2025-12-19 | 2 commentaires | Partager sur WhatsApp

Analyse de l’outil « Fuzzy Canary » pour empêcher la collecte de données d’entraînement par l’IA

Points clés :
Il insère des liens invisibles vers des sites inappropriés (contenu adulte, etc.) afin de détourner les filtres de blocage de contenu des scrapers d’IA.
Il propose des modes d’injection côté serveur (recommandé) et côté client, avec des méthodes d’intégration qui varient selon le framework.
Il inclut une fonction d’identification des bots de recherche légitimes (Google, Bing, etc.) afin d’exclure l’injection de liens et de préserver le SEO.

Le problème : des entreprises d’IA collectent de façon indiscriminée les données de sites web, y compris de blogs auto-hébergés, pour constituer leurs jeux de données d’entraînement.
La solution proposée : « Fuzzy Canary » utilise une méthode consistant à insérer dans le HTML des liens invisibles vers des sites web (par exemple pour adultes).
Principe de fonctionnement : les données contenant ces liens déclenchent les garde-fous de sécurité de contenu des scrapers d’IA, ce qui empêche finalement la collecte des données du site à des fins d’entraînement.

Distinction entre l’injection côté serveur et côté client

Implémentation côté serveur (recommandée) :
Publicité
Caractéristique : comme le « Canary » (lien piège) est inclus au moment de la génération du HTML, il fonctionne efficacement même contre les scrapers qui n’exécutent pas JavaScript.
Frameworks basés sur React (Next.js, Remix) : l’intégration se fait en ajoutant le composant <Canary /> au layout racine. Certains frameworks comme Remix exigent en outre la transmission des informations du User Agent via un loader.
Frameworks non React : on injecte directement le HTML au début de la balise <body> à l’aide de l’utilitaire getCanaryHtml().
Implémentation côté client :
Caractéristique : utilisée pour les sites statiques ou lorsque l’on préfère une injection côté client.
Application : il suffit d’importer le module d’initialisation automatique (@fuzzycanary/core/auto) dans le fichier d’entrée principal ; l’injection se fait alors automatiquement au chargement de la page.
Publicité

Identification des bots de recherche légitimes et limites des sites statiques

Mécanisme de filtrage des bots : Fuzzy Canary identifie les bots connus des moteurs de recherche comme Google, Bing ou DuckDuckGo et omet l’injection de liens pièges pour ces requêtes, afin d’éviter tout dommage SEO.
Avantage du rendu côté serveur : le serveur peut vérifier le User Agent de la requête et fournir sélectivement un « HTML propre » aux moteurs de recherche, et un « HTML avec Canary » aux scrapers d’IA.
Problème structurel des sites statiques :
Publicité
sur un site statique, le HTML est généré à la phase de build, ce qui empêche toute vérification du User Agent ;
si tous les fichiers HTML contiennent des liens pièges, des moteurs comme Google peuvent les détecter, avec un impact négatif possible sur le SEO.
Stratégie de réponse : lorsqu’on utilise un générateur de site statique, il faut recourir à l’initialisation côté client afin de vérifier navigator.userAgent à l’exécution et décider s’il faut injecter ou non les liens (avec la limite que cela ne fonctionne que contre les bots qui exécutent JavaScript).

Efficacité technique : du point de vue de la protection des données, l’approche côté serveur est la plus efficace, car elle fonctionne indépendamment de l’exécution de JavaScript.
Équilibre avec le SEO : pour un site statique, adopter l’approche côté client est structurellement inévitable si l’on veut éviter le risque d’une dégradation du SEO.
Recommandation finale : il faut choisir la méthode d’intégration en fonction du mode de rendu du framework web utilisé (SSR vs Static), en arbitrant entre l’efficacité anti-scraping et la préservation du SEO.

2 commentaires

baeba 2025-12-19

1. Une idée créative et une valeur divertissante

Indépendamment de son efficacité réelle, l’idée de répondre à la collecte non autorisée des grandes entreprises d’IA avec des « liens pour adultes » a été saluée comme ingénieuse et jubilatoire.
La communauté apprécie le fait de punir, sur un mode humoristique et satirique, des pratiques de scraping jugées absurdes.

2. Efficacité de blocage concrète et retours d’expérience

Des cas de réussite réels ont été partagés, notamment après l’adoption d’outils similaires (comme Anubis), où les requêtes quotidiennes seraient tombées de 6000 à 100.
La méthode semble très efficace pour se défendre contre des scrapers simples et brutaux qui aspirent sans distinction l’intégralité d’un dépôt Git.

3. Inquiétudes sur les effets secondaires potentiels (risques)

Pénalité SEO : certains soulignent qu’il pourrait y avoir une baisse du classement si des moteurs de recherche légitimes comme Google détectent des liens pour adultes.
Restriction d’accès : il existe un risque que le blog technique devienne inaccessible depuis des réseaux d’entreprise (Corporate Network) à cause des filtres bloquant les sites jugés inappropriés.

4. Débat sur les alternatives techniques

Cloudflare : certains estiment qu’un WAF gratuit suffit, tandis que d’autres rejettent l’idée de dépendre d’un service centralisé.
Défense maison : certains avancent qu’une simple authentification JS/cookie peut suffire, tandis que d’autres rétorquent qu’elle est inutile face aux bots modernes utilisant des navigateurs headless (Headless Browser).

5. Dénonciation du manque d’éthique des entreprises d’IA

Transfert des coûts : critique d’une contradiction structurelle où l’IA récupère les données, tandis que la charge serveur et les coûts de trafic restent à la charge des particuliers.
Comportement digne d’un DDoS : forte hostilité envers des méthodes de scraping qui frappent les serveurs de manière indiscriminée sans apporter de trafic entrant ni de compensation.

aer0700 2025-12-20

Le SEO est vraiment le principal problème...