Comment les IA lisent le web : tokens, troncature et limites cachées

Vous pensez que ChatGPT, Claude ou Gemini « lisent » vos pages web comme vous le faites ? Détrompez-vous. Aucune IA ne voit l’intégralité d’une page dépassant un certain seuil, et ce seuil est bien plus bas que vous ne l’imaginez. Voici ce que j’ai découvert en construisant un endpoint JSON pour mon blog, et pourquoi chaque éditeur de site devrait s’en préoccuper.

Le token : l’unité de mesure que personne ne vous explique

Quand vous lisez une page web, vous voyez des mots, des paragraphes, des images. Quand une IA lit cette même page, elle voit des tokens, des fragments de texte découpés par un algorithme appelé tokenizer.

Un token n’est ni un mot, ni un caractère, ni un octet. C’est une unité de découpage propre à chaque famille de modèles. GPT utilise tiktoken, Claude a le sien, Mistral un autre, Gemini encore un autre. Chacun découpe différemment le même texte. Ce sont ces mêmes tokens qui posent la question du blanchiment du droit d’auteur par les LLM : l’œuvre originale est atomisée en fragments que le modèle recombine sans attribution.

En pratique, pour du texte occidental :

• 1 token ≈ 4 caractères en anglais
• 1 token ≈ 3 caractères en français (les accents, les mots plus longs et les caractères spéciaux coûtent plus cher)
• 1 token ≈ 3-4 octets pour du JSON avec clés ASCII et valeurs UTF-8

Concrètement : ce paragraphe que vous lisez en deux secondes représente environ 80 tokens pour Claude, peut-être 85 pour GPT-4o, et 78 pour Gemini. Le même texte, trois décomptes différents.

Ce que ça signifie pour un éditeur de site : quand une IA annonce une « fenêtre de contexte de 200 000 tokens », ça correspond à environ 600 000 caractères en français, soit l’équivalent d’un roman de 400 pages. C’est la mémoire de travail totale du modèle, pas ce qu’il peut ingérer depuis votre site en une seule requête.

Comment une IA accède à votre contenu : trois méthodes, un même goulot

1. Le fetch brut (HTTP)

La méthode la plus courante. L’IA envoie une requête HTTP à votre URL et récupère le contenu brut, exactement comme curl ou wget. Claude utilise un outil appelé web_fetch, GPT son module de « browsing », Perplexity son moteur de recherche augmenté.

Le problème : chaque plateforme impose un plafond de tokens par appel, au-delà duquel le contenu est silencieusement tronqué. Pas d’avertissement, pas de message d’erreur, l’IA travaille simplement avec un contenu incomplet, sans le savoir et sans vous le dire. Et la troncature n’est que la face passive du problème : les LLM ont aussi des vulnérabilités actives bien documentées (injection de prompts, empoisonnement de mémoire, exfiltration de données) qui exploitent précisément cette ingestion aveugle de contenu web.

2. Le crawl de recherche

Quand vous posez une question à Perplexity ou que vous demandez à Claude de chercher sur le web, l’IA lance d’abord une recherche, puis fetch les pages des résultats. Chaque page fetchée est soumise au même plafond de troncature. Si votre article fait 80 000 tokens en HTML, l’IA n’en verra que les 40 à 60% premiers : typiquement le header, la navigation, et le début de votre contenu.

3. Le navigateur piloté (MCP)

C’est la méthode la plus récente et la moins répandue. Certaines implémentations, comme « Claude in Chrome » chez Anthropic ou le projet Mariner de Google, pilotent un vrai navigateur Chromium. L’IA n’accède plus au HTML brut mais à l’arbre d’accessibilité de la page (j’y reviens en détail plus bas). Cette approche permet de contourner la troncature en lisant la page par morceaux, mais elle est beaucoup plus lente et coûteuse en ressources.

Les plafonds réels : ce que chaque IA voit de votre page

