Il existe deux mots français pour désigner la même opération sur un texte, et leurs deux publics ne se croisent jamais.

Le premier est « balise Hn ». Il appartient au SEO, il pèse 210 recherches par mois en France en moyenne sur douze mois, et la première page de résultats lui répond par huit pages de définition qui expliquent toutes la même chose : H1 pour le titre principal, H2 pour les grandes parties, hiérarchie logique, mots-clés dans les titres. La moyenne mérite d'ailleurs une réserve, parce qu'un pic isolé à 1 000 en septembre 2025 la tire vers le haut : les derniers mois relevés oscillent entre 50 et 90.

Le second est « chunking ». Il pèse 480 recherches par mois, avec une série mensuelle nettement plus stable, et sa page de résultats ne contient aucune page SEO. On y trouve l'Association des Sports de Mémoire, Teach Up, un projet de l'Agence nationale de la recherche, et de l'autre côté IBM, Pinecone, Databricks et le blog de la direction interministérielle du numérique. La psychologie cognitive d'un côté, l'ingénierie des systèmes de récupération de l'autre.

Les deux SERP décrivent le découpage d'un contenu en blocs. Aucun domaine ne figure sur les deux. Et l'AI Overview que Google sert sur « chunking » se termine par une question adressée au lecteur : « Souhaitez-vous approfondir le chunking pour l'apprentissage personnel ou sa mise en œuvre technique pour les architectures d'IA et de RAG ? » Le sigle RAG désigne la génération augmentée par récupération, c'est-à-dire l'architecture qui va chercher des morceaux de documents pour alimenter un modèle avant qu'il réponde. Deux sens proposés par Google, donc, et votre page web n'est ni l'un ni l'autre.

C'est exactement le trou dont cet article s'occupe. Le titre de section a changé de métier sans que la littérature SEO française l'enregistre.

Ce que j'ai mesuré le 17 août 2026. J'ai récupéré les huit résultats organiques de « balise hn », compté leurs titres, cherché dans leur texte toute phrase reliant les titres de section aux moteurs génératifs, relu ce que Google publie sur les deux sujets, lu le code source de la bibliothèque de découpage la plus utilisée, et fait passer une de ces pages dans un convertisseur de récupération pour voir ce qui en sort. Les commandes sont dans l'article.

Le trou éditorial, mesuré au niveau de la phrase

Les huit pages organiques de « balise hn » ont toutes répondu 200 : thomascubel.com, semji.com, campusnumerique.auvergnerhonealpes.fr, performics.com, webrankinfo.com, benjaminthiers.net, webconversion.fr et digidream-communication.com.

J'ai découpé chaque page en phrases de plus de 40 caractères, en excluant les menus, les en-têtes et les pieds de page, puis compté les phrases contenant à la fois un mot du sujet (balise Hn, balise H1 à H6, titre de section, sous-titre, hiérarchie, heading) et un mot des moteurs génératifs.

Le résultat tient en une ligne : 472 phrases, zéro co-occurrence.

Le contrôle qui donne sa valeur au zéro est le suivant. Un grep, c'est-à-dire une simple recherche de motif dans le texte, appliqué cette fois au niveau de la page et non de la phrase, trouve bien six mentions d'IA réparties sur trois des huit pages. Elles sont toutes hors sujet : un bandeau produit chez Semji qui propose d'être visible sur ChatGPT, une entrée de menu chez Campus Région du numérique qui renvoie vers les métiers de l'intelligence artificielle, une liste d'articles connexes chez Performics qui mentionne DeepSeek. Aucune ne se trouve dans le corps de l'article. C'est le piège classique de ce genre de mesure, et il faut toujours imprimer le contexte avant de conclure.

Huit pages de référence sur les titres de section, et pas une phrase qui relie le sujet aux moteurs qui découpent aujourd'hui les pages en passages.

Google range l'ordre des titres parmi les choses à ne pas surveiller

L'AI Overview qui occupe la position 1 sur « balise hn » énonce trois bonnes pratiques. Deux méritent qu'on s'y arrête : « Garder une hiérarchie logique (ne pas sauter de niveau, comme passer d'un H1 à un H3) » et « Mettre des mots-clés importants dans les titres ».

Le guide de démarrage SEO de Google contient une section intitulée « Things we believe you shouldn't focus on ». Elle comporte neuf entrées, présentées sous forme de liste de définitions. Les voici dans l'ordre : les meta keywords, le bourrage de mots-clés, les mots-clés dans le nom de domaine ou l'URL, la longueur minimale ou maximale du contenu, sous-domaines contre sous-répertoires, le PageRank, la « pénalité » de contenu dupliqué, le nombre et l'ordre des titres, et le fait de croire que l'E-E-A-T est un facteur de classement.

