Le web se voile aux IA : patterns, dette et revanche du HTML sémantique

Après avoir décrypté comment les IA lisent le web, explorons pourquoi elles n’y voient souvent que dalle. Le web n’a jamais été aussi beau, aussi fluide, aussi interactif, et aussi opaque pour les intelligences artificielles qui tentent de le lire. Infinite scroll, single-page apps, contenus piégés derrière du JavaScript : chaque innovation UX creuse un fossé entre ce que l’humain voit et ce que la machine perçoit. Alors que les IA deviennent un canal de découverte majeur, ce paradoxe pourrait redessiner l’économie du contenu en ligne.

Le malentendu fondamental : le web n’a jamais été conçu pour être lu par des machines

En 1989, quand Tim Berners-Lee pose les fondations du World Wide Web au CERN, il imagine un système de documents hypertextes reliés entre eux. Le HTML est alors un format de document au sens strict : des titres, des paragraphes, des liens, des listes. Un texte structuré, lisible aussi bien par un humain que par un programme. Le premier navigateur web était d’ailleurs aussi un éditeur : la distinction entre lire et écrire n’existait pas encore.

Cette lisibilité universelle n’était pas un accident. C’était le principe fondateur. Le HTML devait être un format ouvert, interprétable par n’importe quel agent, humain ou logiciel. Un <h1> signifiait un titre de premier niveau, partout, pour tout le monde. Un <p> était un paragraphe. Un <a href> était un lien. La sémantique était le contrat.

Puis le web a grandi. CSS a séparé le fond de la forme. JavaScript a rendu les pages interactives. AJAX a permis de charger du contenu sans recharger la page. Les frameworks front-end (jQuery, puis Angular, React, Vue, Svelte) ont transformé le navigateur en plateforme d’exécution. Le HTML n’est plus un document. C’est un conteneur d’application. Et quand l’IA elle-même se met à écrire le code de ces frameworks, personne ne vérifie que le HTML produit reste sémantique.

Le contrat implicite a été rompu sans que personne ne s’en aperçoive. Un <div class="sc-1x2b3c4"> ne signifie rien. Un <span> vide qui se remplit par JavaScript au bout de 300 millisecondes n’est pas un paragraphe : c’est une promesse de contenu que seul un navigateur complet peut honorer. Le HTML a cessé d’être un format de document pour devenir un format de rendu, et cette mutation a des conséquences que l’on commence seulement à mesurer.

Comme je l’ai détaillé dans mon article précédent, les IA qui accèdent au web disposent de trois canaux : le fetch HTTP brut (qui récupère le HTML tel quel), le crawl de recherche (fetch + moteur de recherche), et le navigateur piloté (qui exécute JavaScript et lit l’arbre d’accessibilité). Les deux premiers (de loin les plus courants) récupèrent le HTML initial, avant toute exécution de JavaScript. Ils voient le document, pas l’application. Et quand le document est une coquille vide qui attend son contenu du JavaScript, ils ne voient rien.

C’est le malentendu fondamental : le web tel qu’il existe aujourd’hui est construit pour être rendu par un moteur de navigateur, pas pour être lu par un agent extérieur. Les IA, qui sont précisément des agents extérieurs, se retrouvent face à un mur que personne n’a intentionnellement dressé. Le web ne leur tourne pas le dos par malice. Il leur tourne le dos par évolution.

Catalogue raisonné des patterns anti-IA du web moderne

Chaque innovation UX des quinze dernières années a, souvent sans le vouloir, érigé un obstacle supplémentaire entre le contenu et les machines qui tentent de le lire. Voici un inventaire systématique, avec pour chaque pattern son mécanisme technique, son impact concret sur la perception IA, et un verdict de lisibilité.

L’infinite scroll

Le principe est simple : au lieu d’afficher tout le contenu d’un coup, la page n’en charge qu’une fraction initiale et en ajoute au fur et à mesure que l’utilisateur descend. Twitter/X, Instagram, LinkedIn, Pinterest, Reddit : la moitié du web social fonctionne ainsi.

Pour une IA qui fait un fetch HTTP, le problème est radical : le contenu au-delà du premier écran n’existe pas dans le HTML initial. Il n’est pas masqué, il n’est pas caché, il n’a tout simplement pas été généré. Il faudrait exécuter le JavaScript, simuler un scroll, attendre le chargement, simuler un autre scroll, et ainsi de suite. Même un agent navigateur comme Claude in Chrome doit physiquement scroller pour déclencher le chargement, sans aucune garantie de tout récupérer : certaines implémentations désactivent le chargement après un certain nombre de lots, d’autres exigent une authentification.

Verdict : mur total en fetch brut. Contournable en mode navigateur, mais coûteux et incomplet.

La pagination éditoriale

Vous connaissez le pattern : « Les 50 meilleurs restaurants de Paris » découpé en 10 pages de 5, chacune servant une nouvelle salve de publicités. Ou le grand reportage en trois volets, chaque volet sur une URL distincte. C’est le modèle économique du web éditorial depuis vingt ans : plus de pages vues, plus de revenus publicitaires.

