20% de toutes les réponses web « OK » obtenues par l’IA ne sont pas correctes

Mes récentes expériences de collecte de données sur le Web assistée par l’IA m’ont fait prendre la mesure de l’ampleur croissante du verrouillage du Web. Cette restriction est bien sûr motivée par la croissance fulgurante de la collecte de données sur le Web par l’IA, dont la demande insatiable de nouvelles données peut finir par mettre des domaines hors ligne.

C’est une bonne raison pour les domaines de faire ce que beaucoup souhaitent depuis longtemps : réserver l’accès à leur contenu aux utilisateurs connectés (même si, naturellement, Googlebot bénéficie généralement d’un passe-droit). Facebook a achevé l’adoption progressive de cette politique en 2023, et Twitter/X a fait de même la même année. Reddit l’adoptera plus tard ce mois-ci.

De cette façon, il est un peu plus facile pour le domaine de se conformer aux règles de restriction d’âge propres à chaque pays, puisque l’utilisateur est déjà inscrit. Plus important encore, les données de l’utilisateur peuvent être enregistrées, exploitées à des fins d’analyse locale et — si la législation locale le permet — vendues à des courtiers en données et à des entreprises spécialisées dans l’IA.

Ailleurs, les mesures visant directement à se protéger des robots (plutôt qu’à inscrire les utilisateurs) ont augmenté de plus de 58 % sur un an, selon Cloudflare ; et cette activité croissante des robots incite naturellement les sites Web à examiner de près les adresses VPN et de serveurs mandataires, au risque de refuser l’accès à des utilisateurs légitimes, en même temps qu’au trafic « malveillant ».

Sur le plan anecdotique, il me semble rencontrer de plus en plus souvent des réponses de « blocage » ou des défis, au point que je pourrais même abandonner un site qui commence à les afficher ; et puisque l’on a constaté que les murs de CAPTCHA font fuir les utilisateurs et les clients potentiels, on peut imaginer la pression qui pousse les propriétaires de domaines à les adopter malgré cet inconvénient.

Un CAPTCHA d’archive.is, l’un des nombreux sites qui ont adopté des défis, souvent en réaction à un nombre excessif de requêtes automatisées (plutôt qu’humaines).

Toutes ces nouvelles frictions, et leur intensification, s’expliquent en partie par des contraintes logistiques (car tous les domaines ne peuvent pas résister à l’assaut), mais elles constituent aussi souvent une sorte de tactique de négociation visant à déterminer si les entreprises spécialisées dans l’IA proposeront une rémunération unique ou collective pour toutes ces données qu’elles convoitent tant et qui, jusqu’à présent, ont toujours été gratuites.

Comme les robots d’exploration de l’IA doivent fonctionner à grande échelle, ils utilisent généralement des instances de Chrome sans interface graphique avec le framework Playwright. De nos jours, sur un nombre croissant de domaines, cela vous vaudra une erreur 403 (« interdit ») (autrement dit, l’hôte sait que vous générez du trafic automatisé et vous dit de déguerpir) :

Une installation locale de changedetection.io tente d’interroger un site, mais celui-ci n’apprécie pas le navigateur détecté qu’utilise le framework et renvoie une réponse 403 (« Forbidden », c’est-à-dire « interdit »).

Ce que l’on veut, c’est la réponse client « 200 » (« OK »), quitte à verser une grosse somme à une ferme de serveurs mandataires résidentiels, en recourant aussi à diverses autres astuces sournoises non humaines pour l’obtenir.

Rien ne vaut la réponse 200 ; autrement dit, aucun code de réponse client n’indique un niveau de réussite supérieur. Ce n’est pas non plus une réponse ambiguë : elle ne signifie jamais « presque correct », « ce sera correct plus tard » ou « de plus en plus correct » ; elle signifie « correct ! ». Si ce n’est pas correct, ce n’est pas une réponse 200.

Bonjour ! Passez votre chemin

Or, selon un nouvel article, ce manque de granularité pourrait fausser considérablement les jeux de données d’IA, les estimations statistiques et les rapports indiquant un état « satisfaisant » alors que ce n’est pas le cas.