Le verbatim de la huitième entrée :

Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.

Et la phrase qui suit : « There's also no magical, ideal amount of headings a given page should have. However, if you think it's too much, then it probably is. »

Autrement dit, la première bonne pratique récitée par l'AI Overview de Google figure dans la liste des choses dont Google écrit qu'il ne faut pas se préoccuper. Le résultat en position zéro contredit la documentation de l'éditeur qui le génère. Ce n'est pas une contradiction que j'infère : les deux textes sont publics et disent l'inverse l'un de l'autre sur le même point.

Trois autres entrées de cette liste de neuf ont déjà servi de colonne vertébrale à des articles de ce blog : le PageRank dans celui sur le maillage interne, la pénalité de contenu dupliqué dans celui sur le contenu dupliqué et la syndication, et l'E-E-A-T dans celui sur l'attribution au niveau du passage. Cette liste est un bon détecteur de sujets sur lesquels le marché français répète une consigne que Google a désavouée.

Le détail qui rend la chose gênante. J'ai compté les titres des huit pages. Les huit portent exactement un H1. Sept sur huit ne sautent aucun niveau ; la seule exception est Semji, avec un enchaînement H2 vers H4. Ces pages appliquent donc scrupuleusement la règle de hiérarchie, et c'est précisément la règle que la documentation range parmi celles qui n'ont pas d'effet. L'effort est réel, il porte simplement sur la mauvaise propriété.

Reste à savoir laquelle est la bonne.

Ce que dit la documentation IA de Google, et ce qu'elle ne dit pas

J'ai repris le geste habituel de ce blog sur la page « AI features and your website » de Google : récupération, suppression des scripts et des styles, extraction du corps hors menu de navigation, aplatissement, puis comptage.

Le corps fait 6 241 caractères. Les comptages :

chunk ............ 0
heading .......... 0
passage .......... 0
h1 / h2 .......... 0
structured data .. 2

Google ne mentionne donc pas les titres de section dans la page qui explique comment apparaître dans ses surfaces génératives. Il faut lire ce zéro dans les deux sens, comme les précédents relevés du même genre. Il n'établit pas que les titres sont sans effet. Il établit que Google ne publie aucune consigne de titrage pour ses surfaces IA, et donc que quiconque vend une méthode de titrage « optimisée pour les AI Overviews » ne s'appuie sur aucun texte de l'éditeur.

La mécanique se laisse pourtant observer ailleurs, dans le code que tout le monde utilise.

Le titre de section comme frontière de découpage

Un moteur génératif ne récupère pas des pages, il récupère des passages. C'est le point qu'établit l'article pilier de ce cluster sur le query fan-out et l'autonomie des passages. Reste la question que cet article laissait ouverte : où passe la coupure ?

La bibliothèque LangChain est le point d'entrée le plus documenté pour y répondre, parce que son code est public. Les fichiers utiles sont dans libs/text-splitters/langchain_text_splitters/, et il faut les lire sur le dépôt brut : la documentation publique est rendue en JavaScript et un grep sur le HTML ne trouve rien.

Le découpeur générique, celui qu'on obtient sans rien configurer, utilise ces séparateurs par défaut :

self._separators = separators or ["\n\n", "\n", " ", ""]

Paragraphe, ligne, espace, caractère. Aucune structure. Il coupe où il peut, dans cet ordre, jusqu'à tenir dans le budget.

Le même découpeur, réglé sur le Markdown, propose une liste très différente, et le commentaire du code se passe de traduction :

# First, try to split along Markdown headings (starting with level 2)
"\n#{1,6} ",
# End of code block
"```\n",
# Horizontal lines
"\n\\*\\*\\*+\n",
"\n---+\n",
"\n___+\n",
"\n\n",
"\n",
" ",
"",

Le titre de section est le premier séparateur essayé. Il passe avant le paragraphe, avant la ligne, avant tout le reste.

La cascade est la partie qu'il faut comprendre. Ces séparateurs sont essayés dans l'ordre, et on descend d'un cran chaque fois que les morceaux obtenus dépassent encore la taille visée. Si vos sections tiennent dans le budget, la coupure tombe sur vos titres, donc à un endroit que vous avez choisi. Si une section déborde, le découpeur passe au séparateur suivant et coupe sur un saut de paragraphe, c'est-à-dire n'importe où. La longueur de vos sections décide donc de qui choisit la coupure, vous ou l'outil. C'est la conséquence opérationnelle la plus directe de tout cet article, et elle ne figure dans aucune des huit pages de la SERP.