Pour l’IA, c’est un angle mort documenté dans mon article précédent : elle fait un seul fetch, obtient la première page, et travaille avec. Elle ne cliquera pas sur « page suivante ». Le listicle dont elle ne voit que les 10 premiers points sur 50. L’enquête dont elle ne connaît que l’introduction. La recette dont elle a les ingrédients mais pas les étapes. Et elle citera le tout avec aplomb, comme si elle avait lu l’ensemble.

Verdict : mur partiel. L’IA voit la première page, ignore le reste. Théoriquement contournable si les URLs de pagination sont prévisibles, mais en pratique aucune IA ne les suit.

Les single-page applications (SPA)

React, Vue, Angular, Svelte, Next.js en mode CSR (client-side rendering) : les SPA sont devenues l’architecture dominante du web applicatif. Le principe : le serveur envoie une page HTML quasi vide (souvent un simple <div id="root"></div>) et un gros bundle JavaScript qui construit l’intégralité de l’interface dans le navigateur.

Pour un fetch HTTP, le résultat est dévastateur. L’IA récupère un squelette HTML sans contenu. Pas de titres, pas de paragraphes, pas de données : juste des balises de montage et des scripts. Le contenu réel n’existera qu’après l’exécution complète du JavaScript, dans un environnement de navigateur. C’est comme recevoir une enveloppe qui contient les instructions pour fabriquer la lettre, mais pas la lettre elle-même.

Certains frameworks proposent du SSR (server-side rendering) ou du SSG (static site generation) qui pré-rendent le HTML côté serveur. Next.js, Nuxt, Astro, SvelteKit offrent ces options. Mais elles ne sont pas activées par défaut, et une proportion significative des sites en production restent en CSR pur : surtout les applications internes, les dashboards, et les sites d’e-commerce construits à la hâte. Même les architectures WordPress Headless, censées moderniser la stack, retombent dans ce piège si le front-end est en CSR pur.

Verdict : mur total en CSR pur. Transparent si SSR/SSG est activé. Le problème est que l’IA ne peut pas savoir à l’avance quel mode est utilisé.

Le lazy loading agressif

Le lazy loading est une technique de performance : ne charger les ressources que lorsqu’elles entrent dans le viewport de l’utilisateur. Pour les images, c’est devenu un standard : l’attribut loading="lazy" est natif en HTML depuis 2020. Jusque-là, pas de problème majeur pour les IA : le texte alternatif de l’image est généralement dans le DOM dès le chargement initial.

Le problème survient quand le lazy loading s’applique au contenu textuel lui-même. Des bibliothèques comme react-lazyload, react-virtualized ou TanStack Virtual ne rendent les composants que lorsqu’ils sont visibles. Un tableau de 500 lignes n’en affiche que 20 dans le DOM réel : les 480 autres sont des fantômes qui n’existent pas tant qu’on ne scrolle pas jusqu’à eux. Les fiches produits d’un e-commerce, les commentaires utilisateurs, les avis, les spécifications techniques, autant de contenus qui peuvent être virtualisés et donc invisibles à un fetch brut.

Verdict : transparent pour le lazy loading d’images (les balises <img> restent dans le DOM). Mur total pour la virtualisation de contenu textuel.

Les accordéons, onglets et « lire la suite »

Ici, la situation est plus nuancée. Un accordéon ou un onglet HTML bien construit place souvent tout le contenu dans le DOM dès le chargement : il ne fait que le masquer visuellement avec du CSS (display: none, visibility: hidden, ou max-height: 0). Un fetch HTTP récupérera donc le texte, même s’il est « caché » pour l’utilisateur.

Mais ce n’est pas toujours le cas. Certaines implémentations ne chargent le contenu d’un onglet que lorsqu’on clique dessus (chargement AJAX à la demande). D’autres utilisent des frameworks qui conditionnent le rendu du composant à son état d’activation. Et pour les agents IA qui lisent l’arbre d’accessibilité plutôt que le DOM brut, un élément avec aria-hidden="true" ou un <details> fermé peut être omis de l’arbre selon l’implémentation du navigateur.

Le pattern « lire la suite » est particulièrement vicieux : le texte complet est parfois dans le DOM (tronqué par CSS), parfois chargé dynamiquement au clic. Impossible de le savoir sans inspecter le code source.

Verdict : souvent transparent en fetch brut (contenu dans le DOM même si masqué). Variable en mode arbre d’accessibilité. Mur si le contenu est chargé dynamiquement.

Les modales et popovers

Les fenêtres modales, les tooltips enrichis, les panneaux latéraux : tout le contenu qui apparaît en réponse à une interaction utilisateur. Politique de confidentialité derrière un « En savoir plus ». Spécifications techniques dans un popover. Galerie d’images dans une lightbox.

Comme pour les accordéons, le contenu peut être pré-chargé dans le DOM et simplement masqué, ou chargé dynamiquement à l’interaction. La tendance actuelle, pour des raisons de performance, est au chargement dynamique : ne charger le contenu de la modale que lorsqu’elle est ouverte. Ce qui, du point de vue d’une IA en fetch brut, revient à un contenu inexistant.

Verdict : variable. Pré-chargé dans le DOM → transparent. Chargé au clic → mur total.

Le shadow DOM, les Web Components et les iframes

Le shadow DOM est une fonctionnalité du standard Web Components qui permet d’encapsuler un composant (son HTML, son CSS, son état) dans une bulle isolée du reste de la page. C’est élégant pour les développeurs : pas de conflits de styles, pas de fuites, des composants réutilisables.

