Le HTML sémantique est-il vraiment utile aux IA ? Mon test sur les tableaux de données (partie 1)

Temps de lecture estimé : 13 minutes

Et si le HTML sémantique n'était pas si important pour les IA génératives ? On répète souvent que l'accessibilité numérique profite à la fois au SEO et au GEO et qu'un tableau correctement balisé aide à la fois les lecteurs d'écran et les modèles tels que ChatGPT, Claude ou encore Gemini.

J'ai donc comparé un tableau en HTML sémantique avec un tableau équivalent réalisé uniquement en <div>. Résultat : les modèles ont compris les deux versions de manière identique. Une conclusion contre-intuitive qui m'a obligée à nuancer un peu mes convictions.

Du SEO classique au GEO en passant par l'accessibilité : ce que l'on suppose sur la sémantique

Dans le milieu du SEO/GEO, on répète souvent que le HTML sémantique aide les algorithmes à comprendre le contenu. Et c'est vrai, dans une certaine mesure, pour les moteurs de recherche classiques tels que Google.

Tout comme il est vrai que le HTML sémantique est essentiel pour offrir une expérience de navigation efficace aux personnes utilisant des lecteurs d'écran. Ainsi, une page balisée avec <header>, <main> et <footer> permet à l'utilisateur de repérer les grandes zones de la page et d'aller plus vite vers celle qui l'intéresse.

Depuis quelque temps, en vérité depuis qu'on parle de GEO, on lit également souvent que le HTML sémantique serait un avantage pour les IA. L'idée est assez intuitive : un tableau correctement balisé, une hiérarchie de titres cohérente ou encore un lien explicite donneraient aux IA davantage de repères. Comme pour les technologies d'assistance.

La déduction qui suit paraît logique : faire accessible serait également bon pour la visibilité d'un site dans les moteurs génératifs.

J'ai moi-même beaucoup employé cette métaphore pour faire entrer l'accessibilité numérique par la petite porte. Mais plus je l'utilisais, plus une question me revenait : est-ce réellement démontré ?

Alors j'ai fait des tests.

Les IA ont-elles vraiment besoin du HTML sémantique pour comprendre un tableau ?

J'ai d'abord voulu savoir si, dans le cas des tableaux de données, une structure en HTML sémantique aidait vraiment les IA pour la compréhension et l'interprétation.

Ou si, au contraire, un tableau mal balisé était voué à être « mal vu ».

Pour ce test, j'ai construit un même tableau en deux versions : l'une sémantique (version A), l'autre composée de <div> uniquement (version B).

Ce tableau portait sur la comparaison de deux sites web sur cinq indicateurs SEO (voir ci-dessous).

Un point important à mentionner : aucun site ne gagne sur tous les critères.

En effet, si un site était meilleur partout, n'importe quel modèle répondrait juste en repérant une colonne uniformément meilleure sans avoir besoin de comprendre la structure du tableau.

Avec ce test, répondre correctement demandait aux IA d'associer chaque valeur à sa ligne et à sa colonne.

Tableau de test : comparaison des performances SEO

Cette version est la version A du test (tableau HTML sémantique, avec <caption>, <thead> et <th scope>).

Comparaison des performances SEO de deux sites fictifs analysés en juin 2026

Indicateur	Site A	Site B
Pages indexées	870	1 250
Trafic organique mensuel	45 000 visites	38 000 visites
Score Core Web Vitals	68/100	92/100
Taux de conversion	3,2 %	1,8 %
Nombre de domaines référents	340	180

La méthodologie du test

Le but était d'interroger quatre modèles :

• Claude Sonnet 4.6
• GPT-4o
• Gemini 2.5 Flash
• Gemma 27B (exécuté en local sur mon serveur)

Afin d'éviter toute contamination entre les tests, j'ai réalisé tous les appels via API. Contrairement à une interface de chat classique (comme ChatGPT), où la mémoire de conversation peut influencer les réponses suivantes, cette approche garantit que chaque requête reste totalement indépendante.

Pour chaque version du tableau (A et B), j'ai posé quatre questions distinctes à chaque modèle :

