HTML sémantique et IA : avant le LLM, le test des extracteurs (partie 3)

Temps de lecture estimé : 12 minutes

Dans mes deux premiers tests, je n'ai mesuré aucune différence entre un tableau HTML sémantique et son équivalent en <div>, une fois le contenu directement fourni à un LLM. Restait à vérifier ce qui se passe avant : quand un outil doit extraire ce même contenu automatiquement. C'est ce que teste ce troisième article. Résultat : certains outils perdent des données quand le tableau est en <div>, d'autres conservent les valeurs mais aplatissent leur structure, et un dernier échoue quelle que soit la structure.

HTML sémantique et GEO : une promesse d'optimisation à vérifier

Une idée revient régulièrement dans les articles consacrés au GEO : le HTML sémantique, indispensable pour l'accessibilité numérique, favoriserait également la visibilité dans les moteurs de recherche génératifs. Pourtant, peu de sources l'étayent. L'étude la plus citée sur le sujet est Aggarwal et al. (nouvelle fenêtre), celle qui a donné son nom au GEO. Elle ne teste jamais le HTML : elle travaille sur du texte déjà nettoyé. HtmlRAG (nouvelle fenêtre), qui semble plus proche du sujet, compare le HTML brut au texte extrait, mais jamais un HTML sémantique à un HTML « sale ».

J'ai donc tenté d'y voir un peu plus clair.

Le modèle et l'extracteur : deux étapes, pas le même travail

Dans mes deux premiers tests, le HTML sémantique est-il vraiment utile aux IA et le HTML sémantique change-t-il la donne quant à l'attribution de sources, j'ai donné directement le HTML aux modèles. Ceux-ci le lisaient via un prompt et le comprenaient, ou pas.

Mais ce n'est pas ainsi que ça se passe pour un moteur de recherche générative et dans la plupart des systèmes RAG. L'IA, qu'il s'agisse de ChatGPT, de Gemini ou encore Claude, ne récupère pas directement le contenu sur le site web pour construire ses réponses. Avant que le LLM ne voie quoi que ce soit, un extracteur passe en amont. C'est lui qui décide ce qui est du contenu et ce qui est du bruit (publicités, bannières, menus). C'est lui aussi qui transmet au modèle ce qu'il juge utile.

C'est cette étape qu'il me fallait tester.

Protocole de test : 6 parseurs face aux balises sémantiques et aux div

J'ai débuté ce troisième test avec deux outils, mais lorsque les résultats ont divergé, j'en ai ajouté quatre. Au final, ce test sur l'extraction du HTML par les parseurs a mobilisé six outils que j'ai répartis en deux catégories.

Les extracteurs de contenu principal. Au nombre de quatre :

• readability-lxml (nouvelle fenêtre) (inspiré du mode lecture de Firefox)
• trafilatura (nouvelle fenêtre) (utilisé notamment par HuggingFace)
• newspaper4k (nouvelle fenêtre) (orienté articles de presse)
• jusText (nouvelle fenêtre) (issu de recherches sur les corpus linguistiques)

Ces extracteurs décident quoi garder et quoi jeter d'une page ; c'est ici que la perte de données peut se produire.

Les convertisseurs HTML vers Markdown :

• html2text
• markdownify

Ils transforment la représentation, mais ne filtrent pas le contenu. Avec eux, la question n'est pas « qu'est-ce qui est conservé ? » mais « sous quelle forme est-ce restitué ? ».

Le contenu testé est le même que dans les articles précédents : le tableau simple comportant cinq indicateurs pour deux sites, et le tableau complexe entouré de « bruit de page » (publicités, menu, bannière). Chacun existe en deux versions, sémantique et <div>, avec un contenu toujours identique.

Pour chaque combinaison, j'ai voulu tester quatre critères :

• la structure tabulaire est-elle conservée à l'extraction ? Ce qui garantit que la relation entre une valeur et son intitulé reste lisible pour l'étape suivante, sans avoir à la reconstituer.
• la légende est-elle conservée ? Elle donne le contexte du tableau à qui n'a jamais vu la page d'origine.
• combien de valeurs attendues sont retrouvées ? L'information a-t-elle simplement disparu au passage.
• est-ce que du bruit de page a fui dans l'extraction ? La publicité ou le menu se sont-ils invités dans le contenu censé être filtré.