Le titre ne délimite pas seulement, il étiquette

La deuxième fonction est moins connue et plus intéressante. Le découpeur spécialisé dans le HTML, HTMLHeaderTextSplitter, décrit ainsi son travail :

Splits HTML content by detecting specified header tags and creating hierarchical Document objects that reflect the semantic structure of the original content. For each identified section, the splitter associates the extracted text with metadata corresponding to the encountered headers.

L'exemple donné dans le code est plus parlant que la définition. À partir d'un document contenant un H1 « Introduction », un H2 « Background » et leurs paragraphes, le découpeur produit des blocs dont voici deux :

contenu  : "Some background details here."
metadata : {"Main Topic": "Introduction",
            "Sub Topic": "Background"}

La phrase « Some background details here. » est parfaitement opaque hors contexte. Elle voyage pourtant accompagnée de ses deux titres de rattachement. La hiérarchie de titres est recopiée dans les métadonnées de chaque bloc, et elle suit le passage partout où il va.

C'est le point qui change la façon d'écrire un titre. Le titre de section est le seul élément de votre page qui accompagne le passage après extraction. Le reste de l'article, le fil de l'argumentation, le paragraphe précédent, tout cela disparaît. Le titre reste agrafé.

Un détail du code renforce encore l'exigence. Le découpeur Markdown a un paramètre strip_headers dont la valeur par défaut est True, documenté ainsi : « Strip split headers from the content of the chunk ». Le texte du titre est donc retiré du corps du bloc et conservé uniquement en métadonnée. Un titre qui porte une information indispensable à la lecture du paragraphe qui le suit peut donc laisser ce paragraphe orphelin dans le corps du bloc, alors même que le titre existe encore ailleurs dans la fiche.

La règle rédactionnelle qui en découle. Un titre de section doit fonctionner comme une étiquette autonome, lisible sans la page. « Les trois cas » ne dit rien une fois agrafé à un passage. « Les trois cas de blocage d'un robot IA » dit quelque chose. Cette exigence est proche de celle que Google formule depuis des années pour les ancres de lien, et que l'article sur le maillage interne détaille : lire l'ancre hors contexte et vérifier qu'elle se suffit. Le même test s'applique au titre de section, pour une raison mécanique différente.

Elle se distingue aussi de la consigne traitée dans l'article sur la FAQ et la mort du rich result FAQPage. Poser une question en clair dans un titre est une bonne idée quand la requête est une question. Rendre un titre autonome est une contrainte qui vaut pour tous les titres, y compris ceux qui n'ont aucune forme interrogative.

Ce que le pipeline reçoit réellement

Reste à vérifier ce qui survit au trajet. J'ai fait passer la première page de la SERP, thomascubel.com/balises-h1-h6-seo/, par un convertisseur de récupération public, celui de Jina, qui transforme une page HTML en Markdown comme le font les pipelines de récupération.

HTML source ....... 79 699 octets
Markdown reçu ..... 12 201 octets  (15,3 %)

Sur les 84,7 % perdus figurent la navigation, le pied de page, les scripts, la mise en page et toute la feuille de style. Ce qui subsiste :

Les sept titres de section de l'article ressortent en Markdown, quatre en ## et trois en ###. Ce compte correspond exactement aux quatre H2 et trois H3 que j'avais relevés dans le HTML de la page. La conversion n'en a perdu aucun.

Le H1, lui, ne devient pas un titre Markdown. Il devient un champ d'en-tête du document, à côté de l'URL et de la date de publication :

Title: Les Balises Hn en SEO : H1 - H6 - Thomas Cubel
URL Source: https://www.thomascubel.com/balises-h1-h6-seo/
Published Time: 2015-01-20T10:20:40+01:00

Le H1 sert donc d'étiquette au document entier, pas de frontière interne. Toute la discussion française sur l'unicité du H1 porte sur un élément qui, dans ce trajet, ne découpe rien. Ce sont les H2 et les H3 qui travaillent.

Le gras survit mais ne délimite rien. Le Markdown reçu contient 18 marqueurs de gras. Un passage en gras reste donc du gras, et ne devient jamais une frontière. C'est le sort réservé aux faux titres, ces paragraphes stylés en 24 pixels gras que produisent la plupart des constructeurs de pages et que l'œil humain lit comme des titres. Ils traversent la conversion en tant que texte emphasé, et le découpeur ne les voit pas. Le problème est suffisamment répandu pour que LangChain ait prévu une échappatoire : un paramètre custom_header_patterns permet de déclarer que **Titre** doit être traité comme un titre de niveau 1. Personne ne configurera cette échappatoire pour votre site.

