Le parseur fonctionne. Les HTTP 200 affluent sans interruption, les proxys sont actifs, le captcha ne s'affiche pas, la file d'attente des liens augmente. Et une semaine plus tard, il s'avère que la moitié des prix collectés sont fictifs, et des gigaoctets de trafic ont été dirigés vers des pages qui n'existent pas sur le site réel. Ce n'est pas une défaillance du parseur ni un mauvais pool d'IP. C'est un nouveau mode de protection : le site ne vous bloque pas, il vous nourrit.
En un an et demi, l'industrie de la protection anti-bot a discrètement changé d'objectif. Le blocage est une mesure coûteuse et visible : le scraper voit un 403, corrige son empreinte, change de sous-réseau et revient. Il est beaucoup plus avantageux de ne pas l'empêcher de travailler, mais de rendre son travail inutile. Ci-dessous, trois mécaniques qui fonctionnent déjà en production sur des millions de sites, et un ensemble de vérifications qui les détectent de votre côté.
Première mécanique : tarpit au lieu de blocage
Le tarpit (tarpit, « fosse de goudron ») est un générateur de site infini. Le crawler reçoit une page HTML valide avec des dizaines de liens, chaque lien menant à une page générée similaire, et la file d'attente de navigation ne se vide jamais.
L'outil open source le plus connu est Nepenthes. Ses réglages montrent bien l'intention : par défaut, le serveur maintient une réponse de 10 à 65 secondes, renvoie un texte « de blabla markovien », généré à partir d'un corpus, et le fait de manière déterministe — la même URL renvoie toujours le même déchet, afin que les pages ressemblent à des fichiers statiques normaux, et non à un piège. Les données sont renvoyées par petites portions, « quelques octets », pour épuiser les délais d'attente du client. L'auteur fournit une mesure pour une heure de fonctionnement : 1850 clients différents, 10 015 requêtes et 56 020 secondes de latence totale — environ quinze heures de temps machine perdu pour autrui.
Iocaine fonctionne différemment : il agit comme un proxy inverse devant le véritable site, et dès le premier interception, il fournit au bot un lien « empoisonné » unique et le reconnaît à son retour, tandis que le texte est généré par des chaînes de Markov — calculant que ce texte fera partie de l'échantillon d'apprentissage.
Chez Cloudflare, la même approche est devenue un produit — AI Labyrinth, présenté en mars 2025. Les pages appâts ne sont pas générées à la volée : un pipeline de pré-génération sur Workers AI est utilisé, le résultat est stocké dans R2 et distribué rapidement. Les liens vers le labyrinthe sont intégrés dans des pages normales via une transformation HTML, et sur les appâts eux-mêmes, des méta-directives contre l'indexation sont placées pour ne pas nuire aux résultats. L'essentiel ici n'est pas le temps perdu par le bot, mais le signal : les liens, cachés des humains et marqués nofollow, ne sont parcourus que par des automates, et passer trois niveaux en profondeur dans un tel labyrinthe devient en soi une empreinte d'un mauvais bot. L'ampleur du problème pour lequel cela a été fait est estimée par Cloudflare à plus de 50 milliards de requêtes par jour provenant de crawlers IA — un peu moins de 1 % de tout le trafic du réseau.
À quoi ressemble un tarpit dans vos logs
Une image caractéristique : une file d'attente de plusieurs milliers d'URL, qui ne fait qu'augmenter, le temps de réponse reste constamment autour de une seconde et demie et plus, les codes HTTP sont tous des 200, et le nombre d'enregistrements utiles extraits est nul. Pas un seul 403, pas de captcha, et aucune sortie : peu importe combien de pages ont été parcourues, de nouveaux liens apparaissent plus vite que les anciens ne se ferment.
Deuxième mécanique : contenu empoisonné pour les agents IA
Si la première mécanique brûle des ressources, la seconde frappe les résultats. Les chercheurs Minghao Luo et Liang Chen ont publié en juin 2026 un travail avec le simulateur FORGE (Fake Online Recommendations in Generative Environments) : ils ont testé 12 grands modèles linguistiques sur 225 produits dans 15 catégories — des vêtements à l'électronique. La mécanique de l'attaque est simple : dans le texte de la page, une véritable marque est remplacée par une fictive.
Le résultat — une page falsifiée donne jusqu'à 27 % de cas où l'assistant recommande une marque inexistante, et remplacer les trois premiers résultats de recherche augmente cette proportion à 73,8 %. Les modèles ne se contentaient pas de répéter un faux nom — ils inventaient des mérites pour celui-ci, y compris une prétendue popularité dans les communautés. Les trois protections proposées (un prompt de scepticisme, un consensus sur les connaissances internes du modèle, une vérification entre documents) n'ont soit pas fonctionné, soit créé de nouveaux problèmes. La conclusion des auteurs : il faut vérifier plus haut dans le flux — au stade de la collecte, et non au stade du raisonnement.
La troisième mécanique complète le tableau. Dans le travail « A Whole New World: Creating a Parallel-Poisoned Web Only AI-Agents Can See » (Shaked Zychlinski), le cloaking est décrit, ciblant précisément les agents IA : le site reconnaît l'agent par les attributs du navigateur, les signatures du framework d'automatisation et les caractéristiques réseau, et lui renvoie une autre version de la page — avec des instructions cachées et des faits modifiés. Un humain, ouvrant la même URL, voit une page normale, donc une vérification manuelle « je suis entré, tout va bien » ne prouve rien.
Pourquoi c'est avant tout une question de budget
Le tarpit est conçu de telle sorte que chaque page soit bon marché pour le site et coûteuse pour vous. Lorsque le trafic est payé par gigaoctets, le générateur de pages infinies se transforme en compteur de vos dépenses : vous payez pour des mégaoctets de texte markovien qui ne deviendra jamais une ligne dans la base. C'est exactement la même arithmétique que pour les requêtes échouées — le prix par gigaoctet ne dit rien sur le coût du résultat, tant que vous ne calculez pas le coût d'un enregistrement réussi, et non d'une requête.
D'où la première règle pratique : la limite de trafic doit être fixée au niveau du domaine et de la tâche, et non seulement au niveau du compte. Un domaine qui a consommé plus d'un gigaoctet et n'a pas donné un seul enregistrement doit être arrêté automatiquement — sans cela, un seul piège peut épuiser le budget quotidien en une nuit.
Sept vérifications qui attrapent les déchets
- Comptez le yield, pas les codes de réponse. La principale métrique du pipeline est la part des requêtes ayant donné un enregistrement valide avec des champs obligatoires remplis. Tant que vous regardez la part des 200, le tarpit semble être une source parfaitement saine.
- URL canari. Une fois tous les N requêtes, demandez une adresse manifestement inexistante dans le domaine — avec un segment de chemin aléatoire. Un site normal répondra par un 404 ou une redirection, le générateur renverra une page complète avec du texte et des liens. C'est la vérification la moins coûteuse et la plus fiable.
- Cross-validation depuis un autre profil IP. Prenez la même URL par deux chemins différents — par exemple, via un IP résidentiel et via un mobile — et comparez le hachage des champs clés : prix, noms, disponibilité. Une divergence pour la même URL et un temps de requête proche signifie que vous voyez différentes versions de la page, et au moins l'une d'elles n'est pas destinée aux humains.
- Ne suivez pas les liens invisibles. Les liens avec nofollow, de taille nulle,
display:noneou placés en dehors de l'écran — ce sont des appâts, et cliquer dessus est l'empreinte même du bot. Filtrez-les au stade de l'extraction des liens, et non après. - Plafonds stricts sur la réponse. Limitez non seulement le timeout, mais aussi la taille maximale du corps et la profondeur maximale de navigation depuis le point d'entrée. Une réponse lente par petits morceaux est un signe typique d'une fosse, et non d'un serveur lent.
- Cherchez la régularité du texte. La génération markovienne se révèle par des statistiques : longueur des paragraphes suspectement uniforme, n-grammes répétitifs entre des pages « différentes », des dizaines de liens sortants en l'absence d'éléments structurels comme le prix, le numéro d'article ou la date. Une simple vérification des shingles répétitifs entre les pages voisines du domaine élimine ces sources en masse.
- Vérifiez les chiffres pour leur bon sens. Un prix en dehors du couloir historique, un produit sans aucune correspondance dans votre propre base de marques, un saut soudain de l'assortiment — ce sont des règles de validation qui doivent être appliquées avant l'enregistrement dans la base, et non dans le rapport un mois plus tard. Surtout si les données sont ensuite intégrées dans un modèle ou une décision d'achat automatique.
Que faire avec le jeu de données déjà collecté
Si le soupçon est apparu a posteriori, triez non pas par dates, mais par sources. Regroupez les enregistrements par domaine et examinez trois valeurs : la part des pages sans champs obligatoires, le nombre moyen de liens sortants par page et la dispersion de la longueur du texte. Les domaines-pièges se distinguent généralement immédiatement par les trois. Ensuite, vérifiez sélectivement les URL contestées depuis un autre profil IP — si les données ne correspondent pas, l'ensemble du jeu de données de ce domaine doit être reconstruit, et non corrigé par des filtres.
Il convient également de revoir les règles pour les scénarios d'agents, où le modèle navigue lui-même sur les pages et prend lui-même des décisions. C'est précisément là qu'un remplacement d'une page donne le maximum d'effet, et il n'y a pas d'intermédiaire qui pourrait remarquer une anomalie. La couverture minimale consiste à exiger la confirmation du fait à partir de deux sources indépendantes et à ne pas permettre à l'agent d'agir sur des données obtenues d'un seul domaine.
En résumé
Les bots ont depuis longtemps dépassé les humains en part de trafic, et la protection a répondu non seulement par des filtres : aujourd'hui, il est moins cher de nourrir un automate avec des déchets plausibles que de se battre contre lui avec des blocages. Trois conséquences pratiques. Comptez les enregistrements utiles, et non les statuts de réponse. Gardez des vérifications canari et des limites de trafic pour chaque domaine. Comparez les pages contestées depuis différents profils IP — la divergence des versions d'une même page est la preuve que vous voyez un internet séparé, préparé spécialement pour les bots. Les proxys dans ce schéma ne résolvent qu'une seule tâche — fournir un second regard indépendant sur la page ; tout le reste est fait par la validation de votre côté.