Google s’est récemment exprimé via John Mueller (que j’ai rencontré à Zurich lors d’un Search Central) et Danny Sullivan dans le podcast Google Search Central : selon eux, le chunking ne serait pas une approche réellement bénéfique.

Ils reconnaissent que la technique fonctionne aujourd’hui pour le GEO. Mais d’après Google, ce n’est pas une stratégie durable, et ça ne vaudrait donc pas le coup de retravailler son contenu pour l’adapter aux LLMs comme Gemini, ChatGPT ou Perplexity.

Comme tout bon SEO le sait, les déclarations de Google se prennent avec des pincettes…

Ce qui compte, c’est le terrain.

Le Chunking est il une technique pour optimiser SEO et GEO ?

Google utilise le passage indexing

D’un côté, on sait que Google utilise le passage indexing.

Concrètement, ça veut dire que Google est capable de ne pas évaluer une page uniquement comme un bloc entier, mais aussi d’identifier et de classer des passages précis à l’intérieur d’un contenu.

Une page peut donc se positionner grâce à un paragraphe très pertinent, même si lhe reste du contenu est plus large ou moins ciblé. Google ne “voit” plus seulement des pages, il voit aussi des morceaux de pages.

Partant de ce principe, je me dis que le chunking, qui est, par définition, la creation de blocs indépendants, semantiwquemrnt pertinent, digestible, etc, aide Google a identifier ses blocs pour le passage indexing. Si ca n’aide pas, ca ne peut pas heurter…

Les LLMs utilisent le sub document processing

De l’autre côté, les LLMs fonctionnent avec ce qu’on appelle du sub-document processing.

Au lieu d’indexer des pages entières, le moteur indexe des extraits spécifiques et granulaires. Un extrait, dans le jargon de l’IA, correspond à environ 5 à 7 tokens, soit 2 à 4 mots, converti par la suite en chiffres.

Lorsque vous interrogez un système de sous-documents, il ne récupère pas 50 documents, mais environ 130 000 tokens des extraits les plus pertinents (environ 26 000 extraits) pour alimenter l’IA.

Concrètement, les moteurs génératives comme perplexity, chatgpt, gemini, etc, ne consomment pas une page comme un humain qui lit du haut vers le bas. Le contenu est découpé en segments (chunks), transformé en vecteurs, puis stocké dans des bases d’indexation sémantique.

Quand une question est posée, le modèle ne “cherche pas une page” :

il récupère les morceaux de texte les plus pertinents, peu importe d’où ils viennent.

Comment fonctionne le sub document processing ?

Un recent article – entretien de Search Engine Journal avec Jesse Dwyer de Perplexity explique comment ils utilisent le sub document processing.

Jesse parle de « Saturation de la Fenêtre de Contexte »(window context saturation) : Au lieu de récupérer 50 documents, le système récupère environ 26 000 snippets pertinents (soit ~130k tokens) pour remplir à ras bord la fenêtre de contexte du LLM.

L’objectif ?  « Saturer » le modèle avec tellement de faits pertinents qu’il n’a plus aucun espace « neuronal » disponible pour halluciner ou inventer des faits.

« La plus grande différence dans la recherche par IA aujourd’hui réside dans le traitement par ‘sous-documents’ (sub-documents) par opposition au document entier. […] L’approche ‘AI-first’ consiste à indexer des extraits spécifiques et granulaires plutôt que des pages entières. »

Jesse Dwyer

Difference entre l’indexation Google et l’indexation LLMs ?

Les moteurs de recherche traditionnels indexent l’ensemble du document. Ils examinent une page web, lui attribuent une note et l’archivent.

Lorsque vous utilisez un outil d’IA, celui-ci effectue une recherche classique, récupère les 10 à 50 premiers documents, puis demande au LLM de générer un résumé.

	Indexation Traditionnelle (Google / « Whole-Document »)	Indexation IA Native (Perplexity / « Sub-Document »)
