Un code HTTP est un verdict sur la requête. Ce n'est pas une description de ce qui a été livré.

La distinction paraît scolaire. Elle ne l'est pas. Un serveur qui répond 200 OK affirme une seule chose : il a compris la demande et il n'a rien à y redire. Il ne promet pas d'avoir envoyé la page. Il peut envoyer un défi JavaScript, une coquille vide, une image de chargement, et le code reste 200.

L'article d'hier a mesuré trente hôtes français en relevant les codes de réponse. Il a classé Cdiscount parmi les quatorze hôtes « tout ouverts », sur la foi de six 200. Le 19 septembre 2026, j'ai relancé la même liste avec le même protocole, en ajoutant une seule chose : la lecture du corps.

Cdiscount renvoie bien 200 aux six agents. Le corps contient un mot.

Ce que la SERP « captcha » raconte

Relevé du 19 septembre 2026 sur Google France, langue française.

Le champ sémantique du mur anti-robot est le plus volumineux que ce blog ait visé. « captcha » pèse 12 100 recherches par mois, « recaptcha » 12 100 également, « waf » 4 400, « datadome » 1 900, « hcaptcha » 1 000, « je ne suis pas un robot » 480, « turnstile cloudflare » 320, « cloudflare captcha » 260, « anti bot » 170, « pare feu applicatif » 50, « bot management » 20. Le cumul atteint 32 800.

À titre de comparaison, la famille des codes 5xx traitée le 17 septembre cumulait environ 13 800, et celle du refus d'accès traitée le 18 en cumulait 13 020. Le mur pèse plus que les deux réunies.

La concurrence publicitaire sur « captcha » est à l'indice 0,08, presque le plancher de l'échelle. Deux termes montent fort sur douze mois : « recaptcha » à +83 % et « turnstile cloudflare » à +86 %.

Une précaution de lecture, parce qu'elle a failli me faire écrire une bêtise. « challenge cloudflare » s'affiche à 4 400 recherches par mois. Son historique mensuel tient entre 40 et 210, sauf en novembre 2025 où il monte à 60 500. La moyenne annuelle est donc le souvenir d'un incident, pas un volume. Je l'écarte.

Les huit résultats organiques : Wikipédia, l'aide Google Workspace, Fortinet, Cloudflare, l'agence Boscop sur l'accessibilité des captchas, Nexa Digital School, Malwarebytes sur les fausses arnaques au captcha, et dewi.io sur le choix d'un captcha.

Aucun des huit ne traite de l'indexation, du référencement ou des robots des moteurs. Les huit répondent à la même question, et c'est une question de visiteur : qu'est-ce que c'est, pourquoi ça me tombe dessus, comment je m'en débarrasse.

L'Aperçu IA cite Wikipédia, design.numerique.gouv.fr, Fortinet, l'aide Google Workspace et trois vidéos YouTube, et renvoie vers friendlycaptcha.com dans son corps. Cinq des huit organiques ne sont pas cités du tout : Cloudflare, Boscop, Nexa, Malwarebytes et dewi.io. Deux sources citées ne figurent pas au classement.

Et l'Aperçu se termine par une question posée au lecteur : « Souhaitez-vous savoir comment intégrer un CAPTCHA sur votre site ou comprendre pourquoi on vous bloque avec un message de trafic inhabituel ? »

C'est la troisième fois de suite que l'Aperçu IA d'une requête technique se termine en demandant si l'on parle à un visiteur ou à un exploitant. « Erreur 503 » le 17, « erreur 403 » le 18, « captcha » le 19. Le moteur ne sait pas à qui il s'adresse, parce que le corpus français disponible ne contient que la moitié visiteur.

Le protocole

Trente hôtes français, exactement la même liste que le 18 septembre, et c'est délibéré : réutiliser la liste permet de confronter les deux méthodes sur le même terrain. La liste complète figure en fin d'article.

Six agents utilisateur envoyés sur la page d'accueil :