C'est le même mécanisme que celui décrit dans l'article sur le rendu JavaScript, avec une nuance : ici le contenu est bien récupéré, c'est sa structure qui est perdue.

Ce que cet article refuse d'affirmer

LangChain n'est ni ChatGPT, ni Perplexity, ni AI Mode. Aucun de ces trois systèmes ne publie son pipeline de découpage. Ce que le code de LangChain établit, c'est la convention outillée : quand un ingénieur découpe des documents pour un système de récupération, le titre de section est le séparateur qu'on lui propose en premier, et la hiérarchie de titres est ce qu'on lui propose de conserver en métadonnée. C'est un usage dominant et documenté, pas une description du fonctionnement interne de Google. La même prudence s'applique ici que celle retenue à propos de la déduplication dans l'article sur le contenu dupliqué.

Je n'affirme pas non plus que soigner ses titres fait gagner des citations. Il faudrait un groupe témoin pour l'établir, et l'article sur les tests A/B en GEO explique pourquoi un avant-après ne suffit pas. Le raisonnement tenu ici est mécanique : si la coupure passe par les titres, alors les titres décident du contour des passages extraits. Cela vaut comme raisonnement sur le mécanisme, pas comme effet mesuré.

Enfin, le convertisseur utilisé pour la démonstration est un outil parmi d'autres. Un autre convertisseur produirait des chiffres différents. Il faut y lire le sort réservé aux différentes catégories d'éléments d'une page, et non un barème.

La checklist de structure d'article SEO

Cinq vérifications de structure d'article SEO, toutes réalisables sur une page existante.

Un. Vos titres visuels sont-ils de vraies balises. Comptez les titres du HTML brut et comparez au nombre de titres que l'œil identifie sur la page. Tout écart est un faux titre, invisible comme frontière.

curl -s VOTRE_URL | grep -o -E '<h[1-6][ >]' | sort | uniq -c

Deux. Chaque titre de section se suffit-il hors de sa page. Lisez-le seul, sans le titre de l'article et sans le paragraphe qui le précède. S'il commence par « Les trois », « Pourquoi c'est important » ou « Et ensuite », il ne porte rien.

Trois. Vos sections tiennent-elles dans un budget de découpage. Une section de 2 000 mots sera coupée par un séparateur de repli, à un endroit choisi par l'outil. Découper vous-même à l'échelle de la section revient à choisir la frontière.

Quatre. Le titre est-il redondant avec la première phrase de sa section. Puisque le texte du titre peut être retiré du corps du bloc, la première phrase doit rester lisible sans lui. Reprendre le sujet dans la première phrase relève moins de la répétition inutile que de l'autonomie du bloc.

Cinq. Ne perdez pas de temps sur l'ordre. Un H2 suivi d'un H4 ne pose aucun problème à Google, qui l'écrit noir sur blanc, et ne pose aucun problème à un découpeur, qui traite les niveaux comme des étiquettes emboîtées. La hiérarchie stricte reste utile aux lecteurs d'écran, ce qui est une raison suffisante de la respecter, mais ce n'est pas une raison de référencement.

Ce qu'il faut retenir des balises Hn en 2026

La balise Hn a longtemps été enseignée comme un dispositif d'annonce, chargé de dire au moteur de quoi parle la section et d'y loger un mot-clé. Google a désavoué la partie hiérarchique de cette doctrine dans sa propre documentation, et sa surface générative continue pourtant de la réciter en position 1.

Pendant ce temps, la fonction réelle du titre de section s'est déplacée. Il découpe le texte en passages et il les étiquette, et il est le seul élément de la page qui reste attaché à un passage une fois celui-ci extrait. Cela ne demande pas d'écrire autrement, cela demande d'écrire des titres qui tiennent debout tout seuls et des sections assez courtes pour que la coupure tombe là où vous l'avez mise.

Le vocabulaire du SEO appelle cela une balise Hn. Le vocabulaire des systèmes de récupération appelle cela une frontière de chunking. Les deux SERP ne se croisent toujours pas, et c'est très exactement l'écart dans lequel se logent les pages qui seront citées.

Si vous voulez savoir ce que vos pages deviennent une fois converties et découpées, c'est l'un des points que couvre notre audit GEO, et le vocabulaire complet est rassemblé dans le glossaire GEO.