Voici l’état des lieux en février 2026, tel que je l’ai observé ou documenté. Pour le contexte, j’utilise quotidiennement plusieurs de ces IA en parallèle, c’est cette pratique qui m’a confronté aux limites décrites ci-dessous :

Claude (Anthropic)

• Fenêtre de contexte : 200 000 tokens (Opus 4.6)
• Plafond web_fetch : ~50 000 tokens par appel
• Upload fichier : limité par la fenêtre de contexte globale (pas de troncature pour un fichier raisonnable)
• Navigateur Chrome (MCP) : pas de plafond fixe, lecture par morceaux via l’arbre d’accessibilité

La distinction est cruciale : le même fichier JSON de 345 Ko (~86 000 tokens) est tronqué via web_fetch mais passe intégralement en upload direct. Même modèle, même session, même fenêtre de contexte : seul le canal d’entrée change.

GPT-4o / GPT-4.1 (OpenAI)

• Fenêtre de contexte : 128 000 tokens (GPT-4o) à 1 000 000 tokens (GPT-4.1)
• Plafond browsing : non documenté officiellement. Les retours terrain indiquent une troncature variable, souvent entre 30 000 et 60 000 tokens selon le modèle, le type de contenu et le tier d’abonnement. OpenAI a modifié ces seuils plusieurs fois sans communication.
• Upload fichier : jusqu’à 512 Mo par fichier, avec un plafond annoncé de ~2 millions de tokens par fichier texte

Gemini 2.5 Pro / 3 Pro (Google)

• Fenêtre de contexte : 1 000 000 tokens (2.5 Pro et 3 Pro)
• Plafond fetch : mal documenté. Les rapports de bugs sur GitHub montrent des troncatures prématurées à 90 000-130 000 tokens, parfois dues à des erreurs de comptage dans les implémentations tierces. La fenêtre géante ne garantit pas que chaque page soit ingérée en entier.
• Upload fichier : jusqu’à 20 Mo par requête, PDFs traités comme images (une page = une image)

Perplexity

• Fonctionnement : ne donne pas accès au contenu brut des pages. Le moteur fetch les résultats de recherche, les découpe en « chunks », et ne présente que les passages pertinents. L’utilisateur ne voit jamais le contenu intégral.
• Budget tokens : partagé entre le prompt utilisateur, les passages récupérés, les instructions système et la réponse générée. Un article long sera résumé agressivement.
• Max Tokens/Page : 3 000 à 4 000 tokens par résultat de recherche selon le preset utilisé

Grok (xAI)

• Fenêtre de contexte : 131 072 tokens (Grok 3)
• Plafond fetch : non documenté publiquement. Comportement similaire aux autres : troncature silencieuse au-delà d’un seuil interne.

Le vrai scandale : le HTML est un gouffre à tokens

Voici où le problème se corse pour les éditeurs de sites. Quand une IA fetch votre page web, elle ne récupère pas votre article : elle récupère votre HTML complet : navigation, header, footer, sidebar, classes CSS, attributs data-*, balisage schema.org, scripts inline, widgets, commentaires.

Sur un blog WordPress typique, le contenu utile représente 20 à 30% du HTML total. Le reste, c’est du bruit structurel qui dévore des tokens pour rien. Même les architectures WordPress Headless, censées séparer le contenu du rendu, n’éliminent pas ce problème si l’IA fetch la page finale plutôt que l’API.

Prenons un exemple concret sur mon propre blog :

Pour un article de 5 000 tokens utiles, l’IA consomme 15 500 tokens de budget. Sur une page plus lourde (un e-commerce avec des produits, des avis, des recommandations), le ratio peut tomber à 10% de contenu utile.

Multipliez ça par un plafond de troncature à 50 000 tokens, et vous comprenez pourquoi l’IA ne voit souvent que le début de vos articles longs.

L’arbre d’accessibilité : quand le handicap éclaire l’IA

Il existe une façon radicalement différente de lire une page web. Tous les navigateurs modernes construisent en parallèle du rendu visuel un arbre d’accessibilité, une représentation structurée de la page destinée aux technologies d’assistance pour les personnes en situation de handicap.