Chrome 140 (macOS)   TEMOIN : navigateur ordinaire
GPTBot/1.2           collecte d'entrainement, OpenAI
OAI-SearchBot/1.0    recherche, OpenAI
ClaudeBot/1.0        Anthropic
PerplexityBot/1.0    Perplexity
Googlebot/2.1        Google

Pour chaque réponse, je relève le code HTTP final après redirections, la taille en octets, le contenu de la balise title, la présence de signatures de protection anti-robot, et surtout le nombre de mots de texte réellement visible, obtenu en retirant les blocs script, style et noscript, les commentaires, puis toutes les balises.

Ce dernier point mérite qu'on s'y arrête, parce que ma première version du script était fausse. Je comptais les mots après suppression des seules balises, sans retirer les scripts. Sur une page de défi, dont le contenu est du JavaScript minifié sans espaces, ce comptage renvoyait des valeurs trompeuses. Le chiffre publié plus bas vient de la version corrigée.

La règle de classement, énoncée avant d'être appliquée :

page      : texte visible >= 250 mots
mur       : texte < 250 mots ET signature de protection presente
coquille  : texte < 250 mots ET aucune signature
refus     : code 4xx avec un message de refus, sans signature
reseau    : pas de reponse

Le seuil de 250 mots n'est pas choisi au jugé. Sur les cases qui répondent 200, la distribution du texte visible présente un décrochage net : un hôte à 1 mot, un hôte à 4 mots, puis le suivant à 253 et la suite au-dessus de 500. Le seuil tombe dans le vide entre les deux groupes.

Deux passages complets ont été faits. Sur les 180 cases du tableau, 180 sont identiques d'un passage à l'autre, en code comme en verdict. Je reviens plus bas sur ce que cette stabilité ne prouve pas.

Ce que la signature seule ne dit pas

Avant les résultats, un mot sur une erreur que la règle évite de justesse.

Deux hôtes du panel embarquent une brique anti-robot bien visible dans leur code source. doctolib.fr charge Turnstile, la solution de Cloudflare. abondance.com charge reCAPTCHA. Un script qui aurait cherché la signature seule les aurait comptés comme murés.

Ils ne le sont pas. Abondance livre 5 053 mots aux cinq robots, contenu de blog compris. Doctolib en livre 253, avec 99 liens. La brique est là pour garder un formulaire de connexion ou de commentaire, pas pour filtrer l'entrée. La présence d'un captcha dans une page n'est pas un mur ; le mur, c'est quand le captcha remplace la page. D'où la règle en deux conditions.

Doctolib mérite une précision, parce que c'est le cas le plus proche de ma ligne de partage. Ses 253 mots sont sa navigation et son pied de page : le centre d'aide, le plan du site, la liste des spécialités, les mentions de copyright. Le contenu principal de l'accueil, lui, est rendu côté client. Doctolib n'est donc pas muré, mais il n'est pas non plus entièrement livré. Le plancher de ma catégorie « page » est mou, et c'est Doctolib qui s'y appuie.

Le cas Cdiscount : un 200 qui ne contient pas la boutique

Cdiscount répond 200 OK aux six agents, témoin navigateur compris. La réponse pèse environ 14 000 octets. La balise title contient « Cdiscount ».

Le texte visible de ce document, en entier, est le suivant :

Cdiscount

Un mot. Zéro h1, zéro h2, un seul paragraphe, un seul lien, trois scripts. Aucun produit, aucun prix, aucune catégorie.

Ce que contiennent les 14 000 octets, c'est un objet JavaScript :

var __blnChallengeStore = {
  "checkChallengeParams": {
    "request_fate": "challengejs",
    "bot_category": "unknown"
  },
  "cookie": { "name": "visit_baleen_ACM-655d43", ... }
}

Le serveur écrit lui-même le mot : request_fate, le sort réservé à la requête, vaut challengejs. Un défi JavaScript. Le client est prié d'exécuter le script, de résoudre le défi, de récupérer un cookie, et de redemander la page.