Pour les IA, c’est un problème d’un genre nouveau. Le contenu à l’intérieur d’un shadow DOM est invisible au document.querySelector() classique. Certains crawlers ne le traversent pas. L’arbre d’accessibilité, en revanche, le traverse généralement : c’est d’ailleurs l’un des rares avantages de cette approche pour les agents navigateurs.

Comparons deux approches pour un même composant « FAQ » :

<!-- Approche native : un <details> HTML -->
<details>
  <summary>Comment résilier mon abonnement ?</summary>
  <p>Rendez-vous dans vos paramètres, section "Abonnement",
     puis cliquez sur "Résilier".</p>
</details>
Langage du code : HTML, XML (xml)

Le <details> natif est parfaitement lisible par toutes les IA : le contenu est dans le DOM, il apparaît dans l’arbre d’accessibilité, il est exposé en fetch brut. C’est du HTML sémantique pur.

<!-- Approche Web Component avec shadow DOM -->
<faq-item>
  #shadow-root (open)
    <div class="question" @click="toggle">
      Comment résilier mon abonnement ?
    </div>
    <div class="answer" v-if="isOpen">
      Rendez-vous dans vos paramètres...
    </div>
</faq-item>
Langage du code : HTML, XML (xml)

Le Web Component encapsule le contenu. Un fetch brut ne verra que <faq-item></faq-item> : une balise inconnue, vide. Le contenu est dans l’ombre, littéralement.

Quant aux iframes, c’est un cas encore plus tranché. Un iframe charge un document externe à l’intérieur de votre page. Le contenu de l’iframe n’est pas dans le DOM de la page hôte : c’est un document séparé avec sa propre URL. Une IA qui fetch votre page ne verra qu’une balise <iframe src="..."> sans son contenu. Elle devrait faire un second fetch sur l’URL de l’iframe pour récupérer ce contenu, ce qu’aucune IA ne fait automatiquement. Les widgets tiers (commentaires Disqus, formulaires Typeform, lecteurs vidéo embarqués, cartes Google Maps) sont tous dans cette situation : présents visuellement, absents pour l’IA.

Verdict : le shadow DOM est un mur en fetch brut, généralement traversable en mode arbre d’accessibilité. Les iframes sont un mur total dans tous les cas : le contenu tiers est invisible.

Les contenus canvas et WebGL

Les éléments <canvas> et les rendus WebGL sont des surfaces de dessin au pixel. Ce qui y est affiché n’a aucune représentation dans le DOM : c’est une image générée en temps réel par JavaScript. Les graphiques interactifs (D3.js en mode canvas), les jeux, les visualisations 3D, les cartes vectorielles (MapLibre, Deck.gl), les éditeurs graphiques (Figma fonctionne entièrement en canvas) : tout cela est un trou noir absolu pour les IA.

Il n’y a pas de texte à extraire, pas de structure à lire, pas d’arbre d’accessibilité à traverser. Le canvas est à l’IA ce qu’un tableau peint à l’huile est à un lecteur d’écran : une surface opaque dont le sens ne peut être déduit que par la vision, pas par la structure.

Verdict : mur total, absolu, sans contournement possible en l’état de la technologie.

Le piège multimodal : quand la vision ne suffit pas non plus

On pourrait croire que les IA multimodales (GPT-4o, Gemini 2.5, Grok avec capacités visuelles) contournent le problème du canvas en « voyant » la page comme un humain. C’est en partie vrai pour les images statiques : un modèle multimodal peut décrire une photo, lire du texte dans une capture d’écran, interpréter un graphique simple. Mais le web moderne ne se contente pas d’images statiques.

Les carrousels d’images qui défilent automatiquement, les graphiques SVG animés qui révèlent leurs données au survol, les tutoriels vidéo intégrés en lazy loading, les infographies interactives construites en D3.js : tout ce contenu visuel dynamique exige non seulement de voir, mais d’interagir pour voir. Un carrousel n’affiche qu’une image à la fois. Un graphique animé ne montre ses valeurs qu’au passage de la souris. Une vidéo ne livre son contenu qu’à la lecture. L’IA multimodale voit une photo du restaurant, pas le menu qui défile dans le slider d’à côté.

Et le paradoxe se creuse : plus le web enrichit son contenu visuel (animations, transitions, contenus révélés progressivement) plus il devient opaque même pour les IA capables de « voir ». La multimodalité ne résout pas le problème fondamental : le contenu dynamique exige de l’interaction, et l’interaction exige un agent navigateur complet. Demain, votre infographie D3.js restera un pixel muet pour toute IA qui ne pilote pas un navigateur en temps réel.

Verdict : mur croissant. La multimodalité aide pour le contenu visuel statique, mais le contenu visuel dynamique reste opaque.

Les paywalls et murs de consentement

Le dernier obstacle n’est pas technique mais contractuel. L’IA ne peut ni payer un abonnement, ni cliquer « J’accepte les cookies », ni résoudre un CAPTCHA, ni prouver qu’elle est humaine. Les murs de consentement RGPD, les cookie banners, les paywalls hard (contenu bloqué sans abonnement) et soft (trois articles gratuits puis blocage) : tout cela interrompt la lecture avant même la question de la troncature.

