Autoriser un crawler et le laisser passer sont deux choses différentes. La première se décide dans un fichier texte de trois lignes. La seconde se décide beaucoup plus bas, dans une couche que l'équipe marketing ne voit jamais et que l'équipe sécurité n'a aucune raison de rapprocher d'un enjeu de visibilité.

Pourquoi un crawler IA reçoit-il un 403 alors que le robots.txt l'autorise ?

Parce que le robots.txt et l'infrastructure sont deux portes distinctes, et que seule la seconde décide de l'accès réel. OpenAI documente ce cas sans détour : les services de protection web comme Cloudflare, Akamai et équivalents peuvent classer à tort des crawlers légitimes comme trafic automatisé indésirable, et renvoyer une réponse 403 Forbidden. Les crawlers d'OpenAI ressemblent à du trafic automatisé — c'est ce qu'ils sont — et peuvent donc être refusés à moins d'être explicitement autorisés.

Le robots.txt répond à une seule question : le site déclare-t-il que ce robot est autorisé ? Il ne répond pas à celle qui compte : le robot traverse-t-il réellement l'infrastructure et récupère-t-il la page ?

Un site peut donc afficher User-agent: OAI-SearchBot suivi de Allow: /, passer tous les contrôles d'un audit technique conventionnel, et rester inatteignable.

Quelle différence entre accessibilité déclarée et joignabilité effective ?

L'accessibilité déclarée est ce qu'un site autorise. La joignabilité effective est ce qu'un crawler obtient. La première s'exprime dans le robots.txt, les meta robots et les en-têtes HTTP. La seconde se constate au bout de la chaîne complète : DNS, CDN, pare-feu applicatif, gestion de bots, authentification, défis JavaScript, CAPTCHA, limites de débit, règles géographiques, code de réponse et contenu final réellement rendu.

Un site peut réussir le premier test et échouer au second. Quand c'est le cas, il présente ce que nous appelons un écart de découvrabilité : la page est publique pour un navigateur humain et inexistante pour le système qui va construire la réponse.

Le test qui compte

Lire un fichier ne prouve rien. La vérification utile rejoue le chemin complet : permission déclarée → DNS/CDN → pare-feu et WAF → gestion de bots → couche applicative → code HTTP → contenu final. C'est le seul contrôle qui répond à la question « qu'obtient réellement le crawler ».

Quelles couches bloquent les crawlers IA ?

Sept mécanismes peuvent rendre une page publique inatteignable pour un robot tout en la laissant parfaitement accessible à un humain. OpenAI en identifie explicitement plusieurs dans sa documentation d'accès aux crawlers :

Chacune fonctionne exactement comme elle a été conçue. Une configuration de sécurité peut remplir sa mission à la perfection tout en dégradant l'accessibilité machine sans que personne ne s'en aperçoive.

Pourquoi OAI-AdsBot passe-t-il là où OAI-SearchBot est bloqué ?

Parce que les deux crawlers d'OpenAI n'ont pas le même statut auprès des fournisseurs de protection. OpenAI indique que OAI-AdsBot est officiellement vérifié et mis en liste blanche par Cloudflare. OAI-SearchBot ne bénéficie pas de cette vérification.

Autrement dit : le crawler qui valide les pages de destination publicitaires franchit la porte par défaut chez le plus répandu des fournisseurs de protection. Celui dont dépend la citation dans la recherche organique de ChatGPT doit être autorisé à la main.

Cette asymétrie mérite d'être posée telle quelle. Elle ne relève d'aucune intention malveillante — un crawler commercial contractualisé est simplement plus facile à vérifier qu'un crawler d'indexation générale. Mais sa conséquence est concrète : une entreprise qui achète de la publicité sur ChatGPT verra ses pages validées, pendant que les mêmes pages resteront invisibles au système qui construit les réponses organiques. La visibilité payée traverse, la visibilité méritée reste dehors.

Un crawler autorisé et refusé au pare-feu ne produit aucune alerte. Il ne produit rien du tout, et c'est précisément le problème.

Que signifient un 403 et un 429 pour la visibilité IA ?

Un 403 signifie que le crawler a atteint l'infrastructure et s'est vu refuser l'accès. Un 429 signifie qu'il est passé mais se fait limiter en débit. Dans un monitoring classique, ce sont des anomalies techniques parmi d'autres. Pour la visibilité IA, ce sont les deux signaux qui disent que le premier prérequis échoue.

Les causes d'un 403 sont généralement des règles de WAF, des politiques de pare-feu, un blocage automatique de bots, une restriction d'IP ou une règle géographique. Celles d'un 429 sont des règles de débit, des seuils de protection ou un déclenchement automatique de sécurité.