J'ai vérifié que ce défi se résout, parce qu'un mur qui ne s'ouvre jamais serait une panne et non un mur. Depuis la même machine et la même adresse de sortie, quelques minutes plus tard, un navigateur qui exécute le JavaScript obtient le titre complet « Cdiscount : des prix bas qui ont de la voix ! », 1 736 mots visibles, 376 liens et 747 619 octets de document. La boutique est là. Elle est simplement derrière une exécution.

Un mot sur ces deux chiffres, parce qu'ils ne sortent pas du même instrument : le 1 mot vient de mon nettoyage du HTML brut, les 1 736 du texte rendu dans le navigateur. Les deux comptent le texte affichable, par deux chemins différents. L'écart est tel que le choix d'instrument ne le produit pas.

Or les robots des moteurs génératifs n'exécutent pas JavaScript. C'est le sujet d'un article de ce blog depuis le 31 juillet, et c'est ce qui rend ce mur particulier : il n'est pas difficile à franchir pour eux, il est infranchissable, et pour une raison qui n'a rien à voir avec une politique éditoriale.

Deux vérifications complètent le tableau.

Le robots.txt de Cdiscount fait 8 269 octets. Il nomme Mediapartners-Google, ia_archiver, AdsBot-Google et le joker *. Il ne nomme aucun robot d'IA : ni GPTBot, ni ClaudeBot, ni PerplexityBot, ni OAI-SearchBot, ni CCBot, ni Google-Extended. Il ne contient aucun Disallow: /. La page d'accueil est donc autorisée à tout le monde, robots d'IA compris, par défaut.

Et le mur ne vise personne en particulier. Trois chaînes d'agent supplémentaires, une chaîne inventée Wgzptmv/9.9, un Chrome ordinaire, et un Chrome auquel on colle ClaudeBot/1.0 à la fin, reçoivent toutes les trois le même document à un mot. Aucune décision n'a été prise contre les moteurs d'IA sur cet hôte. Le fichier les autorise, et l'infrastructure les arrête quand même.

Le croisement code par corps

Le tableau des 180 cases, croisé sur les deux axes :

code    corps          cases
-----------------------------
200  +  page            100
403  +  refus            43
403  +  mur              20
200  +  mur               6
200  +  coquille          6
000  +  echec reseau      5
-----------------------------
TOTAL                   180

Cent douze cases répondent 200. Douze d'entre elles, soit 11 %, ne contiennent aucune page lisible. Six sont le mur de Cdiscount. Les six autres relèvent d'un mécanisme entièrement différent, et c'est la seconde surprise du relevé.

Le cas France Travail : ouvert, et vide

francetravail.fr répond 200 aux six agents. La réponse pèse environ 23 000 octets. Le texte visible, en entier :

Accueil | France Travail

Quatre mots, et ce sont ceux de la balise title. Zéro h1, zéro h2, zéro paragraphe, zéro lien, quatre scripts. Un robot qui arrive sur cette page n'y trouve rien à lire et, faute de lien, aucune direction où aller.

Aucune signature de protection n'est présente. Rien ne bloque quoi que ce soit. La page d'accueil du service public de l'emploi est simplement rendue côté client : le serveur envoie une coquille, le navigateur la remplit. Contrôle au navigateur, même machine, même minute : 1 h1, 9 h2, 37 liens, 840 mots.

Les deux cas sont opposés dans leur intention et identiques dans leur effet. Cdiscount se protège et livre un mot. France Travail ne se protège de rien et en livre quatre. Du point de vue du moteur, les deux réponses sont le même événement : un 200, un titre, et rien derrière.

C'est ce qui rend le code de réponse trompeur au-delà du seul sujet des captchas. Une supervision d'exploitation qui vérifie « le site répond-il 200 » voit vert sur les deux. Une supervision un peu plus fine, qui cherche en plus un mot attendu dans la page, voit vert aussi : « Cdiscount » est bien dans le titre du mur, « France Travail » est bien dans celui de la coquille.

Trois murs qui ne fonctionnent pas de la même façon

Parmi les hôtes qui traitent un robot autrement qu'un navigateur, trois mécanismes distincts apparaissent.