Certains médias ont signé des accords de licence avec OpenAI ou Google pour permettre l’accès à leurs archives. Mais ces accords sont bilatéraux, exclusifs, et ne bénéficient qu’aux IA signataires. Le reste de l’écosystème (y compris les IA open source) reste devant la porte.

Et l’ironie est savoureuse : les murs de consentement RGPD, conçus pour protéger la vie privée des utilisateurs humains, bloquent aussi les agents artificiels. L’IA ne peut pas cliquer « J’accepte les cookies », et même si elle le pouvait, devrait-elle y consentir au nom de qui ?

Verdict : mur total. Le contenu derrière un paywall ou un mur de consentement est juridiquement et techniquement inaccessible pour la plupart des IA.

Tableau récapitulatif

Pour les impatients, et pour servir de grille d’audit rapide :

La colonne « navigateur/arbre » concerne les rares agents qui pilotent un vrai navigateur (Claude in Chrome, Project Mariner). Pour 90% des IA en production aujourd’hui, seule la colonne « fetch brut » s’applique.

Leçons du passé et dette du présent

Le précédent Flash : quand le web est déjà devenu illisible

L’histoire du web a déjà traversé ce paradoxe. À la fin des années 1990 et durant les années 2000, Macromedia Flash (puis Adobe Flash) a conquis le web avec une promesse irrésistible : des animations fluides, des interfaces riches, du multimédia sans compromis. Des sites entiers (y compris des sites corporate, des portfolios, des restaurants, des magazines en ligne) étaient construits intégralement en Flash.

Le résultat était spectaculaire pour l’œil humain. Et totalement opaque pour tout le reste. Les moteurs de recherche ne pouvaient pas indexer le contenu des fichiers .swf. Les lecteurs d’écran ne pouvaient pas y accéder. Le contenu était enfermé dans un runtime propriétaire, un format binaire que seul le plugin Flash Player savait interpréter. Des pans entiers du web étaient devenus des boîtes noires.

La réponse de l’industrie a pris une décennie, mais elle a été décisive. Le W3C a poussé les standards d’accessibilité (WCAG 1.0 en 1999, WCAG 2.0 en 2008). Google a commencé à pénaliser les sites en Flash dans ses résultats de recherche. Apple a refusé Flash sur l’iPhone en 2010 : le fameux mémo de Steve Jobs, « Thoughts on Flash ». HTML5 a fourni les alternatives natives (vidéo, canvas, animations CSS). Flash est mort en décembre 2020, abandonné par Adobe lui-même.

Le parallèle : JavaScript est le nouveau Flash

Le parallèle avec la situation actuelle est frappant, et troublant. Remplacez « Flash » par « JavaScript lourd » et le scénario se répète presque à l’identique :

Un contenu enfermé dans un runtime que les agents extérieurs ne savent pas interpréter. Flash enfermait le contenu dans un plugin propriétaire. Les SPA en CSR pur enferment le contenu dans l’exécution JavaScript côté client. Dans les deux cas, le HTML (le format ouvert, interopérable, lisible par tous) a été court-circuité.

Des agents extérieurs qui ne voient qu’une coquille vide. En 2005, Googlebot ne voyait rien d’un site Flash. En 2026, une IA en fetch brut ne voit rien d’une SPA en CSR pur. Le mécanisme est différent (binaire propriétaire vs. JavaScript ouvert) mais le résultat est le même : l’agent reçoit un conteneur sans contenu.

Une industrie qui a mis du temps à réagir. Flash a dominé pendant quinze ans avant d’être remis en question. Les SPA en CSR pur sont l’architecture dominante depuis dix ans. La pression des IA n’est pas encore assez forte pour provoquer un changement aussi radical que la mort de Flash.

Mais il y a une différence cruciale. Flash a été tué par un consensus coordonné : Apple a bloqué le plugin, Google a pénalisé les sites, le W3C a proposé des alternatives, Adobe a capitulé. Ce consensus a été possible parce que les intérêts convergeaient : meilleure accessibilité, meilleure sécurité, meilleure performance, meilleur SEO.

Pour les patterns anti-IA du web moderne, ce consensus n’existe pas encore. Les frameworks JavaScript ne sont pas un format propriétaire : React est open source. Le JavaScript n’est pas un plugin tiers : c’est un standard du web. Et les créateurs de sites n’ont pas encore de raison économique forte d’optimiser pour les IA, parce que le trafic IA n’est pas encore mesuré, monétisé ou même compris par la plupart des éditeurs.

Nommer la dette : la dette d’accessibilité IA

Dans le développement logiciel, la « dette technique » désigne les raccourcis pris aujourd’hui qui devront être remboursés demain, avec intérêts. On code vite, on ne documente pas, on empile les dépendances, et un jour la base de code devient ingérable. Le coût du remboursement est toujours supérieur au coût de la prévention.

Je propose de nommer un phénomène analogue : la dette d’accessibilité IA. Chaque choix de conception qui privilégie l’expérience visuelle au détriment de la lisibilité machine ajoute à cette dette. Un infinite scroll au lieu d’une pagination classique. Un accordéon chargé en AJAX au lieu d’un <details> natif. Une SPA en CSR au lieu d’un site avec SSR. Un contenu derrière une modale au lieu d’un contenu en ligne. Chacun de ces choix est rationnel dans le contexte de l’expérience utilisateur humaine. Et chacun contracte une dette envers les agents machine.