Unité d’Indexation	L’URL (La Page Web). Le moteur indexe, note et classe un document HTML entier comme une unité indivisible.	Le « Snippet » Vectorisé. L’unité est un fragment de texte (env. 5-7 tokens ou 2-4 mots selon Dwyer) converti en vecteurs numériques (embeddings).
Méthode de Récupération (Retrieval)	Classement de Documents (Ranking). Le moteur identifie les 10 à 50 meilleures pagesbasées sur des signaux globaux (PageRank, Hn, Backlinks).	Recherche Vectorielle de Fragments. Le système ne cherche pas de pages, il « aspire » environ 26 000 snippets pertinents à travers tout le corpus indexé.
Volume de Données Traitées	Faible densité. L’IA (si utilisée en surcouche type « Bing Chat ») ne lit que le résumé des top documents. C’est l’approche « 4 Bing searches in a trenchcoat ».	Saturation de la Fenêtre de Contexte. Le but est de récupérer ~130 000 tokens pour remplir à 100% la fenêtre de contexte du LLM.
Gestion de l’Hallucination	Faible. Si le document source contient des erreurs ou si le résumé est incomplet, l’IA doit « inventer » pour combler les trous.	Maximale (Par Saturation). En saturant la fenêtre de contexte avec des faits granulaires, on ne laisse « aucune place neuronale » au modèle pour inventer (halluciner).
Rôle du « Conteneur » (La Page)	Crucial. La structure de la page (Hn, balisage) donne le sens. Le contexte est défini par la page elle-même.	Secondaire. La page n’est qu’une source. Le sens est reconstruit par l’association de milliers de snippets provenant de sources disparates.

Le tableau compare l’indexation classique de Google (avec beaucoup de simplification) avec l’indexation dite sub document des LLMS.

Mais si on tient prends en compte le passage indexing de Google, la logique est la même : Google comme les LLMs analysent le contenu à l’échelle du passage, pas seulement de la page entière.

Donc un chunking propre et logique ne peut pas vraiment “heurter” ces systèmes. Il va plutôt dans le sens de leur façon de traiter l’information.

Pour arrêter la théorie et être vraiment à l’aise quand je recommande ça à mes clients, j’ai décidé de faire un petit test…

Le test : quel est l’impact du chunking sur la detection des entities et de la proximité sémantiques ?

Pour ne pas rester au niveau des intuitions, j’ai décidé de passer à l’épreuve du feu : l’API Google Cloud Natural Language.

Pourquoi celle-ci ? Eh bien… parce que c’est Google, déjà. Et parce qu’elle détecte les entités, un élément SEO/GEO souvent négligé, alors qu’utilisé stratégiquement et intelligemment, il est très révélateur.

Et surtout… je l’utilise beaucoup. Tellement que j’ai même bricolé, avec l’aide de Gemini, une petite interface perso pour l’utiliser directement, sans passer par le terminal ou VS Code à chaque fois. Game changer ⬇️

Même si ce n’est pas exactement l’algorithme de ranking, cette API est un miroir public de la façon dont Google comprend un contenu. C’est aussi une partie des briques qui alimentent le Knowledge Graph, donc ça reste très instructif pour tester l’impact du chunking sur la compréhension sémantique.

Objectif du test : chunking vs non-chunking

Grosso modo, je voulais mesurer comment le découpage du contenu (chunking) influence trois aspects clés :

1. Score de saillance (Salience) : le poids d’une entité dans le contexte global du document (0 à 1)
2. Détection des long tail entities : est-ce que des concepts techniques précis restent identifiés dans un contenu long et dense
3. Score sémantique des passages : comment le chunking impacte la relation entre les passages et les requêtes

Hypothèses

H0 – Texte long (non-chunké) :

Le “Global Context” est fort, Google comprend le thème général.

Mais une entité mentionnée au milieu d’un pavé de 2000 mots peut avoir une saillance quasi nulle (0.01), noyée dans le bruit.

H1 – Texte chunké :