• L'extraction brute : vérifier que les chiffres sont bien récupérés sans erreur.
• Le raisonnement avec arbitrage : évaluer si le modèle pèse correctement des critères contradictoires.
• La question ciblée : vérifier qu'une valeur précise est correctement associée à sa ligne et sa colonne.
• Le résumé : observer si les différences entre les deux sites sont bien identifiées.

Pour chacune des questions, chaque modèle était interrogé deux fois : une fois avec la version A du tableau, une fois avec la version B. Soit 32 tests au total.

Protocole détaillé : versions, paramètres et reproductibilité

Modèles et versions utilisés (juillet 2026) :

• Claude Sonnet 4.6 : API Anthropic, temperature: 0, max_tokens: 2048
• GPT-4o : API OpenAI, temperature: 0, max_tokens: 2048
• Gemini 2.5 Flash : API Google AI, temperature: 0, max_tokens: 2048
• Gemma 27B : exécution locale via llama-server, temperature: 0, max_tokens: 3500

Chaque appel était indépendant (pas de mémoire de conversation). Les prompts suivaient un format identique pour tous les modèles : le contenu HTML brut du tableau suivi d'une consigne unique. Le code Python des tests et les sorties brutes des 96 appels sont disponibles sur demande.

Les résultats

Sur les quatre modèles et les quatre questions, je n'ai noté aucune différence entre les deux tableaux. Les IA ont toutes réussi à extraire les chiffres, à réaliser un arbitrage sur la meilleure performance globale en pesant correctement les critères contradictoires et à répondre correctement à la question ciblée. Le résumé était tout aussi complet, d'un côté comme de l'autre.

Résultats de la comparaison

Critère	Tableau sémantique	Tableau en div
Extraction des données	Exacte (4/4 modèles)	Exacte (4/4 modèles)
Erreurs de chiffres ou inversions	Aucune	Aucune
Compréhension des relations ligne/colonne	Bonne (4/4)	Bonne (4/4)
Arbitrage sur signal mixte	Cohérent (4/4)	Cohérent (4/4)
Exactitude sur les questions ciblées	Correcte (4/4)	Correcte (4/4)
Qualité du résumé	Complet (4/4)	Complet (4/4)

Conclusion du test initial : aucune différence mesurable entre les deux approches.

Ce résultat rappelle une règle de prudence technique élémentaire : transposer aveuglément des bonnes pratiques d'un domaine à un autre est risqué. Restructurer des données en HTML sémantique reste indispensable pour l'accessibilité et utile pour le SEO classique. Mais justifier ce chantier par des gains en GEO, c'est confondre une analogie séduisante avec un mécanisme prouvé.

Cependant ce premier test a fait naître d'autres questions chez moi :

• et si le tableau était trop simple ?
• et si les appels se contaminaient quand même entre eux ?
• et si c'était le hasard d'une seule génération ?
• et que se passerait-il si la structure du tableau se complexifiait ?

Il fallait que je renforce mon protocole !

Itérations et tests complémentaires

Premier test : un tableau trop simple ?

Cinq lignes de données, c'était sans doute le cas le plus favorable pour des modèles qui lisent du texte brut : les valeurs sont facilement associables même sans structure.

Pour ce nouveau test, j'ai donc complexifié le tableau : dix lignes de données réparties en trois groupes (acquisition, performance technique, conversion). Chacun des groupes ayant son propre signal mixte.

J'ai également entouré les deux tableaux d'un vrai même bruit de page : un menu, une bannière cookies, un encart publicitaire, des articles connexes avec leurs propres chiffres sans rapport avec le tableau.

Résultat : cette fois encore, aucune différence sur l'extraction, le ciblage et le résumé. Et l'ignorance systématique du bruit environnant. Une seule petite divergence est apparue sur le test d'arbitrage chez ChatGPT. Cependant, la question n'ayant pas de réponse absolue et avec une seule exécution, j'ai interprété ça comme un aléa de génération.

Test de contamination entre appels