Cette dette a trois propriétés pernicieuses.

Elle est invisible. Aucun outil d’audit standard ne la mesure. Lighthouse vérifie l’accessibilité humaine (WCAG), pas la lisibilité machine. Google Search Console montre les erreurs d’indexation, pas les échecs de lecture IA. Le webmaster ne sait pas ce que l’IA ne voit pas.

Elle est payée par le mauvais acteur. C’est le créateur de contenu qui devient invisible, pas le développeur du framework, pas l’hébergeur, pas l’IA elle-même. React n’est pas pénalisé si votre site React est illisible par les IA. C’est vous, l’éditeur, qui perdez un canal de distribution, un canal dont l’importance ne fait que croître depuis que des modèles comme Claude Opus 4.6 ont démontré leur capacité à remplacer des workflows entiers.

Elle s’accumule silencieusement. Tant que le trafic IA reste marginal, la dette ne coûte rien. Mais le jour où 30, 40, 50% de la découverte de contenu passe par les IA (et ce jour approche) la facture arrive d’un coup.

Comment la mesurer ? On peut imaginer quelques métriques simples : le ratio de contenu utile sur le poids HTML total (un site à 20% de contenu utile a une dette plus lourde qu’un site à 80%). Le taux de contenu accessible sans JavaScript (désactivez JS : que reste-t-il ?). La complétude de l’arbre d’accessibilité par rapport au contenu visible. Le nombre de patterns anti-IA dans la liste ci-dessus utilisés sur le site. Ce n’est pas une science exacte, mais c’est un début de diagnostic.

L’invisibilité économique : quand l’IA ne vous cite pas

Le funnel de découverte de contenu en ligne est en train de muter. Pendant vingt ans, la séquence dominante était linéaire : l’utilisateur tape une requête dans Google, parcourt les résultats, clique sur un lien, arrive sur votre site. Le SEO (search engine optimization) a structuré toute l’économie du contenu web autour de cette séquence. Mots-clés, backlinks, balises meta, PageRank, SERP features : tout converge vers un objectif unique, apparaître dans les résultats de Google.

Le nouveau funnel est radicalement différent. L’utilisateur pose une question à ChatGPT, Claude, Perplexity ou Gemini. L’IA synthétise une réponse à partir de sources multiples. Peut-être qu’elle cite un lien. Peut-être pas. L’utilisateur obtient sa réponse sans jamais visiter votre site. Le clic a disparu du parcours.

Ce glissement a des implications économiques profondes pour les éditeurs de contenu. Dans l’ancien funnel, être mal indexé signifiait apparaître en page 2 de Google, désagréable, mais votre contenu existait quelque part dans l’index. Dans le nouveau funnel, si l’IA ne lit pas correctement votre contenu (parce qu’il est derrière un paywall, parce qu’il est en CSR pur, parce qu’il est paginé en dix morceaux) elle ne le cite tout simplement pas. Vous n’êtes pas mal classé. Vous n’existez pas.

C’est une forme d’invisibilité nouvelle, plus radicale que le mauvais référencement. Et elle frappe en priorité ceux qui avaient le plus investi dans l’ancien modèle : les médias premium avec paywalls, les e-commerces avec des SPA lourdes et des fiches produits chargées dynamiquement, les documentations techniques en lazy loading, les sites riches en contenu interactif qui ne vaut rien en HTML brut.

On commence à parler de LLMO (Large Language Model Optimization) comme du successeur (ou du complément) du SEO. Le concept est encore jeune, mais la logique est claire : il ne s’agit plus d’optimiser pour un crawler qui indexe des mots-clés, mais pour un modèle de langage qui comprend (ou tente de comprendre) la sémantique de votre contenu. Les critères changent :

Ce tableau masque une réalité encore plus brutale : l’essor du zero-click. En 2026, une part croissante des recherches informationnelles aboutit à une réponse synthétisée par l’IA, sans qu’aucun clic ne soit généré vers les sources. L’utilisateur obtient ce qu’il cherche directement dans la conversation. Le cas de Wikipedia, dont le trafic s’effondre à mesure que les IA aspirent et resynthétisent son contenu, illustre parfaitement cette dynamique. Dans ce contexte, être « citable » ne suffit même plus : il faut être la source que l’IA choisit de citer, parmi toutes celles qu’elle a consultées. Et les LLM, par construction, privilégient les sources qu’ils peuvent lire intégralement, dont la structure est claire et dont le contenu est sémantiquement riche. Un article en HTML propre avec du Schema.org sera toujours préféré à une SPA opaque, même si le contenu de fond est identique. L’enjeu n’est plus seulement d’être indexable : c’est de devenir une source d’autorité pour les IA. Faites le test : posez une question à Perplexity sur un sujet que vous couvrez. Êtes-vous cité, ou zappé ?

Les premiers perdants de cette transition sont identifiables : les sites techniquement sophistiqués mais opaques pour les machines. Les premiers gagnants aussi : les sites statiques, les wikis, les blogs en HTML sémantique, les documentations en Markdown, le « vieux web » structuré, lisible, complet dès le premier fetch. Ironie de l’histoire : les sites les plus simples techniquement sont les mieux armés pour l’ère de l’IA.