Cet arbre est la colonne vertébrale de la navigation web pour les aveugles et malvoyants. Sans lui, les lecteurs d’écran comme JAWS, NVDA ou VoiceOver ne pourraient pas fonctionner. Chaque élément de la page y est réduit à sa sémantique pure : son rôle (bouton, lien, titre, paragraphe), son nom, et son état.

Là où le HTML ressemble à ça :

<div class="post-entry flex flex-col gap-4 border-b pb-6">
  <h2 class="entry-title font-bold text-xl mt-4 text-gray-900 hover:text-blue-600 transition-colors">
    <a href="/mistral-ai-rachat-koyeb/" rel="bookmark" class="no-underline">
      Mistral rachète Koyeb : la mue vers l&#8217;empire cloud
    </a>
  </h2>
  <p class="excerpt text-gray-600 mt-2 leading-relaxed">Trois jours après mon billet sur le virage infrastructure...</p>
</div>
Langage du code : HTML, XML (xml)

L’arbre d’accessibilité ne retient que :

heading "Mistral rachète Koyeb : la mue vers l'empire cloud" (level 2)
  link "Mistral rachète Koyeb : la mue vers l'empire cloud"
    url: /mistral-ai-rachat-koyeb/
paragraph "Trois jours après mon billet sur le virage infrastructure..."
Langage du code : JavaScript (javascript)

Toute la graisse (classes Tailwind, attributs de style, div de mise en page, transitions CSS) a disparu. Il ne reste que ce qu’un lecteur d’écran (ou un agent IA en mode navigateur) a besoin de percevoir.

Qui utilise l’arbre d’accessibilité ?

• Claude in Chrome (Anthropic) : en beta, pilote un vrai navigateur via le protocole MCP et lit l’arbre par morceaux : pas de troncature brutale
• Project Mariner (Google) : un agent Gemini qui pilote Chrome, pas encore largement déployé
• Tous les autres : fetch brut avec troncature

C’est une passerelle inattendue entre deux mondes : l’accessibilité web, pensée depuis les années 2000 pour les personnes handicapées, devient un avantage technique pour les agents IA qui cherchent à lire le web de façon plus intelligente.

Comment le voir vous-même

Dans Chrome : F12 → onglet Elements → menu ⋮ → « Full-page accessibility tree ». Firefox a son propre inspecteur d’accessibilité dans les DevTools. Safari nécessite l’outil Accessibility Inspector de Xcode, beaucoup moins pratique.

Le webmaster a la main sur l’arbre

La génération de l’arbre est automatique (le navigateur le construit à partir de votre HTML), mais sa qualité dépend entièrement de la façon dont vous écrivez votre code.

Un <button>Envoyer</button> génère un nœud « button » avec le nom « Envoyer » : un lecteur d’écran sait que c’est cliquable. Un <div class="btn" onclick="submit()"> génère un nœud générique sans rôle : le lecteur d’écran ne sait pas que c’est un bouton. L’arbre reflète votre sémantique, pas votre CSS.

Vous pouvez aussi intervenir directement via les attributs ARIA (aria-label, aria-hidden, role) pour corriger ou enrichir l’arbre quand le HTML seul ne suffit pas. Un aria-hidden="true" sur votre navigation la masque de l’arbre : un lecteur d’écran ne la verra plus, et un agent IA qui lirait l’arbre non plus.

Attention cependant à ne pas généraliser. Aujourd’hui, seul Claude in Chrome (en beta) et le projet Mariner de Google (non déployé largement) utilisent l’arbre d’accessibilité pour lire les pages. Toutes les autres IA (GPT, Grok, Perplexity) font du fetch HTTP brut et ne touchent jamais à cet arbre. Soigner votre HTML sémantique pour les IA via l’arbre d’accessibilité est donc un investissement pour l’avenir, pas un bénéfice immédiat sur l’ensemble des plateformes.