Là aussi, je ne pouvais affirmer qu'il n'y avait pas de contamination sans tester. J'ai donc construit un test minimal en ajoutant à mes tableaux un code de projet fictif avec une valeur différente selon la version (4471 et 9902) et une seule question à mes prompts : quel est le code de référence du projet. Aucun modèle ne pouvait connaître la valeur sans lire le contenu qu'on venait de lui soumettre. Si un modèle avait répondu 4471 pour la version B, cela aurait signifié qu'une trace du premier appel s'était glissée dans le second.

Résultat : sur les quatre modèles et les deux versions, chaque réponse correspondait à la valeur de sa propre version. À cette petite échelle, il n'y avait donc pas de contamination.

Test de reproductibilité avec 5 itérations

Même une pendule cassée donne l'heure exacte deux fois par jour. J'ai donc décidé de répéter le test d'arbitrage cinq fois par modèle et par version pour éliminer le hasard. J'ai également demandé à chaque réponse de se terminer par un verdict formaté. C'était plus sûr et plus simple pour vérifier les résultats.

Résultat : les modèles sont tous restés stables sur leur résultat. Même ChatGPT a conservé son verdict dans les deux versions, cinq fois sur cinq. La divergence que j'avais notée lors du premier test était bien un aléa de génération, pas un effet de la structure HTML.

Test sur un tableau à structure complexe

Le critère 5.7 du RGAA (Référentiel général d'amélioration de l'accessibilité) prévoit que pour les tableaux à en-têtes multiples ou à cellules fusionnées, l'usage du scope peut ne plus suffire. Dans les cas complexes, la bonne pratique consiste donc à associer chaque cellule de données à ses en-têtes avec les attributs id et headers.

On retrouve aussi cette idée dans certains guides et discours consacrés au GEO : rendre explicites les relations entre données aiderait les LLM à interpréter un contenu complexe. Cette hypothèse me paraissait suffisamment crédible pour être testée.

J'ai donc construit un tableau à double croisement, quatre trimestres en ligne, deux sites et deux métriques. Toutes les valeurs étaient différentes mais volontairement proches les unes des autres. Ainsi, une mauvaise association entre une ligne, une colonne et une valeur devait produire une réponse fausse, identifiable comme telle, plutôt que comme une coïncidence susceptible de masquer l'erreur.

Le tableau A avait des id et des headers explicites sur chaque cellule, le tableau B étant toujours une version en <div>.

Voici le tableau utilisé pour ce test (version A, avec id/headers et en-têtes fusionnés) :

Trafic organique et taux de conversion par trimestre et par site, année 2026

Trimestre	Site A		Site B
	Trafic organique	Taux de conversion	Trafic organique	Taux de conversion
T1 2026	32 000	2,1 %	28 000	3,4 %
T2 2026	35 000	2,4 %	30 000	3,1 %
T3 2026	41 000	2,9 %	33 000	2,8 %
T4 2026	45 000	3,2 %	38 000	1,8 %

Les valeurs sont volontairement proches d'une case à l'autre : au T3, le taux de conversion du site A est 2,9 %, celui du site B est 2,8 %. Répondre à « quel est le taux de conversion du site B au T3 ? » exigeait de croiser correctement la ligne et la colonne. Une erreur d'association aurait produit 2,9 % (site A, même ligne) ou 3,1 % (site B, trimestre précédent), pas 2,8 %.

Résultat : tous les modèles ont parfaitement répondu sur les deux tableaux. Que ce soit sur l'extraction ou le résumé. Sur les questions ciblées : « quel est le taux de conversion du site B au T3 2026 ? » et « quel est le trafic organique du site A au T4 2026 ? » avec des chiffres entourés de valeurs proches et plausibles pour les cases voisines, tous les modèles ont répondu juste.

Ce que dit ce petit test sur le HTML sémantique et les IA

Et ce que ça ne dit pas surtout...

Il y a au moins quatre choses différentes qu'on peut mesurer quand on parle de « compréhension par une IA » :