L’étude* estime qu’environ un cinquième des réponses de la catégorie 200 ne contiennent aucun contenu de page exploitable, mais affichent plutôt des coquilles de sites Web vides, des défis CAPTCHA, des restrictions d’accès ou des pages de substitution.

L’article indique :

« 20,9 % des pages qu’un client statique reçoit avec le statut 200 ne contiennent pas le contenu principal de la page : coquilles d’application, défis anti-robots, pages de blocage, pages d’erreur et pages de remplacement, ainsi que contenu partiel. »

À cet égard, les systèmes automatisés impatients sont piégés par leur propre manque de discernement, puisque la réponse « 200 » peut être assimilée à une récupération réussie, même lorsque celle-ci ne produit qu’un mur de CAPTCHA, un péage d’accès ou un autre obstacle.

L’article décrit les sept types de contenu qui compliquent fréquemment une réponse 200 :

Les sept catégories de contenu qui n’ont rien de « correct » dans une réponse 200. Source

Pendant trois jours, l’étude a testé 10 307 adresses Web à l’aide d’un programme de récupération Web de base et d’un navigateur capable de charger JavaScript. Les réponses ont été classées en fonction du contenu récupéré, et non de leur code d’état HTTP.

Les catégories les plus importantes de réponses 202 « inutilisables » étaient les coquilles de sites Web vides et les pages d’erreur ou de substitution, qui représentaient ensemble plus des deux tiers des échecs.

Dans le cas des coquilles de sites vides, un site Web peut afficher ses menus et sa navigation tout en laissant vide l’article ou la liste de produits demandés ; dans ce dernier cas, une page sans rapport avec la demande ou la page d’accueil peut s’afficher à la place du contenu recherché. Pourtant, ces deux cas peuvent recevoir le même code d’état HTTP 200 qu’une récupération réussie fournissant un contenu exploitable et utile.

Pour remédier au problème, l’article recommande que les outils de récupération Web indiquent ce qui a réellement été récupéré, plutôt que de se fier aux codes d’état HTTP, car de simples vérifications visant à repérer les pages anormalement courtes, les redirections suspectes et les contenus ressemblant à des pages inexistantes pourraient détecter la plupart des échecs.

Des outils de navigation plus gourmands en ressources pourraient alors être utilisés uniquement lorsqu’une page semble ne pas s’être chargée correctement. En outre, les évaluations de l’IA pourraient vérifier si les sources citées contiennent effectivement les informations attendues, au lieu de supposer qu’une réponse HTTP 200 signifie que le contenu a bien été récupéré.

L’auteur de la nouvelle étude note également que des « heuristiques peu coûteuses » permettent de repérer facilement environ 86 % des réponses inutilisables, au moyen de vérifications élémentaires de la longueur des pages, des redirections et des similitudes avec des pages inexistantes :

Comparaison des stratégies de récupération Web : le rendu des seules pages signalées comme suspectes a permis de récupérer un peu plus de contenu exploitable (81,4 %) que le rendu de toutes les pages (80,3 %), tout en réduisant le temps moyen de récupération de 20,6 à 5,8 secondes par page. 

Pourquoi autant de réponses 200 erronées ?

Depuis plusieurs années, les communautés de développeurs débattent de la question de savoir si l’erreur 202 (« Acceptée ») (« Requête acceptée, mais pas encore exécutée ») pourrait permettre de distinguer ces requêtes ayant échoué malgré un statut 200. Mais, en réalité, le code 202 ne peut pas couvrir tous les cas décrits dans le nouvel article, et aucun code existant ne le peut.

Bien que l’article n’examine pas la question en profondeur, les raisons pour lesquelles les propriétaires de domaines autorisent les erreurs 200 mériteraient peut-être d’être étudiées plus avant dans de futurs travaux connexes.

L’une des raisons pourrait être que tout statut autre que 200 correspond essentiellement à une forme de page d’erreur ou d’obstacle, notamment les erreurs 404 (« introuvable »), les plus courantes, qui indiquent simplement que le contenu recherché est absent. Certains pensent qu’un trop grand nombre de ces erreurs entraînera des pénalités en SEO (et, sans doute, en GEO), mais Google le dément.

