HTML sémantique et IA : test d’attribution de source (partie 2)

Temps de lecture estimé : 7 minutes

Mon premier test sur le HTML sémantique et l'IA a déjà tranché un point : présenté dans un prompt, un tableau en <div> n'est pas moins bien compris par les LLM qu'un tableau sémantique. Pour ce second test, je me suis demandé ce qu'il se passerait si le contenu en question était noyé parmi d'autres sources concurrentes. Une structure en HTML sémantique aide-t-elle les modèles à attribuer correctement une information à la bonne source, plutôt qu'à une autre ?

Toujours pas de RAG, toujours pas d'extraction automatique (ce sera l'objet du prochain test), mais une lecture directe des documents par les LLM. Résultat : zéro erreur d'attribution sur 72 réponses, quelle que soit la structure du document.

Du document isolé aux sources concurrentes : pourquoi ce second test

Le premier volet de mes essais portait sur la lecture d'un document isolé, mais, au fond, si la sémantique devait faire une différence, c'était probablement dans un contexte plus exigeant : plusieurs sources mélangées, des chiffres proches. La structure de la page aiderait-elle alors le modèle à repérer l'information et à l'attribuer à la bonne source ?

Le défi posé ici rappelle une mécanique fondamentale en accessibilité numérique. Lorsqu'une personne navigue à l'aide d'un lecteur d'écran sur une interface agrégeant plusieurs contenus distincts, comme par exemple une page « produits » d'un e-commerce, celui-ci s'appuie sur la sémantique (<article>, <li>…) pour isoler et reconstituer chaque carte produit. En l'absence de structure claire, le lecteur d'écran restitue un flux continu de descriptions, de prix et de boutons « ajouter au panier » sans distinction. C'est précisément ce que formalisent les critères 9.1 à 9.4 du RGAA (nouvelle fenêtre) sur la structuration sémantique de l'information.

Les enjeux sont radicalement différents de ceux du premier test. Avant, le piège consistait à inverser une ligne ou une colonne au sein d'une même grille. Cette fois, le risque est d'amalgamer des documents entiers ou d'associer une métrique au mauvais numéro de source. Comme un utilisateur de lecteur d'écran pourrait associer un prix au mauvais produit sur une page mal structurée.

Protocole du test d'attribution de source

Pour ce test, j'ai envoyé quatre documents fictifs dans un seul prompt, comme une fenêtre de contexte déjà constituée par un système de récupération.

Document 1 : un texte générique sur les tendances SEO 2026, sans donnée chiffrée exploitable.

Document 2 : une étude de cas fictive sur un « Site C », avec un trafic de 42 000 visites par mois et un taux de conversion de 2,9 %.

Document 3 : le tableau de comparaison Site A / Site B utilisé depuis le premier test, en version sémantique ou en <div> selon la condition testée. Le Site A y affiche 45 000 visites et un taux de conversion de 3,2 %.

Document 4 : une interview générique sur les indicateurs à suivre, sans valeur chiffrée rattachée à un site précis.

La proximité entre les chiffres du Site C (document 2) et du Site A (document 3) constituait le piège du test. Leurs taux de conversion (2,9 % et 3,2 %) sont les deux valeurs les plus proches de tout le jeu de données. Si un modèle devait confondre une source avec une autre, c'est là que ça se jouerait.

Une limite à poser tout de suite : dans mon test, le document contenant les vraies données occupe toujours la troisième position. Un effet de position (les modèles accordant plus ou moins d'attention selon la place d'un document dans le contexte) n'a pas pu être exclu.

Trois questions pour mesurer l'attribution par les LLM

Trois questions étaient posées, toujours via API à ChatGPT, Gemini, Claude et en direct pour Gemma en local. Chacune vérifiant un aspect différent de l'attribution.

La première demandait quel site, parmi tous les documents, présentait le meilleur taux de conversion, avec la valeur exacte et le numéro du document source. C'est le test le plus direct : retrouver la bonne réponse (Site A, 3,2 %, document 3) plutôt que de se laisser distraire par le Site C.

La deuxième ciblait le distracteur lui-même : « quel est le taux de conversion du Site C ? ». Si un modèle confondait les sites, c'est là que ça se verrait.

La troisième demandait un résumé de tous les taux de conversion mentionnés dans les quatre documents, avec la source de chaque valeur. Question plus exigeante que les deux premières, parce que le modèle devait restituer l'ensemble, pas seulement la bonne réponse à une question isolée.

Chaque question a été posée trois fois par modèle et par version (température 0, appels indépendants, ordre des appels randomisé pour chaque modèle), soit 72 réponses au total.

Le protocole complet est disponible : méthodologie du test, prompts, code source et sorties brutes (PDF) téléchargement.

Résultats : zéro erreur d'attribution sur 72 réponses

Zéro erreur. Sur les quatre modèles et les deux versions du document 3, aucune confusion entre sources.

Résultats de l'attribution de source

Modèle	Version sémantique (3 questions × 3 runs)	Version en <div> (3 questions × 3 runs)
Claude Sonnet 4.6	9/9 correctes	9/9 correctes
GPT-4o	9/9 correctes	9/9 correctes
Gemini 2.5 Flash	9/9 correctes	9/9 correctes
Gemma 27B	9/9 correctes	9/9 correctes

Voici, à titre d'exemple, la réponse de Claude au test 1 (version sémantique) :

Le site présentant le meilleur taux de conversion est le Site A, avec un taux de 3,2 %. Source : Document 3. À titre de comparaison, le Site B affiche 1,8 % et le Site C (Document 2) affiche 2,9 %, ce qui confirme que le Site A obtient le taux de conversion le plus élevé parmi tous les sites mentionnés dans les documents fournis.

Trois sites, trois valeurs, trois sources correctement identifiées. Claude est d'ailleurs le seul modèle à avoir spontanément mentionné les trois sites dans sa réponse ; les trois autres se sont contentés de donner la bonne réponse avec le bon numéro de document. Les deux comportements sont justes.

Sur le test de résumé avec attribution, les quatre modèles ont chacun produit une liste complète des trois sites avec la valeur et le numéro de document correct pour chacun.

Ce que ce test dit sur le HTML sémantique et l'IA, et ce qu'il ne dit pas

Encore une fois, il faut délimiter.

Une fois les documents réunis dans leur contexte, les quatre modèles testés ont retrouvé les bonnes valeurs et les ont attribuées au bon document. La structure HTML n'a rien changé. Ce résultat rejoint celui du premier test et le prolonge : la compréhension directe n'était pas affectée par la structure, l'attribution de source ne l'est pas non plus.

C'est un constat que je n'avais pas forcément anticipé. Je m'attendais à ce que la complexité supplémentaire (plusieurs sources, un distracteur à chiffres proches) finisse par créer une différence. Ça n'a pas été le cas.

Mais ce test reste modeste. Les quatre documents sont courts. Le distracteur reste un seul document avec un seul point de friction. Un test avec davantage de distracteurs ou des documents plus longs aurait pu donner un résultat différent.

Et surtout, je n'ai toujours testé que la dernière étape de la chaîne : la génération. Les documents étaient directement injectés dans le prompt, sans passer par l'extraction, le découpage ou la recherche automatique qui précèdent normalement cette étape dans un vrai système de recherche augmentée.

Autrement dit, si la sémantique HTML produit un avantage quelque part dans cette chaîne, ce n'est probablement pas à l'étape où le modèle lit et répond. C'est précisément ce qui m'a poussée à regarder l'étape d'avant : l'extraction automatique du contenu par un parseur, avant même qu'un LLM entre en jeu. C'est l'objet du troisième article de cette série.