• la compréhension d'un contenu qu'on lui donne directement à lire ;
• l'extraction correcte de sa structure ;
• la sélection de ce contenu comme source parmi d'autres ;
• la citation explicite dans une réponse générée.

Ce premier test n'avait pas pour but d'aborder les deux derniers points. On peut certes penser qu'un contenu correctement interprété a davantage de chances de pouvoir constituer une source. Mais cela reste une hypothèse.

Mon test évalue uniquement l'effet de la structure HTML sur l'interprétation d'un contenu fourni au modèle. Il ne dit rien sur sa découverte, son classement ni sur sa citation par un moteur conversationnel.

Et sa conclusion est limpide : la structure HTML sémantique n'a produit aucune différence mesurable dans la justesse des réponses fournies par les LLM testés. Y compris sur une structure complexe.

C'est pour moi, un résultat contre-intuitif. J'ai en effet souvent répété que la sémantique aidait les machines à comprendre. Et je le pensais réellement. Ce test ne me permet pas d'affirmer l'inverse, mais il m'oblige à nuancer : dans les conditions de mon expérience, les modèles ont su reconstruire correctement la logique du tableau, même sans HTML sémantique.

Le HTML sémantique est-il vraiment utile ?

Cela ne retire toutefois rien à l'utilité du HTML sémantique.

Pour l'accessibilité, un tableau de données doit exposer sa nature tabulaire et les relations entre cellules et en-têtes pour offrir une navigation pertinente. Une simple grille de <div>, sans sémantique ni relations entre les données, ne fournit aucunement les informations nécessaires.

De son côté, Google recommande l'usage d'un HTML clair et sémantique lorsque cela est possible. John Mueller a expliqué dans une vidéo dédiée (nouvelle fenêtre) que la sémantique pouvait aider Google à comprendre une page, sans toutefois en faire un facteur de classement direct.

De plus, mon test reste modeste : un seul jeu de données, un seul type de contenu, quatre modèles et un protocole limité, tout ceci à une date donnée. Il ne permet pas de dire comment un moteur de recherche ou un crawler exploiterait ces deux versions dans des conditions réelles, ni comment Google en particulier se comporterait face à elles sur la durée, dans un contexte d'indexation réelle. 

Pour répondre à cette dernière question, il faudrait publier deux pages avec un contenu sémantique et l'autre en <div>, les soumettre à l'indexation puis observer sur la durée. Je garde cette idée en réserve.

Les limites de mon test et ses enseignements

J'aimerais ajouter deux choses, ici, sans que celles-ci ne changent la conclusion du test.

La première concerne l'efficacité en tokens : le tableau sémantique, plus verbeux, a coûté davantage en tokens que son équivalent en <div>. C'est logique dans cette configuration, mais ça ne dit rien de ce qu'il se passe sur un site web avec l'ajout de CSS, d'attributs.

La seconde est que ce test ne mesure que la compréhension d'un contenu lorsqu'il est directement injecté dans un prompt. Et non pas tout ce qui se passe en amont (pipelines RAG pour Retrieval Augmented Generation) dans un usage réel lorsque le contenu web est transformé ou extrait par des « parseurs » automatiques qui ciblent certaines balises. 

C'est précisément l'objet d'un prochain test de cette série : l'extraction automatique du contenu par un parseur, avant même qu'un LLM entre en jeu.

En définitive, cette expérience me fait juste dire qu'on ne peut pas transposer aveuglément les règles de l'accessibilité et du SEO au monde de l'IA générative. C'est d'ailleurs ma méthode de travail : je ne formule jamais une recommandation SEO ou GEO sans l'avoir confrontée à un test. Quand l'affirmation tient, elle devient une action. Quand elle ne tient pas, on économise du temps et du budget sur ce qui ne produit aucun effet mesurable.

Mais cela ne change rien à ma conviction profonde : Accessibilité et SEO/GEO doivent être pensés ensemble. Si l'on sacrifie le premier au profit des seconds, le web n'avancera jamais dans le bon sens. Mais les penser ensemble, c'est aussi accepter de distinguer ce qui est prouvé de ce qui reste une intuition séduisante.