Pourquoi votre agent IA échoue sur les sites réels

Votre agent fonctionne sur les pages contre lesquelles vous l'avez testé. Puis vous le lâchez sur le web ouvert et les réponses deviennent vagues, ou franchement fausses, ou il annonce que la page était vide alors que vous voyez le contenu dans votre navigateur.

Le réflexe est d'aller retoucher le prompt. En général le prompt va bien. La panne s'est produite avant que le modèle ne voie quoi que ce soit — dans la couche qui récupère une URL et la transforme en texte.

Nous avons mesuré cette couche sur des pages réelles. Voici les cinq façons dont elle casse, avec l'allure exacte de chacune.

1. La page n'a pas de texte tant que JavaScript ne s'exécute pas

atlassian.com/software/jira/pricing, récupérée normalement, ce sont 1,37 Mo de HTML qui produisent un token de contenu lisible. Pas un paragraphe : un token, un saut de ligne.

Les tarifs sont bien là-dedans. Ils sont dans un <script>, sous forme d'état applicatif, en attendant qu'un navigateur construise la page avec.

Récupérez la même URL avec un navigateur headless et cela devient 3 048 tokens qui commencent par :

## **Transparent pricing for every team.**

Même URL. Même jour. Zéro contenu ou la page entière, selon que vous avez exécuté JavaScript ou non.

C'est la panne qui ressemble à un problème de modèle et n'en est pas un. Votre agent a dit « la page ne mentionne pas de tarifs » parce que, dans les octets qu'on lui a donnés, c'était vrai.

2. Mais le rendu n'est pas le correctif que vous espérez

La réponse évidente est de tout rendre. Essayez sur stripe.com/docs :

FetchError: Rendered fetch failed: Navigation timeout of 25000 ms exceeded

Une page qu'une récupération simple renvoie en moins d'une seconde n'a jamais fini de charger dans un navigateur headless en 25 secondes. La version non rendue, avec tous ses défauts, est au moins revenue.

Le rendu vous coûte un processus de navigateur par page, de plusieurs centaines de millisecondes à plusieurs secondes de latence, et une nouvelle classe de pannes : expirations, ressources bloquées, pages qui ne déclenchent jamais load. Si votre agent effectue un rendu par défaut, il est plus lent et moins fiable sur une partie du web, pas plus.

La forme qui marche : récupération économique d'abord, vérifier si vous avez obtenu quelque chose, et n'escalader vers le rendu que pour les pages revenues vides. Cette vérification est justement la partie qu'on oublie.

3. Vous payez pour du balisage que vous n'utilisez jamais

Sur les douze pages connues que nous avons mesurées, la médiane de ce qui survit du serveur au modèle est sous 1%. shopify.com/pricing envoie 410 515 tokens et en produit 2 479.

Si votre agent enfourne du HTML brut dans la fenêtre de contexte, vous payez des <div> d'emballage et du SVG en ligne au prix du token d'entrée, en évinçant les pages que vous vouliez lire aussi. Extrayez avant d'envoyer. Mieux encore : demandez si le site vous donne directement du Markdown. Certains le font déjà — sur les douze pages testées, cinq servaient une représentation Markdown, dont la nôtre.

4. L'extraction garde la mauvaise partie

L'extraction est une heuristique. Elle cherche l'article et écarte le mobilier, et sur des pages qui n'ont pas la forme d'un article, elle devine mal.

stripe.com/docs se réduit à 1 057 caractères qui commencent ainsi :

$ stripe payment_intents create --amount 1099 --currency "usd"

C'est un fragment réel de la page. C'est aussi un exemple de terminal plutôt qu'une phrase décrivant ce que fait Stripe. Un agent à qui l'on ne donne que cela doit déduire le produit d'un échantillon de code.

Donc : ne croyez jamais qu'une extraction réussie soit une extraction utile. Garde-fou économique — si ce que vous avez extrait ne contient pas de texte en forme de phrase, ou fait moins de quelques centaines de caractères sur une page qui en a envoyé un demi-mégaoctet, traitez-le comme une lecture ratée et escaladez, au lieu de le passer au modèle comme un fait.

5. La même URL ne renvoie pas la même page

La récupération simple de shopify.com/pricing a renvoyé de l'anglais. Le rendu de cette URL identique depuis la machine identique a renvoyé de l'espagnol : Pago mensual32 € EUR/mes là où la récupération simple disait Pay monthly€32 EUR/mo.

Rien n'est cassé ici. Le navigateur headless a envoyé des signaux Accept-Language et de géolocalisation différents de ceux de notre récupération simple, et a obtenu une représentation différente et correcte. Mais si vous mettez en cache par URL seule, ou comparez la lecture d'aujourd'hui à celle d'hier, cette différence aura l'air d'un changement de tarifs.

Envoyez un Accept-Language explicite. Indexez votre cache sur ce que vous avez réellement demandé.

La panne qui n'a pas eu lieu

Nous attendions des blocages. Nous avons sondé les douze pages deux fois — une fois en navigateur, une fois en tant qu'OAI-SearchBot — et comparé les codes de statut à travers Cloudflare, Vercel et CloudFront.

Aucune n'a traité le bot différemment. Pas une.

Cela ne veut pas dire que personne ne bloque les agents ; beaucoup le font, et vous devez toujours lire robots.txt et le respecter. Cela veut dire que si votre agent échoue sur un large échantillon du web, le blocage n'en est probablement pas la cause. La pièce vide est bien plus fréquente que la porte fermée.

Une couche de lecture qui survit au contact du web

1. Demander du Markdown d'abord → Accept: text/markdown, ou /page.md
2. Récupération simple          → économique, sans JS
3. Vérifier ce qui est arrivé   → en forme de phrase ? assez long pour les octets envoyés ?
4. Escalader sinon              → rendu, avec expiration et budget
5. Renoncer honnêtement         → « je n'ai pas pu lire cette page »

L'étape 5 compte plus qu'il n'y paraît. Un agent qui signale une page illisible est débogable. Un agent qui tend un saut de ligne au modèle et le laisse improviser, c'est celui qui invente vos tarifs.

La version courte

• La plupart des échecs d'un agent sont des échecs de lecture, pas de raisonnement.
• Vide-sans-JavaScript est de loin le plus fréquent, et le rendu le corrige — à un prix, et pas toujours.
• Vérifiez chaque extraction avant de lui faire confiance.
• Le blocage attire l'attention. C'est le vide qui fait les dégâts.

Vérifier comment une page se lit · Ce qu'un agent voit vraiment · Servir du Markdown aux agents