OpenAI recommande d'examiner les codes de réponse HTTP — en citant nommément le 429 — ainsi que les logs de pare-feu et de CDN, les événements de gestion de bots, les règles de throttling et l'analytique de trafic autour du moment où le crawler a tenté d'accéder. Les logs de bordure deviennent donc un instrument de diagnostic de visibilité IA. Pas parce qu'ils disent si une marque est recommandée. Parce qu'ils disent si elle est seulement candidate.

Être joignable suffit-il à être cité ?

Non. La joignabilité est la première des sept étapes, et la seule que l'on contrôle entièrement. OpenAI le formule d'ailleurs prudemment : autoriser OAI-SearchBot aide à rendre le contenu éligible à la découverte et à l'affichage. Cela ne promet ni inclusion ni position.

La chaîne de visibilité IA de KAIS sépare les étapes précisément pour éviter cette confusion.

La chaîne de visibilité IA — KAIS

Être découvert → être récupéré → être compris → être crédible → être cité → influencer la réponse → être recommandé.

Le blocage par pare-feu se situe entièrement dans la première étape, et il la scinde en deux : l'accessibilité déclarée, puis la joignabilité effective. Tant que la seconde échoue, tout ce qui suit est théorique.

L'intérêt de cette décomposition est qu'elle interdit de traiter un problème par le mauvais remède. Un crawler bloqué par le WAF ne se répare pas en publiant vingt articles. Un problème de pertinence à la récupération ne se répare pas en modifiant des règles de pare-feu. Une corroboration externe insuffisante ne se répare pas avec une FAQ de plus. Chaque étage appelle une intervention différente, et le diagnostic consiste d'abord à savoir lequel a cédé.

Comment vérifier la joignabilité de son site ?

En rejouant le chemin complet avec l'agent utilisateur du crawler concerné, plutôt qu'en lisant un fichier. Huit contrôles suffisent à établir un constat défendable :

  1. confirmer que les crawlers IA visés sont intentionnellement autorisés dans le robots.txt ;
  2. vérifier que la page renvoie un code HTTP de succès à une requête portant l'agent utilisateur du crawler ;
  3. inspecter les règles de CDN et de WAF à la recherche de faux positifs sur le trafic de bots ;
  4. contrôler les défis JavaScript, les CAPTCHA et les exigences d'authentification ou de session ;
  5. relever les événements 403 et 429 autour des requêtes de crawler ;
  6. vérifier les restrictions d'accès géographiques ;
  7. valider le contenu final réellement renvoyé après redirections, sans exécution de JavaScript ;
  8. séparer ce constat d'accès des mesures ultérieures de récupération et de citation.

Le septième point mérite une insistance particulière. Un crawler ne rend pas le JavaScript. Une page dont le contenu principal n'existe qu'après exécution côté client renvoie un 200 parfaitement valide et un corps vide. C'est le cas le plus trompeur de tous : le code de réponse est bon et il n'y a rien à récupérer.

Faut-il affaiblir sa sécurité ?

Non. La réponse n'est pas de retirer la protection, mais de distinguer l'automatisation malveillante du trafic de crawler légitime. Les deux objectifs — bloquer l'automatisation indésirable et laisser passer les robots légitimes vers du contenu public — ne sont pas contradictoires, ils sont simplement portés par deux équipes qui ne se parlent pas.

OpenAI publie les agents utilisateurs de ses crawlers ainsi que les adresses IP de son searchbot, précisément pour permettre une autorisation ciblée. Sa consigne est de vérifier à la fois l'identité du robot et les règles de blocage au niveau de l'infrastructure, au lieu de s'en remettre au seul robots.txt. Google formule la même exigence dans sa documentation sur les fonctionnalités IA : le crawl doit être autorisé dans le robots.txt et par le CDN ou l'hébergement.

La configuration visée est une accessibilité contrôlée : les zones publiques ouvertes aux robots identifiés et vérifiés, les espaces membres, outils internes et tableaux de bord clients fermés. Et l'exception consignée dans la politique de sécurité, pour qu'une mise à jour de routine ne l'efface pas six mois plus tard.

Le point de départ n'est pas celui qu'on croit

La visibilité IA ne commence pas quand un moteur vous cite. Elle commence à la possibilité que votre information entre dans l'environnement de preuves auquel le système a accès. Et à cet endroit précis, une case verte ne suffit pas.

Votre robots.txt peut dire oui. Votre HTML peut dire oui. Votre équipe marketing peut dire que la page est publique. Pendant qu'à la bordure de votre infrastructure, le pare-feu dit non.

Ce n'est pas un problème de contenu. Ce n'est pas un problème d'autorité. Ce n'est même pas un problème de citation. C'est un écart de découvrabilité — et tant qu'il n'est pas refermé, tout le reste est une conversation théorique.

Sources