En isolant cette même entité dans un paragraphe de 100 mots, sa saillance mécanique devrait exploser.

Mais… perd-on la catégorisation globale du document et les liens relationnels entre entités (triplets sujet-prédicat-objet) ?

Question centrale du test

Le chunking permet-il d’améliorer la détection précise des entités secondaires sans sacrifier la compréhension globale du document ?

Si nous découpons un article en morceaux arbitraires pour satisfaire une fenêtre de contexte ou un index vectoriel, risquons nous de briser le Fil Sémantique (Semantic Thread) ?

KPI du test sur l’impact du chunking :

Le Score de Saillance (Salience Score) est le KPI de ce test. La Salience indique l’importance d’une entité dans le contexte global du document.

• Score proche de 1.0 : C’est le sujet principal du texte.
• Score proche de 0.0 : C’est une mention anecdotique.

 Si votre mot-clé principal a une saillance faible, vous êtes hors-sujet aux yeux de Google.

Le Protocole de Test sur l’impact du chunking

Pour le contenu, j’ai opté pour l’article « L’Intelligence Artificielle » Wikipedia via API pour obtenir le wikitext pur (sans bruit HTML).

Pourquoi ? C’est un texte long, dense, interconnecté, et c’est la base du Knowledge Graph de Google.

Je vais donc utiliser le meme article deux fois. Une fois sans decoupage et une deuxième fois avec decoupage (chunking).

Pour le découpage, j’ai utilisé LangChain « RecursiveCharacterTextSplitter"

Je joue aussi avec les paramètres du decoupage(pour mimer un chunking bien fait et un chunking amateur)

L’API Google Cloud Natural Language intervient en dernier pour la detection des entités.

PHASE 1 : Analyse du texte complet (Baseline)
- 262 entités détectées dans le texte complet.
- Top entité : intelligence artificielle (Salience: 0.0801)

PHASE 2 : Découpage en chunks (200 chars) 
- Texte fragmenté en 82 morceaux.

Les résultats ? Chunking, oui ou non !

name	salience_full	avg_salience_chunk	delta_salience
systèmes informatiques	0,0362	0,064251	0,028051
ensemble	0,0217	0,084512	0,062812
probabilités	0,0088	0,075053	0,066253
informatique	0,0072	0,090179	0,082979
concepts	0,0065	0,146644	0,140144
sciences cognitives	0,0065	0,114593	0,108093
domaine	0,0057	0,08105	0,07535
algèbre linéaire	0,0056	0,097257	0,091657
statistiques	0,0056	0,097257	0,091657
fondements	0,0056	0,059433	0,053833

Interpretation des résultats : impact du chunking

L’explosion des « Mots de Liaison »

• Full Text : Salience de 0.0065 (C’est un mot accessoire, un bruit de fond).
• Chunks : Salience moyenne de 0.1466.
• L’analyse : Son importance a été multipliée par 22 !

« Quand on réduit la fenêtre de contexte à 200 caractères (l’équivalent d’un gros tweet), Google perd le sens des proportions. Le mot ‘Concepts’, qui n’est qu’un terme générique dans l’article global, devient soudainement le Sujet Principal du passage.

La conséquence SEO/GEO : Si Google indexe ce fragment pour un AI Overview, il risque de classer ce passage pour des requêtes informationnelles très vagues (intent mismatch) au lieu de le classer pour ‘Intelligence Artificielle’. »

Le phénomène du « Topic Drift » (Dérive Thématique)

Regardez « Probabilités » et « Statistiques ».

• Ils gagnent environ +0.06 à +0.09 de salience.

« Dans l’article complet, les statistiques ne sont qu’un outil de l’IA. Mais une fois le texte découpé, le lien de subordination est brisé. Dans le chunk isolé, Google ne voit plus ‘L’IA utilise les statistiques’, il voit ‘Ceci est un texte sur les statistiques’.

Consequence SEO / GEO : au lieu d’avoir une page forte sur un sujet, vous vous retrouvez avec 82 morceaux faibles sur des sujets mathématiques disparates. C’est la cannibalisation sémantique par fragmentation. »