Ce qui est vrai dès maintenant et pour toutes les IA : un HTML sémantique propre (<article>, <h2>, <p> plutôt qu’une soupe de <div>) produit un contenu textuel mieux structuré même en fetch brut. Le bénéfice est indirect, mais réel.

L’absence criante d’un standard d’orientation

Quand Google visite votre site, il consulte votre robots.txt, lit votre sitemap.xml, détecte vos balises <link rel="canonical"> et <link rel="alternate">. En trente ans, tout un écosystème de signaux a été construit pour guider les moteurs de recherche vers le bon contenu, au bon format, dans la bonne langue.

Pour les IA ? Rien.

Il n’existe aujourd’hui aucun mécanisme universel et adopté pour dire à une IA : « ne lis pas cette page HTML de 80 000 tokens, va plutôt chercher cette version JSON de 5 000 tokens qui contient la même information sans le bruit ». Pas de balise, pas de header HTTP, pas de fichier de convention à la racine du site.

Votre serveur ne peut pas distinguer un fetch de Claude d’un fetch de curl. Et même s’il le pouvait (via le User-Agent), aucune IA ne cherche de version alternative avant d’ingérer votre HTML brut. Elle prend ce qui vient, tronque si nécessaire, et travaille avec le résultat.

C’est un vide sidérant dans l’écosystème. Les éditeurs d’IA (Anthropic, OpenAI, Google) n’ont aucune incitation à combler ce vide : un appel réseau supplémentaire par page visitée pour chercher un hypothétique fichier de redirection, ça coûte de la latence, et leur priorité est la rapidité de réponse à leurs utilisateurs, pas le confort des éditeurs de contenu.

En attendant qu’un standard émerge (si tant est qu’il émerge un jour), le créateur de contenu n’a que deux options : rendre son HTML suffisamment léger pour être ingéré correctement, ou fournir manuellement l’URL de son endpoint optimisé quand il travaille avec une IA. La souveraineté éditoriale face aux IA, pour l’instant, ne se délègue à aucun protocole.

Ce que ça change pour les éditeurs de sites

Le problème

Si vous êtes éditeur de contenu (blogueur, journaliste, e-commerçant), les IA qui consultent votre site ne voient probablement pas ce que vous croyez :

• Vos articles longs sont tronqués sans avertissement
• 70% des tokens consommés sont du bruit HTML, pas votre contenu
• Vos archives sont invisibles : un index de 400 articles dépasse facilement le plafond de fetch
• Vous n’avez aucun contrôle sur ce que l’IA retient ou ignore

La solution : un endpoint JSON dédié

J’ai créé pour mon blog un endpoint API qui retourne la liste de tous mes articles dans un format optimisé pour la consommation IA. Une dizaine de champs au lieu du HTML complet. Pas de navigation, pas de sidebar, pas de classes CSS. Du contenu pur que l’IA peut ingérer efficacement pour identifier les articles pertinents à citer ou à lier.

Les leçons apprises

En optimisant cet endpoint, j’ai découvert plusieurs réalités que les documentations officielles ne mentionnent pas :

1. La pagination est un angle mort total. J’avais prévu de paginer les résultats de mon endpoint API, mais en réalité, l’IA ne « tourne jamais les pages » : elle fait un seul appel et travaille avec ce qu’elle reçoit. Il faut que tout tienne en un fetch. Et le problème va bien au-delà des API : pensez à ces articles de presse découpés en 5 pages « cliquez pour lire la suite », conçus pour gonfler les pages vues. L’IA ne fetch que la première page. Elle ne cliquera pas sur « page suivante ». Elle travaillera avec un article tronqué au tiers, et elle ne le saura pas. Le listicle en 30 points dont elle ne voit que les 10 premiers. L’enquête en trois volets dont elle ne connaît que l’introduction. La recette dont elle n’a que les ingrédients sans les étapes. Autant de contenus que l’IA citera avec aplomb, comme si elle les avait lus en entier. Si vous paginez votre contenu éditorial, vous le rendez invisible aux IA au-delà de la première page, exactement comme un site non accessible le rend invisible aux lecteurs d’écran.
2. La compression ne contourne pas les limites. Servir du gzip réduit la bande passante, mais l’IA raisonne en tokens après décompression. Un JSON de 345 Ko compressé en 80 Ko consomme toujours ~86 000 tokens une fois lu.
3. Chaque champ compte. Retirer les tags (40-50 par article) et les meta descriptions de mon endpoint a divisé le poids par trois. Les headings_h2 que je pensais utiles représentaient 30% du poids restant pour une valeur marginale.
4. L’upload fichier contourne tout. Si l’IA supporte l’upload direct, le fichier entre dans la fenêtre de contexte sans passer par le plafond de fetch. C’est la voie royale quand on veut zéro troncature.
5. Visez 40-45 000 tokens maximum pour un endpoint destiné à être consommé par fetch. C’est le seuil qui passe chez toutes les IA actuelles sans troncature.