leboncoin.fr filtre sur le nom. Le témoin navigateur reçoit 999 mots. Les cinq robots reçoivent un 403 servi par DataDome, soit 9 mots. Le banc d'essai tranche : la chaîne inventée Wgzptmv/9.9 est refusée elle aussi, et la chaîne Chrome bascule de 200 à 403 dès qu'on lui ajoute ClaudeBot/1.0. L'hôte tient donc une liste de navigateurs admis et réagit au nom du robot.

seloger.com empile trois mécanismes sur une seule page d'accueil. Le navigateur passe, OAI-SearchBot passe, GPTBot reçoit un refus de CloudFront (« ERROR: The request could not be satisfied »), et ClaudeBot, PerplexityBot et Googlebot reçoivent un 403 DataDome. Au banc d'essai, la chaîne inventée passe sans encombre, ce qui écarte la liste blanche, et l'ajout de ClaudeBot/1.0 à la chaîne Chrome suffit à la faire basculer.

laredoute.fr fait l'inverse de tout le monde. Les cinq robots reçoivent la page. C'est le navigateur qui est muré, avec une page qui présente le blocage comme un incident : « Oups… petit bug technique. Désolé pour ce désagrément. » Le motif réel est imprimé plus bas dans la même page : Error reason : WAF Block/IP Block/Rate limiting. Le pare-feu applicatif a classé ma connexion, pas mon agent.

À côté de ces trois, deux hôtes murent tout le monde, témoin navigateur, chaîne inventée et robots confondus : decathlon.fr, avec l'interstitiel « Just a moment… » de Cloudflare, et Cdiscount déjà traité. Pour Decathlon, je n'en conclus rien sur les robots : quand un serveur refuse identiquement un navigateur ordinaire et une chaîne inventée, le filtrage porte sur ma sortie réseau. C'est le rôle du témoin que de le sortir de l'analyse.

Deux refus ciblés du relevé d'hier se confirment sur le corps. ameli.fr écarte ClaudeBot seul, et sert 647 mots aux cinq autres agents. doctolib.fr écarte Googlebot seul, et sert aux cinq autres les 253 mots de navigation décrits plus haut, ce qui confirme le refus ciblé sans rien changer au fait que le contenu principal, lui, reste derrière une exécution.

Ce que deux passages identiques ne prouvent pas

Voici le résultat le plus utile du relevé, et c'est un résultat négatif.

Sur les deux passages complets, liberation.fr affiche un motif net et parfaitement reproductible : OAI-SearchBot reçoit la page, 4 142 mots, et les cinq autres agents, témoin navigateur compris, reçoivent un mur DataDome de 9 mots. Deux passages, deux fois le même tableau. Selon le critère de stabilité que j'ai utilisé hier, la conclusion s'écrivait toute seule : cet hôte laisse entrer le robot de recherche d'OpenAI et refuse les autres.

Quarante minutes plus tard, j'ai voulu vérifier ce cas isolément. Six requêtes consécutives avec OAI-SearchBot, dont deux précédées d'une pause de deux et de trois minutes, reçoivent toutes un 403. Le même agent, la même machine, la même URL.

Le motif n'était donc pas une règle sur l'agent. Sur le mécanisme réel, je ne me prononce pas : OAI-SearchBot occupait la troisième position de ma boucle à chaque passage, derrière deux agents déjà refusés, ce qui exclut l'explication la plus simple d'un quota qui se viderait au fil du relevé. Ce que le relevé établit, c'est que l'agent n'explique pas le résultat.

La leçon dépasse cet hôte. Deux passages qui concordent prouvent qu'une mesure est reproductible dans une fenêtre de temps, pas que la règle observée porte sur ce qu'on croit. Le relevé d'hier annonçait 209 cases stables sur 210 et en tirait des conclusions par agent. Cette stabilité-là était réelle ; elle ne suffisait pas. Un mur à état peut se présenter deux fois de suite sous le même visage.