Contre-attaques et standards émergents

Le fossé entre le web moderne et les IA est réel, mais les deux côtés bougent. Les IA développent des stratégies de contournement, et de nouveaux standards commencent à émerger pour jeter des ponts entre les deux rives.

Les renderers headless

La première réponse technique est brutale : si le HTML brut ne contient rien, exécuter le JavaScript pour obtenir le contenu rendu. Des outils comme Puppeteer (Google) et Playwright (Microsoft) permettent de piloter un navigateur Chrome, Firefox ou WebKit en mode « headless » (sans interface graphique) et de récupérer le DOM après exécution complète du JavaScript.

Certaines IA intègrent déjà cette approche. Perplexity utilise un pipeline de rendu côté serveur pour les pages qu’elle indexe. Des implémentations spécialisées de Grok et d’autres agents font de même pour les pages critiques. Le principe : au lieu de lire le HTML brut, on « regarde » la page comme un navigateur le ferait, puis on en extrait le contenu.

Le problème est le passage à l’échelle. Lancer un Chrome headless pour chaque page web consultée consomme de la RAM, du CPU, du temps. Un fetch HTTP prend quelques millisecondes. Un rendu headless complet (chargement du DOM, exécution du JS, attente des appels API, stabilisation du rendu) prend plusieurs secondes, parfois dizaines de secondes. Multipliez par les millions de pages consultées chaque jour par une IA grand public, et le coût devient prohibitif.

Les agents navigateurs

La deuxième réponse est plus élégante : au lieu de rendre la page en arrière-plan, piloter un vrai navigateur en temps réel. C’est l’approche de Claude in Chrome (Anthropic) via le protocole MCP, et du projet Mariner (Google) avec Gemini. L’IA contrôle un navigateur réel : elle peut cliquer, scroller, interagir avec les éléments, et lire l’arbre d’accessibilité plutôt que le HTML brut.

Cette approche résout le problème de l’infinite scroll (l’IA peut scroller), des modales (elle peut cliquer pour les ouvrir), et en partie des SPA (le navigateur exécute le JavaScript). Mais elle reste limitée : c’est lent, c’est coûteux, et ça ne fonctionne que pour une interaction à la fois. On ne crawle pas le web entier avec un agent navigateur, on visite une page précise, pour un usage précis.

Les partenariats éditeurs-IA

La troisième réponse est contractuelle. OpenAI a signé des accords de licence avec plusieurs médias majeurs (Associated Press, Axel Springer, Le Monde, Financial Times, entre autres) pour accéder à leurs archives complètes, au-delà des paywalls, dans un format structuré. Google a des accords similaires via ses programmes d’indexation étendue.

Ces partenariats résolvent le problème à la racine pour les signataires : l’IA obtient le contenu propre, complet, structuré, sans passer par le web public. Mais ils créent une asymétrie : les médias qui ont les moyens de négocier avec OpenAI ou Google obtiennent une visibilité IA que les autres n’auront jamais. Les blogs, les petits médias, les sites indépendants restent dépendants du fetch brut et de ses limitations, avec, en prime, les vulnérabilités inhérentes à cette ingestion aveugle de contenu web.

Ce qui existe déjà côté standards

L’idée d’un web à double couche (une pour les humains, une pour les machines) n’est pas nouvelle. Elle existe en germe depuis les débuts du web sémantique.

Schema.org et JSON-LD. Depuis 2011, le vocabulaire Schema.org permet d’ajouter des métadonnées structurées à vos pages : type de contenu, auteur, date, résumé, note, prix. Injectées via des blocs <script type="application/ld+json">, ces données sont lisibles par les machines sans toucher au HTML visible. Google les utilise massivement pour ses rich snippets. Mais les IA conversationnelles ne les exploitent pas encore systématiquement : elles fetchent le HTML et l’arbre d’accessibilité, rarement le JSON-LD embarqué.

Les flux RSS et Atom. Le bon vieux RSS (Really Simple Syndication) est peut-être le format le plus IA-friendly jamais inventé. Du XML structuré, sans mise en page, sans JavaScript, avec le contenu complet (ou un résumé) de chaque article. Les flux RSS sont en déclin depuis la fermeture de Google Reader en 2013, mais ils restent fonctionnels sur des millions de sites. Ironie : un protocole donné pour mort il y a dix ans pourrait être le meilleur canal de communication entre un blog et une IA.

Les sitemaps XML. Le sitemap.xml à la racine de votre site donne à n’importe quel agent la liste complète de vos URLs, avec dates de modification et priorités. C’est un index, pas du contenu, mais c’est déjà un point d’entrée structuré que les IA pourraient exploiter beaucoup mieux qu’elles ne le font.

Ce qui manque cruellement

Il n’existe aujourd’hui aucun standard 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 ».

Plusieurs pistes ont été discutées dans la communauté technique :

Un fichier ai.txt à la racine du site (sur le modèle du robots.txt) qui indiquerait les endpoints optimisés pour les IA, les formats disponibles, les politiques d’accès.

Une balise <link rel="ai-content" href="/api/article.json"> dans le <head> de chaque page, pointant vers une version machine-optimisée du contenu.

Des headers HTTP comme X-AI-Content: /api/article.json renvoyés avec chaque réponse.