La méthodologie complète de ce test, avec les prompts exacts et le HTML source, est disponible dans un PDF téléchargeable (nouvelle fenêtre, format PDF), comme pour les articles précédents de la série.

Résultats : le HTML sémantique protège-t-il la donnée ?

Quatre extracteurs, deux comportements opposés, et un troisième cas de figure auquel je ne m'attendais pas.

Résultats des extracteurs : la div ne se comporte pas pareil selon l'outil

Je m'attendais à une dégradation partielle. Pour certains, le résultat fut pire.

• Trafilatura conserve toutes les données, que ce soit avec le tableau en HTML sémantique ou avec le tableau en <div>. Cependant, il ne reconnaît pas ce dernier comme étant un tableau.
• Readability perd des données sur les versions en <div> : 1 valeur sur 5 sur le tableau simple, 5 valeurs sur 7 sur le complexe, mais il en garde au moins une partie.
• Newspaper conserve les données en version sémantique. En revanche, en version <div>, il ne retrouve strictement rien. Le tableau a tout simplement disparu de sa sortie, comme s'il n'existait pas.
• JusText ne restitue rien, ni en sémantique, ni en <div>. Je m'y attendais : sa documentation le décrit comme un outil « conçu pour préserver principalement le texte contenant des phrases complètes ». Les cellules d'un tableau, avec leurs chiffres, n'entrent pas dans ce critère. Ce résultat me semble toutefois intéressant en lui-même : certains extracteurs ne sont tout simplement pas faits pour du contenu tabulaire.

Résultats des quatre extracteurs de contenu

Cas	Version	Extracteur	Structure	Légende	Valeurs
Tableau simple	Sémantique	readability	Oui	Oui	5/5
Tableau simple	Sémantique	trafilatura	Oui	Non	5/5
Tableau simple	Sémantique	newspaper	Non	Oui	5/5
Tableau simple	Sémantique	jusText	Non	Non	0/5
Tableau simple	<div>	readability	Non	Non	1/5
Tableau simple	<div>	trafilatura	Non	Non	5/5
Tableau simple	<div>	newspaper	Non	Non	0/5
Tableau simple	<div>	jusText	Non	Non	0/5
Complexe + bruit	Sémantique	readability	Oui	Oui	7/7
Complexe + bruit	Sémantique	trafilatura	Oui	Non	7/7
Complexe + bruit	Sémantique	newspaper	Non	Oui	7/7
Complexe + bruit	Sémantique	jusText	Non	Non	0/7
Complexe + bruit	<div>	readability	Non	Non	5/7
Complexe + bruit	<div>	trafilatura	Non	Non	7/7
Complexe + bruit	<div>	newspaper	Non	Non	0/7
Complexe + bruit	<div>	jusText	Non	Non	0/7

Convertisseurs Markdown : la perte de la structure tabulaire

Pour les convertisseurs, le résultat est différent : les deux retrouvent toutes les valeurs, qu'elles soient présentées dans du HTML sémantique ou en <div>.

Cependant, ce qu'ils font de ces données diffère selon la structure. 

Avec du HTML sémantique et <table>, les lignes et les colonnes restent explicitement représentées dans le Markdown produit. Le résultat donne un vrai tableau, avec des séparateurs et des pipes. 

Avec des <div>, bien que les valeurs soient conservées, elles sont retranscrites sous forme linéaire. Cela signifie que les relations entre un indicateur et sa valeur doivent obligatoirement être inférées, ce qui constitue une fragilité supplémentaire.

À noter : sur les cas complexes, readability et les deux convertisseurs Markdown ont également conservé des éléments de bruit de page dans leurs sorties. trafilatura et newspaper ne l'ont pas fait dans ce protocole.

Résultats des deux convertisseurs HTML vers Markdown

Cas	Version	Convertisseur	Structure	Légende	Valeurs
Tableau simple	Sémantique	html2text	Oui	Oui	5/5
Tableau simple	Sémantique	markdownify	Oui	Oui	5/5
Tableau simple	<div>	html2text	Non	Non	5/5
Tableau simple	<div>	markdownify	Non	Non	5/5
Complexe + bruit	Sémantique	html2text	Oui	Oui	7/7
Complexe + bruit	Sémantique	markdownify	Oui	Oui	7/7
Complexe + bruit	<div>	html2text	Non	Non	7/7
Complexe + bruit	<div>	markdownify	Non	Non	7/7