En fait, Google considère les erreurs 200 comme des erreurs 404 « masquées », et elles sont clairement susceptibles d’être jugées plus problématiques que de simples erreurs 404, car il s’agit essentiellement de résultats « trompeurs », intentionnels ou non.

Dérive des citations

Si tout cela semble relever du pinaillage, il faut tenir compte de l’échelle, de l’ordre du pétaoctet, des données qui sont régulièrement collectées (ou dont on tente la collecte) à des fins d’entraînement de l’IA. Si un cinquième de ces données est peu fiable, voire carrément trompeur, il est difficile de balayer d’un revers de main les conséquences en aval en les qualifiant d’« imprécisions collatérales ». De telles réponses erronées pourraient plutôt nuire considérablement à la répartition des données dans les jeux de données ainsi qu’aux résultats de l’entraînement de modèles d’IA à partir de ces données.

Par exemple, un problème notable lié aux réponses 200 erronées concerne la « dérive des citations » : une réponse générée par l’IA n’est alors plus étayée par la page Web initialement citée comme preuve. Autrement dit, la page a pu être modifiée, le texte pertinent supprimé ou le lien redirigé vers un autre emplacement.

La nouvelle étude a constaté que la dérive apparente des citations passait de 5,8 % à 21,9 % lorsque toutes les réponses HTTP 200 étaient considérées comme des récupérations réussies, quel que soit leur contenu.

Cela signifie qu’une source pourrait être considérée à tort comme ayant changé, disparu ou cessé d’étayer une affirmation générée par l’IA, simplement parce qu’un CAPTCHA, une page vide ou un autre obstacle a été récupéré à la place du contenu d’origine.

Il suffit de dire que tout va bien !

Le problème a également été mis en évidence par des tests portant sur des adresses Web délibérément inexistantes. Lorsque des chemins aléatoires et inventés étaient demandés à des sites Web, 13,1 % de ceux qui ont répondu renvoyaient un statut 200 (« OK »), alors même que les pages demandées n’existaient pas^†.

« 13,1 % des sites ayant répondu à la requête avec un chemin aléatoire ont renvoyé un statut 200 (S1 : 10,5 %, S2 : 13,3 %, S3 : 17,3 %, S4 : 13,7 %, S5 : 13,1 %). Par définition, chacune de ces réponses est une erreur 404 masquée, mais toutes ne le signalent pas. »

« Dans une analyse exploratoire des 172 réponses de type 404 fantôme, l’annotateur a qualifié 98 d’erreurs ou de pages de remplacement, 32 de coquilles et 28 de contenus : une page d’accueil ou une liste affichée à un chemin aléatoire ressemble à une page normale. »

Conclusion

Si le problème était reconnu à un niveau supérieur, l’IANA pourrait éventuellement créer un nouveau code d’état HTTP plus approprié, par exemple [X] (« La requête a abouti, mais le contenu demandé n’a pas été fourni »). Cela décrirait effectivement ce qui se passe, mais exigerait naturellement de l’hôte une compréhension de la transaction d’une profondeur peu probable.

Des codes similaires existent déjà, mais aucun ne convient vraiment : 451 (« Indisponible pour des raisons juridiques ») est ambigu et plutôt alarmant (!) ; 206 (« Contenu partiel ») est techniquement adapté, mais destiné aux données incomplètes (récupérations) ; et le surprenant 203 (« Informations non définitives »), qui a été créé en 1997, ne concerne que de loin le cas d’usage en question.

Le candidat le plus proche est peut-être en réalité le code 103, au nom peu intuitif (« Indications préliminaires »), qui indique que toutes les ressources de l’URL ne sont pas encore chargées (même si ce serait clairement une interprétation abusive de l’intention du code).

* Intitulé « Quand 200 OK ne suffit pas : échecs silencieux de récupération de contenu Web par des agents ». Veuillez noter que l’article semble avoir été rédigé avant tout pour être lisible par une machine, peut-être en vue d’être interrogé par une IA, et qu’il n’est pas facile à lire en soi.

^† Je vous prie de m’excuser pour cette citation mécaniste, mais l’article entier est rédigé ainsi, comme je le signale plus haut, pour être « lisible par une machine » plutôt que compréhensible par un humain, sans toutefois être présenté au format JSON.

Première publication le mercredi 4 novembre 2026