Le paradoxe des fenêtres géantes

L’industrie se vante de fenêtres de contexte toujours plus grandes : 200 000 tokens chez Anthropic, 1 000 000 chez Google, 128 000 chez OpenAI. La sortie de Claude Opus 4.6 a d’ailleurs provoqué un séisme dans l’industrie du logiciel, mais ces chiffres impressionnants masquent une réalité : la fenêtre de contexte et le plafond de fetch sont deux choses distinctes.

La fenêtre de contexte, c’est le bureau. Le plafond de fetch, c’est la taille maximale d’un document qu’on a le droit de poser dessus en un seul geste. On limite la taille du document pour laisser de la place au reste : le system prompt, l’historique de conversation, les résultats d’autres recherches, et la réponse à générer.

C’est un choix d’ingénierie, pas une contrainte du modèle. Et c’est un choix que chaque éditeur d’IA fait différemment, modifie sans prévenir, et ne documente presque jamais.

Ce que vous pouvez faire dès maintenant

Si vous êtes éditeur de contenu :

• Créez un endpoint JSON léger de votre catalogue d’articles (URL, titre, extrait court, catégories, date), c’est un investissement minimal qui rend votre contenu exploitable par toutes les IA
• Gardez le poids total sous 180 Ko (~45 000 tokens) pour passer chez tout le monde en un seul fetch
• Testez vous-même : demandez à ChatGPT, Claude ou Perplexity de résumer votre article le plus long, et vérifiez s’ils mentionnent des éléments de la fin

Si vous êtes développeur :

• Pensez vos API avec un « budget tokens » en tête, pas seulement un poids en octets
• Offrez des paramètres de filtrage (?fields=url,title,excerpt) pour que le consommateur, humain ou IA, ne récupère que ce dont il a besoin
• Explorez l’arbre d’accessibilité comme canal alternatif : un site bien balisé sémantiquement est un site que les agents IA liront mieux
• Et si vous déléguez de plus en plus votre code à l’IA, vérifiez que le HTML généré reste sémantique : un agent IA qui code du HTML pour un autre agent IA qui le lira n’a aucune raison de produire du balisage propre si personne ne l’exige

Si vous êtes utilisateur d’IA :

• Quand vous avez un gros fichier à analyser, uploadez-le plutôt que de coller un lien : vous contournez le plafond de fetch
• Si l’IA semble ignorer la fin d’un document, c’est probablement une troncature silencieuse, pas une hallucination
• La même question posée à la même IA peut donner des résultats différents selon que le contenu source a été tronqué ou non

Le mot de la fin

Les IA ne lisent pas le web : elles l’échantillonnent. Chaque page est filtrée, tronquée, compressée avant d’atteindre le modèle. Ce que vous publiez et ce que l’IA perçoit sont deux réalités différentes, séparées par des plafonds techniques que personne ne documente, que chaque éditeur fixe arbitrairement, et que tous modifient sans prévenir.

Dans un monde où l’IA devient un canal de découverte aussi important que Google, contrôler la façon dont votre contenu est consommé par les modèles n’est plus une coquetterie technique : c’est de la souveraineté éditoriale.