Notre position, clairement énoncée : nous sommes Geonode et nous vendons des proxys ; nous nous situons donc, par intérêt commercial, du côté des robots d'indexation. Pour être honnête, la plupart des techniques permettant d’éviter les honeypots consistent simplement à explorer correctement le site, et la mesure la plus efficace est celle qui ne coûte rien : respecter la balise robots.txt. Une grande partie des pièges est placée sur des chemins que le site a déjà demandé aux robots d’exploration de ne pas emprunter ; ainsi, un robot conforme ne les rencontre jamais. Les autres pièges sont évités en rendant le CSS, en ne soumettant pas de formulaires pour lesquels vous n’avez pas reçu d’invitation et en limitant votre exploration. Rien de tout cela ne nécessite d’acheter quoi que ce soit chez nous, et un robot d’exploration qui a besoin de proxys pour survivre à un honeypot est un robot qui a déjà commis une erreur plus fondamentale.
Qu'est-ce qu'un « honeypot » ?
La définition est davantage comportementale que technique : il s'agit d'un contenu avec lequel seul un client automatisé interagira, placé là afin que cette interaction permette d'identifier le client comme étant automatisé.
La logique est simple et difficile à contester. Un visiteur humain utilise un navigateur, qui applique le CSS, affiche la mise en page et lui montre ce qui est visible. Un robot d’indexation qui analyse le code HTML perçoit tous les éléments du balisage de la même manière — y compris un lien stylisé pour être invisible, un champ de formulaire masqué hors de l’écran et un chemin vers lequel personne ne renvoie depuis un endroit où un utilisateur pourrait le voir.
Toute interaction avec l’un de ces éléments constitue un signal fort. Ce n’est pas concluant, car les outils d’accessibilité et les navigateurs en mode texte se comportent eux aussi différemment, mais ce signal est suffisamment fort pour que les sites agissent en conséquence.
Les conséquences varient d’un site à l’autre. Certains enregistrent l’événement et l’ignorent. D’autres limitent le débit. D’autres encore bloquent l’adresse. Certains proposent indéfiniment un contenu dégradé, ce qui constitue le pire scénario car cela ressemble à un succès. Et d’autres adoptent désormais des mesures plus élaborées, décrites ci-dessous.
Les six types que vous rencontrerez
1. Les liens invisibles. Un lien dont le style est défini avec « display: none », « visibility: hidden », des dimensions nulles, une couleur identique à celle de l’arrière-plan, ou positionné hors de l’écran. Présent dans le code HTML, mais absent de la page affichée.
<a href="/trap/do-not-follow" style="display:none">Products</a>
<a href="/hidden" class="visually-hidden">Sitemap</a>
La forme la plus courante, et la plus facile à éviter.
2. Les chemins interdits. Des URL qui n’apparaissent que dans le fichier robots.txt sous une directive Disallow, sans lien provenant d’aucune source. La seule façon d’en trouver une est de lire le fichier d’exclusion puis de l’ignorer — ce qui fait d’une requête vers ce chemin un signe quasi infaillible de non-conformité délibérée.
3. Champs de formulaire masqués. Un champ masqué par CSS qu’un utilisateur ne remplit jamais. Toute soumission contenant une valeur pour ce champ provient d’un processus d’analyse du code HTML. Courant dans les formulaires de commentaires et les processus d’inscription, où il s’agit d’une mesure anti-spam légitime et efficace.
4. Espaces d’URL infinis. Pas toujours intentionnels, mais tout aussi préjudiciables dans les deux cas. Un calendrier comportant un lien « mois suivant » génère des URL illimitées. La navigation à facettes sur un vaste catalogue produit des explosions combinatoires. Un robot d’indexation sans limites de profondeur ni de motifs suivra ces liens jusqu’à ce que quelque chose l’arrête.
5. Pièges temporels. Contenu qui n’apparaît qu’après un certain délai, ou formulaires qui rejettent les soumissions remplies plus rapidement qu’un humain ne pourrait le faire. Ceux-ci piègent les clients qui agissent instantanément plutôt que ceux qui analysent le balisage.
6. Contenu empoisonné ou généré. La catégorie la plus récente, suffisamment importante pour mériter sa propre section.
Les « tar pits » de l’IA et les labyrinthes générés
Il s’agit d’une avancée véritablement nouvelle, qui explique pourquoi ce sujet a évolué ces deux dernières années.
Le AI Labyrinth de Cloudflare en est l’exemple le plus répandu. Cloudflare le décrit comme « une nouvelle approche de protection qui utilise du contenu généré par l’IA pour ralentir, désorienter et épuiser les ressources des robots d’indexation basés sur l’IA ».
Le mécanisme : l’IA Workers génère des pages HTML variées sur des sujets divers, stockées dans R2 pour une diffusion rapide, et ces pages leurres sont reliées aux pages réelles par des liens cachés qui sont « invisibles pour les visiteurs humains mais accessibles aux robots d’indexation ».
L’explication de Cloudflare sur les raisons de son efficacité constitue la formulation la plus pertinente du principe du « honeypot » jamais écrite :
Aucun être humain ne s’aventurerait à quatre liens de profondeur dans un labyrinthe d’absurdités générées par l’IA.
Point crucial : le contenu servi est « réel et lié à des faits scientifiques, mais il n’est ni pertinent ni propre au site exploré » — un robot d’indexation ne peut donc pas le détecter en vérifiant si le texte est cohérent. Il est cohérent. Il porte simplement sur un autre sujet.
Cette fonctionnalité est disponible sur tous les forfaits Cloudflare, y compris la version gratuite, et son activation se fait d’un simple clic dans la section de gestion des bots, « sans configuration supplémentaire ».
Des outils indépendants fonctionnent selon le même principe. Nepenthes génère un labyrinthe infini de pages sans liens de sortie. Iocaine fonctionne comme un proxy inverse et effectue une étape supplémentaire qu’il est utile de comprendre : il « empoisonne » les URL qu’il sert, de sorte qu’un robot d’indexation revenant plus tard sous le couvert d’un navigateur peut toujours être identifié par le fait que sa file d’attente de requêtes ne contient que des URL jamais fournies que par le « tarpit ». Il s’agit là d’un marqueur persistant plutôt que momentané.
Deux implications pour quiconque exploite un robot d’indexation.
La détection par la qualité du contenu ne fonctionne pas. Les pages sont cohérentes et factuelles. Ce qui les identifie, c’est qu’elles sont sans rapport avec le site, déconnectées de tout lien vers lequel un utilisateur pourrait accéder, et illimitées en nombre.
Limiter votre exploration est désormais essentiel, et non plus simplement une question d’ordre. Un robot d’exploration sans limites de profondeur, sans limite de nombre de pages et sans détection des doublons peut gaspiller des jours de calcul et des gigaoctets de bande passante facturée sur du contenu absurde généré, sans recevoir la moindre erreur à aucun moment. Avec une tarification au gigaoctet, cela représente une véritable facture pour rien.
Comment les éviter sans recourir à des manœuvres sournoises
Toutes les mesures présentées ici correspondent à ce qu’un robot d’indexation bien conçu devrait de toute façon faire.
Respectez les directives «robots.txt » (directives de l’anonymat). Ce simple fait permet d’éviter une grande partie des pièges, car les chemins interdits se trouvent là où les sites les ont placés. Il s’agit désormais d’une norme — RFC 9309 — qui privilégie la spécificité plutôt que l’ordre, et nous avons expliqué comment l’interpréter correctement dans comment lire un fichier robots.txt.
Vérifiez la visibilité calculée avant de suivre un lien. Dans un navigateur sans interface graphique, c’est très simple :
const links = await page.$$eval('a[href]', els =>
els.filter(el => {
const s = getComputedStyle(el);
const r = el.getBoundingClientRect();
return s.display !== 'none' && s.visibility !== 'hidden' &&
parseFloat(s.opacity) > 0 && r.width > 1 && r.height > 1;
}).map(el => el.href)
);
Remarque : utilisez getComputedStyle plutôt que de lire l’attribut style intégré — un lien masqué par une règle de feuille de style ne possède pas de style intégré à inspecter.
Sans navigateur, appliquez des heuristiques : ignorez les liens dont le style en ligne contient display:none ou visibility:hidden, ignorez les textes d’ancrage vides, ignorez les noms de classe tels que hidden, visually-hidden et sr-only, et méfiez-vous des liens dont l’attribut href n’apparaît nulle part dans le texte visible.
Limitez strictement l’exploration. Une profondeur maximale, un nombre maximal de pages et un budget par domaine. Non pas à titre de solution de secours, mais comme limite stricte. C’est la seule défense efficace contre les espaces infinis, quelle que soit la manière dont ils sont générés.
Détectez les répétitions. Le hachage de contenu permet de repérer les pages générées qui ne diffèrent que superficiellement. L’analyse des modèles d’URL permet de repérer les chemins qui s’allongent sans limite. Si un répertoire a généré deux cents pages et ne montre aucun signe d’arrêt, arrêtez-vous et examinez la situation.
Ne soumettez pas de formulaires pour lesquels vous n’avez pas été invité. Les pièges aux champs cachés ne capturent que les clients qui remplissent tous les champs de saisie qu’ils trouvent.
Limitez le débit et réglez le rythme. Un rythme similaire à celui d’un humain permet d’éviter les pièges de synchronisation tout en réduisant simultanément tous les autres signaux.
Identifiez-vous. Un robot d’indexation doté d’un nom et d’une URL de contact est un robot qu’un opérateur peut choisir d’autoriser. Il ne s’agit pas exactement d’une mesure visant à éviter les pièges, mais cela modifie ce qui se passe après que vous en avez déclenché un.
Détecter un piège en situation réelle
Signaux indiquant que vous vous êtes fourvoyé dans un piège, classés par ordre croissant de rapidité d'apparition.
Le nombre de pages ne converge pas. La file d'attente ne cesse de s'allonger au lieu de se réduire, ce qui constitue le premier signe avant-coureur et le plus facile à mettre en place.
Le contenu est cohérent mais hors sujet. Des pages qui se lisent bien mais qui n’ont rien à voir avec le sujet réel du site. C’est la marque de fabrique du « labyrinthe IA ».
Les URL suivent un schéma généré. Des chemins d’accès longs, des structures de segments inhabituelles et aucune répétition des URL que l’on s’attendrait à trouver sur un vrai site.
Aucun lien entrant provenant d’une source plausible. Les pages renvoient les unes vers les autres, mais aucun lien externe ne pointe vers elles.
Les temps de réponse sont d’une uniformité suspecte. Le contenu généré est servi à partir d’un cache ; les vraies pages présentent des variations.
La qualité de vos données baisse sans que votre taux d’erreur ne change. C’est le signe le plus évident à un stade avancé, et la raison pour laquelle il est important que toutes les requêtes renvoient un code 200.
Le contrôle pratique consiste en une assertion continue plutôt qu’en une vérification manuelle : si le rapport entre les nouvelles URL découvertes et les pages récupérées ne diminue pas au cours d’une exploration, cela signifie que quelque chose génère des URL plus rapidement que vous ne pouvez les traiter, et aucune exploration d’un site fini ne se comporte ainsi.
À l'attention des propriétaires de sites : leur mise en place
L'autre aspect, en bref, car le même principe s'applique aux deux cas.
Les champs de formulaire masqués sont la solution la plus efficace. Faciles à ajouter, efficaces contre les soumissions automatisées de formulaires et sans impact sur les utilisateurs réels. Donnez au champ un nom anodin, masquez-le à l’aide de CSS dans une feuille de style plutôt qu’en ligne, et rejetez toute soumission qui le remplit.
Les liens masqués permettent de détecter les robots d’indexation qui n’affichent pas le contenu. Cette méthode est efficace et mérite d’être associée à la directive robots.txt afin que les robots conformes ne soient pas piégés. Pénaliser un robot bien élevé à cause d’un piège que vous n’avez pas exclu est un problème que vous vous infligez vous-même.
Les « tarpits » gérés sont désormais activables/désactivables. Celui de Cloudflare est disponible sur tous les forfaits, y compris la version gratuite, et ne nécessite aucune configuration, ce qui le rend accessible à n’importe quel site.
L’accessibilité est la véritable contrainte. Les lecteurs d’écran et les navigateurs textuels n’appliquent pas les styles visuels de la même manière que le navigateur d’un utilisateur voyant. Un piège utilisant l’display: none est généralement sans risque car les technologies d’assistance le respectent ; un piège utilisant un positionnement hors écran ou du texte transparent peut être annoncé à un utilisateur de lecteur d’écran, qui le suit alors et se retrouve bloqué. Si vous déployez ce type de pièges, testez-les avec un lecteur d’écran.
Et déterminez ce que vous souhaitez réellement. Les moteurs de recherche, les partenaires de comparaison de prix, les outils d’accessibilité, les services de surveillance et les agents IA envoient tous du trafic automatisé, dont une partie vous intéresse. Un piège général les intercepte tous. Exclure les robots d’indexation connus pour être fiables via l’agent utilisateur, et ne placer des pièges que sur les chemins déjà interdits par robots.txt, est la solution qui permet d’intercepter le trafic que vous refusez tout en épargnant le reste.
Quand il vaut mieux s'arrêter plutôt que de s'adapter
Une décision qu'il convient d'énoncer clairement, puisque nous sommes un fournisseur dont le produit consiste justement en cette « adaptation » habituelle.
Si un site a mis en place des pièges, c’est qu’il a fait passer un message. Combiné aux interdictions d’robots.txts et aux conditions interdisant l’accès automatisé, ce message ne laisse aucune ambiguïté, et continuer à contourner ces mesures est un choix dont les conséquences vont bien au-delà du simple aspect technique.
Les alternatives sont souvent meilleures et presque toujours moins coûteuses :
Demandez. Un e-mail expliquant qui vous êtes et ce dont vous avez besoin résout le problème plus souvent qu’on ne le pense, et un flux partenaire élimine complètement le problème.
Vérifiez s’il existe une API officielle. De nombreux sites dotés d’une protection agressive en publient une, précisément pour que les utilisateurs légitimes aient un recours.
Vérifiez si les données existent ailleurs. Ensembles de données publics, archives, documents officiels, fournisseurs agréés.
Réduisez vos besoins. Une grande partie du scraping collecte bien plus que ce que la requête exige. Une demande plus modeste est plus facile à satisfaire par des moyens légitimes.
Et d’un point de vue pratique : les « tarpits » sont conçus pour vous coûter plus cher qu’ils ne coûtent au site. Cloudflare génère les pages une seule fois et les diffuse à partir de son stockage ; vous payez au gigaoctet, à l’heure de calcul et en temps d’ingénierie. Cette asymétrie est délibérée, et elle ne s’améliore pas avec l’effort.
Questions fréquentes
Qu'est-ce qu'un « honeypot » dans le cadre du web scraping ?
Il s'agit d'un élément placé sur une page avec lequel seul un client automatisé interagira : un lien invisible, un champ de formulaire caché ou un chemin d'accès auquel aucun utilisateur humain ne s'attendrait. Le fait d’interagir avec cet élément identifie le client comme un bot, et les sites réagissent en enregistrant l’activité, en limitant le débit ou en bloquant l’accès.
Comment éviter les pièges « honeypot » ?
Respectez les balises robots.txt, car de nombreux pièges se trouvent sur des chemins interdits. Vérifiez la visibilité calculée avant de suivre des liens plutôt que d’analyser le code HTML brut. Ne remplissez pas les champs de formulaire qui ne vous ont pas été présentés. Et limitez votre exploration en fixant des limites strictes de profondeur et de nombre de pages, ce qui constitue la seule défense contre les espaces infinis.
Qu’est-ce qu’un « tarpit » IA ?
Un système qui propose aux robots d’exploration automatisés un labyrinthe infini de pages générées afin d’épuiser leurs ressources. Le « AI Labyrinth » de Cloudflare génère un contenu cohérent et factuel, mais sans aucun rapport avec le site, accessible via des liens invisibles depuis de vraies pages. Il est disponible sur tous les forfaits, y compris la version gratuite, et s’active d’un simple clic.
Puis-je détecter un « honeypot » avant d’y tomber ?
En partie. L’affichage de la page et la vérification des styles calculés permettent de détecter de manière fiable les liens cachés. Les labyrinthes générés sont plus difficiles à repérer, car le contenu est cohérent : les signaux à surveiller sont une file d’attente qui ne cesse de s’allonger, un contenu sans rapport avec le site et des modèles d’URL qui ne se répètent pas. Limiter l’exploration est la défense qui fonctionne dans tous les cas.
Les liens cachés nuisent-ils au référencement naturel (SEO) ou à l’accessibilité ?
Le texte caché a toujours été considéré comme une pratique manipulatrice par les moteurs de recherche ; les pièges sont donc généralement associés à une directive disallow dans le fichier robots.txt. L’accessibilité est le principal sujet de préoccupation : la balise display: none est respectée par les technologies d’assistance, mais un texte hors écran ou transparent peut être lu à voix haute à un utilisateur de lecteur d’écran, qui risque alors de le suivre.
Que se passe-t-il si mon robot d’indexation tombe sur un « honeypot » ?
Cela varie. Certains sites l’enregistrent, d’autres limitent le débit, d’autres encore bloquent l’adresse, et d’autres enfin diffusent indéfiniment du contenu dégradé — ce qui constitue le pire des cas, car tout renvoie un code 200 et vos données se dégradent insidieusement. Les « tarpits » fonctionnent différemment : ils continuent à vous servir du contenu, indéfiniment.
Les pièges de type « honeypot » sont-ils légaux ?
Les placer sur votre propre site est tout à fait légal — c’est vous qui décidez ce que vous servez. Ce qu’un site fait des informations d’identification ainsi obtenues est régi par ses conditions d’utilisation. Du point de vue du robot d’indexation, le fait de déclencher un « tarpit » n’est pas illégal en soi ; cela peut toutefois constituer une violation des conditions d’utilisation, ce qui relève du domaine contractuel.
Comment empêcher mon robot d’indexation de gaspiller de l’argent sur un « tarpit » ?
Des limites strictes sur la profondeur et le nombre de pages par domaine, le hachage du contenu pour détecter les pages quasi-dupliquées, et une alerte lorsque le ratio entre les URL nouvellement découvertes et les pages récupérées ne diminue pas. Sans ces mesures, un robot d’indexation à quota peut passer des jours et consommer des gigaoctets sur des pages générées tout en affichant un taux de réussite parfait.
En conclusion
Les pièges de type « honeypot » reposent sur un principe : le robot d’indexation voit le code source, tandis qu’un utilisateur humain voit la page telle qu’elle s’affiche. Tout le reste n’est qu’une variante : un lien invisible, un champ masqué, un chemin d’accès mentionné uniquement par robots.txt, ou un labyrinthe sans fin.
Ces mesures de défense correspondent à tout ce qu’un robot d’indexation bien conçu devrait faire de toute façon. Respectez les directives « robots.txt », car c’est là que se trouvent de nombreux pièges et que la conformité ne coûte rien. Vérifiez la visibilité calculée plutôt que d’analyser le code HTML brut. Ne touchez pas aux formulaires, sauf s’ils vous ont été présentés. Et imposez des limites strictes à votre exploration : c’est la seule mesure qui vous protège contre les labyrinthes générés dont le contenu est délibérément impossible à distinguer d’un véritable texte.
Cette dernière catégorie a bouleversé la donne économique. Un « tarpit » géré génère ses pages une seule fois et les sert à partir du cache ; un robot d’exploration paie au gigaoctet et à l’heure de calcul, et reçoit un code d’état 200 à chaque fois. C’est cette asymétrie qui fait toute la différence : elle est désormais accessible à n’importe quel site d’un simple clic, et elle ne cède pas face aux efforts déployés.
Ce qui fait de cette option peu glamour une solution qu’il convient de prendre au sérieux. Un site qui a déployé des pièges vous a envoyé un message, et demander un flux, vérifier l’existence d’une API ou trouver les données ailleurs est généralement plus rapide, moins coûteux et plus durable que de tenter de déjouer les stratagèmes de quelqu’un qui s’est arrangé pour que vous échouiez.