Chunking et GEO : ce que la documentation dit du découpage en passages

Le « chunking » désigne le découpage d'un document en morceaux (chunks) que le système indexe, compare à une question, puis fournit à un modèle de langage. Dans un système de recherche augmentée (RAG), ce n'est généralement pas la page entière qui est retrouvée mais un ou plusieurs passages. Pour un rédacteur, cela change une chose : chaque section doit pouvoir être comprise seule. En revanche, personne en dehors des éditeurs concernés ne sait comment tel assistant grand public découpe réellement vos pages ; cet article distingue ce que la documentation établit de ce qui relève du conseil éditorial.

Ce que dit la documentation : pourquoi on découpe

La documentation d'Azure AI Search explique que partitionner de gros documents permet de rester sous les limites d'entrée des modèles (par exemple 8 191 tokens pour le modèle d'embedding text-embedding-3-small d'Azure OpenAI) et d'éviter les pertes dues à la troncature. Elle ajoute que le découpage est aussi utile quand un contenu est mal représenté par un seul vecteur : une page wiki qui couvre de nombreux sous-sujets peut donner de meilleurs résultats découpée plus finement, même si elle tient dans la limite du modèle.

Amazon décrit la même logique pour ses bases de connaissances Bedrock : à l'ingestion, les documents sont d'abord scindés en chunks, convertis en embeddings (représentations vectorielles) et écrits dans un index vectoriel, avec un lien vers le document d'origine.

Les stratégies de découpage documentées

Les trois documentations lues décrivent des familles de méthodes proches :

  • Taille fixe. Azure cite à titre d'exemple 200 mots ou 600 caractères, avec un recouvrement de 10 à 15 %, et recommande par ailleurs de démarrer à 512 tokens avec 25 % de recouvrement. Bedrock propose un découpage par défaut d'environ 300 tokens qui respecte les limites de phrases. Pour son outil de recherche dans les fichiers, OpenAI indique dans la référence de l'API Vector Stores une stratégie automatique de 800 tokens maximum par chunk avec 400 tokens de recouvrement.
  • Taille variable selon la structure. Azure indique que le balisage HTML ou Markdown, avec ses titres, peut servir à découper par sections.
  • Sémantique. Azure et Bedrock décrivent un découpage qui cherche des unités de sens ; Bedrock précise qu'il utilise un modèle de fondation et entraîne un coût supplémentaire.
  • Hiérarchique. Bedrock décrit des chunks « enfants » retrouvés puis remplacés par des chunks « parents » plus larges pour donner plus de contexte au modèle.

Ces chiffres sont des paramètres par défaut ou des recommandations de fournisseurs pour leurs propres produits, configurables par leurs clients. Ils ne disent rien de la manière dont Google, ChatGPT, Perplexity ou Claude traitent le web public, et il ne faut pas les lire comme tels.

Ce que cela implique pour le GEO : ce qui se déduit

Deux éléments documentés sont utiles à un éditeur de site. Premièrement, un système peut ne retrouver qu'un fragment : le recouvrement et les chunks parents servent notamment à préserver le contexte quand on coupe un texte. Deuxièmement, la documentation Azure note que du balisage avec titres peut servir de frontière de découpage. Une page bien titrée offre donc au moins une prise structurelle, quand le système l'exploite.

Ce qu'on ne peut pas affirmer : qu'un assistant précis découpe selon vos H2, qu'il y ait une taille idéale de paragraphe pour être cité, ou qu'une rédaction « adaptée au chunking » augmente les citations. Aucune des sources lues ne le démontre.

Conseils éditoriaux de notre cru (non documentés)

Ces pratiques découlent du principe ci-dessus et ne sont pas des règles publiées par un moteur :

  • Une section, une idée. Évitez de mélanger plusieurs sujets sous un même intertitre ; un fragment isolé garde ainsi un sens.
  • Nommer le sujet dans la section. Écrivez « le rapport de performances » plutôt que « il » quand le référent est trois paragraphes plus haut. Un passage extrait sans son contexte doit rester interprétable.
  • Répondre d'abord, développer ensuite. Placer la réponse en début de section aide un lecteur humain autant qu'un extracteur.
  • Intertitres descriptifs. « Quelle durée de conservation des données ? » informe mieux qu'« Aspects importants ».
  • Garder ensemble ce qui va ensemble. Un tableau, une liste ou un exemple doivent rester accompagnés de la phrase qui les explique.
  • Éviter les sections minuscules ou interminables. Nous n'avons pas de seuil sourcé ; un ordre de grandeur de quelques paragraphes par section est une préférence de lecture, non une norme.

Sur le contenu en général, Google indique dans sa documentation sur les fonctionnalités d'IA que les contenus importants doivent être disponibles sous forme textuelle et qu'aucune optimisation spéciale n'est requise pour apparaître dans AI Overviews ou AI Mode. Cette page ne parle pas de chunking. Pour la narration et la lisibilité, voir aussi le storytelling GEO et la page GEO.

Limites de cet article

Les sources décrivent des services de RAG destinés à des entreprises qui indexent leurs propres documents, pas le fonctionnement des assistants grand public sur le web ouvert. Nous n'avons trouvé aucune documentation lue sur le découpage appliqué aux pages web par Google, ChatGPT, Perplexity ou Claude. Les paramètres cités peuvent changer. Les conseils de la section dédiée sont des hypothèses de rédaction, non testées ici.

Sources

microseo.fr propose une analyse gratuite de la structure d'une page ; l'outil n'évalue pas les citations réelles par les IA.