La perte de la « Reine Mère » (Le mot-clé principal)

Le mot-clé « Intelligence artificielle » (Top entité du full text avec 0.0801) n’est pas dans ton Top 10 des gains.

Il s’est fait écraser par le bruit.

Alors que des mots secondaires comme ‘ensemble’ ou ‘domaine’ voient leur score exploser, le sujet réel du texte stagne.

Conclusion ?

Le chunking agressif (200 caractères) crée un bruit sémantique qui étouffe le signal principal. Pour Google, le morceau ne parle plus d’IA, il parle de ‘systèmes’, de ‘concepts’ et de ‘domaines’. »

À 200 caractères, nous sommes sous le seuil de cohérence sémantique (Semantic Coherence Threshold). Si vous optimisez pour les ‘Passages’ avec des paragraphes de 200 caractères, vous ne pouvez pas découper aussi fin sans injecter artificiellement du contexte (ex: répéter le mot-clé principal dans chaque fragment). »En l’occurence, répéter le mot cle principal quand c’est pas pertinent, n’est pas la meilleure des stratégie.

PHASE 2 du test

Avec 200 caractères, on avait une « Explosion de Bruit » (des mots génériques devenaient des sujets principaux).

J’ai donc relancé le test en quadruplant la taille des fragments (800 caractères) et en ajoutant un filet de sécurité (50 caractères d’overlap pour ne pas couper les phrases). Les résultats sont sans appel.

L’effondrement du bruit générique (Le retour au calme)

Si on regarde le mot : « Concepts » encore une fois :

• Test 200 chars  Delta +0.14 (Enorme hallucination de pertinence).
• Test 800 chars : Delta +0.001 (Quasi nul).

En passant à 800 caractères (environ un paragraphe complet), Google a assez de mots autour pour comprendre que « concepts » n’est pas le sujet, mais juste un mot de la phrase. Le contexte a dilué le bruit.

La leçon SEO / GEO : Un fragment doit contenir suffisamment de mots pour que l’IA puisse faire la différence entre le Sujet et le Vocabulaire.

L’apparition des Deltas Négatifs : Un signe de santé

Si on regarde le mot : « Informatique »

• Test 200 chars : +0.08 (Suroptimisé).
• Test 800 chars : -0.0008 (Légèrement sous-évalué).

La distribution de l’importance dans le chunk commence à ressembler à celle du texte complet.

Avec 800 caractères (environ 120 mots), nous offrons à Google l’équivalent d’un paragraphe structuré. L’analyse montre que les scores de saillance se rapprochent de ceux du document complet. Pas mal, hein !

L’impact de l’Overlap (Chevauchement) 

Les 50 caractères de chevauchement ont permis de lisser les transitions. Nous n’avons plus d’entités coupées en deux qui génèrent des faux positifs. »

Le « Sweet Spot »

Si on regarde système informatique, Il reste haut (+0.06). Cela indique que ce terme est probablement le sujet central d’un ou deux paragraphes spécifiques. À 800 caractères, Google identifie correctement ce sous-sujet sans pour autant halluciner sur des mots vides.

Mon avis SEO / GEO sur le chunking

• Évitez les chunks trop courts : en dessous de 600 à 800 caractères, le découpage devient trop granulaire et fait remonter du bruit sémantique au lieu de vrais signaux.
• Privilégiez un découpage proche du paragraphe : des blocs plus larges permettent de mieux faire émerger des sous-thématiques cohérentes et exploitables en GEO.
• Ne négligez pas le chunk overlap : avec un overlap à 0, la continuité sémantique est cassée et les performances chutent.
• Côté rédaction, cela implique des transitions naturelles entre paragraphes et une continuité dans les termes et les idées : les blocs ne doivent jamais fonctionner comme des silos isolés. Il faut donc trouver le juste milieu entre indépendance des paragraphes et continuité des idées.