Les résultats détaillés sont disponibles dans le PDF de méthodologie (nouvelle fenêtre, format PDF).

Le piège du template : quand l'enveloppe HTML fausse l'extraction

En relisant mes résultats, je me suis rendue compte que je n'avais pas utilisé le même script entre mon tout premier test, qui ne comportait que readability et trafilatura, et le second test. Mon premier script encapsulait le tableau dans une page complète avec <header>, navigation et <footer>. Le nouveau l'avait placé dans un <article> minimal.

C'était une erreur, mais cette dernière m'a permis de noter autre chose : le contexte HTML environnant semblait modifier le résultat sur le tableau en <div>.

Pour le vérifier, j'ai relancé quelques tests avec le même tableau dans trois contextes :

• Une page complète avec navigation et footer ;
• Un article minimal ;
• Le tableau en <div> seul, sans rien autour.

Dans ces conditions, Readability passe de 4 valeurs conservées sur 5 dans le cadre de l'article minimal à 1 sur 5 pour la page complète. Trafilatura tombe, lui, de 5 sur 5 sur la page complète à 0 sur 5 pour le tableau seul.

Cela voudrait dire qu'un tableau en <div> peut être sensible au contexte HTML qui l'entoure (structure éditoriale, densité de contenu ou navigation) au point de passer de quasiment lisible à totalement invisible selon ce qu'on met autour de lui.

Le tableau sémantique, dans les configurations que j'ai testées, n'a pas montré cette même sensibilité.

Une précision avant de conclure : les six outils testés ne sont probablement pas ceux utilisés en production par ChatGPT, Claude ou Gemini. En revanche, ils représentent des familles d'extracteurs encore largement utilisées dans les pipelines RAG, les outils d'analyse de contenu et de traitement documentaire vibecodé. L'objectif n'est donc pas d'identifier le pipeline d'un moteur donné, mais de montrer que le choix de l'extracteur peut modifier les données transmises au modèle.

Bilan : HTML sémantique, GEO et accessibilité, trois questions distinctes

Jusqu'à présent, on affirmait que le HTML sémantique aidait les IA à mieux comprendre le contenu et, par conséquent, servait le GEO. Aujourd'hui, je peux dire que ce n'est pas tant le modèle qui a besoin de la sémantique : ce sont certains extracteurs et convertisseurs pour lesquels la structure native détermine ce qui est conservé, et surtout la manière dont les relations entre données restent explicites. Les extracteurs s'en servent pour décider quoi garder dans une page, les convertisseurs pour préserver les relations entre entités (littéralement, dans le cas des tableaux de données).

Pour une personne qui fait de l'intégration ou de l'accessibilité numérique, la recommandation qui s'ensuit n'a rien de neuf : un tableau de données doit être balisé.

Pour une IA qui code un site, ce n'est pas toujours si évident.

Pour finir, la sémantique n'est pas affaire de SEO/GEO. Une page, un contenu, correctement balisés avec des balises <head>, <main> ou encore <table>, servent avant tout l'utilisateur et l'accessibilité numérique. Ce n'est pas une aide pour les lecteurs d'écran à laquelle il faudrait chercher d'autres justifications.

Si j'avais des recommandations à faire à la suite de ces tests :

• Utiliser le HTML sémantique pour des données tabulaires ? Oui, sans hésiter. Dans ce protocole, c'est le seul choix qui a résisté aux six outils testés.
• Se passer de sémantique parce qu'un LLM comprend les <div> ? Non. La compréhension directe ne dit rien de ce qui arrive au contenu avant d'atteindre le modèle : parmi les extracteurs capables de restituer le tableau sémantique, deux perdent des données sur sa version en <div> ; jusText, lui, écarte les tableaux dans les deux cas.
• La sémantique garantit-elle une citation par une IA ? Allez savoir ! Ça n'a pas été testé ici, et personne ne peut sérieusement l'affirmer sans connaître les extracteurs utilisés par chaque moteur.
• Un outil qui dit auditer votre site le lit-il vraiment ? Ça dépend de ce qu'il utilise en interne pour le lire. Ce test montre que la réponse n'est jamais évidente par défaut.
• Quand vérifier votre pipeline ? Dés lors qu'une donnée est critique : tarifs, comparatifs, fiches produits, documentation.