liberation.fr sort donc de l'analyse, classé non conclusif.

Ce que cet article n'établit pas

Cinq réserves, et elles comptent.

Le relevé part d'une seule adresse de sortie, en France, depuis une machine de bureau. Les robots réels arrivent depuis des plages d'adresses déclarées par leurs éditeurs, que certains pare-feux reconnaissent. Un hôte qui me refuse peut parfaitement accepter le vrai GPTBot.

Le relevé porte sur des pages d'accueil. Rien ne garantit qu'une fiche produit ou un article se comporte comme la racine du site.

Le relevé mesure ce que le serveur renvoie. Il ne mesure pas ce que le moteur en fait ensuite : ni les nouvelles tentatives, ni un éventuel rendu différé, ni le contenu déjà présent dans l'index. Un site muré aujourd'hui peut rester cité pendant des mois sur la foi d'un passage antérieur.

Deux hôtes sont écartés faute de témoin exploitable, decathlon.fr et liberation.fr, et un troisième, urssaf.fr, n'a pas répondu aux cinq robots alors que le navigateur passait, ce que je classe en échec réseau sans l'interpréter.

Le seuil de 250 mots vient d'un décrochage observé dans ce corpus. Ce n'est pas une constante.

Ce qu'il faut retenir

Le code de réponse est un accusé de réception, pas un bon de livraison. Sur 112 cases qui répondent 200 dans ce relevé, 12 ne contiennent aucune page lisible.

Deux chemins mènent à ce 200 creux, et ils n'ont rien en commun. Le premier est le mur de vérification : Cdiscount renvoie un document dont le texte entier est le mot « Cdiscount », avec un défi JavaScript dans le corps, alors que son robots.txt n'interdit rien à personne et ne nomme aucun robot d'IA. Le second est la coquille rendue côté client : France Travail renvoie un document dont le texte entier est son propre titre, sans qu'aucune protection ne soit en cause, et sans un seul lien.

Les murs qui ciblent ne ciblent pas tous pareil. leboncoin.fr tient une liste de navigateurs admis et réagit au nom du robot, seloger.com empile trois mécanismes sur une seule page, laredoute.fr mure le navigateur et laisse passer les robots en présentant le blocage comme un bug.

Et une règle de méthode, valable au-delà de ce sujet : deux relevés concordants ne suffisent pas à établir qu'une protection réagit à l'agent. Il faut rejouer le cas isolément, à distance du relevé. Sans cette vérification, j'aurais publié que Libération ouvre sa porte à OpenAI. C'est faux.

La conséquence pratique tient en une ligne. Vérifier qu'une page répond ne vous apprend rien. Comptez les mots que le serveur renvoie réellement à un client qui n'exécute pas JavaScript, et comparez-les à ce que voit votre navigateur. L'écart est votre visibilité générative.

Les trente hôtes du relevé

lemonde.fr          lefigaro.fr       liberation.fr
lesechos.fr         francetvinfo.fr   ouest-france.fr
cdiscount.com       fnac.com          darty.com
laredoute.fr        decathlon.fr      sephora.fr
boursorama.com      qonto.com         creditmutuel.fr
axa.fr              maif.fr           ameli.fr
service-public.fr   impots.gouv.fr    francetravail.fr
urssaf.fr           doctolib.fr       seloger.com
leboncoin.fr        blablacar.fr      payfit.com
swile.co            ovhcloud.com      abondance.com

Chez Orbite, nous mesurons ce que vos serveurs livrent réellement aux robots des moteurs génératifs : le code, mais surtout le corps, agent par agent, avec un témoin navigateur en regard. Si vous voulez savoir combien de mots les vôtres renvoient : parlons de votre visibilité générative. Les termes employés ici sont définis dans le glossaire GEO.

Pour la suite de ce cluster : les codes 5xx et l'indisponibilité temporaire, le refus d'accès en 403, les Core Web Vitals vus par les moteurs génératifs, ce que votre robots.txt autorise vraiment, les logs serveur comme preuve de passage et la page 404 face aux moteurs.