Aucune de ces propositions n’a dépassé le stade de la discussion. Et les raisons sont pragmatiques : les éditeurs d’IA (Anthropic, OpenAI, Google) n’ont pas d’incitation à chercher un fichier supplémentaire avant chaque fetch. Ça coûte de la latence, ça complexifie le pipeline, et leur priorité est la rapidité de réponse à l’utilisateur, pas le confort du webmaster.

Les signaux d’espoir côté open source

Le tableau n’est pas entièrement sombre. Des initiatives émergent, même si elles sont encore embryonnaires.

Le W3C explore des extensions au protocole Web Annotation pour permettre aux agents de mieux identifier les zones de contenu pertinentes dans une page. Des travaux sur les « content hints » (des métadonnées indiquant aux agents quelles parties d’une page contiennent le contenu principal) sont en discussion dans le groupe de travail Web Annotation.

Côté open source, des outils comme Trafilatura (extraction de contenu en Python), Readability.js (le moteur derrière le « mode lecteur » de Firefox) offrent des alternatives au fetch brut. Ces parsers tentent d’extraire le contenu principal d’une page en éliminant le bruit (navigation, publicités, widgets). Ils ne sont pas parfaits, mais ils réduisent significativement le ratio bruit/signal.

Des initiatives comme le protocole llms.txt (proposé par Jeremy Howard de fast.ai) visent à standardiser un fichier à la racine des sites qui contiendrait une version condensée du contenu, optimisée pour les LLM. L’adoption reste marginale, mais l’idée circule.

Le verdict : un fossé qui se stratifie

Ces contre-attaques (techniques, contractuelles, standardisées) réduisent le problème pour les gros acteurs, mais ne le résolvent pas pour l’écosystème. Le web indépendant, les petits éditeurs, les sites de niche restent soumis aux mêmes limitations : un fetch HTTP brut, un plafond de tokens, une troncature silencieuse.

Faut-il adapter le web aux machines, ou adapter les machines au web ? Probablement les deux, et c’est déjà ce qui se passe. Les IA deviennent meilleures pour lire des pages complexes (headless rendering, agents navigateurs). Et le web, lentement, redécouvre les vertus du HTML sémantique et du contenu structuré.

Le risque réel n’est pas l’immobilisme technique : les deux côtés avancent. Le risque est la fracture : un web à deux vitesses, où les gros éditeurs ont les moyens d’optimiser leur contenu pour les IA (APIs dédiées, accords de licence, endpoints JSON) tandis que les petits éditeurs restent invisibles. C’est la même fracture que le SEO a créée il y a vingt ans, mais amplifiée, parce que l’IA ne fait même pas l’effort de crawler : elle fetch une fois, et si le contenu est opaque, elle passe à autre chose.

Ce que vous pouvez faire maintenant

En attendant qu’un standard émerge (et il finira par émerger, comme les standards d’accessibilité ont fini par émerger après Flash) voici les actions concrètes pour réduire votre dette d’accessibilité IA.

Le test décisif : deux minutes pour un diagnostic

Ouvrez votre site dans Chrome. Désactivez JavaScript (F12 → Settings → cochez « Disable JavaScript »). Rechargez la page. Ce que vous voyez est ce que 90% des IA voient. Si votre contenu a disparu, vous avez un problème.

Les quick wins

Du HTML sémantique, pas une soupe de <div>. Utilisez <article>, <section>, <header>, <footer>, <nav>, <main>, <aside>. Utilisez les niveaux de titre correctement (<h1> à <h6> dans l’ordre). Un <details> natif plutôt qu’un accordéon JavaScript. Un <button> plutôt qu’un <div onclick>. Ce n’est pas du purisme : c’est de la lisibilité machine.

Du contenu complet au chargement initial. Le contenu principal de votre page doit être dans le HTML servi par votre serveur, pas injecté par JavaScript. Si vous utilisez un framework, activez le SSR (server-side rendering) ou le SSG (static site generation). C’est un réglage, pas une réécriture.

Un endpoint JSON léger. Comme je l’ai détaillé dans mon article précédent, un point d’accès API qui retourne vos articles dans un format optimisé (URL, titre, extrait, catégorie, date) rend votre catalogue exploitable par toutes les IA. Gardez le poids sous 180 Ko (~45 000 tokens) pour passer chez tout le monde sans troncature.

Un flux RSS complet. Si vous avez déjà un flux RSS, vérifiez qu’il contient le texte complet de vos articles, pas juste un extrait. Un flux RSS bien construit est le meilleur ami des IA, et il ne coûte rien à maintenir.

Les choix d’architecture

SSR/SSG plutôt que CSR pur. Si vous construisez un nouveau site, choisissez un framework qui génère du HTML côté serveur : Next.js (avec SSR ou SSG activé), Nuxt, Astro, SvelteKit, Hugo, Jekyll, Eleventy. Le contenu est dans le HTML dès le premier octet.

Progressive enhancement plutôt que JavaScript-first. Le contenu de base doit fonctionner sans JavaScript. Le JavaScript ajoute de l’interactivité, de l’animation, du confort, mais le texte, les images, la navigation doivent être accessibles sans lui. C’est le principe du progressive enhancement, vieux de vingt ans, et plus pertinent que jamais.

Évitez la pagination éditoriale. Un article, une page. Si votre article est long, il sera peut-être tronqué par le plafond de fetch de l’IA, mais au moins elle aura le début, le milieu, et potentiellement la fin. Dix pages de cinq paragraphes, c’est neuf pages que l’IA ne lira jamais.

L’audit de dette IA

Parcourez la liste des patterns anti-IA de la section 2 et cochez ceux qui sont présents sur votre site. Comptez-les. C’est votre score de dette. Priorisez la correction : les patterns « mur total » d’abord (SPA en CSR pur, infinite scroll, iframes de contenu), les patterns « variables » ensuite (accordéons, lazy loading).

Pour aller au-delà du diagnostic manuel, des outils existent déjà et méritent d’être dans votre boîte à outils :

Trafilatura est une bibliothèque Python d’extraction de contenu web. Donnez-lui n’importe quelle URL : elle tente d’extraire le texte principal en éliminant navigation, publicités et bruit structurel. Lancez-la sur vos propres pages : ce qu’elle retourne est une approximation honnête de ce qu’une IA voit de votre contenu en fetch brut. Si le résultat est vide ou tronqué, vous avez votre réponse.

Jina Reader (accessible via r.jina.ai/votre-url) va plus loin : il exécute le JavaScript de la page et restitue le contenu rendu en Markdown propre. C’est un pont entre le monde SPA et le monde texte. Comparez le résultat de Trafilatura (fetch brut) et de Jina Reader (rendu JS) sur la même page : l’écart entre les deux est la mesure exacte de votre dépendance au JavaScript pour délivrer du contenu.

Ce n’est pas un exercice ponctuel : c’est une discipline, comme le SEO l’est devenu. Chaque nouvelle fonctionnalité, chaque refonte, chaque ajout de widget devrait être évalué aussi sous l’angle de la lisibilité machine. Le coût de cette vigilance est négligeable. Le coût de l’invisibilité ne l’est pas.

La double peine du web francophone

Un dernier point, rarement évoqué : cette fracture de visibilité IA n’est pas neutre géographiquement ni linguistiquement. Le web francophone cumule deux handicaps structurels.

Le premier est réglementaire. Le RGPD (et son application stricte en Europe) impose des murs de consentement sur la quasi-totalité des sites. Chaque cookie banner est un obstacle de plus pour l’IA. Les éditeurs français et européens sont mécaniquement plus opaques que leurs homologues américains, non par choix technique mais par obligation légale.

Le second est statistique. Les datasets d’entraînement des grands LLM sont massivement anglophones. Le contenu en français est sous-représenté dans les corpus, ce qui signifie que les modèles ont moins de « familiarité » avec les sources francophones, les citent moins spontanément, et ont plus de mal à évaluer leur pertinence. Un article identique publié en anglais et en français n’aura pas la même visibilité dans les réponses d’une IA.

La combinaison des deux (des barrières techniques plus hautes et une représentation plus faible dans les modèles) crée une double peine pour les éditeurs francophones. C’est un enjeu de souveraineté éditoriale : quand l’IA devient une commodité accessible à tous, c’est le contenu structuré et lisible qui fait la différence, pas le modèle utilisé. Les solutions sont les mêmes que pour le reste (HTML sémantique, RSS complet, endpoints JSON, Schema.org), mais l’urgence est plus grande. Un flux RSS en français bien structuré, avec des métadonnées Schema.org complètes, est peut-être le meilleur investissement qu’un éditeur francophone puisse faire pour exister dans l’écosystème IA.

Le mot de la fin

Le web n’a jamais été aussi riche pour les yeux et aussi pauvre pour les machines. Chaque animation, chaque interaction, chaque composant dynamique qui enrichit l’expérience humaine appauvrit la perception artificielle. Ce n’est la faute de personne en particulier : c’est le résultat de quinze ans d’optimisation pour un seul type de lecteur, l’humain derrière son écran, sans jamais anticiper qu’un autre type de lecteur arriverait.

Ce lecteur est arrivé. Et il ne voit pas grand-chose.

L’histoire se répète avec une régularité déconcertante. Le web Flash était éblouissant et invisible aux moteurs de recherche. Le web JavaScript est interactif et opaque aux IA. Dans les deux cas, la solution n’a pas été de revenir en arrière : personne ne renoncera aux SPA comme personne n’a renoncé à la vidéo en ligne. La solution a été, et sera, de construire des ponts : des standards, des formats alternatifs, des couches de compatibilité qui permettent au contenu d’exister simultanément pour tous ses lecteurs.

En attendant ces ponts, le vieux web sémantique (celui des balises <article> et des flux RSS, celui du HTML lisible et du contenu complet au chargement) prend une revanche inattendue. Il n’a jamais été aussi moderne que depuis qu’il est redevenu lisible par les machines.

Le paradoxe a ceci de réjouissant : ce qui est bon pour les IA est bon pour l’accessibilité humaine, bon pour les lecteurs d’écran, bon pour les connexions lentes, bon pour l’archivage, bon pour le web ouvert. Optimiser pour les machines, c’est paradoxalement revenir aux fondamentaux du web. Tim Berners-Lee avait peut-être raison depuis le début. Il aura simplement fallu trente-cinq ans (et l’arrivée des IA) pour que le web s’en souvienne.